Docker并不是唯一的容器化工具，可能還有更好的選擇……

在容器的早期時(shí)代(其實(shí)更像是4年前)，Docker是容器游戲中唯一的玩家。但現(xiàn)在情況已經(jīng)不一樣了，Docker不再是唯一的一個(gè)，而只是其中一個(gè)容器引擎而已。Docker允許我們構(gòu)建、運(yùn)行、拉、推或檢查容器鏡像，然而對(duì)于每一項(xiàng)任務(wù)，都有其他的替代工具，甚至可能比Docker做得還要好。所以，讓我們探索一下，然后再卸載(只是可能)，直至完全忘記Docker……

那，為什么不再用Docker了?

如果你已經(jīng)使用Docker很長(zhǎng)時(shí)間了，估計(jì)要真正說(shuō)服你去考慮其他工具，得先提供些依據(jù)。

首先，Docker是一個(gè)單體工具。它嘗試去涵蓋所有的功能，通常這并不是最佳實(shí)踐。大多數(shù)情況下，我們都是只選擇一種專(zhuān)門(mén)的工具，它只做一件事，并且做得非常好，非常精。

如果害怕切換到不同的工具集是因?yàn)閷⒉坏貌粚W(xué)習(xí)使用不同的CLI、API或者說(shuō)不同的概念，那么這不會(huì)是一個(gè)問(wèn)題。本文中展示的任何工具都可以是完全無(wú)縫的，因?yàn)樗鼈?包括Docker)都遵循OCI (Open Container Initiative)下的相同規(guī)范。它們包含了容器運(yùn)行時(shí)、容器分發(fā)和容器鏡像的規(guī)范，其中涵蓋了使用容器所需的所有特性。

有了OCI，你可以選擇一套最符合你需求的工具，同時(shí)你仍然可以享受跟Docker一樣使用相同的API和CLI命令。

所以，如果你愿意嘗試新的工具，那么讓我們比較一下Docker和它的競(jìng)爭(zhēng)對(duì)手的優(yōu)缺點(diǎn)和特性，看看是否有必要考慮放棄Docker，使用一些新的閃亮的工具。

容器引擎

在比較Docker和其他工具時(shí)，我們需要將其分解為組件，首先我們先討論一下容器引擎。Container Engine是一種工具，它為處理鏡像和容器提供用戶(hù)界面，這樣就不必處理SECCOMP規(guī)則或SELinux策略之類(lèi)的事情。它的工作還包括從遠(yuǎn)程倉(cāng)庫(kù)提取鏡像并將其擴(kuò)展到磁盤(pán)。它看起來(lái)也是運(yùn)行容器，但實(shí)際上它的工作是創(chuàng)建容器清單和帶有鏡像層的目錄。然后它將它們傳遞到容器運(yùn)行時(shí)，如runC或Crun(稍后我們將討論這一點(diǎn))。

目前已經(jīng)有許多容器引擎，但Docker最突出的競(jìng)爭(zhēng)對(duì)手是由紅帽開(kāi)發(fā)的Podman。與Docker不同，Podman不需要Daemon來(lái)運(yùn)行，也不需要root特權(quán)，這是Docker長(zhǎng)期以來(lái)一直關(guān)注的問(wèn)題。基于它的名字，Podman不僅可以運(yùn)行容器，還可以運(yùn)行pods。如果你不熟悉pods的概念，其實(shí)，簡(jiǎn)單的概括就是，Pod是Kubernetes的最小計(jì)算單元。它由一個(gè)或多個(gè)容器(主容器和執(zhí)行支持任務(wù)的Sidecar)組成，這使得Podman用戶(hù)以后更容易將他們的工作負(fù)載遷移到Kubernetes。因此，作為一個(gè)簡(jiǎn)單的演示，這是如何在一個(gè)Pod中運(yùn)行兩個(gè)容器：

