【重识云原生】第六章容器6.1.9节——Docker镜像技术剖析

  《重识云原生系列》专题索引：

1. 第一章——不谋全局不足以谋一域
2. 第二章计算第1节——计算虚拟化技术总述
3. 第二章计算第2节——主流虚拟化技术之VMare ESXi
4. 第二章计算第3节——主流虚拟化技术之Xen
5. 第二章计算第4节——主流虚拟化技术之KVM
6. 第二章计算第5节——商用云主机方案
7. 第二章计算第6节——裸金属方案
8. 第三章云存储第1节——分布式云存储总述
9. 第三章云存储第2节——SPDK方案综述
10. 第三章云存储第3节——Ceph统一存储方案
11. 第三章云存储第4节——OpenStack Swift 对象存储方案
12. 第三章云存储第5节——商用分布式云存储方案
13. 第四章云网络第一节——云网络技术发展简述
14. 第四章云网络4.2节——相关基础知识准备
15. 第四章云网络4.3节——重要网络协议
16. 第四章云网络4.3.1节——路由技术简述
17. 第四章云网络4.3.2节——VLAN技术
18. 第四章云网络4.3.3节——RIP协议
19. 第四章云网络4.3.4节——OSPF协议
20. 第四章云网络4.3.5节——EIGRP协议
21. 第四章云网络4.3.6节——IS-IS协议
22. 第四章云网络4.3.7节——BGP协议
23. 第四章云网络4.3.7.2节——BGP协议概述
24. 第四章云网络4.3.7.3节——BGP协议实现原理
25. 第四章云网络4.3.7.4节——高级特性
26. 第四章云网络4.3.7.5节——实操
27. 第四章云网络4.3.7.6节——MP-BGP协议
28. 第四章云网络4.3.8节——策略路由
29. 第四章云网络4.3.9节——Graceful Restart(平滑重启)技术
30. 第四章云网络4.3.10节——VXLAN技术
31. 第四章云网络4.3.10.2节——VXLAN Overlay网络方案设计
32. 第四章云网络4.3.10.3节——VXLAN隧道机制
33. 第四章云网络4.3.10.4节——VXLAN报文转发过程
34. 第四章云网络4.3.10.5节——VXlan组网架构
35. 第四章云网络4.3.10.6节——VXLAN应用部署方案
36. 第四章云网络4.4节——Spine-Leaf网络架构
37. 第四章云网络4.5节——大二层网络
38. 第四章云网络4.6节——Underlay 和 Overlay概念
39. 第四章云网络4.7.1节——网络虚拟化与卸载加速技术的演进简述
40. 第四章云网络4.7.2节——virtio网络半虚拟化简介
41. 第四章云网络4.7.3节——Vhost-net方案
42. 第四章云网络4.7.4节vhost-user方案——virtio的DPDK卸载方案
43. 第四章云网络4.7.5节vDPA方案——virtio的半硬件虚拟化实现
44. 第四章云网络4.7.6节——virtio-blk存储虚拟化方案
45. 第四章云网络4.7.8节——SR-IOV方案
46. 第四章云网络4.7.9节——NFV
47. 第四章云网络4.8.1节——SDN总述
48. 第四章云网络4.8.2.1节——OpenFlow概述
49. 第四章云网络4.8.2.2节——OpenFlow协议详解
50. 第四章云网络4.8.2.3节——OpenFlow运行机制
51. 第四章云网络4.8.3.1节——Open vSwitch简介
52. 第四章云网络4.8.3.2节——Open vSwitch工作原理详解
53. 第四章云网络4.8.4节——OpenStack与SDN的集成
54. 第四章云网络4.8.5节——OpenDayLight
55. 第四章云网络4.8.6节——Dragonflow

56.  第四章云网络4.9.1节——网络卸载加速技术综述

57. 第四章云网络4.9.2节——传统网络卸载技术

58. 第四章云网络4.9.3.1节——DPDK技术综述

59. 第四章云网络4.9.3.2节——DPDK原理详解

60. 第四章云网络4.9.4.1节——智能网卡SmartNIC方案综述

61. 第四章云网络4.9.4.2节——智能网卡实现

62. 第六章容器6.1.1节——容器综述

63. 第六章容器6.1.2节——容器安装部署

64. 第六章容器6.1.3节——Docker常用命令

65. 第六章容器6.1.4节——Docker核心技术LXC

66. 第六章容器6.1.5节——Docker核心技术Namespace

