Docker-存储驱动解读（AUFS/DeviceMapper/Overlay）

镜像的分层特性

在说docker的文件系统之前，我们需要先想清楚一个问题。我们知道docker的启动是依赖于image，docker在启动之前，需要先拉取image，然后启动。多个容器可以使用同一个image启动。那么问题来了：这些个容器是共用一个image，还是各自将这个image复制了一份，然后各自独立运行呢？

我们假设每个容器都复制了一份这个image，然后各自独立运行，那么就意味着，启动多少个容器，就需要复制多少个image，毫无疑问这是对空间的一种巨大浪费。事实上，在容器的设计当中，通过同一个Image启动的容器，全部都共享这个image，而并不复制。那么问题又随之而来：既然所有的容器都共用这一个image，那么岂不是我在任意一个容器中所做的修改，在其他容器中都可见？如果我一个容器要将一个配置文件修改成A，而另一个容器同样要将这个文件修改成B，两个容器岂不是会产生冲突？

我们把上面的问题放一放，先来看下面一个拉取镜像的示例：

root@ubuntu:~# docker pull nginx
Using default tag: latest
latest: Pulling from library/nginx
be8881be8156: Pull complete 
32d9726baeef: Pull complete 
87e5e6f71297: Pull complete 
Digest: sha256:6ae5dd1664d46b98257382fd91b50e332da989059482e2944aaa41ae6cf8043a
Status: Downloaded newer image for nginx:latest

上面的示例是从docker官方镜像仓库拉取一个nginx:latest镜像，可以看到在拉取镜像时，是一层一层的拉取的。事实上镜像也是这么一层一层的存储在磁盘上的。通常一个应用镜像包含多层，如下：

我们首先需要明确一点，镜像是只读的。每一层都只读。在上图上，我们可以看到，在内核之上，最底层首先是一个基础镜像层，这里是一个ubuntu的基础镜像，因为镜像的只读特性，如果我们想要在这个ubuntu的基础镜像上安装一个emacs编辑器，则只能在基础镜像之上，在构建一层新的镜像层。同样的道理，如果想要在当前的emacs镜像层之上添加一个apache，则只能在其上再构建一个新的镜像层。而这即是镜像的分层特性。

容器读写层的工作原理

我们刚刚在说镜像的分层特性的时候说到镜像是只读的。而事实上当我们使用镜像启动一个容器的时候，我们其实是可以在容器里随意读写的，从结果上看，似乎与镜像的只读特性相悖。

我们继续看上面的图，其实可以看到在镜像的最上层，还有一个读写层。而这个读写层，即在容器启动时为当前容器单独挂载。每一个容器在运行时，都会基于当前镜像在其最上层挂载一个读写层。而用户针对容器的所有操作都在读写层中完成。一旦容器销毁，这个读写层也随之销毁。

知识点： 容器=镜像+读写层

而我们针对这个读写层的操作，主要基于两种方式：写时复制和用时分配。

写时复制

所有驱动都用到的技术——写时复制（CoW）。CoW就是copy-on-write，表示只在需要写时才去复制，这个是针对已有文件的修改场景。比如基于一个image启动多个Container，如果为每个Container都去分配一个image一样的文件系统，那么将会占用大量的磁盘空间。而CoW技术可以让所有的容器共享image的文件系统，所有数据都从image中读取，只有当要对文件进行写操作时，才从image里把要写的文件复制到自己的文件系统进行修改。所以无论有多少个容器共享同一个image，所做的写操作都是对从image中复制到自己的文件系统中的复本上进行，并不会修改image的源文件，且多个容器操作同一个文件，会在每个容器的文件系统里生成一个复本，每个容器修改的都是自己的复本，相互隔离，相互不影响。使用CoW可以有效的提高磁盘的利用率。

用时配置

用时分配是用在原本没有这个文件的场景，只有在要新写入一个文件时才分配空间，这样可以提高存储资源的利用率。比如启动一个容器，并不会为这个容器预分配一些磁盘空间，而是当有新文件写入时，才按需分配新空间。

Docker存储驱动

接下来我们说一说，这些分层的镜像是如何在磁盘中存储的。

docker提供了多种存储驱动来实现不同的方式存储镜像，下面是常用的几种存储驱动：

• AUFS
• OverlayFS
• Devicemapper

下面说一说AUFS、OberlayFS及Devicemapper，更多的存储驱动说明可参考：http://dockone.io/article/1513

AUFS

AUFS（AnotherUnionFS）是一种Union FS，是文件级的存储驱动。AUFS是一个能透明覆盖一个或多个现有文件系统的层状文件系统，把多层合并成文件系统的单层表示。简单来说就是支持将不同目录挂载到同一个虚拟文件系统下的文件系统。这种文件系统可以一层一层地叠加修改文件。无论底下有多少层都是只读的，只有最上层的文件系统是可写的。当需要修改一个文件时，AUFS创建该文件的一个副本，使用CoW将文件从只读层复制到可写层进行修改，结果也保存在可写层。在Docker中，底下的只读层就是image，可写层就是Container。结构如下图所示：

因为AUFS有很多层，如果要拷贝比较低层的文件时，在穿过很多层时可能会有延迟

Devicemapper

