Podman との関係
Podman は Docker とよく似たコンテナ管理ツールで、RHEL系（MiracleLinux など）で標準的に使われます。コマンドはほぼ互換で、docker を podman に置き換えるだけで動く場面が多く、alias docker=podman として使うこともあります。大きな違いは、Podman は常駐するデーモンを必要とせず、一般ユーザ権限のまま（rootless で）コンテナを動かしやすい点です。学んだ docker の知識はそのまま Podman でも活かせます。
ここまで docker を使って学んできましたが、RHEL系のLinux(MiracleLinux など)では、標準のコンテナ管理ツールとして Podman が採用されていることがほとんどです。新しいツールと聞くと身構えるかもしれませんが、心配は要りません。Podman は docker とコマンド体系がそっくりになるよう設計されており、これまで学んだ知識はそのまま活かせます。大事なのは「docker と何が違い、なぜ RHEL系で好まれるのか」を理解しておくことです。
コマンドはほぼ互換
Podman の最大の特徴は、docker とコマンドがほぼ互換だという点です。これまで打ってきた docker run / docker ps / docker stop / docker rm / docker build / docker logs / docker exec といったコマンドは、先頭を podman に置き換えるだけでそのまま動きます。たとえば podman run -d --name web -p 8080:80 nginx でコンテナを起動し、podman ps で確認し、podman stop web で止め、podman rm web で消す、という具合に、操作の流れはまったく同じです。だから片方を覚えれば、もう片方も新しく覚え直す必要はほとんどありません。
毎回 podman と打つのが面倒で、これまでの癖で docker と打ちたい場合は、別名(エイリアス)を設定できます。alias docker=podman を実行しておくと、以降 docker run … と打っても中身は Podman が処理します。確認として docker --version を打って podman version 4.x.x のように返ってくれば、別名が効いている証拠です。ただしこの alias はターミナルを閉じると消えるので、毎回使いたいならホームディレクトリの ~/.bashrc にこの行を書いておくと、ログインのたびに自動で設定されます。RHEL系では、最初から docker が Podman の別名として用意されている環境もあります。
デーモンレスという違い
では中身は何が違うのか。1つ目の大きな違いがデーモンレスという設計です。Docker には、裏で常に動き続ける管理プロセス(デーモン、dockerd)があり、docker コマンドはそのデーモンに指示を出して仕事をさせる仕組みになっています。便利な反面、この常駐プロセスが1つ落ちるとコンテナ操作全体が止まり、しかもそこに権限が集中するため、攻撃の的にもなりやすいという弱点があります。Podman にはこの常駐デーモンがありません。コマンドを打ったときだけ処理が動くシンプルな作りなので、常駐プロセスを狙った攻撃の的が減り、デーモンが落ちて全体が止まるという心配もありません。
ルートレスという違い
2つ目の、そして安全面で最も重要な違いがルートレスです。Docker のデーモンは通常、管理者(root)権限で動いています。これに対して Podman は、管理者でない一般ユーザーの権限のまま(rootless で)コンテナを動かしやすいように作られています。なぜこれが安全かというと、コンテナはVMに比べて隔離の壁が薄いため、万一コンテナの中から外(ホスト)へ抜け出されたとき、コンテナが root 権限で動いていればホストも root として好き放題されかねないからです。ルートレスなら、抜け出されても奪えるのはその一般ユーザーの権限だけで、被害を小さく封じ込められます。「最初から低い権限で動かしておく」という、セキュリティの基本(最小権限の原則)をコンテナ運用で実践したものがルートレスだ、と捉えてください。
イメージとレジストリまわりの違い
イメージの扱いも基本は docker と同じで、podman pull でレジストリから取得し、podman images で一覧し、podman build で Dockerfile からビルドできます。同じ Dockerfile がそのまま使えるので、ビルドの作法も変わりません。1点知っておきたいのが、レジストリの扱いです。docker は既定で Docker Hub を見にいきますが、Podman は複数のレジストリを設定で扱えるようになっており、RHEL系では Red Hat 公式の registry.access.redhat.com なども使えます。そのため、podman pull したときにどのレジストリから取得するかを確認するよう促されることがあります。曖昧さを避けるには、podman pull docker.io/library/nginx のようにレジストリ名まで含めて指定するのが確実です。
複数コンテナをまとめる
実際のアプリは、Webサーバ・データベース・キャッシュのように複数のコンテナを組み合わせて作ることがほとんどです。これらを1個ずつ run で起動・連携させるのは大変なので、設定ファイルにまとめて一括で起動する仕組みがあります。Docker では compose.yml に構成を書いて docker compose up で全部まとめて起動でき、Podman 側にも同等の podman compose があって同じ compose.yml を使えます。さらに RHEL系では、コンテナを systemd のサービスとして管理し、サーバ起動時に自動でコンテナを立ち上げる、といった運用とも相性がよいのが Podman の強みです。
実務の使いどころ
まとめると、RHEL系(MiracleLinux など)でコンテナを扱うなら、コマンドの使い方はこれまで学んだ docker の知識をそのまま流用でき、その上で Podman は『常駐デーモンを持たず(デーモンレス)、一般ユーザー権限で動かしやすい(ルートレス)』ぶん安全、というのが要点です。学習段階では docker と podman の違いを過度に意識する必要はなく、まずは同じ感覚で手を動かして構いません。実務に入って権限やセキュリティ、systemd との連携が問われる場面で、デーモンレス・ルートレスという Podman の設計思想が効いてきます。docker で身につけたイメージとコンテナの考え方、ボリュームやポート公開の作法は、Podman でもそっくり通用するので、ここまでの学びは無駄にならず、そのまま現場で活かせます。