背景
在我們實際生產容器化部署過程中，往往會遇到 Docker 鏡像很大，部署發佈很慢的情況
影響 docker 鏡像大小的因素，主要有以下三個方面：
1. 基礎鏡像的大小 。儘量選擇 aphine 作為基礎鏡像 減少操作系統內置軟件
2. Dockerfile 指令層數。 這就要求我們優化 Dockerfile 能合併在一行的儘量合併等
3. 應用 jar 的大小。這是今天要分享的重點內容
helloworld 鏡像
我們先來基於 spring boot 2.3.0 構建一個最簡單的 web helloworld，然後構建鏡像。
FROM adoptopenjdk:11-jre-hotspot as builder
WORKDIR application
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} application.jar
ENTRYPOINT ["java", "-jar application.jar"]
docker build --build-arg JAR_FILE=./demo-layer-0.0.1-SNAPSHOT.jar . -t demo:v1.0
查看鏡像分層信息
我們通過 docker inspect demo:v1.0 來看下此鏡像的每層的散列值
// demo:v1.0 版本鏡像分層信息摘要
"Layers": [
"sha256:b7f7d2967507ba709dbd1dd0426a5b0cdbe1ff936c131f8958c8d0f910eea19e",
"sha256:a6ebef4a95c345c844c2bf43ffda8e36dd6e053887dd6e283ad616dcc2376be6",
"sha256:838a37a24627f72df512926fc846dd97c93781cf145690516e23335cc0c27794",
"sha256:28ba7458d04b8551ff45d2e17dc2abb768bf6ed1a46bb262f26a24d21d8d7233",
"sha256:55c91231ac46fdd63c3cf84b88b11f8a04c1870482dcff033029a601bc50e1ab",
"sha256:9816c2d488754509f6024a267738b1e5fe33a7cd33bd25c5a9cdf6d4d7bfed1d",
"sha256:f5fb3f91797d57a92f3f7e033398b8edd094df664db849a4950eabf2f5474535",
"sha256:b87d2ff74819f83038ea2f89736a19cfcf99bfa080b8017d191c900a09a7524f"
]
helloworld 升級重新構建
我們對 helloworld 程序進行部分修改（模擬開發過程），然後重新構建鏡像
docker build --build-arg JAR_FILE=./demo-layer-0.0.1-SNAPSHOT.jar . -t demo:v1.1
此時鏡像分層信息如下 docker inspect demo:v1.1
// demo:v1.1 版本鏡像分層信息摘要
"Layers": [
"sha256:b7f7d2967507ba709dbd1dd0426a5b0cdbe1ff936c131f8958c8d0f910eea19e",
"sha256:a6ebef4a95c345c844c2bf43ffda8e36dd6e053887dd6e283ad616dcc2376be6",
"sha256:838a37a24627f72df512926fc846dd97c93781cf145690516e23335cc0c27794",
"sha256:28ba7458d04b8551ff45d2e17dc2abb768bf6ed1a46bb262f26a24d21d8d7233",
"sha256:55c91231ac46fdd63c3cf84b88b11f8a04c1870482dcff033029a601bc50e1ab",
"sha256:9816c2d488754509f6024a267738b1e5fe33a7cd33bd25c5a9cdf6d4d7bfed1d",
"sha256:f5fb3f91797d57a92f3f7e033398b8edd094df664db849a4950eabf2f5474535",
"sha256:c1b6350d545fea605e0605c4bfd7f4529cfeee3f6759750d6a5ddeb9c882fc8f"
]
比較 v1.0、v1.1 鏡像
通過比較 v1.0 和 v1.1 版本的鏡像摘要信息，我們會發現只有最後的一層發生了變化，我們通過 Dive 是一個用 Go 語言編寫的 Docker 鏡像分析工具 來確定一下 最後一層是做了哪些事情
dive demo:v1.0,「大家會看到是最後的 jar 不一樣 導致 16M 的內容需要重新構建，當你的業務 jar 很大時，這塊就是性能瓶頸」
spring boot 默認打包解密
默認情況下，spring boot 構建出來的 jar ,解壓後可以看到如下目錄結構。默認會當做一個整體 ，在構建鏡像時作為一個單獨層，「沒有區分業務 classes 和 引用的第三方 jar」
META-INF/
MANIFEST.MF
org/
springframework/
boot/
loader/
BOOT-INF/
classes/
lib/
layer jar
通過上文大家就可以知道分層 jar 的思想就是把，jar 再根據規則細分，業務 class 和 三方 jar 分別對應鏡像的不同層，這樣改動業務代碼，只需變動很少的內容 提高構建速度。
開啓分層打包
org.springframework.bootgroupId>
spring-boot-maven-pluginartifactId>
trueenabled>
layers>
configuration>
plugin>