讓容器在網路上擁有自己的位址：得到什麼，付出什麼

預設的安排是這樣：容器共用主機的位址，透過連接埠號碼存取。這種做法簡單、安全，對大多數工作來說也已足夠。

但有些情況並不夠用，而且這些情況是可以預料的。

連接埠號碼不夠用的時候

兩個應用程式想用同一個號碼。把其中一個改到別的號碼之後，應用程式自己產生的連結並不會帶上新的號碼，事情就開始混亂。

應用程式會在網路上宣告自己。尋找印表機、尋找媒體播放器、尋找智慧家庭裝置：這些都靠自我廣播的訊息運作。這些訊息無法通過連接埠對應。應用程式宣告了自己，但宣告出去的是主機的位址，另一端無法連到它。

希望應用程式出現在路由器的裝置清單中。為了給它固定位址、為它另外撰寫防火牆規則、單獨查看它的流量。使用連接埠對應時，就網路而言這個應用程式並不存在，存在的只有主機。

另一種做法：給容器自己的身分

容器以自己的硬體位址出現在網路上，向路由器取得自己的位址，並像實體裝置一樣列在裝置清單中。

聽到這裡，第一個反應通常是：為什麼不是每個人都這樣做？答案就在代價裡。

代價一：主機連不到自己的容器

這是最讓人意外的部分，而且通常在工作完成後才被發現。

網路上的每台裝置都能連到那個容器。承載它的主機卻不能。

原因很合理：兩者使用同一個實體網路介面，而流量不會從交換器折返。主機把封包送出去，封包不會回到它自己的網路卡。

後果都很日常：在主機上執行的健康檢查連不到應用程式，同一台主機上的另一個容器無法連線，自行撰寫的腳本無法運作。這一切都發生在網路從外部看來毫無瑕疵的時候。

解法是有的，但它是額外的一塊：在主機上開一個附加在同一張網路卡上的第二個虛擬介面，讓前往容器位址的流量經由它路由。裝好之後問題就消失，但因為它是附加的東西，一旦被遺忘，就沒有人明白原因。

代價二：會用掉一個真實的位址

每個容器都會用掉網路中的一個位址。十個應用程式就是十個位址。在小型網路上很快就會碰到上限。

此外，如果位址來自租約，它可能會改變。一旦改變，所有綁定在它上面的東西，包括自行撰寫的規則，都會悄悄指向錯誤的地方。

代價三：網路卡與防火牆

網路卡必須能接受多個硬體位址。大多數無線連線做不到，有些虛擬環境則預設停用這項功能。決定之前務必先測試。

而防火牆現在會看到網路上出現一台它不認得的裝置。對建立者來說那是容器，對撰寫規則的人來說那是一台普通的裝置。這本身不是問題，但如果沒有說明，總有一天會讓某個人困惑。

只有位址不夠，還需要名稱

有位址卻沒有名稱的應用程式，只得到一半的好處。沒有人想背位址。

要在網路上宣告名稱，必須有某個東西負責這件事。應用程式本身的映像檔通常沒有這個元件，也沒有理由要有：資料庫映像檔本來就不需要在網路上宣告自己。

原則

連接埠對應是替一扇門編上號碼。網路身分則是授予公民身分。

只有在網路確實必須把該應用程式當成一台裝置看待時，才授予公民身分。不需要的時候，連接埠號碼既簡單又安全。

Atlas 的做法

Atlas 建立這種配置時不會動到應用程式本身的映像檔。它會在應用程式旁邊開一個小型的輔助容器，這個輔助容器共用應用程式的網路堆疊。由輔助容器向路由器要求位址，也由輔助容器在網路上宣告名稱。

這種附掛方式是刻意的，帶來兩個好處。應用程式的映像檔不需要內含取得位址的用戶端或宣告名稱的程式。而且因為網路堆疊屬於應用程式，應用程式停止時，輔助容器也會跟著停止，不會留下孤兒容器。

針對主機連不到自己容器的問題，會安裝上述的橋接介面，而且是以服務的形式安裝，因此主機重新啟動時它會自行重建。

真正值得一提的，是在實機測試中於這個橋接介面發現的一個錯誤。

橋接介面會開啟一條通往容器位址的路由。但它不會刪除已經消失之容器的路由。重新啟動之後，一個臨時位址的路由被留在原地。後果是：如果之後另一台裝置取得了那個位址，原本要送往那台裝置的流量就會被導向橋接介面。所以這個錯誤傷到的不是容器，而是網路上無辜的第三方。

修正方式是讓橋接介面不再只是新增路由的東西，而是會刪除不再對應到運作中容器的路由。

一般性的教訓，在網路之外也成立：新增只是容易的那一半。一條路由、一條規則、一個對應，都是對世界所做的一項宣稱。世界改變時，沒有人撤回的宣稱就會變成謊言，而且受害的通常不是做出宣稱的人，而是與此毫不相干的人。