~ $ podman pod create --name mypod 
~ $ podman pod list 
 
 
POD ID         NAME    STATUS    CREATED         # OF CONTAINERS   INFRA ID 
211eaecd307b   mypod   Running   2 minutes ago   1                 a901868616a5 
 
 
~ $ podman run -d --pod mypod nginx  # First container 
~ $ podman run -d --pod mypod nginx  # Second container 
~ $ podman ps -a --pod 
 
 
CONTAINER ID  IMAGE                           COMMAND               CREATED        STATUS            PORTS  NAMES               POD           POD NAME 
3b27d9eaa35c  docker.io/library/nginx:latest  nginx -g daemon o...  2 seconds ago  Up 1 second ago          brave_ritchie       211eaecd307b  mypod 
d638ac011412  docker.io/library/nginx:latest  nginx -g daemon o...  5 minutes ago  Up 5 minutes ago         cool_albattani      211eaecd307b  mypod 
a901868616a5  k8s.gcr.io/pause:3.2                                  6 minutes ago  Up 5 

最后，Podman提供了與Docker完全相同的CLI命令，因此只需執(zhí)行alias docker = podman并裝作什么都沒(méi)有改變。

除了Docker和Podman之外，還有其他的容器引擎，但我個(gè)人認(rèn)為它們都是沒(méi)什么出路的技術(shù)，或者都不太適合本地開(kāi)發(fā)和使用。但是，要全面了解，至少要看一下其中的內(nèi)容：

• LXD——LXC (Linux Containers)是一個(gè)容器管理器(守護(hù)進(jìn)程)。該工具提供了運(yùn)行系統(tǒng)容器的能力，這些系統(tǒng)容器提供了更類(lèi)似于VM的容器環(huán)境。它位于非常狹窄的空間，沒(méi)什么用戶(hù)，所以除非你有非常具體的實(shí)例，否則最好還是使用Docker或Podman。
• CRI-O——當(dāng)你Google什么是CRI-O你可能會(huì)發(fā)現(xiàn)它被描述為容器引擎。不過(guò)，實(shí)際上它只是容器運(yùn)行時(shí)。其實(shí)它既不是引擎，也不適合“正常”使用。我的意思是，它是專(zhuān)門(mén)為Kubernetes運(yùn)行時(shí)(CRI)而構(gòu)建的，而不是為最終用戶(hù)使用的。
• Rkt——rkt(“火箭”)是由CoreOS開(kāi)發(fā)的容器引擎。這里提到這個(gè)項(xiàng)目只是為了完整性，因?yàn)檫@個(gè)項(xiàng)目已經(jīng)結(jié)束，開(kāi)發(fā)也停止了——所以也就沒(méi)必要再使用了。

構(gòu)建鏡像

對(duì)于容器引擎來(lái)說(shuō)，一般都只選擇Docker。但是，當(dāng)涉及到構(gòu)建鏡像時(shí)，選擇的余地還是比較多的。

首先，介紹一下Buildah。Buildah是紅帽開(kāi)發(fā)的另一個(gè)工具，它與Podman配合使用相當(dāng)合適。如果已經(jīng)安裝了Podman，你可能會(huì)注意到podman build子命令，它實(shí)際上只是偽裝的Buildah，因?yàn)樗亩M(jìn)制文件已經(jīng)包含在Podman里。

至于它的特性，它遵循了與Podman相同的路線——無(wú)守護(hù)程序和無(wú)根的，并遵循OCI的鏡像標(biāo)準(zhǔn)，所以它能保證所構(gòu)建的鏡像和Docker構(gòu)建的是一樣的。它還能夠從Dockerfile或更恰當(dāng)?shù)拿鸆ontainerfile來(lái)構(gòu)建鏡像，Dockerfile和Containerfile都是相同的，只是命名的區(qū)別。除此之外，Buildah還對(duì)鏡像層提供了更精細(xì)的控制，允許在單層中提交更多變更。唯一的例外是(在我看來(lái))與Docker的區(qū)別是，由Buildah構(gòu)建的鏡像是基于用戶(hù)的，因此用戶(hù)可以只列出自己構(gòu)建的鏡像。

