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

OverlayFS是与AUFS类似的现代联合文件系统，但速度更快，实现更简单。Docker为OverlayFS提供了一个存储驱动程序。

本主题将Linux内核驱动程序称为OverlayFSDocker存储驱动程序，overlay或称为Docker存储驱动程序overlay2。

注意：如果您使用OverlayFS，请使用overlay2驱动程序而不是overlay驱动程序，因为它在inode利用率方面效率更高。要使用新的驱动程序，您需要4.0版或更高版本的Linux内核。有关overlayvs 之间差异的更多信息overlay2，请参阅选择存储驱动程序。

先决条件

如果您满足以下先决条件，则支持OverlayFS：

• 仅限Docker CE。Docker EE不支持OverlayFS。有关每个Docker EE平台支持的存储驱动程序列表，请参阅产品兼容性列表。
• 版本4.0或更高版本的Linux内核。如果您使用较旧的内核，则需要使用该overlay驱动程序，这是不推荐的。
• 支持以下支持文件系统：
  • ext4 （仅限RHEL 7.1）
  • xfs（RHEL 7.2和更高版本），但仅限于d_type=true启用。使用xfs_info验证ftype选项设置为1。要xfs正确格式化文件系统，请使用标志-n ftype=1。
• 更改存储驱动程序将使您已创建的任何容器在本地系统上都不可访问。使用docker save保存的容器，并推动现有图像多克尔集线器或私人仓库，让你不必后重新创建它们。

使用overlay或overlay2存储驱动程序配置Docker

要将Docker配置为使用overlay存储驱动程序，Docker主机必须运行Linux内核版本3.18（最好更新），并加载覆盖内核模块。对于overlay2驱动程序，你的内核版本必须是4.0或更新。强烈建议您overlay2尽可能使用。

在执行此过程之前，您必须先满足所有先决条件。

1. 停止Docker。$ sudo systemctl停止docker
2. 将内容复制/var/lib/docker到临时位置。$ cp -au /var/lib/docker /var/lib/docker.bk
3. 如果您想使用所使用的备份文件系统/var/lib/，请格式化文件系统并将其装入/var/lib/docker。请确保将此挂载添加/etc/fstab到永久。
4. 编辑/etc/docker/daemon.json。如果它还不存在，请创建它。假设文件为空，请添加以下内容。{“storage-driver”:“overlay2”}如果您需要使用旧版overlay驱动程序，请改为指定它。要overlay2在CentOS（仅限Docker CE）上使用，还必须设置存储选项overlay2.override_kernel_check。在这种情况下，daemon.json将如下所示：{ "storage-driver": "overlay2", "storage-opts": "overlay2.override_kernel_check=true" }查看每个存储驱动程序的所有存储选项：

