ハクソク

世界を動かす技術を、日本語で。

Podman、Compose、BuildKitの利用

277日前原文(emersion.fr)

概要

  • Podman で Docker Compose プロジェクトを扱う課題と解決策の解説
  • BuildKit 利用のための設定手順と注意点
  • Bake を活用したビルドプロセスの簡略化
  • Bakah ツールによるComposeビルドの効率化
  • 今後の活用例と soju-containers への応用計画

PodmanでDocker Composeプロジェクトを運用する課題

  • Docker は nftables との相性や rootless/daemonless 運用に制約
  • Podman はDocker Compose互換を2方式で提供
    • 公式 Docker Compose CLI をPodmanソケットへ接続
    • 独自の podman-compose ラッパーを利用
  • 公式CLI利用時は BuildKit が無効化され、追加コンテキスト等の機能が未対応
  • podman-compose 利用時は一部Compose機能（!reset, configs, サービス参照等）が未実装
  • podman-compose の機能追加は追従作業が多く、Python実装のためモチベーション低下

BuildKitをPodmanと連携させる方法

  • Docker Compose CLI をPodmanソケットに直結し、 BuildKit を有効化する手順
    • podman-compose ラッパーはBuildKitを強制的に無効化
    • Arch Linuxの場合の設定例
      • pacman -S docker-compose docker-buildx
      • systemctl --user start podman.socket
      • docker context create podman --docker host=unix://$XDG_RUNTIME_DIR/podman/podman.sock
      • docker context use podman
  • この設定で docker compose がBuildKitコンテナを自動生成
  • 自動生成を避けたい場合はBuildKitデーモンを手動で起動
    • pacman -S buildkit
    • systemctl --user start buildkit.service
    • docker buildx create --name local unix://$XDG_RUNTIME_DIR/buildkit/rootless
    • docker buildx use local
  • これで docker compose がsystemd管理のBuildKitサービスを利用

デーモンレス・BuildKit非依存ビルドの工夫

  • Podman の魅力は デーモンレス 運用
  • BuildKitデーモン常駐は理想ではないため、ビルドを Bake で記述
  • docker buildx bake --printでComposeプロジェクトをJSON形式のBakeファイルに変換
  • COMPOSE_BAKE=true 設定でDocker Compose CLIがBakeファイルを利用（v2.33以降対応）
  • BakeはHCLファイル等も扱えるが、JSON変換で十分

Bakahツールによるビルドプロセスの簡略化

  • Bake JSON ファイルと podman build コマンドの引数は類似
  • Bake JSONを Buildah で直接ビルドするツール Bakah を開発
    • BuildahはPodmanのビルド基盤
  • Bakah の特徴
    • 依存関係解決、並列ビルド等の基本機能を実装
    • HCL・継承・変数等の高度なBake機能は未対応
  • 使い方例
    • docker buildx bake --print >bake.json
    • bakah --file bake.json
  • 複雑なComposeプロジェクトのビルドにも十分対応

今後の展望とsoju-containersへの応用

  • soju-containers での複数Dockerfile（バックエンド・フロントエンド分離）管理に活用予定
  • CIシェルスクリプトのPodman CLI呼び出し部分の廃止計画
  • Bakah の今後の発展と、他ユーザーへの有用性の期待

Hackerたちの意見

数ヶ月前に、まさにこの問題（Podmanでのbuildkitなし）に直面したことがあるよ。諦めてDocker Desktopを使ったけど、君は頑張ったんだね。素晴らしい！

docker-composeにこだわらないなら、Podmanのkubeサポートを使うといいよ。これはKubernetesのポッドデプロイメント構文の一部を使って、docker-composeに近い機能を提供してくれるんだ。さらに、Podmanはkubeサービスのためのsystemd統合もあって、短いsystemdの設定スニペットを書くだけで、他のsystemdサービスと同じようにkubeサービスを管理できるよ。Kubernetesの全機能を使わずにコンテナ化されたサービスをデプロイするには、すごくいい組み合わせだね。

└

（私はPodmanの大ファンです）最後に.kubeファイルを使おうとしたとき、コンテナネットワークの指定で問題が発生したんだ（https://github.com/containers/podman/issues/12965）。Quadletの“.kube”を使うことで一応「修正」されたけど、個人的にはそれはかなり弱い解決策だと思うし、「これがあなたのコンポーズファイル、実行して」っていう部分がなくなっちゃう。最近（Deb13がPodman 5と共に出たので）PodmanのQuadletファイルに移行し始めたけど、今のところかなりスムーズだよ。君が言うように、Kubernetesのオーバーヘッドなしで動かせるのは素晴らしいね。

└

それって単一ノードに限られてるんじゃない？クラスターをどうやって設定するの？Kubernetesの軽量な代替手段を探しているんだけど、docker swarmみたいな。ポッドやサービスの同等のものをサポートする必要があるなら、選択肢は限られてると思う。

└

短いsystemdの設定スニペットを書くだけで、他のsystemdサービスと同じようにkubeサービスを管理できる。ちなみに、podman generate systemd --files --name mypodを使えば、すべてのsystemdサービスファイルを自動生成してくれるよ。 https://docs.podman.io/en/latest/markdown/podman-generate-sy...

└

PodmanとIncusのパフォーマンス差について気になるな。Incusもすごく柔軟だと思った。

└

