小鯨魚大事記 | Docker誕生歷程之羣雄並起

做者：張磊

來源： 極客時間《深刻剖析Kubernetes》

在上一篇文章中，我剖析了Docker項目迅速走紅背後的技術與非技術緣由，也介紹了Docker公司開啓平臺化戰略的野心。但是，Docker公司爲何在Docker項目已經取得巨大成功以後，卻執意要從新走回那條已經讓無數先驅們塵沙折戟的PaaS之路呢？

實際上，Docker項目一日千里的發展勢頭，一直伴隨着公司管理層和股東們的陣陣擔心。他們內心明白，雖然Docker項目備受追捧，但用戶們最終要部署的，仍是他們的網站、服務、數據庫，甚至是雲計算業務。

這就意味着，只有那些可以爲用戶提供平臺層能力的工具，纔會真正成爲開發者們關心和願意付費的產品。而Docker項目這樣一個只能用來建立和啓停容器的小工具，最終只能充當這些平臺項目的「幕後英雄」。

而談到Docker項目的定位問題，就不得不說說Docker公司的老朋友和老對手CoreOS了。

CoreOS是一個基礎設施領域創業公司。 它的核心產品是一個定製化的操做系統，用戶能夠按照分佈式集羣的方式，管理全部安裝了這個操做系統的節點。從而，用戶在集羣裏部署和管理應用就像使用單機同樣方便了。

Docker項目發佈後，CoreOS公司很快就認識到能夠把「容器」的概念無縫集成到本身的這套方案中，從而爲用戶提供更高層次的PaaS能力。因此，CoreOS很早就成了Docker項目的貢獻者，並在短期內成爲了Docker項目中第二重要的力量。

然而，這段短暫的蜜月期到2014年末就草草結束了。CoreOS公司以強烈的措辭宣佈與Docker公司中止合做，並直接推出了本身研製的Rocket（後來叫rkt）容器。

此次決裂的根本緣由，正是源於Docker公司對Docker項目定位的不知足。Docker公司解決這種不知足的方法就是，讓Docker項目提供更多的平臺層能力，即向PaaS項目進化。而這，顯然與CoreOS公司的核心產品和戰略發生了嚴重衝突。

也就是說，Docker公司在2014年就已經定好了平臺化的發展方向，而且絕對不會跟CoreOS在平臺層面開展任何合做。這樣看來，Docker公司在2014年12月的DockerCon上發佈Swarm的舉動，也就一點都不忽然了。

相較於CoreOS是依託於一系列開源項目（好比Container Linux操做系統、Fleet做業調度工具、systemd進程管理和rkt容器），一層層搭建起來的平臺產品，Swarm項目則是以一個完整的總體來對外提供集羣管理功能。而Swarm的最大亮點，則是它徹底使用Docker項目本來的容器管理API來完成集羣管理，好比：

• 單機Docker項目：

$ docker run "個人容器複製代碼

• 多機Docker項目：

$ docker run -H "個人Swarm集羣API地址" "個人容器"複製代碼

因此在部署了Swarm的多機環境下，用戶只須要使用原先的Docker指令建立一個容器，這個請求就會被Swarm攔截下來處理，而後經過具體的調度算法找到一個合適的Docker Daemon運行起來。

這個操做方式簡潔明瞭，對於已經瞭解過Docker命令行的開發者們也很容易掌握。因此，這樣一個「原生」的Docker容器集羣管理項目一經發布，就受到了已有Docker用戶羣的熱捧。而相比之下，CoreOS的解決方案就顯得很是另類，更不用說用戶還要去接受徹底讓人摸不着頭腦、新造的容器項目rkt了。

固然，Swarm項目只是Docker公司從新定義「PaaS」的關鍵一環而已。在2014年到2015年這段時間裏，Docker項目的迅速走紅催生出了一個很是繁榮的「Docker生態」。在這個生態裏，圍繞着Docker在各個層次進行集成和創新的項目層出不窮。