67. 第六章容器6.1.6节—— Docker核心技术Chroot

68. 第六章容器6.1.7.1节——Docker核心技术cgroups综述

69. 第六章容器6.1.7.2节——cgroups原理剖析

70. 第六章容器6.1.7.3节——cgroups数据结构剖析

71. 第六章容器6.1.7.4节——cgroups使用

72. 第六章容器6.1.8节——Docker核心技术UnionFS

73. 第六章容器6.1.9节——Docker镜像技术剖析

74. 第六章容器6.1.10节——DockerFile解析

75. 第六章容器6.1.11节——docker-compose容器编排

76. 第六章容器6.1.12节——Docker网络模型设计

77. 第六章容器6.2.1节——Kubernetes概述

78. 第六章容器6.2.2节——K8S架构剖析

79. 第六章容器6.3.1节——K8S核心组件总述

80. 第六章容器6.3.2节——API Server组件

81. 第六章容器6.3.3节——Kube-Scheduler使用篇

82. 第六章容器6.3.4节——etcd组件

83. 第六章容器6.3.5节——Controller Manager概述

84. 第六章容器6.3.6节——kubelet组件

85. 第六章容器6.3.7节——命令行工具kubectl

86. 第六章容器6.3.8节——kube-proxy

87. 第六章容器6.4.1节——K8S资源对象总览

88. 第六章容器6.4.2.1节——pod详解

89. 第六章容器6.4.2.2节——Pod使用(上)

90. 第六章容器6.4.2.3节——Pod使用(下)

91. 第六章容器6.4.3节——ReplicationController

92. 第六章容器6.4.4节——ReplicaSet组件

93. 第六章容器基础6.4.5.1节——Deployment概述

94. 第六章容器基础6.4.5.2节——Deployment配置详细说明

95. 第六章容器基础6.4.5.3节——Deployment实现原理解析

96. 第六章容器基础6.4.6节——Daemonset

97. 第六章容器基础6.4.7节——Job

98. 第六章容器基础6.4.8节——CronJob

1 容器镜像概述

1.1 什么是镜像

1. 镜像就是一个可执行独立运行的软件包。包含应用运行所必须的文件和依赖包;
2. 镜像可以理解为类或者模板，只要在容器的环境下开箱即用;

        Docker容器与镜像的关系：

1.2 bootfs和rootfs

        通常而言，Linux的操作系统由两类文件系统组成：bootfs（boot file system）和rootfs（root file system），它们分别对应着系统内核与根目录文件。bootfs层主要为系统内核文件，这层的内容是无法修改的。当我们的系统在启动时会加载bootfs，当加载完成后整个内核都会存到内存中，然后系统会将bootfs卸载掉。

        而rootfs层则包含了系统中常见的目录和文件，如/bin，/etc，/proc等等。

        bootfs(boot file system）主要包含 bootloader 和 Kernel ， bootloader 主要是引导加 kernel, Linux刚启动时会加载 bootfs 文件系统，在 Docker 镜像的最底层是 bootfs 。这一层与我们典型的 Linux/Unix系统是一样的，包含 boot 加载器和内核。当 boot 加载完成之后整个内核就都在内存中了，此时内存的使用权已由 bootfs 转交给内核，此时系统也会卸载 bootfs 。

        rootfs（root file system)，在 bootfs之上。包含的就是典型 Linux系统中 的 /dev,/proc,/bin,/etc 等标准目录和文件。 rootfs就是各种不同的操作系统发行版，比如 Ubuntu, Centos 等等。平时我们安装进虚拟机的CentOS都是好几个G，为什么Docker这里才200M？

        对于精简的 OS，rootfs 可以很小，只需要包合最基本的命令，工具和程序库就可以了，因为底层直接用宿主机的kernel，自己只需要提供 rootfs 就可以了。由此可见对于不同的Linux发行版， bootfs 基本是一致的，rootfs会有差別，因此不同的发行版可以共用 bootfs。

        Docker的镜像技术可以使用宿主机的bootfs层，这使得镜像本身只需要封装rootfs层所需要的文件和工具即可。因此，镜像可以根据需要进行定制化封装，减少占用的存储空间，如部分极精简的镜像只有几MB大小。

        在不同Linux发行版本中，它们之间的主要区别在于rootfs层，比如ubuntu使用apt管理软件，而Centos使用yum方式。而在内核层面，两者的差别并不大。因此，我们可以在一台主机上同时支持不同Linux系统的镜像而不出现报错，如同时启动Centos和Ubuntu的容器。

        但需要注意的是，不管容器使用什么系统的镜像，实际的内核版本都与镜像无关，都为宿主机的内核。如ubuntu16.04 的容器跑在Centos7.x的宿主机上，虽然ubuntu的内核版本是4.x.x，但我们在容器中会看到内核为centos 7.x 的内核，即 3.x.x。如果是对内核版本的要求的程序，可能会因此受到影响。