Device mapper是Linux内核2.6.9后支持的，提供的一种从逻辑设备到物理设备的映射框架机制，在该机制下，用户可以很方便的根据自己的需要制定实现存储资源的管理策略。前面讲的AUFS和OverlayFS都是文件级存储，而Device mapper是块级存储，所有的操作都是直接对块进行操作，而不是文件。Device mapper驱动会先在块设备上创建一个资源池，然后在资源池上创建一个带有文件系统的基本设备，所有镜像都是这个基本设备的快照，而容器则是镜像的快照。所以在容器里看到文件系统是资源池上基本设备的文件系统的快照，并没有为容器分配空间。当要写入一个新文件时，在容器的镜像内为其分配新的块并写入数据，这个叫用时分配。当要修改已有文件时，再使用CoW为容器快照分配块空间，将要修改的数据复制到在容器快照中新的块里再进行修改。Device mapper 驱动默认会创建一个100G的文件包含镜像和容器。每一个容器被限制在10G大小的卷内，可以自己配置调整。结构如下图所示：

OverlayFS

Overlay是Linux内核3.18后支持的，也是一种Union FS，和AUFS的多层不同的是Overlay只有两层：一个upper文件系统和一个lower文件系统，分别代表Docker的镜像层和容器层。当需要修改一个文件时，使用CoW将文件从只读的lower复制到可写的upper进行修改，结果也保存在upper层。在Docker中，底下的只读层就是image，可写层就是Container。目前最新的OverlayFS为Overlay2。结构如下图所示：

Overlay2目前是我们最常用的一种驱动，这次会重点介绍下

[root@k8s-node1 overlaytest]# docker inspect 79b938051f81 | jq '.[] | .GraphDriver'
{
  "Data": {
    "LowerDir": "/var/lib/docker/overlay2/1b75ad1a57dd8340f2b692c33953817e50323d0cb3da1b32f30a4129b4a67d82-init/diff:/var/lib/docker/overlay2/8d15c8b485b75e6b7bb3ce98807280b3498c0e64f8d4d3854276de9191442935/diff:/var/lib/docker/overlay2/28d19acdd4c70ce8789f8bf9386073f263c1d60643fc36412bdbf6976d0cf163/diff:/var/lib/docker/overlay2/89d6fff91f9619574c3af6d2af23bc9e20aa2787181be5e4c6b2aa6bc5c5588d/diff:/var/lib/docker/overlay2/25ae7bf75775c69c9ce8913ea4f35bae1cb08eb68d8656ef21d331ee12baf8f8/diff",
    "MergedDir": "/var/lib/docker/overlay2/1b75ad1a57dd8340f2b692c33953817e50323d0cb3da1b32f30a4129b4a67d82/merged",
    "UpperDir": "/var/lib/docker/overlay2/1b75ad1a57dd8340f2b692c33953817e50323d0cb3da1b32f30a4129b4a67d82/diff",
    "WorkDir": "/var/lib/docker/overlay2/1b75ad1a57dd8340f2b692c33953817e50323d0cb3da1b32f30a4129b4a67d82/work"
  },
  "Name": "overlay2"
}

查看docker容器可以看到，每个docker容器有4个Dir
UpperDir和LowerDir分别对应的是读写层和只读层
MergedDir则是合并后的目录，统一的读写都是在该目录，如果是写文件则会自动写到UpperDir下

手动测试下：
1.在支持 overlay文件系统的 Linux (内核3.18以上)的操作系统上一个同级目录内创建四个文件目录 lower，upper，merged ，work。其中 lower 和 upper 文件夹的内容如下图所示，merged 和work 为空，Same文件名相同，内容不同

[root@k8s-node1 overlaytest]# tree -a
.
├── lower
│   ├── Dir_A
│   │   ├── file2
│   │   └── Same
│   ├── Dir_B
│   ├── file4
│   └── Same
├── upper
│   ├── Dir_A
│   │   ├── file1
│   │   └── Same
│   ├── Dir_C
│   ├── file3
│   └── Same
├── merged
└── work

2.挂载overlay系统

[root@k8s-node1 overlaytest]# mount -t overlay overlay -olowerdir=./lower,upperdir=./upper,workdir=./work ./merged

[root@k8s-node1 overlaytest]# df -h | grep overlaytest
overlay                                                                                 1.8T  680G  1.1T   38% /opt/dinghh/overlaytest/merged

[root@k8s-node1 overlaytest]# ll merged/
总用量 12
drwxr-xr-x 1 root root 31 7月  24 16:41 Dir_A
drwxr-xr-x 2 root root  6 7月  24 15:16 Dir_B
drwxr-xr-x 2 root root  6 7月  24 16:37 Dir_C
-rw-r--r-- 1 root root  6 7月  24 16:42 file3
-rw-r--r-- 1 root root  6 7月  24 15:17 file4
-rw-r--r-- 1 root root  7 7月  24 16:42 Same

可以看到挂载之后merged目录下把upper和lower中内容进行了合并
规则如下：
1.文件名及目录不相同，则 lower 及 upper 目录中的文件及目录按原结构都融入到 merged 目录中；
2.文件名相同，只显示 upper 层的文件。如上图在 lower 和 upper 目录下及下层目录 dir_A 下都有 same.txt 文件，但在合并到 merged 目录时，则只显示 upper 的，而 lower 的隐藏 ;
3.目录名相同， 对目录进行合并成一个目录。如上图在 lower 及 upper 目录下都有 dir_A 目录，将目录及目录下的所有文件合并到 merged 的 dir_A 目录，目录内如有文件名相同，则同样只显示 upper 的，如上图中 dir_A 目录下的same.txt文件。

参考：
https://www.jianshu.com/p/ad19a76cac0c
https://www.cnblogs.com/breezey/p/9589288.html