所謂三十年河東，三十年河西，曾經在容器領域叱咤風云的 Docker 如今已風光不再。拋開情懷，我們不得不承認，Docker 已經被后浪拍死在沙灘上了……

大約 4 年前的容器領域，Docker 是唯一的選擇。

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

所以，下面就讓我們來探索一下這個領域，然后卸載和忘記 Docker 吧。

為什么說不要用 Docker 了？

如果長期以來你一直在使用 Docker，那么說服你考慮其他工具可能需要多費點唇舌。

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

可能你因為擔心需要學習使用不同的 CLI、不同的 API 或接受不同的概念，所以會害怕使用其他工具。但是，請不用擔心。本文介紹的任何工具都可以完美地無縫銜接，因為它們（包括 Docker）都遵循同一個 OCI（OpenContainer Initiative，開放容器計劃）規范。OCI 包括容器運行時、容器分發和容器鏡像的規范，涵蓋了使用容器所需的所有功能。

因為有了 OCI，所以你可以自由選擇適合自己的需求的工具，與此同時，你可以繼續使用與 Docker 相同的 API 和 CLI 命令。

因此，如果你愿意嘗試新工具，那么我們就來比較一下 Docker 與其競爭對手的優缺點和功能，看看是否有必要考慮放棄 Docker，并嘗試使用一些新鮮出爐的工具。

容器引擎

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

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

目前有很多容器引擎可供我們使用，不過 Docker 最主要的競爭對手是紅帽開發的 Podman。與 Docker 不同，Podman 不需要運行守護進程，也不需要 root 特權，這些都是 Docker 長期以來一直倍受關注的問題。從名字就可以看出來，Podman 不僅可以運行容器，還可以運行 pod。

如果你不熟悉 pod 的話，我可以簡單介紹一下：pod 是 Kubernetes 的最小計算單元，由一個或多個容器 (主容器與負責支持主容器的 sidercar 容器) 組成。因此，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?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

最后一點，Podman 提供的 CLI 命令與 Docker 完全相同，因此你只需執行

alias?docker=podman

然后就像什么都沒有發生過一樣。

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

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

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

CRI-O：如果在網上搜索 cri-o 是什么，你可能會發現它被描述成了一種容器引擎。但實際上，它是一種容器運行時。它既不是容器引擎，也不適合“常規”使用。我的意思是說，它是專門作為 Kubernetes 運行時（CRI）而創建的，并不是給最終用戶使用的。

rkt：rkt（讀作“rocket”）是 CoreOS 開發的容器引擎。這里提到這個項目只是為了清單的完整性，因為這個項目已經結束了，它的開發也停止了，因此你不應該再使用它。

構建鏡像

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

首先，我們來看一看 Buildah。這也是一款紅帽開發的工具，可以很好地與 Podman 協同工作。如果你已經安裝了 Podman，可能會注意到 podman build 子命令，因為它的二進制文件已經包含在 Podman 中了，實際上這個命令只是經過包裝的 Buildah。

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

你可能會問，既然 Podman CLI 中已經包含了 Buildah，為什么還要使用單獨的 Buildah CLI 呢？其實，Buildah CLI 是 podman build 所包含的命令的超集，因此你可能不需要直接使用 BuildahCLI，但是通過使用它，你可能會發現一些額外的功能。

下面，我們來看一個示例：

~?$?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 構建鏡像，其中 bud 代表使用 Dockerfile 進行構建，你也可以使用其他腳本化的方法，比如使用 Buildahs 的 from、run 和 copy，它們分別對應 Dockerfile 中的 FROM、RUN、COPY 命令。

接下來是 Google 的 Kaniko。Kaniko 也是利用 Dockerfile 構建容器鏡像，而且與 Buildah 類似，它也不需要守護進程。但它與 Buildah 的主要區別在于，Kaniko 更加側重于 Kubernetes 中的鏡像構建。

Kaniko 本身也要作為鏡像(gcr.io/kaniko-project/executor) 運行，這對于Kubernetes 來說是沒有問題的，但對于本地構建來說不是很方便，并且在某種程度上違背了構建鏡像的目的，因為你需要使用 Docker 運行 Kaniko 鏡像才能構建鏡像。話雖如此，如果你正在尋找在 Kubernetes 集群中構建鏡像的工具 (例如在 CI/CD 管道中)，那么 Kaniko 可能是一個不錯的選擇，因為它不需要守護進程，而且更安全。

以我個人的經驗來看，我認為兩者都能很好地完成工作，但是使用 Kaniko 時，我遇到了一些隨機的構建故障，而且在將鏡像推送到倉庫時也出現了失敗的情況。

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

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

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

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

Bazel：這也是一款由 Google 開發的工具。它不僅可用于構建容器鏡像，而且是一個完整的構建系統。如果你只是想構建鏡像，那么使用 Bazel 可能會有點大材小用，但絕對是一種不錯的學習體驗，如果你愿意，可以先從 rules_docker 著手。

容器運行時

最后我們來說說負責運行容器的容器運行時。容器運行時是整個容器生命周期的一部分，除非你對速度、安全性等有一些非常特殊的要求，否則請不要亂動它。

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

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

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

說到 CRI-O，前面我說過，它并不是容器引擎，而是容器運行時。這是因為 CRI-O 沒有推送鏡像之類的功能，但這些功能是容器引擎應該具備的。CRI-O 內部使用 runc 來運行容器。你不應該在自己的機器上嘗試使用這個運行時，因為它的設計就是 Kubernetes 節點上的運行時，而且它是“Kubernetes 所需的唯一的運行時”。因此，除非你要建立 Kubernetes 集群，否則就不應該考慮 CRI-O。

最后一個是 containerd，它是云原生計算基金會即將推出的一個項目。它是一個守護進程，可作為各種容器運行時和操作系統的 API 接口。它后臺依賴于 runc，它是 Docker 引擎的默認運行時。Google Kubernetes Engine（GKE）和 IBM Kubernetes Service（IKS）也在使用它。它是 Kubernetes容器運行時接口的一個實現（與 CRI-O 一樣），因此是 Kubernetes 集群運行時的理想選擇。

鏡像的檢查與分發

最后一部分內容是鏡像的檢查與分發，主要是為了替代 docker inspect，并增加在遠程倉庫之間復制鏡像的能力（可選）。

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

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

總結

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

文章來源于網絡，侵刪！