1.3 Docker镜像的主要技术特点

        为了更好的理解docker镜像的结构，下面介绍一下docker镜像设计上的关键技术。

1.3.1 镜像分层技术

        docker镜像是采用分层的方式构建的，每个镜像都由一系列的"镜像层"组成。分层结构是docker镜像如此轻量的重要原因。当需要修改容器镜像内的某个文件时，只对处于最上方的读写层进行变动，不覆写下层已有文件系统的内容，已有文件在只读层中的原始版本仍然存在，但会被读写层中的新版本所隐藏。当使用docker commit提交这个修改过的容器文件系统为一个新的镜像时，保存的内容仅为最上层读写文件系统中被更新过的文件。分层达到了在不的容器同镜像之间共享镜像层的效果。

1.3.2 写时复制(copy-on-write)策略

        docker镜像使用了写时复制(copy-on-write)的策略，在多个容器之间共享镜像，每个容器在启动的时候并不需要单独复制一份镜像文件，而是将所有镜像层以只读的方式挂载到一个挂载点，再在上面覆盖一个可读写的容器层。在未更改文件内容时，所有容器共享同一份数据，只有在docker容器运行过程中文件系统发生变化时，才会把变化的文件内容写到可读写层，并隐藏只读层中的老版本文件。写时复制配合分层机制减少了镜像对磁盘空间的占用和容器启动时间。

1.3.3 内容寻址存储(content-addressable storage)机制

        在docker 1.10版本后，docker镜像改动较大，其中最重要的特性便是引入了内容寻址存储(content-addressable storage)的机制，根据文件的内容来索引镜像和镜像层。与之前版本对每个镜像层随机生成一个UUID不同，新模型对镜像层的内容计算校验和，生成一个内容哈希值，并以此哈希值代替之前的UUID作为镜像层的唯一标识。该机制主要提高了镜像的安全性，并在pull、push、load和save操作后检测数据的完整性。另外，基于内容哈希来索引镜像层，在一定程度上减少了ID的冲突并且增强了镜像层的共享。对于来自不同构建的镜像层，主要拥有相同的内容哈希，也能被不同的镜像共享。

1.3.4 联合挂载(union mount)技术

        通俗地讲，联合挂载技术可以在一个挂载点同时挂载多个文件系统，将挂载点的原目录与被挂载内容进行整合，使得最终可见的文件系统将会包含整合之后的各层的文件和目录。实现这种联合挂载技术的文件系统通常被称为联合文件系统(union filesystem)。以下图所示的运行Ubuntu:14.04镜像后的容器中的aufs文件系统为例：

        由于初始挂载时读写层为空，所以从用户的角度看，该容器的文件系统与底层的rootfs没有差别；然而从内核的角度看，则是显式区分开来的两个层次。当需要修改镜像内的某个文件时，只对处于最上方的读写层进行了变动，不复写下层已有文件系统的内容，已有文件在只读层中的原始版本仍然存在，但会被读写层中的新版本文件所隐藏，当docker commit这个修改过的容器文件系统为一个新的镜像时，保存的内容仅为最上层读写文件系统中被更新过的文件。联合挂载是用于将多个镜像层的文件系统挂载到一个挂载点来实现一个统一文件系统视图的途径，是下层存储驱动(aufs、overlay等)实现分层合并的方式。所以严格来说，联合挂载并不是docker镜像的必需技术，比如在使用device mapper存储驱动时，其实是使用了快照技术来达到分层的效果。

2 机制原理

