Docker底层unionfs(overlayfs)、rootfs和镜像分层的内含

Docker unionfs(overlayfs) 实现 rootfs

前提理论******
unionfs联合文件系统
Docker 中的文件存储驱动叫做 storage driver。

Docker 最早支持的stotage driver是 AUFS，它实际上由一层一层的文件系统组成，这种层级的文件系统叫UnionFS。

联合文件系统（UnionFS）：Union 文件系统，是一种分层、轻量级并且高性能的文件系统，它支持对文件系统的修改作为一次提交来一层层的叠加，同时可以将不同目录挂载到同一个虚拟文件系统下（unite serveral directories into a single virtual filesystem）。

Union文件系统是Docker镜像的基础。镜像可以通过分层来进行集成，基于基础镜像可以制作具体的应用镜像。

特性：一次同时加载多个文件系统，但从外面看起来，只能看到一个文件系统，联合加载会把各层文件系统叠加起来，这样最终的文件系统会包含所有底层的文件和目录。

后来出现的docker版本中，除了AUFS，还支持OverlayFS、Btrfs、Device Mapper、VFS、ZFS等storage driver。

rootfs定位

置于整个容器的最底层。

bootfs和rootfs

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等，是copy-on-write资管管理技术叫写时复制的产物。

常用实现

AUFS

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

overlayfs

Overlayfs 是一种堆叠文件系统，它依赖并建立在其它的文件系统之上（例如 ext4fs 和 xfs 等等），并不直接参与磁盘空间结构的划分，仅仅将原来底层文件系统中不同的目录进行“合并”，然后向用户呈现。

简单的总结为以下3点：

（1）上下层同名目录合并；

（2）上下层同名文件覆盖；

（3）lower dir文件写时拷贝。

操作步骤

[root@master ~]# mkdir ovs
[root@master ~]# cd ovs/
[root@master ovs]# ll
总用量 0
[root@master ovs]# mkdir lower
[root@master ovs]# echo a > lower/a
[root@master ovs]# echo c > lower/c
[root@master ovs]# mkdir upper
[root@master ovs]# echo a1 > upper/a
[root@master ovs]# echo b > upper/b
[root@master ovs]# mkdir merged
[root@master ovs]# mkdir work
#初始内容如下
[root@master ovs]# tree ./
./
├── lower
│   ├── a
│   └── c
├── merged
├── upper
│   ├── a
│   └── b
└── work
    └── work
[root@master ovs]# mount -t overlay overlay -o lowerdir=./lower,upperdir=./upper,workdir=./work ./merged
[root@master ovs]# tree ./
./
├── lower
│   ├── a
│   └── c
├── merged
│   ├── a
│   ├── b
│   └── c
├── upper
│   ├── a
│   └── b
└── work
    └── work

merged 目录已经可以同时看到 lower和upper中的文件了，而由于文件a同时存在于lower和upper中，因此被覆盖了，只显示了一个a。现在可以查看下merged中a文件的值，发现是upper中的值，mount挂载的时候指定lower为lowerdir类型，upper为upperdir类型。

[root@master ovs]# cat merged/a
a1

lowerdir是限制为只读，无法进行任何写的操作。

upperdir支持可读可写，可以进行写的操作。

观察下面步骤，可以推出upper跟lower出现同名文件，在merged目录下同名文件内的值是upper目录文件的内容。

[root@master ovs]# echo a2 lower/a
a2 lower/a
[root@master ovs]# cat lower/a
a
[root@master ovs]# cat merged/a
a1

生成的/merged可以作为container的rootfs

思考？？？？？？

1、若是对merged目录下文件进行操作，lower、upper目录下文件内容会不会变化呢？

[root@master merged]# ll
总用量 12
-rw-r--r-- 1 root root 3 4月  17 17:03 a
-rw-r--r-- 1 root root 2 4月  17 17:10 b
-rw-r--r-- 1 root root 2 4月  17 17:02 c
[root@master merged]# cat *
a1
b
c
[root@master merged]# echo testb > b
[root@master merged]# echo testc > c
[root@master merged]# cat *
a1
testb
testc

lower目录

[root@master lower]# ll
总用量 8
-rw-r--r-- 1 root root 2 4月  17 17:02 a
-rw-r--r-- 1 root root 2 4月  17 17:02 c
[root@master lower]# cat c
c
[root@master lower]#

upper目录

[root@master upper]# ll
总用量 12
-rw-r--r-- 1 root root 3 4月  17 17:03 a
-rw-r--r-- 1 root root 6 4月  17 17:25 b
-rw-r--r-- 1 root root 6 4月  17 17:25 c
[root@master upper]# cat b c
testb
testc

出现了一个有意思的地方，upper目录本身就只有a和b俩个文件，突然就多了一个c文件，对比前面mount tree后的目录架构，这是在操作merged文件的时候生成的，而且lower值没有变动，却都生成在了upper下。

原因：因为lower不可进行写操作，所以采用了 CoW 技术，在对 c 进行修改时，复制了一份数据到 overlay 的 upperdir，从 lower copy 到 upper，也叫做 copy_up。

2、删除文件会发生事情呢？
现在lower目录生成一个f文件。

[root@master lower]# echo f > f
[root@master lower]# ll
总用量 12
-rw-r--r-- 1 root root 2 4月