はじめに

Docker か Podman か

Docker と Podman はコマンド互換性が高い一方、設計思想が異なります。daemonless・rootless・systemd 連携の違いから、選択の指針を整理します。

Docker か Podman か diagram

CLI の互換性

Podman の設計上の目標の 1 つが Docker CLI との互換性で、多くのサブコマンドがそのまま置き換え可能です。

docker run --rm -it alpine sh
podman run --rm -it alpine sh
# どちらもほぼ同じ挙動

alias docker=podman として運用する現場もあります。

Compose についても podman compose または docker-compose コマンドが Podman の API と連携できます。

ただし完全に同じではなく、次のような差があります。

  • Docker Swarm 相当の機能はない
  • docker buildx のすべての機能が揃っているわけではない(Podman では代わりに Buildah を使う)
  • ネットワークの既定ドライバや DNS の振る舞いが一部異なる

daemonless: 常駐デーモンの有無

Docker は dockerd という 常駐デーモンが root 権限で動くアーキテクチャで、クライアント(docker CLI)がそれに REST API で接続します。

Podman は デーモンレスで、podman コマンドが直接 OCI ランタイムを呼び出します。

これには次の利点があります。

  • デーモンの単一障害点がない
  • 「root で動くデーモン」を狙う攻撃面が減る
  • systemd のユニットとしてコンテナをそのまま登録できる

一方で、Kubernetes / Docker API を期待するツール(Portainer、CI の一部 step など)と組み合わせる場合は、podman system service で API ソケットを立ち上げる必要があります。

rootless: 一般ユーザーでコンテナを動かす

Podman の大きな特徴が rootless 運用の容易さです。

user namespace と newuidmap / newgidmap を使い、一般ユーザー権限でコンテナを起動できます。

docker グループに入れなくて済むので、マシン全体の root 権限を配らなくて済みます。

Docker にも rootless モードはありますが、有効化するには dockerd-rootless-setuptool.sh install などの追加設定が必要で、既定ではありません。

また、ポート 80 / 443 のバインドや一部ネットワーク機能は rootless だと制限があります(setcap などで緩和可能)。

項目 Docker Podman
既定での root 要否 デーモンが root 不要
rootless 有効化の手間 追加セットアップが必要 既定で使える
<1024 ポートのバインド 通常は可 設定 (sysctl net.ipv4.ip_unprivileged_port_start) が必要

systemd 連携と長期運用

Podman は systemd との親和性が高く、podman generate systemd でコンテナから .service ユニットを出力できます。

ユーザーユニット(systemctl --user)としても動くので、一般ユーザー権限で自動起動・再起動・ログ収集まで systemd に任せられます。

さらに最近は Quadlet という仕組みで、.container / .volume / .network ファイルを /etc/containers/systemd/ に置くだけで、systemd が自動でユニット化してくれるようになっています。

Docker Engine にも --restart=always やユニットからの docker run 呼び出しはありますが、「コンテナが 1 級の systemd サービスになる」感覚は Podman + Quadlet のほうが自然です。

サーバーで docker-compose up -d しっぱなしにしているような運用を、systemd ユニットに置き換えていく用途で Podman を採用するケースが増えています。

どちらを選ぶかの指針

実務での選択は次のような軸で整理できます。

  • 個人開発・学習目的: 情報量の多さから Docker Desktop / Colima / OrbStack が無難。Podman も引けは取らないが、エラーメッセージをググったときに Docker のほうが事例が豊富
  • 商用利用・社内ポリシーがシビア: Docker Desktop の商用ライセンスを回避したいなら Podman / Colima / Rancher Desktop が候補
  • 本番サーバー(Linux): Kubernetes を使うなら containerd もしくは CRI-O。単独サーバーで数本のコンテナを動かすなら Podman + Quadlet は相性がよい
  • CI/CD: GitHub Actions・GitLab CI は Docker 前提のステップが多い。Podman をビルドランナーにするなら Docker API ソケットを有効化しておくか、Buildah 等を使う
  • Windows で開発: Docker Desktop か Podman Desktop が現実解。どちらも WSL2 を活用する

最後に重要なのは、どちらも OCI 標準に沿っているため、イメージは相互に互換ということです。

Podman でビルドしたイメージを Docker ホストで動かすのも、その逆も問題なくできます。