翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

その他の考慮事項

このセクションでは、Java EE アプリケーション固有ではない Java コンテナ化に関する一般的な考慮事項について説明します。

小さなベースイメージを使用する

小さいサイズで (500 MB 未満)、よく管理されたベースイメージを作成することをお勧めします。ベースイメージのサイズを小さくすると、ネットワークコストや運用コストを削減できます。また、ベースイメージを小さくするほど、悪用される可能性のあるコンポーネントの数が減り、セキュリティも向上します。Debian ベースの distroless イメージから 1 つ使用することができます。イメージには最小限のツールがインストールされており、パッケージマネージャーやシェルは含まれていません。これら distroless イメージは、攻撃の対象範囲も全体的に縮小させることができます。distroless イメージは 150 MB 未満のサイズになります。詳細については、GitHub リポジトリの「"Distroless" Container Images」を参照してください。

ベストプラクティスは、廃棄容易性の原則に従い、コンテナイメージの起動時間を短縮することです。ahead-of-time-compilation (OpenJDK のドキュメント) または application class data sharing (OpenJDK のドキュメント) のようなテクニックを使って、仮想マシンを起動する前に Java クラスをネイティブコードにコンパイルし、クラスのセットを共有アーカイブファイルに事前処理することで、全体的な起動時間を短縮させることができます。また、GraalVM を使用して Java アプリケーション用に最小限の Docker イメージを構築することもできます。詳細については、GraalVM を使用して Java アプリケーション用の最小限の Docker イメージを構築する AWS ブログ記事を参照してください。

コンテナ対応の JDK バージョンにアップグレードする

JDK 8u131 以前のバージョンでは、JVM は Docker エンジンがフラグを使用して設定したメモリ、または CPU の制限を認識していませんでした。つまり、アプリケーションをコンテナ内で実行するたびに、JVM はシステム、または仮想マシンの場合は仮想システム上で、使用可能なプロセッサの総数を「認識」することになります。デフォルトのメモリ制限についても同じことが言えます。JVM はホストのメモリ全体を見て、そのメモリを使ってデフォルトを設定します。そのため、JVM はコンテナプラットフォームで許可されているよりも多くのメモリを要求する可能性があり、その結果、コンテナプラットフォーム (Docker) によって Java プロセスが終了することになります。この問題の 1 つの解決策としては、コンテナ化する前に Java アプリケーションを Java 9 もしくは Java 8u131 以上のバージョンに移行することです。Java 10 以降のバージョンでは、コンテナを完全に認識してサポートしています。