而此時已經大紅大紫到「不差錢」的Docker公司，開始及時地藉助這波浪潮經過併購來完善本身的平臺層能力。其中一個最成功的案例，莫過於對Fig項目的收購。

要知道，Fig項目基本上只是靠兩我的全職開發和維護的，可它倒是當時GitHub上熱度堪比Docker項目的明星。

Fig項目之因此受歡迎，在於它在開發者面前第一次提出了「容器編排」（Container Orchestration）的概念。

其實，「編排」（Orchestration）在雲計算行業裏不算是新詞彙，它主要是指用戶如何經過某些工具或者配置來完成一組虛擬機以及關聯資源的定義、配置、建立、刪除等工做，而後由雲計算平臺按照這些指定的邏輯來完成的過程。

而容器時代，「編排」顯然就是對Docker容器的一系列定義、配置和建立動做的管理。而Fig的工做實際上很是簡單：假如如今用戶須要部署的是應用容器A、數據庫容器B、負載均衡容器C，那麼Fig就容許用戶把A、B、C三個容器定義在一個配置文件中，而且能夠指定它們之間的關聯關係，好比容器A須要訪問數據庫容器B。

接下來，你只須要執行一條很是簡單的指令：

$ fig up複製代碼

Fig就會把這些容器的定義和配置交給Docker API按照訪問邏輯依次建立，你的一系列容器就都啓動了；而容器A與B之間的關聯關係，也會交給Docker的Link功能經過寫入hosts文件的方式進行配置。更重要的是，你還能夠在Fig的配置文件裏定義各類容器的副本個數等編排參數，再加上Swarm的集羣管理能力，一個活脫脫的PaaS呼之欲出。

Fig項目被收購後更名爲Compose，它成了Docker公司到目前爲止第二大受歡迎的項目，一直到今天也依然被不少人使用。

當時的這個容器生態裏，還有不少使人眼前一亮的開源項目或公司。好比，專門負責處理容器網絡的SocketPlane項目（後來被Docker公司收購），專門負責處理容器存儲的Flocker項目（後來被EMC公司收購），專門給Docker集羣作圖形化管理界面和對外提供雲服務的Tutum項目（後來被Docker公司收購）等等。

一時之間，整個後端和雲計算領域的聰明才俊都聚集在了這個「小鯨魚」的周圍，爲Docker生態的蓬勃發展獻上了本身的智慧。

而除了這個異常繁榮的、圍繞着Docker項目和公司的生態以外，還有一個勢力在當時也是風頭無兩，這就是老牌集羣管理項目Mesos和它背後的創業公司Mesosphere。

Mesos做爲Berkeley主導的大數據套件之一，是大數據火熱時最受歡迎的資源管理項目，也是跟Yarn項目殺得難捨難分的實力派選手。

不過，大數據所關注的計算密集型離線業務，其實並不像常規的Web服務那樣適合用容器進行託管和擴容，也沒有對應用打包的強烈需求，因此Hadoop、Spark等項目到如今也沒在容器技術上投下更大的賭注；可是對於Mesos來講，天生的兩層調度機制讓它很是容易從大數據領域抽身，轉而去支持受衆更加普遍的PaaS業務。

在這種思路的指導下，Mesosphere公司發佈了一個名爲Marathon的項目，而這個項目很快就成爲了Docker Swarm的一個有力競爭對手。

雖然不能提供像Swarm那樣的原生Docker API，Mesos社區卻擁有一個獨特的競爭力：超大規模集羣的管理經驗。

早在幾年前，Mesos就已經經過了萬臺節點的驗證，2014年以後又被普遍使用在eBay等大型互聯網公司的生產環境中。而此次經過Marathon實現了諸如應用託管和負載均衡的PaaS功能以後，Mesos+Marathon的組合實際上進化成了一個高度成熟的PaaS項目，同時還能很好地支持大數據業務。