2.1 Docker镜像加载逻辑

        docker的镜像实际上由一层一层的文件系统组成，这种层级的文件系统UnionFS，如下图所示:

        docker本身是没有完整的操作系统的，它需要借助主机，无论是物理机还是虚拟机，docker启动的容器没有独立的操作系统，不需要自己的Bootloader ，所以没有bootfs的，因为主机已经启动起来了，但是它需要rootfs。

        以在Linux操作系统主机中启动docker容器为例：

        1. 在Linux操作系统启动后，首先将 rootfs 设置为 readonly, 进行一系列检查, 然后将其切换为 “readwrite”供用户使用。

        2.Docker启动（以unionfs方式加载文件系统），初始化时也是将 rootfs 以 readonly 方式加载并检查；

        3. 接下来，利用 union mount方式将一个readwrite文件系统挂载在readonly 的 rootfs 之上，并且允许再次将下层的 FS(file system) 设定为 readonly 并且向上叠加，这样一组readonly和一个writeable的层级结构就构成了一个 container 的运行时态, 每一个 FS 被称作一个 FS 层。但是在 Docker里，root文件系统永远只能是只读状态。

        4. 这样一层一层堆叠，下面的层永远都是只读的，当所有层级加载完毕之后，它会将最上面的一层变为readwrite。所以针对这个容器的修改，事实上都是在最上面这一层进行的，并不会修改下面的readonly层。Union FS是层层叠加的，可以看到在做镜像构建的时候，差不多每条指令都会作为一个文件层保存下来。

        可以查看到每一层里面执行了什么样的命令。

        5. 在docker run具体容器的时候，就会去回放这个镜像，按照层级一级一级的去加载，通过unionfs方式去加载，这会有不同的驱动，会将dockerfile里面的每一层加载，每一层是readonly的层，然后不断的叠加，将下面一层变为readonly，最终将上面变为writeable，这个时候完整的操作系统所需要的文件系统就存在了，rootfs也就存在了，容器就可以去读取这些文件了。

2.2 镜像内部结构

2.2.1 镜像的内部结构剖析

        在日常的开发中，我们一般不需要自己进行镜像制作，但是如果想要给自己编写的程序制作镜像的话那就需要我们会制作镜像。在制作镜像之前，我们有必要对镜像的内部结构进行了解掌握，不然按照指令要求制作镜像只知其一，不知其二。

1.最小的镜像hello-world

        hello-world镜像是Docker官方提供的最小的镜像，用来验证docker是否安装成功，我们一般使用也是这样。

        从上图中我们可以看到hello-world镜像只有13KB之多，运行这个镜像会出现什么结果呢？

        上面的结果就是运行hello-world镜像之后的结果。她首先说明了你的Docker安装成功，然后简单介绍了运行镜像的过程。

        这个镜像是怎么制作的？

        Dockerfile是镜像的描述文件，定义了如何构建Docker镜像。Dockerfile的语法简洁且可读性强，后面我们会专门文章介绍如何编写Dockerfile。利用Dockerfile我们自己可以编写自己的镜像。

        hello-world镜像的Dockerfile非常简单：

（1）FROM scratch镜像是从白手起家，从0开始构建。

（2）COPY hello/将文件“hello”复制到镜像的根目录。

（3）CMD[“/hello”]容器启动时，执行/hello。

        镜像 hello-world 中就只有一个可执行文件 “hello”，其功能就是打印出 “Hello from Docker ......” 等信息。

        /hello 就是文件系统的全部内容，连最基本的 /bin，/usr, /lib, /dev 都没有。

        hello-world 虽然是一个完整的镜像，但它并没有什么实际用途。通常来说，我们希望镜像能提供一个基本的操作系统环境，用户可以根据

        需要安装和配置软件。这样的镜像我们称作 base 镜像。我们下一节讨论 base 镜像。

2.base镜像

        base镜像有两层含义：

（1）不依赖其他镜像，从scratch构建；

（2）其他镜像可以以之为基础进行扩展。

        所以，能称作base镜像的都是各种Linux发行版的镜像，如Ubuntu、Debian、CentOS等。

        在本篇中我就下载了Ubuntu镜像的多个版本。

2.2.2 镜像的结构分层

        Docker镜像采用分层的结构，由一些松耦合的只读层堆叠而成，并对外展示为一个统一的对象。所有的镜像都开始于一个基础的镜像层，当我们进行修改或内容添加时，会在镜像层上面创建新的一层。

        最底层通常为基础层镜像，然后再层层叠加上来，比如安装一个Python软件，此时会在基础层上面添加一个新的层，上面包含了我们所安装的Python程序。

        镜像做为所有镜像层的组合，如果镜像中有相同路径的文件，则上层镜像会覆盖下层镜像的内容，最终展示为所有层的数据汇总。如下图所示，由于第二层的文件2与第一层具有相同的文件路径，则镜像将以第二层的文件2内容进行展示，第一层只有文件1会被显示。

        我们再来回顾一下前面镜像拉取时的输出内容，Pull complete结尾的每一行代表镜像中某个被拉取的层，每个层级通过一个唯一的ID进行标识。

