背景
- 《体验SpringBoot(2.3)应用制作Docker镜像(官方方案)》一文中,我们体验了官方推荐的镜像制作方案,执行docker history命令观察镜像内部,发现是由多个layer组成的,如下图:
- 问题来了:搞这么多layer干啥?接下来以图文方式,您一起理解docker镜像layer对java开发者的的作用;
声明
本文的目标是通过图文帮助java开发者理解docker镜像的layer作用,内容和实际情况并未完全保持一致,例如基础镜像的layer没有提到,而且java镜像的layer可能不止业务镜像、配置文件、依赖库这三层;
常见角色
使用docker时,有三个常见角色:
- 镜像制作者:本文中就是SpringBoot应用开发者,写完代码把应用做成docker镜像;
- docker公共镜像仓库:镜像制作者将镜像推送到仓库给大家使用;
- 镜像使用者:从镜像仓库将镜像下载到本地使用;
接下来的故事围绕上述三个角色展开;
从制作到使用的过程
- 如下图,SpringBoot应用开发者,写完代码把应用做成docker镜像,该镜像的TAG是1.0,此时开发者将镜像推送到公共仓库时,一共要推送三个layer:
- 接下来,使用者要下载镜像,就从镜像仓库下载三个layer:
- 此时,三个角色拥有的内容都是一样,都是三个layer:
- 这时候SpringBoot开发者修改了业务代码,于是做了个新的镜像(TAG是2.0),然后推送到镜像仓库;
- 重点来了:因为只改了业务代码,因此只有业务class的layer是新的,只有这个layer会被推送到仓库,如下图:
- 对镜像使用者来说,如果之前下载过1.0的镜像,此时要用2.0镜像的话,只要从仓库下载最新的业务class的layer即可:
- 最终结果如下,公共仓库和镜像使用者都已最小的代价得到了2.0镜像:
可见,使用多个layer的镜像,在镜像的分发过程中,相比单一layer的镜像会更加高效,尤其是使用hub.docker.com这样的外网公有仓库,以及频繁发布新版的场景下;
欢迎访问我的GitHub
- 地址:https://github.com/zq2599/blog_demos
- 内容:原创文章分类汇总,及配套源码,涉及Java、Docker、K8S、DevOPS等;