925      阿裏雲  技術社區[雲棲]

容器，你還隻用Docker嗎？(下)

作者介紹

周暉，Pivotal大中國區雲計算首席架構師，有豐富的PaaS雲實際建設經驗，負責過國內某知名銀行已經生產上線一年的PaaS雲的架構設計和部分功能的實現，參與過某超算PaaS、某超市電商PaaS、某電力PaaS等項目的建設。

上文說到CaaS生態圈的公司如何應對Docker用捆綁方式從容器入侵CaaS領域，CaaS廠商通過容器抽象、標準化容器運行時RunC以及容器功能外化插件來重新定義容器。下麵我們繼續來看CaaS廠商的具體方案。

一、CaaS業界通過分解重組Docker技術來替代Docker的方案

和Cloud Foundry的架構模式類似，K8s也發展了CRI-O來取代Docker，架構圖如下：

CRI-O是Google的Kelsey和Docker CTO所羅門論戰之後的結果，論戰之後，Google就提出一個設想，要讓K8s調度的容器去Docker化，雖然他們一開始說的是要分支出一個Docker的分支來做容器，但是後來考慮到這樣做屬於刺刀見紅，殺傷力太大，所以在2016年6月先弄了一個OCID(OCI守護進程)，就是RunC的守護進程，和Docker Daemon有異曲同工之妙，該項目的維護人員此地無銀三百兩的說“這不是Docker的分支”。

由於OCID過於和Docker Daemon類似，隨後Google又把這個項目重新命名為—CRI-O(Container Runtime Interface，容器運行時接口，O表示OCI，也就是RunC的運行時接口)，這也反映了Google的心態，一方麵通過CRI對容器進行抽象，什麼容器我都支持，另外加一個O，我重點支持OCI的RunC，顯得不是那麼白刀子進紅刀子出，大家表麵上還是和平共處，而且顯得立意更高，通過容器抽象層進一步標準化容器，RunC隻是標準化容器運行時，CRI把對容器的調用管理等也標準化，潛台詞是Docker Daemon是非標準的、獨家的。

同時，Google也在向Mesos推銷其CRI-O，希望Mesos也采用其CRI-O的架構。

CRI-O對容器運行時提供基本管理功能，同時Google的K8s提供鏡像管理功能(Container/Images)，完全可以取代Docker的鏡像倉庫。K8s一方麵支持容器插件技術，另一方麵自己也製定實現一些容器插件，最典型的就是容器網絡插件，自己定義並實現了CNM的容器網絡插件。

因為K8s之前一直支持Docker，為了保持一定的兼容性，K8s繼續支持Docker容器，但是不再支持Docker超出標準容器之外的特定功能，也就是把Docker的定位和RunC等同化，Docker做的再多功能也不用。

和K8s類似，Mesos也不再隻支持Docker容器，而且對容器進行了抽象，項目名字直接就叫”Unified Containerizer”—統一容器。目前還是支持 Docker 和 Mesos Containerizer 兩種容器機製，未來就統一到”Unified Containerizer”。架構圖如下：

Unified Containerizer也支持插件架構，但是和Docker的插件不是完全一樣，設計的插件類型更豐富，包括三大類：

• 第一類是進程管理，支持容器之前的進程，這也是Mesos一貫的調度管理策略

• 第二類是隔離器: 在容器生命周期的各個階段提供擴展接口，保護了Docker的幾類插件，如網絡、磁盤、文件係統、卷插件。

• 第三類是容器鏡像管理，除了容器鏡像，還將支持虛機鏡像等。

Mesos的統一容器基本就包含了DockerDaemon、Docker倉庫等功能。

當然，由於之前一直支持Docker容器，目前階段Mesos還繼續支持Docker，但是也有自己的Mesos Containerizer容器機製。

從RunC逐步成熟，Cloud Foundry的容器引擎Garden就采用了RunC作為容器運行時，如下圖：

Garden取代DockerDaemon(Docker Daemon有內有Docker Server，Docker Server內有Docker引擎)，直接調用RunC來生成容器運行環境，同時CFGarden也支持容器插件，容器插件是獨立進程，在網絡插件方麵優先支持K8s的CMN插件標準。CF Diego有自己的鏡像倉庫管理，也可以從Docker倉庫中獲取Docker鏡像部署。

