Spring Boot アプリケーション用に最適化された Docker イメージの作成

コンテナは、アプリケーションをすべてのソフトウェアおよびオペレーティング システムの依存関係とともにパッケージ化し、それらをさまざまな環境に配信するための推奨される手段となっています。

この記事では、Spring Boot アプリケーションをコンテナ化するさまざまな方法について説明します。

• Docker ファイルを使用して Docker イメージを作成する
• Cloud-Native Buildpack を使用してソースから OCI イメージを作成する
• 多層ツールを使用して JAR の一部を異なる層に分離することによる実行時イメージの最適化。

 コード例

この記事には実際に動作するコード例が含まれています GitHubで .

コンテナ用語

この記事で使用されているコンテナ用語から始めます。

• コンテナイメージ: 特定の形式のファイル。 ビルド ツールを実行して、アプリケーションをコンテナー イメージに変換します。
• コンテナ: コンテナ イメージの実行可能インスタンス。
• コンテナエンジン: コンテナの実行を担当するデーモン プロセス。
• コンテナホスト: コンテナー エンジンが実行されるホスト コンピューター。
• コンテナレジストリ: コンテナー イメージの公開および配布に使用される一般的な場所。
• OCI規格: Open Container Initiative（OCI） は、Linux Foundation 内に形成された軽量でオープンなガバナンス構造です。 OCI イメージ仕様は、すべてのコンテナ エンジンがあらゆるビルド ツールで作成されたコンテナ イメージを実行できるようにするために、コンテナ イメージとランタイム形式の業界標準を定義します。

アプリケーションをコンテナ化するには、アプリケーションをコンテナ イメージでラップし、そのイメージを共有レジストリに公開します。 コンテナー ランタイムは、このイメージをレジストリから取得して解凍し、その中でアプリケーションを実行します。

Spring Boot バージョン 2.3 は、OCI イメージを作成するためのプラグインを提供します。

デッカー は最も一般的に使用されるコンテナ実装であり、例では Docker を使用しているため、この記事の以降のコンテナ参照はすべて Docker を指します。

従来の方法でコンテナ イメージを構築する

Spring Boot アプリケーション用の Docker イメージの作成は、Docker ファイルにいくつかの命令を追加するだけで非常に簡単です。

まず実行可能 JAR ファイルを作成し、Docker ファイルの指示の一部として、必要な設定を適用した後、その実行可能 JAR ファイルをベース JRE イメージの上にコピーします。

Spring アプリケーションを作成しましょう 春のイニシャル 依存関係あり web, lombokи actuator。 API を提供するためのレスト コントローラーも追加しています。 GET方法。

Dockerfileの作成

次に、追加することでこのアプリケーションをコンテナ化します。 Dockerfile:

FROM adoptopenjdk:11-jre-hotspot
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} application.jar
EXPOSE 8080
ENTRYPOINT ["java","-jar","/application.jar"]

Docker ファイルには、次の基本イメージが含まれています。 adoptopenjdk、その上に JAR ファイルをコピーし、ポートを開きます。 8080リクエストをリッスンします。

アプリケーションの構築

まず、Maven または Gradle を使用してアプリケーションを作成する必要があります。 ここでは Maven を使用します。

mvn clean package

これにより、アプリケーションの実行可能 JAR ファイルが作成されます。 この実行可能 JAR を Docker エンジンで実行できるように Docker イメージに変換する必要があります。

コンテナイメージの作成

次に、次のコマンドを実行して、この実行可能 JAR ファイルを Docker イメージに配置します。 docker build前に作成した Dockerfile を含むプロジェクトのルート ディレクトリから:

docker build  -t usersignup:v1 .

次のコマンドを使用して、リスト内のイメージを確認できます。

docker images 

上記のコマンドの出力には画像が含まれています usersignupベース画像と一緒に、 adoptopenjdkDocker ファイルで指定されています。

REPOSITORY          TAG                 SIZE
usersignup          v1                  249MB
adoptopenjdk        11-jre-hotspot      229MB

コンテナイメージ内のレイヤーを表示する

画像内のレイヤーのスタックを見てみましょう。 我々は使用するだろう инструмент  飛び込む、 これらのレイヤーを表示するには:

dive usersignup:v1

以下は、Dive コマンドからの出力の一部です。 

見てわかるように、アプリケーション層がイメージ サイズのかなりの部分を占めています。 最適化の一環として、次のセクションでこの層のサイズを削減したいと思います。

Buildpackを使用したコンテナイメージの作成

