Go to Qiita Advent Calendar Top
LoginSignup
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@ootakazuhiko(太田 和彦)in株式会社アイティードゥ

DockerユーザーのためのPodman移行ガイド

Posted at

Dockerは知っているけれど、Podmanも試したい・移行したい――そんな人向けの「差分」＆「乗り換え」の実践ガイドです。
この記事では、以下のような疑問に答えます。

  • PodmanはDockerと何が違うのか
  • 既存のDocker環境をどこまでそのまま流用できるのか
  • docker コマンドに慣れていてもスムーズに移行するにはどうすればよいか
  • 本番環境で移行するときにどこに気をつければよいか

すでにDockerの基本操作は知っている前提で、**「Dockerとの違い・互換性」と「現実的な移行パターン」**にフォーカスします。

※Podmanそのものの概要やインストール方法は、別記事「Podmanの基本的な使い方ガイド 2025年版」を参照してください。

1. なぜ Docker から Podman を検討するのか

1-1. コンテナランタイムの選択肢が増えた

Docker は「コンテナといえばDocker」という時代を作りましたが、現在は以下のようにコンポーネントが分離してきています。

  • コンテナランタイム（runc / crun など）
  • イメージ管理・CLI（Docker / Podman / nerdctl など）
  • オーケストレーション（Kubernetes / Nomad など）

Podmanはその中で**「Docker互換CLIを持つ、デーモンレスなコンテナエンジン」**というポジションにいます。

1-2. rootless コンテナとセキュリティ

企業利用・マルチユーザーサーバーでは、root権限で動く常駐デーモン（dockerd）がポリシー上NGのケースがあります。

Podmanの特徴:

  • デーモン（dockerd）を持たない
  • 各ユーザーが自分の権限でコンテナを起動する
  • rootless実行が前提として設計されている

つまり、「1台のLinuxを複数の人が使う環境で、各自が安全にコンテナを使う」というユースケースに向いています。

1-3. 既存Docker資産をほぼそのまま活かしたい

Dockerfileやdocker-compose.ymlをすでにたくさん持っている場合、ゼロから書き換えたくはありません。
Podmanは以下の点で、Docker資産を活かしやすい設計になっています。

  • Docker互換のCLI（podman run はほぼ docker run と同じ）
  • Dockerfileをそのままビルド可能
  • docker-compose.ymlを podman compose で利用可能（※完全互換ではないがかなり近い）

2. CLI互換性と alias docker=podman の是非

2-1. 基本的なコマンドはほぼ同じ

たとえば、Dockerでよく使う以下のようなコマンドは、Podmanでもほぼ同じ構文で動作します。

# Docker
docker run --rm -it alpine:latest sh
docker ps
docker images
docker build -t myapp:latest .
docker logs myapp
docker exec -it myapp bash

# Podman
podman run --rm -it alpine:latest sh
podman ps
podman images
podman build -t myapp:latest .
podman logs myapp
podman exec -it myapp bash

オプションが全く同じではないものの、**日常的に使う範囲では「ほぼコピペで動く」**感覚です。

図: Docker CLI と Podman CLI の互換イメージ

2-2. alias docker=podman はアリか

既存のシェルスクリプトや手が覚えているコマンドを考えると、以下のようなエイリアスを設定したくなります。

alias docker=podman

これは実際に多くの人が使っている方法で、**「手を慣らすフェーズ」**では有効です。
ただし、以下の点に注意してください。

  • DockerとPodmanが同一環境に共存している場合、どちらを呼んでいるか混乱しやすい
  • 将来的に「Podman固有の機能」を使い始めると、podman コマンドを明示したほうが設計上わかりやすくなる

実務的には、

  1. 初期は alias docker=podman で慣れる
  2. チームや本番環境のスクリプトは、早めに podman 明示に揃える

くらいの運用が無難です。

3. Docker と Podman の違い（アーキテクチャ編）

3-1. デーモンの有無

Docker:

  • dockerdという常駐デーモンがroot権限で動く
  • CLIはdockerdに対してHTTPでAPIリクエストを投げる

Podman:

  • デーモンレス（常駐プロセスなし）
  • CLIが直接コンテナランタイムを呼び出す（コンテナ単位でプロセスとして存在）

