許多企業(yè)都采用容器來進(jìn)行開發(fā)和管理穩(wěn)定的應(yīng)用程序，Docker 是該領(lǐng)域功能最豐富且使用最廣泛的工具之一，已有數(shù)百萬應(yīng)用程序在使用它。Docker 本身有著強大的獨立生態(tài)系統(tǒng)，并提供了一個廣泛的工具包來管理容器化過程，但 Docker 還有其他替代品，它們提供了獨特的用例和功能。本文深入探討了 Docker 七個替代品，其中包括一系列綜合平臺，如 Docker 以及可以作為 Docker 生態(tài)系統(tǒng)組件替代品的工具等。

一、Podman

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

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

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

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

二、LXD

LXD 一個專為 LXC Linux 容器設(shè)計的開源容器引擎。LXC 使用戶能夠在隔離的容器或類似于虛擬機的虛擬環(huán)境中運行應(yīng)用程序，而無需承擔(dān)管理單個內(nèi)核的技術(shù)負(fù)擔(dān)。LXD 提供了一個用于連接 LXC 軟件庫的接口，同時創(chuàng)建了一個守護(hù)進(jìn)程，負(fù)責(zé)處理網(wǎng)絡(luò)、數(shù)據(jù)存儲和管理多個 LXC 容器。盡管 LXC 可以作為獨立工具運行，但它擁有有限的功能子集。LXD 提供了這些附加功能，因此依賴于 LXC 工作。

LXD 與 Docker 的主要區(qū)別如下。與 Docker 建議每個容器只有單個進(jìn)程的設(shè)計模式不同，LXC/LXD 中的容器可以運行多個進(jìn)程。此外，Docker 容器可移植性更強，為與 LXD 相比，Docker 有效地抽象了資源。最后，Docker 支持在 Windows 和 macOS 環(huán)境上運行，但 LXD 只支持 Linux。

三、Containerd

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

Containerd 提供的這種抽象級別功能消除了進(jìn)行若干低級系統(tǒng)調(diào)用的復(fù)雜性，使得容器的可移植性得以實現(xiàn)。然而，與 Docker 不同，Containerd 不處理鏡像的構(gòu)建或卷的創(chuàng)建。有趣的是，Containerd 是 Docker 的默認(rèn)運行時，現(xiàn)在它是一個獨立的工具，就像 runc 一樣。這也使得 Containerd 像 Kubernetes 一樣成為一個方便的編排工具，Containerd 也是最受歡迎的 Docker 替代品之一。

四、Buildah

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

它可以從 Dockerfile 或 Containerfile 中構(gòu)建鏡像，并生成與使用 Docker 創(chuàng)建的鏡像相同的鏡像，因為這些鏡像是符合 OCI 的。此外，它還提供了對鏡像層的細(xì)粒度控制，允許在一個單一層中進(jìn)行多次修改提交。它還提供了從頭開始構(gòu)建鏡像的能力，即不包含任何內(nèi)容的鏡像，這讓用戶可以自由地只添加運行應(yīng)用程序所需的軟件包。最后，與 Docker 不同的是，在 Buildah 中，用戶只能看到他們構(gòu)建的鏡像。

五、BuildKit

BuildKit 是第二代構(gòu)建鏡像的 Moby 項目，在較新的 Docker 版本中作為實驗性功能提供。與 Docker 一樣，它使用守護(hù)程序運行。不過，標(biāo)準(zhǔn) Docker 構(gòu)建和 BuildKit 之間的主要區(qū)別之一是，前者是逐層構(gòu)建，后者提供并行構(gòu)建處理。這個功能提高了性能，使構(gòu)建速度更快。BuildKit 還允許跳過未使用的階段，改善增量構(gòu)建，并允許無根構(gòu)建。此外，BuildKit 使用一個緩存來減少重建圖像每一層的需要。

六、Kaniko

Kaniko 是一個谷歌鏡像構(gòu)建工具，它可以從 Dockerfile 構(gòu)建鏡像。它和 Buildah 一樣是無守護(hù)進(jìn)程的，但更側(cè)重于在 Kubernetes 中構(gòu)建鏡像。Kaniko 對于本地開發(fā)實例來說不是很方便，因為它通常作為鏡像與 Kubernetes 等容器編排器一起運行。對于 Kubernetes 集群中的持續(xù)集成和交付管道，Kaniko 可以成為一個實用的工具。

七、RunC

RunC 以前是嵌入到 Docker 架構(gòu)中的一個模塊，在 2015 年作為獨立工具發(fā)布。此后，它成為一個廣泛使用的、標(biāo)準(zhǔn)化的、可互操作的容器運行時。DevOps 團隊可以將其作為 Docker 或其他定制容器引擎的一部分。RunC 屬于容器化生態(tài)系統(tǒng)中的容器運行時部分。容器運行時是處理容器運行的容器引擎中使用的較低級別的組件。

盡管 Docker 為組織在容器化過程中所需的各個方面提供了一個全面的工具包，但某些 DevOps 功能可能需要探索其他替代方案。但是，在選擇任何此類選項時也需牢記此類替代方案所運行的主機操作系統(tǒng)及其使用情況。