所謂三十年河?xùn)|，三十年河西，曾經(jīng)在容器領(lǐng)域叱咤風(fēng)云的 Docker 如今已風(fēng)光不再。拋開情懷，我們不得不承認(rèn)，Docker 已經(jīng)被后浪拍死在沙灘上了……

大約 4 年前的容器領(lǐng)域，Docker 是唯一的選擇。

然而，如今情況已然大不同，Docker 不再是是唯一的選擇，它只不過是一個(gè)容器引擎而已。我們可以用 Docker 構(gòu)建、運(yùn)行、拉取、推送或檢查容器鏡像，但是這里的每一項(xiàng)任務(wù)，都可以用其他工具替代，甚至有些工具比 Docker 還好。

所以，下面就讓我們來探索一下這個(gè)領(lǐng)域，然后卸載和忘記 Docker 吧。

為什么說不要用 Docker 了？

如果長(zhǎng)期以來你一直在使用 Docker，那么說服你考慮其他工具可能需要多費(fèi)點(diǎn)唇舌。

首先，Docker 是一個(gè)整體化的工具，它試圖做好所有的事情，但往往只會(huì)適得其反。在大多數(shù)情況下，我們應(yīng)該選擇專門的工具，它可能只做一件事情，但會(huì)做到最好。

可能你因?yàn)閾?dān)心需要學(xué)習(xí)使用不同的 CLI、不同的 API 或接受不同的概念，所以會(huì)害怕使用其他工具。但是，請(qǐng)不用擔(dān)心。本文介紹的任何工具都可以完美地?zé)o縫銜接，因?yàn)樗鼈儯ò?Docker）都遵循同一個(gè) OCI（OpenContainer Initiative，開放容器計(jì)劃）規(guī)范。OCI 包括容器運(yùn)行時(shí)、容器分發(fā)和容器鏡像的規(guī)范，涵蓋了使用容器所需的所有功能。

因?yàn)橛辛?OCI，所以你可以自由選擇適合自己的需求的工具，與此同時(shí)，你可以繼續(xù)使用與 Docker 相同的 API 和 CLI 命令。

因此，如果你愿意嘗試新工具，那么我們就來比較一下 Docker 與其競(jìng)爭(zhēng)對(duì)手的優(yōu)缺點(diǎn)和功能，看看是否有必要考慮放棄 Docker，并嘗試使用一些新鮮出爐的工具。

容器引擎

在比較 Docker 與其他工具時(shí)，我們需要分別討論它的各個(gè)組件，首先要討論的就是容器引擎。

容器引擎是一種工具，它提供了處理鏡像與容器的用戶界面，這樣你就不需要與 SECCOMP 規(guī)則或 SELinux 策略苦苦糾纏了。除此之外，容器引擎還可以從遠(yuǎn)程倉(cāng)庫(kù)提取鏡像，并將其解壓到本地磁盤上。它似乎也運(yùn)行容器，但是實(shí)際上，它的工作是創(chuàng)建容器清單以及鏡像層的目錄。接著，它將這些文件傳遞給 runc 或 crun 等容器運(yùn)行時(shí)。

目前有很多容器引擎可供我們使用，不過 Docker 最主要的競(jìng)爭(zhēng)對(duì)手是紅帽開發(fā)的 Podman。與 Docker 不同，Podman 不需要運(yùn)行守護(hù)進(jìn)程，也不需要 root 特權(quán)，這些都是 Docker 長(zhǎng)期以來一直倍受關(guān)注的問題。從名字就可以看出來，Podman 不僅可以運(yùn)行容器，還可以運(yùn)行 pod。

如果你不熟悉 pod 的話，我可以簡(jiǎn)單介紹一下：pod 是 Kubernetes 的最小計(jì)算單元，由一個(gè)或多個(gè)容器 (主容器與負(fù)責(zé)支持主容器的 sidercar 容器) 組成。因此，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?minutesago??Up?5?minutes?ago?????????cool_albattani??????211eaecd307b?mypod
a901868616a5?k8s.gcr.io/pause:3.2??????????????????????????????????6?minutesago??Up?5?minutes?ago?????????211eaecd307b-infra??211eaecd307b?mypod

