目前，許多組織都采用容器來(lái)進(jìn)行開(kāi)發(fā)和運(yùn)行應(yīng)用程序。Docker 是該領(lǐng)域功能最豐富且使用最廣泛的產(chǎn)品之一，已有數(shù)百萬(wàn)應(yīng)用程序在使用它。Docker 本身有著強(qiáng)大的生態(tài)系統(tǒng)，并提供了一個(gè)廣泛的工具包來(lái)管理容器化過(guò)程。

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

因此，Docker 并不是容器的唯一選擇，容器還有其他的替代品，它們提供了獨(dú)特的用例和功能。

本文將深入探討 Docker 的相關(guān)替代品，其中包括一系列與 Docker 類似的產(chǎn)品以及可以作為 Docker 生態(tài)系統(tǒng)組件替代品的工具。

Podman

Podman 是 RedHat 開(kāi)發(fā)的一個(gè)無(wú)守護(hù)程序的開(kāi)源 Linux 原生容器引擎，用于構(gòu)建、運(yùn)行和管理 Linux OCI 容器與容器鏡像。盡管 Podman 提供了一個(gè)類似于 Docker 的命令行界面，但它的操作方式并不相同。

Docker 和 Podman 之間的一個(gè)顯著區(qū)別是，Docker 運(yùn)行一個(gè)持久的、自給自足的運(yùn)行時(shí)來(lái)管理其對(duì)象或稱為 dockerd 的守護(hù)進(jìn)程；而 Podman 并不依賴守護(hù)進(jìn)程來(lái)工作，相反Podman 將容器作為子進(jìn)程啟動(dòng)，它還直接與注冊(cè)表和使用運(yùn)行時(shí)進(jìn)程的 Linux 內(nèi)核進(jìn)行交互。也正因如此，Podman 被稱為無(wú)守護(hù)進(jìn)程的容器技術(shù)。

沒(méi)有守護(hù)進(jìn)程提高了 Podman 作為容器引擎的靈活性，消除了對(duì)單個(gè)進(jìn)程的依賴。Podman 與 Docker 的另一大不同就是它不需要 root 權(quán)限。這一特點(diǎn)提供了一個(gè)額外的安全緩沖區(qū)，限制了某些可能操縱關(guān)鍵系統(tǒng)設(shè)置并使容器和包含的應(yīng)用程序易受攻擊的潛在危險(xiǎn)進(jìn)程。

此外，Podman 可以運(yùn)行 pod（包含一個(gè)或多個(gè)容器的集合），作為一個(gè)單一實(shí)體管理，并利用共享的資源池。通過(guò)這項(xiàng)能力，Podman 用戶可以將他們的工作負(fù)載轉(zhuǎn)移到 Kubernetes。

LXD

LXD 是一個(gè)專為 LXC Linux 容器設(shè)計(jì)的開(kāi)源容器引擎。LXC 使用戶能夠在隔離的容器或類似于虛擬機(jī)的虛擬環(huán)境中運(yùn)行應(yīng)用程序，而無(wú)需承擔(dān)管理單個(gè)內(nèi)核的技術(shù)負(fù)擔(dān)。LXD 提供了一個(gè)用于連接 LXC 軟件庫(kù)的接口，同時(shí)創(chuàng)建了一個(gè)負(fù)責(zé)處理網(wǎng)絡(luò)、數(shù)據(jù)存儲(chǔ)和管理多個(gè)LXC容器的守護(hù)進(jìn)程。

盡管 LXC 可以作為獨(dú)立工具運(yùn)行，但它擁有有限的功能子集。LXD 提供了這些附加功能，因此依賴于 LXC 工作。

LXD 與 Docker 的主要區(qū)別在于：Docker 建議每個(gè)容器只運(yùn)行單個(gè)進(jìn)程，而LXC/LXD 中的容器則可以運(yùn)行多個(gè)進(jìn)程。此外，Docker 容器可移植性更強(qiáng)，因?yàn)榕c LXD 相比，Docker 有效地抽象了資源。最后，Docker 支持在 Windows 和 macOS 環(huán)境上運(yùn)行，但 LXD 只支持 Linux。

