DockerからPodmanへ移行するメリットとは？Rootless・Daemonless設計と互換性を解説

最近、DockerやめてPodmanにしようかなって話をよく聞くようになったよね。正直、僕も最初は「また新しいやつか…」って思ってたんだけど、調べてみるとこれがなかなか面白い。特に「root権限なし」で動くとか、「デーモンがいない」とか。でも、一番気になるのはそこじゃないんだよな。

結局、一番大事なのは「今まで使ってたツールがそのまま使えるのか？」ってことじゃない？ docker-compose.ymlは？ Diveは？ DockerSlimは？ その辺のリアルな話って、あんまり見かけない気がする。だから今日は、その辺の互換性の話を中心に、僕が実際に試して分かったことを、思考の垂れ流しみたいに書いていこうと思う。

TL;DR

先に結論から言っちゃうと、「全部Podmanに乗り換える必要はない。Dockerと賢く共存するのが今のところ最強」って感じ。Podmanはセキュリティとか軽さとか、Dockerにはないメリットが確かにある。でも、エコシステム、つまり周辺ツールの成熟度はまだDockerに分がある。だから、それぞれの良いとこ取りをするのが一番現実的だって話。

実際のところ、いつものツールは使えるの？

そう、ここが一番の関心事だよね。`podman-compose up`で既存の`docker-compose.yml`が動くってのはよく聞く話。それはまあ、だいたい本当。でも、開発ってそれだけじゃない。イメージの中身を覗いたり、サイズを小さくしたり、便利なUIを使ったり…そういうのができないと、生産性だだ下がりだし。

いくつか代表的なツールで試してみた結果を正直に書いてみる。

Dive: イメージのレイヤーを解析する神ツール

これはね、全く問題なく使える。最高。Docker使ってるときと全く同じ感覚でOK。PodmanはDockerとイメージの保存形式が互換性あるから、ローカルにあるイメージならDiveが普通に読んでくれる。

# まずPodmanでイメージ一覧を見て
podman images

# そのままDiveに渡すだけ。Dockerと違うのは `localhost/` が付くことが多い点かな
dive localhost/my-app-image

これでいつも通り、どのレイヤーでファイルが増えてるかとか、無駄なファイルがないかとかをチェックできる。これは本当に助かる。

DockerSlim: イメージを自動でスリムにしてくれる魔法

うーん、これはね、直接は使えない。これが結構痛い。DockerSlimはDockerのAPIソケット (`/var/run/docker.sock`) に接続することを前提に作られてるから、デーモンレスなPodmanだと「接続先がいないよ！」って怒られちゃう。

じゃあ諦めるしかないのか？っていうと、そうでもない。ちょっと面倒だけど、回避策はある。

1. Podmanでビルドしたイメージを `podman save` でtarファイルに書き出す。
2. そのtarファイルを `docker load` でDockerに読み込ませる。
3. Docker側でDockerSlimを実行して、イメージをスリム化する。
4. スリムになったイメージを `docker save` でまたtarファイルに書き出す。
5. 最後に、そのtarファイルを `podman load` でPodmanに読み込む。

…正直、面倒くさいよね。でも、本番環境にデプロイするイメージを極限まで小さくしたい、っていう需要は確かにあるから、この手順を知っておく価値はあると思う。後で具体的なコマンドも紹介するよ。

Lazydocker / Dockge: CUIやWeb UIの管理ツール

これもDockerSlimと同じ理由で、基本的には動かない。LazydockerもDockgeも、Dockerソケットに依存してるからね。PodmanにはPodman Desktopっていう公式のGUIがあるけど、ターミナルでサクッと操作したい派からすると、Lazydockerが使えないのは地味に痛い。

これも「じゃあ開発中はDocker使って、本番運用はPodmanで」みたいな使い分けが現実的になってくる理由の一つかな。無理に全部Podmanでやろうとすると、こういうところでストレスが溜まっちゃう。

じゃあ、どうやってPodmanを始めるの？

互換性の話ばっかりしちゃったけど、実際に導入する手順ももちろん大事。ここはOSによってちょっと違う。特にMacは一手間いるから注意が必要。

Linux (Ubuntu/Debian系) の場合

これは一番簡単。パッケージマネージャで一発。

sudo apt update
sudo apt install podman

# podman-composeも忘れずに。pipで入れるのが一般的かな
pip3 install podman-compose

最近は`podman compose`っていう、`podman`コマンドに統合されたバージョンもある。`podman-compose`はPython製の別ツールで、`podman compose`はGoで書かれててPodman本体に含まれてる。どっちを使えばいいか迷うけど、今から始めるなら公式に統合された`podman compose`の方を意識していくのが良さそう。Podman Desktopを入れるとこっちが入ったりする。

Macの場合 (Homebrew使用)

