SpringBoot-2.3镜像方案为什么要做多个layer

背景

1. 《体验SpringBoot(2.3)应用制作Docker镜像(官方方案)》一文中，我们体验了官方推荐的镜像制作方案，执行docker history命令观察镜像内部，发现是由多个layer组成的，如下图：
   
2. 问题来了：搞这么多layer干啥？接下来以图文方式，您一起理解docker镜像layer对java开发者的的作用；

声明

本文的目标是通过图文帮助java开发者理解docker镜像的layer作用，内容和实际情况并未完全保持一致，例如基础镜像的layer没有提到，而且java镜像的layer可能不止业务镜像、配置文件、依赖库这三层；

常见角色

使用docker时，有三个常见角色：

1. 镜像制作者：本文中就是SpringBoot应用开发者，写完代码把应用做成docker镜像；
2. docker公共镜像仓库：镜像制作者将镜像推送到仓库给大家使用；
3. 镜像使用者：从镜像仓库将镜像下载到本地使用；

接下来的故事围绕上述三个角色展开；

从制作到使用的过程

1. 如下图，SpringBoot应用开发者，写完代码把应用做成docker镜像，该镜像的TAG是1.0，此时开发者将镜像推送到公共仓库时，一共要推送三个layer：
   
2. 接下来，使用者要下载镜像，就从镜像仓库下载三个layer：
   
3. 此时，三个角色拥有的内容都是一样，都是三个layer：
   
4. 这时候SpringBoot开发者修改了业务代码，于是做了个新的镜像（TAG是2.0），然后推送到镜像仓库；
5. 重点来了：因为只改了业务代码，因此只有业务class的layer是新的，只有这个layer会被推送到仓库，如下图：
   
6. 对镜像使用者来说，如果之前下载过1.0的镜像，此时要用2.0镜像的话，只要从仓库下载最新的业务class的layer即可：
   
7. 最终结果如下，公共仓库和镜像使用者都已最小的代价得到了2.0镜像：
   
   可见，使用多个layer的镜像，在镜像的分发过程中，相比单一layer的镜像会更加高效，尤其是使用hub.docker.com这样的外网公有仓库，以及频繁发布新版的场景下；

欢迎访问我的GitHub

• 地址：https://github.com/zq2599/blog_demos
• 内容：原创文章分类汇总，及配套源码，涉及Java、Docker、K8S、DevOPS等；

欢迎关注我的公众号：程序员欣宸