Podmanに切り替えるとDockerより本当に楽になるのか試してみた

「Dockerを使うとき、管理者にsudo権限をお願いしたことがある人って結構いる気がする。自分の開発環境なのに、自分でコントロールできてないような感じ、ありませんか？セキュリティ担当から“もうDockerはダメだよ”なんて言われて、CIジョブも困っちゃう人、多分七割近くはそうじゃないかなぁ。それに、『docker ps』みたいな簡単なコマンド一つ打つのにもバックグラウンドでデーモンが動いてないといけない…そこに引っかかったこと、一度や二度じゃ済まない。

Podmanって名前、どこかで耳にしたことがある人も少なくないはず。これ、実はDockerの代わりになるコンテナツールなんだけど、“root要らず”、しかも“デーモン要らず”、それでいて普段のワークフローほぼそのままというちょっと信じがたい特徴持ってるんです。誰かが『Podmanなら違う』って話してたけど、本当にその通り。“ドロップイン互換”とかいう話、半信半疑だったけど…思ったよりハードル低い。

もし今までDockerやDocker Composeを何十回と使ってきたなら、その経験無駄にならないし、むしろPodmanとpodman-composeへの移行は案外スムーズ。セキュリティ的にもだいぶ強固になったような印象受けますね。systemdとも連携しやすくなるし…あ、それとrootless運用始める人が最近増えてる感じします。

DiveやDockerSlim、それからLazydockerやDockgeみたいな便利系ツールとの相性も悪くないので、「あれ、このツール使えなくなるの？」みたいな不安もそんなになかったです。不安になる前に、とりあえず試してみても損は無さそう。

ちなみに、“Docker→Podman”の橋渡し方法はいろいろあるっぽいので、“好きなワークフローそのままでいいんじゃ？”と思う瞬間もちらほら出てきます。本当のところ、新しいコンテナ開発環境求めてるなら、この2つ（Podman＋podman-compose）で十分なんじゃ…？手放せなくなる理由、多分一度触ればわかりますよ。

Podmanを使う理由？それは、Dockerとは少し違うアプローチなんだ。

まあ、ざっくり言うと、いくつかの興味深いポイントがあるんだけど。

まず、デフォルトでルートレス。つまり、特別な権限なしでコンテナを動かせるってこと。セキュリティ面でちょっとスマートな感じ。dockerのソケットとかいろいろ面倒くさいリスクがないんだ。

で、面白いのが、デーモンレスなところ。バックグラウンドでゴトゴト動くプロセスとかないんだよ。各コマンドが独立してるから、スクリプティングとかシステム連携が超楽。

Docker CLIとの互換性もバッチリ。基本的にdockerコマンドと同じように使えるから、移行も簡単。bashのエイリアス一発で切り替えられるし。

Kubernetesとの連携も結構スムーズ。コンテナからKubernetesのYAMLを自動生成できるんだ。スケーリングとかも楽チン。

システムサービスとの統合も柔軟。長時間稼働するコンテナを、まるでネイティブなサービスみたいに管理できるんだよ。

まあ、色々と面白い特徴があるんだけど、結局使ってみないとわからないよね。

Podmanやpodman-composeのインストール方法って、OSによって結構違うんだよね。UbuntuやDebian系なら、まずシステムのアップデートを済ませてから、Podmanをインストールするみたい。pip3でpodman-composeも入れるんだけど、この辺は他のLinuxと大体似た感じ。

FedoraとかRHEL系だと、dnfでPodmanが入る。でも、そのあたりのディストリビューションはちょっと手順が前後したりすることもあるかもしれないし、人によって微妙にコマンド違ったりするかも。pip3経由でpodman-composeを追加する流れは変わらないっぽい。

macOSの場合はまた話が変わってきて、Homebrewを使うことになる。brew install podmanで本体を入れるけど、なんとなく容量も七百数十メガくらい食う感じ。それに加えてPodman Desktopというグラフィカルなツールも導入できるらしいけど、それが本当に必要かどうかは人それぞれかな。

