【重识云原生】第六章容器6.1.8节——Docker核心技术UnionFS

江中散人

已于 2022-11-09 21:48:50 修改

阅读量1.4k

点赞数 2

分类专栏：云原生-IaaS专栏文章标签： linux 云原生 docker UnionFS AUFS

于 2022-09-08 08:00:00 首次发布

本文链接：https://blog.csdn.net/junbaozi/article/details/126689860

版权

云原生-IaaS专栏专栏收录该内容

87 篇文章 283 订阅

订阅专栏

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

1 UnionFS综述

1.1 什么是 UnionFS

联合文件系统（Union File System），2004年由纽约州立大学开发，它可以把多个目录内容联合挂载到同一个目录下，而目录的物理位置是分开的。UnionFS可以把只读和可读写文件系统合并在一起，具有写时复制功能，允许只读文件系统的修改可以保存到可写文件系统当中。

UnionFS（联合文件系统）是一种分层、轻量级并且高性能的文件系统，它支持对文件系统的修改作为一次提交来一层层的叠加，同时可以将不同目录挂载到同一个虚拟文件系统下。UnionFS是一种为Linux，FreeBSD和NetBSD操作系统设计的把其他文件系统联合到一个联合挂载点的文件系统服务。它使用branch把不同文件系统的文件和目录“透明地”覆盖，形成一个单一一致的文件系统。这些branches或者是read-only或者是read-write的，所以当对这个虚拟后的联合文件系统进行写操作的时候，系统是真正写到了一个新的文件中。看起来这个虚拟后的联合文件系统是可以对任何文件进行操作的，但是其实它并没有改变原来的文件，这是因为unionfs用到了一个重要的资管管理技术叫写时复制。

写时复制（copy-on-write，下文简称CoW），也叫隐式共享，是一种对可修改资源实现高效复制的资源管理技术。它的思想是，如果一个资源是重复的，但没有任何修改，这时候并不需要立即创建一个新的资源；这个资源可以被新旧实例共享。创建新资源发生在第一次写操作，也就是对资源进行修改的时候。通过这种资源共享的方式，可以显著地减少未修改资源复制带来的消耗，但是也会在进行资源修改的时候增减小部分的开销。

用一个经典的例子来解释一下，Knoppix，一个用于Linux演示、光盘教学和商业产品演示的Linux发行版，就是把一个CD-ROM或者DVD和一个存在在可读写设备（eg，U盘）上的叫knoppix.img的文件系统联合起来。这样任何对CD/DVD上文件的改动都会在被应用在U盘上，不改变原来的CD/DVD上的内容。

当然，这个联合文件系统在现阶段的容器技术体系中，更多的是一类存储驱动概念，实际上各linux发行版会支持不同的联合文件系统实现。Docker 目前支持的联合文件系统包括 OverlayFS, AUFS, Btrfs, VFS, ZFS 和 Device Mapper。

1.2 Docker镜像中对UnionFS的使用背景

任何程序运行时都会有依赖，无论是开发语言层的依赖库，还是各种系统lib、操作系统等，不同的系统上这些库可能是不一样的，或者有缺失的。为了让容器运行时一致，docker将依赖的操作系统、各种lib依赖整合打包在一起（即镜像），然后容器启动时，作为它的根目录（根文件系统rootfs），使得容器进程的各种依赖调用都在这个根目录里，这样就做到了环境的一致性。

不过，这时你可能已经发现了另一个问题：难道每开发一个应用，都要重复制作一次rootfs吗（那每次pull/push一个系统岂不疯掉）？

比如，我现在用Debian操作系统的ISO做了一个rootfs，然后又在里面安装了Golang环境，用来部署我的应用A。那么，我的另一个同事在发布他的Golang应用B时，希望能够直接使用我安装过Golang环境的rootfs，而不是重复这个流程，那么本文的主角UnionFS就派上用场了。

Docker镜像的设计中，引入了层（layer）的概念，也就是说，用户制作镜像的每一步操作，都会生成一个层，也就是一个增量rootfs（一个目录），这样应用A和应用B所在的容器共同引用相同的Debian操作系统层或是Unbuntu系统层等、Golang环境层（作为只读层），而各自有各自应用程序层，和可写层。启动容器的时候通过UnionFS把相关的层挂载到一个目录，作为容器的根文件系统。

