Docker 容器實戰 (三) ：Docker 的自我重新定位

原文作者：javaedge 原文連結 更多雲原生技術資訊可關注 阿裡巴巴雲原生技術圈

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

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在各個層次進行內建和創新的項目層出不窮。

Fig

而此時已經大紅大紫到“不差錢”的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

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

“ 阿裡巴巴雲原生 關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”