これにより、Podmanでは**「ユーザーごとに完全に分離されたコンテナ環境」**が作りやすくなります。

図: Docker と Podman のアーキテクチャ比較

3-2. イメージストアとコンテナの扱い

概念上は似ていますが、実装は異なります。

  • イメージの格納ロケーション
  • rootless時のストレージドライバ
  • namespace や uid/gid mapping の扱い

などは異なるため、「Dockerと同じディレクトリ構造を前提にした運用」はそのまま持ち込まないほうが安全です。

3-3. ネットワーク周りの違い

Docker:

  • デフォルトでDocker独自のbridgeネットワークを作成
  • docker run -p 8080:80 でホストにポート公開

Podman（rootlessの場合）:

  • slirp4netns などを使ったユーザー空間ネットワーク
  • -p オプションが利用可能だが、rootless特有の制約がある
  • 1024番未満のポートを直接開けないなどの制限

rootful Podman（sudo podman）であれば、Dockerに近い動作に寄せることも可能です。
運用ポリシーに応じて

  • 開発：rootless Podman
  • 本番：rootful Podman または別の構成（systemd＋firewalldで制御）

のように使い分けるとよいです。

4. よく使う Docker コマンドとの対応表

Dockerに慣れている人向けに、典型的なコマンドの対応を一覧で整理します。

4-1. コンテナ操作

やりたいこと Docker Podman 備考
コンテナ一覧 docker ps podman ps -a も同じ
コンテナ起動 docker run ... podman run ... ほぼ同じ
コンテナ停止 docker stop CONTAINER podman stop CONTAINER
コンテナ削除 docker rm CONTAINER podman rm CONTAINER
ログ表示 docker logs CONTAINER podman logs CONTAINER
exec で中に入る docker exec -it CONTAINER sh podman exec -it CONTAINER sh

4-2. イメージ操作

やりたいこと Docker Podman
イメージ一覧 docker images podman images
イメージ取得（pull） docker pull IMAGE:TAG podman pull IMAGE:TAG
イメージ削除 docker rmi IMAGE podman rmi IMAGE
ビルド（Dockerfile） docker build -t NAME . podman build -t NAME .

4-3. 便利コマンド

Podman固有で便利なものとして、次のようなものがあります。

  • podman generate systemd
    → systemdのユニットファイルを自動生成
  • podman generate kube / podman play kube
    → Kubernetes YAML の生成／適用

これらは「移行後にPodmanを活かす」フェーズで効いてきます。

5. volume / network 周りの差分と注意点

5-1. 名前付きボリューム

Docker:

docker volume create mydata
docker run -v mydata:/var/lib/mysql ...

Podman:

podman volume create mydata
podman run -v mydata:/var/lib/mysql ...

構文は同じですが、実際のパスや権限の扱いが異なるため、rootless環境でDBを動かす際は権限やパーミッションをチェックしてください。

5-2. bind mount のパーミッション

-v /host/path:/container/path のようなbind mountでは、

  • Dockerではrootが書き込む前提が多い
  • Podman rootlessでは、ホスト側のディレクトリ所有者が「ホストユーザー」である必要がある

など、所有者と権限の整合性をきちんと意識する必要があります。

5-3. ネットワークとポート

  • -p 8080:80 はどちらも使えるが、rootless Podmanでは1024未満のポートに制限あり
  • 複数コンテナ間通信は、Podmanのネットワーク（pod）やCNI設定に依存

図: rootless Podman におけるポート公開イメージ

複数コンテナ構成は、後述の podman compose を使うとDockerに近い感覚で管理しやすくなります。

6. Docker Compose → Podman Compose への乗り換え

6-1. podman compose の位置づけ

Podmanには、Docker Compose互換を目指した podman compose サブコマンドがあります。
概念的には、**「docker-composeコマンドのPodman版」**と考えて問題ありません。

典型的な使い方:

podman compose up -d
podman compose down
podman compose ps

6-2. 既存 docker-compose.yml を試す

まずは、既存の docker-compose.yml をそのまま持ってきて試すのがよいです。

# 例：docker-compose.yml をそのまま利用
podman compose up -d

