Docker公司為什麼在Docker項目已經取得巨大成功之後，執意走回已經讓無數先驅折戟的PaaS路呢？

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

這就意味著，只有那些能夠為用戶提供平臺層能力的工具，才會真正成為開發者們關心和願意付費的產品

而Docker項目這樣一個只能用來創建和啟停容器的小工具，最終只能充當這些平臺項目的“幕後英雄”。

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

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項目：

1

docker run "我的容器

• 多機Docker項目：

1

docker run -H "我的Swarm集群API地址" "我的容器"

所以在部署了Swarm的多機環境下

用戶只需要使用原先的Docker指令創建一個容器

這個請求就會被Swarm攔截下來處理，然後通過具體的調度算法找到一個合適的Docker Daemon運行起來。

這個操作方式簡潔明瞭，對於已經瞭解過Docker命令行的開發者們也很容易掌握。所以，這樣一個“原生”的Docker容器集群管理項目一經發布，就受到了已有Docker用戶群的熱捧

而相比之下，CoreOS的解決方案就顯得非常另類，更不用說用戶還要去接受完全讓人摸不著頭腦、新造的容器項目rkt了。

當然，Swarm項目只是Docker公司重新定義“PaaS”的關鍵一環而已

在2014年到2015年這段時間裡，Docker項目的迅速走紅催生出了一個非常繁榮的“Docker生態”。在這個生態裡，圍繞著Docker在各個層次進行集成和創新的項目層出不窮。

Fig

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

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

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

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

而容器時代，“編排”顯然就是對Docker容器的一系列定義、配置和創建動作的管理。而Fig的工作實際上非常簡單：假如現在用戶需要部署的是應用容器A、數據庫容器B、負載均衡容器C，那麼Fig就允許用戶把A、B、C三個容器定義在一個配置文件中，並且可以指定它們之間的關聯關係，比如容器A需要訪問數據庫容器B。

接下來，你只需要執行一條非常簡單的指令

1

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

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完全不在同一個“競技水平”之上。

那麼，事實果真如此嗎？

Kubernetes橫空出世

就在這一年的6月，基礎設施領域的翹楚Google公司突然發力，正式宣告了一個名叫Kubernetes項目的誕生

而這個項目，不僅挽救了當時的CoreOS和RedHat，還如同當年Docker項目的橫空出世一樣，再一次改變了整個容器市場的格局。

參考

• docker官網
• Docker實戰
• 深入剖析Kubernetes