最后一點(diǎn)，Podman 提供的 CLI 命令與 Docker 完全相同，因此你只需執(zhí)行

alias?docker=podman

然后就像什么都沒有發(fā)生過一樣。

除了 Docker 和 Podman 之外，還有其他容器引擎，但我并不看好它們的發(fā)展，或者不適合用于本地開發(fā)。

不過，如果你想對(duì)容器引擎有一個(gè)較為完整的了解，我也可以介紹一些：

LXD：LXD 是 LXC（Linux 容器）的容器管理器（守護(hù)進(jìn)序）。這個(gè)工具提供了運(yùn)行系統(tǒng)容器的能力，而這些系統(tǒng)容器提供了類似于虛擬機(jī)的容器環(huán)境。該工具比較小眾，沒有太多用戶，所以除非你有非常特殊的用例，否則最好還是使用 Docker 或 Podman。

CRI-O：如果在網(wǎng)上搜索 cri-o 是什么，你可能會(huì)發(fā)現(xiàn)它被描述成了一種容器引擎。但實(shí)際上，它是一種容器運(yùn)行時(shí)。它既不是容器引擎，也不適合“常規(guī)”使用。我的意思是說，它是專門作為 Kubernetes 運(yùn)行時(shí)（CRI）而創(chuàng)建的，并不是給最終用戶使用的。

rkt：rkt（讀作“rocket”）是 CoreOS 開發(fā)的容器引擎。這里提到這個(gè)項(xiàng)目只是為了清單的完整性，因?yàn)檫@個(gè)項(xiàng)目已經(jīng)結(jié)束了，它的開發(fā)也停止了，因此你不應(yīng)該再使用它。

構(gòu)建鏡像

對(duì)于容器引擎，實(shí)際上 Docker 的替代品只有一種選擇（即 Podman）。但是，在構(gòu)建鏡像方面，我們有很多選擇。

首先，我們來看一看 Buildah。這也是一款紅帽開發(fā)的工具，可以很好地與 Podman 協(xié)同工作。如果你已經(jīng)安裝了 Podman，可能會(huì)注意到 podman build 子命令，因?yàn)樗亩M(jìn)制文件已經(jīng)包含在 Podman 中了，實(shí)際上這個(gè)命令只是經(jīng)過包裝的 Buildah。

至于功能，Buildah 沿用了 Podman 的方針：沒有守護(hù)進(jìn)程，不需要 root 特權(quán)，而且生成的是符合 OCI 的鏡像，因此你的鏡像的運(yùn)行方式與使用 Docker 構(gòu)建的鏡像完全相同。它還能使用 Dockerfile 或 Containerfile 構(gòu)建鏡像， Dockerfile 與 Containerfile 實(shí)際上是同一個(gè)東西，只是叫法不同罷了。除此之外，Buildah 還提供了對(duì)鏡像層更精細(xì)的控制，支持提交大量的變更到單個(gè)層。我認(rèn)為，它與 Docker 之間有一個(gè)出乎意料的區(qū)別（但這個(gè)區(qū)別是好事），那就是使用 Buildah 構(gòu)建的鏡像特定于用戶，因此你可以只列出自己構(gòu)建的鏡像。

你可能會(huì)問，既然 Podman CLI 中已經(jīng)包含了 Buildah，為什么還要使用單獨(dú)的 Buildah CLI 呢？其實(shí)，Buildah CLI 是 podman build 所包含的命令的超集，因此你可能不需要直接使用 BuildahCLI，但是通過使用它，你可能會(huì)發(fā)現(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??#?equivalentto?"RUN?apk?add?--update?--no-cache?python3"
fetchhttp://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
fetchhttp://dl-cdn.alpinelinux.org/alpine/v3.12/community/x86_64/APKINDEX.tar.gz
...

~?$?buildah?commit?alpine-working-containermy-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 進(jìn)行構(gòu)建，你也可以使用其他腳本化的方法，比如使用 Buildahs 的 from、run 和 copy，它們分別對(duì)應(yīng) Dockerfile 中的 FROM、RUN、COPY 命令。

接下來是 Google 的 Kaniko。Kaniko 也是利用 Dockerfile 構(gòu)建容器鏡像，而且與 Buildah 類似，它也不需要守護(hù)進(jìn)程。但它與 Buildah 的主要區(qū)別在于，Kaniko 更加側(cè)重于 Kubernetes 中的鏡像構(gòu)建。

Kaniko 本身也要作為鏡像(gcr.io/kaniko-project/executor) 運(yùn)行，這對(duì)于Kubernetes 來說是沒有問題的，但對(duì)于本地構(gòu)建來說不是很方便，并且在某種程度上違背了構(gòu)建鏡像的目的，因?yàn)槟阈枰褂?Docker 運(yùn)行 Kaniko 鏡像才能構(gòu)建鏡像。話雖如此，如果你正在尋找在 Kubernetes 集群中構(gòu)建鏡像的工具 (例如在 CI/CD 管道中)，那么 Kaniko 可能是一個(gè)不錯(cuò)的選擇，因?yàn)樗恍枰刈o(hù)進(jìn)程，而且更安全。