自分もそうしてるよ。いろんなやり方を覚えたくないから、「podman play kube」を使うことで、Kubernetesの知識をローカルや小規模なことにも活かせるのがいいんだ。

数ヶ月前にDockerの使用を完全にOrbStackに置き換えたけど、今のところ全く問題なし。ライセンス料を払う価値がある素晴らしい製品だよ。ただ、私の使い方はかなり基本的だから、他の人はどうか分からないけど、私の基本的なウェブ開発環境には完璧だった。

└

orbstackはMacでDockerのためのVMプロバイダーに過ぎないし、colimaはUIなしで同じ機能を提供してくれる素晴らしいオープンな代替品だけど、どちらもPodmanをサポートしてないから、Podmanの議論にはあまり関係ないね。

└

OrbStackの代わりにPodman Desktopを完全に使ってるけど、問題はゼロだよ。OrbStackとは違ってね。特に、OrbStackが使ってる1TBのVMディスクイメージは、バックアップの重複排除にめちゃくちゃ影響を与えるし。ディスクキャッシュのせいで、資産が最新じゃない理由を何時間もデバッグする羽目になったし。まあ、OrbStackのGUIはすごくサクサクだけどね。

残念ながら、かなり大きな混乱があるね（記事にもある通り）。これが「ちょっと画像をビルドしたいだけ」の人にとっては急な学習曲線につながるんだ。それが半分に過ぎないけどね。二つのネイティブアーキテクチャ（ARM64とAMD64）で画像をビルドして、それらからマルチアーキ画像を作りたいんだけど、2025年のDocker技術でそれがどれだけ複雑か、誰かの頭を吹き飛ばすかもね。 https://docs.docker.com/build/ci/github-actions/multi-platfo...

└

qemuを使えば、複雑なマルチノードビルドシステムは必要ないよね。もちろん、パフォーマンスも重要な要素になるけど。

面白い発見だね、OP！これ、DockerからPodmanに移行するのに役立つかも（特にDocker-Composeでデプロイしてる人には）。でも、長期的にはsystemdユーザー単位を使ったデプロイがいいと思うし、もっとモダンな方法としてPodman Quadletsを使うのもありだね。ちょっと学ぶことがあるけど、これらのアプローチはPodmanプラットフォームにより馴染んでるし、systemdサービスの仕組みを理解するのは素晴らしいスキルになるよ。

Podmanの大ファンだったけど、結局あきらめてローカル開発にはDocker Composeを使ってる。システムと戦う価値はないからね。でも、Kubernetesが必要ない単一サーバーのデプロイでは、今はQuadletsだけでアプリを動かしてて、すごく満足してる。普通のDocker/Podmanのセットアップよりもずっと快適だし、システムに統合されてる感じがする。

└

Podmanの大ファンだったけど、結局諦めてDocker Composeを使うようになった。 混ぜて使えるよ。Dockerの代わりにPodmanでdocker-composeを使ってたし、quadletsに切り替える前もそうだった。コンポーズファイルの使い勝手はまだ好きだけど、quadletsはsystemdにうまく統合されてるね。

VPSでPodmanを試してみたけど、すぐにrootless Dockerに戻っちゃった。決定的だったのは、podman composeのバグで、面白いことに2時間前に修正されたばかりなんだ[1]。service1がservice2にdepends_onしてる場合、service1を下げると、他のサービスがそれに依存していても無条件でservice2も下がっちゃう。だから、2つの別々のサービスがデータベースに依存してると、一方を殺すとデータベースも死んじゃう。もう一つ、Dockerとの互換性の問題が2020年に提起されて、数ヶ月前に修正されたんだけど[2]、build:にURLを渡して自動的にイメージをプル＆ビルドできなかったんだ。このパッチは数行で済んだみたい。Podmanはこれらのバグが解消されれば素晴らしいと思うけど、今のところはまだちょっと足りないかな。

└

Podman composeは、Dockerユーザーを引き込もうとする悪いアイデアを移植した試みだね。それよりも、"quadlets"を作る方法を学べば、もうDockerに触れたくなくなるよ。詳しくはここを見てね: https://www.redhat.com/en/blog/quadlet-podman .kubeの代わりに.containerファイルから始めることをおすすめするよ、Kubernetesに詳しくないならね。

└

ソケットモードでrootless Podmanを使ってるけど、フロントエンドとしてDocker CLIを使ってる（CLIだけで、デーモンやサービス、iptablesに触れない）。おすすめだよ！

└

これらのバグが解消されれば それについては、君が言ったばかりだよね。

記事からは明確じゃないけど、これはローカル開発用なのか、それとも本番デプロイ用なの？というのも、Swarmは本番環境でコンテナを動かす際のComposeやPodmanの制限をかなり解消してくれるからね。SwarmはシングルVMでもうまく動くし、Dockerの経験がある人なら1日で使い方を覚えられるよ。

自分は主にDockerを使ってるけど、Podmanにも興味はあるんだよね。ただ、学ぶ時間が取れてないだけなんだ。TFAへの改善提案としては、コンポーズファイルのパスのハッシュを取って、それを一時ディレクトリのプレフィックス名にするってのはどうかな？ハッシュが変わったら、.jsonをダンプして一時パスで再構築する感じで。それからそのファイルに対してバカやればいいし。簡単なスクリプトで作れそう。

いつもpodman(-compose)のcpが恋しいよ…docker(-compose)のcpが便利だったなぁ :(