Docker 網路管理的未來

最近有很多關於Docker網路管理的討論，對這個問題大家眾說紛壇。引起爭論的主要原因是近年來使用Docker的人越來越多，使用者逐漸意識到Docker的網路缺陷亟待解決。當然，實際情況也是這樣，目前Docker的網路能力嚴重不足，不支援複雜的設定，現在Docker的網路模型存在效能問題且不易擴充套件。不過對於一個基本的應用而言，Docker的網路模型已經很不錯了。然而，我們不能永遠停留在使用“基本應用”的級別上，伴隨著雲端計算和微服務的普及，這些還遠遠不夠。作為libcontainer的貢獻者之一，我想透過本文，發表一些自己的觀點。

首先我需要先聊聊一些和網路相關背景知識。一開始的時候，Docker使用者和開發者就意識到Docker網路模型的不足，因為他們需要給Docker容器分配更多的IP地址，而使用LXC作為容器引擎卻不會為這個問題而感到苦惱。容器已經存在了相當長一段時間，只是由於Docker的出現好多人才去學習Linux的名稱空間（namespace），包括網路的名稱空間，它是Linux容器網路的基石。Docker Tinkerer Extraordinaire 寫了很多的部落格並開發了pipework工具，它可以幫助瞭解Docker的網路以及如何在Docker中構建複雜網路。雖然pipework很強大，但它也僅僅只是一個第三方的工具罷了，我們希望Docker原生的支援。

我從Docker 0.7版本開始就關注它的網路問題了，但我並不是直接一頭扎進原始碼裡研究。相反，我首先嚐試研究LXC網路，我希望它可以幫助我找到問題的關鍵點並運用到Docker上。我聯絡了Jerome並且對在未來在Docker中嵌入golang-pipwork hack達成了共識。接下來就是個漫長的故事。時間過去七個月了，我們並沒有在Docker-network-land這個專案上投入太多的精力，在GitHub上也鮮有人討論網路相關的問題。當我開啟那些需要解決的問題的連結的時候，我覺得是時候需要改變了。Docker們關心的是那些優先順序比較高的問題，因為我們已經有了pipework以及pipework衍生的工具。與此同時，越來越多的實用性工具使得我們能突破Docker的網路侷限。人們不再關心Docker的網路問題，而只是透過一小部分人修復那些已經存在的問題並新增一些新功能。

轉眼過了幾個月的時間，我們最終決定開始改變現狀。我們向官方提出了網路方面的建議並建立了一個關於libnetwork的聊天室，儘管這些距離我們某些不成熟的想法有些遙遠。現在參與討論的人越來越多。在我的觀點看來，這對Docker來說是至關重要的。值得欣慰的是社群裡很多人也開始意識到這個問題。

Docker的網路問題是極其複雜的，包括表面的和深層次的。它會涉及到非常多的專案，小到本地開發環境，大到類似牛逼的Kubernetes專案。當你閱讀了Kubernates關於網路方面的設計文件後，你會發現一些好點子。在過去的一年時間裡，我們開發了很多工具和類庫去解決網路問題。我真的希望正在進行的討論不會影響（fuck）到我們現有的工作，而是能夠為新人創造更好的環境。我之所以使用Fuck這個詞是因為我曾見識過一個壞決定是如何讓所有人失望的，這也是我對Docker的一點擔心。也許這些都只是人生經歷罷了，正如俗語有云：歷史教不給我們什麼，所以我只是替古人擔憂罷了。

對於我來說Docker不僅僅意味著軟體交付，不僅僅意味著DevOps。它是另一種開發工具。對我而言，Docker應該是一個工具，而且也許更重要的是一個平臺。嗯，是開放平臺，並且不是我們經常討論的那種軟體平臺。如果Docker準備讓使用者或者公司在現有的平臺上構建其解決方案，那它就不應該依賴其它專案。我希望官方不會這樣做，因為Docker的夥計們已經知道擺脫依賴LXC並使用自己的libcontainer專案來替代。類似的處理思路應該用到網路問題的上。

目前看到有一些計劃是打算將OVS專案關聯到Docker上來，從Linux Kernel 3.3開始，OVS專案就是核心的一部分。當我聽到這個的時候我覺得是不是腦袋讓驢踢了。首先宣告我並不是反對使用OVS，實際上，它是一個非常不錯的網路工具套件。它的設定比較複雜，對於新手來說有一個陡峭的學習曲線，但是一旦學會，OVS就可以幫你事半功倍。關於這個話題我聽到的一個討論是：“如果OVS工作在Docker上，那麼工作一切都變得很美好”。讓我告訴你，親們：如果讓我花費大量時間學習它，最後的結果只能是：“還好，可以用”。我並不想說的那麼憤世嫉俗，實際情況是在某些常用環境下OVS會崩潰。因此，使用OVS只是一種瘋狂的想法罷了。我並不想大家都認同我的說法。是的，你可以什麼都不做，也可以把他當做日常基礎工作。你可以讓系統管理員和網路工程師很開心，但是不全是這樣，同時也會讓開發者很孤獨。這是一個複雜的話題，當然解決問題並非只有一種方法(沒有銀彈)，所以我們不奢望真的有銀彈罷了。

這個帖子並不是討論是否將OVS成為Docker的一部分。我選擇談到OVS是因為，這可能是解決Docker網路問題的方案之一。我們討論的範圍有且不限於Docker的第三方專案，無論它是否開源。截止到目前，Docker們已經做了一些工作去避免這種問題的出現。很重要的一點是我們之前談到的問題：避免對某個專案的依賴。一旦你決定使用某個專案，你的注意力就不得不集中在避免損害已經作為有機整體的平臺構建專案的相互依賴的問題上。正如我們現在討論的專案例如 flannel、weave、docket等，還有更多的新增的專案平臺帶來的眾多依賴專案上。

目前有一個基於可插拔的網路後端設定看起來是個不錯的建議。但是這還需要一點時間，直到有基於硬體的可插拔的架構設計而不僅僅是解決網路問題，還有更多的Docker參與和時間的檢驗。這個改變發生在Docker的核心，目前正在從移動終端轉移到網路部分。我認為，給Docker們建立一個健壯的預設的後臺，而不是給使用者一些列的解決方案，強迫他們使用固定的路徑，是一個比較穩妥的做法。不可避免的我們會對其他專案引用和依賴，這將不會影響目前的Docker使用者，並且不會給未來的Docker使用者帶來影響。我們都明白不可能讓每個人都滿意，但是你可以建立一個友好的環境，用來建立自己的解決方案，這樣使得不同使用者可以共同工作而不會相互影響。如果你和我一樣加入可插拔的API專案，那麼我們就是在同一條船上的人了。

說起Docker網路的未來，我真的很興奮，我非常期待Docker能做出最正確的決定。最重要的是，我希望本文能激發更多的人能參與其中一同完善這個專案。

---

 

【編者的話】作者是一個極客，從Docker的0.7版本開始就關注了Docker的網路問題，本文雖然帶有些感情色彩，但也不難看到作者對Docker的痴迷程度，不難看出他那顆想讓Docker更好的心。文章分析了Docker的網路歷史，對相關的解決方案發表了自己的看法，作者期待Docker官方能做出最正確的決定。