在之前的文章中，我們從容器OS、容器引擎，基礎架構的容器網路、儲存、安全，容器執行必不可少的映象倉庫、編排，及運維關注的監控、日誌，多維度關注並解讀了容器生態圈中的各個玩家。總體而言，較為活躍的有Google主導的kubernetes生態，和Docker公司主導的docker生態。選擇哪個技術流派從某種意義上，也決定了選擇哪種生態，這也是當前使用容器的公司面臨的一大難題。

本文將從容器引擎為切入點，說明這兩大流派的歷史、初衷和技術對比。

容器引擎玩家知多少

看到這個標題，你的表情可能是這樣滴[驚愕]：納尼？容器引擎不就是docker麼？這時，CoreOS可能在後面默默地流淚，因為CoreOS的

Rocket與Docker 引發的站隊

前世

這裡讓我們先來八一個卦，故事要從2013年開始說起。是的，Docker公司在2013年釋出了後來紅遍大江南北的docker產品，一場新的技術帶來一次新的革命，也帶來新的市場機遇，CoreOS也是其中的一員，在容器生態圈中貼有標籤：專為容器設計的作業系統CoreOS。作為互補，CoreOS+Docker曾經也是容器部署的明星套餐。值得一提的是，CoreOS為Docker的推廣和原始碼社群都做出了巨大的貢獻。

然而好景不長，CoreOS認為Docker野心變大，與之前對Docker的期望是“一個簡單的基礎單元”不同，Docker也在通過開發或收購逐步完善容器雲平臺的各種元件，準備打造自己的生態圈，而這與CoreOS的佈局有直接競爭關係。

2014年底，CoreOS的CEO Alex Polvi正式釋出了CoreOS的開源容器引擎Rocket（簡稱rkt），作為一份正式的“分手”宣告。當然，Docker的CEO Ben Golub也在官網作出了及時迴應，總體意思表明沒有違背初心，但這些都是應使用者和貢獻者的要求而擴充套件的，希望大家能一起繼續並肩作戰。

今生

當然，我們都知道了後來的事實，作為容器生態圈的一員，Google堅定的站在了CoreOS一邊，並將kubernetes支援rkt作為一個重要里程碑，Docker釋出的docker 1.12版本開始集成了叢集swarm的功能。作為相親相愛的一家人，Google於2015年4月領投CoreOS 1200萬美元，而CoreOS也釋出了Tectonic，成為首個支援企業版本kubernetes的公司。從此，容器江湖分為兩大陣營，Google派系和Docker派系。

而CoreOS除了Rocket和CoreOS外，也提供類似dockerhub的Quay的公共映象服務，也逐步推出容器網路方案flannel、映象安全掃描Clair、容器分散式儲存系統Torus（2017年2月在對應github專案上表示停止開發）等優質的開源產品，包括早期的etcd，各個產品都和kubernetes有了很好的融合。

CNI&CNCF

在兩大派系的強烈要求（對撕）下，2015年6月，Docker不得已帶頭成立了OCI組織，旨在“制定並維護容器映象格式和容器執行時的正式規範（“OCI Specifications”），以達到讓一個相容性的容器可以在所有主要的具有相容性的作業系統和平臺之間進行移植，沒有人為的技術屏障的目標 （artificial technical barriers）”。在2016年8月所羅門和Kubernetes 的Kelsey Hightower的Twitter大戰中，所羅門透露出對容器標準化消極的態度。

有意思的是，同年（2015年）7月，Google聯合Linux基金會成立了最近國內容器廠商陸續加入的CNCF組織，並將kubernetes作為首個編入CNCF管理體系的開源專案。旨在“構建 雲原生 計算並促進其廣泛使用，一種圍繞著微服務、容器和應用動態排程的以基礎設施架構為中心的方式”。陸續加入CNCF的專案有CoreDNS，Fluentd（日誌），gRPC, Linkerd（服務管理），openTracing，Prometheus（監控）。

Docker與Rocket的半毛錢關係

為了表示本文真的是篇技術型文章，也來說說Docker和Rocket的一些對比。

Docker和Rocket目前都遵循OCI標準，但兩者對容器引擎的設計初衷有較大差異：

功能邊界

總的來說，CoreOS認為引擎作為一個獨立的元件，而Docker目前已發展成為一個平臺，這也是CoreOS推出Rocket的官方原因之一。從功能角度來對比，Docker提供了日誌、映象和管理，甚至在1.12版本集成了swarm叢集功能。而Rocket（rkt）的邊界為在Linux系統上執行應用容器的功能元件。

表1 常用功能對比

容器安全

容器安全也是CoreOS一直詬病docker的地方，docker自1.10後的版本在安全性上也在不斷增強。以下從容器的安全方面，包含映象、系統、容器執行時三部分橫向對比。需要說明的是，映象安全中映象掃描也尤為重要，Docker Cloud和DockerHub提供線上漏洞掃描，CoreOS也提供了Clair開源專案對接CVE庫進行映象的漏洞掃描。

表2 安全對比

相容性

除了兩者在功能和安全上的對比，為了使用者方便評估，在相容性上也稍作比較。可以看到，釋出較晚的rkt在對Docker相容性方面採用包容的態度，且rkt和kubernetes保持一致，基本執行單元為pod。

表3 相容執行單元對比

總結

本文從歷史的角度說明rkt的由來，及引伸的技術流派問題。同時，也對Docker和rkt從設計（功能、安全和相容性）的初衷進行簡單對比。如果單從Docker和rkt社群相比，Docker目前熱度更高，但後續如何發展，與其說是簡單的Docker和rkt對比，倒不如說是兩大技術流派的選擇。

對於容器引擎的選擇，雖然rkt在安全和相容性設計上更勝一籌，但當前使用者使用Docker較多，筆者分析主要也是以下原因：

1. 安裝便利性。對於企業常用的OS，在CentOS中進行yum和Ubuntu中進行apt-get，即可方便安裝；同比，目前CoreOS官網資訊表明，rkt針對CentOS版本還不能使用在生產環境中，對ubuntu也沒有釋出對應的安裝包。另外，對於國內的網路環境，筆者科學上網後幾經波折才下載到rkt的release版本。
2. 社群活躍度。從兩者在github中的資料，可以看到Docker社群無論在貢獻者數量和提交次數上都比rkt社群要多，一定程度上也說明了兩者使用者的使用數量。這點和兩者首個版本釋出的時間有很大關係。

鑑於以上，建議容器平臺使用者和學習者目前可以優先考慮Docker作為容器引擎，或是直接使用容器相關廠家提供的從容器引擎到容器雲平臺的整體解決方案。對於需要基於容器進行二次開發形成產品的容器廠家，尤其是基於kubernetes提供服務的廠家，建議同時對rkt保持關注。