那么，考慮到Buildah已經(jīng)包含在Podman CLI中，大家可能會(huì)問(wèn)，為什么還要使用單獨(dú)的Buildah CLI?Buildah CLI是podman build中包含的命令的超集，所以基本不需要單獨(dú)接觸Buildah CLI，但是通過(guò)使用它，你可能還會(huì)發(fā)現(xiàn)一些額外有用的特性(有關(guān)podman build和buildah之間的差異的細(xì)節(jié)，請(qǐng)參閱這個(gè)文章)。

現(xiàn)在，我們來(lái)看看一個(gè)演示：

~ $ buildah bud -f Dockerfile . 
 
~ $ buildah from alpine:latest  # Create starting container - equivalent to "FROM alpine:latest" 
Getting image source signatures 
Copying blob df20fa9351a1 done   
Copying config a24bb40132 done   
Writing manifest to image destination 
Storing signatures 
alpine-working-container  # Name of the temporary container 
~ $ buildah run alpine-working-container -- apk add --update --no-cache python3  # equivalent to "RUN apk add --update --no-cache python3" 
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz 
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/community/x86_64/APKINDEX.tar.gz 
... 
 
~ $ buildah commit alpine-working-container my-final-image  # Create final image 
Getting image source signatures 
Copying blob 50644c29ef5a skipped: already exists   
Copying blob 362b9ae56246 done   
Copying config 1ff90ec2e2 done   
Writing manifest to image destination 
Storing signatures 
1ff90ec2e26e7c0a6b45b2c62901956d0eda138fa6093d8cbb29a88f6b95124c 
 
~ # buildah images 
REPOSITORY               TAG     IMAGE ID      CREATED         SIZE 
localhost/my-final-image latest  1ff90ec2e26e  22 seconds ago  51.4 MB 

從上面的腳本可以看到，我們可以只用buildah bud構(gòu)建鏡像，bud代表使用Dockerfile構(gòu)建，但是你還可以使用更多Buildahs的腳本：from，run和copy，這些命令對(duì)應(yīng)命令Dockerfile的(FROM image，RUN…，COPY…)。

下一個(gè)是谷歌的Kaniko。Kaniko也是從Dockerfile構(gòu)建容器鏡像，跟Buildah類(lèi)似，也不需要守護(hù)進(jìn)程。與Buildah的主要區(qū)別在于，Kaniko更專(zhuān)注于在Kubernetes中構(gòu)建鏡像。

Kaniko使用gcr.io/ Kaniko -project/executor作為鏡像運(yùn)行。這對(duì)于Kubernetes來(lái)說(shuō)是行得通的，但是對(duì)于本地構(gòu)建來(lái)說(shuō)不是很方便，并且在某種程度上違背了它的初衷，因?yàn)槲覀兊孟仁褂肈ocker來(lái)運(yùn)行Kaniko鏡像，然后再去構(gòu)建鏡像。也就是說(shuō)，如果正在為Kubernetes集群中構(gòu)建鏡像的工具進(jìn)行選型(例如在CI/CD Pipeline中)，那么Kaniko可能是一個(gè)不錯(cuò)的選擇，因?yàn)樗菬o(wú)守護(hù)程序的，而且(可能)更安全。

從我個(gè)人的經(jīng)驗(yàn)來(lái)看——我在Kubernetes/OpenShift集群中使用了Kaniko和Buildah來(lái)構(gòu)建鏡像，我認(rèn)為兩者都能很好地完成任務(wù)，但在使用Kaniko時(shí)，我看到了一些將鏡像導(dǎo)入倉(cāng)庫(kù)時(shí)的，會(huì)有隨機(jī)構(gòu)建崩潰和失敗的情況。

