Podman 容器技術遷移:從 Docker 到無 Daemon 架構的平滑轉換

前言

容器技術的發展歷程中,Docker 無疑是最具影響力的里程碑。自 2013 年問世以來,Docker 以其簡潔的操作介面與強大的容器管理能力,迅速成為開發者建構與部署應用程式的首選工具。然而,隨著容器技術的成熟與雲端原生架構的演進,業界對於容器引擎的需求也逐漸產生變化。安全性、輕量化、標準化成為新的關注焦點,而這正是 Podman 誕生的背景。

Podman 的全名是 Pod Manager,由 Red Hat 主導開發,是一個完全開源的容器引擎。與 Docker 最根本的差異在於架構設計:Docker 採用 Client-Server 架構,所有容器操作都必須透過一個以 root 權限執行的 Daemon 程序來處理,這種集中式管理雖然帶來便利性,但也引入了潛在的安全風險與單點故障問題。相對的,Podman 採用無 Daemon 架構,直接透過 fork-exec 模型啟動容器,每個容器都是獨立的子程序,不需要常駐的背景服務,這種設計大幅降低了攻擊面,同時也支援以非 root 使用者執行容器,實現真正的 Rootless 容器部署。

對於已經在生產環境大量使用 Docker 的團隊而言,遷移到新的容器引擎是一個需要謹慎評估的決策。幸運的是,Podman 在設計時就充分考慮了與 Docker 的相容性。Podman 的命令列介面幾乎完全模仿 Docker,絕大多數的 Docker 指令都能直接在 Podman 上執行,這種高度相容性大幅降低了遷移的複雜度與風險。開發者不需要重新學習全新的指令集,也不需要大規模修改既有的部署腳本或自動化流程。

然而,相容性並不代表完全相同。由於底層架構的差異,Podman 在某些指令的行為上做出了調整,這些調整往往是為了修正 Docker 在設計上的不一致性,或是為了符合 OCI 標準的規範。理解這些差異對於成功遷移至關重要,能夠避免在實際部署時遇到意料之外的問題。同時,掌握容器的轉移策略、資料持久化的處理方式,以及如何驗證遷移後的系統行為,都是確保平滑過渡的關鍵要素。

本文將深入探討從 Docker 遷移到 Podman 的完整流程,從最基礎的命令別名設定,到進階的容器轉移策略與架構差異分析。我們會透過實際的範例操作,展示如何驗證 Podman 的相容性,如何處理既有容器的轉移,以及如何理解兩個平台在指令行為上的細微差異。透過這些知識,您將能夠評估 Podman 是否適合您的使用場景,並在決定遷移後,掌握執行平滑轉換所需的所有技術細節。

Podman 架構優勢與設計理念

在深入遷移技巧之前,我們需要先理解 Podman 為何值得投資時間與精力來進行轉換。Podman 的核心設計理念圍繞著三個主要目標:安全性、簡潔性與標準化。這三個目標在架構層面的實現,構成了 Podman 相較於 Docker 的獨特優勢。

Docker 的 Client-Server 架構是其早期成功的關鍵因素之一。透過一個集中式的 Daemon 程序,Docker 能夠統一管理所有容器的生命週期,提供一致的操作介面,並支援遠端管理功能。然而,這種架構也帶來了幾個顯著的問題。首先是安全性議題,Docker Daemon 必須以 root 權限執行才能管理容器,這意味著任何能夠存取 Docker Socket 的使用者,實際上都擁有了系統的 root 權限。即使 Docker 後來引入了使用者命名空間等安全機制,但 Daemon 本身以 root 權限執行的事實並未改變,這在安全稽核時經常被視為潛在風險。

其次是單點故障問題。由於所有容器都由 Daemon 管理,一旦 Daemon 因為任何原因當機或需要重啟,所有正在執行的容器都可能受到影響。雖然 Docker 實作了 live-restore 功能來緩解這個問題,但這終究是一個需要額外處理的複雜性。最後是資源消耗,即使系統中沒有執行任何容器,Docker Daemon 仍然持續佔用記憶體與 CPU 資源,在資源受限的環境中,這種開銷可能成為明顯的負擔。

