開辟 Docker 的分支：分離的討論現在已經擺上臺面

一些Docker生態系統的廠商和最終用戶正在進行一場從Docker分割出去的討論。在表達各種對Docker公司在Docker Engine上管理的失望背后，這些技術專家和公司實際上是在探索如何解決在支持企業級的Dokcer部署中遇到的各種煩心問題。

在諸多正在考慮的選項之中，包括可能會將整個開源的Docker Engine一起重起爐灶( fork )。據一些接近討論的人士透露，相關代表來自Red Hat、Google、CoreOS、華為和兩家大量使用Docker的客戶。

Red Hat和CoreOS的發言人否認了一切與Docker討論相關的消息。Docker公司拒絕公開就此置評。Google和華為截止發文前也尚未回應置評請求。

這是對容器生態系統影響深遠的時刻。這些技術專家和公司沒有任何一方希望采取fork的方式，但同時他們也對Docker的代碼庫穩定性不足表達了各自的憂慮，因為這可能會在生產環境下基于Docker構建附加服務或者向客戶提供技術支持的時候招致各種麻煩。

除此之外，許多參與分割討論的公司也是使用容器技術來建立大規模分布式系統的公司，Docker公司最近推出的內置編排功能可能會被這些公司視為自家編排產品的威脅，這些產品都幾乎基于Google的Kubernetes。

“目前發生的這件事情，如果處理不得當，會讓讓容器生態系統支零破碎，并導致單個的容器再無可能適配多種目標運行時環境。” 一位Hacker News上的觀察員指出。

_{Docker的話題仍然在StackOverflow中處于領先地位，但是 Kubernetes的勢頭正在上升。}

一個企業級的問題？

一個我們在Docker生態系統中反復聽到的問題是，Docker采取的激進發布安計劃時常讓第三方的系統提供者和他們的客戶發生不快。

“Docker不斷地破壞向后的兼容性”，RackN公司的CEO、Kubernetes社區的帶頭人 Rob Hirschfeld（兼TNS不定時的貢獻者）說。他此前并未參與此次分割相關討論中。RackN公司的應用程序生命周期管理平臺同時使用和提供了Docker組件，因此對后端的改動將會對其支持的客戶的業務造成影響。

“Docker將Docker Engine用作一個產品，而不是一個社區用來構建自有服務的組件”，Hirschfeld指責道。這種基于產品的策略意味著使用者被逼著在Docker發布新的革新特性或者合并新的組件（如Swarm）的時候去修復其破壞的向后兼容的問題。

“盡管我們會使用這些發布的特性，然而這些改動會帶來一系列與穩定性、版本、遷移和后端兼容相關的問題”。

在上周之前，對Docker的不滿議論主要都是私下的。但是現在這種議論進入到公共論壇。如谷歌Kubernetes布道師 Craig McLuckie 的推特博文：

_{推文 1：Docker公司必須要容許革新和獲利（它們已經做出了了不起的事情），但現在我們需要無聊的內核基礎設施。
推文 2：現在真的是容器運行時和格式的標準超越（現有）OCI的范圍出現的時候了。}

在Docker公司最近將Docker Swarm納入Docker1.12 后，長期壓抑的沮喪達到了頂點。有了Swarm后，Docker Engine能讓用戶使用熟悉的用來操作Docker的命令行結構和語法，無需借助額外的軟件即可管理復雜的容器應用。Docker的編排功能是可選的，他們必須由用戶激活 。然而選擇不啟用可能會在之后帶來向后向兼容性問題。

在此之前這些人們熟知編排功能只能通過第三方工具，如Google開源的Kubernetes，來提供。

盡管Google不直接銷售企業級容器編排軟件，但它的開源編排系統的的確確讓谷歌很快駛上了Google Cloud Platform容器服務的高速公路。其他公司，如CoreOS和Apprenda， 也提供Kubernetes的商業支持版本。華為也正在推出了基于Kubernetes的容器引擎（http://thenewstack.io/huawei-launches-kubernetes-based-container-engine/）。

因此，毫不奇怪，所有這些各方都希望將話題從容器轉移到容器編排上。

Bob Wise，一名三星SDS云工程師，作為該公司參與Kubernetes的主導人員，也曾同樣呼吁Docker放慢其容器創新的腳步。三星電子正在收購Joyent的過程中，該公司同樣提供了基于云的容器相關支持服務。

“如果你的團隊在深度使用Kubernetes、Mesos或Cloud Foundry，你需要一個穩定、簡單、無奇的容器實現方案，僅有最少的基本功能，由社區協商鏡像的創建、命名和發布”，Wise在上周的一篇博客中寫道。“你需要使用每個都人都在使用的一個相同的、簡單的、無奇的容器實現方案。作為一個社區，我們需要放緩對于基本構建組件的變更速度。唯有穩定性才能讓構建其上的系統蓬勃發展。”

_{推文：@countspongebob 來到了這個話題中，也想談點Docker穩定性的事情。到了fork的時候了嗎？}

同樣，Apcera技術產品經理 Phillip Tribble在個人博客（http://www.linux-toys.com/?p=684）中，以一種極具外交辭令的口吻，讓Docker不要再把其新推出的特性鼓吹成一個完工的企業級可用的產品。“讓互聯網或者大會充斥著營銷材料，宣揚各種令人振奮的新特性，但實際上卻不如所說那樣能用，不是一個明智的做法” ，Tribble寫道。

Apcera的商業模式一部分是基于提供Docker容器的支持上的。