組立パッケージ (ビルドパック) は、ソース コードからコンテナー イメージを作成するために、さまざまな Platform as a Service (PAAS) オファリングで使用される一般用語です。 2011 年に Heroku によって発表され、それ以来、Cloud Foundry、Google App Engine、Gitlab、Knative などで採用されています。

クラウドビルドパッケージの利点

Buildpack を使用してイメージを作成する主な利点の XNUMX つは次のとおりです。 イメージ構成の変更は集中管理 (ビルダー) でき、ビルダーを使用してすべてのアプリケーションに伝達できます。

ビルド パッケージはプラットフォームと密接に結合されていました。 クラウドネイティブ ビルドパックは、OCI イメージ形式をサポートすることでプラットフォーム間の標準化を実現し、Docker エンジンでイメージを実行できるようにします。

Spring Boot プラグインの使用

Spring Boot プラグインは、Buildpack を使用してソースから OCI イメージをビルドします。 画像は以下を使用して作成されます bootBuildImageタスク (Gradle) または spring-boot:build-imageターゲット (Maven) とローカルの Docker インストール。

Docker レジストリにプッシュするために必要なイメージの名前をカスタマイズするには、次の名前を指定します。 image tag:

<plugin>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-maven-plugin</artifactId>
  <configuration>
    <image>
      <name>docker.io/pratikdas/${project.artifactId}:v1</name>
    </image>
  </configuration>
</plugin>

Mavenを使ってやってみましょう build-imageアプリケーションの作成とコンテナー イメージの作成の目標。 現時点では Dockerfile は使用していません。

mvn spring-boot:build-image

結果は次のようになります。

[INFO] --- spring-boot-maven-plugin:2.3.3.RELEASE:build-image (default-cli) @ usersignup ---
[INFO] Building image 'docker.io/pratikdas/usersignup:v1'
[INFO] 
[INFO]  > Pulling builder image 'gcr.io/paketo-buildpacks/builder:base-platform-api-0.3' 0%
.
.
.. [creator]     Adding label 'org.springframework.boot.version'
.. [creator]     *** Images (c311fe74ec73):
.. [creator]           docker.io/pratikdas/usersignup:v1
[INFO] 
[INFO] Successfully built image 'docker.io/pratikdas/usersignup:v1'

出力からわかるのは、 paketo Cloud-Native buildpack動作する OCI イメージを作成するために使用されます。 前と同様に、次のコマンドを実行すると、イメージが Docker イメージとしてリストされていることがわかります。

docker images 

結論：

REPOSITORY                             SIZE
paketobuildpacks/run                  84.3MB
gcr.io/paketo-buildpacks/builder      652MB
pratikdas/usersignup                  257MB

Jibを使用したコンテナイメージの作成

Jib は、ソース コードからコンテナ イメージを作成するための代替方法を提供する、Google のイメージ作成プラグインです。

カスタマイズする jib-maven-pluginpom.xml 内:

      <plugin>
        <groupId>com.google.cloud.tools</groupId>
        <artifactId>jib-maven-plugin</artifactId>
        <version>2.5.2</version>
      </plugin>

次に、Maven コマンドを使用して Jib プラグインを実行し、アプリケーションをビルドし、コンテナー イメージを作成します。 前と同様、ここでは Docker ファイルを使用しません。

mvn compile jib:build -Dimage=<docker registry name>/usersignup:v1

上記の Maven コマンドを実行すると、次の出力が得られます。

