Podman v6.0.0 公開

 (blog.podman.io)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 2件のコメント | WhatsAppで共有
  • Podman v6.0.0 は、コンテナ管理体験を磨き上げるメジャーリリースで、コアインフラのモダナイゼーションとセキュリティ・使いやすさの改善をあわせて含む
  • ネットワーキングは slirp4netns・iptables 中心から Netavark・Pasta・nftables ベースへ移行し、保守負担を減らして今後の機能拡張に備える
  • 実験機能の Pesto rootless port forwarding は、カスタムネットワーク上の rootless コンテナで正しい source IP の保持をサポートする
  • Podman Machine は複数の VM プロバイダーの使い勝手を改善し、podman machine os update によって VM 環境を最新の状態に保てるようになった
  • Quadlet、設定ファイル処理、Docker API 互換性、コマンド出力も改善され、マルチユーザー管理や Docker からの移行がしやすくなった

Podman v6.0.0 で変わった点

  • 最新リリースは GitHub リリースページ で確認でき、パッケージマネージャーにもまもなく配布される予定

  • ネットワーキングのモダナイゼーション

    • slirp4netns と iptables から Netavark、Pasta、nftables へ移行
    • 整理されたネットワーキングスタックは保守を単純化し、今後の機能追加の基盤となる
    • Pesto rootless port forwarding の実験的サポートにより、カスタムネットワークの rootless コンテナで正しい source IP を保持できる

  • Podman Machine の改善

    • 複数の VM プロバイダーをよりスムーズに扱えるよう、使い勝手が改善された
    • podman machine os update コマンドで VM 環境を最新の状態に保てる
    • 関連する追加の改善点は、今後別記事でより詳しく扱う予定

  • Quadlet の拡張

    • REST API サポートが追加された
    • 関連ファイルの追跡が改善され、管理しやすくなった
    • .volume ユニット機能が拡張された
    • 配布パッケージングを容易にするための追加の検索パスが含まれる

設定と Docker 互換性

  • 設定ファイル処理 が変わり、マルチユーザー環境を管理する管理者が、よりスムーズかつ信頼性高く利用できるようになった
  • Docker 互換性 も改善された
    • Docker API サポートが更新された
    • コマンド出力が調整され、Docker から Podman へ移行しやすくなった
  • 変更点の一覧は Podman v6.0.0 release notes にまとめられている

関連記事

2件のコメント

 
click 3 시간 전

podman compose が実用的になったら乗り換えようと思っているのですが、いったいいつ実用レベルになるのか分かりません。
最近は docker run で直接実行するのは、一時的なコンテナやテスト実行用くらいだと思っていますが、Compose 対応が弱いのは大きな弱点だと思います。
冗長な設定と厳密な管理が必要なら、もう素直に k8s を使うほうがいいです。
2026年の今、docker や podman の魅力は、k8s のさまざまなリソース定義なしに、シンプルな yml 設定ファイル1つで1つのアプリで使うスタックを全部定義できることなのに、
k8s 互換性を売りにするなら、むしろ k3s や minikube、microk8s のようなローカルで動く軽量な k8s 実装を使うほうがずっと良いです。
rootless が問題だとは思いません。
 