Desktopアプリを起動して最初のセットアップ進めていると、「podman compose」も一緒にインストールされるようになっているみたい。ただ、そのままだとmacOSでは仮想環境（VM）上で動く形になるので、「podman machine init」を実行すると八百数十メガくらい何かダウンロードされ始める。ちょっと時間かかった気がする。そのあと「podman machine start」でVM起動して完了…という流れ。

全部終われば、一応Podmanを使える状態にはなるかな、と。ただ実際に「podman machine start」を叩くと、「現在rootlessモードです」とか英語で何行か出てくることが多い。特権ポート使いたい場合には管理者権限絡みのヘルパーツール（sudoつけて/opt/homebrew以下のバイナリ）を何度か実行しろと言われたりした記憶がある。その後もう一度仮想マシン止めて再度スタートすれば大体OKだったと思う。

ちなみに、「podman machine start」コマンドの出力内容としては、「このマシンは今rootless設定ですよ」と案内されたりとか、そのへんまでしか自分もちょっと覚えてないけど…。

Podmanコンポーズは、いわゆるDockerコンポーズの代替ツールで、よく似た感じのやつです。基本的にDocker Composeの設定ファイルをそのまま使えて、Podmanというコンテナエンジンで動かせるんです。

インストールは、brewとかPodman Desktopからできるみたい。最近のバージョンは単に「podman compose」って呼ばれてて、昔の「podman-compose」より新しいらしいです。

主な機能は、ボリュームとかネットワーク、依存関係の設定なんかが大体できます。基本的なコマンドは、`podman compose up`みたいな感じ。ただし、Docker Composeほど成熟してないので、複雑な設定の場合はよく動作テストした方がいいかもしれません。

正直、まだ発展途上のツールって感じで、使ってみないとわからない部分もありそう。でも、軽く使う分には結構使えるんじゃないかな。

コンテナ周りの便利ツールって、まあ色々あるけど、Podmanと相性が良いかどうかは…うーん、正直微妙なものも多い気がする。例えばDockerSlimというイメージをギュッと小さくしてくれるやつ、勝手に不要なファイルとか削ぎ落としてくれるらしい。だけどPodman単体では動かないっぽい。どうもDockerのソケットが必要になるみたいで、そのため結局一時的にDockerを使ってイメージを細くした後、レジストリ経由でPodman側に戻すという流れになることが多そう。直接じゃなくて遠回り。

あとDiveっていうCLIツールがあって、あれは自分のイメージの層ごとの中身や無駄を覗き見できるから、わりと重宝されているようだ。brewでサクッと入れてしまえばいいし、「dive イメージ名」みたいな形でコマンド叩くだけ。ただし条件としてローカルに保存されているPodmanイメージなら何とかなるらしい。他にも同じ類似ツールもありそうだけど、とりあえずDiveは相性悪くない方。

Lazydockerの話もたまに聞くけど、これはUI付き（ターミナル画面ベース）の管理ツールなんだよね。でもこれまたDockerソケット前提だから、そのままだとPodmanにはほぼ対応してない感じ。ただ「完全NG」とまでは言えなくて、一部ワークアラウンド的なのはあるらしい。ただ開発者向け限定だったりPR（プルリク）が保留になったままだったりするので、本番環境や真面目な用途にはちょっと頼りづらいという印象。

DockgeなんてGUI管理用のWebアプリも出てきた。でもdocker-compose前提なので、結局ネイティブなPodman対応とは言えないっぽい。本当に使いたかったら開発時だけdocker-composeでUI操作して最終デプロイだけPodmanに任せるとか？Docker自体rootless運用しながら両立させる方法もゼロじゃないみたいだが…割と裏技感強め。

結局、多くの場合こういう妥協案になることが多いと思う——実際のコンテナ化作業はほぼ全部Podmanに任せつつ、それ以外の部分（最適化とか可視化）は従来通りDocker系ツールのお世話になる。この組み合わせが今んところ現実的なのかなぁ、と誰か言ってた気がする。

Podmanへの移行は、複雑で興味深い選択肢です。