[INFO] Containerizing application to pratikdas/usersignup:v1...
.
.
[INFO] Container entrypoint set to [java, -cp, /app/resources:/app/classes:/app/libs/*, io.pratik.users.UsersignupApplication]
[INFO] 
[INFO] Built and pushed image as pratikdas/usersignup:v1
[INFO] Executing tasks:
[INFO] [==============================] 100.0% complete

出力には、コンテナー イメージが作成され、レジストリに配置されたことが示されます。

最適化された画像を作成する動機とテクニック

最適化を行う主な理由は XNUMX つあります。

• Производительность: コンテナ オーケストレーション システムでは、コンテナ イメージがイメージ レジストリからコンテナ エンジンを実行しているホストに取得されます。 このプロセスは計画と呼ばれます。 レジストリから大きなイメージを取得すると、コンテナ オーケストレーション システムではスケジュール時間が長くなり、CI パイプラインではビルド時間が長くなります。
• セキュリティ: イメージが大きいほど、脆弱性が存在する領域も大きくなります。

Docker イメージはレイヤーのスタックで構成されており、各レイヤーは Dockerfile 内の命令を表します。 各レイヤーは、基礎となるレイヤーの変更のデルタを表します。 レジストリから Docker イメージをプルすると、レイヤーごとにプルされ、ホスト上にキャッシュされます。

Spring Boot が使用するもの 「ファットJAR」 デフォルトのパッケージ形式として。 厚い JAR を見ると、アプリケーションが JAR 全体のごく一部を占めていることがわかります。 これは最も頻繁に変更される部分です。 残りは Spring Framework の依存関係で構成されます。

最適化の公式は、アプリケーションを Spring Framework の依存関係から別のレベルで分離することに重点を置いています。

厚い JAR ファイルの大部分を形成する依存関係レイヤーは、一度だけダウンロードされ、ホスト システムにキャッシュされます。

アプリケーションの更新およびコンテナーのスケジューリング中に、アプリケーションの薄い層のみがプルされます。 この図に示すように:

次のセクションでは、Spring Boot アプリケーション用にこれらの最適化されたイメージを作成する方法を見ていきます。

Buildpack を使用した Spring Boot アプリケーション用に最適化されたコンテナー イメージの作成

Spring Boot 2.3 は、厚い JAR ファイルの一部を個別のレイヤーに抽出することによる階層化をサポートします。 階層化機能はデフォルトでは無効になっており、Spring Boot Maven プラグインを使用して明示的に有効にする必要があります。

<plugin>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-maven-plugin</artifactId>
  <configuration>
    <layers>
      <enabled>true</enabled>
    </layers>
  </configuration> 
</plugin>

この構成を使用して、最初に Buildpack を使用して、次に Docker を使用してコンテナー イメージをビルドします。以下のセクションで説明します。

起動しましょう build-imageコンテナー イメージを作成するための Maven ターゲット:

mvn spring-boot:build-image

Dive を実行して結果のイメージ内のレイヤーを確認すると、アプリケーション レイヤー (赤で囲まれた部分) が、シック JAR 形式を使用して取得したものと比較してキロバイト単位ではるかに小さいことがわかります。

Docker を使用した Spring Boot アプリケーション用に最適化されたコンテナー イメージの作成

Maven または Gradle プラグインを使用する代わりに、Docker ファイルを使用して階層化された Docker JAR イメージを作成することもできます。

Docker を使用する場合、レイヤーを抽出して最終イメージにコピーするために XNUMX つの追加手順を実行する必要があります。

階層化を有効にして Maven を使用してビルドした後に生成される JAR の内容は次のようになります。

META-INF/
.
BOOT-INF/lib/
.
BOOT-INF/lib/spring-boot-jarmode-layertools-2.3.3.RELEASE.jar
BOOT-INF/classpath.idx
BOOT-INF/layers.idx

出力には、という名前の追加の JAR が表示されます。 spring-boot-jarmode-layertoolsи layersfle.idxファイル。 この追加の JAR ファイルは、次のセクションで説明するように、階層化された処理機能を提供します。

個々のレイヤーの依存関係を抽出する

階層化された JAR からレイヤーを表示および抽出するには、システム プロパティを使用します。 -Djarmode=layertoolsはじめに spring-boot-jarmode-layertoolsアプリケーションの代わりに JAR:

java -Djarmode=layertools -jar target/usersignup-0.0.1-SNAPSHOT.jar

このコマンドを実行すると、使用可能なコマンド オプションを含む出力が生成されます。

Usage:
  java -Djarmode=layertools -jar usersignup-0.0.1-SNAPSHOT.jar

Available commands:
  list     List layers from the jar that can be extracted
  extract  Extracts layers from the jar for image creation
  help     Help about any command

出力にはコマンドが表示されます list, extractи helpс helpデフォルトになります。 でコマンドを実行しましょう listオプション：

java -Djarmode=layertools -jar target/usersignup-0.0.1-SNAPSHOT.jar list

dependencies
spring-boot-loader
snapshot-dependencies
application

レイヤーとして追加できる依存関係のリストが表示されます。

デフォルトのレイヤー:

レイヤー名

ページ内容

dependencies

バージョンに SNAPSHOT が含まれていない依存関係

spring-boot-loader

JAR ローダー クラス

snapshot-dependencies

バージョンに SNAPSHOT が含まれる依存関係

application

アプリケーションのクラスとリソース

レイヤーは次のように定義されます。 layers.idxDocker イメージに追加する必要がある順序でファイルを作成します。 これらのレイヤーは変更されないため、最初の取得後にホストにキャッシュされます。 更新されたアプリケーション層のみがホストにダウンロードされ、サイズが削減されるため高速になります。 .

依存関係を個別のレイヤーに抽出してイメージを構築する

というメソッドを使用して、XNUMX 段階で最終イメージを構築します。 多段階組み立て 。 最初のステップでは依存関係を抽出し、XNUMX 番目のステップでは抽出された依存関係を最終イメージにコピーします。

マルチステージビルド用に Dockerfile を変更しましょう。

# the first stage of our build will extract the layers
FROM adoptopenjdk:14-jre-hotspot as builder
WORKDIR application
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} application.jar
RUN java -Djarmode=layertools -jar application.jar extract

# the second stage of our build will copy the extracted layers
FROM adoptopenjdk:14-jre-hotspot
WORKDIR application
COPY --from=builder application/dependencies/ ./
COPY --from=builder application/spring-boot-loader/ ./
COPY --from=builder application/snapshot-dependencies/ ./
COPY --from=builder application/application/ ./
ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]

この構成を別のファイルに保存します。 Dockerfile2.

次のコマンドを使用して Docker イメージをビルドします。

docker build -f Dockerfile2 -t usersignup:v1 .

このコマンドを実行すると、次の出力が得られます。

Sending build context to Docker daemon  20.41MB
Step 1/12 : FROM adoptopenjdk:14-jre-hotspot as builder
14-jre-hotspot: Pulling from library/adoptopenjdk
.
.
Successfully built a9ebf6970841
Successfully tagged userssignup:v1

Docker イメージがイメージ ID を使用して作成され、タグ付けされていることがわかります。

最後に、前と同じように Dive コマンドを実行して、生成された Docker イメージ内のレイヤーを検査します。 画像 ID またはタグを Dive コマンドへの入力として指定できます。

dive userssignup:v1

出力からわかるように、アプリケーションを含むレイヤーはわずか 11 KB になり、依存関係は別のレイヤーにキャッシュされます。 

個々のレイヤーの内部依存関係を抽出する

カスタム依存関係をアプリケーションと一緒に宣言してパッケージ化するのではなく、カスタム依存関係を別の層に抽出することで、アプリケーション層のサイズをさらに縮小できます。 yml同様の名前のファイル layers.idx:

- "dependencies":
  - "BOOT-INF/lib/"
- "spring-boot-loader":
  - "org/"
- "snapshot-dependencies":
- "custom-dependencies":
  - "io/myorg/"
- "application":
  - "BOOT-INF/classes/"
  - "BOOT-INF/classpath.idx"
  - "BOOT-INF/layers.idx"
  - "META-INF/"

このファイルの中で layers.idxという名前のカスタム依存関係を追加しました。 io.myorg共有リポジトリから取得した組織の依存関係が含まれています。

出力

この記事では、クラウドネイティブ ビルドパックを使用してソース コードからコンテナ イメージを直接ビルドする方法について説明しました。 これは、Docker を使用して通常の方法でコンテナ イメージを作成する代わりの方法です。最初に厚い実行可能 JAR ファイルを作成し、次に Docker ファイルで指示を指定してそれをコンテナ イメージにパッケージ化します。

また、依存関係をホスト上にキャッシュされる個別のレイヤーに取り込む階層化機能を有効にすることでコンテナーを最適化することも検討しました。また、アプリケーションの薄いレイヤーがコンテナーの実行エンジンのスケジュール時に読み込まれます。

この記事で使用されているすべてのソース コードは、次の場所にあります。 githubの .

コマンドリファレンス

この記事で使用したコマンドを簡単にまとめます。

コンテキストのクリア:

docker system prune -a

Docker ファイルを使用してコンテナー イメージを作成します。

docker build -f <Docker file name> -t <tag> .

ソース コードからコンテナー イメージをビルドします (Dockerfile は使用しません)。

mvn spring-boot:build-image

依存関係レイヤーを表示します。 アプリケーション JAR ファイルをビルドする前に、階層化機能が spring-boot-maven-plugin で有効になっていることを確認してください。

java -Djarmode=layertools -jar application.jar list

依存関係レイヤーを抽出しています。 アプリケーション JAR ファイルをビルドする前に、階層化機能が spring-boot-maven-plugin で有効になっていることを確認してください。

 java -Djarmode=layertools -jar application.jar extract

コンテナイメージのリストを表示する

docker images

コンテナ イメージ内の左側を表示します (ダイビング ツールがインストールされていることを確認してください)。

dive <image ID or image tag>

出所： habr.com