Podman vs Docker：選擇哪一個？

如果您進入虛擬化和容器化領域，您可能遇到過 Podman 和 Docker，您可能想知道它們之間有何不同。

在這篇文章中，我們將探討 Docker 和 Podman 之間的區別，並嘗試找出最適合您的選擇！

碼頭工人

Docker 是一種容器化技術，可促進項目中所有級別（開發和部署）的依賴項管理。

在 Linux、Windows 和 Mac OS 上可用，Docker 的機制以容器及其編排為中心，這就是容器化與虛擬化的不同之處。

Docker 有兩個主要構建塊：Docker CLI 和 Docker Daemon。

碼頭工人守護進程：

它是一個持續的後台進程，有助於管理 Docker 映像、容器、網絡和存儲卷。 Docker 使用其 Docker Engine REST API 與通過 HTTP 協議訪問的 Docker 守護進程進行交互。

碼頭工人命令行界面：

它是用於與 Docker 守護進程交互的 Docker 命令行客戶端。 這是您在運行任何 Docker 命令時使用的內容。

Docker的運行是基於Linux內核和這個內核的功能，比如cgroups和namespaces。 這些功能將進程分開，以便它們可以獨立運行，因為容器的目的是分別運行多個進程和應用程序。

與單獨的系統相比，這使得在不降低安全級別的情況下優化基礎設施的使用成為可能。

Docker 等所有容器工具都帶有基於映像的部署模型。 此模型簡化了跨多個環境共享應用程序或服務集。

此外，Docker 有助於在容器環境中自動部署應用程序。 通過這些不同的工具，用戶可以獲得對應用程序的完全訪問權限，並可以加速部署、控製版本和分配它們。

波德曼

Podman（POD MANager）構建、運行和管理 OCI 容器和容器鏡像。 它由 Red Hat 開發，最初用於其企業 Linux 8。它用於容器管理，是 Docker 的正式繼承者。

Red Hat 因此停止了對 Docker 的支持，但保證這種轉換對用戶來說很容易，因為 Podman 是基於 Docker 的，儘管最初它只是作為一個調試工具。

它使用 libpod 庫管理整個容器生態系統。 由於 Podman 僅適用於 Linux 平台，因此目前正在開發 REST API 和客戶端以允許 Mac 和 Windows 系統調用該服務。

然而，   目前有一個基於 Varlink 的遠程客戶端，可以在 Mac 或 Windows 平台上運行，允許與基於 Linux 的 Podman 服務器進行遠程通信。 libpod 庫支持多種安全上傳圖片的方法，包括信任和圖片驗證。

它還支持 pod 來管理容器組和多種圖像格式，包括 OCI 和 Docker 圖像格式。

在非常小且易於管理的環境中，Podman 甚至可以作為 Kubernetes 的前身。 它彌合了早年容器炒作對單個實例的單一管理與使用 Kubernetes 進行現代編排之間的差距。

雄心勃勃的容器用戶已經可以享受 pod 的下一個層次。 不再需要 Kubernetes 集群的構建和運行。 在最簡單的情況下，新設計的吊艙可以在單獨的操作中進行測試和改進。 甚至可以隨後轉移到 Kubernetes。

命令podman generate kube提供相應的配置文件。 然後，它們一對一地作為 Kubernetes 工具 kubectl 的輸入。

當前版本的 Podman 甚至可以為 systemd 創建配置文件——對於使用無處不在的 init 繼任者進行容器編排的任何人來說，這是一種享受。

Podman 與 Docker：差異

Docker 已迅速成為管理容器的木馬。 然而，Docker 有很多優點，最重要的是，快速增長的圖像庫，以及缺點和可能的安全風險。 此外，不再支持將 Docker 作為 Kubernetes 的容器。

與虛擬系統相比，容器不需要其內核這一事實通常被視為一大優勢。 但是，它給 Docker 帶來了重大的安全風險，因為 Docker 容器只能以 root 權限運行。

它允許在容器中運行的進程以 root 權限訪問內核，從而攻擊主機系統。

當您第一次使用它時，第一個區別是顯而易見的。 雖然 Docker 需要先啟動 Docker 守護進程，但可以直接從命令行啟動 Podman 容器。 所以沒有後台進程，應用程序只在需要的時候執行。

