使用AUFS存储驱动程序（引擎） | Use the AUFS storage driver (Engine)

AUFS 联合文件系统。的aufs存储驱动程序是用于在多克尔管理图像和层的Ubuntu的默认存储驱动器，以及适用于Debian版本拉伸之前。对于Debian Stretch，overlay2是默认值。

AUFS是Docker使用的最成熟的存储驱动程序。它提供了快速的容器启动时间，以及高效的内存和存储使用。

如果您的Linux内核版本为4.0或更高版本，并且您使用Docker CE，请考虑使用较新的overlay2，它比aufs存储驱动程序具有潜在的性能优势。

注意：尽管如果AUFS在Linux内核中存在，但默认情况下使用AUFS，但某些分发版和Docker版本不支持AUFS。请参阅先决条件>以获取有关受支持平台的更多信息，另请参阅存储驱动程序首选项的顺序。

先决条件

对于Docker CE，AUFS在Ubuntu上支持，而在Stretch之前在Debian版本上支持。
对于Docker EE，AUFS在Ubuntu上受支持。
如果您使用Ubuntu，则需要安装额外的软件包以将AUFS模块添加到内核。如果您不安装这些软件包，则需要devicemapper在Ubuntu 14.04（不推荐）或overlay2Ubuntu 16.04及更高版本上使用，这也受支持。
AUFS不能使用下面的后盾文件系统：aufs，btrfs，或ecryptfs。这意味着包含的文件系统/var/lib/docker/aufs不能是这些文件系统类型之一。

使用`aufs`存储驱动程序配置Docker

如果在启动Docker时将AUFS驱动程序加载到内核中，并且没有配置其他存储驱动程序，Docker默认使用它。

使用以下命令来验证您的内核是否支持AUFS。$ grep aufs /proc/filesystems nodev aufs
检查Docker正在使用哪个存储驱动程序。$ docker info <truncated output>存储驱动程序：aufs Root Dir: /var/lib/docker/aufs 备份文件系统：extfs Dirs：0 Dirperm1支持：true<truncated output>
如果您使用的是不同的存储驱动程序，则AUFS不包含在内核中（在这种情况下，将使用不同的默认驱动程序），或者Docker已明确配置为使用不同的驱动程序。检查/etc/docker/daemon.json或输出ps auxw | grep dockerd以查看Docker是否已经启动了--storage-driver标志。

如何`aufs`存储驱动程序作品

AUFS是一个联合文件系统，这意味着它在单个Linux主机上分层多个目录并将它们呈现为单个目录。这些目录在AUFS术语中称为分支，在Docker术语中称为层。统一过程被称为联合安装。

下图显示了一个基于ubuntu:latest图像的Docker容器。

每个图像层和容器层都在Docker主机上表示为子目录/var/lib/docker/。联合安装提供了所有图层的统一视图。目录名称不直接对应于图层本身的ID。

AUFS使用Copy-on-Write（CoW）策略来最大限度地提高存储效率并将开销降至最低。

示例：映像和容器在磁盘上的结构

以下docker pull命令显示了一个Docker主机下载一个包含五层的Docker镜像。

$ docker pull ubuntu

Using default tag: latest
latest: Pulling from library/ubuntu
b6f892c0043b: Pull complete
55010f332b04: Pull complete
2955fb827c94: Pull complete
3deef3fcbd30: Pull complete
cf9722e506aa: Pull complete
Digest: sha256:382452f82a8bbd34443b2c727650af46aced0f94a44463c62a9848133ecb1aa8
Status: Downloaded newer image for ubuntu:latest

图像层

警告：不要直接操作其中的任何文件或目录/var/lib/docker/。这些文件和目录由Docker管理。

所有关于图像和容器图层的信息都存储在中的子目录中/var/lib/docker/aufs/。

diff/：每个图层的内容，每个图层都存储在一个单独的子目录中
layers/：关于图像图层堆叠的元数据。该目录包含Docker主机上每个图像或容器层的一个文件。每个文件都包含堆栈（其父项）下面的所有图层的ID。
mnt/：安装点，每个映像或容器层一个，用于组装和安装容器的统一文件系统。对于只读的图像，这些目录将始终为空。

