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

最近有很多關于Docker網(wǎng)絡管理的討論，對這個問題大家眾說紛壇。引起爭論的主要原因是近年來使用Docker的人越來越多，用戶逐漸意識到Docker的網(wǎng)絡缺陷亟待解決。當然，實際情況也是這樣，目前Docker的網(wǎng)絡能力嚴重不足，不支持復雜的設置，現(xiàn)在Docker的網(wǎng)絡模型存在性能問題且不易擴展。不過對于一個基本的應用而言Docker的網(wǎng)絡模型已經(jīng)很不錯了。然而，我們不能永遠停留在使用“基本應用”的級別上，伴隨著云計算和微服務的普及，這些還遠遠不夠。作為libcontainer的貢獻者之一，我想通過本文，發(fā)表一些自己的觀點。

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

我從Docker 0.7版本開始就關注它的網(wǎng)絡問題了，但我并不是直接一頭扎進源碼里研究。相反，我首先嘗試研究LXC網(wǎng)絡，我希望它可以幫助我找到問題的關鍵點并運用到Docker上。我聯(lián)系了Jerome并且對在未來在Docker中嵌入golang-pipwork hack達成了共識。接下來就是個漫長的故事。時間過去七個月了，我們并沒有在Docker-network-land這個項目上投入太多的精力，在GitHub上也鮮有人討論網(wǎng)絡相關的問題。當我打開那些需要解決的問題的鏈接的時候，我覺得是時候需要改變了。Docker們關心的是那些優(yōu)先級比較高的問題因為我們已經(jīng)有了pipework以及pipework衍生的工具。與此同時，越來越多的實用性工具使得我們能突破Docker的網(wǎng)絡局限。人們不再關心Docker的網(wǎng)絡問題，而只是通過一小部分人修復那些已經(jīng)存在的問題并添加一些新功能。

轉(zhuǎn)眼過了幾個月的時間，我們最終決定開始改變現(xiàn)狀。我們向官方提出了網(wǎng)絡方面的建議并建立了一個關于libnetwork的聊天室，盡管這些距離我們某些不成熟的想法有些遙遠?，F(xiàn)在參與討論的人越來越多。在我的觀點看來，這對Docker來說是至關重要的。值得欣慰的是社區(qū)里很多人也開始意識到這個問題。

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

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

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

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

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

說起Docker網(wǎng)絡的未來，我真的很興奮，我非常期待Docker能做出最正確的決定。最重要的是，我希望本文能激發(fā)更多的人能參與其中一同完善這個項目。

本文出自:http://www.ctocio.com/ccnews/17681.html