因此，在這波容器化浪潮中，Mesosphere公司不失時機地提出了一個名叫「DC/OS」（數據中心操做系統）的口號和產品，旨在使用戶可以像管理一臺機器那樣管理一個萬級別的物理機集羣，而且使用Docker容器在這個集羣裏自由地部署應用。而這，對不少大型企業來講具備着非同尋常的吸引力。

這時，若是你再去審視當時的容器技術生態，就不難發現CoreOS公司居然顯得有些尷尬了。它的rkt容器徹底打不開局面，Fleet集羣管理項目更是少有人問津，CoreOS徹底被Docker公司壓制了。

而處境一樣不容樂觀的彷佛還有RedHat，做爲Docker項目早期的重要貢獻者，RedHat也是由於對Docker公司平臺化戰略不滿而憤憤退出。但此時，它竟只剩下OpenShift這個跟Cloud Foundry同時代的經典PaaS一張牌能夠打，跟Docker Swarm和轉型後的Mesos徹底不在同一個「競技水平」之上。

那麼，事實果然如此嗎？

2014年註定是一個神奇的年份。就在這一年的6月，基礎設施領域的翹楚Google公司忽然發力，正式宣告了一個名叫Kubernetes項目的誕生。而這個項目，不只挽救了當時的CoreOS和RedHat，還如同當年Docker項目的橫空出世同樣，再一次改變了整個容器市場的格局。

第四階段、塵埃落定

在上一次的分享中我提到，伴隨着Docker公司一手打造出來的容器技術生態在雲計算市場中站穩了腳跟，圍繞着Docker項目進行的各個層次的集成與創新產品，也如雨後春筍般出如今這個新興市場當中。而Docker公司，不失時機地發佈了Docker Compose、Swarm和Machine「三件套」，在從新定義PaaS的方向上走出了最關鍵的一步。

這段時間，也正是Docker生態創業公司們的春天，大量圍繞着Docker項目的網絡、存儲、監控、CI/CD，甚至UI項目紛紛出臺，也涌現出了不少Rancher、Tutum這樣在開源與商業上均取得了巨大成功的創業公司。

在2014~2015年間，整個容器社區可謂熱鬧非凡。

這使人興奮的繁榮背後，卻浮現出了更多的擔心。這其中最主要的負面情緒，是對Docker公司商業化戰略的種種顧慮。

事實上，不少從業者也都看得明白，Docker項目此時已經成爲Docker公司一個商業產品。而開源，只是Docker公司吸引開發者羣體的一個重要手段。不過這麼多年來，開源社區的商業化其實都是相似的思路，無非是高不高調、心不心急的問題罷了。

而真正令大多數人不滿意的是，Docker公司在Docker開源項目的發展上，始終保持着絕對的權威和發言權，並在多個場合用實際行動挑戰到了其餘玩家（好比，CoreOS、RedHat，甚至谷歌和微軟）的切身利益。

那麼，這個時候，你們的不滿也就再也不是在GitHub上發發牢騷這麼簡單了。

相信不少容器領域的老玩家們都據說過，Docker項目剛剛興起時，Google也開源了一個在內部使用多年、經歷過生產環境驗證的Linux容器：lmctfy（Let Me Container That For You）。

然而，面對Docker項目的強勢崛起，這個對用戶沒那麼友好的Google容器項目根本沒有招架之力。因此，知難而退的Google公司，向Docker公司表示了合做的願望：關停這個項目，和Docker公司共同推動一箇中立的容器運行時（container runtime）庫做爲Docker項目的核心依賴。

不過，Docker公司並無認同這個明顯會削弱本身地位的提議，還在不久後，本身發佈了一個容器運行時庫Libcontainer。此次匆忙的、由一家主導的、並帶有戰略性考量的重構，成了Libcontainer被社區長期詬病代碼可讀性差、可維護性不強的一個重要緣由。

