Docker から Podman へ移る一番デカい差分は、「rootless（root権限なし実行）」と「daemonless（常駐デーモン不要）」で、攻撃面と運用の摩擦が同時に減る点だ。Podman は systemd と噛み合い、Kubernetes っぽい pod も素で扱える。
- rootless：コンテナを root で動かさない設計が基本
- daemonless：dockerd みたいな常駐管理プロセスがない
- 互換：Docker イメージ / docker 風 CLI / compose 系までだいたい繋がる
- pod：Kubernetes の pod に寄せたコンテナの束ね方
- systemd：起動・再起動・自動起動をOS の作法に寄せられる
で、ここから先は「みんな言うけど、そこじゃない」も混ぜる。
正直 Docker が悪いって話じゃない。だけど homelab とか自前運用って、最後は セキュリティと保守の怠さで死ぬんだよね。
あと、最初に釘。これは Linux 側の話が主役。Windows は WSL 2 を噛ませる前提。ネイティブで気持ちよく、はまだ違う。
いきなり動かす 最小の導入コマンド
Podman は Ubuntu / Debian なら apt で入り、バージョン確認は podman --version だけで済む。Windows は WSL 2 上の Ubuntu に同じ手順で入れる。
Ubuntu / Debian。
sudo apt update
sudo apt install -y podman
podman --version表示はだいたい podman version 4.x.x みたいなやつ。
4系なら「今の話」になってくる。
Windows 側。PowerShell を管理者で。
wsl --install -d Ubuntu再起動挟んだら、WSL の Ubuntu で同じ。
sudo apt update
sudo apt install -y podman
podman --version移行の心理的コストを下げたいなら、これを貼って終わりにする人が多い。
echo "alias docker=podman" >> ~/.bashrc && source ~/.bashrc…いや、これやると混乱も起きる。
でも現場って「混乱より手が動く」方が勝つ瞬間がある。ある。
rootless がデフォルト これが地味に効く
rootless コンテナは、Podman が root 権限なしでコンテナを動かす運用を前提にした設計で、ホスト側の被害半径を小さくする。Docker の rootless は後付け要素になりやすい。
「root で動かすのが普通」って文化、長期運用だとだいたい事故る。
事故るっていうか、事故らないための儀式が増える。
Podman の rootless は、まず普通にこうなる。
podman run --rm -it alpine shポートも現実がある。privileged ports（特権ポート：0〜1023）は rootless だと基本つらい。
だから 8080 みたいな “逃げ” を使う。
podman run -d -p 8080:80 nginxこれ、口で言うと些細だけど、運用の癖が変わる。
「80 に出したいから sudo」みたいな誘惑が減る。地味に。
あ、ちなみに “rootless だと何でも安全” って話でもない。コンテナはコンテナ。
でも、最初の一手が安全側に倒れてるのは偉い。そういうこと。
daemonless は 事故の形が変わる
daemonless アーキテクチャは、Podman が常駐デーモンに依存せず CLI から直接コンテナを起動し、各コンテナが起動ユーザーの子プロセスとして見える構造だ。単一障害点と特権常駐プロセスが減る。
Docker の dockerd が悪者、って単純な話じゃない。
ただ「常駐の特権プロセスがいる」ってだけで、監査も説明も面倒になる。これ、分かる人には分かるやつ。
Podman は普通に叩く。
podman psそれだけ。
余計な儀式が減る。
Proxmox みたいな “素の Linux 感” が強い環境だと、この噛み合いが気持ちいい。
気持ちいいけど、まあ、そういう快感って一般には語られない。
互換はだいたい勝つ ただし compose は癖が出る
Podman は Docker イメージ互換と docker 風 CLI を持ち、podman-compose で Compose 運用にも寄せられる。完全互換を期待するより、互換の範囲を把握して割り切る方が速い。
現場で一番多いのは、結局これ。
podman pull nginx
podman run -d -p 8080:80 nginxで、Compose 系をやるなら。
sudo apt install -y podman-compose
podman-compose -f docker-compose.yml upここ、夢見すぎるとコケる。
Compose の挙動、ネットワーク、ボリューム、細かい差で “あれ？” ってなる瞬間がある。
でもさ、Docker だって「完全に分かってる」人だけで回ってないでしょ。
動いてるなら勝ち、みたいなところ、あるじゃん。
The catch: 互換の話は、結局「自分の compose がどれだけ特殊か」の自己紹介になる。
特殊な人ほど声がでかい。ほんとに。
pod は Kubernetes の真似じゃなくて 生活の知恵
Podman の pod は、複数コンテナで network namespace などを共有してまとめて扱う仕組みで、Kubernetes の pod 概念に近い。密結合なサービス群を “束” として管理しやすい。
microservices とか言い出すと話が濁るけど、要するに「nginx と redis とアプリ」を一緒に面倒見る時の器。
Docker でもできる。でも Podman は最初からその器がある。
podman pod create --name mypod -p 8080:80
podman run -dt --pod=mypod nginx
podman run -dt --pod=mypod redis同じ pod の中だとネットワーク共有で話が早い。
変な自作ネットワーク設計で迷子になりにくい。
まあ、ここも “慣れ” なんだけどね。
慣れが一番高い。いつも。
systemd 統合が本命 コンテナをサービスに戻す
Podman の systemd 統合は、podman generate systemd で unit ファイルを生成し、systemctl で起動・自動起動・再起動管理を OS 標準に寄せられる。rootless は ~/.config/systemd/user/ 配下で扱える。
ここが刺さる人は刺さる。刺さらない人は一生刺さらない。
でも自前運用って、最後はここに回帰することが多い。
podman generate systemd --name mypod --files --restart-policy=always生成された .service を user unit として置くならこの辺。
systemctl --user daemon-reexec
systemctl --user enable --now container-mypod.serviceコンテナ管理を “専用の世界” に閉じ込めない。
OS の流儀に戻す。
これ、監視も障害対応も説明も、地味にラクになる。
ラク。ほんとに。
時間 vs 金の算盤 移行コストを冷たく見る
Podman 移行の費用対効果は、「手元の compose 資産」と「rootless + systemd による運用削減時間」で決まる。小規模なら半日〜数日で回収し、大規模ほど検証工数が先に膨らむ。
数字を盛ると嘘くさくなるから、レンジで話す。
だいたいこんな “財布とカレンダー” の話になる。
- パターンA：コンテナ 1〜5 個、単純な構成（nginx + app くらい）
移行に食われるのは「半日〜1日」寄り。戻りも速い。
得るものは rootless の安心と、常駐デーモン周りの気持ち悪さが消えること。 - パターンB：compose が増殖、volume と network が複雑
ここで金（工数）が溶ける。1〜3日どころか、週末が消えることもある。
でも、systemd 統合で “再起動ポリシーと自動起動” が OS 側に寄ると、以後の保守が軽くなる。 - パターンC：チーム運用、監査・権限・説明責任が重い
最初の検証は重い。手順書も直す。人の教育も入る。
ただ、rootless と daemonless の説明が通ると、長期的なリスクコストが下がる。ここは「金」より「事故の確率」の話。
で、結局どれが得か。
自分の環境がどれに近いか、雑に当てはめたら見える。
余談。
移行を “技術的に正しいから” でやると失敗しやすい。運用って、正しさより摩擦の少なさが勝つ局面があるから。
FAQ そこだけ直答する
ポイント: ここは短く、言い切る。ふわっとさせない。
Q. Podman は Windows でネイティブに動く？
A. Podman は Windows では基本 WSL 2 上で動かし、Linux ディストリ内にインストールして使う。
Q. Docker の資産は捨てることになる？
A. Podman は Docker イメージをそのまま扱え、CLI も近いので大半の手順は流用できる。
Q. rootless の落とし穴は？
A. rootless は 0〜1023 の特権ポートに直接 bind できないため、8080 など上位ポート運用に寄せる必要がある。
Q. Compose はどうする？
A. Compose は podman-compose で寄せられるが、複雑な構成ほど差分検証の工数が先に出る。
Q. 何が一番うまい使いどころ？
A. systemd で unit 化して systemctl --user 管理に寄せると、起動と再起動が OS 標準に揃って保守が軽くなる。
結論の芯：Podman は rootless と daemonless を前提に、systemd と pod で「自前運用のだるさ」を削る方向に進んだコンテナ運用だ。
最後に、俺がその時やる “最初の小さい動き”。
いきなり全部移行しない。まず 1 本だけ、いちばん単純なやつを Podman にして、systemd user unit を生成して enable して、再起動しても勝手に立ち上がるかだけ見る。そこまで。
