在容器的遠古時代 (差不多就是 4 年前)，Docker 是這場游戲的唯一玩家。但現(xiàn)在情況已經(jīng)不一樣了，Docker 不再是唯一玩家，而只是一個容器引擎而已。我們可以用 Docker 構建、運行、拉取、推送或檢查容器鏡像，但對于這里的每一項任務，都有其他可替代的工具，它們可能比 Docker 做得更好。所以，讓我們來探究一下它們，然后卸載和忘掉 Docker……

為什么說不要用 Docker 了？

如果你已經(jīng)使用 Docker 很長時間了，那么要說服你考慮使用其他的工具可能需要費點唇舌。

首先，Docker 是一個整體性的工具，它試圖做所有的事情，但這通常不是最好的方法。大多數(shù)情況下，選擇一種專門的工具會更好，它可能只做一件事，但會做到最好。如果你害怕使用不同的工具，可能是因為你要學習使用不同的 CLI、不同的 API 或接受不同的概念。不過請放心，選擇本文介紹的工具都是完全無縫銜接的，因為它們 (包括 Docker) 都遵循 OCI (Open Container Initiative) 規(guī)范。OCI 包含了容器運行時、容器分發(fā)和容器鏡像的規(guī)范，涵蓋了使用容器所需的所有特性。多虧了 OCI，你可以選擇一套最適合自己的工具，同時又能夠繼續(xù)使用與 Docker 一樣的 API 和 CLI 命令。

所以，如果你愿意嘗試新的工具，那么就讓我們來比較一下 Docker 和其他工具的優(yōu)缺點和特性，看看是否有必要考慮放棄 Docker，并轉(zhuǎn)向其他一些新的工具。

容器引擎

在比較 Docker 和其他工具時，我們需要將其分解為組件，首先我們要討論的是容器引擎。容器引擎是一種工具，它為處理鏡像和容器提供了用戶界面，這樣你就不需要處理 SECCOMP 規(guī)則或 SELinux 策略之類的事情。它的工作還包括從遠程存儲庫提取鏡像并將其解壓到磁盤。它似乎也運行容器，但實際上它的工作是創(chuàng)建容器清單和包含了鏡像層的目錄。然后它將它們傳到容器運行時，例如使用 runc 或 crun(稍后我們將討論這個)。目前有很多可用的容器引擎，不過 Docker 最突出的競爭對手是由 Red Hat 開發(fā)的 Podman。與 Docker 不同，Podman 不需要守護進程，也不需要 root 特權，這是 Docker 長期以來一直存在的問題。從它的名字就可以看出來，Podman 不僅可以運行容器，還可以運行 Pod。Pod 是 Kubernetes 的最小計算單元，由一個或多個容器 (主容器和所謂的邊車) 組成，Podman 用戶在以后可以更容易地將他們的工作負載遷移到 Kubernetes。以下演示了如何在一個 Pod 中運行兩個容器：

~$podmanpodcreate--namemypod ~$podmanpodlist PODIDNAMESTATUSCREATED#OFCONTAINERSINFRAID 211eaecd307bmypodRunning2minutesago1a901868616a5 ~$podmanrun-d--podmypodnginx#Firstcontainer ~$podmanrun-d--podmypodnginx#Secondcontainer ~$podmanps-a--pod CONTAINERIDIMAGECOMMANDCREATEDSTATUSPORTSNAMESPODPODNAME 3b27d9eaa35cdocker.io/library/nginx:latestnginx-gdaemono...2secondsagoUp1secondagobrave_ritchie 211eaecd307bmypodd638ac011412docker.io/library/nginx:latestnginx-gdaemono...5minutesagoUp5minutesagocool_albattani 211eaecd307bmypoda901868616a5k8s.gcr.io/pause:3.26minutesagoUp5minutesago211eaecd307b-infra211eaecd307bmypod

Podman 提供了與 Docker 完全相同的 CLI 命令，因此你只需執(zhí)行 alias Docker=Podman，然后就像什么都沒有發(fā)生改變一樣。除了 Docker 和 Podman 之外，還有其他容器引擎，但我認為它們沒有出路或者都不適合用于本地開發(fā)。不過如果你想要對容器引擎有一個較為完整的了解，我們可以列出一些：

LXD——是 LXC (Linux 容器) 的容器管理器 (守護進程)。這個工具提供了運行系統(tǒng)容器的能力，這些系統(tǒng)容器提供了類似于 VM 的容器環(huán)境。它比較小眾，沒有很多用戶，所以除非你有特定的用例，否則最好使用 Docker 或 Podman。