GN⁺ 4 시간 전
Hacker Newsでの反応

  • DockerがなぜいまだにPodmanよりはるかに人気なのか分からない。実装だけ見ればPodmanのほうが明らかに優れているし、新しいネットワーク機能も歓迎すべき改善だと思う

    • デプロイが少し面倒で、分断された手順が多いのが主な理由ではないか。特にルートレスでやろうとするとそうだし、実際そうすべきでもある
      Linux優先ではない人、たとえばアプリのコンテナ化を学び始めた初心者開発者にとって、systemdのユニットファイルやkubeletの設定を扱い、専用のローカルサービスアカウントを作り、lingerの有効化まで覚えておく必要があるのは、Dockerをインストールしてdocker composeファイルを作り、「start」を押すよりかなり威圧感がある
      なぜこういうアプローチを取ったのかは理解できるが、かなり不格好で親切ではない
    • fuse-overlayfsはDockerのoverlayfs構成より明らかに遅かった。再構成する方法があるのかもしれないが、最近は確認していない
      Zigでghosttyをビルドしたとき、Podmanでは曖昧な「unknown file」エラーで失敗した記憶があり、結局fuse-overlayfsが確認しようとしていた一部の属性をサポートしていなかったのが原因だった
      移行しようとするたびに、こうした任意の小さな問題が足を引っ張り続ける。単純な用途では使っている
    • 最後に確認したとき、podman composeはdocker composeと見た目だけ似ている程度だった。inotifyのようなものもPodman側ではランダムに頻繁に壊れるようだ
      Podmanを勧めたい気持ちはあるが、docker compose互換性がよくなく、ボリュームでinotifyが抜けると開発者体験としては大きな問題になる
    • より強いブランド名も理由だと思う。macOSではDocker Desktopのほうが直感的だった。ただ最近はエラーが非常に多くなり、ファイルマウントやネットワークルールの整理がランダムに失敗したり、急に極端に遅くなってVMを再起動しなければならなかったりした
      macOSのPodmanはずっと磨き込みが足りない感じで、OrbStackのほうがはるかに良い選択肢だ
      LinuxでだけPodmanを使っているが、そこでは非常に速い。それでも大半の機能はsystemdと組み合わせてKubernetesを置き換える方向に寄っているようで、肝心のdocker composeサポートは不安定だし、TUI/UXも本家に後れを取っている
    • 些細な理由でPodmanを諦めた。ひとつはDockerと違うやり方でSELinuxを扱うことにしたため、標準のCentOSシステムでSELinuxのセキュリティラベルを変更する作業が必要だった点。これは採用不可だった
      もうひとつの問題はDockerとの差異が小さく積み重なることで、パッケージ化されたDocker composeがそのまま動かないほどだった。Dockerに戻せばすぐ動いてその日の仕事を続けられるのに、それをデバッグすることに時間を使いたくなかった

  • Docker Desktopがまたランダムに膨大なメモリを食い始めたあとPodmanに切り替えたが、本当にインストールしてdocker-compose.ymlを指すだけというくらい簡単だった
    変更はまったく不要で、今ではデーモンを常に起動しておく必要もない。素晴らしいソフトウェアだ

    • Docker Desktopよりcolimaのほうがよく、colimaよりOrbstackのほうがさらによかった。その後、https://smolmachines.com's のsmolvmマイクロVMを見つけた
    • DockerのAI絡みの迷走のせいでついに一線を越え、Podmanへの移行を試みたが、いくつか互換性の問題に遭遇した。数か月前なので詳細は覚えていない
      それでRancher Desktopを試したところ、名前をしょっちゅう忘れること以外は普通にうまく動いた。必要な人にはもうひとつのシンプルな選択肢だ

  • Quadletが本当に気に入っている。数年にわたりHetzner、Ansible、SystemD、RockyLinuxでルートレスコンテナを問題なくホスティングしてきて、その構成をテンプレートリポジトリとして切り出した
    [1] https://github.com/Mati365/hetzner-podman-bunjs-deploy

    • ホームサーバーをk3sからquadletに替えたら、**消費電力が8%**減った

  • DockerからPodmanへ移行してみた経験が気になる
    ホームラボ／自動化構成にcomposeファイルが多いので、それが一番心配

    • 約15か月前にDockerからPodmanへ移行し、もう戻るつもりはない。個人的にはquadlet、つまりsystemd統合が本当に良く、通常のsystemdサービスであれコンテナであれ、実行中のサービス群をずっと簡単に監視できるようにしてくれる
      ルートレス実行も非常に直感的で、Podmanはとても高速。個人的にdocker composeが大きく恋しいわけではないが、docker composeがないことが他の人には致命的になり得るのは理解できる。Podmanのcomposeプラグインは使ったことがない
    • ホームラボで巨大なdocker composeファイルをpodman quadletに置き換えた。記憶では、最初のいくつかのサービスを移すときは、composeファイルに比べてquadletのドキュメントや例が多くなく少し時間がかかったが、その後はとても簡単だった。強くおすすめする
      唯一の問題は検証。quadletファイルを検証する便利な組み込みコマンドがなく、systemdも生成失敗を警告してくれない。先に--dry-runするか、コマンド全体を適当なエイリアスにするか、あるいはジャーナルでエラーを確認する必要がある
    • 数年前、5.0以前に移行し、それ以来振り返っていない。composeファイルはquadletの利用を検討する価値がある
      素早い変換にはpodman-composeを直接使うか、Podmanソケットを指すようにdocker composeを設定できる[0]
      composeファイルをネイティブなquadletに変換してくれるpodlet[1]もある。単純、または中程度の複雑さのcomposeファイルはたいてい自動でうまく処理し、そのまま動作する。これをライブラリ形式にして、他のツールがcomposeファイルをquadletへ透過的に変換できるようにしようという話もあり、今後似たツールがさらに出てくることを期待している
      systemdユニットファイルに少しでも慣れているなら、自分でQuadletファイルを書くのも難しくない。ほとんどのdocker runまたはpodman runの引数はquadletにそのまま対応するので、YAMLの代わりにINI形式に慣れれば、composeファイルを見て同等のquadletを作るのは簡単 [0] https://www.redhat.com/en/blog/podman-docker-compose
      [1] https://github.com/containers/podlet
    • 1〜2年前に全部ルートレスPodmanへ移行した。一部のコンテナは古いデータを読むときに権限問題が起きたが、別のUIDで実行されていたのが原因だった
      実際に遭遇した問題はこれがすべてで、root権限のDockerからルートレスDockerへ移行しても同じ問題はあったはず。まったく後悔していないし、絶対に戻るつもりはない
    • Podmanにはgitと同じくらい感謝している
      Podmanは成熟していて合理的だった。誰かのコンテナがsu権限に依存しているなら、Podmanではなくその誰かを責める

  • Podmanで嫌な点は、Docker互換のふりをしているが、後で噛みついてくる小さな違いがあること。DockerベースのプロジェクトのユーザーがPodmanで実行しようとして、結局プロジェクト側に来て不満を言うことになる

    • ほとんどの違いはソケットAPIや論理的な動作、コマンドラインの差から来たものではなかった。Dockerがroot権限で実行されると仮定している一方で、Podmanはデフォルトではそうではない、という点から主に生じる
      そのためPodman/Dockerの非互換を直す作業は、たいていその仮定に対処することになる。Podmanコマンドにいくつかフラグを追加して、コンテナとホスト間のユーザー名前空間マッピング方法を変える、といった形
    • MacとLinuxでPodmanを3年使ってきたが、残念ながらこの問題は常に事実だった。根気強く根本原因を探してバグを上げる気はあるが、多くの人には単に壊れているように見えるはず
      直近では、Netavarkが公開ポートでブロードキャストトラフィックを受け取る挙動がDockerと一致していなかった
    • その通り。このせいで数年間Podmanを避けることになった。今では賢いアイデアだと思うし、RHELを使っているなら当然の選択だが、慣れが必要だという点をもっと率直に伝えるべき
      特にroot権限のDockerからルートレスPodmanへ移行する場合はなおさら

  • 最近のPodmanはどうなのか気になる。macOSではOrbStackを使っていて、ずっと速いように思う。macOS 27がWSLに似た、マイクロVMベースのよりネイティブで性能の良いLinuxコンテナを追加したら、勢力図がどうなるか分からない

    • macOSはよく分からないが、Linuxでは自分の用途に滑らかに合っている。注意点が1つあって、Podman Composeはデフォルトのプロバイダーとしてdocker-composeを使うこと
      podman-composeプロバイダーは使ったことがなく、名前がPodman Composeと紛らわしいくらい少し違う。Podman Composeはdocker-composeやpodman-composeの上位抽象化。必要ならPodmanでもDockerエンジン経由でコンテナを実行できる
    • 同じ質問で、同じ状況。MacOSで試したが、最初に遭遇した問題を理解するためにRedhatフォーラムの奥深くまで潜る必要があった。OrbStackに切り替えるのは当然の選択だったが、機能面での明確なトレードオフはある

  • Quadletとルートレスコンテナは、DockerからPodmanへ移行したい大きな理由の2つ

    • ルートレスが数年前にPodmanへ移行した理由だった。本当にスムーズで、もう曖昧な権限問題やサービスエラーを心配しなくてよくなった

  • Podmanは良いが、あのグレーの文字色はなぜなのか分からない。見栄えが悪く、コントラスト比4.96:1で読みにくく、WCAG AAAレベルにも届いていない

  • ホームサーバーを約2年間podman + quadletsで動かしているが、リリースノートでいくつか押さえておくべきものを見つけた
    podman quadlet listはv5.6.0で追加され、quadletとそのコンテナを一覧表示する
    podman system migrate --migrate-dbはv5.8.0で追加されたフラグ。以前bolt DBのサポート終了警告を見たが、sqliteへ移行するツールがなかった。今は用意されている。あるいはpodman 6.0.0へ上げれば自動で処理される

  • Docker ではない CRI ランタイム向けのイメージビルドに Podman を使った経験があるか知りたい
    Podman でイメージをビルドすると、cri-o、Docker、そのほか複数のランタイムで実行できるのだろうか？
    docker build には sudo が必要で、エージェントベースのワークフローでは面倒になるため、ルートレス Podman でイメージをビルドするか検討中