セキュリティが強化されたDocker代替、`Podman` を探る

Podman と Docker の比較

• Podman と Docker はどちらも、効率的かつスケーラブルな方法でコンテナを実行、管理、デプロイできる。
• Podman はデーモンレスアーキテクチャを採用しており、ユーザーがコンテナを直接管理する。
• Podman は Systemd と統合されており、コンテナのライフサイクルを管理する。
• Docker Compose に似た機能を提供する Podman Compose を使って、複数のコンテナをオーケストレーションできる。
• セキュリティ面では、Podman は Docker より強化されたデフォルト設定を提供する。

Podman をインストールする

• Podman は macOS、Windows、および主要な Linux ディストリビューションで実行できる。
• Linux ではネイティブに、Windows と macOS では仮想マシン経由で動作する。
• インストールは sudo apt update と sudo apt install podman コマンドで行う。

最初のコンテナを実行する

• "Hello World!" イメージを使って、Podman のインストールが正常に動作しているか確認する。
• Podman は OCI(Open Container Initiative) 標準に従っているため、Docker イメージと互換性がある。

短いイメージ名を使う

• Podman はイメージを参照する際、完全修飾名を使うことを推奨している。
• 短い名前を使う場合、Podman は設定ファイルを参照して正規化されたイメージ名を確認する。

プライベートイメージレジストリを使う

• Podman は Docker と同様に、プライベートレジストリと一緒に利用できる。
• Docker Hub アカウントを使って、プライベートレジストリ設定の例に従うことができる。

複数コンテナをオーケストレーションする

• Podman Compose を使って複数のコンテナをオーケストレーションできる。
• Podman Compose は Docker Compose に似た機能を提供し、既存の docker-compose.yml ファイルと互換性がある。

GN⁺の意見:

• Podman は Docker と比べてより高速で、セキュリティ面で強化されたデフォルト設定を提供するコンテナエンジンである。これは開発者やシステム管理者にとって魅力的な代替になりうる。
• Podman のデーモンレスアーキテクチャはセキュリティ監査証跡を容易にし、セキュリティインシデント発生時にユーザーを特定できるようにする。
• Podman と Docker の互換性により、既存の Docker ユーザーは Podman へ移行しやすくなる。これは既存のインフラやワークフローを維持しながら、セキュリティとパフォーマンスを改善したい組織にとって有用である。

[GN⁺]

Hacker News のコメント

• Podman と systemd

  • Podman は systemd ユニットファイルをサポートしていたときは良かった。コンテナとポッドを自動起動・更新できた。
  • しかし Quadlet を優先するようになってこの機能は削除された。今では単一コンテナはユニットファイルで扱えるが、ポッドには Kubernetes クラスタ定義が必要になる。
  • Docker と違って、Podman のコンテナは SELinux の定義に従って動作するため、マウントしたディレクトリにアクセスできない問題が繰り返し起きる。
  • Podman を使うべきなのか、Kubernetes を使うべきなのか、論理的な配置ではなく専用ディレクトリを作るべきなのかという混乱がある。

• Podman のネットワーク互換性

  • Podman の大きな利点の一つは、Docker と違ってネットワーク設定を壊さないこと。
  • Docker を使って KVM 仮想マシンと一緒にブリッジを運用するのは悪夢だったが、Podman はデフォルトでうまく動く。
  • Docker によって VPN が壊れたり切断されたりする問題もあったが、Podman のネットワーク方式は今のところ他の作業の妨げになっていない。

• 高まり続ける Podman の人気

  • 多くのツールは sudo docker グループの追加を前提に作られているが、セキュリティを意識した Docker 設定では問題になる。
  • Podman は root 権限なしでも使えるため、セキュリティ面では好ましい。

• RHEL エンジニアの Podman 利用経験

  • 認定 RHEL エンジニアとして、個人的なコンテナ利用では Podman を好んで使っている。
  • ただし開発者向けには依然として Docker を使っており、Docker Compose の手軽さを置き換えられるものはまだ提供できていない。
  • CI パイプラインでは Buildah を使っているが、開発者ユーザー向けでは Docker Compose が依然として優勢だ。

• Docker と UFW のセキュリティ欠陥

  • Docker と UFW のセキュリティ欠陥で、危うく被害を受けるところだった。

• ルートレスコンテナと独立した名前空間の重要性

  • ルートレスコンテナと独立した名前空間は重要なセキュリティ機能だ。
  • Docker でもルートレスは利用でき、設定もそれほど複雑ではない。
  • Docker を使い続ける利点は、よりアクセスしやすいことにある。コミュニティが大きく、ブログも多く、Docker Compose の設定例も広く利用でき、使い方を知っている同僚もいる。
  • 結局のところ Podman も Docker も、ホストから独立した名前空間でプロセスを実行する。

• Red Hat の Docker 代替、Podman

  • Red Hat が Docker の代替を作る理由ははっきりしないが、Podman は気に入っている。
  • Podman は Docker ができることのほとんどをこなせるうえ、さらに多くの機能を備えていたり（例: ポッド）、Podman のやり方のほうが優れていたりする（例: デーモンレスなコンテナ作成プロセス）。
  • 開発者にとっての主な問題は Docker Compose かもしれないが、シンプルな Compose ファイルを使うなら、Docker Compose 仕様との互換性を目指す podman-compose スクリプトがある。
  • Podman を Docker Compose のバックエンドとして使うことも可能だ。2024年時点では、少なくとも Linux マシン上では Docker を使う理由はなさそうに見える。Podman が macOS や Windows でどう動くかは分からない。

• Podman のセキュリティ重視のアプローチ

  • Podman のセキュリティ重視のアプローチと、いくつかの判断は気に入っている。デフォルトで安全な設定を提供し、Docker Compose とも互換性がある。
  • Podman が十分な人気を得れば、コマンドや yml について独自の方向に進むかもしれない。現状では Docker と Docker Compose のファイル形式に「依存している」ツールのように見える。
  • Podman には、k8s なしでオーケストレーション不足を補える swarm の代替が必要だ。優れたセキュリティ観点で、小規模なコンテナを運用するためのシンプルで妥当な方法を提示できるはずだ。

• Podman 利用時に経験した問題

  • Podman は素晴らしいが、Docker の代替として使い始めたとき、UID と GID のマッピング、SELinux ポリシー、欠けている DNS 設定などで苦労した。
  • 問題を解決するためにシステム migration を実行して設定を壊してしまったことが何度もある。セキュリティ ACL、ID マッピング、ラベルに関する複雑な問題がある。
  • 結果には満足しているが、Docker のように「ただ動く」ソリューションではなかった。使い始めてから改善されている可能性はある。

• Podman と Apple シリコン

  • Podman には、Docker と違って Apple シリコン上で x86 イメージを Rosetta 経由で実行できる機能がない。
  • QEMU は実用には遅すぎる。