539
容器，你還隻用Docker嗎？（上）
作者介紹
周暉，Pivotal大中國區雲計算首席架構師，有豐富的PaaS雲實際建設經驗，負責過國內某知名銀行已經生產上線一年的PaaS雲的架構設計和部分功能的實現，參與過某超算PaaS、某超市電商PaaS、某電力PaaS等項目的建設。
一、從一場容器的撕逼戰開始說起
從2016年7月底開始，Google Kubernetes布道師 Kelsey Hightower 和Docker的CTO Solomon Hykes在Twitter上發生了一場撕逼大戰，主題是要不要用RunC或其他容器來取代Docker引擎以及OCI的意義。
首先是Google的Kelsey挑事，說：“很多平台都可以跑Docker鏡像，已經不再需要Docker Daemon了。哪個會成功呢？”
Docker CTO Solomon馬上接招：“其他平台跑Docker鏡像是假的，其中隻有90%能正常工作，其餘10%則隨時可能會出問題。而且Docker還在演進中。”“所以嘛，聲稱‘可以跑Docker鏡像’的都是在撒謊。”
Kelsey Hightower反諷：“好吧，那我們就沒必要再提支持Docker了。我們實際支持的隻是Docker的容器格式”，“Docker擁有創建和分發鏡像的最佳工作流，而運行時，還是留給它的競爭者們吧。”
所羅門繼續強調Docker的不兼容性：“這些都是不完整的、不兼容的支持”，“他們也並不支持鏡像格式，鏡像的很多信息都會丟失”。
後來，所羅門急眼了，說“OCI就是個偽標準”。
此言一出，驚詫四方，因為OCI有50多家廠商參與，而且Docker還是重要貢獻者，有說“標準不是一個人可以決定對錯的”，有反諷的 “我相信工程師們樂於聽到他們創始人說他們做的工作是假貨”。
K8s的老大Tim Hockin直接就說“不爽你就走，不要假裝參與”。
所羅門不得不改口說“OCI標準的初衷是好的，隻可惜擴展太早，我不認同就得走？”
有人隨即反駁“隻有你一個人說擴展的太早，這是明顯的利益投射”。
所羅門還嘴硬“就因為我是唯一的不認同者，那我就必須離開？”
Kelsey隨後則直點主題，“有兩個問題在台麵上，一是容器需不需要標準化，二是需不需要由Docker來領導這個標準化的工作？”
Kelsey再以嘲諷的口吻自問自答“如果是Docker來回答這些問題，對第一個肯定是說不，那幹脆對第二個問題也同樣說不吧，這可不是對和錯的問題”。
因為事關OCI，Docker現在這麼鄙視RunC，OCI不得點出Docker你也是參與者就別鬧了， “Docker參與在OCI運行時和鏡像規範，也參與了每周的開發會議”。
Kelsey乘勝追擊，代表業界吐了個槽，“我一直相信Docker會給容器帶來很多，但是我真的擔心一個人想控製的太多”。Docker公司的控製欲早成為人們的吐槽點，什麼都想做，把整個生態圈其他的參與者逼到牆角去了。
看業界大佬撕逼，感覺和咋人民群眾撕逼沒太大差別。所羅門的撕逼技巧明顯略遜一籌，有點像祥林嫂反複說“其他容器就是和Docker不兼容，包括RunC”，但是沒說出個哪裏不兼容的道道。
二、容器撕逼之爭反應了容器生態麵臨的問題
我們來總結這次著名的撕逼事件的來龍去脈，這會成為容器界一個關鍵的曆史轉折事件。容器之爭始實際上是很早之前就起源於Docker生態麵臨的問題。
1、Docker商標的注冊圍剿了容器生態圈
從表麵上看，是容器標準之爭，其實，反應的是赤裸裸的利益問題。Docker從容器開始，在獲得社區的熱烈響應之後，就進入了圈地過程，而且第一招圈地就非常凶悍，把公司從dotCloud改名為Docker，然後注冊Docker商標，商標意味著當其他公司使用未經Docker社區許可的補丁、代碼或軟件包的時候時可能麵臨法律責任。這種情況下，一個公司可能因為補丁尚未經過Docker公司許可，抑或尚未被合並到項目中，而不能為客戶提供技術支持。
這不隻是法務上的圈地，對於很多采用Docker名字的，Docker公司給予了實際行動---口頭警告(誰叫Docker是人家注冊的名字呢，就好比weibo.com就是微博)，包括你建一個群名不加修飾限定的叫Docker,或是你要寫本書，不加修飾的叫DockerXXX，都容易受到Docker的警告。從法務上看這確實也屬於侵權，就看Docker要不要告你。
其後果就是第三方Docker生態廠商被迫忍受Docker公司任何對該開源項目作出的決定，在問題出現的時候等待Docker公司的補丁。最好的結果與Docker達成某種協議，由Docker公司來保證提供穩定的發行版本。那Docker的生態公司就淪為Docker公司的代理商了。
2、Docker攜容器引擎優勢進入容器集群管理，擠壓了容器生態圈的其他廠商生存空間
如果隻是口頭撕逼，那大夥兒看看熱鬧就可以了，事實上這涉及到巨大的利益和整體生態環境的分歧。
在Docker獲得廣泛關注以後，就利用Docker容器的廣泛性優勢來擠壓生態圈其他夥伴的生存空間。直接把Swarm內置在Docker中。和當年的Microsoft通過Windows捆綁IE來打擊NetScape有異曲同工之妙。
Docker公司原來隻在容器領域發展，K8s/Mesos等做容器集群管理，屬於CaaS(Container as a Service)，相互補充，互不競爭。等Docker容器被廣泛關注以後，Docker進入容器編排市場，收購了相關的技術以後推出Swarm的容器集群管理，從容器進入CaaS市場。2016年7月發布的Docker 1.12把Swarm內置到Docker中去了，Docker Swarm作為容器集群管理軟件，內置在Docker中，幾乎就是Windows捆綁瀏覽器IE的模式，這就是用不平等的市場優勢打擊了Google的K8s和Mesos等，Google也不是吃素的，所以7月底馬上就是和Docker CTO口頭開撕。
對於Docker生態圈的集群管理軟件K8s和Mesos等來說，不但是不平等的競爭，最關鍵的是在容器生態圈最能帶來商業價值的就是容器集群管理，單單容器本身並沒有太多的商業價值，容器沒有集群管理是很難進入企業運行環境的。因為容器的直接商業價值並不大，CaaS廠商也沒有自己做容器。容器用於生產係統，就必須有容器的集群管理，而K8s和Mesos已經進入了這個商業領域並且取得了一定的優勢。現在Docker進入這個領域，就直接和容器集群管理的公司競爭，但Docker又是必須進入這個領域，如果不進入這個領域，很難取得商業成功， Docker本身又經過多輪風投，風投給Docker帶來了巨大的盈利壓力，如果久久不能盈利，那風頭的臉色不會那麼好看了。
如果是公平競爭還好，比如Docker單獨發布Swarm的Docker集群管理，但是Docker直接把Swarm內置到Docker中去，安裝部署Docker就帶了Swarm，而Swarm的很多功能和K8s和Mesos是重疊的，K8s和Mesos再用Docker就顯得功能有大量重疊，而且帶來了係統的複雜性和不穩定性。
三、Docker的問題——業界對Docker的吐槽
在Google和Docker口水戰之後，業界對Docker的吐槽越來越多，主要包括以下幾點：
1、Docker向後兼容性問題
Docker被業界詬病最多的就是後向兼容性，Docker的新版本更關注的是革新性，而不是兼容性，但是，對於一個生產係統來說，後向兼容性至關重要，沒有後向兼容性，意味著每次Docker升級都帶來巨大的風險。
這也和Docker的企業文化有關，Docker更傾向於采納新技術，實現突破性的功能，這是典型的初創公司的企業文化，不斷的追加新功能，而不考慮企業級特性，更不考慮後向兼容的束縛。這個好處是能在個人粉絲中取得共鳴，這也是Docker快速流行的一個重要原因。任何特征都可能是雙刃劍，這種企業文化並不適合企業級，不考慮生產運行的可用性，對企業級應用來說可能是災難性的。
我們看看業界人士是怎麼說的：“Docker不斷地破壞向後的兼容性”，RackN公司的CEO Rob Hirschfeld說。RackN公司的應用程序生命周期管理平台同時使用和提供了Docker組件，因此對後端的改動將會對其支持的客戶的業務造成影響。
“Docker將Docker Engine用作一個產品，而不是一個社區用來構建自有服務的組件”，Hirschfeld指責道。這種基於產品的策略意味著使用者被逼著在Docker發布新的革新特性或者合並新的組件（如Swarm）的時候去修複其破壞的向後兼容的問題。
“盡管我們會使用這些發布的特性，然而這些改動會帶來一係列與穩定性、版本、遷移和後端兼容相關的問題”。
Bob Wise，一名三星SDS雲工程師，也同樣唿籲Docker放慢其容器創新的腳步，該公司同樣提供了基於雲的容器相關支持服務。
“如果你的團隊在深度使用Kubernetes、Mesos或Cloud Foundry，你需要一個穩定、簡單、無奇的容器實現方案，僅有最少的基本功能，由社區協商鏡像的創建、命名和發布”，Wise的一篇博客中寫道。“你需要使用每個都人都在使用的一個相同的、簡單的、無奇的容器實現方案。作為一個社區，我們需要放緩對於基本構建組件的變更速度。唯有穩定性才能讓構建其上的係統蓬勃發展。”
2、Docker容器在企業級方麵還有待提高
Docker雖然一直宣稱Production Ready，但是在實際的生產係統中同樣受到不少詬病。
看看業界人士的說法：
Apcera技術產品經理 Phillip Tribble在個人博客中，以一種外交辭令的口吻，讓Docker不要再把其新推出的特性鼓吹成一個完工的企業級可用的產品。Tribble寫道：“讓互聯網或者大會充斥著營銷材料，宣揚各種令人振奮的新特性，但實際上卻不如所說那樣能用，不是一個明智的做法”，Apcera的商業模式一部分是基於提供Docker容器的支持。
Tribble的帖子引發了其他人在Hacker News上表達他們的Docker經曆，包括一些新版本帶來的讓人傷心的bug。一位讀者談到一天中啟動70,000到90,000個容器，約9%左右的會因為“各種Docker bug”遇到問題，這個比例最近的一次升級後下降到了4%。
但也有一些人在稱讚Docker的穩定性，“我們一直在生產中使用Docker約3年了，還沒有發現什麼大的問題”，另一外讀者評論說，“它將一些很炫的Linux內核特性用簡潔的方式封裝了起來”。
當然也有不少Docker的支持者認為Docker公司的軟件是穩定的。同一個產品，在不同的客戶有截然相反的反應說明有的用的好，有的用的碰到不少問題，在不同的環境下缺乏一致性，這也是企業生產係統的大忌。
3、Docker撈過界了，越過了紅帽的操作係統界限？
哪些功能應該有Docker來實現，哪些功能應該由底層操作係統或者技術棧中的其他組件來負責處理？
在今年的很多會議上，包括 LinuxCon North America 2016，紅帽工程師 Dan Walsh 說紅帽陷入了困境，一方麵客戶越來越多的使用 systemd 來初始化Linux係統，而另一方麵Docker似乎不願使用systemd，取而代之使用Docker Daemon來提供初始化，服務激活，安全和容器日誌的相關功能。
“在過去的三年裏，我們一直試圖使systemd和Docker更好的整合，而我卻發現，兩個領導人都非常強烈的堅持己見”，Walsh說，兩個領導人指 Hykes和systemd的創造者-Lennart Poettering
“所以，當機器的時候，誰來負責啟動係統服務，是systemd還是Docker？”Walsh問到。一個拙劣的係統實現可能會導致systemd和Docker互相衝突。
紅帽為自己的客戶維護著自己的Docker版本分支，紅帽分支中的補丁Docker有一天可能會合並，或者永遠不。紅帽也冒著巨大的風險，紅帽的客戶也冒著巨大的風險。所以紅帽對Docker的支持其實遠不如Ubuntu,因為Docker已經侵入到OS的領域了。
即使是麵對以上種種吐槽，Docker也不打算折中一下，甚至也不打算照顧這些意見，而是繼續我行我素。
四、容器生態圈集群管理廠商的應對
——不用Docker，把容器引擎拆解重組
撕逼隻是矛盾爆發的階段總結，後麵就開始進入實質性的對抗階段了。容器生態圈的集群管理廠商如Google/Mesos也不是嚇大的，快要被Docker斷了財路——— “人為財死鳥為食亡”，其反應也直取Docker命門——在其CaaS中廢棄Docker，對容器進行抽象，用誰的容器都可以。容器運行時不再用Docker，而直接采用RunC，容器擴展功能通過插件來實現，基本就是全拋棄Docker了，這對Docker來說幾乎是生死之戰。
其實，容器技術本身的壁壘不高，Docker 2013年一開始也就是幾十人的開發隊伍，到現在也隻有200多人，各大廠商一直沒有重視這一塊，因為單單容器的商業價值比較低。真正要投入做容器，也隻是分分鍾的事情，隻不過Docker已經在容器領域形成了氣候，所以要走些變通的曲折路線。
各大廠商一起做個RunC，大家再隻用RunC還是輕而易舉的。
我們再來看容器最主要的兩個的技術來源：
-
Namespace---來源於IBM
-
cGroup----來源於Google
其他的容器核心技術都是Linux操作係統的功能，容器的核心技術是和Linux操作係統密切相關的，Docker本身在容器核心並沒有什麼貢獻，NameSpace和cGroup都不是Docker的，也和Docker無關。Docker也不是最早用容器技術的，Cloud Foundry比Docker更早把容器用於PaaS。
所以容器生態圈的公司撇開Docker做一個容器標準並不是什麼難事。
我們再從時間線來梳理這個撕逼事件，讓大家更直觀的理解：
1、提前鋪墊：先通過RunC把容器運行時分離出Docker
2012年，隨著Cloud Foundry的PaaS率先引入了容器技術，容器技術發展的愈發火熱，特別是Docker成為流行技術，形成了廣泛的生態圈，由於Docker一貫的控製欲，讓生態圈的其他大小夥伴難以參與，為破解這種狀況。Google先是支持CoreOS打造了Rocket容器，在Rocket和CF容器Garden的競爭壓力下，Docker終於同意容器標準化----RunC項目成立，通過RunC對容器運行時進行標準化。
於是容器生態圈終於達到了拆解Docker技術堆棧第一個小目標---通過RunC把容器運行時獨立於Docker之外。在 2015年6月成立OCI（Open Container Initiative）組織，掛在Linux基金會旗下。旨在圍繞容器格式和運行時製定一個開放的工業化標準。該組織超過50家大小成員，包括穀歌、Pivotal、Docker、CoreOS、微軟、亞馬遜、華為等一係列雲計算廠商，按照該開放容器格式標準（OCF, Open Container Format）製定的一種具體實現，當然Docker是RunC的重要貢獻者。
OCI對Docker意味著什麼，Docker不是不清楚， 知道RunC是來搶食的，除了會削弱自己的優勢，也還會被OCI標準束縛住，限製自己的發揮，所以Docker對OCI是消極抵製，但是無法和整個生態圈抗衡，不是不接受OCI和RunC。
麵對Google、RedHat或者Microsoft這樣的大公司，不管從技術實力還是財務實力，以及政治關係處理上，Docker應該都很難占到太多便宜。但是技術大勢所趨，Docker也無法抗拒。
2、RunC容器格式標準是什麼？
製定容器格式標準的宗旨概括來說就是不受上層結構的綁定，如特定的客戶端、編排棧等，同時也不受特定的供應商或項目的綁定，即不限於某種特定操作係統、硬件、CPU架構、公有雲等。
最核心，是通過格式標準化來脫離Docker，有利於CaaS生態圈的公司各自發展，但是在標準層麵匯聚。
3、RunC容器標準化宗旨
標準化容器的宗旨具體分為如下五條。
-
操作標準化：容器的標準化操作包括使用標準容器感覺創建、啟動、停止容器，使用標準文件係統工具複製和創建容器快照，使用標準化網絡工具進行下載和上傳。
-
內容無關：內容無關指不管針對的具體容器內容是什麼，容器標準操作執行後都能產生同樣的效果。如容器可以用同樣的方式上傳、啟動，不管是php應用還是mysql數據庫服務。
-
基礎設施無關：無論是個人的筆記本電腦還是AWS S3，亦或是Openstack，或者其他基礎設施，都應該對支持容器的各項操作。
-
為自動化量身定製：製定容器統一標準，是的操作內容無關化、平台無關化的根本目的之一，就是為了可以使容器操作全平台自動化。
-
工業級交付：製定容器標準一大目標，就是使軟件分發可以達到工業級交付成為現實。
RunC標準化是瞄準工業級交付和運行時的，和Docker定位不一樣。各個CaaS/PaaS生態廠商需要一個標準的容器運行時，然後圍繞著這個標準運行時各自發揮自己的技術優勢，做編排的、做集群管理的、做資源調度等等，形成真正的容器生態圈。
4、第一步：虛張聲勢揚言對Docker容器另起分支，廢棄Docker公司對Docker的獨一控製權
在和Docker撕逼之後，引起了業界的集體吐槽，然後Google進入第一步：虛張聲勢，先來個大殺招嚇唬Docker——嚐試分支開源Docker來廢除Docker公司對Docker容器的獨家控製權。
先是Google方放出風聲，要對開源的Docker Engine重起爐灶—分支出一個容器，馬上在業界引起巨大的波瀾。
“在諸多正在考慮的選項之中，包括可能會將整個開源的Docker Engine一起重起爐灶(fork)。據一些接近討論的人士透露，相關代表來自Red Hat、Google、CoreOS、華為和兩家大量使用Docker的客戶。”
隨後大家對Docker的代碼庫穩定性不足表達了各自的憂慮，因為這可能會在生產環境下基於Docker構建附加服務或者向客戶提供技術支持的時候招致各種麻煩。在表達各種對Docker公司在Docker Engine上管理的失望之後，沒有得到Docker的正麵響應，相當多的技術專家和公司是支持分支的。因為Docker也不是嚇大的，對種種指責不予理會。
但是，也有很強的聲音擔心Docker從此支離破碎：
“目前發生的這件事情，如果處理不得當，會讓讓容器生態係統支零破碎，並導致單個的容器再無可能適配多種目標運行時環境。” 一位Hacker News上的觀察員指出。
鑒於直接分支對整個生態會產生不可預知的影響，屬於殺敵三千自損八百的，雖然Docker CTO所羅門當初說OCI是個偽標準就是“殺敵三千自損八百”的招，但是碰到豬隊友不能把自己也變成豬。直接分支停留在口頭上。
5、第二步：通過RunC和插件來拆解Docker技術堆棧
在和Docker撕逼之後，引起了業界的集體吐槽，然後Google和業界進入第二步：
隨著RunC標準化的發展，RunC逐步成了構建容器運行隔離環境的標準，和Libcontainer的功能類似，Libcontainer對RunC也有很大的貢獻。那到底RunC和Docker是什麼關係，如下圖：
Docker從1.11開始就采用了右邊的架構，這其實是Docker公司折中妥協的結果，因為麵對Rocket和Garden的競爭，如果不支持RunC，那麼在容器馬上就會進入分裂競爭狀態。
而OCI業界希望能夠在容器的運行環境標準化，也就是構建出一個容器運行環境的這部分能標準化，在容器運行環境下不需要Docker龐雜的功能，容器運行時這部分占Docker的整體功能比重很小，所以OCI組織很快就達成的一致，發展RunC容器運行時。
所以，理解Docker和RunC的關係，你可以理解為RunC是Docker一部分，而且是構建容器隔離運行環境的一部分，而這一部分，也恰恰是CaaS的廠商所需要的，他們隻需要一個生產環境下的容器環境構建，不需要容器的鏡像打包等，這屬於開發測試所需。
通過RunC，也基本確定了CaaS/PaaS產品如Cloud Foundry/K8s/Mesos等隻需要RunC這個容器生產時的運行環境，而Docker更多的用於開發測試時。
除了RunC，容器插件也是一個關鍵的公有技術，把容器的功能擴展和外部交互的功能插件化，而插件在開源社區相當活躍，插件主要是四類：安全認證、存儲卷管理、網絡、IP池。比如各個存儲廠商都在開發或是已經開發了自己的存儲插件。
而這些插件也可以和RunC交互，通過上麵一層的集成，可以讓RunC用到這些插件。而插件也基本外化了Docker的功能。
雖然Docker定義和開發了很多插件，但是插件可以各自開發。插件隻要提供接口就可以容器運行時交互。不再局限於某個公司的插件。這裏不得不提到K8s開發的網絡插件CNM和Docker自身提供的CNI就不一樣，雖然理論上是可以相互兼容，但是實際上是兩套實現機製，而且CNM得到了CaaS/PaaS廠商更廣泛的支持。
通過RunC和插件，把Docker容器引擎的功能進行了分拆，而且分拆的部分都有了替代品，隻等下一步。
6、第三步：CaaS生態廠商通過容器抽象、RunC和插件來重組自己的容器技術堆棧
如下圖是各個業界廠商對Docker容器技術堆棧的進一步分拆，然後進行組合，形成各自自己的容器堆棧。分拆不是目標，是手段，組成成自己的容器才是目標。和我們的國產化替代是不是有點類似？
首先把Docker的技術堆棧分解為容器運行時RunC、插件、容器管理進程和容器倉庫。因為已經有了RunC的基礎，而且插件可以公用，各個廠商隻要做容器進程管理和容器鏡像管理，既然是新的技術架構，各個廠商也考慮到容器的兼容性，大家很一致的做了一個模塊，稱為容器抽象，無論是Mesos還是K8s。有的把容器鏡像也一起做在容器抽象層，有的是單獨再做一個鏡像管理。
看下圖右邊的重組後的技術架構，完全沒有了Docker，也不需要Docker，但是很自然而然的取代了Docker的容器。這就是很典型的對Docker技術棧分解，先取代最核心的容器運行時RunC，再把功能外化到插件，然後再做一個容器抽象層，徹底肢解並取代了Docker。
注意紅色的框架，通過RunC和插件，CaaS/PaaS業界把他們所需的容器功能從Docker中獨立出來了，也就是有了RunC和插件，CaaS/PaaS完全可以不需要Docker就構建出CaaS/PaaS運行環境。
行文至此，大家應當對容器生態圈的撕逼事情的來龍去脈、各個廠商的應對、撕逼原因以及整個容器生態圈的巨大變化有個初步了解，欲知後事，且聽下回分解。
原文發布時間為：2016-11-25
本文來自雲棲社區合作夥伴DBAplus
最後更新：2017-05-11 12:02:04