Docker網絡管理的未來：基于線程與基于事件的并發編程之爭
【寫在前面】作者是一個極客，從Docker的0.7版本開始就關注了Docker的網絡問題，本文雖然帶有些感情色彩，但也不難看到作者對Docker的癡迷程度，不難看出他那顆想讓Docker更好的心。文章分析了Docker的網絡歷史，對相關的解決方案發表了自己的看法，作者期待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能做出最正確的決定。最重要的是，我希望本文能激發更多的人能參與其中一同完善這個項目。
