Docker不再是唯一的選擇

時間：2021-01-25 16:42:43

關(guān)鍵字： Docker 容器化

手機看文章

掃描二維碼
隨時隨地手機看文章

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

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

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

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

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

那，為什么不再用Docker了？

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

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

如果害怕切換到不同的工具集是因為將不得不學習使用不同的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í)行支持任務的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 minutes ago         211eaecd307b-infra  211eaecd307b  mypod

最后，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（“Rocket”）是由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é)，請參閱這個文章[1]）。

現(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，這些命令對應命令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)建鏡像，我認為兩者都能很好地完成任務，但在使用Kaniko時，我看到了一些將鏡像導入倉庫時的，會有隨機構(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)建鏡像的工具包。這個工具在簡單的、預期的場景和工作流中運行的很好，但是如果有太多的定制，或者該項目沒有預期的布局，你很快就會覺得這個工具很煩人和笨拙。如果你對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可能有點過頭，但絕對是一個很好的學習體驗，所以如果你想嘗試，rules_docker絕對是一個很好的起點。

容器運行時

最后一個大塊兒是容器運行時，它負責運行容器。容器運行時是整個容器生命周期/棧的一部分，除非你對速度、安全性等有一些非常具體的要求，否則一般是不需要對其進行干擾。所以，如果讀者看到這里已經(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ù)預覽版中，它將作為一個替代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服務（IKS）也在使用。它是Kubernetes容器運行時接口的一個部署（與CRI-O相同），因此它是Kubernetes集群運行時的一個很好的備選項。

鏡像檢測與分發(fā)

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

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

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