イメージの転送には、いくつかの面白いテクニックがあります。例えば、ローカルレジストリを使ったり、`docker save`や`podman load`のようなコマンドを駆使したりできます。Docker環境からPodmanへ、あるいはその逆も可能。

一時的なDockerデーモンを立ち上げて、DiveやDockerSlimを活用し、再度インポートするなんてこともできちゃうんです。基本的には、こんな感じのコマンドペアで橋渡しできます：

# Dockerから

docker save myimage > myimage.tar



# Podmanへ

podman load < myimage.tar

でも、本当にPodmanに乗り換えるべきなの？

もし、あなたが：
- セキュリティに敏感
- Kubernetesに興味がある
- Dockerデーモンに不満
- systemdとの統合を望んでいる
- よりクリーンでルートレスな環境を求めている

なら、おそらくPodmanは魅力的な選択肢でしょう。

ただし、チーム全体がDockerに完全にコミットしていたり、特殊なDocker専用ツールを使っている場合は、慎重に判断する必要があります。

結局のところ、技術選択は常にコンテキストに依存するんです。

両方を一緒に使う方法もあるっぽいですね。まあ、DockerとPodmanは同時に動かせるみたいな話を聞いたことがある人もいそうだけど、その辺りはaliasで切り替えできるってのがコツらしいです。例えば「d」でdocker、「p」でpodman、みたいな感じ。ちなみに、docker saveとかpodman loadみたいなのが、お互いの間でイメージをやり取りする橋渡しになる、とかそんな噂。

で、ちょっと話は変わるけど――実際にどうやって使うの？というパターンも色々ありそうです。たとえば簡単なウェブアプリ（Flask）とRedisキャッシュを組み合わせて動かしてみる例があります。こういうの、多分テストとかサンプルにはぴったりなんじゃないかな。

構成としては、どこかで見かけた「docker-compose.yml」を思い出す人もいるかもしれません。中身は大まかにwebサービス（Flaskアプリ）とredisサービス。このふたつが連携する形です。ディレクトリ構造もちょっとシンプル目で、「app」フォルダ下にDockerfileとかapp.pyだけ置いてあるような感じだった気がします。

Dockerfile自体はPythonベースのスリムなものから始めて、作業ディレクトリをセットした後にファイルコピーして必要なパッケージを入れる流れ。本当に必要最低限って雰囲気ですね。

コード部分――app.pyですが、一番上でflaskとredis両方importしてて、Flaskアプリ作ったあとredisにつないでます。「redis」という名前はさっきのcomposeファイルから来てるんですよね、多分。他にもカウンター機能的なのがあって、このページ見るたびに数字増える仕掛けになってます。一度アクセスすると「このページ何回見られた」的なメッセージ返されます。本当に軽量なので複数コンテナ試すには便利でしょう。

さて、このセットアップ全体を動かす場合、大抵ローカルホストの五千番台ポートだったような……細かい数字忘れました、ごめんなさい。ただブラウザ開いてlocalhost指定するとすぐ確認できますし、curlでも叩けるので好みに合わせればいいでしょう。

Docker Composeの場合だと……buildしてupするコマンド打つだけです。なんだっけ、「docker compose up --build -d」だったと思います。それで全部立ち上がりますし、その後ウェブページ見てもちゃんと動くと思いますよ。もちろん、細部はいろんな環境によって微妙に違う可能性も否定できませんけどね。

Dockerワークフローの世界へようこそ！ちょっと複雑そうに見えるかもしれませんが、実は意外とシンプルなんです。

### ステップ1: イメージを覗いてみる
Diveというツールを使うと、イメージの各レイヤーが丸見え。何がスペースを食っているのか、どんな変更があったのか、すぐに分かっちゃいます。あれ、でもどのくらい小さくできるんだっけ？

### ステップ2: イメージをスリムに
DockerSlimを使えば、イメージをほぼ魔法のように縮小できるらしい。おそらく元のサイズの数分の一くらいになるんじゃないかな。本当に？