$ docker pull nginx:1.20

1.20: Pulling from library

/nginx

5eb5b503b376: Pull complete

cdfeb356c029: Pull complete

d86da7454448: Pull complete

7976249980ef: Pull complete

8f66aa6726b2: Pull complete

c004cabebe76: Pull complete

Digest: sha256:02923d65cde08a49380ab3f3dd2f8f90aa51fa2bd358bd85f89345848f6e6623

Status: Downloaded newer image for nginx:1.20 docker.io/library/nginx:1.20

        镜像层的松耦合代表着它不属于某个镜像独有，当不同镜像包含相同的层时，系统只会存储该层的一份内容，这是Docker镜像的重要特点，这样的好处有利于减少存储空间的占用。如下所示，当我们拉取另一个版本的Nginx镜像时，其中ID号为5eb5b503b376的层已经存在，则会显示为Already exists，直接使用此镜像层。

$ docker pull nginx:1.21

1.21: Pulling from library

/nginx

5eb5b503b376: Already exists

1ae07ab881bd: Pull complete

78091884b7be: Pull complete

091c283c6a66: Pull complete

55de5851019b: Pull complete

b559bad762be: Pull complete

Digest: sha256:2834dc507516af02784808c5f48b7cbe38b8ed5d0f4837f16e78d00deb7e7767

Status: Downloaded newer image for nginx:1.21 docker.io/library/nginx:1.21

2.2.3 容器层

        我们前面说到镜像层是只读模板，那么当我们使用镜像生成容器时，为什么又能写入数据呢？这个问题的答案涉及到一个概念：容器层。

        当容器启动时，会有一个新的可写层被加载到镜像的顶部，这一层通常被称为容器层。所有对容器的修改都会发生在容器层，只有容器层是可写入的，容器层以下的镜像层都是只读的。

        当我们对容器进行操作时，底层的工作原理如下：

• 读取文件：当容器需要读取文件时，会先在容器层寻找，如果没有发现，则会从最上层的镜像层往下寻找，当找到文件后读取到内存使用。
• 增加文件：当增加文件时，文件会直接写到最上面容器层，不会影响到镜像层内容。所以，当我们将容器删除时，容器中的文件也会随着消失。
• 修改文件：此时，如果该文件是在容器层的，则会直接修改。否则的话，Docker会从上往下依次在各层镜像中查找此文件 ，当找到后将其复制到容器层中，并进行修改。这被称为容器的写时复制特性（Copy-on-Write），这个技术保证了我们对容器的修改不会影响到底层的镜像，也实现了一个镜像可以被多个容器共用。
• 删除文件：当我们需要删除文件时，Docker也是由上往下寻找该文件 ，如果在容器层的文件会被直接删除，而在镜像层的文件则会被标记，此时在容器将不会再出现此文件，但镜像中的文件并不会做更改。

2.3 联合文件系统​

        关于镜像与容器功能的实现，依赖其使用了联合文件系统（UnionFS）技术，这是一种分层、轻量级并且高性能的文件系统。Docker 目前支持的联合文件系统包括 ​​OverlayFS​​​, ​​AUFS​​​, ​​VFS​​​ ​​Device Mapper等​​，而默认的存储驱动为Overlay2。此部分详细内容参加上一节"6.1.8 Docker核心技术-UnionFS"。

2.4 Docker镜像的存储组织方式

        综合考虑镜像的层级结构，以及volume、init-layer、可读写层这些概念，一个完整的、在运行的容器的所有文件系统结构可以用下图来描述：

　　从图中我们不难看到，除了 echo hello 进程所在的 cgroups 和 namespace 环境之外，容器文件系统其实是一个相对独立的组织。可读写部分(read-write layer 以及 volumes)、init-layer、只读层(read-only layer) 这 3 部分结构共同组成了一个容器所需的下层文件系统，它们通过联合挂载的方式巧妙地表现为一层，使得容器进程对这些层的存在一无所知。

3 构建镜像

3.1 为何要构建镜像

        对于 Docker 用户来说，最好的情况是不需要自己创建镜像。几乎所有常用的数据库、中间件、应用软件等都有现成的 Docker 官方镜像或其他人和组织创建的镜像，我们只需要稍作配置就可以直接使用。

        使用现成镜像的好处除了省去自己做镜像的工作量外，更重要的是可以利用前人的经验。特别是使用那些官方镜像，因为 Docker 的工程师知道如何更好的在容器中运行软件。

        当然，某些情况下我们也不得不自己构建镜像，比如：

