作者  |盧愛飛

近兩年Docker可謂充滿了爭議，例如去年底K8s宣布不打算支持Docker，消息一出，大家爭相討論Docker的可替代方案，Colima作為Docker Desktop的熱門開放替代方案，Podman作為Docker的替代方案，收到許多開發(fā)者和企業(yè)的關注。在今年Docker公司又宣布了Docker Desktop準備向中大型企業(yè)用戶收費，“再見Docker”的聲音再度高漲。

從各方面來看，無論從技術的領導力，還是盈利能力，Docker公司都已經開始掉隊，不禁要問，曾經風頭無二的容器化大佬究竟怎么了？

容器興起

把時間往回推幾年，大家提起Docker，都會把它與容器技術畫上等號，Docker引領容器技術變革的光榮歲月，依然讓人滿懷激動。在2013年，Cloud Foundry是云服務領域的絕對焦點，以Cloud Foundry為核心的PaaS平臺服務能力變革席卷了整個云服務領域，同時也涌現(xiàn)了一批優(yōu)秀的PaaS平臺，包括Salesforce Heroku、IBM Red Hat等。其中一家叫dotCloud的公司，也是這股 PaaS 熱潮中的一份子。但在當時的Cloud Foundry項目中，容器是最底層、最沒人關注的那一部分，因此dotCloud的產品一直無人問津。為改變這種被動的現(xiàn)狀，dotCloud公司決定開源自家的容器項目Docker。

就在短短的幾個月的時間里，Docker項目迅速崛起，很快就顛覆了Cloud Foundry定義的PaaS平臺的玩法。那相比于Cloud Foundry，Docker到底存在什么樣的決定性優(yōu)勢呢？

這要從Cloud Foundry的應用托管說起，Cloud Foundry最核心的組件就是一套應用的打包和分發(fā)機制。用戶只需要執(zhí)行一個命令，就能一鍵將應用發(fā)布到云端。為支持這樣的特性，Cloud Foundry實際上會為不同語言或框架發(fā)布不同的打包器(BuildPack)，然后把本地的可執(zhí)行應用打包，并上傳到Cloud Foundry，Cloud Foundry會調度合適的agent來下載應用，并完成部署。為保障agent上的服務相互隔離，Cloud Foundry會通過Cgroup和Namespace為應用提供隔離的“沙箱”運行環(huán)境。

Cloud Foundry 的首席產品經理在對比Cloud Foundry和Docker之后，也說過Docker并沒有什么黑科技，和Cloud Foundry一樣，也是依賴Cgroup和Namespace創(chuàng)建了“沙箱”運行環(huán)境而已。

那究竟Docker比Cloud Foundry強在哪呢？答案就在鏡像這種特別的應用打包方式。

典型的應用運行環(huán)境包括代碼、依賴和操作系統(tǒng)，Cloud Foundry可以保證代碼和依賴一致，但無法保障系統(tǒng)環(huán)境，所以有時本地運行正常，在云端卻不行，出了問題，也很難定位到系統(tǒng)環(huán)境的差異性。但Docker正好解決了這個痛點，通過Image構建出Rootfs，完美保障本地和云端運行環(huán)境的一致性。

在此基礎上，Docker還提供了友好的Docker CLI來創(chuàng)建Image，同時提供了Docker Hub來快速分發(fā)Image和同性交友。在Docker迅速取得成功之后，dotCloud公司也順勢改名為Docker，Docker公司儼然已經成為容器技術的代言人。

容器云之爭

單純解決應用打包并沒有價值，企業(yè)真正需要解決的是應用部署問題。Docker公司也意識到容器平臺化能力才是致勝關鍵。在2014年Docker公司很快發(fā)布了Swarm項目，依然保持著Docker的友好命令風格，幾個命令就可以完成多機集群部署。在此基礎上，不斷招兵買馬，例如收購了Fig項目(后改名為Compose)，以及專門負責容器網格的SocketPlane等，充實著自己的平臺化能力。此時Docker公司掌握著容器的絕對話語權，而Docker公司的平臺化戰(zhàn)略，又切實挑戰(zhàn)到了其它云服務平臺的切身利益，其中就包括Google和RedHat等公司。

為了改變Docker一家獨大的局面，由Docker、Google、RedHat等公司共同成立了OCI(Open Container Initiative)，旨在定義出鏡像和容器運行時標準，將標準從Docker項目實現(xiàn)中抽離出來。顯然，Docker公司不會花精力在這種削弱自己影響力的項目上，所以OCI規(guī)范一直進度緩慢。

但Google和RedHat沒有坐以待斃，隨后祭出了大殺器 --- Kubernetes，大家拉幫結伙，共同成立了CNCF基金會，以 Kubernetes 項目為基礎，建立一個由開源基礎設施領域廠商主導的、按照獨立基金會方式運營的平臺級社區(qū)，來對抗以 Docker 公司為核心的容器商業(yè)生態(tài)。Kubernetes憑借強大的設計和RedHat的優(yōu)秀社區(qū)運營，很快催生了一個與眾不同的容器編排與管理的生態(tài)，催生了Prometheus、Istio等一批優(yōu)秀的開源產品。為了應對Kubernetes帶來的挑戰(zhàn)，Docker公司主打的則是Docker Native的戰(zhàn)略，放棄現(xiàn)有的Swarm 項目，將容器編排和集群管理功能全部內置到 Docker 項目當中，這也為將來埋下了隱患 --- 尾大難掉。

即使這樣，Docker也無法與日益壯大的Kubernates社區(qū)相抗衡，最終以失敗收場，Docker公司將容器運行時runc項目捐贈給 CNCF 社區(qū)，將 Docker 項目改名為 Moby，交給社區(qū)自行維護，而 Docker 公司將占有 Docker 這個注冊商標，將Docker的客戶轉移到自己的手上，徹底地開始了自己的商業(yè)化運營。

Docker的困局

容器云之爭，最終以Docker公司的失敗收場，痛失云平臺高地之后，留給Docker公司的盈利點也不算太多：

• 軟件付費
• 私有Hub
• 容器云平臺
• 專業(yè)技術支持和培訓

容器云平臺的低占有率限制了收益，Docker公司為了保障盈利，宣布了Docker Hub、Docker Desktop收費的商業(yè)決策，頗有飲鴆止渴的感覺。從技術層面，Kubernates已經成為了容器編排的事實標準，而Container在整個版圖中，也只屬于最底層的部分。

OCI的規(guī)范已初見雛形，同類容器運行時containerd已經取代Docker，成為大多數(shù)托管 Kubernetes服務采用的容器運行時。再談Docker Hub，基本上成熟的云平臺都有發(fā)布自己的Container Registry，例如Amazon Elastic Container Registry (ECR)等，私有Hub的收費方式還很脆弱。

由于設計理念的不同，Docker添加了許多組件來保障友好的用戶體驗，這是Kubernates不需要的，此外它不支持Kubernates的CRI規(guī)范，從下圖可以看到，社區(qū)需要維護一個Docker Shim項目來橋接Kubernates Node和Docker。一開始Kubernetes為了接入Docker生態(tài)，自然愿意維護這一套項目，但隨著OCI、CRI規(guī)范和產品的成熟，社區(qū)便失去繼續(xù)維護該項目的動力。

(圖片來源：Kubernetes is Removing Docker Support, Kubernetes is Not Removing Docker Support)

痛失容器編排陣地，容器標準的話語權被逐漸削弱，再加上飲鴆止渴般的收費商業(yè)模式，僅憑借優(yōu)秀的用戶體驗，Docker真的能留住大家嗎？不禁讓人想問，廉頗老矣，尚能飯否？