不得不對Garden的設計多說幾句，Garden包括之前的Warden，從一開始的設計就是容器抽象，使得可以支持不同的容器運行時，而且Garden做了三層抽象，所以Garden從一開始就支持.Net應用，不是通過Windows 2016的容器機製來實現，而是在.Net運行時模擬了一個容器的實現，所以Garden支持Windows的幾乎所有版本的.Net應用。

K8s CRI-O和Mesos的UnifiedContainerizer都借鑒了Garden的容器抽象設計思路，所以Garden也是第一個支持RunC的CaaS/PaaS。

從這個架構可以看出，Cloud Foundry的Garden基於RunC和容器插件，就替代了Docker的容器功能，共同的是RunC和容器插件，而Garden取代Docker Daemon的容器管理功能。

當然，Garden也支持直接部署Docker鏡像。

二、容器生態的演進

在對開源Docker分支進行了反複斟酌、放風聲、試探和討論之後，各方覺得殺傷力太大的方案。而重新回到了折中方案，以RunC為核心重新構建生態圈，並且通過插件來弱化容器在CaaS生態圈的重要性。

我們來看看生態圈的演進示意：

如上圖，標識了容器生態圈或是CaaS的演進變化。

最早隻有Docker和Garden兩大主流容器，Mesos和Google都專注於CaaS，容器就全部采用Docker，CloudFoundry由於在Docker之前就推出了Warden(後升級到Garden)容器，CF采用自己的容器打造了PaaS平台，形成了一個和諧的生態。

在Docker撈過界了，並且確實有些不符合企業生產係統的因素，包括後向兼容性、商標問題、穩定性問題，於是各CaaS/PaaS生態廠商組建OCI聯盟，打造RunC容器引擎，隻需要一個簡單的容器起停、管理等引擎，把Docker的容器功能一分為二，RunC作為一個簡單明了的運行環境，降低複雜度，提升穩定性，適合生產係統。而對於Docker容器的其他功能，則在各自的容器抽象層，依據需要去實現，而且因為Docker本身集成了太多功能，不利於生產環境穩定性要求，各個容器抽象層都采用插件模式，維持容器的簡潔性，需要什麼功能再插入容器，比如需要網絡就可以插入網絡插件，需要存儲和卷訪問，就插入存儲和卷的插件。

目前的形勢，就形成了Docker和各個CaaS/PaaS廠商在同一層麵競爭，在CaaS/PaaS平台，Docker並沒有什麼優勢，但是Docker想把其容器的廣泛使用的優勢在CaaS中延續，目前看來並不容易。容器的主要用戶還是個人用戶、開發者用戶、運維用戶，而CaaS是企業係統，二者目標客戶不同、技術要求不同。

隨著這個生態的演進，Docker容器會更多的用於開發、測試環境，而RunC在各個CaaS廠商的推動下會在生產環境得到廣泛的應用。

K8s目前基本隻支持RunC容器，對於Docker超出其容器抽象層之外的功能，一概不支持。同樣，Mesos也通過其Unified Containerizer隻支持RunC容器，目前還支持Docker，但是未來的規劃是隻支持Unified Containerizer。CF也通過Garden隻支持RunC，不支持Docker超出RunC之外的功能。

由於Docker的消極抵製，RunC的發展好像並不為人所知，但是RunC的發展還是很快的，RunC本身就簡單，通過版本的持續的迭代更新，目前已經達到生產可用，而且主流的PaaS/CaaS紛紛采用。Docker也從1.11開始內置RunC容器運行時。

除了RunC本身的發展，RunC的生態圈也在快速發展，這個生態圈就脫離了的Docker。比如最近的Riddler，就是一個把Docker容器轉換為RunC鏡像。

詳見https://github.com/jfrazelle/riddler。

三、你還隻用Docker嗎？

