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

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

那，為什么不再用Docker了?

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

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

如果害怕切換到不同的工具集是因為將不得不學(xué)習(xí)使用不同的CLI、API或者說不同的概念，那么這不會是一個問題。本文中展示的任何工具都可以是完全無縫的，因為它們(包括Docker)都遵循OCI (Open Container Initiative)下的相同規(guī)范。它們包含了容器運行時、容器分發(fā)和容器鏡像的規(guī)范，其中涵蓋了使用容器所需的所有特性。

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

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

容器引擎

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

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

~ $ 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并裝作什么都沒有改變。

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

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

構(gòu)建鏡像

對于容器引擎來說，一般都只選擇Docker。但是，當涉及到構(gòu)建鏡像時，選擇的余地還是比較多的。

首先，介紹一下Buildah。Buildah是紅帽開發(fā)的另一個工具，它與Podman配合使用相當合適。如果已經(jīng)安裝了Podman，你可能會注意到podman build子命令，它實際上只是偽裝的Buildah，因為它的二進制文件已經(jīng)包含在Podman里。

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

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

現(xiàn)在，我們來看看一個演示：

~ $ 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，這些命令對應(yīng)命令Dockerfile的(FROM image，RUN…，COPY…)。

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

Kaniko使用gcr.io/ Kaniko -project/executor作為鏡像運行。這對于Kubernetes來說是行得通的，但是對于本地構(gòu)建來說不是很方便，并且在某種程度上違背了它的初衷，因為我們得先使用Docker來運行Kaniko鏡像，然后再去構(gòu)建鏡像。也就是說，如果正在為Kubernetes集群中構(gòu)建鏡像的工具進行選型(例如在CI/CD Pipeline中)，那么Kaniko可能是一個不錯的選擇，因為它是無守護程序的，而且(可能)更安全。

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

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

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

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

容器運行時

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

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

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

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

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

鏡像檢測與分發(fā)

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

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

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

結(jié)論

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