欢送拜访我的GitHub

https://github.com/zq2599/blog_demos

内容：所有原创文章分类汇总及配套源码，波及Java、Docker、Kubernetes、DevOPS等；

背景

  1. [《体验SpringBoot(2.3)利用制作Docker镜像(官网计划)》]()一文中，咱们体验了官网举荐的镜像制作计划，执行docker history命令观察镜像外部，发现是由多个layer组成的，如下图：

  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：

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

  1. 此时，三个角色领有的内容都是一样，都是三个layer：

  1. 这时候SpringBoot开发者批改了业务代码，于是做了个新的镜像（TAG是2.0），而后推送到镜像仓库；
  2. <font color="red">重点来了</font>：因为只改了业务代码，因而只有业务class的layer是新的，只有这个layer会被推送到仓库，如下图：

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

  1. 最终后果如下，公共仓库和镜像使用者都已最小的代价失去了2.0镜像：


可见，应用多个layer的镜像，在镜像的散发过程中，相比繁多layer的镜像会更加高效，尤其是应用hub.docker.com这样的外网私有仓库，以及频繁公布新版的场景下；

你不孤独，欣宸原创一路相伴

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

欢送关注公众号：程序员欣宸

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