至此，Docker公司在容器運行時層面上的強硬態度，以及Docker項目在高速迭代中表現出來的不穩定和頻繁變動的問題，開始讓社區叫苦連天。

這種情緒在2015年達到了一個小高潮，容器領域的其餘幾位玩家開始商議「切割」Docker項目的話語權。而「切割」的手段也很是經典，那就是成立一箇中立的基金會。

因而，2015年6月22日，由Docker公司牽頭，CoreOS、Google、RedHat等公司共同宣佈，Docker公司將Libcontainer捐出，並更名爲RunC項目，交由一個徹底中立的基金會管理，而後以RunC爲依據，你們共同制定一套容器和鏡像的標準和規範。

這套標準和規範，就是OCI（ Open Container Initiative ）。OCI的提出，意在將容器運行時和鏡像的實現從Docker項目中徹底剝離出來。這樣作，一方面能夠改善Docker公司在容器技術上一家獨大的現狀，另外一方面也爲其餘玩家不依賴於Docker項目構建各自的平臺層能力提供了可能。

不過，不難看出，OCI的成立更多的是這些容器玩家出於自身利益進行干涉的一個妥協結果。因此，儘管Docker是OCI的發起者和創始成員，它卻不多在OCI的技術推動和標準制定等事務上扮演關鍵角色，也沒有動力去積極地推動這些所謂的標準。

這，也正是迄今爲止OCI組織效率持續低下的根本緣由。

眼看着OCI並沒能改變Docker公司在容器領域一家獨大的現狀，Google和RedHat等公司因而把與第二把武器擺上了檯面。

Docker之因此不擔憂OCI的威脅，緣由就在於它的Docker項目是容器生態的事實標準，而它所維護的Docker社區也足夠龐大。但是，一旦這場鬥爭被轉移到容器之上的平臺層，或者說PaaS層，Docker公司的競爭優點便馬上捉襟見肘了。

在這個領域裏，像Google和RedHat這樣的成熟公司，都擁有着深厚的技術積累；而像CoreOS這樣的創業公司，也擁有像Etcd這樣被普遍使用的開源基礎設施項目。

但是Docker公司呢？它卻只有一個Swarm。

因此此次，Google、RedHat等開源基礎設施領域玩家們，共同牽頭髮起了一個名爲CNCF（Cloud Native Computing Foundation）的基金會。這個基金會的目的其實很容易理解：它但願，以Kubernetes項目爲基礎，創建一個由開源基礎設施領域廠商主導的、按照獨立基金會方式運營的平臺級社區，來對抗以Docker公司爲核心的容器商業生態。

而爲了打造出這樣一個圍繞Kubernetes項目的「護城河」，CNCF社區就須要至少確保兩件事情：

1. Kubernetes項目必須可以在容器編排領域取得足夠大的競爭優點；

1. CNCF社區必須以Kubernetes項目爲核心，覆蓋足夠多的場景。

咱們先來看看CNCF社區如何解決Kubernetes項目在編排領域的競爭力的問題。

在容器編排領域，Kubernetes項目須要面對來自Docker公司和Mesos社區兩個方向的壓力。不難看出，Swarm和Mesos實際上分別從兩個不一樣的方向講出了本身最擅長的故事：Swarm擅長的是跟Docker生態的無縫集成，而Mesos擅長的則是大規模集羣的調度與管理。

這兩個方向，也是大多數人作容器集羣管理項目時最容易想到的兩個出發點。也正由於如此，Kubernetes項目若是繼續在這兩個方向上作文章恐怕就不太明智了。

因此這一次，Kubernetes選擇的應對方式是：Borg。

若是你看過Kubernetes項目早期的GitHub Issue和Feature的話，就會發現它們大多來自於Borg和Omega系統的內部特性，這些特性落到Kubernetes項目上，就是Pod、Sidecar等功能和設計模式。

