SpringBoot-2.3ミラーリングソリューションに複数のレイヤーがある理由

バックグラウンド

「SpringBoot（2.3）アプリケーションを作成するDockerミラー（公式ソリューション）を体験する」の記事では、次の図に示すように、公式に推奨されているミラーリングソリューションを体験し、docker historyコマンドを実行してミラーの内部を観察し、複数のレイヤーで構成されていることを発見しました。
ここで問題が発生します。非常に多くのレイヤーで何をしますか？次に、グラフィックスとテキストの形式で、Java開発者にとってのDockerイメージレイヤーの役割を理解します。

ステートメント

この記事の目的は、Java開発者がグラフィックスとテキストを通じてDockerイメージのレイヤー機能を理解できるようにすることです。コンテンツは実際の状況と完全には一致していません。たとえば、基本イメージのレイヤーは言及されておらず、Javaイメージのレイヤーにはビジネスイメージ、構成ファイルだけが含まれていない場合があります。ライブラリの3つのレイヤーに依存します。

一般的な役割

dockerを使用する場合、3つの一般的な役割があります。

ミラーリング：ここではSpringBootアプリケーション開発者が、Dockerで作成したコードイメージのアプリケーションを完成させます。
Dockerパブリックミラーウェアハウス：ミラーメーカーがミラーをウェアハウスにプッシュし、誰もが使用できるようにします。
ミラーユーザー：ミラーウェアハウスからローカルで使用するためにミラーをダウンロードします。

次のストーリーは、上記の3つの役割を中心に展開します。

生産から使用までの流れ

次の図に示すように、SpringBootアプリケーション開発者は、コードを記述した後、アプリケーションをDockerイメージに変換します。イメージのTAGは1.0です。このとき、開発者がイメージをパブリックウェアハウスにプッシュすると、合計で3つのレイヤーがあります。
次に、ユーザーがミラーをダウンロードする場合は、ミラーリポジトリから3つのレイヤーをダウンロードします。
現時点では、3人のキャラクターのコンテンツはすべて同じであり、それらはすべて3つのレイヤーです。
この時点で、SpringBoot開発者はビジネスコードを変更して新しいミラーを作成し（TAGは2.0）、それをミラーウェアハウスにプッシュしました。
ここでポイントになります。以下に示すように、ビジネスコードのみが変更されるため、ビジネスクラスのレイヤーのみが新しくなり、このレイヤーのみがウェアハウスにプッシュされます。
ミラーユーザーの場合、以前に1.0ミラーをダウンロードしたことがあり、現時点で2.0ミラーを使用する場合は、最新のサービスクラスレイヤーをウェアハウスからダウンロードするだけで済みます。
最終的な結果は次のとおりです。公共の倉庫とミラーユーザーの両方が最小のコストで2.0ミラーを取得

しました。特にハブを使用する場合、ミラーの分散において、複数層ミラーを使用する方が単一層ミラーリングよりも効率的であることがわかります。 .docker.comなどのインターネット上の公共倉庫、および新しいバージョンが頻繁にリリースされるシナリオ。