Tribble的帖子引發了其他人在Hacker News上表達他們的Docker經歷（https://news.ycombinator.com/item?id=12364123），包括一些新版本帶來的讓人傷心的bug。一位讀者談到一天中啟動70,000到90,000個容器，約9%左右的會因為“各種Docker bug”遇到問題，這個比例最近的一次升級后下降到了4%。

但也有一些人在稱贊Docker的穩定性，“我們一直在生產中使用Docker約3年了，還沒有發現什么大的問題”，另一外讀者評論說，“它將一些很炫的Linux內核特性用簡潔的方式封裝了起來”。

事實上，Docker確實有大量的支持者認為Docker公司的軟件是穩定的。Docker工程師在吹捧公司技術實力雄厚方面自然也是比誰都快的。

不管什么情況，Docker似乎不會照顧它的潛在對手的心情而起意扼殺自己的革新的，就像最近一次在推ter上Google Kubernetes布道師 Kelsey Hightower 和Docker的CTO Solomon Hykes 關于OCI鏡像和運行時標準應該在基于Docker容器棧的標準化過程中扮演何種角色的爭執中所顯示的那樣。

OCI成立的要旨中提供的正是Wise等人呼吁的：無奇的、標準化的容器技術。

然而，Hykes提出OCI對第三方提供商有用性程度的質疑。Hykes指出，那些聲稱不需要Docker Daemon（假設通過runC運行時引擎） 也可以提供對Docker容器完全支持的提供商，事實上僅僅Docker提供了擁有Docker 90%特性的“偽支持”。

“我知道的情況是，Docker發展很快，因此那些聲稱‘支持Docker’的產品都是謊言”，Hykes寫到。而在另一篇推文中，Hykes甚至有些事態，屑稱OCI鏡像是“偽標準”。

_{推文：看看這些討論，告訴我憑什么Docker值得作為一個開放容器標準的管家？}

該問題因為Docker公司擁有Docker商標而進一步加劇。商標意味著當公司使用未經Docker社區許可的補丁、代碼或軟件包的時候時可能面臨法律責任。這種情況下，一個公司可能因為補丁尚未經過Docker公司許可，抑或尚未被合并到項目中，而無法為客戶客戶提供技術支持。

其結局：第三方供應商被迫忍受Docker公司任何對該開源項目作出的決定，在問題出現的時候等待Docker公司的補丁。最好的結果與Docker達成某種協議，保證提供穩定的發行版本。

_{推文：某一方的特性是另一方的累贅 > 容器運行時的fork（Docker的！）正在醞釀，因為生態系統需要一個穩定且輕型的構建塊。}

另外一個存在的問題是，哪些功能應該有Docker來實現，哪些功能應該由底層操作系統或者技術棧中的其他組件來負責處理。

另外一家使用Docke，但是也與Docker競爭，的公司是Red Hat。在今年的很多會議上，包括 LinuxCon North America 2016（http://thenewstack.io/tag/linuxcon-north-america-2016/），紅帽工程師 Dan Walsh 描述說紅帽成陷入了困境，一方面客戶越來越多的使用 systemd 來初始化Linux系統，而另一方面Docker似乎不愿使用systemd，取而代之使用Docker Daemon來提供初始化，服務激活，安全和容器日志的相關功能。

“在過去的三年里，我們一直試圖使systemd和Docker更好的整合，而我卻發現，兩個領導人都非常強烈的堅持己見”，Walsh說，兩個領導人指 Hykes和systemd的創造者，現Red Hat員工——Lennart Poettering（https://github.com/poettering）。

“所以，當機器的時候，誰來負責啟動系統服務，是systemd還是Docker？”Walsh問到。一個拙劣的系統實現可能會導致systemd和Docker互相沖突。

紅帽為自己的客戶維護著自己的Docker版本分支，包含著的補丁Docker有一天可能會合并，或者永遠不。

可選的方案

時間會告訴我們這些非正式言論是否會帶來更合作化的努力。有的方案是能滿足各方的。例如，可能會有一個通過OCI管理的、穩定Docker鏡像格式版本和運行時環境。這將使生態系統的參與者擁有穩定的組件，同時讓Docker繼續開發自己的Docker Engine。如果是這種情形，OCI運行時將是一個Docker的分支。

但如果生態系統內的這些公司想和Docker完全分割開來，那就意味一個完完整整的fork，使用不同的名稱，并需要一個新的小組來管理所有事宜。如CoreOS， 提供了另一種“無守護進程”的容器技術，叫rkt，然而它目前尚未得到市場足夠多的目光，至少沒法和Docker的成功相比。

這是一片新的領地，充分顯示出市場的快速成熟速度和利益博弈。從政治和經濟的觀點來探究容器生態系統，對于幫助理解社區的技術方向是比較重要的。特別是當你面對Docker和容器生態系統深深的裂痕，以及目前這場圍繞著是否需要創建一個Docker的分支的大討論的時候，這一點尤其適用。如果沒有其他可選方案，可能只有創建一個穩定的替代品作為標準內核，然后在其基礎上構建能保證終端用戶穩定的服務和產品。

 

 

 

來自：https://mp.weixin.qq.com/s?__biz=MzA5OTAyNzQ2OA==&mid=2649691570&idx=1&sn=7677ba9f5a78ca22048ddaf097dec12f&chksm=88932ad1bfe4a3c71d84d824b7126addf81f1f9dbdc61f1fc954166ed9dec7deabcd3a08c747&scene=1&srcid=09094NwidAputoCWsq87wOA3&pass_ticket=QAyEOTyTA7mvXeaX15nIJNIkphHqMn1Adf1YVA4zBGE%3D#rd