サーバー、データベース、インフラに関するトピックス

■第20話：podmanの基本とDockerとの違い

（最終更新日：2025.05.18）

「Rootlessで運用しよう」

podmanは、近年注目されているコンテナエンジンで、特にRootlessモードによるセキュリティ強化とデーモンレス設計が特徴だ。 Dockerと同様にコンテナのビルド、管理、実行が可能でありながら、より軽量で効率的な動作が可能である。 本記事では、podmanの基本概念からインストール方法、Dockerとの違い、基本コマンドの比較、Composeの使い方までを解説する。

１.podmanとは

podmanは、Red Hatが開発したコンテナエンジンで、Dockerの代替として注目されている。 Dockerと同様にOCI (Open Container Initiative) 準拠のコンテナを扱うことができ、コンテナのビルド、管理、実行が可能だ。 ただし、podmanは次の特徴がある。

podmanの最大の特徴は、Rootlessコンテナに対応していることだ。 これは、システムの管理者権限（root）を必要とせずに、一般ユーザー権限でコンテナを実行できる仕組みであり、 セキュリティ面で非常に大きなメリットがある。

RootlessコンテナはホストOSへの影響が極めて小さいのが特長だ。 通常、コンテナはホストのカーネルを共有して動作するが、root権限で動作する場合、コンテナ内部での脆弱性がホスト全体に波及するリスクがある。 しかし、Rootlessモードではコンテナはホストのリソースに対して直接的なアクセス権を持たず、 ユーザー空間で隔離されて実行されるため、セキュリティリスクが大幅に低減される。カーネルに対する攻撃や権限昇格のリスクが低減される。

さらに、Rootlessコンテナはシステム管理者の介入が少なくて済むため、開発者が独立して環境を管理しやすくなる。 これにより、開発サイクルが短縮され、迅速なデプロイメントが可能になる。 また、ユーザー名前空間（User Namespace）を利用することで、ホストシステムのUIDやGIDとは異なる権限マッピングが行われるため、 コンテナがホストのファイルシステムに対して意図しない変更を行うリスクも軽減される。 つまり、ホストとコンテナ間のファイルアクセスが分離され、データの安全性が向上する。

このように、Rootlessコンテナはセキュリティ、独立性、運用効率の面で大きな利点があり、特にマルチテナント環境や開発環境での利用が推奨される。

Dockerとpodmanの比較

項目	Docker	podman
デーモン	必要	不要
Rootless	部分的に対応	完全対応
Compose	docker-compose	podman-compose
ネットワーク	Bridge, Host, None	Bridge, Host, None (CNI)
オーケストレーション	Swarm, Kubernetes	Kubernetes

２.podmanのインストールと環境セットアップ

podmanのインストールは、従来のDockerと異なり、デーモンを必要としない点が特徴だ。 特にWSL2環境では、仮想マシンやコンテナの管理が効率的に行えるため、開発者にとって大きな利点がある。 podmanの基本的なインストール手順は以下の通りだ。

WSL2でpodmanを使用するには、標準のUbuntuやDebianのリポジトリからpodmanをインストールすることができる。 以下のコマンドでpodmanをインストールする。

インストールが完了したら、バージョンを確認して正しくインストールされていることを確認する。 Ubuntu22以下だと、podmanのバージョンが3以下になり、上手く動作することができない。 その場合は、Windows StoreでUbuntu24.04LTSを入れるか、podman desktopからインストール（ディストリビューションはFedoraになる）してしまおう。 以下では、Ubuntu24.04LTSで、podmanのバージョンが4以降をインストール出来た場合で説明する。おそらく、バージョン4.7～4.9辺りがインストールされる。

その後、基本的なシステム情報を確認するために以下のコマンドを実行する。 これにより、現在のpodmanの設定や動作環境が表示される。

次にオープンソースの仮想化ソフトウェアQEMUをインストールしよう。 x86、ARM、RISC-V、PowerPC、MIPSなど、さまざまなCPUアーキテクチャをエミュレート可能な仮想化ソフトウェアである。 これにより、podmanのコンテナが動作する。