Podman 透過完全不同的架構設計解決了這些問題。Podman 不使用 Daemon,而是採用 fork-exec 模型直接啟動容器。當使用者執行 podman run 指令時,Podman 會 fork 出一個新的程序,然後在這個程序中設定好容器的命名空間、cgroups 等隔離機制後,exec 執行容器的主程序。這種方式讓每個容器都是獨立的程序樹,彼此之間沒有共同的父程序,自然也就不存在單點故障的問題。

在安全性方面,Podman 從一開始就支援 Rootless 模式。一般使用者可以在完全不需要 root 權限的情況下,建立與管理自己的容器。這是透過 Linux 的使用者命名空間與 subordinate UID/GID 機制實現的,每個使用者在自己的命名空間中擁有完整的容器管理能力,但這些權限被嚴格限制在命名空間內部,無法影響主機系統或其他使用者的程序。這種設計在多租戶環境或共享開發伺服器上特別有價值。

Podman 對 OCI 標準的支援也是其重要特色。OCI 定義了容器映像檔與容器執行時的標準規範,確保不同容器引擎之間的互通性。Podman 完全遵循 OCI 標準,這意味著 Podman 建立的容器映像檔可以在任何符合 OCI 標準的執行環境中運行,反之亦然。這種標準化消除了廠商鎖定的風險,讓組織在選擇容器技術時擁有更大的彈性。

以下的架構對比圖展示了 Docker 與 Podman 在程序模型上的根本差異:

@startuml
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

package "Docker 架構" {
  actor "使用者" as USER1
  [Docker CLI] as CLI1
  [Docker Daemon\n(root 權限)] as DAEMON
  [容器 A] as CONT1A
  [容器 B] as CONT1B
  [容器 C] as CONT1C
  
  USER1 --> CLI1 : 執行指令
  CLI1 --> DAEMON : Socket 通訊
  DAEMON --> CONT1A : 管理
  DAEMON --> CONT1B : 管理
  DAEMON --> CONT1C : 管理
}

package "Podman 架構" {
  actor "使用者" as USER2
  [Podman CLI] as CLI2
  [容器 X] as CONT2A
  [容器 Y] as CONT2B
  [容器 Z] as CONT2C
  
  USER2 --> CLI2 : 執行指令
  CLI2 --> CONT2A : 直接 fork-exec
  CLI2 --> CONT2B : 直接 fork-exec
  CLI2 --> CONT2C : 直接 fork-exec
}

note right of DAEMON
  集中式管理
  需要 root 權限
  單點故障風險
  持續佔用資源
end note

note right of CLI2
  無 Daemon 設計
  支援 Rootless
  程序獨立執行
  無額外開銷
end note

@enduml

這個架構圖清楚呈現了兩種設計的本質差異。在 Docker 架構中,所有容器都透過 Daemon 這個中央管理程序來啟動與監控,使用者的指令必須經過 CLI 與 Daemon 之間的 Socket 通訊才能執行。相對的,Podman 架構中不存在這個中間層,CLI 直接負責啟動容器程序,每個容器都是獨立的程序樹,與其他容器沒有直接的依賴關係。

理解這些架構差異後,我們可以更清楚地認知到遷移到 Podman 所帶來的實際價值。對於重視安全性的環境,Rootless 容器能夠顯著降低風險。對於需要高可靠性的系統,消除單點故障能夠提升整體穩定性。對於資源受限的場景,無 Daemon 設計能夠減少不必要的資源消耗。這些優勢構成了投資遷移工作的強大動機。

命令列相容性與別名設定

Podman 在設計命令列介面時,刻意保持與 Docker 的高度相似性。這種設計決策大幅降低了使用者的學習曲線,讓熟悉 Docker 的開發者能夠幾乎無縫地切換到 Podman。絕大多數的 Docker 指令都能直接在 Podman 上執行,只需要將指令開頭的 docker 替換為 podman 即可。

