Union File System 在 Docker 中的应用

Union File System

Union File System,简称 UnionFS,关于联合文件系统我之前的一篇博客里也写过的 《Docker 镜像与数据容器卷》,是一种为 Linux、FreeBSD 和 NetBSD 操作系统设计的,把其他文件系统联合到一个联合挂载点的文件系统服务。它使用 branch 把不同文件系统的文件和目录 “透明地” 覆盖,形成一个单一一致的文件系统。这些 branch 或者是 read-only 的,或者是 read-write 的,所以当对这个虚拟后的联合文件系统进行写操作的时候,系统是真正写到了一个新的文件中。看起来这个虚拟后的联合文件系统是可以对任何文件进行操作的,但是其实它并没有改变原来的文件,这是因为 unionfs 用到了一个重要的资源管理技术,叫写时拷贝。

关于写时拷贝技术用到的地方有很多,我在之前一篇转载的文章中也说到了写时拷贝技术,《谈谈写时拷贝》,可以参考 Unix 的 fork 函数与 vfork 函数,还是很容易明白的,调用 fork 函数时,内核只为新生成的子进程创建虚拟空间结构,它们来复制于父进程的虚拟究竟结构,但是不为这些段分配物理内存,它们共享父进程的物理空间,当父子进程中有更改相应段的行为发生时,再为子进程相应的段分配物理空间。 vfork 函数调用时连内核连子进程的虚拟地址空间结构也不创建了,直接共享了父进程的虚拟空间,当然了,这种做法就顺水推舟的共享了父进程的物理空间。

高级多层统一文件系统 AUFS

AUFS(全称:advanced multi-layered unification filesystem 高级多层统一文件系统)用于为 Linux 文件系统实现联合挂载。AUFS 完全重写了早期的 UnionFS 1.x,其主要目的是为了可靠性和性能,并且引入了一些新的功能,比如可写分支的负载均衡。AUFS 的一些实现已经被纳入 UnionFS 2.x 版本。同 UnionFS 类似,它能够将不同类型的文件系统透明地层叠在一起,实现一个高效的分层文件系统。说白了 AUFS 就是能将不同的目录挂载到某一目录下,并将各个源目录下的内容联合到目标目录下,这里每个源目录对应 aufsAUFS 一层,用户在目标目录读写时,感觉不到此目录是联合而来的。早期的 Docker 就是使用了 AUFS 作为第一种存储驱动。从 Linux 对 AUFS 支持版本可以看出,最新的内核已经支持到了 AUFS 5, http://aufs.sourceforge.net/

Docker 如何使用 AUFS

首先得看一下 Docker 的镜像层,每一个 Docker image 都是由一系列只读镜像层 (image layer) 组成的。镜像层的内容都存储在 Docker hosts filesystem 的 /var/lib/docker/aufs/diff 目录下。而 /var/lib/docker/aufs/layers 目录,则存储着镜像层如何堆叠这些镜像的元数据,可以近似看成是镜像层之间的依赖关系!

我在我的 Ubuntu16.04 上安装了 Docker1.11.2,执行 ls /var/lib/docker/aufs/diff/ 发现无任何文件

mark

拉取镜像后,可以看到在 docker pull 中的结果显示 ubuntu:l5.04 镜像一共有 4 个 layer ,在执行命令的结果中也有 4 个对应的存储文件目录。自从 Docker1.10 之后,diff 目录下的存储镜像 layer 文件夹不再与镜像 ID 相同。

mark

所以说,/var/lib/docker/aufs/layers 目录,则存储着镜像层如何堆叠这些镜像的元数据,可以近似看成是镜像层之间的依赖关系!

接下来,以 ubuntu:l5.04 镜像为基础镜像,创建一个名为 changed-ubuntu 的镜像。这个镜像只是在镜像的 /tmp 文件夹中添加一个写了 “Hello world” 的文件。可以使用下面的 DockerFile 来实现。

mark

