Podmanルートレスへの段階移行｜rootコンテナとの動作差異と切り戻しを含む確認手順

なぜ今、ルートレスPodmanへの移行が求められるのか

コンテナランタイムにおける「デーモンレス・ルートレス」という設計思想は、Podmanが当初から掲げてきた軸です。しかし現場では、既存のDockerワークフローをそのままPodmanに置き換えた結果、root権限でコンテナを動かし続けているケースが少なくありません。

2026年現在、主要ディストリビューション（RHEL 9系・Ubuntu 24.04 LTS・Fedora 40以降）ではルートレスPodmanがデフォルト推奨となり、セキュリティベースラインの観点から「rootコンテナはなぜ使っているのか」を説明できなければ構成審査を通過しにくい状況になっています。一方で、ネットワークやボリュームの挙動がrootとルートレスで異なる部分も多く、「とりあえず移行したら動かなくなった」という声も依然として上がります。

本記事では、既存のrootコンテナ環境を壊さずに段階的にルートレスへ移行する手順と、移行前に把握しておくべき動作差異、そして問題が起きたときの切り戻し方法を、実務的な流れで整理します。

rootコンテナとルートレスコンテナの動作差異を整理する

移行前に動作差異を把握していないと、移行後に原因不明のエラーに直面します。主な差異は次の5点です。

ネットワーク（Slirp4netns vs CNI/Netavark）
rootコンテナはホストの物理NICに直接ブリッジを作れますが、ルートレスコンテナはユーザー空間のネットワークスタック（Slirp4netnsまたはPasst）を経由します。ポート80・443など1024番未満のポートを直接バインドすることはできず、代わりに高ポートにバインドしてホスト側でポート転送するか、sysctl net.ipv4.ip_unprivileged_port_startを調整する必要があります。Podman 4.x以降ではNetavarkがデフォルトのネットワークバックエンドですが、ルートレスではPasstが推奨されるようになっています。

UID/GIDマッピング（User Namespace）
ルートレスコンテナ内でのrootユーザー（UID 0）は、ホスト側では実行ユーザーのサブUIDにマッピングされます。/etc/subuidと/etc/subgidに該当ユーザーのエントリがなければコンテナは起動しません。bindマウントしたディレクトリの所有者がコンテナ内のUID 0として見える必要がある場合は、podman unshare chownでホスト側の所有権を事前に調整します。

ボリュームのSELinuxラベル
RHEL系ではSELinuxが有効なため、bindマウント時に:zまたは:Zオプションがないとパーミションエラーになることがあります。rootコンテナではSELinuxコンテキストが自動付与されるケースもありますが、ルートレスでは明示指定が必要な場面が増えます。

cgroupsのバージョン
ルートレスコンテナでリソース制限（CPUクォータ・メモリリミット）を使うにはcgroup v2が必要です。RHEL 8系やUbuntu 20.04はcgroup v1/v2ハイブリッドで動くケースがあり、podman info | grep cgroupVersionで確認してから設定を組む必要があります。

systemdサービスとしての起動
rootコンテナは/etc/systemd/system/配下にユニットファイルを置きますが、ルートレスコンテナは~/.config/systemd/user/配下にユーザーユニットとして配置し、loginctl enable-lingerでログアウト後も動作を継続させます。この差異が切り替え時に最も見落とされやすいポイントです。

移行前の環境確認と準備手順

段階移行の原則は「既存rootコンテナを止めずに、ルートレス環境を並行して立ち上げ、動作確認後に切り替える」です。まず現状を記録します。

実行中のrootコンテナと関連する設定を一覧化します。

# rootで動いているコンテナを確認
sudo podman ps -a --format "table {{.ID}} {{.Names}} {{.Status}} {{.Ports}}"

# 使用中のボリュームとbindマウントを確認
sudo podman inspect <コンテナ名> --format '{{json .Mounts}}' | jq .

# 既存のsystemdユニットファイルを確認
systemctl list-units --type=service | grep container

次に移行対象ユーザーのsubUID/subGIDを確認します。

grep ^$(whoami) /etc/subuid /etc/subgid

エントリがない場合はusermod --add-subuids 100000-165535 --add-subgids 100000-165535 <ユーザー名>で追加します。RHEL 9・Ubuntu 24.04では新規ユーザー作成時に自動付与されますが、既存ユーザーには手動対応が必要です。

ルートレスPodmanの動作環境を事前検証します。

# rootなしでpodman infoが通るか確認
podman info

# User Namespace が有効か確認
podman unshare cat /proc/self/uid_map

podman infoのrunRoot・graphRootがユーザーホームディレクトリ配下（/run/user/<UID>・~/.local/share/containers）を指していればルートレス環境として正常に動作しています。

ルートレスコンテナの起動とsystemdユーザーユニット化

既存のrootコンテナと同等の動作をルートレスで再現します。ここではNginxコンテナを例に取ります。

まずルートレスで起動確認します。

