DockerかPodmanか、rootlessでも移行互換性は同じではない

Linuxサーバーで既存のCompose構成やDocker APIへの依存が大きいなら、まずDockerのrootlessモードが選びやすい。コンテナごとの管理をユーザー単位のsystemdサービスに寄せたいなら、Podmanが有力だ。どちらも非rootで実行できるが、接続先やデータの扱いまで同じになるわけではない。

選択を左右するのは、デーモンの有無だけではない。監視やデプロイのツールが使うソケット、公開ポートへの通信、イメージの保存先、永続データの所有者、再起動後のサービス起動までが移行範囲に入る。コンテナが起動した段階と、既存サービスを継続して運用できる段階は分けて考えたい。

デーモンとソケット：既存ツールはどこへ接続するか

Dockerのrootlessモードでは、デーモンとコンテナの両方を非rootユーザーのユーザー名前空間で実行する。クライアントがデーモンに要求を送る構成は維持されるため、Dockerコマンドを使う既存の運用手順を残しやすい。ただし、設定例のユーザー用ソケットは従来のシステム共通ソケットとは場所が異なる。

Podmanの通常のコンテナ操作には常駐デーモンが不要だ。一方、Docker API経由で操作する外部ツールを使うなら、Podman側のサービスとユーザー用ソケットを用意することになる。コマンド名を置き換えるだけでは、ソケットのパスを固定した監視ツールやデプロイ処理は移らない。接続先を変更できても、そのツールが呼ぶAPIとPodman側の動作が合うかは別に確認が必要だ。

Dockerをrootless化する場合も、root権限のシステム用デーモンが動いたままなら、運用全体が切り替わったとは言えない。クライアントが選んでいるコンテキスト、ツールに渡す接続先、ホスト上で動作するデーモンをそろえて判断する。Podmanでは操作した非rootユーザーごとにコンテナが分かれるため、管理用アカウントを変えたときに同じコンテナが見えるという前提も置けない。

ネットワークと保存先：rootlessの制約はどこに出るか

Podmanの公式仕様は、rootless実行でユーザー名前空間と従属UID/GIDを使うこと、ユーザーごとにイメージを保存することを示している。同じ仕様には、ネットワークデバイスの作成にpastaが必要な構成、rootlessでの古いカーネルのOverlayFS制約、NFS上のコンテナ保存領域の制約も記されている。通信方式とストレージドライバーは、製品名から推測するのではなく、採用するホストの設定として扱うべき項目だ。

公開ポートを持つサービスでは、外部から到達できるかに加え、アプリケーションから見える送信元IPとコンテナからホストへの接続を確認したい。rootlessの通信経路は、従来のroot権限によるブリッジ構成と同一とは限らない。特権ポートで直接待ち受ける設計なら、ホスト側の許可設定や転送方法も選択に関わる。ここで必要なのは抽象的な速度順位より、実際のサービスが必要とする通信方向とアドレスの扱いだ。

Podmanのrootless環境では、イメージやコンテナのレイヤーを置く領域と、アプリケーションの永続データを区別する。ホームディレクトリがNFS上にある場合、ユーザー用のstorage.confでgraphrootをローカル領域に向ける方法がある。NFSの制約を、サービスが扱うあらゆるファイルへの一律の禁止と読み替えると、移行に必要な変更箇所を誤る。まずコンテナエンジン自身の保存先を特定し、そのうえで各マウント先の動作を確認する。

古いカーネルでrootlessのOverlayFSを使えない環境では、fuse-overlayfsを使う構成が候補になる。ユーザー用storage.confが既に存在する場合は、必要なmount_program設定が自動で加わると決めつけられない。ストレージ方式が変われば、イメージの展開やファイル操作を含む性能評価の条件も変わる。イメージ取得の所要時間を比べるなら、キャッシュの有無と実際の保存先を合わせる必要がある。

Compose：ファイルを読めても運用は同一とは限らない

podman composeの仕様では、このコマンドは外部のCompose実装を呼び出すラッパーと説明されている。利用する実装はdocker-composeまたはpodman-composeなどで、選択した実装がPodmanのソケットと通信する。したがって「podman composeを実行できる」ことだけを、既存のComposeファイルが同じ意味で動く証拠にはできない。

移行時には、どのCompose実装を使うかを固定したうえで、サービス間通信、ネットワーク名、依存関係、環境変数、ボリューム定義を確認する。たとえば条件付きの話として、コンテナ自体は起動しても、アプリケーションが別サービスの名前を解決できなければ、従来の構成を再現したことにはならない。外部ツールがDockerソケットに直接接続する場合は、Composeファイルの確認とは別に、そのツールの接続先とAPI操作を調べる必要がある。