為了進一步簡化轉換過程,我們可以透過設定 shell 的命令別名,讓系統在執行 docker 指令時自動調用 podman。這種方式讓我們能夠繼續使用既有的腳本與工作流程,而不需要逐一修改每個指令。在 Bash 或 Zsh 等常見的 shell 中,設定別名的方式非常簡單:

# 設定 docker 命令別名為 podman
alias docker=podman

# 驗證別名設定
which docker

# 測試別名是否正常運作
docker --version

執行這個別名設定後,當我們輸入 docker 指令時,shell 會自動將其替換為 podman 並執行。這種轉換對使用者來說是完全透明的,我們可以繼續使用熟悉的 docker run、docker build、docker ps 等指令,而實際上背後運行的是 Podman 的實作。

為了讓這個別名設定永久生效,我們需要將它加入到 shell 的配置檔中。根據使用的 shell 不同,配置檔的路徑也會有所差異:

# 對於 Bash shell,將別名加入到 ~/.bashrc
echo "alias docker=podman" >> ~/.bashrc

# 重新載入配置檔使設定生效
source ~/.bashrc

# 對於 Zsh shell,將別名加入到 ~/.zshrc  
echo "alias docker=podman" >> ~/.zshrc

# 重新載入配置檔
source ~/.zshrc

加入到配置檔後,每次開啟新的 terminal 視窗時,這個別名都會自動載入,不需要手動重新設定。這種配置方式在日常開發工作中特別方便,讓我們能夠在 Podman 與既有的 Docker 工作流程之間平滑切換。

讓我們透過一個實際的範例來驗證別名的運作。我們將執行一個有趣的容器應用 nyancat,這是一個在 terminal 中顯示彩虹貓動畫的小程式:

# 使用 docker 別名執行 nyancat 容器
# --rm 參數表示容器結束後自動刪除
# -it 參數提供互動式 terminal
docker run --rm -it docker.io/wernight/funbox nyancat

當這個指令執行時,Podman 會從 Docker Hub 拉取 wernight/funbox 映像檔,然後在容器中執行 nyancat 程式。如果一切正常,我們會在 terminal 中看到彩虹貓的動畫。這個簡單的測試驗證了幾個關鍵功能:命令別名正常運作、Podman 能夠從 Docker Hub 拉取映像檔、容器能夠正常執行並提供互動式介面。

需要注意的是,雖然別名提供了便利性,但在某些情況下可能會造成混淆。例如,當系統中同時安裝了 Docker 與 Podman 時,使用別名可能會讓我們不確定實際執行的是哪個工具。在這種情況下,建議明確使用完整的指令名稱,避免產生歧義。同時,在撰寫部署文件或教學材料時,也應該明確說明使用的是 Docker 還是 Podman,避免讀者產生困惑。

另一個值得考慮的是 docker-compose 的處理。雖然 Podman 能夠透過相容性層執行 docker-compose 指令,但在某些環境中,我們可能需要額外的設定。Podman 提供了一個 socket 服務,能夠模擬 Docker 的 socket 介面,讓 docker-compose 能夠透過這個 socket 與 Podman 通訊:

# 啟用 Podman socket 服務
systemctl --user enable --now podman.socket

# 設定環境變數指向 Podman socket
export DOCKER_HOST=unix:///run/user/$UID/podman/podman.sock

# 驗證 docker-compose 能否正常運作
docker-compose version

透過這些設定,docker-compose 能夠透過 Podman 的 socket 介面來管理容器,實現與 Docker 類似的多容器編排功能。這種相容性設計讓我們能夠繼續使用既有的 docker-compose.yml 配置檔,不需要進行大規模的修改。

相容性驗證:執行 Docker 官方教學

為了更全面地驗證 Podman 的相容性,我們可以嘗試執行 Docker 官方提供的 Getting Started 教學容器。這個教學容器包含了一個完整的 Web 應用程式,涵蓋了容器的常見使用場景,如埠號對應、資料持久化、多容器應用等。如果 Podman 能夠順利執行這個教學,就證明了它在實際應用中具有良好的 Docker 相容性。