MacはLinuxと違って、コンテナをネイティブに実行できない。だから、裏側で軽量なLinux仮想マシン(VM)を動かして、その中でコンテナを走らせる仕組みになってる。Docker Desktop for Macがやってることと、基本的には同じだね。

# まずはpodman本体をインストール
brew install podman

# これでPodmanのVMを初期化して起動する
podman machine init
podman machine start

ただ、これを実行しただけだと、Docker APIとの互換性が完全じゃないことがある。ターミナルに「`podman-mac-helper`をインストールするといいよ」みたいなメッセージが出るはず。それに従うのが吉。

# たぶんこんな感じのコマンドを実行するように言われるはず
sudo /opt/homebrew/Cellar/podman/<バージョン>/bin/podman-mac-helper install
podman machine stop
podman machine start

これをやっておくと、Docker APIのエンドポイント（ソケットファイル）がDocker Desktopと同じ場所 (`/var/run/docker.sock`) に作られて、Dockerにしか対応してないツール（の一部）がそのまま動くようになったりする。まあ、それでもLazydockerとかはうまく動かなかったりするんだけど…。やっておいて損はない設定かな。

DockerとPodmanを共存させる「賢い」使い方

ここまで読んで、なんとなく察しがついたかもしれないけど、僕がおすすめしたいのは「Podman原理主義」になるんじゃなくて、「Dockerのエコシステムも活用しつつ、Podmanのメリットを享受する」っていうハイブリッドなスタイル。

そのための鍵になるのが、さっきちょっと触れた `save` と `load` コマンド。

例えば、さっきのDockerSlimみたいに「Podmanでは直接使えないけど、Dockerなら使える」ツールを使いたい時。こんな感じでイメージを行き来させることができる。

1. PodmanからDockerへイメージを渡す

   まずPodmanで開発・ビルドしたイメージをtarファイルにエクスポートする。この時、Podmanのイメージ名には`localhost/`が付いてることが多いから、それを忘れずに指定するのがポイント。

   # Podmanからイメージをtarファイルとして標準出力に書き出す
   podman save localhost/my-flask-app > my-flask-app.tar
   
   # Docker側で標準入力からtarファイルを読み込む
   docker load < my-flask-app.tar

2. Docker側でよしなにやる

   Dockerにイメージが来たら、こっちのもん。DockerSlimで軽量化するなり、他のDocker専用ツールで何か処理をするなり、自由にできる。

   # Docker側でDockerSlimを実行
   docker-slim build my-flask-app

   これで `my-flask-app.slim` みたいな軽量化されたイメージが出来上がる。

3. DockerからPodmanへイメージを戻す

   処理が終わったら、逆の手順でPodmanに戻してあげる。

   # Dockerからスリム化されたイメージを書き出す
   docker save my-flask-app.slim > my-flask-app-slim.tar
   
   # Podmanでそれを読み込む
   podman load < my-flask-app-slim.tar

これで、Podmanのrootlessな環境で、Dockerツールで最適化されたイメージを動かせるわけだ。このワークフロー、ちょっと手間はかかるけど、知ってるとめちゃくちゃ便利。 CI/CDパイプラインに組み込む時も、ビルドステージではDockerを使いつつ、デプロイステージではPodmanを使う、みたいな分業が可能になる。

結局、どっちを使えばいいの？比較してみた

じゃあ、改めてメリット・デメリットを整理してみようか。まあ、僕の個人的な感想マシマシで。

まとめ：僕なりの付き合い方

というわけで、色々見てきたけど、今の僕の結論はこう。

• ローカルでの開発・試行錯誤フェーズ： 便利なUIツールとか使いたいから、まだDockerが優勢。Lazydockerなしでは生きていけない体になっちゃってるし…。
• CI/CD パイプライン・本番環境： セキュリティと安定性が最優先。だから、PodmanのRootlessモードが輝く。コンテナをsystemdで管理できるのも、運用を考えるとすごく魅力的。

だから無理にどっちか一つに絞るんじゃなくて、「開発時はDocker、デプロイはPodman」みたいに使い分けるのが、一番ストレスなく、かつ安全な方法なんじゃないかな。そのための`save`/`load`テクニックだしね。

日本の開発コミュニティ、例えばQiitaとかでもPodmanの記事はすごい勢いで増えてる。でも、みんながみんな一斉に乗り換えるというよりは、こういう現実的な共存方法を探ってる段階なんだと思う。まあ、Red Hatが本腰入れて開発してるから、これからエコシステムがどんどん追いついてくる可能性は十分ある。その時が来たら、また考えればいいかなって。

結局のところ、コンテナ技術の未来は、より安全で、よりLinuxの作法に忠実な方向（つまり、RootlessでDaemonless）に進んでいくはず。Podmanはその流れを先取りしてる。だから、今から触っておいて、その思想に慣れておくのは絶対に無駄にはならないと思うな。