CRI-O——如果你在網(wǎng)上搜索 cri-o 是什么東西，你可能會發(fā)現(xiàn)它被描述為一種容器引擎。不過，它實際上是一種容器運行時。除了不是容器引擎之外，它也不適合用于“一般”的情況。我的意思是，它是專門為 Kubernetes 運行時 (CRI) 而構建的，并不是給最終用戶使用的。

rkt——rkt(“rocket”) 是由 CoreOS 開發(fā)的容器引擎。這里提到這個項目只是為了清單的完整性，因為這個項目已經(jīng)結束了，它的開發(fā)也停止了——因此它不應該再被使用。

鏡像的構建

從容器引擎方面來說，除了 Docker 之外只有一種選擇。但是，在構建鏡像方面，我們有很多選擇。首先是 Buildah。Buildah 是 Red Hat 開發(fā)的一款工具，可以很好地與 Podman 配合使用。如果你已經(jīng)安裝了 Podman，可能會注意到 podman build 子命令，它實際上是經(jīng)過包裝的 Buildah。在特性方面，Buildah 遵循了與 Podman 相同的路線——它是無守護進程的，可以生成符合 OCI 的像，并保證以相同的方式來運行使用 Docker 構建的鏡像。它還能基于 Dockerfile 或 Containerfile（它們實際上是同一個東西，只是叫法不一樣）構建鏡像。

除此之外，Buildah 還提供了對鏡像層更精細的控制，支持提交大量的變更到單個層。在我看來，它與 Docker 之間有一個出乎人意料的區(qū)別，使用 Buildah 構建的鏡像是特定于用戶的，因此你可以只列出自己構建的鏡像。你可能會問，既然 Buildah 已經(jīng)被包含在 Podman CLI 中，為什么還要使用單獨的 Buildah CLI？buildah CLI 是 podman build 所包含的命令的超集，你可能不需要使用 buildah CLI，但是通過使用它，你可能會發(fā)現(xiàn)一些額外有用的特性。

我們來看看一個小演示：

~$buildahbud-fDockerfile. ~$buildahfromalpine:latest#Createstartingcontainer-equivalentto"FROMalpine:latest" Gettingimagesourcesignatures Copyingblobdf20fa9351a1done Copyingconfiga24bb40132done Writingmanifesttoimagedestination Storingsignatures alpine-working-container#Nameofthetemporarycontainer ~$buildahrunalpine-working-container--apkadd--update--no-cachepython3#equivalentto"RUNapkadd--update--no-cachepython3" 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 ... ~$buildahcommitalpine-working-containermy-final-image#Createfinalimage Gettingimagesourcesignatures Copyingblob50644c29ef5askipped:alreadyexists Copyingblob362b9ae56246done Copyingconfig1ff90ec2e2done Writingmanifesttoimagedestination Storingsignatures 1ff90ec2e26e7c0a6b45b2c62901956d0eda138fa6093d8cbb29a88f6b95124c ~#buildahimages REPOSITORYTAGIMAGEIDCREATEDSIZE localhost/my-final-imagelatest1ff90ec2e26e22secondsago51.4MB

從上面的腳本可以看到，你可以直接使用 buildah bud 構建鏡像，其中 bud 表示使用 Dockerfile 來構建鏡像，你也可以使用其他更多的命令，如 from、run 和 copy，它們分別對應 Dockerfile 中的 FROM、RUN、COPY。

第二個工具是谷歌的 Kaniko。Kaniko 也基于 Dockerfile 構建容器鏡像，而且與 Buildah 類似，它也不需要守護進程。與 Buildah 的主要區(qū)別在于，Kaniko 更專注于在 Kubernetes 中構建鏡像。

Kaniko 本身是作為鏡像 (gcr.io/kaniko-project/executor) 運行的，這對于 Kubernetes 來說是沒有問題，但對于本地構建來說不是很方便，并且在某種程度上違背了構建鏡像的目的，因為你需要使用 Docker 來運行 Kaniko 鏡像來構建鏡像。

如果你正在尋找在 Kubernetes 集群中構建鏡像的工具 (例如在 CI/CD 管道中)，那么 Kaniko 可能是一個不錯的選擇，因為它是無守護進程的，而且 (可能) 更安全。

從我個人的經(jīng)驗來看——我在 Kubernetes/OpenShift 集群中使用了 Kaniko 和 Buildah 來構建鏡像，我認為兩者都能很好地完成任務，但在使用 Kaniko 時會隨機出現(xiàn)構建故障，在將鏡像推送到注冊表時也會隨機地出現(xiàn)失敗的情況。

第三個是 buildkit，也可以稱之為下一代 docker build。它是 Moby 項目的一部分，在運行 Docker 時通過 DOCKER_BUILDKIT=1 docker build 就可以啟用它，作為 Docker 的一個實驗性特性。

