Dockerコンテナー内のセキュリティ更新を処理する方法？
アプリケーションをサーバーにデプロイする場合、通常、アプリケーションがそれ自体にバンドルするものと、プラットフォーム（オペレーティングシステムおよびインストールされたパッケージ）が提供することを期待するものとの間に分離があります。この点の1つは、アプリケーションとは無関係にプラットフォームを更新できることです。これは、アプリケーション全体を再構築せずに、セキュリティ更新をプラットフォームによって提供されるパッケージに緊急に適用する必要がある場合などに役立ちます。
従来、セキュリティ更新プログラムは、パッケージマネージャーコマンドを実行してオペレーティングシステムにパッケージの更新バージョンをインストールするだけで適用されていました（たとえば、RHELの "yum update"）。しかし、Dockerなどのコンテナーテクノロジーの登場により、コンテナーイメージは本質的にアプリケーションの両方をバンドルするandプラットフォームであり、コンテナーを備えたシステムを最新の状態に保つための標準的な方法は何ですか？ホストとコンテナーの両方に、更新が必要な独自の独立したパッケージのセットがあり、ホストでの更新はコンテナー内のパッケージを更新しません。 Dockerコンテナーが特に注目されているRHEL 7のリリースにより、コンテナーのセキュリティ更新を処理するためにRedhatが推奨する方法が何か興味深いと思います。
オプションのいくつかについての考え：
- ホスト上のパッケージマネージャーでパッケージを更新しても、コンテナー内のパッケージは更新されません。
- 更新を適用するためにすべてのコンテナーイメージを再生成する必要があると、アプリケーションとプラットフォームの分離が損なわれるようです（プラットフォームを更新するには、Dockerイメージを生成するアプリケーションビルドプロセスにアクセスする必要があります）。
- 実行中の各コンテナ内で手動コマンドを実行するのは面倒であり、次にコンテナがアプリケーションリリースアーティファクトから更新されるときに変更が上書きされるリスクがあります。
したがって、これらのアプローチはどれも満足できるものではないようです。
Dockerイメージには、アプリケーションと「プラットフォーム」がバンドルされています。ただし、通常、イメージはベースイメージと実際のアプリケーションで構成されます。
したがって、セキュリティ更新を処理する正規の方法は、ベースイメージを更新してから、アプリケーションイメージを再構築することです。
コンテナは軽量で交換可能であると想定されています。コンテナーにセキュリティの問題がある場合は、パッチが適用されたバージョンのコンテナーを再構築し、新しいコンテナーをデプロイします。 （多くのコンテナーは、apt-getなどの標準パッケージ管理ツールを使用して依存関係をインストールする標準ベースイメージを使用します。再構築すると、リポジトリから更新がプルされます）
コンテナー内にパッチを適用することはできますが、これでは十分にスケーリングできません。
まず、これまでに実行してきた更新の多くは、単にコンテナー自体の内部にはありません。コンテナーは、これまで見慣れていた完全なファイルシステムのかなり軽量で小さなサブセットである必要があります。更新する必要があるパッケージはDockerFileの一部であるパッケージであり、DockerFileがあるため、更新が必要なパッケージとコンテナIDを追跡できるはずです。間もなくリリースされるCloudsteinのUIは、これらのDockerFileの構成要素を追跡するため、コンテナに最適な更新スキームを構築できます。お役に立てれば
一般に、指定した3つの選択肢よりもさらに悪いものです。ほとんどのDockerイメージはパッケージマネージャーを使用して構築されていないため、DockerイメージにShellして更新を発行することはできません。 Dockerイメージを再構築または再取得する必要があります。
ほとんどの場合、セキュリティパッチを再構築するために再構築する必要がある、または他の人に見直されているという事実は不合理に思われます。
私はソッカーとレーダーをDockerコンテナーにデプロイすることを検討していましたが、それらが私のコンテナーが取得する定期的なセキュリティ更新を取得しないことを知っていることは取引ブレーカーです。コンテナーのセキュリティ更新プログラムを管理することは、セキュリティ更新プログラムを各Dockerイメージに個別に手動で適用する必要がないので、十分に面倒です。