Docker镜像技术剖析

1、概述
- 1.1 什么是镜像？
- 1.2 联合文件系统UnionFS
- 1.3 bootfs和rootfs
- 1.4 镜像结构
- 1.5 镜像的主要技术特点
- - 1.5.1 镜像分层技术
  - 1.5.2 写时复制(copy-on-write)策略
  - 1.5.3 内容寻址存储(content-addressable storage)机制
  - 1.5.4 联合挂载(union mount)技术
2.机制原理

1、概述

1.1 什么是镜像？

Docker镜像是一种轻量级，可以执行的独立软件包，用于打包软件运行环境，或者基于某种运行环境的软件。一个镜像内包含了某个软件所需要的所有内容，包括了代码，运行时，库，环境变量和配置文件。镜像可以理解为模板，对容器来说开箱即用。

1.2 联合文件系统UnionFS

    它是一种分层，轻量级，并且高性能的文件系统。它将对文件系统的修改作为一次提交来一层层的在原先的文件系统中进行叠加；同时它可以将不同的目录挂载到同一个虚拟文件系统下(unite several directories into to a single virtual filesystem)。
    Union文件系统是Docker镜像的基础。镜像可以通过分层进行继承，基于基础镜像，可以制作各种具体的应用镜像。
    一个镜像文件实际上是由多个文件系统组成，但是镜像为我们提供了一个统一的视角，让我们凭直觉认为：我们操作的是一个整体的文件系统。
    因此，当我们从阿里云仓库中下载centos和tomcat镜像时，并不是下载了一个镜像，而是同时下载了很多分镜像，然后向我们展现了最外层的镜像ID。

1.3 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.4 镜像结构

在这里插入图片描述
docker的分层镜像结构如图所示，镜像的最底层必须是一个启动文件系统（bootfs）的镜像层。bootfs的上层镜像称为根镜像（rootfs）或者基础镜像（Base Image），它一般是操作系统，比如centos、debian或者Ubuntu。
用户的镜像必须构建在基础镜像之上。如图所示， emacs镜像层就是在基础镜像上安装emacs创建出来的镜像，在此基础上安装apache又创建了新的镜像层。利用这个新的镜像层启动的容器里运行的是一个已经安装好emacs和apache的Debian系统。

1.5 镜像的主要技术特点

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

1.5.1 镜像分层技术

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

查看镜像分层方式可以通过docker image inspect [IMAGEID]命令。其中RootFS部分则是表示了分层信息。

[root@iZbp1bum6107bp8mgzkeunZ ~]# docker image inspect redis
[
   {
       "Id": "sha256:53aa81e8adfa939348cd4c846c0ab682b16dc7641714e36bfc57b764f0b947dc",
       ...
       ...
       "RootFS": {
           "Type": "layers",
           "Layers": [
                 "sha256:ad6562704f3759fb50f0d3de5f80a38f65a85e709b77fd24491253990f30b6be",     
                 "sha256:49cba0f0997b2bb3a24bcfe71c7cbd6e9f6968ef7934e3ad56b0f1f9361b6b91",   
                 "sha256:309498e524b3e2da1f036d00cd5155e0b74cf9e1d964a3636c8ed63ca4a00d43",
                 "sha256:f7c9b429437f7ada2d3d455ac4ea90ff38e0cb7ef2551b08d152264b74116309",        
                 "sha256:4dabdd56bbf16307e2328cb6ed1d42b0bb9b8f40551421271c0b38dc9a685dcc",        
                 "sha256:ea450ad6ef893e998f88a35dc9cc22f952c62b88d58f948344cf4eda1a6264fc"
           ]
       },
  }
]

所有的Docker镜像都起始于一个基础镜像层，当镜像修改或者新增新的内容时，就会在当前镜像层之上，创建新的镜像层。即在添加额外的镜像层的同时，镜像始终保持是当前所有镜像的组合。docker通过存储引擎（新版本采用快照机制）的方式实现镜像层堆栈，并保证多个镜像层对外展示为统一的文件系统。示例：
在这里插入图片描述
这个镜像中包含了三个镜像层，第一层有三个文件，第二层也有三个文件，第三层镜像中仅有一个文件，且这个文件是对第二层镜像中的文件5的一个更新版本。在这种情况下，上层镜像层中的文件会覆盖底层镜像层的文件，这样就使得文件的更新版本作为一个新的镜像层添加到镜像当中。
最后docker通过存储引擎将所有镜像层堆叠并合并，对外提供统一的视图。
在这里插入图片描述
Dockerfile中的操作对于镜像分层的影响：在镜像构建过程中需要向镜像写入数据的时候会产生分层，一个写操作指令产生一个分层。

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

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

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

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

1.5.4 联合挂载(union mount)技术

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

2.机制原理

在这里插入图片描述

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

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

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

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

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

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

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