MENU

Podman — デーモンレスでDocker互換を実現したコンテナエンジン

Podman アイキャッチ
Podman

Podman(ポッドマン)は、コンテナとPodを操作するためのオープンソースのコンテナエンジンです。Red Hatが2018年に「libpod」プロジェクトとして発表し、2019年1月にPodman 1.0がリリースされました。最大の特徴は、Docker Engineのような常駐デーモンを必要としない「デーモンレス」設計と、コマンドラインがdockerとほぼ互換である点です。Red Hat Enterprise Linux 8(2019年)以降ではDocker Engineの代替として既定採用され、Fedora、CentOS Stream、macOS/Windows向けPodman Desktopにも提供されています。

目次

この記事の目次

  1. デーモンレス・rootless・Pod対応
  2. libpodからPodman 4.xまで
  3. Dockerからの移行手順
  4. Docker Engineとの比較
  5. まとめ

デーモンレス・rootless・Pod対応

デーモンレス・rootless・Pod対応

Podmanの設計を特徴づけるのは、デーモンレス、rootless、Pod対応の3点です。Docker Engineがdockerdという常駐プロセスを必要とするのに対し、Podmanはpodmanコマンド実行時にforkで子プロセスを生成して直接コンテナを起動します。「中央デーモンが死ぬとすべてのコンテナが影響を受ける」という単一障害点が無いため、システムサービスとしての堅牢性が高く、systemdとの相性が良いことから、Podmanは生成したコンテナをsystemd unitファイルとして書き出す機能も持ちます。

rootless実行はユーザー名前空間(user namespaces)を活用し、一般ユーザー権限のままコンテナを動かせる仕組みです。Dockerでもrootlessモードはあるものの、Podmanでは設計当初から第一級機能として用意されており、設定もシンプルです。またKubernetesのPod概念を直接サポートし、複数コンテナを1つのPodとしてまとめて管理したり、podman generate kubeでKubernetesマニフェストYAMLをエクスポートしたりできます。

libpodからPodman 4.xまで

libpodからPodman 4.xまで

Podmanの開発は、Red Hatでコンテナ関連を率いるダニエル・ウォルシュらが2018年に立ち上げました。前年にCRI-OとBuildahをリリースしていた流れの延長で、ユーザー向けのコンテナエンジンを「Dockerデーモン無しでも作れるはずだ」という思想のもと開発が始まりました。2018年8月のlibpod 0.7発表を経て、2019年1月にPodman 1.0として正式リリースされ、同年5月のRHEL 8でDocker Engineに代わる既定ツールとなりました。

2020年のPodman 2.0ではDocker互換のREST API(Docker Compatible API)を導入し、Dockerクライアントから直接Podmanへ接続できるようになりました。2022年2月のPodman 4.0では、ネットワークスタックがCNIから新しいNetavarkへ移行し、IPv6対応や複数ネットワーク同時接続を改善しました。2023年のPodman Desktop 1.0公開でWindowsやmacOSのGUI体験も整い、Docker Desktopから乗り換える企業ユーザーが増えました。Podman 5系では、podman machineの刷新やQuadletによるsystemd統合の正式化が進んでいます。

Dockerからの移行手順

Dockerからの移行手順

Dockerからの移行は、コマンドラインだけで言えば極めて簡単です。podman runpodman pspodman buildpodman pushなど、サブコマンド体系がDocker CLIとほぼ同一に保たれており、シェルでalias docker=podmanと書くだけで多くの既存スクリプトがそのまま動きます。RHEL 8系のパッケージにも/usr/bin/dockerという名前でPodmanへのリンクが用意されているため、Dockerをアンインストールしても既存の運用手順を温存できます。

課題はDocker Composeとの連携です。Podmanではpodman-composeというPythonラッパーや、Compose Specに準拠したdocker-compose v2をPodman socketに向けて動かす方式が選択肢になります。後者は2021年以降公式にサポートされ、Docker Composeのバイナリをそのまま使いつつ裏側でPodmanを操作する構成が可能です。CI/CDで使う場合は、ビルドにBuildah、転送にSkopeo、実行にPodmanといったRed Hatツール群を組み合わせると、Dockerデーモンを起動できないコンテナビルダー環境でも完結します。

Docker Engineとの比較

Docker Engineとの比較

PodmanはDocker Engineの代替を明示的に狙ったツールであり、コマンドの互換性と機能の対応関係が極めて高いのが特徴です。一方で運用思想は対照的で、Docker Engineが「中央デーモンが状態を保持する」モデルなのに対し、Podmanは「コマンドごとにプロセスが立ち上がり、状態はファイルシステムとconmonに分散する」モデルを採ります。この違いがそのまま長所と短所として表れ、Podmanの方がクラッシュ耐性は高い一方、デーモン前提のツール連携には工夫が必要です。

市場では、Docker Desktopが2021年に大企業向け有償化を発表したのを契機にPodman Desktopへの注目が高まり、金融機関や行政機関で公式に乗り換えを進める事例が増えました。一方、Docker Desktopは多くの開発者にとって最も親しまれたコンテナ環境であり、依然として個人開発・小規模チームでは優位です。サーバ側ではKubernetes+containerd/CRI-O、開発側ではDocker DesktopかPodman Desktop、という棲み分けが現代のコンテナ環境の現実的な構図です。

まとめ

Podmanは2018年にRed Hatが立ち上げ、2019年にv1.0を出したデーモンレスのコンテナエンジンです。rootless実行とPod対応を備え、コマンドラインはDockerと高い互換性を持ちます。RHEL/Fedoraの既定ツールとして広く配布されており、Docker DesktopのライセンスやデーモンモデルからPodmanへの移行を検討する場面が増えています。

※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

コメント

コメントする

目次