4
3

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(太田 和彦)Team Tea & Waterin株式会社アイティードゥ

Podman入門 2026: Dockerユーザー向け基本コマンド・Compose・Quadlet

4
Posted at

はじめに

以前、DockerユーザーのためのPodman移行ガイド で、Docker から Podman へ移るときに気になりやすい差分と、移行時に押さえるべきポイントを整理しました。この記事はその補完として、Podman 自体の基本操作と現行仕様を 2026 年版として整理し直した基礎ガイドです。

Docker との違いや移行判断を先に見たい場合は前記事、本記事ではインストール、基本コマンド、Compose、Quadlet、rootless / rootful の注意点までをまとめます。単体でも読めますが、2 本を通して読むと「移行の判断」と「実務での使い方」を分けて把握できます。

Podman は Docker 互換 CLI を持つ daemonless なコンテナエンジンです。Docker の基本操作が分かっている人なら、学習コストはそれほど高くありません。

ただし、2026 年時点で Docker と同じ感覚のまま使うとハマる点が 3 つあります。

  1. macOS / Windows では Linux VM (podman machine) 前提
  2. podman compose は Compose の実装本体ではなく、外部 provider を呼ぶ
  3. 長期常駐サービスの systemd 連携は podman generate systemd より Quadlet を前提にする

この記事は、この 3 点を軸に、実務で必要な差分だけを整理します。

まず押さえるべきポイント

結論から書きます。

  • Linux ではかなり素直に使える
  • macOS / Windows は「ローカルで Linux コンテナを動かしている」というより、「ローカルの VM 越しに操作している」と理解した方が正確
  • Compose は Docker と完全互換だと期待しない方がよい
  • 長期運用するなら Quadlet を覚えた方がよい
  • rootless / rootful の違いを曖昧にすると、コンテナやイメージが「消えた」ように見える

Podman が向くケース / 向かないケース

向くケース

  • Docker CLI に近い操作感を維持したい
  • daemonless で運用したい
  • Linux で rootless 実行を優先したい
  • systemd と自然に統合したい

向かないケース

  • Compose 周りも Docker と完全同一だと思っている
  • macOS / Windows で VM 境界を意識したくない
  • Kubernetes 級のオーケストレーションを期待している

インストール

Linux

ディストリビューションのパッケージを使うのが基本です。

# Ubuntu / Debian
sudo apt-get update
sudo apt-get -y install podman

# Fedora
sudo dnf -y install podman

インストール後は、まず情報を確認します。

podman version
podman info

macOS

macOS では Linux カーネルがないため、podman machine の VM 上でコンテナが動きます。
公式 installer を使う方が無難です。Homebrew は非推奨です。

初回セットアップは以下です。

podman machine init
podman machine start
podman info

Windows

Windows でも podman machine 前提です。
Provider は WSL と Hyper-V を選べます。

  • 既に WSL ベースの開発環境があるなら WSL が無難
  • 組織ポリシーや分離要件があるなら Hyper-V を検討

初回セットアップ例です。

podman machine init
podman machine start
podman info

Provider を明示したい場合は次のようにできます。

podman machine init --provider wsl

podman machine init --provider hyperv

最初に確認しておくコマンド

まずはこのあたりを叩いておけば十分です。

podman version
podman info
podman ps -a
podman images
podman network ls
podman volume ls

macOS / Windows なら machine 側も見ます。

podman machine list
podman machine inspect

イメージ操作

イメージ取得は Docker とほぼ同じです。

podman search nginx
podman pull docker.io/library/nginx:1.27
podman images

不要になったイメージを消す場合:

podman rmi docker.io/library/nginx:1.27

実務では 短縮名より fully-qualified image name を使う 方が安全です。
少なくとも README、Compose、Quadlet では省略しない方がいいです。

コンテナの基本操作

podman run --name web -d -p 8080:80 docker.io/library/nginx:1.27
podman ps
podman logs -f web
podman exec -it web /bin/sh
podman stop web
podman rm web

