overlay
,以及更新更稳定的 overlay2
。Note:如果你使用 OverlayFS,使用overlay2
而不是overlay
驱动,因为overlay2
在 inode 利用率上更高效。要使用新的驱动,你需要系统内核版本 4.0 或者更高版本,除非你是使用 RHEL 或者 CentOS 用户,此时需要内核版本在 3.10.0-514 或更高版本。
overlay
,满足条件下优先使用 overlay2
d_type=true
必须开启。使用 xfs_info
验证 ftype
选项是否为 1
。docker save
保存镜像或推送到 Docker Hub(也可以是内部私有镜像仓库),防止镜像丢失overlay
或 overlay2
驱动/etc/docker/daemon.json
加入 overlay2
存储配置项,重启 docker daemon 即可生效。overlay2
驱动是如何工作的lowerdir
,上层目录称为 upperdir
,统一视图通过称为 merged
自身目录暴露。overlay
驱动仅适用单个 lower OverlayFS 层,因此需要通过硬链接来实现多层镜像,overlay2
驱动原生支持 128 个 lower OverlayFS 层。这个功能为与层相关的命令如 docker build
和 docker commit
提供了更好的性能,并且在后备文件系统上消耗更少的 inode。docker pull ubuntu
下载一个五层镜像后,你可以在 /var/lib/docker/overlay2
目录下看到 6 个目录。l
(小写 L
) 目录包含缩短的层标识符作为软链接,这些标识符用于避免 mount
命令参数页面大小限制。link
的文件,其中包含缩短标识符的名称,以及一个包含镜像内容的名为 diff
的目录。lower
的文件,表示其父级,以及包含这层镜像内容的名为 diff
的目录。它包含一个 merged
目录,包括父层以及自身的统一内容,以及 OverlayFS 自身使用的 work
目录。mount
命令查看 Docker 使用 overlay2
存储驱动的挂载情况:rw
选项显示 overlay
是读写方式挂载的。overlay
驱动是如何工作的lowerdir
,上层目录称为 upperdir
,统一视图通过称为 merged
自身目录暴露。lowerdir
,容器层术语 upperdir
。统一视图通过名为 merged
的目录暴露。overlay
驱动仅适用于两层,这意味着多层镜像不能实现多个 OverlayFS 层。取而代之,每个镜像层都在 /var/lib/docker/overlay
下实现自己的目录。通过硬链接引用与底层共享数据的方式来节省空间。从 Docker 1.10 开始,镜像层 IDs 不再对应于 /var/lib/docker
中的目录名。overlay
驱动组合顶层的目录以及容器的新目录。镜像的顶层是叠加层中的 lowerdir
,并且是只读挂载的。容器的新目录是 upperdir
并且是可写的。docker pull
命令暂时了一个 Docker 主机下载一个包含五层的 Docker 镜像。/var/lib/docker/overlay/
目录下有自己的目录。/var/lib/docker/overlay/
目录下。如果你使用 ls -l
命令列出运行容器的子目录,可以看到三个目录和一个文件存在:lower-id
文件包含了容器所基于的镜像的顶层 ID,即 OverlayFS lowerdir
。upper
目录包含容器读写层的内容,对应 OverlayFS 中的 upperdir
。merged
目录是 lowerdir
和 upperdir
的联合挂载,包含正在运行的容器文件系统视图。work
目录是 OverlayFS 内部目录。mount
命令查看 Docker 使用 overlay
存储驱动的挂载情况:rw
选项显示 overlay
是读写方式挂载的。overlay
或 overlay2
读写的overlay
打开文件读取的场景。upperdir
),则从镜像层(lowerdir
)读取该文件。这会导致很少的性能开销。upperdir
)但不存在于镜像层(lowerdir
)的文件,则直接从容器层中读取该文件。upperdir
)和镜像层(lowerdir
)的文件,则容器层(upperdir
)会覆盖镜像层(lowerdir
) 相同名字的文件。upperdir
)。overlay
/overlay2
驱动程序从镜像层(lowerdir
)执行一个 copy_up
操作到容器层(upperdir
)。然后,容器将更改写入容器层中的文件的新副本。但是,OverlayFS 工作在文件级别而不是块级别,意味着所有 OverlayFS copy_up
操作都会复制整个文件,即使文件非常大,并且只修改了其中的一小部分。这就对容器写入性能产生显著的影响。不过,有两件事值得注意:copy_up
操作仅在第一次写入文件时发生,对同一文件的后续写入操作只对已复制到容器的文件副本进行操作。overlay
和 overlay2
,overlayfs2
在初始读取时的性能略低于 overlayfs
,因为它会查看更多层级,但是它会缓存结果。upperdir
)中创建一个 whiteout 文件。镜像层(lowerdir
)中文件的版本并不会被删除(因为 lowerdir
是只读的)。但是,whiteout 文件会阻止其在容器中可用。当在容器中删除目录时,会在容器层(upperdir
)中创建一个 opaque 目录。它的工作机制同 whiteout,并且有效地防止目录被访问,即使它仍然存在于镜像层(lowerdir
)。rename(2)
,否则会返回 EXDEV
error("cross-device link not permitted")。overlay2
和 overlay
驱动比 aufs
和 devicemapper
拥有更好的性能。在某些情况下,overlay2
的性能表现可能比 btrfs
还要好。不过要注意以下几点:overlay
和 overlay2
驱动高效利用内存以及高密度使用案例的优先选择如 PaaS。copy_up
比 AUFS 同样的操作要更快,因为 AUFS 比 OverlayFS 拥有更多的层级,如果在多个 AUFS 层级搜索可能会造成大的延迟。overlay2
也支持多层,但通过缓存减轻了性能损失。overlay
存储驱动会导致过多的 inode 损耗。特别是 Docker 主机上存在大量的镜像和容器时尤为明显。格式化文件系统增加可用的 inode 数量是唯一的解决方式。为了避免这个问题,因此建议尽可能的使用 overlay2
。fd1=open("foo", O_RDONLY)
和 fd2=open("foo", O_RDWR)
。在这个案例中,你的应用期望 fd1
和 fd2
引用同一个文件。但是,因为发生了 copy-up 操作导致第二次调用 open(2)
,文件描述符指向的是不同的文件。fd1
继续引用镜像层(lowerdir
)而 fd2
引用的文件在容器层(upperdir
)。解决方式是 touch
这些文件,引发 copy-up 操作发生。所有的后续 open(2)
操作无论是读写访问模式都引用容器层(upperdir
)的文件。yum
是已知受影响的,除非 yum-plugin-ovl
已经安装了。如果 yum-plugin-ovl
包在你的发行版中不可用如 RHEL/CentOS 6.8 或 7.2,你可能需要在运行 yum install
前执行 touch /var/lib/rpm/*
。yum-plugin-ovl
软件包实现了针对 yum
的 touch
变通方案。rename(2)
系统调用。你的应用需要检测它的失败以及返回 "copy and unlink" 策略。