既存の構成をできるだけ維持することが優先なら、Dockerをrootless化する選択には変更範囲を絞りやすい利点がある。Podmanへ移る理由が明確な場合でも、Composeの記法、呼び出す実装、コンテナエンジンの動作を一つの「互換性」として扱わない方が、問題の所在を特定しやすい。

systemd：Quadletが変えるのはサービスの管理方法

Quadletの公式仕様では、コンテナ、ネットワーク、ボリュームなどの定義からsystemdのサービスユニットを生成できる。rootless用の定義をユーザー用ディレクトリに置く構成も示されている。個々のサービスの起動、停止、依存関係をsystemdで管理したいLinuxサーバーでは、これがPodmanを選ぶ具体的な理由になる。

Compose中心の環境からQuadletへ移すなら、ファイル名を変えるだけでは済まない。コンテナに与える設定に加え、ネットワークやボリューム、サービス同士の依存関係をsystemdで扱える形に表現し直す。イメージ取得やビルドをサービス起動時に行う定義では、その所要時間が起動待ち時間に影響するため、再起動時にサービスが立ち上がる条件まで含めた設計になる。

Dockerのrootlessモードでも、ユーザーのsystemdサービスとしてデーモンを管理できる。そのため、systemdを使えること自体はPodman固有の利点ではない。違いは、Dockerではユーザーのデーモンを管理の中心に置くのに対し、Quadletではコンテナなどの定義をsystemdのユニットに結び付けられる点にある。無人再起動後もrootlessサービスを動かすなら、どちらを選ぶ場合もユーザーサービスの起動条件を確認したい。

公開測定：起動と通信の数値をどう読むか

同一Linuxホストでの公開測定では、取得済みのAlpineイメージを使った起動がDocker Engine 29.5で352ミリ秒、Podman 4.9.3で342ミリ秒だった。ただし測定条件はDockerがrootful、Podmanがrootlessである。同じ測定の公開ポートへの通信も、この権限条件の異なる構成を比べているため、rootless同士の性能順位にはできない。

起動時間の差は、そのホストで採用理由にできるほど明確ではない。一方、通信の測定値は、Podman側のpastaとDocker側のブリッジという経路の差も含んでいる。測定が示すのは、その組み合わせで得られた結果だ。エンジンだけを入れ替えた場合の効果や、別のLinuxサーバーでも再現する速度まで示すものではない。

採用条件が性能なら、両者をrootlessで動かし、同じホスト、同じイメージとキャッシュ状態、同じ通信方向、同じ種類の保存先で比較するのが妥当だ。起動だけでなく、イメージ取得、公開ポートを通る通信、アプリケーションが実際に使うボリュームの読み書きを分けて測る。公開測定にないイメージ取得時間やボリュームI/Oの優劣を、起動時間の数値から補うことはできない。

移行判断を分ける項目

既存のComposeとDocker APIを中心にサービスを運用しているなら、Dockerのrootless化を先に検討する方が自然だ。Podmanを選ぶ場合は、ユーザー単位の管理やQuadletによるsystemd運用から得る利点と、接続先やサービス定義を書き換える作業を併せて評価する。両者とも非rootで動くという共通点だけでは、移行の作業量は決まらない。

• ComposeとAPI：使用するCompose実装を決め、既存ファイルの動作と外部ツールが必要とするAPI操作を分けて確認する。
• ソケット：監視、デプロイ、開発支援の各ツールがユーザー用ソケットへ接続先を変更できるかを調べる。
• ネットワーク：公開ポートへの到達性、送信元IP、コンテナからホストへの接続がサービスの要件に合うかを見る。
• 保存領域と権限：Podmanのgraphrootを適切な領域に置けるか確認し、永続データではコンテナ内外のUID/GIDに対応した作成、更新、再読込ができるかを確かめる。
• 再起動と性能：ユーザーサービスが無人再起動後に復旧するかを確かめ、起動、イメージ取得、通信、ボリュームI/Oを採用するrootless構成で測る。

この項目を満たす見通しが立てば、Podmanへの移行は運用方式を選ぶ判断になる。ComposeとDocker APIへの依存を維持したい環境では、Dockerのrootlessモードが変更箇所を抑える選択肢になる。

関連記事：

• SubstackアプリにPodcast専用タブ、発見と収益化は同じではない
• Grok Botを全社導入する前に、Teamsでは使えない管理機能を確認
• 法人設立ワンストップでも全部は同時に終わらない、申請の順番