使い方はかなり Docker に近いです。
まずは run / ps / logs / exec / stop / rm を押さえれば十分です。

ボリューム

永続データを扱うなら named volume を使います。

podman volume create pgdata

podman run -d \
  --name pg \
  -e POSTGRES_PASSWORD=secret \
  -v pgdata:/var/lib/postgresql/data \
  docker.io/library/postgres:17

一覧確認:

podman volume ls
podman volume inspect pgdata

削除:

podman volume rm pgdata

バインドマウント

開発用途では bind mount もよく使います。

podman run --rm -it \
  -v "$(pwd)":/work \
  -w /work \
  docker.io/library/node:22-alpine \
  node -v

ただし、macOS / Windows は VM 越しなので、Linux より filesystem 周りの違いを意識した方がいいです。
「ホストのディレクトリをそのまま触っている」感覚で運用すると、性能や共有設定で差が出ます。

ネットワーク

Podman は新規環境では netavark が既定です。
また rootless networking は古い記事で slirp4netns 前提になっていることがありますが、今は pasta が既定です。

まずは一覧を見るところからで十分です。

podman network ls

ユーザー定義ネットワークを作る例:

podman network create app-net

podman run -d --name api --network app-net docker.io/library/nginx:1.27
podman run --rm --network app-net docker.io/library/busybox:latest nslookup api

ネットワーク周りで挙動が読めないときは、まずこれを確認します。

podman info --format '{{.Host.NetworkBackend}}'
podman info --format '{{.Host.CgroupsVersion}}'

Pod を使う

Pod は Podman の特徴のひとつです。
Docker ユーザーには馴染みが薄いですが、関連コンテナをまとめて扱いたいときに便利です。

podman pod create --name webpod -p 8080:80
podman run -d --pod webpod --name nginx docker.io/library/nginx:1.27
podman pod ps

停止と削除:

podman pod stop webpod
podman pod rm -f webpod

Pod が不要なら無理に使う必要はありません。
ただし、systemd や kube 連携まで見るなら、Podman は「コンテナ単体」だけのツールではないと理解しておくと整理しやすいです。

Compose は「内蔵機能」ではない

ここが一番誤解されやすいです。

podman compose は Compose を内蔵実装したコマンドではありません。
docker-compose や podman-compose のような外部 provider を呼ぶ薄いラッパーです。

つまり、以下の前提で考えた方が安全です。

  • Podman を入れただけで Compose 実装まで全部そろうとは限らない
  • チームで使う provider を決めた方が事故が少ない
  • README と CI で provider を明示した方がよい

まずは provider の状態を確認します。

podman compose version

起動例:

podman compose up -d
podman compose ps
podman compose down

compose.yml の例:

services:
  web:
    image: docker.io/library/nginx:1.27
    ports:
      - "8080:80"

provider を固定したい場合は、環境変数で明示できます。

export PODMAN_COMPOSE_PROVIDER=/usr/bin/docker-compose

または:

export PODMAN_COMPOSE_PROVIDER=/usr/bin/podman-compose

チーム運用での実務的な方針はこれです。

  1. provider を固定する
  2. podman compose version を README や CI で確認する
  3. Compose 依存が重いなら「Docker 完全代替」と決めつけない

長期運用は Quadlet を前提にする

2026 年時点では、systemd 連携でまず覚えるべきなのは Quadlet です。
podman generate systemd は deprecated 扱いで、急ぎのバグ修正は入っても新機能の中心ではありません。

Quadlet は、コンテナ・pod・volume・network・image などを systemd unit ファイルで宣言的に管理する仕組みです。

rootless で nginx を常駐させる最小例

配置先:

mkdir -p ~/.config/containers/systemd

~/.config/containers/systemd/web.container

[Unit]
Description=nginx container on Podman

[Container]
Image=docker.io/library/nginx:1.27
ContainerName=web
PublishPort=8080:80
AutoUpdate=registry

[Service]
Restart=always
TimeoutStartSec=900