以我個(gè)人的經(jīng)驗(yàn)來看，我認(rèn)為兩者都能很好地完成工作，但是使用 Kaniko 時(shí)，我遇到了一些隨機(jī)的構(gòu)建故障，而且在將鏡像推送到倉(cāng)庫(kù)時(shí)也出現(xiàn)了失敗的情況。

我要介紹的第三個(gè)工具是 buildkit，也可以稱之為 docker build 二代。它是 Moby 項(xiàng)目的一部分（與 Docker一樣），只需設(shè)置 DOCKER_BUILDKIT=1 docker build，就可以啟動(dòng)這個(gè)工具，并作為 Docker 的一個(gè)實(shí)驗(yàn)性功能使用。那么，這個(gè)工具究竟能給你帶來什么？它帶來了很多改進(jìn)和很酷的功能，包括并行構(gòu)建、跳過未使用的階段、更好的增量構(gòu)建以及不需要 root 權(quán)限等構(gòu)建。但是，它仍然需要運(yùn)行守護(hù)進(jìn)程 (buildkitd)。因此，如果你不想擺脫 Docker，同時(shí)又想要一些新的功能和改進(jìn)，那么可以考慮一下 buildkit。

這里，我也會(huì)列出一些其他的工具，它們有各自的特定用途，但不是我的首選：

Source-To-Image（S2I）：這是一個(gè)不使用 Dockerfile，直接根據(jù)源代碼構(gòu)建鏡像的工具包。這個(gè)工具在簡(jiǎn)單的預(yù)期場(chǎng)景和工作流中表現(xiàn)良好，但如果你需要多一些自定義，如果你的項(xiàng)目的結(jié)構(gòu)不符合預(yù)期，那么它就變得非常煩人和笨拙。如果你對(duì) Docker 不太滿意，或者你在 OpenShift 集群上構(gòu)建鏡像，則可以考慮使用 S2I，因?yàn)槭褂?S2I 構(gòu)建鏡像是它的一個(gè)內(nèi)置功能。

Jib：這是一款由 Google 開發(fā)的工具，專門用于構(gòu)建 Java 鏡像。它提供了 Maven 和 Gradle 插件，可以讓你輕松地構(gòu)建鏡像，而無需在意 Dockerfile。

Bazel：這也是一款由 Google 開發(fā)的工具。它不僅可用于構(gòu)建容器鏡像，而且是一個(gè)完整的構(gòu)建系統(tǒng)。如果你只是想構(gòu)建鏡像，那么使用 Bazel 可能會(huì)有點(diǎn)大材小用，但絕對(duì)是一種不錯(cuò)的學(xué)習(xí)體驗(yàn)，如果你愿意，可以先從 rules_docker 著手。

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

最后我們來說說負(fù)責(zé)運(yùn)行容器的容器運(yùn)行時(shí)。容器運(yùn)行時(shí)是整個(gè)容器生命周期的一部分，除非你對(duì)速度、安全性等有一些非常特殊的要求，否則請(qǐng)不要亂動(dòng)它。

看到這里，如果你感到厭倦了，則可以跳過這一部分。但是，如果你想了解一下在容器運(yùn)行時(shí)方面，都有哪些選擇，則可以看看下面這些：