Containerd

Containerd 是一個(gè)高級(jí)容器運(yùn)行時(shí)，它通過(guò)在底層運(yùn)行 runc 以提供操作系統(tǒng)和容器引擎之間的接口。runc 是一個(gè)支持 Windows 和 Linux 的守護(hù)進(jìn)程，它抽象了特定于操作系統(tǒng)的功能，使運(yùn)行和監(jiān)督容器以及管理圖像傳輸和存儲(chǔ)變得更加容易。

Containerd 提供的這種抽象級(jí)別功能消除了進(jìn)行若干低級(jí)系統(tǒng)調(diào)用的復(fù)雜性，使得容器的可移植性得以實(shí)現(xiàn)。

然而，與 Docker 不同的是，Containerd 不處理鏡像的構(gòu)建或卷的創(chuàng)建。有趣的是，Containerd 是 Docker 的默認(rèn)運(yùn)行時(shí)，現(xiàn)在它是一個(gè)獨(dú)立的工具，就像 runc 一樣。這也使得 Containerd 像 Kubernetes 一樣成為一個(gè)方便的編排工具，Containerd 也是最受歡迎的 Docker 替代品之一。

Buildah

Buildah 是紅帽基金會(huì)為容器化系統(tǒng)開(kāi)發(fā)的一個(gè) OCI 鏡像構(gòu)建工具。它是一個(gè)提供類似于在 Docker 中運(yùn)行 docker build 功能的工具。Buildah 經(jīng)常與 Podman 一起使用，互作補(bǔ)充，例如，Podman 在后臺(tái)使用 Buildah 功能的子集來(lái)實(shí)現(xiàn)其構(gòu)建過(guò)程。

它可以從 Dockerfile 或 Containerfile 中構(gòu)建鏡像，并生成與使用 Docker 創(chuàng)建的鏡像相同的鏡像，因?yàn)檫@些鏡像是符合 OCI 規(guī)范的。

此外，它還提供了對(duì)鏡像層的細(xì)粒度控制，允許向單個(gè)層提交多次更改。它還提供了從頭開(kāi)始構(gòu)建鏡像的能力，即不包含任何內(nèi)容的鏡像，這讓用戶可以自由地只添加運(yùn)行應(yīng)用程序所需的軟件包。最后，與 Docker 不同的是，在 Buildah 中用戶只能看到他們構(gòu)建的鏡像，因?yàn)樗翘囟ㄓ谟脩舻摹?/p>

BuildKit

BuildKit 是第二代構(gòu)建鏡像的 Moby 項(xiàng)目，在較新的 Docker 版本中作為實(shí)驗(yàn)性功能提供。與 Docker 一樣，它使用守護(hù)程序運(yùn)行。不過(guò)，標(biāo)準(zhǔn) Docker 構(gòu)建和 BuildKit 之間一個(gè)主要的區(qū)別是，前者使用逐層構(gòu)建，而后者提供并行構(gòu)建處理。這個(gè)功能提高了性能，使構(gòu)建速度變得更快。

BuildKit 還允許跳過(guò)未使用的階段，改善增量構(gòu)建，并允許無(wú)根構(gòu)建。此外，BuildKit 使用高速緩存來(lái)減少構(gòu)建鏡像每一層的需要。

Kaniko

Kaniko 是一個(gè)谷歌鏡像構(gòu)建工具，它可以從 Dockerfile 構(gòu)建鏡像。它和 Buildah 一樣是無(wú)守護(hù)進(jìn)程的，但更側(cè)重于在 Kubernetes 中構(gòu)建鏡像。

Kaniko 對(duì)于本地開(kāi)發(fā)實(shí)例來(lái)說(shuō)不是很方便，因?yàn)樗ǔＷ鳛殓R像與 Kubernetes 等容器編排器一起運(yùn)行。然而，對(duì)于 Kubernetes 集群中的持續(xù)集成和交付管道，Kaniko 可以成為一個(gè)實(shí)用的工具。

審核編輯 ：李倩