Docker 中最大层数限制的原因是什么？

Question

在不同的地方我发现了一个docker镜像最多只能包含X层的信息。这似乎是所使用的存储驱动程序的限制。

有人能告诉我为什么存在这个限制吗？或者有人有一些文档解释这一点吗？

Answer 1

我开始怀疑不存在这样的硬性限制。

创建以下Python脚本，并将其命名为“makeDockerfile.py”

with open("Dockerfile", "w") as file:
    file.write("from alpine:3.8\n")
    for i in range(0, 201):
        file.write("run echo {i}\n".format(i=i))

然后运行

python makeDockerfile.py && docker build --tag manylayer . && docker run -it manylayer /bin/sh

您将看到您正在运行一个超过 200 层的工作容器。

（注意，这是在 Linux 上使用 Linux 容器进行测试的）

请注意，这并不意味着必须支持这么多层，只是在某些情况下它们是可能的。

事实上，我见过容器在层数远少于 42 的情况下失败，并且删除任意层似乎可以修复它。 （参见https://github.com/docker/for-win/issues/676#issuecomment-462991673）

编辑：

Docker 的维护者

thaJeztah

对此有这样的说法：

aufs 上的“42 层限制”是在旧版本的 aufs 上，但不应再是这种情况。

但是，127层的限制仍然存在。这是由于 Linux 的限制，所使用的系统调用不能接受超过 X 个参数。

虽然这个限制可以在现代内核中提高，但它不是默认值，所以如果我们超出这个最大值，在一台机器上构建的图像可能无法在另一台机器上使用。

（参见 https://github.com/docker/docker.github.io/issues/8230 ）

Answer 2

来自Docker BP文档：

尽量减少层数

您需要在

Dockerfile

的可读性（以及长期可维护性）和最小化其使用的层数之间找到平衡。对您使用的层数保持策略和谨慎。

他们还提供了如何避免太多层的建议：

这样您就可以在提取后删除不再需要的文件，并且无需在图像中添加另一个图层

[..]

最后，为了减少层次和复杂性，避免频繁地来回切换 USER。

---

TL;DR： 最小化层数的好处可以比作最小化小文件数量但减少大文件数量的好处。 A

docker pull

也更快（尝试下载 2048 个 1kB 的文件或 1 个 2MB 的文件）。更少的层数会降低图像的复杂性，从而降低可维护性。

至于

42

限制。嗯...我想他们必须想出一个数字，然后他们选择了这个特定的数字;)

Answer 3

这似乎主要是由 AUFS (

sfjro/aufs4-linux

) 强加的。
请参阅PR 50“禁止核心层数超过 42 层”

嘿，出于好奇，这背后的详细原理是什么？
人们一直在询问如何绕过 42 层限制，我们总是告诉他们“等待设备映射器！”那么...我们现在应该告诉他们什么？

我们目前还不能允许超过 42 层。 Devicemapper确实支持它，但是，如果你将50层图像推送到注册表，大多数人将无法使用它。一旦我们支持超过 42 层的 AUFS，我们就会启用此功能。

PR 66 应该取消该限制

此帖子报道：

42个限制来自aufs代码本身。
我的猜测是，这是因为堆栈深度：如果您将这些内核数据结构堆栈得太深，则可能会在某处触发溢出。硬编码限制可能是避免这种情况的实用方法。

Answer 4

Docker 镜像层数（包括所有嵌套镜像）的当前限制为 128 （不是 42，这在提出问题时可能是有效的），这是由于当前默认/首选存储的限制造成的驱动程序

overlay2

，如 Docker docs 中所述：

overlay2 驱动程序本身支持最多 128 个较低的 OverlayFS 层。此功能为与层相关的 Docker 命令（例如 docker build 和 docker commit）提供了更好的性能，并在支持文件系统上消耗更少的 inode。