這就解釋了，爲何Kubernetes發佈後，不少人「抱怨」其設計思想過於「超前」的緣由：Kubernetes項目的基礎特性，並非幾個工程師忽然「拍腦殼」想出來的東西，而是Google公司在容器化基礎設施領域多年來實踐經驗的沉澱與昇華。這，正是Kubernetes項目可以從一開始就避免同Swarm和Mesos社區同質化的重要手段。

因而，CNCF接下來的任務就是，如何把這些先進的思想經過技術手段在開源社區落地，並培育出一個認同這些理念的生態？這時，RedHat就發揮了重要做用。

當時，Kubernetes團隊規模很小，可以投入的工程能力也十分緊張，而這偏偏是RedHat的長處。更可貴的是，RedHat是世界上爲數很少的、能真正理解開源社區運做和項目研發真諦的合做夥伴。

因此，RedHat與Google聯盟的成立，不只保證了RedHat在Kubernetes項目上的影響力，也正式開啓了容器編排領域「三國鼎立」的局面。

這時，咱們再從新審視容器生態的格局，就不難發現Kubernetes項目、Docker公司和Mesos社區這三大玩家的關係已經發生了微妙的變化。

其中，Mesos社區與容器技術的關係，更像是「借勢」，而不是這個領域真正的參與者和領導者。這個事實，加上它所屬的Apache社區固有的封閉性，致使了Mesos社區雖然技術最爲成熟，卻在容器編排領域鮮有創新。

這也是爲什麼，Google公司很快就把注意力轉向了動做更加激進的Docker公司。

有意思的是，Docker公司對Mesos社區也是相似的見解。因此從一開始，Docker公司就把應對Kubernetes項目的競爭擺在了首要位置：一方面，不斷強調「Docker Native」的「重要性」，另外一方面，與Kubernetes項目在多個場合進行了直接的碰撞。

不過，此次競爭的發展態勢，很快就超過了Docker公司的預期。

Kubernetes項目並無跟Swarm項目展開同質化的競爭，因此「Docker Native」的說辭並無太大的殺傷力。相反地，Kubernetes項目讓人耳目一新的設計理念和號召力，很快就構建出了一個不同凡響的容器編排與管理的生態。

就這樣，Kubernetes項目在GitHub上的各項指標開始一騎絕塵，將Swarm項目遠遠地甩在了身後。

有了這個基礎，CNCF社區就能夠放心地解決第二個問題了。

在已經囊括了容器監控事實標準的Prometheus項目以後，CNCF社區迅速在成員項目中添加了Fluentd、OpenTracing、CNI等一系列容器生態的知名工具和項目。

而在看到了CNCF社區對用戶表現出來的巨大吸引力以後，大量的公司和創業團隊也開始專門針對CNCF社區而非Docker公司制定推廣策略。

面對這樣的競爭態勢，Docker公司決定更進一步。在2016年，Docker公司宣佈了一個震驚全部人的計劃：放棄現有的Swarm項目，將容器編排和集羣管理功能所有內置到Docker項目當中。

顯然，Docker公司意識到了Swarm項目目前惟一的競爭優點，就是跟Docker項目的無縫集成。那麼，如何讓這種優點最大化呢？那就是把Swarm內置到Docker項目當中。

實際上，從工程角度來看，這種作法的風險很大。內置容器編排、集羣管理和負載均衡能力，當然可使得Docker項目的邊界直接擴大到一個完整的PaaS項目的範疇，但這種變動帶來的技術複雜度和維護難度，長遠來看對Docker項目是不利的。

不過，在當時的大環境下，Docker公司的選擇恐怕也帶有一絲背注一擲的意味。

而Kubernetes的應對策略則是反其道而行之，開始在整個社區推動「民主化」架構，即：從API到容器運行時的每一層，Kubernetes項目都爲開發者暴露出了能夠擴展的插件機制，鼓勵用戶經過代碼的方式介入到Kubernetes項目的每個階段。