第三個(gè)競(jìng)爭(zhēng)者是Buildkit，也可以稱(chēng)為下一代的Docker build。它是Moby項(xiàng)目的一部分。在Docker里可以使用DOCKER_BUILDKIT=1 Docker build…作為實(shí)驗(yàn)特性進(jìn)行啟用。那么，它的核心價(jià)值到底有哪些?它引入了許多改進(jìn)和炫酷的特性，包括并行構(gòu)建、跳過(guò)未使用的階段、更好的增量構(gòu)建和無(wú)根構(gòu)建。然而另一方面，它仍然需要運(yùn)行守護(hù)進(jìn)程(buildkitd)才能運(yùn)行。所以，如果你不想擺脫Docker，但是想要一些新的特性和更好的改進(jìn)，那么使用Buildkit可能是最好的選擇。

和前面一樣，這里我們也還有一些“光鮮亮麗的產(chǎn)品”，它們也都有非常具體的場(chǎng)景，雖然并不是我們的首選：

• Source-To-Image(S2I)是一個(gè)不需要Dockerfile直接從源代碼構(gòu)建鏡像的工具包。這個(gè)工具在簡(jiǎn)單的、預(yù)期的場(chǎng)景和工作流中運(yùn)行的很好，但是如果有太多的定制，或者該項(xiàng)目沒(méi)有預(yù)期的布局，你很快就會(huì)覺(jué)得這個(gè)工具很煩人和笨拙。如果你對(duì)Docker還不是很有信心，或者如果在OpenShift集群上構(gòu)建鏡像，那么你可以嘗試考慮一下使用S2I，因?yàn)槭褂肧2I構(gòu)建是一個(gè)內(nèi)置特性。
• Jib是谷歌的另一個(gè)工具，專(zhuān)門(mén)用于構(gòu)建Java鏡像。它包括Maven和Gradle插件，可以輕松地構(gòu)建鏡像，而不會(huì)干擾Dockerfile。
• 最后一個(gè)但并不是不重要的是Bazel，它是谷歌的另一款工具。它不僅用于構(gòu)建容器鏡像，而且是一個(gè)完整的構(gòu)建系統(tǒng)。如果你只是想構(gòu)建一個(gè)鏡像，那么鉆研Bazel可能有點(diǎn)過(guò)頭，但絕對(duì)是一個(gè)很好的學(xué)習(xí)體驗(yàn)，所以如果你想嘗試，rules_docker絕對(duì)是一個(gè)很好的起點(diǎn)。

容器運(yùn)行時(shí)

最后一個(gè)大塊兒是容器運(yùn)行時(shí)，它負(fù)責(zé)運(yùn)行容器。容器運(yùn)行時(shí)是整個(gè)容器生命周期/棧的一部分，除非你對(duì)速度、安全性等有一些非常具體的要求，否則一般是不需要對(duì)其進(jìn)行干擾。所以，如果讀者看到這里已經(jīng)厭倦，那么可以跳過(guò)這一部分。如果不是，那么有關(guān)容器運(yùn)行時(shí)的選擇，如下：

runC是基于OCI容器運(yùn)行時(shí)規(guī)范創(chuàng)建的，且最流行的容器運(yùn)行時(shí)。Docker(通過(guò)containerd)、Podman和crio使用它，所以幾乎所有東西都依賴(lài)于LXD。它幾乎是所有產(chǎn)品/工具的默認(rèn)首選項(xiàng)，所以即使你在閱讀本文后放棄Docker，但你仍然會(huì)用到runC。