容器层

如果容器正在运行，则以/var/lib/docker/aufs/下列方式更改内容：

diff/：可写容器层中引入的差异，如新文件或修改过的文件。
layers/：关于可写容器层的父层的元数据。
mnt/：每个正在运行的容器的统一文件系统的安装点，完全与容器内显示的一样。

容器用`aufs`读取和写入的工作方式

读取文件

考虑三种场景，其中一个容器打开一个文件进行重叠读取访问。

该文件不存在于容器层中：如果容器打开一个文件以进行读取访问，并且文件尚不存在于容器层中，则存储驱动程序会在图像层中搜索文件，容器层。它从它所在的图层读取。
该文件仅存在于容器层中：如果容器打开一个用于读取访问的文件，并且文件存在于容器层中，则从该文件中读取该文件。
该文件同时存在于容器图层和图像图层中：如果容器打开文件进行读取访问，并且文件存在于容器图层和一个或多个图像图层中，则从容器图层读取文件。容器图层中的文件会隐藏图像图层中具有相同名称的文件。

修改文件或目录

考虑一些容器中的文件被修改的场景。

第一次写入文件：容器首次写入现有文件时，该文件不存在于容器（upperdir）中。该aufs驱动程序执行copy_up操作将文件从存在的图像层复制到可写容器层。容器然后将更改写入容器层中的文件的新副本。但是，AUFS在文件级别而不是块级别上工作。这意味着所有的copy_up操作都会复制整个文件，即使文件非常大，只有一小部分被修改。这可能会对容器写入性能产生显着影响。AUFS在搜索多层图像中的文件时可能会出现明显的延迟。但是，值得注意的是copy_up操作仅在给定文件第一次写入时发生。随后写入同一文件的操作与已经复制到容器的文件副本相反。
删除文件和目录：

-  When a _file_ is deleted within a container, a _whiteout_ file is created in the container layer. The version of the file in the image layer is not deleted (because the image layers are read-only). However, the whiteout file prevents it from being available to the container.

-  When a _directory_ is deleted within a container, an _opaque file_ is created in the container layer. This works in the same way as a whiteout file and effectively prevents the directory from being accessed, even though it still exists in the image layer.

重命名目录：rename(2)在AUFS上不完全支持呼叫目录。它返回EXDEV（即“跨设备链接不允许”），即使源和目标路径都位于同一个AUFS层上，除非目录中没有子节点。您的应用程序需要被设计为处理EXDEV并回退到“复制和取消链接”策略。

AUFS和Docker性能

总结一些已经提到的性能相关方面：

AUFS存储驱动程序的性能低于overlay2驱动程序，但对于PaaS和其他类似的容器密度很重要的使用案例来说，这是一个不错的选择。这是因为AUFS可以在多个正在运行的容器之间高效地共享映像，从而实现快速的容器启动时间和最少的磁盘空间使用。
AUFS如何在图像层和容器之间共享文件的底层机制非常高效地使用页面缓存。
AUFS存储驱动程序可以在容器写入性能方面引入显着的延迟。这是因为第一次容器写入任何文件时，该文件必须被定位并被复制到容器顶部可写层中。当这些文件存在于许多图像层下并且文件本身很大时，这些延迟会增加并且复杂化。

性能最佳实践

以下通用性能最佳实践也适用于AUFS。

固态设备（SSD）比旋转磁盘提供更快的读取和写入速度。
将卷用于写入繁重的工作负载：卷为写入繁重的工作负载提供最佳和最可预测的性能。这是因为它们绕过了存储驱动程序，并且不会产生精简配置和写入时复制引入的任何潜在开销。卷还有其他好处，例如允许您在容器之间共享数据，并且即使在没有正在运行的容器正在使用它们时也会持久存在。

先决条件

使用aufs存储驱动程序配置Docker

如何aufs存储驱动程序作品