PodmanかDockerか？毎日Fedoraを使うユーザーからの視点
Fedoraをメインの開発マシンとして2年間使っており、パッケージの更新速度にかなり満足しています。最も早く移行したツールのひとつがPodmanです——トレンドだからではなく、Fedoraにプリインストールされており、rootデーモンを起動する必要がないからです。しかし、Podmanでのイメージ管理ワークフローはDockerと実際に何が違うのでしょうか？答えは：コマンド面ではほぼ同じですが、内部アーキテクチャは全く異なります。
今日は理論の話はしません。イメージ管理の3つのアプローチを直接比較し、実際の違いだけを指摘した後、現在動いているFedoraマシンでbuild/push/pullをデモします。
Fedoraでのコンテナイメージ管理：3つのアプローチ
アプローチ1：FedoraにDocker Engineを追加インストール
この方法は依然として使えます——Docker CEリポジトリを追加し、docker-ceをインストールし、デーモンを起動します。しかし、いくつかの実際の問題があります：
- Dockerデーモンがrootで動作するため、実行するすべてのコンテナにホストへの権限昇格の可能性があります
- Fedoraはカーネルの更新が速く、Docker CEが最新バージョンに対応しきれないことがあります
- 両方が
/var/run/docker.sockを使用する場合、Podmanとの競合が発生します
Docker CEをPodmanと並行してインストールしてみましたが——結果は不要なヘッドエイクでした。
アプローチ2：Podman DesktopでのPodman
Podman DesktopはFlatpakまたはRPM経由でインストールできるGUIアプリです。コマンド入力よりもクリック操作が好みなら、これは良い選択です——イメージやコンテナを管理するダッシュボード、レジストリ接続、Docker Compose互換レイヤーが統合されています。
しかし、私はそこで立ち止まりました。抽象化レイヤーを追加するということは、失敗する可能性のあるレイヤーを追加するということです——エラーが発生した際、GUIが内部でどのコマンドを呼んでいるか調べなければならず、デバッグに2倍の時間がかかります。
アプローチ3：純粋なPodman CLI——私が現在使っている方法
これが開発環境とCIパイプラインに私が選んだ方法です。理由はシンプルです：
- デフォルトでRootless——コンテナがユーザーのnamespace内で動作します
- デーモン不要——
podmanコマンドごとに独立したプロセスが起動し、クラッシュセーフです - OCI準拠——PodmanでビルドしたイメージはDockerレジストリと完全互換です
- Buildahが統合済み——Dockerデーモンなしでイメージをビルドできます
メリット・デメリット分析
| 評価基準 | Docker CE | Podman Desktop | Podman CLI |
|---|---|---|---|
| Rootless | 部分的（Docker rootlessモード） | あり | あり（デフォルト） |
| デーモン | 必要 | 不要 | 不要 |
| Fedora互換性 | リポジトリ追加が必要 | 良好 | プリインストール済み |
| CI/CDフレンドリー | 良好 | 低い | 非常に良い |
| 学習コスト | 低い（慣れている） | 低い | Dockerを知っていれば低い |
FedoraでDockerデーモンを必要とするツールに縛られていなければ——Podman CLIに固執しましょう。失敗する可能性のある箇所が少なく、メンテナンスすべき箇所も少なくなります。
実践：FedoraでのPodmanによるBuild・Push・Pull
ステップ1：Podmanの確認
Fedora 38以降、Podmanはプリインストールされています。簡単な確認：
podman --version
# Podman version 5.x.x
podman info | grep -E 'rootless|cgroup'
# rootless: trueインストールされていない場合：
sudo dnf install -y podmanステップ2：Containerfileの作成（Dockerfileに相当）
PodmanはContainerfileまたはDockerfileのどちらも使用できます。Dockerワークフローではないことを明確にするため、私はContainerfileという名前をよく使います。
FROM fedora:40
LABEL maintainer="[email protected]"
LABEL version="1.0"
RUN dnf update -y && \
dnf install -y python3 python3-pip && \
dnf clean all
WORKDIR /app
COPY requirements.txt .
RUN pip3 install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["python3", "-m", "uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]ステップ3：イメージのビルド
# カレントディレクトリのContainerfileからビルド
podman build -t myapp:1.0 .
# 特定のファイルを指定してビルド
podman build -f Containerfile -t myapp:1.0 .
# ビルド引数を指定してビルド
podman build --build-arg APP_ENV=production -t myapp:1.0 .
# ビルドしたイメージを確認
podman imagespodman imagesの出力はこのようになります：
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost/myapp 1.0 a3f8c21d9e4b 2 minutes ago 412 MB
registry.fedoraproject.org/fedora 40 8f3a1bc2d5e9 3 weeks ago 182 MB注意：Podmanはローカルイメージにlocalhost/プレフィックスを使用しますが、Dockerにはそのようなプレフィックスがありません。小さな違いですが、初めて移行する際によく混乱を招きます。
ステップ4：プッシュ前のイメージのタグ付け
レジストリ（Docker Hub、Quay.io、GitHub Container Registry…）にプッシュするには、正しいフォーマットでタグを付ける必要があります：
# Docker Hub用タグ付け
podman tag localhost/myapp:1.0 docker.io/yourusername/myapp:1.0
podman tag localhost/myapp:1.0 docker.io/yourusername/myapp:latest
# GitHub Container Registry用タグ付け
podman tag localhost/myapp:1.0 ghcr.io/yourusername/myapp:1.0
# Quay.io用タグ付け
podman tag localhost/myapp:1.0 quay.io/yourusername/myapp:1.0ステップ5：レジストリへのログインとプッシュ
# Docker Hubにログイン
podman login docker.io
# Username: yourusername
# Password: yourpassword_or_token
# GitHub Container Registryにログイン（Personal Access Tokenを使用）
echo $GITHUB_TOKEN | podman login ghcr.io -u yourusername --password-stdin
# イメージをプッシュ
podman push docker.io/yourusername/myapp:1.0
podman push docker.io/yourusername/myapp:latest認証情報は~/.config/containers/auth.jsonに保存されます——Dockerの~/.docker/config.jsonとは異なります。ただし、必要に応じてPodmanはDockerのファイルも読み取ることができます。
ステップ6：レジストリからのイメージのプル
# Docker Hubから明示的にプル
podman pull docker.io/yourusername/myapp:1.0
# Fedoraレジストリからプル（例）
podman pull registry.fedoraproject.org/fedora:40
# プラットフォームを指定してプル（クロスプラットフォームビルド向け、M1/M2 Mac用arm64）
podman pull --platform linux/amd64 docker.io/yourusername/myapp:1.0
# プル後の全イメージを確認
podman imagesステップ7：イメージ管理——クリーンアップとインスペクト
ディスクが95%になるまでこのセクションをスキップするのはよくある経験です。そうなる前に対処しましょう：
# イメージの詳細を確認
podman inspect myapp:1.0
# イメージの履歴（レイヤー）を確認
podman history myapp:1.0
# 特定のイメージを削除
podman rmi localhost/myapp:1.0
# 使用されていないイメージをすべて削除（ダングリング）
podman image prune
# コンテナが使用していないイメージをすべて削除
podman image prune -a
# 使用ディスク容量を確認
podman system dfFedoraでのPodman活用のための実践的なヒント
registries.confを使ってフルレジストリパスの入力を省略
/etc/containers/registries.confではunqualified-search-registriesの設定が可能です。システムファイルの編集はお勧めしません——代わりに安全のためにユーザーレベルでオーバーライドを作成します：
mkdir -p ~/.config/containers
cat > ~/.config/containers/registries.conf << 'EOF'
unqualified-search-registries = ["docker.io", "quay.io", "registry.fedoraproject.org"]
EOFイメージサイズ削減のためのマルチステージビルド
# ステージ1：ビルド
FROM fedora:40 AS builder
RUN dnf install -y golang
WORKDIR /src
COPY . .
RUN go build -o myapp .
# ステージ2：ランタイム（最小構成）
FROM fedora-minimal:40
COPY --from=builder /src/myapp /usr/local/bin/myapp
CMD ["/usr/local/bin/myapp"]実際の数字：Goアプリをビルド環境のままにすると通常700〜900MBになります。マルチステージビルドを使えば、ランタイムイメージは40〜80MBになります——レジストリ容量とプル時間を90%以上節約できます。
レジストリを経由しないイメージの保存と読み込み（オフライン転送）
# イメージをtarファイルにエクスポート
podman save -o myapp-1.0.tar localhost/myapp:1.0
# 転送のために圧縮
gzip myapp-1.0.tar
# 別のマシンで読み込む
podman load -i myapp-1.0.tar.gz外部インターネット接続のないサーバーへデプロイする際によく使う方法です——開発マシンでビルドし、ファイルとして保存し、scpでサーバーに転送し、ロードすれば完了です。
まとめ
FedoraとPodmanは自然なコンビです——追加インストール不要、デーモン不要、デフォルトでrootless。build/push/pullのワークフローはDockerとほぼ同じで、localhost/プレフィックスや認証設定のパスといった細かな違いがあるだけです。数日使えば慣れてDockerとの違いはほとんど感じなくなりますが、不要なオーバーヘッドを大幅に削減できます。
DockerベースのCI/CDを持つチームの移行も痛くありません——いくつかのリポジトリで試しましたが、ほとんどはスクリプト内のdockerをpodmanに置き換えるだけで済みました。残りの作業は主に認証設定のパスの修正です。