### ステップ3: コンテナを楽々管理
Lazydockerを起動すれば、端末から離れずにログ確認やサービス再起動が簡単。まるで魔法のリモコンみたいだね。

### ステップ4: おまけのWeb管理画面
Dockgeを使えば、ブラウザから複数のcomposeプロジェクトを管理できる。なんだか便利そう！

### もう一つの選択肢：Podman
rootなしで、デーモンもなしって、なかなかスグレモノ。docker-composeとほぼ同じように動くみたい。

イメージ管理って、最初は難しく見えるけど、慣れてくるとけっこう楽しいかも。さあ、コンテナの世界へ！

Podmanでイメージを管理する時、まあローカルに保存されてるっていうのは割と普通な話なんだけど、DiveってやつもDockerのイメージみたいにすんなり読める。
で、DockerSlimを使いたい場合はちょっと面倒。あれDockerのソケットが必要らしいから、一度手作業でブリッジしないといけない感じ。たしかPodmanからエクスポートしてtarファイル作って、それをDockerに読み込ませる流れだったはず。
具体的なコマンドとか細かいことは置いといて、大まかにはPodmanでtar保存→Dockerでロード→スリム化→またtar書き出し→それをPodmanでもう一回インポート…　みたいな迂回ルートになる。

ちなみに「-o」でファイル名指定できるけど、標準出力にもそのまま流せるんだよね。逆もしかりで、loadコマンドは標準入力対応してたりするから、パイプで繋げばファイル経由せずにもできなくはない。ただ慣れてないとうっかり間違えそう。

このやり方だと結局Dockerのツールも活用できちゃうから、Podmanなのに中身スリムになったイメージが手元に戻ってくるわけ。ちょっと遠回りだけど…。

あとログ見たり稼働状況チェックしたい時？Lazydockerみたいな派手なUIじゃないけど、「ps」とか「logs」、「top」あたりならPodman単体でもそこそこ事足りる感じ。systemd用のユニットファイル生成なんて小技まであったような気もする。

Dockgeについて言えば、直接Podman対応じゃないっぽい。でも「docker-compose」を「podman-compose」にaliasしたり、「docker」自体を「podman」に置き換えるalias技があるみたい。ただ全部がちゃんと動く保証はなくて、ごく基本的な部分なら何とかなる…くらいかな。

ところで、この辺比較すると──例えばUI重視だったり既存パイプライン維持したかったら結局Dockerのほうが楽だと思う人多そう。でもroot権限不要とかsystemdとの連携考えてたりすると、不思議とPodman選ぶ人も少なくないらしい。
実際にはどちらにも一長一短あるし、その場その場の事情次第…そんな印象だった気がするんだよね。

コンテナの世界、それは常に進化し続けるダイナミックな領域。Dockerとその新しい挑戦者Podmanについて、ちょっと興味深い話をしてみよう。

開発とツール周りではDockerが頼もしい存在。セキュリティと本番環境ではPodmanが頼りになる。そう、両者をうまく使い分けるのがプロのテクニックなんだ。docker saveとpodman loadを使って、まるで橋を渡すように自在に移動できちゃうんだよ。

正直に言えば、Dockerは今でも頼れる老舗。でも、Podmanは未来を見据えたセキュアな選択肢。どちらか一方を選ぶ必要なんてない。むしろ、状況に応じて賢く使い分けるのがスマートな方法。

これからのコンテナの世界は、rootlessで、デーモンレスで、そして相互運用性が高い。Podmanを武器に持っていれば、すでに一歩先を行っていると言えるかもしれない。

最後に、コミュニティの一員として、いくつかのお願い。記事が気に入ったら拍手を忘れずに。そして、私たちをフォロー。XやらリンクトインやらYouTubeやら、いろんな場所で情報発信してるから、チェックしてみてね。

テック情報に飢えている人には、CoFeedをおすすめ。AIパワーで最新情報をキャッチできるよ。Differで無料ブログも始められるし、Discordのクリエイターコミュニティにも参加できる。

テクノロジーの海は広い。一緒に泳いでいこう！