大家好，我是乔克，一名一线运维实践者。
镜像对于YAML工程师来说都不陌生，每天都在和他打交道，编写、构建、发布，重复而有趣。
在我们编写一个构建镜像的Dockerfile之后，只要应用能正常跑起来，便很少再去看这个Dockerfile了（至少我是这样）。对于这个Dockerfile是不是想象中的那么合理，是不是还可以再优化一下，并没有做太深入的思考。
本文主要从以下几个方面带你深入了解镜像的知识。
镜像的基本概念
在了解一件事物的时候，脑海中总是会先问一句“是什么”，学习Docker镜像也是同样的道理，什么是Docker镜像？
在说Docker镜像之前，先简单说说Linux文件系统。
典型的Linux文件系统由bootfs和rootfs组成，bootfs会在Kernel加载到内存后umount掉，所以我们进入系统看到的都是rootfs，比如/etc，/prod，/bin等标准目录。
我们可以把Docker镜像当成一个rootfs，这样就能比较形象是知道什么是Docker镜像，比如官方的ubuntu:21.10，就包含一套完整的ubuntu:21.10最小系统的rootfs，当然其内是不包含内核的。
Docker镜像是一个_特殊的文件系统_，它提供容器运行时需要的程序、库、资源、配置还有一个运行时参数，其最终目的就是能在容器中运行我们的代码。
以上是从宏观的的视角去看Docker镜像是什么，下面再从微观的角度来深入了解一下Docker镜像。假如我们现在只有一个ubuntu:21.10镜像，如果现在需要一个nginx镜像，是不是可以直接在这个镜像中安装一个nginx，然后这个镜像是不是就可以变成nginx镜像？
答案是可以的。其实这里面就有一个分层的概念，底层用的是ubuntu镜像，然后在上面叠加了一个nginx镜像，这样就完成了一个nginx镜像的构建了，这种情况我们称ubuntu镜像为nginx的父镜像。
这么说起来还是有点不好理解，介绍完下面的镜像存储方式，就好理解了。
镜像的存储方式
在说镜像的存储方式之前，先简单介绍一个UnionFS（联合文件系统，Union File System）。
所谓UnionFS就是把不同物理位置的目录合并mount到同一个目录中，然后形成一个虚拟的文件系统。一个最典型的应用就是将一张CD/DVD和一个硬盘的目录联合mount在一起，然后用户就可以对这个只读的CD/DVD进行修改了。
Docker就是充分利用UnionFS技术，将镜像设计成分层存储，现在使用的就是OverlayFS文件系统，它是众多UnionFS中的一种。
OverlayFS只有lower和upper两层。顾名思义，upper层在上面，lower层在下面，upper层的优先级高于lower层。
在使用mount挂载overlay文件系统的时候，遵守以下规则。
- lower和upper两个目录存在同名文件时，lower的文件将会被隐藏，用户只能看到upper的文件。
- lower低优先级的同目录同名文件将会被隐藏。
- 如果存在同名目录，那么lower和upper目录中的内容将会合并。
- 当用户修改merge中来自upper的数据时，数据将直接写入upper中原来目录中，删除文件也同理。
- 当用户修改merge中来自lower的数据时，lower中内容均不会发生任何改变。因为lower是只读的，用户想修改来自lower数据时，overlayfs会首先拷贝一份lower中文件副本到upper中。后续修改或删除将会在upper下的副本中进行，lower中原文件将会被隐藏。
- 如果某一个目录单纯来自lower或者lower和upper合并，默认无法进行rename系统调用。但是可以通过mv重命名。如果要支持rename，需要CONFIG_OVERLAY_FS_REDIRECT_DIR。
下面以OverlayFS为例，直面感受一下这种文件系统的效果。
系统：CentOS 7.9 Kernel：3.10.0
（1）创建两个目录lower、upper、merge、work四个目录
# # mkdir lower upper work merge
其中：
lower目录用于存放lower层文件upper目录用于存放upper层文件work目录用于存放临时或者间接文件merge目录就是挂载目录
（2）在lower和upper两个目录中都放入一些文件，如下：
# echo "From lower." > lower/common-file # echo "From upper." > upper/common-file # echo "From lower." > lower/lower-file # echo "From upper." > upper/upper-file # tree . ├── lower │ ├── common-file │ └── lower-file ├── merge ├── upper │ ├── common-file │ └── upper-file └── work
可以看到lower和upper目录中有相同名字的文件common-file，但是他们的内容不一样。
（3）将这两个目录进行挂载，命令如下：
# mount -t overlay -o lowerdir=lower,upperdir=upper,workdir=work overlay merge
挂载的结果如下：
# tree . ├── lower │ ├── common-file │ └── lower-file ├── merge │ ├── common-file │ ├── lower-file │ └── upper-file ├── upper │ ├── common-file │ └── upper-file └── work └── work # cat merge/common-file From upper.
可以看到两者共同目录common-dir内容进行了合并，重复文件common-file为uppderdir中的common-file。
（4）在merge目录中创建一个文件，查看效果
# echo "Add file from merge" > merge/merge-file # tree . ├── lower │ ├── common-file │ └── lower-file ├── merge │ ├── common-file │ ├── lower-file │ ├── merge-file │ └── upper-file ├── upper │ ├── common-file │ ├── merge-file │ └── upper-file └── work └── work
可以看到lower层没有变化，新增的文件会新增到upper层。
（5）修改merge层的lower-file，效果如下
# echo "update lower file from merge" > merge/lower-file # tree . ├── lower │ ├── common-file │ └── lower-file ├── merge │ ├── common-file │ ├── lower-file │ ├── merge-file │ └── upper-file ├── upper │ ├── common-file │ ├── lower-file │ ├── merge-file │ └── upper-file └── work └── work # cat upper/lower-file update lower file from merge # cat lower/lower-file From lower.
可以看到lower层同样没有变化，所有的修改都发生在upper层。
从上面的实验就可以看到比较有意思的一点：不论上层怎么变，底层都不会变。
Docker镜像就是存在联合文件系统的，在构建镜像的时候，会一层一层的向上叠加，每一层构建完就不会再改变了，后一层上的任何改变都只会发生在自己的这一层，不会影响前面的镜像层。
我们通过一个例子来进行阐述，如下图。
具体如下：
- 基础L1层有file1和file2两个文件，这两个文件都有具体的内容。
- 到L2层的时候需要修改file2的文件内容并且增加file3文件。在修改file2文件的时候，系统会先判定这个文件在L1层有没有，从上图可知L1层是有file2文件，这时候就会把file2复制一份到L2层，然后修改L2层的file2文件，这就是用到了联合文件系统
写时复制机制，新增文件也是一样。 - 到L3层修改file3的时候也会使用
写时复制机制，从L2层拷贝file3到L3层 ，然后进行修改。 - 然后我们在视图层看到的file1、file2、file3都是最新的文件。
上面的镜像层是死的。当我们运行容器的时候，Docker Daemon还会动态生成一个读写层，用于修改容器里的文件，如下图。
比如我们要修改file2，就会使用写时复制机制将file2复制到读写层，然后进行修改。同样，在容器运行的时候也会有一个视图，当我们把容器停掉以后，视图层就没了，但是读写层依然保留，当我们下次再启动容器的时候，还可以看到上次的修改。
值得一提的是，当我们在删除某个文件的时候，其实并不是真的删除，只是将其标记为删除然后隐藏掉，虽然我们看不到这个文件，实际上这个文件会一直跟随镜像。
到此对镜像的分层存储有一定的认识了？这种分层存储还使得镜像的复用、定制变得更容易，就像文章开头基于ubuntu定制nginx镜像。
Dockerfile和镜像的关系
我们经常在应用代码里编写Dockerfile来制作镜像，那Dockerfile和镜像到底是什么关系呢？没有Dockerfile可以制作镜像吗？
我们先来看一个简单的Dockerfile是什么样的。
FROM ubuntu:latest ADD run.sh / VOLUME /data CMD ["./run.sh"]
通过这几个命令就可以做出新的镜像？
是的，通过这几个命令组成文件，docker就可以使用它制作出新的镜像，这是不是有点像给你一些柠檬、冰糖、金银花就能制作出一杯柠檬茶一个道理？
这个一联想，Dockerfile和镜像的关系就清晰明了了。
Dockerfile就是一个原材料，镜像就是我们想要的产品。当我们想要制作某一个镜像的时候，配置好Dcokerfile，然后使用docker命令就能轻松的制作出来。
那不用Dockerfile可以制作镜像吗？
答案是可以的，这时候就需要我们先启动一个基础镜像，通过docker exec命令进入容器，然后安装我们需要的软件，最好再使用docker commit生成新的镜像即可。这种方式就没有Dockerfile那么清晰明了，使用起来也比较麻烦。
镜像和容器的关系
上面说了Dockerfile是镜像的原材料，在这里，镜像就是容器的运行基础。
容器镜像和我们平时接触的操心系统镜像是一个道理，当我们拿到一个操作系统镜像，比如一个以iso结尾的centos镜像，正常情况下，这个centos操作系统并不能直接为我们提供服务，需要我们去安装配置才行。
容器镜像也是一样。
当我们通过Dockerfile制作了一个镜像，这时候的镜像是静态的，并不能为我们提供需要的服务，我们需要通过docker将这个镜像运行起来，使它从镜像变成容器，从静态变成动态。
简单来说，镜像是文件，容器是进程。容器是通过镜像创建的，没有 Docker 镜像，就不可能有 Docker 容器，这也是 Docker 的设计原则之一。
