Podman コンテナーの自動更新を有効にする方法
Podman は、Docker の代わりによく使用される OCI 準拠のコンテナー化プラットフォームです。デーモンを使用しないモデルと豊富な機能セットにより、開発と運用の両方で使用するのに適しています。
この記事では、Podman の自動更新システムを使用して、新しいイメージがリリースされたときにコンテナーを再起動する方法を紹介します。Podman は、更新を定期的に確認し、最新のイメージをプルし、現在の設定を使用して影響を受けるコンテナーを再生成するように構成できます。
コンテナーを自動的に更新する理由
多くの場合、コンテナーは短命ですが、それでも定期的なメンテナンスが必要です。イメージ内の重大な脆弱性により、攻撃者がアプリケーションにアクセスできる可能性があり、発見されてから数時間以内に悪用される可能性があります。
一般的なコンテナー テクノロジのほとんどでは、コンテナーを手動で更新する必要があります。これにより、運用チームは、リリースのアナウンスにサインアップし、新しい変更を実装するツールを構築する責任を負っています。
Podman の組み込みコンテナー更新システムは、この問題を解決し、ワークロードを最新の状態に保ちます。新しいイメージ バージョンがプッシュされた後、コンテナーをすばやく更新できるため、デプロイが最新のパッチとバグ修正で最新の状態に保たれます。
自動更新を有効にする
io.containers.autoupdateコンテナーの作成時にラベルを設定すると、コンテナーの自動更新が有効になります。
$ podman run -d -p 8080:80 \
–name nginx-container\
–label io.containers.autoupdate=registry \
docker.io/library/nginx:latest
ラベルには、次の 2 つの値を指定できます。
registry– 更新をチェックしている間、Podman はイメージ レジストリをチェックして、コンテナーで使用されているタグの新しいバージョンが利用可能かどうかを確認します。この場合、イメージが抽出され、コンテナーが再起動します。レジストリの更新は、レジストリのフル パスを使用する場合にのみ機能します。docker.io/library/nginx:latest上記のリンクは、nginx:latestあいまいすぎるため、意図的なものです。local– この更新方法では、Podman がホストのファイル システムに既に存在するコンテナー イメージを表示できなくなります。イメージ タグのローカル バージョンが、コンテナーが実行されているバージョンと異なる場合、コンテナーは再起動されます。これは、開発中にイメージを再構築するときに役立ちます。
ラベルの存在により、このサンプル NGINX コンテナーは自動更新の対象になります。ただし、更新を実際に適用するには、さらに多くの作業が必要です。
Systemd サービスの作成
Podman の更新メカニズムでは、コンテナーをsystemd サービス内で実行する必要があります。Podman はデーモンレスであるため、コンテナーを開始および停止できる中央コントローラーがありません。それらを systemd サービスにラップすると、ライフサイクル管理機能と、特定のイベントに応答して再起動する機能が提供されます。
Podman CLI には、コンテナーから systemd モジュール定義を作成するコマンドが含まれています。
$ podman generate systemd --name nginx-container > /etc/systemd/system/nginx-container.service
上記のコマンドは、正しい場所に systemd サービスを含む新しい NGINX コンテナーを作成します。
次に、systemd をリロードしてサービス定義を登録し、サービスを有効にして開始します。
$ systemctl daemon-reload
$ systemctl enable nginx-container.service
$ systemctl start nginx-container.service
NGINX コンテナーは、ホストの起動時に自動的に開始される systemd サービスになりました。systemctlPodman CLI の代わりに、コマンドを使用してコンテナーを開始および停止できます。
$ systemctl start nginx-container.service
$ systemctl stop nginx-container.service
今後コンテナーを削除するには、サービス モジュール ファイルを停止、無効化、および削除する必要があります。その後、systemd を再起動して変更を完全に適用します。
$ systemctl stop nginx-container.service
$ systemctl disable nginx-container.service
$ rm /etc/systemd/system/nginx-container.service
$ systemctl daemon-reload
更新の実行
これで、NGINX コンテナーの自動更新を成功させるためのすべての設定が完了しました。Podman コマンドを使用して、オンデマンドの更新チェックを実行できますauto-update。
$ podman auto-update
docker.io/library/nginx:latest をプルしようとしています…
画像ソースの署名を取得する
…
ユニットコンテナの画像ポリシーが更新されました
nginx-container.service 2de4ba96b09 docker.io/library/nginx:latest registry true
これにより、コマンドを実行しているユーザーが利用できる systemd サービスのコンテナーが更新されます。sudo上記の例に従うには、を使用する必要がある場合があります。auto-updateその場合は、root としてもコマンドを実行します。
$ sudo podman auto-update
このregistry例では、更新戦略が使用されたため、Podman はイメージ レジストリに接続し、変更を確認してから、該当する場合は新しいイメージをプルします。コマンド出力には、各サービス コンテナーがアップグレードされているかどうかが示されます。
コンテナーは systemd によって管理されるため、Podman は新しいコンテナーが正常に開始されたかどうかを判断できます。アップグレードの失敗が検出された場合、Podman はイメージの以前のバージョンに自動的にロールバックします。これが確実に機能するためには、コンテナー内のアプリケーションがsystemdに正常に起動したことを通知する必要があります。これは、実行することで実行できますsystemd-notify --ready。
アップデートの確認
更新をすぐに適用せずに、コンテナー フリートで利用できる更新があるかどうかを確認したい場合があります。flag コマンドを使用auto-updateして--dry-run、更新されたイメージが公開されているサービスのリストを取得します。
$ podman auto-update --dry-run
…
ユニットコンテナの画像ポリシーが更新されました
nginx-container.service 2de4ba96b09 docker.io/library/nginx:latest registry pending
表示されているサービスpendingには、利用可能な更新があります。
スケジュールに従ってアップデートを適用する
これで、オンデマンドのコンテナー更新が正常に構成されました。新しいイメージを手動でプルしたり、コンテナーを再起動したりする必要はありません。auto-update最後のステップは、コマンドを実行せずに Podman が定期的に更新を適用するようにスケジュールを設定することです。
ほとんどの Podman ディストリビューションには、この目的のためにシステム タイマーが含まれています。次を使用してタイマーを有効にできますsystemctl。
$ systemctl enable podman-auto-update.timer
タイマーは、毎日更新をチェックするように設定されています。フィールドsystemctl edit値を使用して変更し、タイマー ファイルを開くことで、スケジュールをカスタマイズできます。OnCalendar
$ systemctl edit podman-auto-update.timer
[タイマー]
OnCalendar=Fri *-*-* 18:00
上記の時間式は、毎週金曜日の 18:00 に更新チェックを実行します。構文は systemd のマニュアルに記載されています。
タイマーが有効になったので、io.containers.autoupdateラベル付きコンテナーのデプロイを開始できます。それらは定期的に更新されて再起動され、メンテナンス手順が自動化されます。
Podman のシステム タイマーを使用して更新をスケジュールする必要はありません。podman auto-update既存のツールキットまたは などの別のタスク スケジューラ内で実行できますcron。
概要
Podman の自動更新により、コンテナーを手動で再起動したり、外部ツールを使用したりせずに、コンテナーを新しいイメージ バージョンに移動できます。これは、イメージがバグ修正とセキュリティ修正をリリースするため、コンテナー フリートを維持するのに役立ちます。
自動更新は便利なツールですが、十分な注意を払わずに使用しないでください。自動更新を許可すると、破損したイメージが誤ってリリースされた場合に、それ自体が問題を引き起こす可能性があります。独自に再起動するコンテナーも、ダウンタイムを引き起こしたり、依存するサービスを中断したりする可能性があります。
したがって、このソリューションを実装する前に、独自のアプリケーションの適合性を評価する必要があります。中間的なアプローチの 1 つは、auto-update --dry-run定期的に実行して結果を監視サービスに送信することです。これにより、承認なしに適用されるリスクを冒すことなく、利用可能な更新が通知されます。
コメントを残す