那么，這到底會給你帶來什么呢？它帶來了很多改進和很酷的特性，包括并行構建步驟、跳過未使用的階段、更好的增量構建和無根構建。但是，它仍然需要運行守護進程 (buildkitd)。所以，如果你不想擺脫 Docker，同時又想要一些新的特性和更好的改進，那么使用 buildkit 可能是最好的選擇。

跟之前的章節(jié)一樣，這里也將提及一些工具，它們滿足了一些特定的使用場景，但并不是我的首選：Source-To-Image (S2I) 是一個不使用 Dockerfile 直接從源代碼構建鏡像的工具包。

這個工具在簡單可預期的場景和工作流中表現(xiàn)良好，但如果你需要多一些定制化，或者你的項目沒有預期的結構，那么它就會變得煩人和笨拙。如果你對 Docker 還不是很有信心，或者如果你在 OpenShift 集群上構建鏡像，可能可以考慮使用 S2I，因為使用 S2I 構建鏡像是它的一個內(nèi)置特性。

Jib是谷歌開發(fā)的一款工具，專門用于構建 Java 鏡像。它提供了 Maven 和 Gradle 插件，可以讓你輕松地構建鏡像，不需要理會 Dockerfile。

最后一個是 Bazel，它是谷歌的另一款工具。它不僅用于構建容器鏡像，而且是一個完整的構建系統(tǒng)。如果你只是想構建鏡像，那么使用 Bazel 可能有點大材小用，但這絕對是一個很好的學習體驗，所以如果你愿意，可以將 rules_docker為入手點。

容器運行時

最后一個是負責運行容器的容器運行時。

容器運行時是整個容器生命周期的一部分，除非你對速度、安全性等有一些非常具體的要求，否則你很可能不會對其加以干擾。所以，如果你已經(jīng)感到厭倦了，可以跳過這一部分。

但是，如果你想知道有哪些可選擇的容器運行時，可以看看以下這些：runc是符合 OCI 容器運行時規(guī)范的容器運行時。Docker(通過 containerd)、Podman 和 CRI-O 都在使用它，它是 (幾乎) 所有東西的默認配置，所以即使你在閱讀本文后放棄使用 Docker，很可能仍然會使用 runc。

runc 的另一種替代品是 crun。這是 Red Hat 開發(fā)的一款工具，完全用 C 語言開發(fā) (runc 是用 Go 開發(fā)的)，所以它比 runc 更快，內(nèi)存效率更高。因為它也是兼容 OCI 的運行時，所以你應該可以很容易上手。盡管它現(xiàn)在還不是很流行，但作為 RHEL 8.3 版本的技術預覽，它將作為一個可選的 OCI 運行時，又因為它是 Red Hat 的產(chǎn)品，它可能最終會成為 Podman 或 CRI-O 的默認配置。

前面我說過，CRI-O 實際上不是容器引擎，而是容器運行時。這是因為 CRI-O 沒有提供諸如鏡像推送之類的特性，而這些特性是容器引擎應該具備的。

CRI-O 在內(nèi)部使用 runc 來運行容器。你不應該在自己的機器上嘗試使用這個運行時，因為它是作為運行在 Kubernetes 節(jié)點上的運行時而設計的，并被描述為“Kubernetes 所需的運行時”。因此，除非你正在運行 Kubernetes 集群 (或 OpenShift 集群——CRI-O 已經(jīng)是默認設置了)，否則不應該接觸這個。

最后一個是 containerd，它是 CNCF 的一個畢業(yè)項目。它是一個守護進程，作為各種容器運行時和操作系統(tǒng)的 API 外觀。在后臺，它依賴 runc，是 Docker 引擎的默認運行時。谷歌 Kubernetes 引擎 (GKE) 和 IBM Kubernetes 服務 (IKS) 也在使用它。它是 Kubernetes 容器運行時接口的一個實現(xiàn) (與 CRI-O 一樣)，因此它是 Kubernetes 集群運行時的一個很好的候選對象。

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

最后一部分內(nèi)容是鏡像的檢查與分發(fā)，主要是替代 docker inspect，并 (可選地) 增加遠程注冊表之間復制鏡像的能力。

我這里要提到的一個可以完成這些任務的工具是 Skopeo。它由 Red Hat 公司開發(fā)，可以與 Buildah、Podman 和 CRI-O 配套使用。除了基本的 inspect 之外，Skopeo 還提供了 skopeo copy 命令來復制鏡像，可以直接在遠程注冊表之間復制鏡像，無需將它們拉取到本地注冊表。如果你使用了本地注冊表，這個命令也可以作為拉取 / 推送的替代方案。

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

結論

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

責任編輯：lq