サーバーにアプリケーションを展開する場合、通常、アプリケーションがそれ自体にバンドルするものと、提供するプラットフォーム(オペレーティングシステムおよびインストール済みパッケージ)に期待するものとが分離されます。これの1つのポイントは、プラットフォームをアプリケーションとは無関係に更新できることです。これは、たとえば、アプリケーション全体を再構築せずにプラットフォームが提供するパッケージにセキュリティ更新プログラムを緊急に適用する必要がある場合に役立ちます。
従来、セキュリティアップデートは、パッケージマネージャコマンドを実行して、オペレーティングシステムにパッケージの更新バージョンをインストールするだけで適用されてきました(たとえば、RHELの「yum update」)。しかし、コンテナイメージがアプリケーションとプラットフォームの両方を本質的にバンドルするDockerなどのコンテナテクノロジーの出現により、コンテナを備えたシステムを最新の状態に保つ標準的な方法は何ですか?ホストとコンテナの両方に独自の独立したパッケージのセットがあり、ホスト上で更新および更新が必要な場合、コンテナ内のパッケージは更新されません。Dockerコンテナが特に注目されているRHEL 7のリリースでは、コンテナのセキュリティ更新を処理するRedhatの推奨される方法を聞くのは興味深いでしょう。
いくつかのオプションについての考え:
- ホスト上のパッケージマネージャーにパッケージを更新させても、コンテナー内のパッケージは更新されません。
- 更新を適用するためにすべてのコンテナイメージを再生成する必要があると、アプリケーションとプラットフォームの分離が崩れるようです(プラットフォームを更新するには、Dockerイメージを生成するアプリケーションビルドプロセスにアクセスする必要があります)。
- 実行中の各コンテナ内で手動コマンドを実行するのは面倒で、アプリケーションリリースアーティファクトからコンテナが次に更新されるときに変更が上書きされる危険があります。
したがって、これらのアプローチはどれも満足のいくものではありません。
docker pull debian/jessie
、イメージを更新し、既存のイメージを再構築してから、コンテナを停止して再度実行することです(新しい画像で)。作成するイメージの名前は以前のものと同じであるため、開始はスクリプトを介して行われます。次に、「名前のない」画像を削除します。ワークフローを改善していただければ幸いです。