Spring Boot 階層化パッケージング Docker イメージの実践と分析 (推奨)

1. Spring Bootプロジェクトを準備する

シンプル、スキップ
Spring Bootバージョン2.3.x以上では、単にhello worldを書くだけでよい。

2. 関連する設定を実行する

インターネット上の多くのブログでは、階層化パッケージ化を有効にするには pom.xml を手動で構成する必要があることを強調しています。

<ビルド>
    <プラグイン>
        <プラグイン>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <構成>
                <!--階層型コンパイルのサポートを有効にする-->
                <レイヤー>
                    <enabled>有効</enabled>
                </レイヤー>
            </構成>
        </プラグイン>
    </プラグイン>
</ビルド>

バージョン 2.3.x では、これは新しい機能であり、手動で構成して有効にする必要があります。ただし、現在の Spring Boot バージョン (バージョン 2.6.1 を使用) では、手動での構成は必要なく、デフォルトでこの機能がサポートされています。 (いくつかのブログによると、バージョン 2.4.x 以降ではデフォルトで有効になっているようです)

現在の公式ドキュメント (バージョン 2.6.0) にも、デフォルトでサポートされていると記載されていますが、この機能が必要ない場合にのみ手動で構成する必要があります。

再パッケージ化されたアーカイブには、デフォルトでlayers.idxファイルが含まれています。この機能を無効にするには、次の方法を実行します。

<プロジェクト>
   <ビルド>
       <プラグイン>
           <プラグイン>
               <groupId>org.springframework.boot</groupId>
               <artifactId>spring-boot-maven-plugin</artifactId>
               <構成>
                   <レイヤー>
                       <enabled>偽</enabled>
                   </レイヤー>
               </構成>
           </プラグイン>
       </プラグイン>
   </ビルド>
</プロジェクト>

3. パッケージ

mvn package実行してパッケージ化し、jar パッケージファイルを取得します。

実際、本質は、spring-boot-mavenプラグインの再パッケージを使用して、依存関係を含む完全なjarパッケージと元のjarパッケージを取得することです（サフィックス.originalは自動的に追加されます）
jar パッケージを開くと、BOOT-INF フォルダーにclasspath.idxおよびlayers.idxファイルがあります。これらを開いて確認してみましょう。

クラスパス.idx

- 「BOOT-INF/lib/logback-classic-1.2.7.jar」
- 「BOOT-INF/lib/logback-core-1.2.7.jar」
- 「BOOT-INF/lib/log4j-to-slf4j-2.14.1.jar」
- 「BOOT-INF/lib/log4j-api-2.14.1.jar」
- 「BOOT-INF/lib/jul-to-slf4j-1.7.32.jar」
- 「BOOT-INF/lib/jakarta.annotation-api-1.3.5.jar」
- 「BOOT-INF/lib/snakeyaml-1.29.jar」
- 「BOOT-INF/lib/jackson-databind-2.13.0.jar」
- 「BOOT-INF/lib/jackson-annotations-2.13.0.jar」
- 「BOOT-INF/lib/jackson-core-2.13.0.jar」
- 「BOOT-INF/lib/jackson-datatype-jdk8-2.13.0.jar」
- 「BOOT-INF/lib/jackson-datatype-jsr310-2.13.0.jar」
- 「BOOT-INF/lib/jackson-module-parameter-names-2.13.0.jar」
- 「BOOT-INF/lib/tomcat-embed-core-9.0.55.jar」
- 「BOOT-INF/lib/tomcat-embed-el-9.0.55.jar」
- 「BOOT-INF/lib/tomcat-embed-websocket-9.0.55.jar」
- 「BOOT-INF/lib/spring-web-5.3.13.jar」
- 「BOOT-INF/lib/spring-beans-5.3.13.jar」
- 「BOOT-INF/lib/spring-webmvc-5.3.13.jar」
- 「BOOT-INF/lib/spring-aop-5.3.13.jar」
- 「BOOT-INF/lib/spring-context-5.3.13.jar」
- 「BOOT-INF/lib/spring-expression-5.3.13.jar」
- 「BOOT-INF/lib/spring-boot-2.6.1.jar」
- 「BOOT-INF/lib/spring-boot-autoconfigure-2.6.1.jar」
- 「BOOT-INF/lib/slf4j-api-1.7.32.jar」
- 「BOOT-INF/lib/spring-core-5.3.13.jar」
- 「BOOT-INF/lib/spring-jcl-5.3.13.jar」
- 「BOOT-INF/lib/spring-boot-jarmode-layertools-2.6.1.jar」

レイヤー.idx

- 「依存関係」:
- 「BOOT-INF/lib/」
- 「スプリングブートローダー」:
- 「org/」
- 「スナップショットの依存関係」:
- "応用"：
- 「BOOT-INF/classes/」
- 「BOOT-INF/classpath.idx」
- 「BOOT-INF/layers.idx」
- 「META-INF/」

再度確認:

階層化された情報OK

4. Dockerファイル

Dockerfile ファイルも比較的従来型です。イメージをパッケージ化する前に、jarmode コマンドを使用して jar パッケージを解凍するだけです。次に、パッケージ化プロセス中に、さまざまなレイヤーが順番にコピーされ、変更される可能性が最も高いアプリケーションレイヤーが最後に配置されます。このようにして、変更のない前のレイヤーは Docker のキャッシュを直接使用して、パッケージ化の効率を向上させることができます。

eclipse-temurin:8-jre-focal からビルダーとして
WORKDIR アプリケーション
ARG JAR_FILE=ターゲット/*.jar
${JAR_FILE} application.jar をコピーします
実行 java -Djarmode=layertools -jar application.jar extract
eclipse-temurin:8-jre-focalより
WORKDIR アプリケーション
コピー --from=builder application/dependencies/ ./
コピー --from=builder application/spring-boot-loader/ ./
コピー --from=builder application/snapshot-dependencies/ ./
コピー --from=builder application/application/ ./
ENV TZ="アジア/上海"
実行 ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
環境変数 JVM_OPTS=""
環境変数JAVA_OPTS=""
ENTRYPOINT ["sh","-c","java $JVM_OPTS $JAVA_OPTS org.springframework.boot.loader.JarLauncher"]

5. アプリケーションの変更とダイブ分析

実際、画像を一度だけパッケージ化すると、レイヤー化の利点が反映されないため、一部のコンテンツを変更してから再度パッケージ化する必要があります（複数回でも、本質は同じなので、ここでは一度だけ変更します）。
いくつかのアプリケーションコードを変更します。

jar パッケージを再パックしてイメージを再作成し、2 つのイメージを取得します。

dive を使用して 2 つの画像を分析します。

アプリケーション層 (application/application/) が変更されるまで、両側の層の Id と Digest はまったく同じであるため、これらの層を再利用できることがわかります。また、同じ層は docker ディレクトリに個別に保存されるだけなので、コンテナのコンパイルとプッシュにかかる時間を大幅に短縮できます。
(Docker イメージの具体的な階層化についての理解はまだ限られているので、後で詳しく学習します)

Spring Boot 階層化パッケージング Docker イメージの実践と分析に関するこの記事はこれで終わりです。より関連性の高い Spring Boot 階層化パッケージング Docker イメージのコンテンツについては、123WORDPRESS.COM の過去の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません: