容器江湖的愛恨情仇

作者： Thoughtworks洞見 2022-05-13 09:47:28

從各方面來看，無論從技術(shù)的領(lǐng)導(dǎo)力，還是盈利能力，Docker公司都已經(jīng)開始掉隊(duì)，不禁要問，曾經(jīng)風(fēng)頭無二的容器化大佬究竟怎么了？

作者 |盧愛飛

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

容器興起

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

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

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

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

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

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

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

容器云之爭(zhēng)

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

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

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

即使這樣，Docker也無法與日益壯大的Kubernates社區(qū)相抗衡，最終以失敗收?qǐng)觯珼ocker公司將容器運(yùn)行時(shí)runc項(xiàng)目捐贈(zèng)給 CNCF 社區(qū)，將 Docker 項(xiàng)目改名為 Moby，交給社區(qū)自行維護(hù)，而 Docker 公司將占有 Docker 這個(gè)注冊(cè)商標(biāo)，將Docker的客戶轉(zhuǎn)移到自己的手上，徹底地開始了自己的商業(yè)化運(yùn)營。

Docker的困局

容器云之爭(zhēng)，最終以Docker公司的失敗收?qǐng)觯词г破脚_(tái)高地之后，留給Docker公司的盈利點(diǎn)也不算太多：

軟件付費(fèi)
私有Hub
容器云平臺(tái)
專業(yè)技術(shù)支持和培訓(xùn)

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

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

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