[Install]
WantedBy=default.target

反映:

systemctl --user daemon-reload
systemctl --user enable --now web.service
systemctl --user status web.service

ポイントは以下です。

  • rootless の配置先は ~/.config/containers/systemd/
  • rootful の配置先は /etc/containers/systemd/
  • AutoUpdate=registry を使うなら fully-qualified image name を使う
  • image pull に時間がかかる環境では TimeoutStartSec を伸ばす

ログ確認:

journalctl --user -u web.service -f

ログアウト後も user service を生かしたい場合は、必要に応じて linger を有効にします。

loginctl enable-linger $USER

podman generate systemd を使うべき場面

完全に不要ではありません。
既存コンテナから unit を起こして挙動確認したい場面では、まだ使えます。

ただし、新規に本番や長期運用の定義を書くなら Quadlet を優先した方がいいです。
今から新規記事や社内標準を作るなら、Quadlet を中心に据えた方がよいです。

Docker ユーザーがハマりやすい点

1. rootless と rootful は別世界

rootless と rootful は同じものではありません。
切り替えると、コンテナやイメージが「消えた」ように見えることがありますが、単に見ている storage / connection が違うだけのことが多いです。

確認例:

podman info --format '{{.Host.Security.Rootless}}'
podman ps -a
sudo podman ps -a

macOS / Windows で podman machine set --rootful を使う場合も同じです。
root と rootless で見える世界が分かれる前提で運用した方が安全です。

2. 低いポートや特権操作は rootless で詰まることがある

80/443 のような低いポート、特権前提の処理、デバイス操作などは rootless で素直にいかないことがあります。
その場合は rootful を使うか、設計を変えるかを先に決めた方が早いです。

3. macOS / Windows は「実体が VM 側」にある

ローカルで CLI を叩いていても、コンテナの実体は VM 側です。
トラブル時は podman machine 系コマンドを見ます。

podman machine list
podman machine ssh
podman machine inspect

4. 認証ファイルの場所は Docker と完全には同じではない

podman login の既定 authfile は Docker と同じ場所ではありません。
ただし Docker の config.json を参照するフォールバックがあります。

CI や自動化では、どの資格情報ファイルを使うかを明示した方が安全です。

2026 年の注意点

1. macOS / Windows は machine 側の更新も見る

ホストに Podman CLI を入れただけで終わりではありません。
machine 側の OS 更新も確認対象です。

macOS と Windows の Hyper-V provider では、まず次を確認します。

podman machine os upgrade

ただし Windows の WSL provider は例外です。
WSL ベースの machine はこのコマンドで更新しない前提で考えた方が安全です。

2. 古い環境からの更新では DB 移行に注意する

最近の Podman では、古い BoltDB から SQLite への移行に注意が必要です。
起動や更新で詰まる場合は、以下を確認します。

podman system migrate --migrate-db

特に 5.8.0 には Quadlet 利用時の DB 自動移行に関する既知の不具合があるため、該当しそうなら 5.8.1 以降で確認した方がいいです。

実務でのおすすめ運用方針

最後に、実務で事故を減らすための方針を整理します。

  • イメージ名は fully-qualified で書く
  • Compose provider を固定する
  • rootless / rootful のどちらを標準にするか決める
  • 長期常駐は Quadlet で管理する
  • README に podman version, podman compose version, podman info の確認手順を書く
  • macOS / Windows は podman machine も運用対象に含める

まとめ

Podman 自体は難しくありません。
難しいのは、Docker と完全に同じだと思い込むことです。

押さえるべき差分はこの 4 点です。

  1. macOS / Windows は VM 前提
  2. Compose は外部 provider
  3. systemd 連携は Quadlet
  4. rootless / rootful を混ぜない

この 4 点を理解していれば、Docker ユーザーでもかなりスムーズに移行できます。
逆にここを曖昧にしたまま使うと、「動くけど運用が安定しない」状態になりやすいです。

参考

4
3
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
4
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?