執行 Getting Started 教學容器的指令非常簡單:

# 使用 Podman 執行 Docker 官方教學容器
# -d 參數讓容器在背景執行
# -p 80:80 將主機的 80 埠對應到容器的 80 埠
docker run -d -p 80:80 docker.io/docker/getting-started

這個指令會從 Docker Hub 拉取 docker/getting-started 映像檔,並在背景啟動容器。容器內執行著一個 Web 伺服器,透過埠號對應,我們可以在主機的瀏覽器中存取這個應用程式。

執行指令後,Podman 會顯示容器的相關資訊:

Trying to pull docker.io/docker/getting-started:latest...
Getting image source signatures
Copying blob 540db60ca938 done  
Copying blob 8f6d69d83a89 done  
Copying blob adfa0e8b7e2c done  
Copying blob e39c43b65229 done  
Copying blob c6c0a525d44d done  
Copying blob 188e6b5e3bb3 done  
Copying config 3e4394f6b72f done  
Writing manifest to image destination
Storing signatures
3e4394f6b72fa1b81e0f3c0a9e5c8d2a8b9e7c6d5e4f3a2b1c0d9e8f7a6b5c4d

這些輸出顯示了映像檔拉取的詳細過程。Podman 從 Docker Hub 下載映像檔的各個層,驗證簽章,然後將映像檔儲存到本地。最後一行的長字串是容器的 ID,我們可以用這個 ID 來管理容器。

現在,讓我們檢視容器是否正常執行:

# 列出所有執行中的容器
docker ps

輸出結果會顯示容器的詳細資訊:

CONTAINER ID  IMAGE                                    COMMAND               CREATED        STATUS        PORTS                 NAMES
3e4394f6b72f  docker.io/docker/getting-started:latest  /docker-entrypoint... 30 seconds ago Up 30 seconds 0.0.0.0:80->80/tcp    gallant_hopper

從這個輸出中,我們可以確認容器已成功啟動,並且埠號對應設定正常運作。PORTS 欄位顯示 0.0.0.0:80->80/tcp,表示主機的 80 埠已經對應到容器的 80 埠,我們可以透過瀏覽器存取這個應用程式。

開啟瀏覽器,輸入 http://localhost,如果一切正常,我們會看到 Docker Getting Started 教學的歡迎頁面。這個頁面包含了互動式的教學內容,引導使用者學習容器的基本操作。能夠成功顯示這個頁面,證明了 Podman 不僅能夠執行容器,還能正確處理網路配置、檔案系統掛載等複雜功能。

我們可以進一步測試容器的互動功能。嘗試在教學頁面中完成一些基本操作,如建立待辦事項、刪除項目等。這些操作會透過 HTTP 請求與容器內的應用程式互動,涉及到資料的讀寫與處理。如果所有功能都能正常運作,就表示 Podman 在實際應用場景中具有良好的相容性。

完成測試後,我們可以停止並移除容器:

# 停止容器
docker stop 3e4394f6b72f

# 移除容器
docker rm 3e4394f6b72f

# 或是直接使用 -f 參數強制移除執行中的容器
docker rm -f 3e4394f6b72f

這個驗證過程展示了 Podman 在實際應用中的相容性表現。能夠順利執行 Docker 官方的教學容器,意味著 Podman 在處理真實世界的容器應用時,具有與 Docker 相當的能力。這為我們遷移既有的容器化應用提供了信心。

容器轉移策略與實務操作

當我們決定從 Docker 遷移到 Podman 後,一個關鍵問題是如何處理既有的容器。雖然容器本身設計為暫時性的執行環境,但在實務上,許多容器包含了重要的配置資訊或狀態資料,需要妥善處理轉移過程,避免資料遺失或服務中斷。

不幸的是,目前沒有官方的工具能夠直接將 Docker 容器轉換為 Podman 容器。這主要是因為 Docker 與 Podman 在底層儲存格式與執行時配置上存在差異,直接轉換可能導致不可預期的問題。然而,我們可以透過幾種策略來實現容器的遷移,每種策略適用於不同的場景。

