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 の強みだ。
🎓 学んだことは、Podman でも無駄にならないか
まとめると、RHEL系(MiracleLinux など)でコンテナを扱うなら、コマンドの使い方はこれまで学んだ docker の知識をそのまま流用できる。その上で Podman は『常駐デーモンを持たず(デーモンレス)、一般ユーザー権限で動かしやすい(ルートレス)』ぶん安全、というのが要点だ。
学習段階では docker と podman の違いを過度に意識する必要はなく、まずは同じ感覚で手を動かして構わない。実務に入って権限やセキュリティ、systemd との連携が問われる場面で、デーモンレス・ルートレスという Podman の設計思想が効いてくる。
docker で身につけたイメージとコンテナの考え方、ボリュームやポート公開の作法は、Podman でもそっくり通用する。ここまでの学びは無駄にならず、そのまま現場で活かせる。