需要注意的是，rootfs只是一个操作系统所包含的文件、配置和目录，并不包括操作系统内核。这就意味着，如果你的应用程序需要配置内核参数、加载额外的内核模块，以及跟内核进行直接的交互，你就需要注意了：这些操作和依赖的对象，都是宿主机操作系统的内核，它对于该机器上的所有容器来说是一个“全局变量”，牵一发而动全身。

分层的收益总结：

分层最大的一个好处就是共享资源
有多个镜像都从相同的base镜像构建而来，那么宿主机只需在磁盘上保存一份base镜像；
同时内存中也只需加载一份base镜像，就可以为所有容器服务了，而且镜像的每一层都可以被共享。

1.3 存储驱动

Docker 使用了一系列不同的存储驱动管理镜像内的文件系统并运行容器，这些存储驱动与 Docker 卷（volume）有些不同，存储引擎管理着能够在多个容器之间共享的存储。

想要理解 Docker 使用的存储驱动，我们首先需要理解 Docker 是如何构建并且存储镜像的，也需要明白 Docker 的镜像是如何被每一个容器所使用的；Docker 中的每一个镜像都是由一系列只读的层组成的，Dockerfile 中的每一个命令都会在已有的只读层上创建一个新的层：

FROM ubuntu:15.04

COPY . /app

RUN make /app

CMD python /app/app.py

容器中的每一层都只对当前容器进行了非常小的修改，上述的 Dockerfile 文件会构建一个拥有四层 layer 的镜像：

当镜像被 docker run 命令创建时就会在镜像的最上层添加g zhi一个可写的层，也就是容器层，所有对于运行时容器的修改其实都是对这个容器读写层的修改。

容器和镜像的区别就在于，所有的镜像都是只读的，而每一个容器其实等于镜像加上一个可读写的层，也就是同一个镜像可以对应多个容器。

1.4 AUFS简述

AUFS又叫Another UnionFS，后来叫Alternative UnionFS。AUFS是Docker选用的第一种存储驱动。AUFS具有快速启动容器，高效利用存储和内存的优点，直到现在AUFS仍然是Docker支持的一种存储驱动类型。AUFS可以看成是 UnionFS 的升级版，它完全重写了早期的UnionFS 1.x，其主要目的是为了可靠性和性能，并且引入了一些新的功能，比如可写分支的负载均衡。AUFS在使用上全兼容UnionFS，而且比之前的UnionFS在稳定性和性能上都要好很多，后来的UnionFS 2.x开始抄AUFS中的功能。虽然AUFS没有进到Linux主干里，但是在很多Linux发行版都用了AUFS，比如：Ubuntu 10.04，Debian6.0, Gentoo Live CD支持AUFS。

AUFS 作为联合文件系统，它能够将不同文件夹中的层联合（Union）到了同一个文件夹中，这些文件夹在 AUFS 中称作分支，整个『联合』的过程被称为联合挂载（Union Mount）：

每一个镜像层或者容器层都是 /var/lib/docker/ 目录下的一个子文件夹；在 Docker 中，所有镜像层和容器层的内容都存储在 /var/lib/docker/aufs/diff/ 目录中：

$ ls /var/lib/docker/aufs/diff/

00adcccc1a55a36a610a6ebb3e07cc35577f2f5a3b671be3dbc0e74db9ca691c

93604f232a831b22aeb372d5b11af8c8779feb96590a6dc36a80140e38e764d8

00adcccc1a55a36a610a6ebb3e07cc35577f2f5a3b671be3dbc0e74db9ca691c-init

93604f232a831b22aeb372d5b11af8c8779feb96590a6dc36a80140e38e764d8-init

019a8283e2ff6fca8d0a07884c78b41662979f848190f0658813bb6a9a464a90

93b06191602b7934fafc984fbacae02911b579769d0debd89cf2a032e7f35cfa

而 /var/lib/docker/aufs/layers/ 中存储着镜像层的元数据，每一个文件都保存着镜像层的元数据，最后的 /var/lib/docker/aufs/mnt/ 包含镜像或者容器层的挂载点，最终会被 Docker 通过联合的方式进行组装。

