當您踏入虛擬化和容器化的領域時，您可能會遇到 Podman 和 Docker 這兩個工具，並好奇它們之間究竟有什麼差異。
在這篇文章中，我們將深入探討 Docker 和 Podman 的不同之處，並嘗試找出哪一個選項最適合您的需求！
Docker
Docker 是一種容器化技術，它能夠簡化專案中各個層級（從開發到部署）的依賴項管理。
Docker 可在 Linux、Windows 和 Mac OS 上運行，其核心機制圍繞著容器及其編排，這也是容器化與傳統虛擬化的根本區別。
Docker 主要由兩個核心組件構成：Docker CLI 和 Docker Daemon。
Docker 守護進程：
這是一個持續在後台運行的進程，負責管理 Docker 映像、容器、網路和儲存卷。 Docker 使用其 Docker Engine REST API，透過 HTTP 協議與 Docker 守護進程互動。
Docker 命令行介面：
圖片來源：Redhat
這是用於與 Docker 守護進程互動的 Docker 命令行客戶端。當您執行任何 Docker 命令時，實際上就是在使用它。
Docker 的運作基於 Linux 核心及其提供的功能，例如 cgroups 和 namespaces。這些功能將進程隔離，使其能夠獨立運行，因為容器的主要目的是分別執行多個進程和應用程式。
與獨立的系統相比，這種方式能夠在不降低安全性的前提下，更有效地利用基礎設施。
所有容器工具，包括 Docker，都採用基於映像的部署模型。此模型簡化了跨多個環境共享應用程式或服務集合的過程。
此外，Docker 有助於在容器環境中自動部署應用程式。透過這些工具，使用者可以完全控制應用程式，並加速部署、版本管理和分配。
Podman
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 集群。在最簡單的情況下，新設計的 pod 可以單獨進行測試和改進。甚至可以隨後遷移到 Kubernetes。
命令 `podman generate kube` 提供了相應的配置檔案。然後，它們可以作為 Kubernetes 工具 kubectl 的輸入。
當前版本的 Podman 甚至可以為 systemd 建立配置檔案——對於任何使用無處不在的 init 替代方案來進行容器編排的使用者來說，這無疑是一大福音。
Podman 與 Docker：差異
Docker 已經迅速成為管理容器的標準工具。然而，Docker 雖然擁有諸多優點，例如龐大的映像庫，但也存在一些缺點和潛在的安全風險。此外，Docker 已不再被支援作為 Kubernetes 的容器運行時。
與虛擬系統相比，容器不需要其自身的作業系統核心這一事實通常被認為是一大優勢。但是，這也給 Docker 帶來了嚴重的安全風險，因為 Docker 容器只能以 root 權限運行。
這使得在容器中運行的進程能夠以 root 權限存取核心，進而可能攻擊主機系統。
當您初次使用 Podman 時，最明顯的區別在於：雖然 Docker 需要先啟動 Docker 守護進程，但您可以直接從命令行啟動 Podman 容器。因此，沒有後台進程，應用程式僅在需要時才執行。
從安全角度來看，這是一個優勢，因為如果守護進程不需要以超級使用者權限 24 小時全天候運行，Podman 就不太容易受到攻擊。由於其架構，Podman 不需要後台進程，這與 Docker 有著根本上的區別。
Docker 遵循客戶端-伺服器模型，其中 Docker 客戶端透過 API 與 Docker 守護進程進行通訊，而 Podman 則遵循 fork-exec 模型。每個容器都作為 Podman 的子進程運行。
當 Podman 以普通使用者權限運行時，它會在第一次使用時建立使用者命名空間。在使用者命名空間中，Podman 以 root 權限運行，具有掛載檔案系統和建立容器的權限。
因此，Podman 容器只具有執行使用者所擁有的權限。使用使用者命名空間意味著每個使用者都可以建立和管理自己的容器，但這些容器對其他使用者和超級使用者不可見。
由於 Podman 獨立於 Docker 運行，開發人員擁有很大的靈活性，可以響應社群的需求。 Podman 的一些有趣的新功能包括 mount/unmount 命令和 systemd 集成。
主機可以使用 mount/unmount 命令來掛載容器的檔案系統，例如存取或修改檔案，然後再次卸載它們。
由於 Docker 中使用了守護進程，因此使用 systemd 監視容器在 Docker 中不起作用，但在 Podman 中，您可以透過 systemd 啟動、監視甚至重新啟動容器。
另外，Podman 還提供了 `podman generate systemd` 命令，可以為各個容器產生相應的 systemd 服務檔案，從而免除了使用者建立 systemd 服務的麻煩，也就是可以在主機系統上進行集成。
Podman 和 Docker 之間的另一個重要區別是，後者不會更改防火牆規則或當前的 dnsmasq 設定，因為它能夠建立內部網路。相比之下，Docker 必須覆寫防火牆規則才能啟用容器之間的通訊。
| Podman | Docker | |
| 架構 | 無守護進程 | 守護進程 |
| 服務管理 | systemd | Docker 引擎 |
| 防火牆相容性 | 遵循防火牆規則 | 覆寫防火牆規則 |
| 平台 | 原生支援 Linux | Linux、Windows 和 Mac |
何時應該從 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 命令來管理容器。