効率的なコンテナーイメージ

Spring Boot uber jar を Docker イメージとしてパッケージ化することは簡単です。ただし、uber jar をそのまま Docker イメージにコピーして実行することにはさまざまな欠点があります。uber jar を解凍せずに実行すると常にある程度のオーバーヘッドが発生し、コンテナー化された環境ではこれが顕著になる可能性があります。もう 1 つの課題は、アプリケーションのコードとそのすべての依存関係を Docker イメージの 1 つのレイヤーに配置することは最適ではないことです。使用する Spring Boot のバージョンをアップグレードするよりも頻繁にコードを再コンパイルする可能性が高いため、多くの場合、もう少し分離する方がよいでしょう。jar ファイルをアプリケーションクラスの前のレイヤーに配置すると、Docker は多くの場合、最下層を変更するだけで済み、他のファイルをキャッシュから取得できます。

Docker イメージのレイヤー化

最適化された Docker イメージの作成を容易にするために、Spring Boot はレイヤーインデックスファイルを jar に追加することをサポートしています。レイヤーのリストと、レイヤー内に含める必要のある jar のパーツを提供します。インデックス内のレイヤーのリストは、レイヤーを Docker/OCI イメージに追加する順序に基づいて並べられています。すぐに使用できる、次のレイヤーがサポートされています。

  • dependencies (定期的にリリースされる依存関係の場合)

  • spring-boot-loader (org/springframework/boot/loader のすべての)

  • snapshot-dependencies (スナップショットの依存関係)

  • application (アプリケーションのクラスとリソース)

layers.idx ファイルの例を次に示します。

- "dependencies":
  - BOOT-INF/lib/library1.jar
  - BOOT-INF/lib/library2.jar
- "spring-boot-loader":
  - org/springframework/boot/loader/launch/JarLauncher.class
  - ... <other classes>
- "snapshot-dependencies":
  - BOOT-INF/lib/library3-SNAPSHOT.jar
- "application":
  - META-INF/MANIFEST.MF
  - BOOT-INF/classes/a/b/C.class

この階層化は、アプリケーションのビルド間で変更される可能性に基づいてコードを分離するように設計されています。ライブラリコードはビルド間で変更される可能性が低いため、ツールがキャッシュからレイヤーを再利用できるように独自のレイヤーに配置されます。アプリケーションコードはビルド間で変更される可能性が高いため、別のレイヤーに分離されます。

Spring Boot は、layers.idx を使用して war ファイルのレイヤー化もサポートします。

Maven の場合、アーカイブへのレイヤーインデックスの追加の詳細については、「階層化された jar または war のパッケージ化」セクションを参照してください。Gradle については、Gradle プラグインのドキュメントの階層化された jar または war のセクションを参照してください。