上面的这张图片非常好的展示了组装的过程，每一个镜像层都是建立在另一个镜像层之上的，同时所有的镜像层都是只读的，只有每个容器最顶层的容器层才可以被用户直接读写，所有的容器都建立在一些底层服务（Kernel）上，包括命名空间、控制组、rootfs 等等，这种容器的组装方式提供了非常大的灵活性，只读的镜像层通过共享也能够减少磁盘的占用。

1.5 其他存储驱动

AUFS 只是 Docker 使用的存储驱动的一种，除了 AUFS 之外，Docker 还支持了不同的存储驱动，包括 aufs、devicemapper、overlay2、zfs 和 vfs 等等，在最新的 Docker 中，overlay2 取代了 aufs 成为了推荐的存储驱动，但是在没有 overlay2 驱动的机器上仍然会使用 aufs 作为 Docker 的默认驱动。

不同的存储驱动在存储镜像和容器文件时也有着完全不同的实现，有兴趣的读者可以在 Docker 的官方文档 Select a storage driver 中找到相应的内容。

想要查看当前系统的 Docker 上使用了哪种存储驱动只需要使用以下的命令就能得到相对应的信息：

$ docker info | grep Storage

Storage Driver: aufs

1.5.1 以 OverlayFS 为例

OverlayFS 也是一种与 AUFS 类似的联合文件系统，同样属于文件级的存储驱动，包含了最初的 Overlay 和更新更稳定的 overlay2。Overlay 只有两层：upper 层和 Lower 层。Lower 层代表镜像层，upper 层代表容器可写层。

相当于可以将多个目录mount成为一个合并的目录，在合并的时候有多个源，需要指定哪个源是下层，哪个源是上层。合并之后就会做merge。

如果一个文件在下层，那么合并之后是可以看到的。
如果一个文件在上层，合并之后还是可以看的到的。
如果文件即来自上层和下层，上层文件会将下层文件覆盖掉。

2 使用原理剖析

2.1 Docker 如何使用 UnionFS

上文已经讲到，大多数镜像都不是从头开始制作，而是从一些base镜像基础上创建，比如debian基础镜像。而新镜像就是从基础镜像上一层层叠加新的逻辑构成的。

想象这样一个场景，一台宿主机上运行了100个基于debian base镜像的容器，难道每个容器里都有一份重复的debian拷贝呢？这显然不合理；借助Linux的unionFS，宿主机只需要在磁盘上保存一份base镜像，内存中也只需要加载一份，就能被所有基于这个镜像的容器共享。

当某个容器修改了基础镜像的内容，比如 /bin文件夹下的文件，这时其他容器的/bin文件夹是否会发生变化呢？

根据容器镜像的写时拷贝（Copy-on-Write）技术，某个容器对基础镜像的修改会被限制在单个容器内。

容器镜像由多个镜像层组成，所有镜像层会联合在一起组成一个统一的文件系统。如果不同层中有一个相同路径的文件，比如 /text，上层的 /text 会覆盖下层的 /text，也就是说用户只能访问到上层中的文件 /text。

将中间只读的 rootfs 的集合称为 Docker 镜像，Docker 镜像构建时，会一层层构建，前一层是后一层的基础。每一层构建完就不会再发生改变，后一层上的任何改变只发生在自己这一层。UnionFS 使得镜像的复用、定制变得更为容易。甚至可以用之前构建好的镜像作为基础层，然后进一步添加新的层，以定制自己所需的内容，构建新的镜像。

当用docker run启动这个容器时，实际上在镜像的顶部添加了一个新的可写层。这个可写层也叫容器层。

Docker 镜像都是只读的，当容器启动时，一个新的可写层加载到镜像的顶部！这一层就是我们通常说的容器层，容器之下的都叫镜像层！容器启动后，其内的应用所有对容器的改动，文件的增删改操作都只会发生在容器层中，对容器层下面的所有只读镜像层没有影响。依然引用这张经典图来做形象示意：

2.2 Docker镜像加载原理

docker的镜像实际上由一层一层的文件系统组成，这种层级的文件系统UnionFS。

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本身是没有完整的操作系统的，它需要借助主机，无论是物理机还是虚拟机，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也就存在了，容器就可以去读取这些文件了。