使用如下命令,可以清楚地查看到 changed-ubuntu 镜像使用了哪些 image layer

mark

从输出中可以看到 83f8696997cf image layer 位于最上层,只有 12B 的大小,由 /bin/sh -c echo"Hello World"> /tmp/newfile 命令创建

也就是说,changed-ubuntu 镜像只占用了 12B 的磁盘空间,这也证明了 AUFS 是如何高效使用磁盘空间的。而下面的四层 image layer ,则是共享地构成 ubuntu:15.04 镜像的 4 个 image layer 。”missing” 标记的 layer,是自 Docker1.10 之后,一个镜像的 image layer 的 image history 数据都存储在一个文件中导致的,这是 Docker 官方认为的正常行为,可以看到新的镜像层需要之前的四层来构建:

mark

进一步探查 /var/lib/docker/aufs/diff/f973657917d003daa420129cc1f1d802e2d31e34429d1ded178fa988d94f9182 文件夹,发现其中存储了一个 /tmp/newfile 文件,文件中只有一行 “Hello world”,至此我们完整地分析出了 image layer 和 AUFS 是如何通过共享文件和文件夹来实现镜像存储的。

mark

mark

container layer 与 AUFS

Docker 使用 AUFS 的 COW 技术来实现 image layer 共享和减少磁盘空间占用。COW 意味着一旦某个文件只有很小的部分有改动, AUFS 也需要复制整个文件。这种设计会对容器性能产生一定的影响,尤其是在待复制的文件很大,或者位于很多 image layer 下方,又或者 AUFS 需要深度搜索目录结构树的时候。不过也不用过度担心,对于一个容器而言,每个 image layer 最多只需要复制一次。后续的改动都会在第一次拷贝的 container layer 上进行。

启动一个 container 的时候,Docker 会为其创建一个 read-only 的 init layer,用来存储与这个容器内环境相关的内容:Docker 还会为其创建一个 read-write 的 layer 来执行所有写操作。

container layer 的 mount 目录也是 /var/lib/docker/aufs/mnt。container 的元数据和配置文件都存放在 /var/lib/docker/containers/<container-id>目录中。container 的 read-write layer 存储在 /var/lib/docker/aufs/diff/ 目录下。即使容器停止,这个可读写层仍然存在,因而重启容器不会丢失数据,只有当一个容器被删除的时候,这个可读写层才会一起删除。

接下来,仍然用实验来证明上面的结论。首先查询到现有的容器数目为 0 ,而且在 /var/lib/docker/containers 目录下也没有查到任何数据。最后,查看一下系统的 aufs mount 情况,发现只有一个 config 文件。

mark

如上图,我们启动了一个 changed-ubuntu 容器,查看 /var/lib/docker/aufs/diff 目录发现,下面多了 2 个文件夹,fe0d1e8647d74a0f0a6eaf381ba135502be61e8eb323f31767e48fda4042fb01-init 是 Docker 为容器创建的 read-only 的 init layer,而 fe0d1e8647d74a0f0a6eaf381ba135502be61e8eb323f31767e48fda4042fb01 则是 Docker 为容器创建的 read-write layer

在 /var/lib/docker/containers 目录下多了一个与 containerid 相同的文件夹,存放着容器的 metadata 和 config 文件

mark

接下来从系统 AUFS 来看 mount 的情况,在 /sys/fs/aufs/ 目录下多了一个 si_dca9c25b7188665e 文件夹,执行如下命令

mark

可以清楚地看到这就是刚刚创建的容器的 layer 权限, 只有最上面的 fe0d1e8647d74a0f0a6eaf381ba135502be61e8eb323f31767e48fda4042fb01 layer 是 read-write 权限

说一下 AUFS 如何为 container 删除一个文件。如果要删除 file1 时,AUFS 会在 container 的 read-write 层生成一个.wh.file1 的文件来隐藏所有 read-only 层的 file1 文件。至此,我们己清楚地描述和验证了 Docker 是如何使用 AUFS 来管理 container layer 的