AUFS 是曾是 Docker 默认的首选存储驱动。它非常稳定、有很多真实场景的部署、很强的社区支持。它有以下主要优点:
极短的容器启动时间。
有效的存储利用率。
有效的内存利用率。
虽然如此,但由于它没有包含在 Linux 内核主线中,所有很多 Linux 发行版并不支持 AUFS。
以下章节介绍 AUFS 的特性,并且它们如何作用于 Docker。
AUFS 是一种联合文件系统。它使用同一个 Linux host 上的多个目录,逐个堆叠起来,对外呈现出一个统一的文件系统。AUFS 使用该特性,实现了 Docker 镜像的分层。下图展示出 ubuntu:latest 的镜像的分层。
注意:在 Docker1.10 之前,layer 的 ID 对应着其在 / var/lib/docker 下的目录名称,但在 Docker1.10 之后,不再有这种直接的对应关系。
对于一个容器来说,只有顶层的容器 layer 是可读写的,而下面的 layer 都是只读的。
Docker 使用 AUFS 的 CoW(Copy-on-Write)技术来实现镜像共享和最小化磁盘空间的使用。AUFS 作用于文件层,也就是说 AUFS CoW 拷贝整个文件——即使文件只修改了一点点的内容。所以,它对容器的性能影响很明显,尤其拷贝多层镜像下的大文件,或者是在一个深层次的目录树中进行搜索。
不过,在给定的容器中,这种拷贝到顶层 layer 的操作,每个文件只会做一次。随后,对该文件的读写操作,都只针对容器顶层可读写 layer 的拷贝文件。
通过上面的介绍,很容易想到。如果要在容器中删除一个非顶层 layer 的文件,肯定不会在下层 layer 中直接删除,因为下层 layer 对于容器来说都是只读的。AUFS 存储驱动要删除一个文件,是通过在容器顶层 layer 增加一个来实现的。这个 whiteout 文件可以隐藏下层只读 layer 中文件的存在,容器感知不到只读层 layer 中文的存在。事实上,无论该文件在下层只读 layer 中是否还存在,容器都认为这个文件被删除了。下图展示了 whiteout 文件如何工作的:
AUFS 未能完美的支持 rename(2) 重命名操作,会返回 EXDEV["cross-device link not permitted"],即使源路径和目的路径都在同一个 AUFS 层。因此,你的应用需要能处理 EXDEV,可以用 "拷贝再删除" 的策略来替代 rename 操作。
我在这里做了一个测试,写了一个简单地 C 程序,该程序将目录 test 重命名为目录 gaga,并打印出 rename 的结果。该程序在普通服务器上完美运行,那么在容器中呢?开始做测试吧。
- $ mkdir build-rename
- $ cd build-rename
- $ mkdir test
- $ vim test.c
- #include<stdio.h>
- #include <fcntl.h>
- int main(void)
- {
- char oldname[100] = "test", newname[100]="gaga";
- int ret = rename(oldname, newname);
- if (ret == 0)
- printf("rename ok.\n");
- else
- printf("ret = %d\n", ret);
- return 0;
- }
编译该程序,生成可执行文件 a.out。
- $ gcc test.c
- $ vim Dockerfile
- FROM ubuntu
- WORKDIR /usr/src/app
- COPY ./* /usr/src/app/
- CMD /usr/src/app/a.out
- $ docker build -t rename:v1.0 ./
- $ docker run --rm rename:v1.0
- ret = -1
该容器启动后会执行可执行文件 a.out,重命名一个目录。可见结果,rename 重命名一个目录的确是返回了失败。
只有在 OS 安装了 AUFS 的情况下才能使用 AUFS 存储驱动,一般来说,Debian/Ubuntu 都支持 AUFS,而 Redhat/CentOS 都不支持 AUFS。所以,你需要先查看下你的系统是否安装了 AUFS。
- $ grep aufs /proc/filesystems
- nodev aufs
如果以上命令有输出则表示支持 AUFS,否则就说明还未安装 AUFS。可执行以下步骤:
a. 升级你系统的 kernel 版本到 3.13 或者更高,另外建议安装 kernel headers;
b. 对于 Ubuntu/Debian:安装 linux-image-extra-* 包:
- $ apt-get install linux-image-extra-$(uname -r) \
- linux-image-extra-virtual
如果上述操作无误,就可以使用 AUFS 来作为你 Docker Daemon 的存储驱动了。
- $ dockerd --storage-driver=aufs &
如果想持久化这个配置,可以编辑你的 Docker 配置文件(如 / etc/default/docker,虽然官方已经不建议使用该文件了),并加入 --storage-driver=aufs 选项到 DOCKER_OPTS 中。
- # Use DOCKER_OPTS to modify the daemon startup options.
- DOCKER_OPTS="--storage-driver=aufs"
重启 docker daemon(systemctl restart docker.service)后,确认默认存储驱动是否配置成功:
- $ docker info | grep "Storage Driver"
- Storage Driver: aufs
当 dockerd 使用 AUFS 驱动时,驱动把镜像和容器存储在 Docker host 的本地存储下:/var/lib/docker/aufs。
镜像层存储在 / var/lib/docker/aufs/diff 里。Docker 1.10 之后,镜像对应的目录名称不再和镜像 ID 意义对应了。
/var/lib/docker/aufs/layers / 目录保存了元数据信息,这些元数据显示了 image 层是如何叠加的。该目录下的每个文件,对应了一个层,而这个文件的内容就是该层之下的层。如:
- $ cat /var/lib/docker/aufs/layers/91e54dfb11794fad694460162bf0cb0a4fa710cfa3f60979c177d920813e267c
- d74508fb6632491cea586a1fd7d748dfc5274cd6fdfedee309ecdcbc2bf5cb82
- c22013c8472965aa5b62559f2b540cd440716ef149756e7b958a1b2aba421e87
- d3a1f33e8a5a513092f01bb7eb1c2abf4d711e5105390a3fe1ae2248cfde1391
由于 base layer 之下不再有其它层,所有 base layer 对应的文件内容是空的。
运行中的容器映射在 /var/lib/docker/aufs/mnt/
- $ ls /var/lib/docker/aufs/mnt/670e0053b2ba02ab33dc24daca293e200aa98e871cefec016a5cbf9d41b7cfbf
- bin boot dev etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var
容器的可写层存储在目录 /var/lib/docker/aufs/diff/,即使容器停止了,容器对应的目录依然存在。只有删除容器时,对应的目录才会删除。
对于 PaaS 层来说,AUFS 存储驱动是一个很好的选择。因为 AUFS 有效地在多个运行容器中共享镜像,加速了容器启动时间,减少了容器使用的磁盘空间。
AUFS 在多个镜像层和容器间分享文件所使用的底层机制,高效地使用了系统的页缓存。
同时,AUFS 存储驱动也带来了一些容器写性能上的隐患。这是因为,容器第一次对任何文件的修改,都需要先定位到文件的所在的镜像层次,并拷贝到容器最顶层的读写层。尤其当这些文件存在于很底层,或者文件本身非常大时,性能问题尤其严重。
AUFS 是 Docker 在 Ubuntu/Debian 中的默认存储驱动,虽然后面可能会被替换掉。但暂时来说,它完美地契合 Docker 的特性。并且,如何合理使用,其性能非常优异。另外,需要注意的是,AUFS 对目录的重命名支持得不好,在编写程序时需要注意这点。
来源: http://www.cnblogs.com/styshoo/p/6442041.html