Kubernetes項目的這個變革的效果立竿見影，很快在整個容器社區中催生出了大量的、基於Kubernetes API和擴展接口的二次創新工做，好比：

• 目前熱度極高的微服務治理項目Istio；

• 被普遍採用的有狀態應用部署框架Operator；

• 還有像Rook這樣的開源創業項目，它經過Kubernetes的可擴展接口，把Ceph這樣的重量級產品封裝成了簡單易用的容器存儲插件。

就這樣，在這種鼓勵二次創新的總體氛圍當中，Kubernetes社區在2016年以後獲得了空前的發展。更重要的是，不一樣於以前侷限於「打包、發佈」這樣的PaaS化路線，這一次容器社區的繁榮，是一次徹底以Kubernetes項目爲核心的「百花爭鳴」。

面對Kubernetes社區的崛起和壯大，Docker公司也不得不面對本身豪賭失敗的現實。但在早前拒絕了微軟的天價收購以後，Docker公司實際上已經沒有什麼迴旋餘地，只能選擇逐步放棄開源社區而專一於本身的商業化轉型。

因此，從2017年開始，Docker公司先是將Docker項目的容器運行時部分Containerd捐贈給CNCF社區，標誌着Docker項目已經全面升級成爲一個PaaS平臺；緊接着，Docker公司宣佈將Docker項目更名爲Moby，而後交給社區自行維護，而Docker公司的商業產品將佔有Docker這個註冊商標。

Docke公司這些舉措背後的含義很是明確：它將全面放棄在開源社區同Kubernetes生態的競爭，轉而專一於本身的商業業務，而且經過將Docker項目更名爲Moby的舉動，將本來屬於Docker社區的用戶轉化成了本身的客戶。

2017年10月，Docker公司出人意料地宣佈，將在本身的主打產品Docker企業版中內置Kubernetes項目，這標誌着持續了近兩年之久的「編排之爭」至此落下帷幕。

2018年1月30日，RedHat宣佈斥資2.5億美圓收購CoreOS。

2018年3月28日，這一切紛爭的始做俑者，Docker公司的CTO Solomon Hykes宣佈辭職，曾經紛紛擾擾的容器技術圈子，到此塵埃落定。

如今，我來總結一下今天的主要內容

容器技術圈子在短短几年裏發生了不少變數，但不少事情其實也都在情理之中。就像Docker這樣一家創業公司，在經過開源社區的運做取得了巨大的成功以後，就不得不面對來自整個雲計算產業的競爭和圍剿。而這個產業的壟斷特性，對於Docker這樣的技術型創業公司其實天生就不友好。

在這種局勢下，接受微軟的天價收購，在大多數人看來都是一個很是明智和實際的選擇。但是Solomon Hykes卻多少帶有一些理想主義的影子，既然不甘於「寄人籬下」，那他就必須帶領Docker公司去對抗來自整個雲計算產業的壓力。

只不過，Docker公司最後選擇的對抗方式，是將開源項目與商業產品緊密綁定，打造了一個極端封閉的技術生態。而這，其實違背了Docker項目與開發者保持親密關係的初衷。相比之下，Kubernetes社區，正是以一種更加溫和的方式，承接了Docker項目的未盡事業，即：以開發者爲核心，構建一個相對民主和開放的容器生態。

這也是爲什麼，Kubernetes項目的成功實際上是必然的。

如今，咱們很難想象若是Docker公司最初選擇了跟Kubernetes社區合做，現在的容器生態又將會是怎樣的一番景象。不過咱們能夠確定的是，Docker公司在過去五年裏的風雲變幻，以及Solomon Hykes本人的傳奇經歷，都已經在雲計算的長河中留下了濃墨重彩的一筆。

戳此查看：第一階段嶄露頭角

戳此查看全文：極客時間《深刻剖析Kubernetes》