Docker作為目前最熱的容器開源項目，受到廣泛的追捧。但是也要清醒地看到Docker和容器生態圈的種種爭鬥，Docker通過注冊商標和在Docker中內嵌容器集群管理，擠壓生態圈其他公司的生存空間，而受到生態圈聯盟以RunC和相應的技術來製約Docker。

如果你是開發測試用Docker，那麼基本不受影響，可以繼續，這也是很多公司對Docker的定位。如果你是生產係統采用Docker(包括Swarm)，你就要注意，如果是你自己定製開發基於Docker/Swarm的CaaS(Container As a Service)，那問題也不大，出現漏洞或是定製可以自己打補丁，但是要意識到你的補丁不一定能合並到Docker的主幹版本。如果是你采用的是第三方給你定製的基於Docker和Swarm的CaaS，你就一定要當心了，他們針對Docker做的定製要合並到Docker的後續版本有相當的難度，因為對於Docker的補丁定製合並，除了Docker公司其他公司幾乎是沒有什麼控製力度的，還包括後向兼容性問題。

作為用戶或是容器生態圈的創業公司，不能一棵樹上吊死，如果在容器層麵隻考慮Docker，而不考慮RunC，可能會和CaaS/PaaS生態圈的標準越來越遠，未來和CaaS/PaaS的標準容器差異越來越大，主流的CaaS/PaaS廠商和技術，如K8s/Mesos/CloudFoundry均不再支持Docker容器超越RunC之外的功能，而隻支持插件對RunC功能的擴展。

業界更普遍的定位是Docker用於開發測試環境，而RunC用於生產環境，所以對於要在生產環境采用容器技術的，一定要研究RunC。

作為容器創業公司，很多是在Docker的風口成立的，但是由於Docker一家獨大和Docker注冊商標的法務問題，可能還沒有在風口起飛。應當可以考慮在OCI/RunC的生態圈進行相關技術的發展，OCI/RunC的生態圈受到實力強大的幾家公司的強力支持，如Google、CF基金會、Pivotal、Redhat、Mesos、CoreOS等。而且RunC的生態圈還剛剛起步，還有很大的發展空間。而且作為技術創新，對於技術的前瞻性判斷非常重要，方向判斷正確，一路辛苦是披荊斬棘，方向判斷錯誤，一路辛苦也是前程堪憂。

國內的公司對RunC的貢獻度越來越高，特別是華為，可能是國內公司中對RunC貢獻最大的。還有EasyStack、南大索芙特等的貢獻，反倒是一些著名的Docker創業公司看不到對RunC的貢獻。這一方麵反應了華為、EasyStack技術眼光和對社區的貢獻，另外也反映了為什麼華為和EasyStack在商業上也更成功一些。

四、對一些問題的提前答複

Docker對RunC有重大的貢獻，RunC的早期也是基於DockerLibcontainer，但是RunC在OCI下獨立發展，有貢獻的廠商遠遠不止Docker。在RunC項目後，在OCI的推動下，各個廠商積極貢獻，Docker的代碼貢獻並不占主導，更談不上主要是Docker在維護，更準確的說Docker是RunC的重要維護力量之一。

如下圖，是Git上RunC的代碼貢獻者排名：

前10個貢獻者中，Docker隻占2位，不得不提國內的公司華為代碼貢獻排名是相當的靠前。而且RunC的代碼貢獻者超過100人。

除了K8s/Mesos/CloudFoundry支持RunC容器運行時，Docker的容器從1.11開始也內置RunC作為容器運行時，說明RunC受到最為廣泛的支持。

而K8s/Mesos/CloudFoundry明確表示在容器抽象層不再支持Docker超越RunC之外的功能。

RunC屬於OCI，不再受Docker注冊商標的影響，對RunC的代碼貢獻不再受限於Docker。

用RunC相當於給你一個幹淨簡單的容器運行時，用Docker相當於不管你要不要，強塞給你一堆可能你不想用的東西。

對於RunC和Docker的技術區別，詳細請參考上篇的4.5。         

Docker現在是如日中天，但是3年前也是剛起步，也許可以說RunC就是3年前的Docker。Docker由於Docker公司自身的商業特征，對容器生態圈其他公司的生存空間的擠壓，已經造成了容器生態圈的裂變。

