Docker並不是唯一的容器化工具，可能還有更好的選擇……
在容器的早期時代（其實更像是4年前），Docker是容器遊戲中唯一的玩家。但現在情況已經不一樣了，Docker不再是唯一的一個，而只是其中一個容器引擎而已。Docker允許我們構建、運行、拉、推或檢查容器鏡像，然而對於每一項任務，都有其他的替代工具，甚至可能比Docker做得還要好。所以，讓我們探索一下，然後再卸載（只是可能），直至完全忘記Docker……
那，爲什麼不再用Docker了？
如果你已經使用Docker很長時間了，估計要真正說服你去考慮其他工具，得先提供些依據。
首先，Docker是一個單體工具。它嘗試去涵蓋所有的功能，通常這並不是最佳實踐。大多數情況下，我們都是隻選擇一種專門的工具，它只做一件事，並且做得非常好，非常精。
如果害怕切換到不同的工具集是因爲將不得不學習使用不同的CLI、API或者說不同的概念，那麼這不會是一個問題。本文中展示的任何工具都可以是完全無縫的，因爲它們（包括Docker）都遵循OCI （Open Container Initiative）下的相同規範。它們包含了容器運行時、容器分發和容器鏡像的規範，其中涵蓋了使用容器所需的所有特性。
有了OCI，你可以選擇一套最符合你需求的工具，同時你仍然可以享受跟Docker一樣使用相同的API和CLI命令。
所以，如果你願意嘗試新的工具，那麼讓我們比較一下Docker和它的競爭對手的優缺點和特性，看看是否有必要考慮放棄Docker，使用一些新的閃亮的工具。
容器引擎
在比較Docker和其他工具時，我們需要將其分解爲組件，首先我們先討論一下容器引擎。Container Engine是一種工具，它爲處理鏡像和容器提供用戶界面，這樣就不必處理SECCOMP規則或SELinux策略之類的事情。它的工作還包括從遠程倉庫提取鏡像並將其擴展到磁盤。它看起來也是運行容器，但實際上它的工作是創建容器清單和帶有鏡像層的目錄。然後它將它們傳遞到容器運行時，如runC或Crun（稍後我們將討論這一點）。
目前已經有許多容器引擎，但Docker最突出的競爭對手是由紅帽開發的Podman。與Docker不同，Podman不需要Daemon來運行，也不需要root特權，這是Docker長期以來一直關注的問題。基於它的名字，Podman不僅可以運行容器，還可以運行pods。如果你不熟悉pods的概念，其實，簡單的概括就是，Pod是Kubernetes的最小計算單元。它由一個或多個容器（主容器和執行支持任務的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命令，因此只需執行alias docker = podman並裝作什麼都沒有改變。
除了Docker和Podman之外，還有其他的容器引擎，但我個人認爲它們都是沒什麼出路的技術，或者都不太適合本地開發和使用。但是，要全面瞭解，至少要看一下其中的內容：
-
LXD——LXC （Linux Containers）是一個容器管理器（守護進程）。該工具提供了運行系統容器的能力，這些系統容器提供了更類似於VM的容器環境。它位於非常狹窄的空間，沒什麼用戶，所以除非你有非常具體的實例，否則最好還是使用Docker或Podman。
-
CRI-O——當你Google什麼是CRI-O你可能會發現它被描述爲容器引擎。不過，實際上它只是容器運行時。其實它既不是引擎，也不適合“正常”使用。我的意思是，它是專門爲Kubernetes運行時（CRI）而構建的，而不是爲最終用戶使用的。
- Rkt——rkt（“Rocket”）是由CoreOS開發的容器引擎。這裏提到這個項目只是爲了完整性，因爲這個項目已經結束，開發也停止了——所以也就沒必要再使用了。
構建鏡像
對於容器引擎來說，一般都只選擇Docker。但是，當涉及到構建鏡像時，選擇的餘地還是比較多的。
首先，介紹一下Buildah。Buildah是紅帽開發的另一個工具，它與Podman配合使用相當合適。如果已經安裝了Podman，你可能會注意到podman build子命令，它實際上只是僞裝的Buildah，因爲它的二進制文件已經包含在Podman裏。
至於它的特性，它遵循了與Podman相同的路線——無守護程序和無根的，並遵循OCI的鏡像標準，所以它能保證所構建的鏡像和Docker構建的是一樣的。它還能夠從Dockerfile或更恰當的命名Containerfile來構建鏡像，Dockerfile和Containerfile都是相同的，只是命名的區別。除此之外，Buildah還對鏡像層提供了更精細的控制，允許在單層中提交更多變更。唯一的例外是（在我看來）與Docker的區別是，由Buildah構建的鏡像是基於用戶的，因此用戶可以只列出自己構建的鏡像。
那麼，考慮到Buildah已經包含在Podman CLI中，大家可能會問，爲什麼還要使用單獨的Buildah CLI？Buildah CLI是podman build中包含的命令的超集，所以基本不需要單獨接觸Buildah CLI，但是通過使用它，你可能還會發現一些額外有用的特性（有關podman build和buildah之間的差異的細節，請參閱這個文章[1]）。
現在，我們來看看一個演示：
\~ \$ 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構建鏡像，bud代表使用Dockerfile構建，但是你還可以使用更多Buildahs的腳本：from，run和copy，這些命令對應命令Dockerfile的（FROM image，RUN…，COPY…）。
下一個是谷歌的Kaniko。Kaniko也是從Dockerfile構建容器鏡像，跟Buildah類似，也不需要守護進程。與Buildah的主要區別在於，Kaniko更專注於在Kubernetes中構建鏡像。
Kaniko使用gcr.io/ Kaniko -project/executor作爲鏡像運行。這對於Kubernetes來說是行得通的，但是對於本地構建來說不是很方便，並且在某種程度上違背了它的初衷，因爲我們得先使用Docker來運行Kaniko鏡像，然後再去構建鏡像。也就是說，如果正在爲Kubernetes集羣中構建鏡像的工具進行選型（例如在CI/CD Pipeline中），那麼Kaniko可能是一個不錯的選擇，因爲它是無守護程序的，而且（可能）更安全。
從我個人的經驗來看——我在Kubernetes/OpenShift集羣中使用了Kaniko和Buildah來構建鏡像，我認爲兩者都能很好地完成任務，但在使用Kaniko時，我看到了一些將鏡像導入倉庫時的，會有隨機構建崩潰和失敗的情況。
第三個競爭者是Buildkit，也可以稱爲下一代的Docker build。它是Moby項目的一部分。在Docker裏可以使用DOCKER_BUILDKIT=1 Docker build…作爲實驗特性進行啓用。那麼，它的核心價值到底有哪些？它引入了許多改進和炫酷的特性，包括並行構建、跳過未使用的階段、更好的增量構建和無根構建。然而另一方面，它仍然需要運行守護進程（buildkitd）才能運行。所以，如果你不想擺脫Docker，但是想要一些新的特性和更好的改進，那麼使用Buildkit可能是最好的選擇。
和前面一樣，這裏我們也還有一些“光鮮亮麗的產品”，它們也都有非常具體的場景，雖然並不是我們的首選：
-
Source-To-Image（S2I）是一個不需要Dockerfile直接從源代碼構建鏡像的工具包。這個工具在簡單的、預期的場景和工作流中運行的很好，但是如果有太多的定製，或者該項目沒有預期的佈局，你很快就會覺得這個工具很煩人和笨拙。如果你對Docker還不是很有信心，或者如果在OpenShift集羣上構建鏡像，那麼你可以嘗試考慮一下使用S2I，因爲使用S2I構建是一個內置特性。
-
Jib是谷歌的另一個工具，專門用於構建Java鏡像。它包括Maven和Gradle插件，可以輕鬆地構建鏡像，而不會干擾Dockerfile。
- 最後一個但並不是不重要的是Bazel，它是谷歌的另一款工具。它不僅用於構建容器鏡像，而且是一個完整的構建系統。如果你只是想構建一個鏡像，那麼鑽研Bazel可能有點過頭，但絕對是一個很好的學習體驗，所以如果你想嘗試，rules_docker絕對是一個很好的起點。
容器運行時
最後一個大塊兒是容器運行時，它負責運行容器。容器運行時是整個容器生命週期/棧的一部分，除非你對速度、安全性等有一些非常具體的要求，否則一般是不需要對其進行干擾。所以，如果讀者看到這裏已經厭倦，那麼可以跳過這一部分。如果不是，那麼有關容器運行時的選擇，如下：
runC是基於OCI容器運行時規範創建的，且最流行的容器運行時。Docker（通過containerd）、Podman和crio使用它，所以幾乎所有東西都依賴於LXD。它幾乎是所有產品/工具的默認首選項，所以即使你在閱讀本文後放棄Docker，但你仍然會用到runC。
runC的另一款替代方產品爲Crun，名稱類似（容易混淆）。這是Red Hat開發的工具，完全用C編寫（runC是用Go編寫的）。這使得它比runC更快，內存效率更高。考慮到它也是OCI兼容的運行時。所以，如果你想做個測試，切換起來很容易。儘管它現在還不是很流行，但在RHEL 8.3技術預覽版中，它將作爲一個替代OCI運行時，同時，考慮到它是紅帽的產品，我們可能最終會看到它會成爲Podman或CRI-O的默認首選項。
說到CRI-O。前面我說過，CRI-O實際上不是一個容器引擎，而是容器運行時。這是因爲CRI-O不包括比如推送鏡像這樣的特性，而這正是容器引擎的特性。作爲運行時的CRI-O在內部使用runC運行容器。通常情況下不需要在單機嘗試這個工具，因爲它被構建爲用於Kubernetes節點上的運行時，可以看到它被描述爲“Kubernetes需要的所有運行時，僅此而已”。因此，除非你正在設置Kubernetes集羣（或OpenShift集羣——CRI-O已經是默認首選項了），否則不大可能會接觸到這個。
本節的最後一個內容是containerd，它是CNCF的一個畢業的項目。它是一個守護進程，充當各種容器運行時和操作系統的API。在後臺，它依賴於runC，是Docker引擎的默認運行時。谷歌Kubernetes引擎（GKE）和IBM Kubernetes服務（IKS）也在使用。它是Kubernetes容器運行時接口的一個部署（與CRI-O相同），因此它是Kubernetes集羣運行時的一個很好的備選項。
鏡像檢測與分發
容器棧的最後一部分是鏡像的檢測與分發。這有效地替代了docker inspect，還（可選地）增加了遠程鏡像倉庫之間複製/映射鏡像的能力。
這裏唯一要提到的可以完成這些任務的工具是Skopeo。它由紅帽公司開發，是Buildah，Podman和CRI-O的配套工具。除了我們都從Docker中知道的基本的skopeo inspect之外，Skopeo還能夠使用skopeo copy複製鏡像，它允許你在遠程鏡像倉庫之間映射鏡像，而無需先將它們拉到本地倉庫。如果你使用本地倉庫，此功能也可以作爲pull/push。
另外，我還想提一下Dive，這是一個檢查、探測和分析鏡像的工具。它對用戶更友好一些，提供了更可讀的輸出，可以更深入地探測鏡像，並分析和衡量其效率。它也適合在CI管道中使用，它可以測量你的鏡像是否“足夠高效”，或者換句話說——它是否浪費了太多空間。
結論
本文的目的並不是要說服大家完全拋棄Docker，而是向大家展示構建、運行、管理和分發容器及其鏡像的整個場景和所有選項。包括Docker在內的每一種工具都有其優缺點，評估哪一組工具最適合你的工作流和場景纔是最重要的，真心希望本文能在這方面幫助到你。
原文鏈接：https://towardsdatascience.com/its-time-to-say-goodbye-to-docker-5cfec8eff833