runc 是一款流行的容器運(yùn)行時(shí)，且符合 OCI 容器運(yùn)行時(shí)規(guī)范。Docker(通過containerd)、Podman 和 CRI-O 都在使用它，因此無需我多言。它幾乎是所有容器引擎的默認(rèn)設(shè)置，因此即便你在閱讀本文后拋棄了 Docker，很可能仍然會(huì)使用 runc。

runc 的另一種替代品是 crun。這是一款由紅帽開發(fā)的工具，全部用 C 語(yǔ)言編寫（runc 是用 Go 編寫的），所以它比 runc 更快，內(nèi)存效率更高。由于它也是兼容 OCI 的運(yùn)行時(shí)，所以如果你想試試看的話，應(yīng)該能很快上手。雖然它現(xiàn)在還不是很流行，但是它即將作為 RHEL 8.3 版本的備選 OCI 運(yùn)行時(shí)，出現(xiàn)在技術(shù)預(yù)覽中，而且考慮到它是紅帽的產(chǎn)品，所以最終很可能會(huì)成為 Podman 或 CRI-O 的默認(rèn)配置。

說到 CRI-O，前面我說過，它并不是容器引擎，而是容器運(yùn)行時(shí)。這是因?yàn)?CRI-O 沒有推送鏡像之類的功能，但這些功能是容器引擎應(yīng)該具備的。CRI-O 內(nèi)部使用 runc 來運(yùn)行容器。你不應(yīng)該在自己的機(jī)器上嘗試使用這個(gè)運(yùn)行時(shí)，因?yàn)樗脑O(shè)計(jì)就是 Kubernetes 節(jié)點(diǎn)上的運(yùn)行時(shí)，而且它是“Kubernetes 所需的唯一的運(yùn)行時(shí)”。因此，除非你要建立 Kubernetes 集群，否則就不應(yīng)該考慮 CRI-O。

最后一個(gè)是 containerd，它是云原生計(jì)算基金會(huì)即將推出的一個(gè)項(xiàng)目。它是一個(gè)守護(hù)進(jìn)程，可作為各種容器運(yùn)行時(shí)和操作系統(tǒng)的 API 接口。它后臺(tái)依賴于 runc，它是 Docker 引擎的默認(rèn)運(yùn)行時(shí)。Google Kubernetes Engine（GKE）和 IBM Kubernetes Service（IKS）也在使用它。它是 Kubernetes容器運(yùn)行時(shí)接口的一個(gè)實(shí)現(xiàn)（與 CRI-O 一樣），因此是 Kubernetes 集群運(yùn)行時(shí)的理想選擇。

鏡像的檢查與分發(fā)

最后一部分內(nèi)容是鏡像的檢查與分發(fā)，主要是為了替代 docker inspect，并增加在遠(yuǎn)程倉(cāng)庫(kù)之間復(fù)制鏡像的能力（可選）。

在這里，我要提到的唯一可以完成這些任務(wù)的工具是 Skopeo。它由紅帽開發(fā)，是 Buildah、Podman 和 CRI-O 的附屬工具。除了基本的 skopeo inspect（Docker 有相應(yīng)的命令），Skopeo 還可以通過 skopeo copy 令來復(fù)制鏡像，因此你可以直接在遠(yuǎn)程倉(cāng)庫(kù)之間復(fù)制鏡像，無需將它們拉取到本地。如果你使用本地倉(cāng)庫(kù)，那么這個(gè)功能也可以作為拉取/推送。

另外，我還想提一下 Dive，這是一款檢查、探索和分析鏡像的工具。它更加人性化，提供了更加方便閱讀的輸出，而且還可以更深入地挖掘鏡像，并分析和測(cè)量鏡像的效率。此外，它也很適合在 CI 管道中使用，用于衡量你的鏡像是否“足夠高效”，或者換句話說，是否浪費(fèi)了太多空間。

總結(jié)

本文的目的并不是要說服你完全拋棄 Docker，而是為了向你展示構(gòu)建、運(yùn)行、管理和分發(fā)容器及其鏡像的整個(gè)過程以及所有備選工具。每個(gè)工具（包括 Docker）都有其優(yōu)缺點(diǎn)，因此，評(píng)估哪些工具最適合你的工作流程和情況才是最重要的，希望本文能在這方面為你提供一些幫助。

文章來源于網(wǎng)絡(luò)，侵刪！