Docker AUFS存储驱动程序

作者：九筒 更新时间：2022-01-31 01:12 阅读原文

Docker AUFS是一个联合文件系统。以前，aufs存储驱动程序是默认存储驱动程序，用于在Docker上管理Ubuntu和Ubuntu之前的Debian版本中的镜像和层。如果您的Linux内核是版本4.0或更高版本，并且您使用的是Docker Engine-Community，请考虑使用较新的[overlay2](/docker/docker-guides/use-the overlayfs-storage-driver)，它的潜在性能优于aufs存储驱动程序。

注意：在某些发行版和Docker版本中不支持AUFS。查看先决条件有关支持的平台，另请参阅存储驱动程序的优先顺序。

先决条件

  • 对于Docker Engine - Community，支待Ubuntu上的AUFS，和Debian之前的版本。
  • 对于Docker EE，U支待Ubuntu上的AUFS。
  • 如果您使用Ubuntu，则需要安装其他软件包将AUFS模块添加到内核。如果不安装这些软件包，则需要在Ubuntu 14.04上使用devicemapper(不建议使用)，或者在Ubuntu 16.04及更高版本上使用overlay2。
  • AUFS不能使用以下支持文件系统：aufs，btrfs或ecryptfs。这意味着包含/var/lib/docker/aufs的文件系统不能是这些文件系统类型之一。

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

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

  1. 使用以下命令来验证您的内核是否支持AUFS。

    $ grep aufs/proc/filesystems

nodev   aufs

  2. 检查Docker使用哪个存储驱动程序。

    $ docker info

<truncated output>
Storage Driver: aufs
Root Dir:/var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 0
Dirperm1 Supported: true
<truncated output>

  3. 如果您使用其他存储驱动程序，不管是内核中不包含AUFS(在这种情况下，将使用其他默认驱动程序)，或者已将Docker明确配置为使用其他驱动程序。检查/etc/docker/daemon.json或ps auxw | grep dockerd来查看Docker是否已通过--storage-driver标志启动。

aufs存储驱动程序如何工作

AUFS是一个联合文件系统，这意味着它在单个Linux主机上分层多个目录，并将它们显示为单个目录。这些目录在AUFS术语中称为branches，在Docker术语中称为layers。

联合过程称为联合挂载(union mount)。

下图显示了基于ubuntu：latest镜像的Docker容器。

Ubuntu容器的图层

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

AUFS使用写时复制(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进行读写

读取文件

考虑三种情况，其中容器打开文件以通过aufs进行读取访问。

  • 该文件在容器层中不存在：如果容器打开文件进行读取访问并且该文件在容器层中尚不存在，则存储驱动程序将从镜像层开始搜索文件容器层下方的层。从找到它的层读取它。

  • 文件仅存在于容器层中：如果容器打开文件进行读取访问，并且文件存在于容器层中，则从那里读取文件。

  • 文件同时存在于容器层和镜像层中：如果容器打开文件进行读取访问并且文件存在于容器层和一个或多个镜像层中，则从容器层读取文件。容器层中的文件掩盖了镜像层中具有相同名称的文件。

修改文件或目录

考虑在某些情况下修改了容器中的文件。

  • 第一次写入文件：容器第一次写入现有文件时，该文件在容器中不存在（upperdir）。 aufs驱动程序执行copy_up操作，将文件从存在的镜像层复制到可写容器层。然后，容器将更改写入容器层中文件的新副本。

但是，AUFS在文件级别而不是块级别工作。这意味着所有copy_up操作都将复制整个文件，即使该文件非常大且只有一小部分正在被修改。这会对容器写入性能产生明显影响。在具有多层的镜像中搜索文件时，AUFS可能会出现明显的延迟。 但是，值得注意的是，copy_up操作仅在第一次写入给定文件时发生。随后对同一文件的写入将对已经复制到容器的文件副本进行操作。

  • 删除文件和目录：

    • 在容器中删除文件时，将在容器层中创建一个whiteout文件。不会删除镜像层中文件的版本(因为镜像层是只读的)。但是，whiteout文件会阻止容器使用它。

    • 在容器中删除目录时，会在容器层中创建opaque文件。这与whiteout文件的工作方式相同，并且即使该目录仍然存在于镜像层中，也可以有效地防止该目录被访问。

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

AUFS和Docker性能

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

  • AUFS存储驱动程序的性能不如overlay2驱动程序，但对于容器密度很重要的PaaS和其他类似用例来说，它是一个不错的选择。这是因为AUFS可以在多个运行中的容器之间有效地共享镜像，从而缩短了容器的启动时间，并减少了磁盘空间的使用。

  • AUFS如何在镜像层和容器之间共享文件的基本机制非常高效地使用了页面缓存。

  • AUFS存储驱动程序可能会在容器写入性能中引入巨大的延迟。这是因为容器第一次写入任何文件时，都需要找到该文件并将其复制到容器的可写层中。当这些文件存在于许多镜像层下面并且文件本身很大时，这些延迟会增加并且变得更加复杂。

性能最佳实践

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

  • **固态设备(SSD)**提供比旋转磁盘更快的读写速度。

  • 将卷用于繁重的工作负载：卷为繁重的工作负载提供最佳和最可预测的性能。这是因为它们绕过了存储驱动程序，并且不会产生任何储存资源随需分配和写入时复制所带来的潜在开销。卷还有其他好处，例如，允许您在容器之间共享数据，并且即使没有正在运行的容器使用它们也可以持久存储。

相关信息