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

欢迎访问我的GitHub

https://github.com/zq2599/blog_demos

内容:所有原创文章分类汇总及配套源码,涉及Java、Docker、Kubernetes、DevOPS等;

背景

  1. [《体验SpringBoot(2.3)应用制作Docker镜像(官方方案)》]()一文中,我们体验了官方推荐的镜像制作方案,执行docker history命令观察镜像内部,发现是由多个layer组成的,如下图:

SpringBoot-2.3镜像方案为什么要做多个layer_第1张图片

  1. 问题来了:搞这么多layer干啥?接下来以图文方式,您一起理解docker镜像layer对java开发者的的作用;

声明

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

常见角色

使用docker时,有三个常见角色:

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

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

从制作到使用的过程

  1. 如下图,SpringBoot应用开发者,写完代码把应用做成docker镜像,该镜像的TAG是1.0,此时开发者将镜像推送到公共仓库时,一共要推送三个layer:

SpringBoot-2.3镜像方案为什么要做多个layer_第2张图片

  1. 接下来,使用者要下载镜像,就从镜像仓库下载三个layer:

SpringBoot-2.3镜像方案为什么要做多个layer_第3张图片

  1. 此时,三个角色拥有的内容都是一样,都是三个layer:

SpringBoot-2.3镜像方案为什么要做多个layer_第4张图片

  1. 这时候SpringBoot开发者修改了业务代码,于是做了个新的镜像(TAG是2.0),然后推送到镜像仓库;
  2. 重点来了:因为只改了业务代码,因此只有业务class的layer是新的,只有这个layer会被推送到仓库,如下图:

SpringBoot-2.3镜像方案为什么要做多个layer_第5张图片

  1. 对镜像使用者来说,如果之前下载过1.0的镜像,此时要用2.0镜像的话,只要从仓库下载最新的业务class的layer即可:

SpringBoot-2.3镜像方案为什么要做多个layer_第6张图片

  1. 最终结果如下,公共仓库和镜像使用者都已最小的代价得到了2.0镜像:

SpringBoot-2.3镜像方案为什么要做多个layer_第7张图片
可见,使用多个layer的镜像,在镜像的分发过程中,相比单一layer的镜像会更加高效,尤其是使用hub.docker.com这样的外网公有仓库,以及频繁发布新版的场景下;

你不孤单,欣宸原创一路相伴

  1. Java系列
  2. Spring系列
  3. Docker系列
  4. kubernetes系列
  5. 数据库+中间件系列
  6. DevOps系列

欢迎关注公众号:程序员欣宸

微信搜索「程序员欣宸」,我是欣宸,期待与您一同畅游Java世界...
https://github.com/zq2599/blog_demos

你可能感兴趣的:(云计算)