- [Stable](../../../reference/commandline/dockerd/index#storage-driver-options)
- [Edge](https://docs.docker.com/edge/engine/reference/commandline/dockerd/#storage-driver-options)

如果daemon.json文件包含格式错误的JSON，Docker将无法启动。

1. 启动Docker。$ sudo systemctl启动docker
2. 验证守护进程正在使用overlay/ overlay2storage驱动程序。使用该docker info命令并查找Storage Driver和Backing filesystem。$ docker info容器：0映像：0存储驱动程序：overlay备份文件系统：extfs <output truncated>

Docker现在使用overlay2存储驱动程序。泊坞窗已自动创建overlay与所需的安装lowerdir，upperdir，merged，和workdir结构。

继续阅读以了解OverlayFS如何在Docker容器中工作的详细信息，以及有关与不同支持文件系统兼容的限制的性能建议和信息。

overlay2drivers如何工作

如果您仍在使用overlay驱动程序而不是overlay2，请参阅覆盖驱动程序如何工作。

OverlayFS将单个Linux主机上的两个目录分层并将它们呈现为单个目录。这些目录称为图层，统一过程称为联合装载。OverlayFS将下部目录称为lowerdir上部目录upperdir。统一视图通过自己的目录公开merged。

虽然overlay驱动程序只能使用一个较低的OverlayFS层，因此需要硬链接来实现多层图像，但该overlay2驱动程序本身最多支持128个较低的OverlayFS层。此功能为和层相关的Docker命令（如docker buildand）提供更好的性能docker commit，并且在后备文件系统上占用更少的inode。

映像和容器层在磁盘上

使用下载五层图像后docker pull ubuntu，您可以看到六个目录/var/lib/docker/overlay2。

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

$ ls -l /var/lib/docker/overlay2

total 24
drwx------ 5 root root 4096 Jun 20 07:36 223c2864175491657d238e2664251df13b63adb8d050924fd1bfcdb278b866f7
drwx------ 3 root root 4096 Jun 20 07:36 3a36935c9df35472229c57f4a27105a136f5e4dbef0f87905b2e506e494e348b
drwx------ 5 root root 4096 Jun 20 07:36 4e9fa83caff3e8f4cc83693fa407a4a9fac9573deaf481506c102d484dd1e6a1
drwx------ 5 root root 4096 Jun 20 07:36 e8876a226237217ec61c4baf238a32992291d059fdac95ed6303bdff3f59cff5
drwx------ 5 root root 4096 Jun 20 07:36 eca1e4e1694283e001f200a667bb3cb40853cf2d1b12c29feda7422fed78afed
drwx------ 2 root root 4096 Jun 20 07:36 l

新的l（小写L）目录包含缩短的层标识符作为符号链接。这些标识符用于避免触及mount命令参数的页面大小限制。

$ ls -l /var/lib/docker/overlay2/l

total 20
lrwxrwxrwx 1 root root 72 Jun 20 07:36 6Y5IM2XC7TSNIJZZFLJCS6I4I4 -> ../3a36935c9df35472229c57f4a27105a136f5e4dbef0f87905b2e506e494e348b/diff
lrwxrwxrwx 1 root root 72 Jun 20 07:36 B3WWEFKBG3PLLV737KZFIASSW7 -> ../4e9fa83caff3e8f4cc83693fa407a4a9fac9573deaf481506c102d484dd1e6a1/diff
lrwxrwxrwx 1 root root 72 Jun 20 07:36 JEYMODZYFCZFYSDABYXD5MF6YO -> ../eca1e4e1694283e001f200a667bb3cb40853cf2d1b12c29feda7422fed78afed/diff
lrwxrwxrwx 1 root root 72 Jun 20 07:36 NFYKDW6APBCCUCTOUSYDH4DXAT -> ../223c2864175491657d238e2664251df13b63adb8d050924fd1bfcdb278b866f7/diff
lrwxrwxrwx 1 root root 72 Jun 20 07:36 UL2MW33MSE3Q5VYIKBRN4ZAGQP -> ../e8876a226237217ec61c4baf238a32992291d059fdac95ed6303bdff3f59cff5/diff

最下层包含一个名为的文件link，其中包含缩短标识符的名称，以及一个名为diff其中包含图层内容的目录。

$ ls /var/lib/docker/overlay2/3a36935c9df35472229c57f4a27105a136f5e4dbef0f87905b2e506e494e348b/

diff  link

$ cat /var/lib/docker/overlay2/3a36935c9df35472229c57f4a27105a136f5e4dbef0f87905b2e506e494e348b/link

6Y5IM2XC7TSNIJZZFLJCS6I4I4

$ ls  /var/lib/docker/overlay2/3a36935c9df35472229c57f4a27105a136f5e4dbef0f87905b2e506e494e348b/diff

bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

次低层和每个高层包含一个名为的文件lower，它表示其父文件，以及一个名为diff其中包含其内容的目录。它还包含一个merged目录，该目录包含其父层和其自身的统一内容以及work由OverlayFS内部使用的目录。

$ ls /var/lib/docker/overlay2/223c2864175491657d238e2664251df13b63adb8d050924fd1bfcdb278b866f7

diff  link  lower  merged  work

$ cat /var/lib/docker/overlay2/223c2864175491657d238e2664251df13b63adb8d050924fd1bfcdb278b866f7/lower

l/6Y5IM2XC7TSNIJZZFLJCS6I4I4

$ ls /var/lib/docker/overlay2/223c2864175491657d238e2664251df13b63adb8d050924fd1bfcdb278b866f7/diff/

etc  sbin  usr  var

要查看在overlayDocker中使用存储驱动程序时存在的安装，请使用该mount命令。为了可读性，下面的输出被截断。

$ mount | grep overlay

overlay on /var/lib/docker/overlay2/9186877cdf386d0a3b016149cf30c208f326dca307529e646afce5b3f83f5304/merged
type overlay (rw,relatime,
lowerdir=l/DJA75GUWHWG7EWICFYX54FIOVT:l/B3WWEFKBG3PLLV737KZFIASSW7:l/JEYMODZYFCZFYSDABYXD5MF6YO:l/UL2MW33MSE3Q5VYIKBRN4ZAGQP:l/NFYKDW6APBCCUCTOUSYDH4DXAT:l/6Y5IM2XC7TSNIJZZFLJCS6I4I4,
upperdir=9186877cdf386d0a3b016149cf30c208f326dca307529e646afce5b3f83f5304/diff,
workdir=9186877cdf386d0a3b016149cf30c208f326dca307529e646afce5b3f83f5304/work)

rw在第二行示出了overlay安装件是可读写的。

overlay driver如何工作

此内容仅适用于overlay驱动程序。Docker建议使用overlay2驱动程序，其工作方式不同。请参阅overlay2驱动程序的工作原理overlay2。

OverlayFS将单个Linux主机上的两个目录分层并将它们呈现为单个目录。这些目录被称为图层，并且统一过程被称为联合安装。OverlayFS将下部目录称为lowerdir上部目录a upperdir。统一视图通过自己的目录公开merged。

下图显示了Docker镜像和Docker容器如何分层。图像层是lowerdir和容器层是upperdir。统一视图通过一个名为的目录公开，该目录merged实际上是容器的装载点。该图显示了Docker构造如何映射到OverlayFS构造。

​

​

在图像图层和容器图层包含相同文件的情况下，容器图层会“wins”并遮挡图像图层中相同文件的存在。

overlay驱动程序仅适用于两层。这意味着多层图像不能实现为多个OverlayFS图层。相反，每个图像层都被实现为其自己的目录下/var/lib/docker/overlay。然后使用硬链接作为空间高效的方式来引用与较低层共享的数据。从Docker 1.10开始，图像层ID不再对应于中的目录名称/var/lib/docker/。

为了创建容器，overlay驱动程序将表示图像顶层的目录和容器的新目录结合起来。图像的顶层是lowerdir覆盖图中的，并且是只读的。容器的新目录upperdir是可写的。

映像和容器层在磁盘上

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

$ docker pull ubuntu

Using default tag: latest
latest: Pulling from library/ubuntu

5ba4f30e5bea: Pull complete
9d7d19c9dc56: Pull complete
ac6ad7efd0f9: Pull complete
e7491a747824: Pull complete
a3ed95caeb02: Pull complete
Digest: sha256:46fb5d001b88ad904c5c732b086b596b92cfb4a4840a3abd0e35dbb6870585e4
Status: Downloaded newer image for ubuntu:latest

图像层

每个图像层都有自己的目录/var/lib/docker/overlay/，其中包含其内容，如下所示。图像层ID不对应于目录ID。

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

$ ls -l /var/lib/docker/overlay/

total 20
drwx------ 3 root root 4096 Jun 20 16:11 38f3ed2eac129654acef11c32670b534670c3a06e483fce313d72e3e0a15baa8
drwx------ 3 root root 4096 Jun 20 16:11 55f1e14c361b90570df46371b20ce6d480c434981cbda5fd68c6ff61aa0a5358
drwx------ 3 root root 4096 Jun 20 16:11 824c8a961a4f5e8fe4f4243dab57c5be798e7fd195f6d88ab06aea92ba931654
drwx------ 3 root root 4096 Jun 20 16:11 ad0fe55125ebf599da124da175174a4b8c1878afe6907bf7c78570341f308461
drwx------ 3 root root 4096 Jun 20 16:11 edab9b5e5bf73f2997524eebeac1de4cf9c8b904fa8ad3ec43b3504196aa3801

图像层目录包含该层独有的文件以及与较低层共享的数据的硬链接。这可以有效利用磁盘空间。

$ ls -i /var/lib/docker/overlay/38f3ed2eac129654acef11c32670b534670c3a06e483fce313d72e3e0a15baa8/root/bin/ls

19793696 /var/lib/docker/overlay/38f3ed2eac129654acef11c32670b534670c3a06e483fce313d72e3e0a15baa8/root/bin/ls

$ ls -i /var/lib/docker/overlay/55f1e14c361b90570df46371b20ce6d480c434981cbda5fd68c6ff61aa0a5358/root/bin/ls

19793696 /var/lib/docker/overlay/55f1e14c361b90570df46371b20ce6d480c434981cbda5fd68c6ff61aa0a5358/root/bin/ls

容器层

容器也存在于Docker主机文件系统的磁盘中/var/lib/docker/overlay/。如果使用该ls -l命令列出正在运行的容器的子目录，则存在三个目录和一个文件：

$ ls -l /var/lib/docker/overlay/<directory-of-running-container>

total 16
-rw-r--r-- 1 root root   64 Jun 20 16:39 lower-id
drwxr-xr-x 1 root root 4096 Jun 20 16:39 merged
drwxr-xr-x 4 root root 4096 Jun 20 16:39 upper
drwx------ 3 root root 4096 Jun 20 16:39 work

lower-id文件包含容器所基于的图像顶层的ID，即Ove​​rlayFS lowerdir。

$ cat /var/lib/docker/overlay/ec444863a55a9f1ca2df72223d459c5d940a721b2288ff86a3f27be28b53be6c/lower-id

55f1e14c361b90570df46371b20ce6d480c434981cbda5fd68c6ff61aa0a5358

upper目录包含容器的读写层的内容，该层对应于OverlayFS upperdir。

merged目录是lowerdirand 的联合装载upperdir，它包含正在运行的容器内的文件系统的视图。

work目录在OverlayFS内部。

要查看在overlayDocker中使用存储驱动程序时存在的安装，请使用mount命令。为了可读性，下面的输出被截断。

$ mount | grep overlay

overlay on /var/lib/docker/overlay/ec444863a55a.../merged
type overlay (rw,relatime,lowerdir=/var/lib/docker/overlay/55f1e14c361b.../root,
upperdir=/var/lib/docker/overlay/ec444863a55a.../upper,
workdir=/var/lib/docker/overlay/ec444863a55a.../work)

rw在第二行示出了overlay安装件是可读写的。

容器读取和写入的工作方式overlay或overlay2

读取文件

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

• 该文件不存在于容器层中：如果容器打开一个文件进行读取访问，并且该文件尚不存在于容器（upperdir）中，则从图像中读取该文件（lowerdir)这会导致很少的性能开销。
• 该文件只存在于容器层中：如果容器打开文件以进行读取访问，并且文件存在于容器（upperdir）中而不存在于image（lowerdir）中，则直接从容器中读取文件。
• 该文件同时存在于容器图层和图像图层中：如果容器打开一个用于读取访问的文件，并且该文件存在于图像图层和容器图层中，则读取容器图层中的文件版本。容器图层（upperdir）中的文件在图像图层（lowerdir）中隐藏具有相同名称的文件。

修改文件或目录

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

• 第一次写入文件：容器首次写入现有文件时，该文件不存在于容器（upperdir）中。的overlay/ overlay2驱动程序执行一个copy_up操作将文件从图像（复制lowerdir）到所述容器（upperdir）。容器然后将更改写入容器层中的文件的新副本。但是，OverlayFS在文件级别而不是块级别上工作。这意味着所有OverlayFS copy_up操作都会复制整个文件，即使\文件非常大并且只有一小部分被修改。这可能会对容器写入性能产生显着影响。但是，有两件事值得注意：

-  The copy\_up operation only occurs the first time a given file is written to. Subsequent writes to the same file operate against the copy of the file already copied up to the container.

-  OverlayFS only works with two layers. This means that performance should be better than AUFS, which can suffer noticeable latencies when searching for files in images with many layers. This advantage applies to both `overlay` and `overlay2` drivers. `overlayfs2` will be slightly less performant than `overlayfs` on initial read, because it has to look through more layers, but it caches the results so this is only a small penalty.

• 删除文件和目录：

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

-  When a _directory_ is deleted within a container, an _opaque directory_ is created within the container (`upperdir`). 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 (`lowerdir`).

• 重命名目录：rename(2)仅当源路径和目标路径位于顶层时，才允许调用目录。否则，它会返回EXDEV错误（“不允许跨设备链接”）。您的应用程序需要被设计为处理EXDEV并回退到“复制和取消链接”策略。

OverlayFS和Docker性能

这两个overlay2和overlay驱动程序比aufs和更高性能devicemapper。在某些情况下，overlay2可能表现更好btrfs。但是，请注意以下细节。

• 页面缓存。OverlayFS支持页面缓存共享。访问同一文件的多个容器共享该文件的单个页面缓存条目。这使得内存驱动程序overlay和overlay2驱动程序更加高效，并且适用于高密度用例（如PaaS）。
• copy_up。与AUFS一样，只要容器首次写入文件，OverlayFS就必须执行复制操作。这可能会延迟写入操作，特别是对于大型文件。但是，一旦文件被复制完毕，后续对该文件的所有写入都会发生在上层，而不需要进一步的复制操作。OverlayFS copy_up操作比AUFS操作要快，因为AUFS支持的层数多于OverlayFS，并且如果搜索很多AUFS层，可能会产生更大的延迟。overlay2同样支持多个图层，但可以缓解高速缓存中的任何性能。
• Inode限制。使用overlay存储驱动程序会导致过多的inode消耗。在Docker主机上存在大量图像和容器时尤其如此。增加文件系统可用的inode数量的唯一方法是重新格式化它。为避免遇到此问题，强烈建议您overlay2尽可能使用。

性能的最佳实践

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

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

OverlayFS兼容性的限制

总结OverlayFS与其他文件系统不兼容的方面：

• open(2)：OverlayFS只实现POSIX标准的一个子集。这可能导致某些OverlayFS操作违反POSIX标准。一种这样的操作是复制操作。假设你的应用程序调用fd1=open("foo", O_RDONLY)，然后fd2=open("foo", O_RDWR)。在这种情况下，您的应用程序期望fd1并fd2引用同一个文件。但是，由于第二次调用后发生的复制操作，open(2)描述符引用不同的文件。的fd1继续引用该文件的图像（在lowerdir）和fd2引用在容器中的文件（upperdir）。解决这个问题的方法是touch引起复制操作发生的文件。随后所有open(2)无论只读还是读写访问模式，操作都将引用容器中的文件（upperdir）。 yum已知会受到影响，除非yum-plugin-ovl安装了包装。如果yum-plugin-ovl软件包在您的发行版中不可用，例如6.8或7.2之前的RHEL / CentOS，则可能需要在运行touch /var/lib/rpm/*之前运行yum install。这个包实现了touch上面提到的解决方法yum。
• rename(2)：OverlayFS不完全支持rename(2)系统调用。您的应用程序需要检测其失败并回退到“复制和取消链接”策略。

容器，存储，驱动程序，OverlayFS