runC的另一款替代方產(chǎn)品為Crun，名稱(chēng)類(lèi)似(容易混淆)。這是Red Hat開(kāi)發(fā)的工具，完全用C編寫(xiě)(runC是用Go編寫(xiě)的)。這使得它比runC更快，內(nèi)存效率更高?？紤]到它也是OCI兼容的運(yùn)行時(shí)。所以，如果你想做個(gè)測(cè)試，切換起來(lái)很容易。盡管它現(xiàn)在還不是很流行，但在RHEL 8.3技術(shù)預(yù)覽版中，它將作為一個(gè)替代OCI運(yùn)行時(shí)，同時(shí)，考慮到它是紅帽的產(chǎn)品，我們可能最終會(huì)看到它會(huì)成為Podman或CRI-O的默認(rèn)首選項(xiàng)。

說(shuō)到CRI-O。前面我說(shuō)過(guò)，CRI-O實(shí)際上不是一個(gè)容器引擎，而是容器運(yùn)行時(shí)。這是因?yàn)镃RI-O不包括比如推送鏡像這樣的特性，而這正是容器引擎的特性。作為運(yùn)行時(shí)的CRI-O在內(nèi)部使用runC運(yùn)行容器。通常情況下不需要在單機(jī)嘗試這個(gè)工具，因?yàn)樗粯?gòu)建為用于Kubernetes節(jié)點(diǎn)上的運(yùn)行時(shí)，可以看到它被描述為“Kubernetes需要的所有運(yùn)行時(shí)，僅此而已”。因此，除非你正在設(shè)置Kubernetes集群(或OpenShift集群——CRI-O已經(jīng)是默認(rèn)首選項(xiàng)了)，否則不大可能會(huì)接觸到這個(gè)。

本節(jié)的最后一個(gè)內(nèi)容是containerd，它是CNCF的一個(gè)畢業(yè)的項(xiàng)目。它是一個(gè)守護(hù)進(jìn)程，充當(dāng)各種容器運(yùn)行時(shí)和操作系統(tǒng)的API。在后臺(tái)，它依賴(lài)于runC，是Docker引擎的默認(rèn)運(yùn)行時(shí)。谷歌Kubernetes引擎(GKE)和IBM Kubernetes服務(wù)(IKS)也在使用。它是Kubernetes容器運(yùn)行時(shí)接口的一個(gè)部署(與CRI-O相同)，因此它是Kubernetes集群運(yùn)行時(shí)的一個(gè)很好的備選項(xiàng)。

鏡像檢測(cè)與分發(fā)

容器棧的最后一部分是鏡像的檢測(cè)與分發(fā)。這有效地替代了docker inspect，還(可選地)增加了遠(yuǎn)程鏡像倉(cāng)庫(kù)之間復(fù)制/映射鏡像的能力。

這里唯一要提到的可以完成這些任務(wù)的工具是Skopeo。它由紅帽公司開(kāi)發(fā)，是Buildah，Podman和CRI-O的配套工具。除了我們都從Docker中知道的基本的skopeo inspect之外，Skopeo還能夠使用skopeo copy復(fù)制鏡像，它允許你在遠(yuǎn)程鏡像倉(cāng)庫(kù)之間映射鏡像，而無(wú)需先將它們拉到本地倉(cāng)庫(kù)。如果你使用本地倉(cāng)庫(kù)，此功能也可以作為pull/push。

另外，我還想提一下Dive，這是一個(gè)檢查、探測(cè)和分析鏡像的工具。它對(duì)用戶(hù)更友好一些，提供了更可讀的輸出，可以更深入地探測(cè)鏡像，并分析和衡量其效率。它也適合在CI管道中使用，它可以測(cè)量你的鏡像是否“足夠高效”，或者換句話說(shuō)——它是否浪費(fèi)了太多空間。

結(jié)論

本文的目的并不是要說(shuō)服大家完全拋棄Docker，而是向大家展示構(gòu)建、運(yùn)行、管理和分發(fā)容器及其鏡像的整個(gè)場(chǎng)景和所有選項(xiàng)。包括Docker在內(nèi)的每一種工具都有其優(yōu)缺點(diǎn)，評(píng)估哪一組工具最適合你的工作流和場(chǎng)景才是最重要的，真心希望本文能在這方面幫助到你。