“風起於青萍之末”，如日中天的時候可能就是走向下坡路的開始。Docker一家和其他CaaS生態圈分裂，這條路注定是不平坦的。

黑Docker的資料很多，所有資料都有出處，有參考內容鏈接，詳見後麵的引用。

Docker已經被布道師們說成”無所不能”，稍微有幾個不能，我覺得大家還是能區別得出來。

RunC的自身發展遠不如Docker那麼有名氣，因為RunC本身就是一個很小的容器運行時，不是針對開發者的，開發者往往是通過Docker接觸到RunC，所以RunC的受眾遠比Docker要少。

但是對於CaaS項目來說，K8s/Mesos/CloudFoundry往往就是基於RunC容器運行時。

RunC的社區也很活躍，除了RunC本身的更新很快，各大CaaS/PaaS生態圈如Google/Pivotal/Redhat/華為/CoreOS等都有專人在貢獻代碼。

RunC相應的生態空間也在活躍，也有不同的項目在進行中。

RunC是CaaS/PaaS/OCI等生態圈共同的孩子，不是沒人看的孩子。

5、容器不需要標準更好

業界也有一些人持這個觀點。其實，標準的價值是常識，當然總會有反常識的言論出來。沒有標準就沒有合力，沒有合力哪來的發展。如果Docker公司把閉源，那可以沒有標準。既然是開源，又想要生態圈的其他公司和力量做貢獻，就要讓大家有合力，就要讓大家在標準的基礎做貢獻，而不是把生態圈的其他公司當作免費打工的。

五、總結和展望

Docker和CaaS生態圈在容器上的分裂已經是現在進行時了，雖然大家都沒有明說。這也將是容器和CaaS生態圈重要轉折事件。讓我們來看看目前正在發生的和在未來一年中很有可能發生的事情：

1. Cloud Foundry率先采用RunC作為容器運行時，而且剛剛做了一個25萬個容器集群的測試，https://www.cloudfoundry.org/cloud-foundry-approaching-250000-containers/  驗證了PaaS+RunC的大規模集群的支持。

   K8s的CRI-O也會盡快發布，等CRI-O成熟以後，內置的容器運行時就應當是RunC，而不再是Docker了。

2. Mesos的Unified Containerizer 也應當會在1年之內成熟，隨後內置的容器應當也是RunC，而不再是Docker。

3. 在Docker被科普以後，客戶更關注的是CaaS而不是容器，再給客戶去科普Docker體現不出容器創業公司的價值。

4. 一些不適合容器的Docker應用場景的案例會被證偽，在Docker和容器鮮為人知的時候，各種各樣的Docker案例層出不窮，包括一些明顯和常識有違的案例，比如交易係統采用Docker, 交易極嚴格的延時的要求不適合Docker。有的是故意混淆概念，交易本身不在Docker容器中，交易係統相關的一些模塊在Docker中，為了突出宣傳效果，說交易係統采用Docker。

5. Docker創業公司分化，越來越多的容器創業公司給別人介紹自己的時候會說我們是K8s初創公司(或我們是Mesos創業公司)，不是Docker創業公司，強調自己是CaaS廠商，突出自己不是Docker廠商。當然，也有純Docker的創業公司，但優勢會變成劣勢，畢竟在CaaS領域,Docker沒有優勢。

6. Docker在容器失去了K8s/Mesos/CloudFoundry的支持之後，會更專注於Swarm，和CaaS的其他廠商的競爭將更直接，但是Docker公司一貫的對企業生產環境特性的不在乎，Swarm很難對其他CaaS形成競爭優勢。

7. RunC的生態圈將越來越豐富，第一個就是把Docker鏡像轉換為RunC標準鏡像(這個已經有了)，其次就是各種各樣的插件和RunC可以交互，中間還可以衍生出各種插件的功能，如即插即用(動態性)、自動發現之內的。

原文發布時間為：2016-11-29

本文來自雲棲社區合作夥伴DBAplus

最後更新：2017-05-11 13:31:04

  上一篇：  仿微信陌陌映客社交項目整套出售並接受定製開發

  下一篇：  分布式實時處理係統在高性能計算場景下的應用