第一種策略是重新建立容器,這是最推薦也最穩健的方式。容器的設計理念強調不可變基礎設施,容器本身應該是可以隨時丟棄與重建的。真正需要持久化的資料應該儲存在資料卷中,而不是容器的檔案系統裡。基於這個原則,我們可以使用 Podman 重新建立容器,並掛載相同的資料卷,達到無縫轉移的效果。

以一個執行 PostgreSQL 資料庫的容器為例,原本的 Docker 指令可能是:

# Docker 建立 PostgreSQL 容器
docker run -d \
  --name postgres-db \
  -e POSTGRES_PASSWORD=secure_password \
  -v postgres-data:/var/lib/postgresql/data \
  -p 5432:5432 \
  postgres:15

要遷移到 Podman,我們只需要使用幾乎相同的指令:

# Podman 建立 PostgreSQL 容器
podman run -d \
  --name postgres-db \
  -e POSTGRES_PASSWORD=secure_password \
  -v postgres-data:/var/lib/postgresql/data \
  -p 5432:5432 \
  docker.io/library/postgres:15

關鍵在於資料卷 postgres-data 的處理。如果我們使用具名資料卷,資料實際儲存在 Docker 管理的目錄中,通常是 /var/lib/docker/volumes/。要將這些資料轉移到 Podman,我們需要先找到資料的實際位置:

# 檢視 Docker 資料卷的詳細資訊
docker volume inspect postgres-data

輸出會顯示資料卷的掛載點:

[
    {
        "CreatedAt": "2025-11-24T10:30:00+08:00",
        "Driver": "local",
        "Labels": {},
        "Mountpoint": "/var/lib/docker/volumes/postgres-data/_data",
        "Name": "postgres-data",
        "Options": {},
        "Scope": "local"
    }
]

從 Mountpoint 欄位,我們可以找到資料的實際路徑。接著,我們可以將這些資料複製到 Podman 的資料卷中:

# 建立 Podman 資料卷
podman volume create postgres-data

# 檢視 Podman 資料卷的掛載點
podman volume inspect postgres-data

