- Dockerは バックグラウンドデーモン（dockerd） 構造のため、セキュリティ脆弱性とリソース消費の問題が継続的に指摘されてきた
- Podmanは デーモンレス構造 を採用しており、コンテナがユーザー権限で直接実行されるため、攻撃対象領域を減らし安定性を高める
- systemd統合、Kubernetesフレンドリーな設計、Buildah/SkopeoなどUnix哲学に基づく分離されたツール のサポートにより、運用効率が高い
- Docker CLIとの高い互換性を維持しており、
alias docker=podman だけでも既存ワークフローの大半がそのまま動作する
- 実運用環境でもセキュリティとリソース管理がシンプルになり、新規プロジェクトではPodmanが より合理的で将来性のある選択肢 になっている
Dockerの限界とセキュリティ問題
- Dockerは dockerdデーモン が常にroot権限で実行される構造を持つ
- デーモンの脆弱性が見つかると、ホスト全体が危険にさらされる可能性がある
- 主なセキュリティ問題の事例
- 2019: runCコンテナエスケープ（CVE-2019-5736）
- 2022: Linux Dirty Pipe脆弱性、cgroups v1エスケープ
- 2024: runC「Leaky Vessels」、BuildKit脆弱性
- 2024: Docker APIの露出を悪用したクリプトジャッキングキャンペーン
- こうした事件が繰り返されることで、デーモンベース構造の根本的な危険性 が明らかになった
Podmanのデーモンレス構造
- Podmanは バックグラウンドデーモンを使用しない
podman run 実行時、コンテナはコマンド実行者の 直接の子プロセス として動作する- rootlessモードで実行されるため、コンテナ内のroot権限もホスト上では一般ユーザー権限にすぎない
- 利点
- セキュリティ強化: コンテナエスケープ時の被害範囲を縮小
- 安定性の確保: 1つのコンテナが停止しても他のコンテナには影響しない
- リソース効率: 不要なデーモンが常駐しないためメモリ使用量を削減
Podmanの差別化された機能
- systemd統合
podman generate systemd でsystemdユニットファイルを自動生成- 標準の
systemctl コマンドでサービス管理が可能
- Kubernetesフレンドリー
- Podの概念が標準で組み込まれており、マルチコンテナアプリの開発がしやすい
podman generate kube でそのままKubernetes YAMLを生成できる
- Unix哲学
- Podmanはコンテナ実行に集中し、イメージビルドは Buildah、レジストリ管理は Skopeo を使用
- 目的ごとに最適化されたツールを活用できる
移行プロセスと互換性
- DockerからPodmanへの移行は ほぼ無停止
- CLIに互換性があるため、
docker の代わりに podman をそのまま使える
- 既存のDockerfileもそのまま動作する
- 相違点
- rootlessモードでは1024以下のポートをバインドできない → リバースプロキシを推奨
- ボリューム権限の管理が必要
- Dockerソケット依存ツールは、PodmanのDocker API互換モードを利用可能
実務への適用と利点
- 運用環境でPodmanを使用した結果
- セキュリティ監査の負担が軽減され、rootlessセキュリティが標準で適用される
- リソース使用パターンがよりシンプルで予測しやすくなった
- Dockerは依然として一般的だが、新しいプロジェクトや技術選定の自由度がある場合はPodmanのほうが適している
- Linux管理体系との自然な統合
- Kubernetes志向のアーキテクチャ
- より安全で合理的なコンテナ実行環境を提供
FastAPI移行ガイド要約
- 既存のDockerfileはそのまま使用可能
podman build、podman run に簡単に置き換えられるpodman generate systemd でsystemdサービスを登録- Podを活用してDBなどのマルチサービス環境をサポート
- Docker Composeワークフローは
podman-compose または kompose への変換で対応可能
8件のコメント
ここでは無停止での移行が可能だと書かれていますが、実際の運用環境では妙な点がいろいろあるんですよね。たとえば mac 環境ではデフォルト設定で zstd 圧縮を使うため、ビルドしたイメージがレジストリをかなり圧迫したりとか..
Docker も Podman も……
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
securityContext:
runAsNonRoot: true
runAsUser: UID
実際にはDocker互換性があまり良くなくて、使い勝手はそれほど良くありません…。
rootlessを考えてPodmanに移ったものの、結局Dockerに戻ってきました。
他の方の言う通り、Kubernetesで使うなら普通にcontainerdを使えばいいですね。
Docker Compose がうまく動かず、Kubernetes 互換性が高いのが利点なら、いっそ最初から Kubernetes を使えばいいのでは、という疑問が湧きますね。
私も使ってみようとしましたが、一発で動かず、1024 未満のポートマッピングも直接できないので、結局 k3s にイメージビルド用の nerdctl を組み合わせて使っています。
いつか置き換えたい気持ちはあるのですが、以前試してみたときは開発者たちが言うのとは違って、あまりにも多くの
docker composeプロジェクトがまともに動かなかったんですよね……Dockerのnetworkをサポートしてないじゃん。
Dockerと同様にネットワーク機能もサポートしていると認識していますが、
まだきちんと動かないものがあるのでしょうか？
Hacker Newsの意見
chrootとjailのコンセプトを選んだ。自分のデプロイコードがjail環境の外でソフトウェアを実行し、ptraceでプロセスが開くファイルを監視していた。この出力から依存関係リストを抽出してパッケージ化した。結果として、配布物は小さく、不変性が保たれ、セキュリティも強化された。Dockerが登場したとき、この昔のやり方を思い出したし、実際にDockerコンテナのファイル使用状況を監視して配布物を縮小するような類似ツールがあるのか気になっているgit push live masterを実行するだけでデプロイできた。Dockerもかなり使ってきたが、これが一番簡単なデプロイだった。Dockerの利点は理解しているが、UbuntuやOpenBSDでHTTP設定をするのはそれほど難しくない。Docker特有の再現性が、本当にそれだけの運用オーバーヘッドを払う価値があるのか疑問だ関連コードリンク
--connectionフラグで使いたい環境を指定すればよい。必要ならPodmanが自動でVMも作ってくれる（limaを利用）。Podman DesktopにはDocker互換レイヤーもあり、互換性の問題を緩和してくれる.debビルド配布元がない。公式の.debはなく、見つかるものもどれも古いか、今後更新しないと言っているところばかりだ。となると、なぜPodmanはインストールをもっと簡単にしないのかという疑問が残る。自分の考えでは、RedHatは競合製品のサポートに開発リソースを割きたくないのだろう。もっともな話ではあるが、RedHatエコシステム外では二級市民のように扱われている印象がある.debが継続的に提供されない点が、社内でPodmanを使えない理由になっている。Dockerは公式の.debリポジトリがきちんと管理されているので、うらやましく感じるpodman generate systemdコマンドは、今ではdeprecatedだ。代替としてPodman Quadletsがあり、これはsystemd unitファイルの中に定義するdocker-compose.yamlのような方式だignore_chown_errorsオプションを使えば、rootをユーザーIDにマッピングするときに、追加のマッピングなしで比較的簡単に適用できる/devだけをマウントして、ごく限定的なプログラムを隔離されたネットワークで公開するほうが簡単だこちら、
こちら、
こちら で確認できる