動かしてみて問題が出るのは、主に以下のような箇所です。

  • 特殊なネットワーク設定
  • volume のマウント（特にrootless）
  • Docker独自拡張に依存している部分

6-3. よくある修正ポイント

  • privileged: true に頼っている部分は、Podman rootlessではそのまま動かない可能性が高い
  • /var/run/docker.sock をマウントしているような構成（Docker in Docker的なもの）は設計から見直したほうがよい
  • depends_on やヘルスチェックの挙動が微妙に違うことがあるため、起動順序やリトライロジックはアプリ側で持つほうが堅い

7. 実例：シンプルなWeb+DB構成をDocker→Podmanへ移行する

ここでは、非常にシンプルなWebアプリ＋DBの構成を例に、

  1. Docker Composeで動いているものを
  2. Podman環境に持っていく

という流れを示します。

7-1. もともとの docker-compose.yml（例）

version: "3.9"
services:
  web:
    build: ./web
    ports:
      - "8080:80"
    depends_on:
      - db
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: example
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  db-data:

7-2. Podman 環境でそのまま動かしてみる

podman compose up -d
podman compose ps

エラーが出ないか、ログを確認します。

podman logs <webコンテナ>
podman logs <dbコンテナ>

rootless環境でDBのvolumeが権限エラーになる場合は、

  • ホストのディレクトリをbind mountに変更
  • 所有者を実行ユーザーに揃える

といった調整を行います。

例:

volumes:
  db-data:
    driver: local
    driver_opts:
      type: none
      o: bind
      device: /home/devuser/data/db

図: Web + DB 構成のコンテナ間関係

8. 本番環境で移行するときのチェックリスト

開発環境での動作確認が取れたとしても、本番移行では以下の点を改めて確認してください。

8-1. セキュリティ・権限

  • rootlessで運用するか、rootfulで運用するかを方針として決めたか
  • コンテナ実行ユーザー（UID/GID）の管理方法を決めたか
  • bind mountするディレクトリの所有者・パーミッションは適切か

8-2. ネットワーク・ファイアウォール

  • Podmanのネットワーク（CNI）とホストのfirewall（firewalld, nftablesなど）の整合性
  • 公開ポート・閉じるポートが明確になっているか
  • ロードバランサやリバースプロキシとの組み合わせ設計

8-3. ログ・バックアップ・監視

  • ログの保管場所（コンテナ内か、ホストのディレクトリか）
  • バックアップ（DB・設定ファイルなど）の取得方法
  • 監視（プロセス生存監視・メトリクス）の設計

podman generate systemd を使って systemd のユニットを作成し、

  • 起動順序
  • 自動再起動
  • ログ出力

をOS標準の仕組みで統合すると、Docker時代よりシンプルに運用できるケースも多いです。

9. 移行の進め方（段階的アプローチ）

DockerからPodmanへの移行は、一気にやる必要はありません。
現実的には、以下のような段階を踏むことをおすすめします。

  1. 開発環境にPodmanを導入

    • 個人環境で podman run を試す
    • alias docker=podman を使って手を慣らす

  2. CI・テスト環境への導入

    • podman build でイメージをビルド
    • podman compose でテスト用環境を立てる

  3. 一部サービスをPodmanに切り替え

    • 影響範囲の小さいサービスから移行
    • podman generate systemd でOSレベルの起動制御に切り替え

  4. 本番環境の標準ランタイムとして位置付け

    • オペレーション手順書をPodman前提で再整備
    • 権限管理・監視・バックアップをPodman前提に再設計

図: Docker から Podman への段階的移行ステップ

10. まとめ

  • Podmanは、Docker互換のCLIを持つデーモンレスなコンテナエンジンで、rootless運用やマルチユーザー環境に強みがあります。

  • podman run / podman build / podman compose など、Dockerユーザーにとって馴染みのあるコマンドがそのまま使えます。

  • ただし、volumeやネットワーク、権限周りの挙動には違いがあるため、本番移行前に必ず確認が必要です。

  • 段階的に、

    • 個人開発環境
    • CI・テスト環境
    • 一部本番サービス
    • 全体の標準ランタイム
      という順に移していくのが現実的です。

関連記事

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?