1. 找不到现成的镜像，比如自己开发的应用程序。
2. 需要在镜像中加入特定的功能，比如官方镜像几乎都不提供 ssh。

        所以本节我们将介绍构建镜像的方法。同时分析构建的过程也能够加深我们对前面镜像分层结构的理解。

3.2 构建镜像方法

        Docker 提供了两种构建镜像的方法：

1. docker commit 命令
2. Dockerfile 构建文件

3.2.1 docker commit构建镜像

        docker commit 命令是创建新镜像最直观的方法，其过程包含三个步骤：

1. 运行容器
2. 修改容器
3. 将容器保存为新的镜像

        举个例子：在 ubuntu base 镜像中安装 vi 并保存为新镜像。

1) 第一步：运行容器

        -it 参数的作用是以交互模式进入容器，并打开终端。6e2d389d4576 是容器的内部 ID。

2) 第二步：安装 vi

        确认 vi 没有安装。开始安装 apt-get install -y vim

3) 第三步：保存新镜像

        在新窗口中查看当前运行的容器。

        新镜像命名为 ubuntu-with-vi。

        执行 docker commit 命令将容器保存为镜像。

        新镜像命名为 ubuntu-with-vi。

        查看新镜像的属性。

        从 size 上看到镜像因为安装了软件而变大了。从新镜像启动容器，验证 vi 已经可以使用。

        以上演示了如何用 docker commit 创建新镜像。然而，Docker 并不建议用户通过这种方式构建镜像。原因如下：

1. 这是一种手工创建镜像的方式，容易出错，效率低且可重复性弱。比如要在 debian base 镜像中也加入 vi，还得重复前面的所有步骤。
2. 更重要的：使用者并不知道镜像是如何创建出来的，里面是否有恶意程序。也就是说无法对镜像进行审计，存在安全隐患。

        既然 docker commit 不是推荐的方法，我们干嘛还要花时间学习呢？

        原因是：即便是用 Dockerfile（推荐方法）构建镜像，底层也 docker commit 一层一层构建新镜像的。学习 docker commit 能够帮助我们更加深入地理解构建过程和镜像的分层结构。下一节我们学习如何通过 Dockerfile 构建镜像。

3.2.2Dockerfile 构建镜像

        Dockerfile 是一个文本文件，记录了镜像构建的所有步骤。

1）创建Dockerfile文件

touch Dockerfile

2）用 Dockerfile 创建上节的 ubuntu-with-vi，其内容则为：

3）构建镜像

docker build -t ubuntu-with-vi-dockerfile

        ubuntu-with-vi-dockerfile是构建镜像所取的名字。

        运行 docker build 命令，-t 将新镜像命名为 ubuntu-with-vi-dockerfile，命令末尾的 . 指明 build context 为当前目录。

        Docker 默认会从 build context 中查找 Dockerfile 文件，我们也可以通过 -f 参数指定 Dockerfile 的位置。

4）镜像构建成功

        通过 docker images 查看镜像信息。可以看到新镜像已经构建成功，而且大小跟之前docker commit 构建的大小是一样大的。

        下一篇我们将详细讲述DockerFile。

参考链接

Docker入门篇（三）：Docker 镜像 & UnionFS-搜云库技术团队

容器底层-UnionFS 工作原理-AUFS 和 Docker 实现 - 多选参数的个人空间 - OSCHINA - 中文开源技术交流社区

带你玩转 Docker 容器技术之镜像_Java_ttcd的博客-CSDN博客

Docker Container容器镜像技术详解_JavaEdge的技术博客_51CTO博客

Docker容器技术之镜像理论_helmer_hanssen的博客-CSDN博客_docker镜像技术

Docker与容器技术 | 容器镜像 - 知乎

什么是容器镜像？

Docker核心技术之容器与镜像深入了解 - 腾讯云开发者社区-腾讯云

阿里巴巴开源容器镜像加速技术 - 知乎

Docker容器技术之镜像理论-pudn.com

容器技术原理：Docker容器技术原理 - 墨天轮

Docker镜像基本原理 - 大魔王先生 - 博客园

Docker容器实战之镜像与容器的工作原理

Docker的镜像和容器（一）_cdtaogang的博客-CSDN博客