文章轉(zhuǎn)自：分布式實(shí)驗(yàn)室

原文鏈接：https://towardsdatascience.com/its-time-to-say-goodbye-to-docker-5cfec8eff833

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ì)要真正說服你去考慮其他工具，得先提供些依據(jù)。

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

如果害怕切換到不同的工具集是因?yàn)閷⒉坏貌粚W(xué)習(xí)使用不同的CLI、API或者說不同的概念，那么這不會(huì)是一個(gè)問題。本文中展示的任何工具都可以是完全無縫的，因?yàn)樗鼈儯ò―ocker）都遵循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是一種工具，它為處理鏡像和容器提供用戶界面，這樣就不必處理SECCOMP規(guī)則或SELinux策略之類的事情。它的工作還包括從遠(yuǎn)程倉庫提取鏡像并將其擴(kuò)展到磁盤。它看起來也是運(yùn)行容器，但實(shí)際上它的工作是創(chuàng)建容器清單和帶有鏡像層的目錄。然后它將它們傳遞到容器運(yùn)行時(shí)，如runC或Crun（稍后我們將討論這一點(diǎn)）。

目前已經(jīng)有許多容器引擎，但Docker最突出的競(jìng)爭(zhēng)對(duì)手是由紅帽開發(fā)的Podman。與Docker不同，Podman不需要Daemon來運(yùn)行，也不需要root特權(quán)，這是Docker長(zhǎng)期以來一直關(guān)注的問題?；谒拿郑琍odman不僅可以運(yùn)行容器，還可以運(yùn)行pods。如果你不熟悉pods的概念，其實(shí)，簡(jiǎn)單的概括就是，Pod是Kubernetes的最小計(jì)算單元。它由一個(gè)或多個(gè)容器（主容器和執(zhí)行支持任務(wù)的Sidecar）組成，這使得Podman用戶以后更容易將他們的工作負(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 minutes ago         211eaecd307b-infra  211eaecd307b  mypod 

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

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

• LXD——LXC （Linux Containers）是一個(gè)容器管理器（守護(hù)進(jìn)程）。該工具提供了運(yùn)行系統(tǒng)容器的能力，這些系統(tǒng)容器提供了更類似于VM的容器環(huán)境。它位于非常狹窄的空間，沒什么用戶，所以除非你有非常具體的實(shí)例，否則最好還是使用Docker或Podman。

• CRI-O——當(dāng)你Google什么是CRI-O你可能會(huì)發(fā)現(xiàn)它被描述為容器引擎。不過，實(shí)際上它只是容器運(yùn)行時(shí)。其實(shí)它既不是引擎，也不適合“正常”使用。我的意思是，它是專門為Kubernetes運(yùn)行時(shí)（CRI）而構(gòu)建的，而不是為最終用戶使用的。

• Rkt——rkt（“Rocket”）是由CoreOS開發(fā)的容器引擎。這里提到這個(gè)項(xiàng)目只是為了完整性，因?yàn)檫@個(gè)項(xiàng)目已經(jīng)結(jié)束，開發(fā)也停止了——所以也就沒必要再使用了。

構(gòu)建鏡像

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

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

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

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

現(xiàn)在，我們來看看一個(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類似，也不需要守護(hù)進(jìn)程。與Buildah的主要區(qū)別在于，Kaniko更專注于在Kubernetes中構(gòu)建鏡像。

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

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

第三個(gè)競(jìng)爭(zhēng)者是Buildkit，也可以稱為下一代的Docker build。它是Moby項(xiàng)目的一部分。在Docker里可以使用DOCKER_BUILDKIT=1 Docker build…作為實(shí)驗(yàn)特性進(jìn)行啟用。那么，它的核心價(jià)值到底有哪些？它引入了許多改進(jìn)和炫酷的特性，包括并行構(gòu)建、跳過未使用的階段、更好的增量構(gòu)建和無根構(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)目沒有預(yù)期的布局，你很快就會(huì)覺得這個(gè)工具很煩人和笨拙。如果你對(duì)Docker還不是很有信心，或者如果在OpenShift集群上構(gòu)建鏡像，那么你可以嘗試考慮一下使用S2I，因?yàn)槭褂肧2I構(gòu)建是一個(gè)內(nèi)置特性。

• Jib是谷歌的另一個(gè)工具，專門用于構(gòu)建Java鏡像。它包括Maven和Gradle插件，可以輕松地構(gòu)建鏡像，而不會(huì)干擾Dockerfile。

• 最后一個(gè)但并不是不重要的是Bazel，它是谷歌的另一款工具。它不僅用于構(gòu)建容器鏡像，而且是一個(gè)完整的構(gòu)建系統(tǒng)。如果你只是想構(gòu)建一個(gè)鏡像，那么鉆研Bazel可能有點(diǎn)過頭，但絕對(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ān)容器運(yùn)行時(shí)的選擇，如下：

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

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

說到CRI-O。前面我說過，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)，它依賴于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)程鏡像倉庫之間復(fù)制/映射鏡像的能力。

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

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

結(jié)論

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