podman run -d --name nginx-test \
  -p 8080:80 \
  -v /srv/www:/usr/share/nginx/html:ro,z \
  docker.io/library/nginx:stable-alpine

ポートを8080にしているのは1024番未満を避けるためです。ホスト側で80番への接続が必要な場合は、firewall-cmdやiptablesでポート転送ルールを追加するか、/etc/sysctl.d/でnet.ipv4.ip_unprivileged_port_start=80を設定します。後者はシステム全体に影響するため、セキュリティポリシーの確認が先決です。

動作確認後、systemdユーザーユニットを生成します。

mkdir -p ~/.config/systemd/user/
podman generate systemd --name nginx-test --files --new \
  --restart-policy=always
mv container-nginx-test.service ~/.config/systemd/user/

systemctl --user daemon-reload
systemctl --user enable --now container-nginx-test.service

Podman 4.4以降ではpodman generate systemdはdeprecatedとなり、Quadletが推奨されています。Quadletを使う場合は~/.config/containers/systemd/nginx.containerにINIファイルを配置し、systemctl --user daemon-reloadだけでユニットが自動生成されます。2026年環境では新規構成はQuadletで書くのがベストプラクティスです。

ログアウト後もサービスを継続させるにはlingerを有効にします。

loginctl enable-linger $(whoami)
# 確認
loginctl show-user $(whoami) | grep Linger

移行後の動作検証チェックリスト

ルートレスコンテナを本番相当の条件で検証する際、確認すべき項目を運用観点で整理します。

起動・再起動の確認
サーバー再起動後にルートレスコンテナが自動起動するかを確認します。systemctl --user status container-nginx-testでActiveになっていること、およびjournalctl --user -u container-nginx-testにエラーがないことを確認します。

ネットワーク疎通の確認
コンテナ内から外部への名前解決と通信が可能かを確認します。

podman exec nginx-test curl -s https://example.com -o /dev/null -w "%{http_code}"

ルートレス環境ではDNS解決に/etc/resolv.confの内容が引き継がれますが、systemd-resolvedを使っているホストでは127.0.0.53がコンテナ内で機能しないことがあります。その場合はpodman run --dns=8.8.8.8か、containers.confの[network]セクションでDNSサーバーを明示します。

ボリュームの読み書き確認
bindマウントしたディレクトリへの読み書きが想定通りか確認します。SELinuxが有効な環境では:zを付けていても、ポリシーによって拒否される場合があります。ausearch -m avc -ts recentでAVCデナイルが記録されていないかを確認します。

リソース制限の確認
cgroup v2環境であれば--memory・--cpusオプションが機能します。podman stats <コンテナ名>でリソース消費を確認しつつ、意図したリミットが適用されているかcat /sys/fs/cgroup/user.slice/user-<UID>.slice/memory.maxで確認できます。

切り戻し手順と移行後の注意点

問題が発生した場合の切り戻しは、rootコンテナ側のsystemdユニットを再度有効化することで対応します。段階移行の原則通り、rootコンテナのユニットファイルはあらかじめsystemctl disableで停止しておくだけにして、削除はしないでください。

# ルートレスサービスを停止
systemctl --user stop container-nginx-test
systemctl --user disable container-nginx-test

# rootコンテナのユニットを再有効化
sudo systemctl enable --now container-nginx-prod.service

ルートレス環境のストレージとrootコンテナのストレージは完全に分離されています。ルートレス側でpodman pullしたイメージはrootコンテナには引き継がれず、逆も同様です。移行の際に「同じイメージタグなのに動作が違う」という問題が起きる場合、ダイジェストが一致しているかをpodman image inspect <image> --format '{{.Digest}}'で確認します。

永続データを含むボリューム（named volume）もrootとルートレスでは格納場所が異なります。rootの場合は/var/lib/containers/storage/volumes/、ルートレスの場合は~/.local/share/containers/storage/volumes/です。データを引き継ぐ場合はpodman volume exportとpodman volume importを使うか、bindマウントに切り替えてホストパスで共有するのが確実です。

2026年時点での運用環境において、特に注意が必要な点を付記します。RHEL 9.4以降・Fedora 41以降ではPodmanのデフォルトネットワークバックエンドがNetavarkに統一され、CNIプラグインのサポートが縮小されています。既存のCNIベースのカスタムネットワーク設定がある場合は、Netavark形式への書き直しが必要です。また、Podman 5.x（Fedora 41に同梱）ではpodman generate systemdが完全に削除されており、Quadletへの移行が必須となっています。RHEL 9系ではPodman 4.x系が継続提供されているため、ディストリビューションごとのバージョンをpodman --versionで確認してから手順を選択してください。

rootコンテナからルートレスへの移行は一度で完結させる必要はありません。サービス単位で並行稼働期間を設け、ネットワーク・ボリューム・リソース制限の動作を個別に確認してから切り替えるアプローチが、現場では最もリスクが低いとされています。