# 複製資料從 Docker 到 Podman
# 假設 Podman 資料卷的掛載點是 /var/lib/containers/storage/volumes/postgres-data/_data
sudo cp -a /var/lib/docker/volumes/postgres-data/_data/* \
  /var/lib/containers/storage/volumes/postgres-data/_data/

複製完成後,我們可以啟動 Podman 容器,資料就會被正確載入。這種方式確保了資料的完整性,同時也讓容器配置保持乾淨與一致。

第二種策略是使用容器匯出與匯入功能。Docker 提供了 export 與 import 指令,能夠將容器的檔案系統匯出為 TAR 檔案,然後再匯入到其他環境。這種方式適用於需要遷移容器內部檔案的場景,但需要注意的是,匯出的檔案系統不包含容器的執行時配置,如環境變數、埠號對應等,這些配置需要在匯入後重新設定。

以下是使用匯出與匯入進行遷移的完整流程:

# 步驟 1: 使用 Docker 匯出容器檔案系統
# 將容器的檔案系統匯出為 TAR 檔案
docker export postgres-db > postgres-container.tar

# 步驟 2: 使用 Podman 匯入檔案系統建立映像檔
# 從 TAR 檔案建立新的容器映像檔
podman import postgres-container.tar postgres-migrated:latest

# 步驟 3: 使用匯入的映像檔啟動容器
# 需要重新設定所有執行時參數
podman run -d \
  --name postgres-db \
  -e POSTGRES_PASSWORD=secure_password \
  -v postgres-data:/var/lib/postgresql/data \
  -p 5432:5432 \
  postgres-migrated:latest \
  postgres

這個流程中有幾個需要注意的地方。首先,匯出的 TAR 檔案可能非常大,特別是對於包含大量資料的容器。其次,匯入建立的映像檔不包含原始映像檔的元資料,如 ENTRYPOINT、CMD 等,我們需要在啟動容器時手動指定這些參數。最後,這種方式建立的映像檔沒有層級結構,所有內容都在單一層中,可能影響儲存效率。

第三種策略是使用容器映像檔進行遷移。如果容器是從公開的映像檔倉庫拉取的,我們可以直接在 Podman 中拉取相同的映像檔,然後重新建立容器。這種方式最為簡潔,因為映像檔本身就是標準化的,Docker 與 Podman 都能正確處理符合 OCI 標準的映像檔。

對於自訂建置的映像檔,我們可以透過映像檔倉庫來進行轉移:

# 步驟 1: 將 Docker 建置的映像檔推送到倉庫
docker tag my-custom-app:latest registry.example.com/my-custom-app:latest
docker push registry.example.com/my-custom-app:latest

# 步驟 2: 使用 Podman 從倉庫拉取映像檔
podman pull registry.example.com/my-custom-app:latest

# 步驟 3: 使用 Podman 啟動容器
podman run -d \
  --name my-app \
  -p 8080:8080 \
  registry.example.com/my-custom-app:latest

這種方式的優點是完全遵循容器的最佳實踐,映像檔在倉庫中進行版本管理,容器可以隨時重建。缺點是需要有可用的映像檔倉庫,對於本地開發環境可能需要額外設定私有倉庫。

以下的流程圖展示了三種轉移策略的選擇邏輯:

@startuml
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

start

:需要遷移 Docker 容器到 Podman;

if (容器使用\n具名資料卷?) then (是)
  :複製資料卷內容\n從 Docker 到 Podman;
  :使用 Podman 重新建立容器\n並掛載資料卷;
else (否)
  if (映像檔來自\n公開倉庫?) then (是)
    :使用 Podman 拉取\n相同映像檔;
    :重新建立容器;
  else (否)
    if (需要保留\n容器內檔案?) then (是)
      :使用 docker export\n匯出容器檔案系統;
      :使用 podman import\n建立新映像檔;
      :啟動容器並\n重新設定參數;
    else (否)
      :重新建置映像檔;
      :推送到映像檔倉庫;
      :使用 Podman 拉取並執行;
    endif
  endif
endif

:驗證容器功能;

stop

@enduml

這個流程圖提供了一個決策樹,協助我們根據實際情況選擇最適合的遷移策略。在實務上,建議優先考慮重新建立容器的方式,因為這最符合容器不可變基礎設施的理念,也最容易確保遷移後的系統行為與預期一致。

Docker 與 Podman 的指令行為差異分析

雖然 Podman 在設計時極力保持與 Docker 的相容性,但由於底層架構的差異,以及 Podman 團隊對某些 Docker 行為的改進,兩者在一些指令的具體行為上仍存在差異。理解這些差異對於成功遷移至關重要,能夠避免在實際部署時遇到意料之外的問題。

第一個顯著差異出現在資料卷的建立行為上。Docker 的 volume create 指令在資料卷已存在時會默默跳過,不會報錯也不會有任何提示。這種行為在某些情況下很方便,但也可能掩蓋配置錯誤。Podman 則選擇了更嚴格的做法,當嘗試建立已存在的資料卷時會回報錯誤:

# Docker 的行為
docker volume create my-volume
# 輸出: my-volume

docker volume create my-volume
# 再次執行,沒有錯誤,默默跳過
# 輸出: my-volume

# Podman 的行為
podman volume create my-volume
# 輸出: my-volume

podman volume create my-volume
# 再次執行,會回報錯誤
# Error: volume my-volume already exists

這個差異的設計理念在於提高可預測性。Podman 認為,如果使用者嘗試建立一個已存在的資源,很可能是腳本邏輯錯誤或配置不一致,應該明確回報錯誤讓使用者知道,而不是默默跳過可能掩蓋問題。在撰寫自動化腳本時,我們需要處理這種差異,可以先檢查資料卷是否存在再決定是否建立:

# 相容 Podman 的資料卷建立腳本
if ! podman volume inspect my-volume &> /dev/null; then
  # 資料卷不存在,建立新的
  podman volume create my-volume
else
  # 資料卷已存在,顯示訊息
  echo "資料卷 my-volume 已存在,跳過建立"
fi

第二個重要差異是在使用 run -v 參數掛載主機目錄時的行為。Docker 在掛載主機目錄時,如果來源路徑不存在,會自動建立該目錄。Podman 則認為這種自動建立行為可能導致權限問題或不預期的目錄結構,因此選擇在來源路徑不存在時直接回報錯誤:

# Docker 的行為
docker run -v /tmp/noexist:/data alpine ls /data
# 如果 /tmp/noexist 不存在,Docker 會自動建立
# 容器正常執行

# Podman 的行為  
podman run -v /tmp/noexist:/data alpine ls /data
# 如果 /tmp/noexist 不存在,Podman 回報錯誤
# Error: statfs /tmp/noexist: no such file or directory

這個差異反映了不同的設計哲學。Docker 傾向於提供便利性,自動處理一些邊緣情況。Podman 則更重視明確性與可預測性,要求使用者明確建立所需的目錄,避免因為自動化行為導致的權限或配置問題。在實務上,建議在執行容器前先確認掛載點是否存在:

# 確保掛載點目錄存在
mkdir -p /tmp/mydata

# 再執行容器掛載
podman run -v /tmp/mydata:/data alpine ls /data

第三個值得注意的差異是在網路模式的預設行為上。Docker 預設使用橋接網路模式,所有容器都連接到一個共享的橋接網路,能夠相互通訊。Podman 在 Rootless 模式下預設使用 slirp4netns 網路,這是一個使用者空間的網路實作,提供更好的安全隔離,但效能相對較低。如果需要容器間通訊,建議明確建立自訂網路:

# 建立自訂橋接網路
podman network create my-network

# 在網路中啟動容器
podman run -d --name db --network my-network postgres:15
podman run -d --name web --network my-network nginx:latest

第四個差異涉及特權容器的處理。Docker 的 –privileged 參數會給予容器幾乎完整的主機權限,這在某些需要存取硬體設備的場景中很有用,但也帶來顯著的安全風險。Podman 在 Rootless 模式下不支援完整的特權容器,因為一般使用者本身就沒有這些權限。如果真的需要特權容器,必須使用 root 權限執行 Podman,或是尋找替代方案,如使用 –device 參數掛載特定設備而非給予完整權限。

以下表格整理了主要的指令行為差異:

@startuml
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 150

skinparam class {
  BackgroundColor white
  BorderColor black
}

class "資料卷建立" as VOL {
  **Docker 行為**
  已存在時默默跳過
  不回報錯誤訊息
  --
  **Podman 行為**
  已存在時回報錯誤
  提示資源已存在
}

class "主機目錄掛載" as MOUNT {
  **Docker 行為**
  來源不存在時自動建立
  以 root 權限建立目錄
  --
  **Podman 行為**
  來源不存在時回報錯誤
  要求明確建立目錄
}

class "預設網路模式" as NET {
  **Docker 行為**
  預設使用橋接網路
  容器可相互通訊
  --
  **Podman 行為**
  Rootless 使用 slirp4netns
  需明確建立網路
}

class "特權容器" as PRIV {
  **Docker 行為**
  完整支援特權模式
  可能帶來安全風險
  --
  **Podman 行為**
  Rootless 不支援
  建議使用替代方案
}

@enduml

這些差異雖然在日常使用中可能不常遇到,但在特定場景下可能造成困擾。建議在遷移前仔細測試關鍵的容器操作,確保所有功能都能在 Podman 環境中正常運作。同時,在撰寫自動化腳本或部署文件時,也應該考慮這些差異,提供相應的處理邏輯或說明。

實務建議與最佳實踐

在完成從 Docker 到 Podman 的遷移後,有幾個實務建議能夠幫助我們更好地運用 Podman 的特性,並避免常見的陷阱。

首先是善用 Rootless 模式。這是 Podman 相較於 Docker 最顯著的優勢之一,能夠在不需要 root 權限的情況下管理容器。在開發環境或多使用者的共享伺服器上,Rootless 模式提供了更好的安全隔離。然而,需要注意的是,Rootless 模式在網路與檔案系統權限上有一些限制,例如無法綁定 1024 以下的特權埠號。如果應用程式需要使用這些埠號,可以透過埠號轉發或調整應用程式配置來解決。

其次是充分利用 Pod 的概念。Podman 原生支援 Kubernetes 的 Pod 概念,允許將多個容器組織在一個 Pod 中,共享網路命名空間與其他資源。這種組織方式在本地開發時特別有用,能夠模擬 Kubernetes 的部署結構:

# 建立一個 Pod
podman pod create --name my-app -p 8080:80

# 在 Pod 中啟動 Web 容器
podman run -d --pod my-app nginx:latest

# 在同一個 Pod 中啟動側車容器
podman run -d --pod my-app busybox \
  sh -c 'while true; do echo "$(date) - Health check"; sleep 60; done'

在這個範例中,Web 容器與側車容器共享網路命名空間,可以透過 localhost 相互通訊,這種模式與 Kubernetes 的行為一致,有助於在本地開發時驗證部署配置。

第三是善用 Podman 的 systemd 整合。Podman 能夠產生 systemd unit 檔案,讓容器作為系統服務執行,享有 systemd 的管理功能,如自動重啟、日誌管理等:

# 啟動一個容器
podman run -d --name web-service -p 8080:80 nginx:latest

# 產生 systemd unit 檔案
podman generate systemd --new --files --name web-service

# 移動 unit 檔案到 systemd 目錄
mkdir -p ~/.config/systemd/user/
mv container-web-service.service ~/.config/systemd/user/

# 啟用服務
systemctl --user enable container-web-service.service
systemctl --user start container-web-service.service

透過這種方式,容器會在系統啟動時自動執行,並在異常終止時自動重啟,提供了類似生產環境的可靠性。

第四是注意映像檔來源的完整性。Podman 要求明確指定映像檔的完整路徑,包含 registry 網域名稱,這雖然增加了指令的長度,但提升了安全性,避免從非預期的來源拉取映像檔。建議在配置檔中明確定義常用的 registry,或使用完整的映像檔路徑。

最後是定期清理未使用的資源。容器、映像檔與資料卷會逐漸累積,佔用磁碟空間。Podman 提供了便利的清理指令:

# 移除所有停止的容器
podman container prune

# 移除所有未使用的映像檔
podman image prune -a

# 移除所有未使用的資料卷
podman volume prune

# 一次清理所有未使用的資源
podman system prune -a --volumes

定期執行這些清理指令能夠保持系統的整潔,避免磁碟空間不足的問題。

結論

從 Docker 遷移到 Podman 是一個值得投資的過程,特別是對於重視安全性、追求輕量化或希望擁抱開放標準的團隊。Podman 透過無 Daemon 架構消除了單點故障風險,透過 Rootless 模式提升了安全性,透過完整的 OCI 標準支援確保了互通性。這些優勢使 Podman 成為容器技術的重要選擇。

遷移過程的關鍵在於理解兩個平台的差異,而非盲目替換。透過命令別名,我們能夠快速驗證 Podman 的相容性,並在既有工作流程中逐步引入 Podman。透過適當的容器轉移策略,我們能夠妥善處理既有容器的遷移,確保資料的完整性與服務的連續性。透過掌握指令行為的差異,我們能夠避免常見的陷阱,編寫出在兩個平台上都能穩定運作的自動化腳本。

Podman 的發展持續進步,社群活躍且功能不斷增強。無論是選擇完全遷移到 Podman,或是在不同場景中混合使用 Docker 與 Podman,理解兩者的特性與差異都能幫助我們做出更明智的技術決策。希望本文提供的知識與經驗,能夠協助您在容器技術的選擇與應用上,找到最適合自己需求的解決方案。