從安全角度來看，這很好，因為如果守護進程不必以超級用戶權限全天候 24/7 運行，Podman 就不太容易受到攻擊。 由於架構，Podman 不需要後台進程，這與 Docker 有根本區別。

Docker 遵循客戶端-服務器模型，其中 Docker 客戶端通過 API 與 Docker 守護進程通信，而 Podman 遵循 fork-exec 模型。 每個容器都作為 Podman 的子進程運行。

當 Podman 以普通用戶權限運行時，會在首次使用時創建用戶命名空間。 在用戶命名空間中，Podman 以 root 權限運行，具有掛載文件系統和創建容器的權限。

因此，Podman 容器僅具有執行用戶所具有的權限。 使用用戶命名空間意味著每個用戶都可以創建和管理自己的容器，但這些容器對其他用戶和超級用戶不可見。

由於 Podman 獨立於 Docker 運行，開發者有很大的迴旋餘地，可以響應社區的意願。 Podman 的有趣新增功能包括 mount/unmount 命令和 systemd 集成。

宿主機可以使用 mount/unmount 命令掛載容器的文件系統，例如訪問或更改文件，然後再次卸載它們。

由於使用 Podman 的 Docker 中的守護進程，使用 systemd 監視容器不起作用，但可以通過 systemd 啟動、監視甚至重新啟動容器。

另外，Podman 提供了podman generate systemd命令，可以為各個容器生成相應的 systemd 服務，從而免去用戶創建 systemd 服務的麻煩，也就是可以在宿主系統上進行集成。

Podman 和 Docker 之間的另一個重要區別是後者不會更改防火牆規則或當前的 dnsmasq 安裝，因為它能夠創建內部網絡。 相比之下，Docker 必須覆蓋防火牆規則才能啟用容器間通信。

什麼時候應該從 Docker 遷移到 Podman

如果您在基於 RHEL 的環境中部署容器，在這種情況下，您沒有太多選擇，只能使用 Podman，因為它是 RHEL 原生的。 如果您的部署容器很少，也可以遷移到 Podman 或選擇 Podman 而不是 Docker。

但是，如果您想變得比這更複雜，可以在網絡上擁有多個容器和一堆帶有 docker-compose/podman-compose 的協調容器。 最好使用 Docker，因為它可以更好地處理網絡。

同樣，如果您剛剛開始進入容器世界，在這種情況下，Docker 是一個更好的選擇，因為它穩定、完善且有適當的文檔，並且與 Podman 相比學習曲線較淺，Podman 仍然缺乏穩定性和沒有明確定義的文檔。

從 Podman 遷移到 Docker

如果你在命令行上，從 Docker Engine 切換到 Podman 是相當容易的。 在最簡單的情況下， $ alias docker=podman命令大部分時間都有效。

當然，這是假設系統上安裝了合適的軟件。 對於 Linux，這也不是問題。 現成的軟件包可用於商業發行版。

Windows 或 macOS 不在受支持的操作系統之列。 別名方法之所以有效，是因為許多 Docker 命令都有一個 Podman 等效命令。

但也有例外，因為一些 Docker 命令在 Podman 世界中沒有對應命令。 同樣，一些命令在 Docker 中的行為與在 Podman 世界中的行為不同。 目前，這只會影響已設置的捲的處理。

當使用 Docker Desktop 等圖形工具時，切換會有點困難。 它應該特別影響那些使用 Windows 或 macOS 的開發人員。

Docker Desktop 用戶將不得不習慣命令行，這同樣適用於 Docker compose。 但是，有 podman-compose 項目。 該軟件用 Python 編寫，可替代 Docker compose。

最後的話

Podman 對 Docker 的替代也算是大功告成了。 對於用戶和管理員來說，此更改的大多數方面都很容易。 許多 Docker 功能在 Podman 中具有相同的等價物。

真正的好處是沒有單一的守護進程和 root 權限，更不用說容器組的自然使用了。 然而，值得一提的是，Docker 仍然是容器的主要技術，但從長遠來看，這種情況很可能會發生變化。

您還可以探索一些 Docker 命令來管理容器。