关于容器技术的原理，我在很早之前翻译过命名空间相关的文章，但这还远远不够，需要切入的还有cgroup、文件系统和网络相关方面的细节。
到了招聘季，稍微有点时间整理这方面的资料，索性先从文件系统入手，本文的目标仅仅是“知其然”。
0x00 对于分层的需求
在LiveCD的场景下，有这么一种需求：要求在发行版启动后，在逻辑上得到一个统一的文件系统，用户能够对其进行读写，而该文件系统中的基础部分来自一个只读文件系统，无法对其进行写操作。
容器镜像的需求也是类似，用户需要能够根据基础镜像构建新镜像，出于共享基础镜像的目的，整个过程并不能影响基础镜像本身，也就是说最终得到的是一个逻辑意义上的新镜像。
通俗而言，就是要求文件系统提供“层次”的概念，目前可选的方案有AUFS，OverlayFS，DeviceMapper等。
作为UnionFS之一的OverlayFS就是这么一种文件系统，它于2014年被合并到3.18内核，顾名思义其主要特性就是“覆盖”，可以结合下图进行理解(图非原创)。
0x01 特性介绍
正如上图所示，在OverlayFS中，存在Lower和Upper的概念，指定的Lower和Upper文件系统共同组成了新的文件系统。
其效果就如同上图所示，我们从Upper的正上方向下观察，存在文件和目录的位置是“不透明”的，因此最终得到的俯视图应该就如同Overlay那一层所示。
对于文件系统而言，“不透明”的另一种表达方式即为覆盖。也就是说Upper中存在的文件会覆盖Lower中的同名文件，但这对于目录而言稍有不同，同名文件会被覆盖，而不同名的则是合并。
对于文件/目录的修改，处理策略如下：
- 若指定文件存在于Upper，则直接修改该文件。
- 若指定文件仅存在于Lower，则会先从Lower拷贝该文件到Upper(copy_up操作)，然后进行修改。
对于文件/目录的创建，效果等同于在Upper层直接进行创建。
对于文件的删除，处理策略如下：
- 若指定文件仅存在于Upper，则直接删除该文件。
- 若指定文件存在于Lower，则在Upper层创建同名的字符设备。
对于目录的删除，处理策略如下：
- 若指定目录仅存在于Upper，则直接删除该目录。
- 若指定目录存在于Lower，则在Upper层创建同名的字符设备。
- 若在删除后再次创建同名目录，且同名目录存在于Lower，此时新的目录成为opaque目录，通过将xattr的“trusted.overlay.opaque”设置为“y”实现标记，此时Upper层的该目录就会完全覆盖Lower中的目录，而非原先的合并。
通过上述策略，使得在OverlayFS中，Lower可以是只读的，而Upper则需要是可写的文件系统。
0x02 copy_up操作
在上一节，我们已经提及了copy_up操作，简单阐述，就是指当涉及需要修改Lower中的数据时，将对应数据从Lower拷贝到Upper的操作。
触发copy_up操作有2个条件：
- 涉及到对文件的写操作，无论是meta信息还是文件内容
- 文件仅存在于Lower文件系统中
创建硬链接也会导致copy_up操作，而符号链接则不会。
copy_up操作在解决一些问题的同事，也带来了一些问题，毕竟它不是万能的。
如果你在copy_up前，对该文件加了文件锁，copy_up后，文件锁的目标并不会改变。对于拥有多个硬链接的文件，亦是如此。
0x03 实战
接下来我们通过实际操作来感受一下OverlayFS的功能。具体的命令如下：
sudo mount -t overlay overlay -olowerdir=LLL,upperdir=UUU,workdir=WWW MMM这里允许存在多个lowerdir，使用“：”分隔即可，upperdir和workerdir是可选的，且它们必须位于同一个文件系统上，workdir似乎是用来存储一些操作的中间产物的。
LLL，UUU，WWW，MMM均为目录，且WWW必须为空。
假设我们有如下目录：
|- lower
| |- a
| |- b
| |- dir/
| | |- c
| | |- d
| |- test/
|- upper/
| |- e
| |- f
| |- dir/
| |- g
|- work/
|- merged/我们可以通过如下命令将lower和upper“合并”，并挂载到merged目录。
sudo mount -t overlay overlay -olowerdir=lower,upperdir=upper,workdir=work merged通过查看merged目录和merged/dir目录，可以得到如下结果：
[codesun@lucode overlay]$ ls -l merged/
总用量 8
-rw-r--r-- 1 codesun users 0 8月 1 00:01 a
-rw-r--r-- 1 codesun users 0 8月 1 00:01 b
drwxr-xr-x 1 codesun users 4096 8月 1 00:02 dir
-rw-r--r-- 1 codesun users 0 8月 1 00:02 e
-rw-r--r-- 1 codesun users 0 8月 1 00:02 f
drwxr-xr-x 2 codesun users 4096 8月 1 00:01 test
[codesun@lucode overlay]$ ls -l merged/dir
总用量 0
-rw-r--r-- 1 codesun users 0 8月 1 00:01 c
-rw-r--r-- 1 codesun users 0 8月 1 00:01 d
-rw-r--r-- 1 codesun users 0 8月 1 00:02 g尝试添加一个新文件h，然后查看upper目录：
[codesun@lucode overlay]$ touch merged/h
[codesun@lucode overlay]$ ls -l upper/
总用量 4
drwxr-xr-x 2 codesun users 4096 8月 1 00:02 dir
-rw-r--r-- 1 codesun users 0 8月 1 00:02 e
-rw-r--r-- 1 codesun users 0 8月 1 00:02 f
-rw-r--r-- 1 codesun users 0 8月 1 00:05 h可以看到，h文件被创建到了upper目录，这个就证明了文件创建的规则。
接下来，我们来测试一下copy_up操作，分为两步：
- 修改文件a的meta信息
- 修改文件b的内容
然后，再次查看uppder目录：
[codesun@lucode overlay]$ touch merged/a
[codesun@lucode overlay]$ echo test >> merged/b
[codesun@lucode overlay]$ ls -l upper/
总用量 8
-rw-r--r-- 1 codesun users 0 8月 1 00:08 a
-rw-r--r-- 1 codesun users 5 8月 1 00:08 b
drwxr-xr-x 2 codesun users 4096 8月 1 00:02 dir
-rw-r--r-- 1 codesun users 0 8月 1 00:02 e
-rw-r--r-- 1 codesun users 0 8月 1 00:02 f
-rw-r--r-- 1 codesun users 0 8月 1 00:05 h可以看到，touch操作修改了文件a的atime信息，所以被copy_up了，文件b由于内容被修改，亦被copy_up。
接下来，我们验证一下文件的删除和文件夹的删除，分为如下几步：
- 删除upper独有的文件e
- 删除test目录
- 删除共有的文件a，测试字符设备机制
[codesun@lucode overlay]$ rm merged/e
[codesun@lucode overlay]$ rmdir merged/test
[codesun@lucode overlay]$ rm merged/a
[codesun@lucode overlay]$ ls -l upper/
总用量 8
c--------- 1 root root 0, 0 8月 1 00:12 a
-rw-r--r-- 1 codesun users 5 8月 1 00:08 b
drwxr-xr-x 2 codesun users 4096 8月 1 00:02 dir
-rw-r--r-- 1 codesun users 0 8月 1 00:02 f
-rw-r--r-- 1 codesun users 0 8月 1 00:05 h
c--------- 1 root root 0, 0 8月 1 00:12 test
[codesun@lucode overlay]$ ls -l lower/
总用量 8
-rw-r--r-- 1 codesun users 0 8月 1 00:01 a
-rw-r--r-- 1 codesun users 0 8月 1 00:01 b
drwxr-xr-x 2 codesun users 4096 8月 1 00:01 dir
drwxr-xr-x 2 codesun users 4096 8月 1 00:01 test可以看到文件e删除后，没有任何字符设备生成，因为它是upper目录独有的，文件a和目录test被删除后，则是生成了字符设备，以表示文件已被删除，而lower目录中的文件a和目录test，并没有任何变化。
接下来，我们来测试opaque目录机制，具体的步骤是删除共有目录dir，然后再创建同名目录。
[codesun@lucode overlay]$ rm -r merged/dir
[codesun@lucode overlay]$ ls -l upper/
总用量 4
c--------- 1 root root 0, 0 8月 1 00:12 a
-rw-r--r-- 1 codesun users 5 8月 1 00:08 b
c--------- 1 root root 0, 0 8月 1 00:15 dir
-rw-r--r-- 1 codesun users 0 8月 1 00:02 f
-rw-r--r-- 1 codesun users 0 8月 1 00:05 h
c--------- 1 root root 0, 0 8月 1 00:12 test
[codesun@lucode overlay]$ ls -l lower/
总用量 8
-rw-r--r-- 1 codesun users 0 8月 1 00:01 a
-rw-r--r-- 1 codesun users 0 8月 1 00:01 b
drwxr-xr-x 2 codesun users 4096 8月 1 00:01 dir
drwxr-xr-x 2 codesun users 4096 8月 1 00:01 test删除dir目录后，可以看到和目录test被删除后一样的现象，lower中的dir目录则并无变化，那么在重新创建dir目录呢？
[codesun@lucode overlay]$ mkdir merged/dir
[codesun@lucode overlay]$ ls -l upper/
总用量 8
c--------- 1 root root 0, 0 8月 1 00:12 a
-rw-r--r-- 1 codesun users 5 8月 1 00:08 b
drwxr-xr-x 2 codesun users 4096 8月 1 00:17 dir
-rw-r--r-- 1 codesun users 0 8月 1 00:02 f
-rw-r--r-- 1 codesun users 0 8月 1 00:05 h
c--------- 1 root root 0, 0 8月 1 00:12 test
[codesun@lucode overlay]$ ls -l merged/dir
总用量 0可以看到，目录创建后，upper中的同名字符设备不见了，而其内部并没有文件c和文件d，也就是说该目录已经是一个opaque目录了。
需要注意的是，在挂载OverlayFS后，如果修改其Lower和Upper目录中的内容，其行为对于合并后的文件系统是未定义的，所以尽量不要这么做。
0xFF 总结
总体而言，OverlayFS的使用还是很方便的，并且其概念也不难理解，在使用Docker时，我们可以通过配置使daemon使用该驱动，据说相交DeviceMapper更适合生产环境。
从目录结构来看，目前我的系统中，Docker默认使用的似乎是DeviceMapper，所以近期还会摸索一下DeviceMapper，尽请期待。