次に、podman desktopを使用する場合、podman machineコマンドで仮想環境を設定する必要がある。 これは、podmanがデーモンレスであるため、WSL2内での実行環境を明示的に作成するためだ。

startコマンドで躓く場合は、ChatGPTなどに聞きながら、足りないモジュールをインストールしてほしい。 実行ファイルのパーミッションの変更も一部要るだろう。これにより、podman startが実行できるはずだ。 これでpodmanがWSL2内で動作する準備が整った。

３.基本コマンドの比較

podmanとDockerは、基本的なコマンド構造が非常に似ており、Dockerに慣れた開発者であれば、ほとんど違和感なくpodmanに移行できるようになっている。 dockerと打っていた部分をpodmanと置き換えれば、多くのコマンドは動作する。 上から順に「コンテナの起動」「コンテナ一覧表示」「コンテナの停止」「コンテナの削除」になる。

dockerとpodmanのコマンドはほぼ同じ

このように、基本的な操作は非常に似ており、特に初期の学習コストは低いと言える。

４.Docker Composeとpodman Compose

Docker Composeは、複数のコンテナを一括で管理するためのツールで、特にマイクロサービスアーキテクチャや複雑なアプリケーションの開発で重宝される。 podmanもこれに対応するために、podman-composeというツールを提供している。 まず、podman-composeをインストールするには以下のコマンドを実行する。

pip3を用いるにあたり、Pythonとpipのインストールは行っておこう。 バージョンによっては、セキュリティの関係上、venv（仮想環境）の使用を求められるので、仮想空間上でpipコマンドを使用する。 インストールが完了したら、以下のようなシンプルなYAMLファイルを使用して、コンテナを定義、docker-compose.ymlとして保存しよう。

docker-compose.ymlファイル

そして、以下のコマンドでコンテナを起動する。dockerをpodmanに変えただけで同じように動く。

ここまでが、podmanでコンテナを起動する一連の流れになる。

５.podman desktopでの可視化と管理

podman desktopは、CLIに加えてGUIでの操作が可能なツールで、コンテナの起動、停止、ログの確認、リソース使用状況の監視などを視覚的に行うことができる。 これにより、podmanの操作がより直感的になり、初心者にも扱いやすくなる。

podman desktopでは、起動中のコンテナ一覧やリソース使用状況がリアルタイムで表示され、特に大量のコンテナを同時に管理する場合に便利だ。 また、ボリュームやネットワークの設定も視覚的に確認できるため、複雑な設定も管理しやすくなる。 さらに、podman desktopは、各コンテナのログをリアルタイムで表示する機能も備えており、 トラブルシューティングやデバッグ作業を効率化するのに役立つ。 このように、CLIとGUIの両方から柔軟に管理できる点が、podman desktopの大きな強みだ。 CPUコア数、メモリの使用状況などが見られる部分はDocker Desktopそっくりだ。

podman desktop

ただし、Docker Desktopと比べるといささか完成度が低い。 podman desktopでは、WSL2の選択がクリック1つでできない（コマンドベースになる）、 コンテナ起動のUIへの反映が難しい、Doceker Hubのような公式イメージの提供が少ないなどである。 また、実際使って比べてみると、直観的でない不自由さも感じるはずだ。 良くなるにはもう少し時間が必要に思える。

６.まとめ

podmanは、Dockerと比較してより軽量でセキュアなコンテナエンジンとしての特長を持ち、特にRootlessモードでのセキュリティ強化が大きなメリットだ。 デーモンレス設計により、システム全体への影響が少なく、効率的なリソース管理が可能になる。 さらに、podmanはKubernetesとの親和性も高く、将来的なスケーラビリティや分散システムの構築にも適している。

また、podmanのコマンドは、Dockerのコマンドのdocker部分をpodmanに置き換えただけのものが多いことが分かった。 使い勝手はDockerを踏襲し、低い学習コストで始められるのも魅力である。Dockerを触ったことがある人は、ぜひ、この機会に一度使ってみよう。

▼参考図書、サイト

   podman 　podman 公式サイト
   podman desktop 　podman desktop 公式サイト