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提供了與Docker完全相同的CLI命令,因此只需執行alias docker = podman並裝作什麼都沒有改變。
除了Docker和Podman之外,還有其他的容器引擎,但我個人認為它們都是沒什麼出路的技術,或者都不太適合本地開發和使用。但是,要全面了解,至少要看一下其中的內容:
構建鏡像
對於容器引擎來說,一般都只選擇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之間的差異的細節,請參閱這個文章)。
現在,我們來看看一個演示:
從上面的腳本可以看到,我們可以只用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可能是最好的選擇。
和前面一樣,這裡我們也還有一些「光鮮亮麗的產品」,它們也都有非常具體的場景,雖然並不是我們的首選:
容器運行時
最後一個大塊兒是容器運行時,它負責運行容器。容器運行時是整個容器生命周期/棧的一部分,除非你對速度、安全性等有一些非常具體的要求,否則一般是不需要對其進行幹擾。所以,如果讀者看到這裡已經厭倦,那麼可以跳過這一部分。如果不是,那麼有關容器運行時的選擇,如下:
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在內的每一種工具都有其優缺點,評估哪一組工具最適合你的工作流和場景才是最重要的,真心希望本文能在這方面幫助到你。
【編輯推薦】
【責任編輯:
未麗燕TEL:(010)68476606】