文件查找如何在Docker容器中工作

Question

根据Docker docs，每个Dockerfile指令都会创建一个图层，并且在创建基于旧图像的新图像时会保留所有图层。然后，当我创建自己的图像时，由于基本图像层的递归继承，我可能涉及数百个图层。

据我所知，容器中的文件查找以这种方式工作：

1. 进程想要访问文件a，查找从容器层开始（瘦w / r层）。
2. UnionFS检查此图层是否有记录（包含它或标记为已删除）。如果是，则分别返回或说不找到，结束查找。如果不是，请将任务传递给下面的图层。
3. 底层的查找结束。

如果是这样的话，考虑一个位于底层并且未被其他层更改的文件，/bin/sh可能需要遍历所有层到底部。虽然这些层可能非常轻，但查找仍然需要比常规层多100倍的时间，这是显而易见的。但根据我的经验，Docker非常快，几乎与本机操作系统相同。我哪里错了？

Answer 1

这完全归功于UnionFS和Union mounts！

直接来自维基百科：

  

它允许单独文件系统的文件和目录，称为   分支，透明覆盖，形成一个连贯的文件   系统

来自一个有趣的article：

  

在内核中，文件系统按其安装顺序堆叠   顺序，第一个安装的文件系统位于mount的底部   堆栈，最新的挂载位于堆栈的顶部。只有文件   并且可以看到安装堆栈顶部的目录。与工会   挂载，来自较低文件系统的目录条目与其合并   上层文件系统的目录条目，从而形成逻辑   所有已安装文件系统的组合。 a中具有相同名称的文件   较低的文件系统被屏蔽，因为较高的文件系统优先。

所以它没有经过层次＆＃34;在传统意义上（例如，一次一个），但它知道（在任何给定时间）哪个文件驻留在哪个磁盘上。

在文件系统层执行此操作也意味着软件不必担心文件所在的位置，它知道要求/bin/sh并且文件系统知道从哪里获取它。

可在此webinar找到更多信息。

所以回答你的问题：

  

我哪里错了？

您认为必须一次查看一个图层，而不必这样做。 （UnionFS太棒了！）

Answer 2

要添加到正确的先前答案，写时复制（CoW）和联合文件系统实现者希望具有接近本机的性能，因此，当然，已经调整了他们的实现和＆＃34; API＆＃34;获得最佳的查找/文件系统性能。

也就是说，了解Docker不能只运行一个＆＃39;类型的＆＃39; union / CoW文件系统，但有一小部分可用选项，默认值取决于安装它的Linux发行版。

AUFS和overlay（fs）是最常见的，但Docker还支持devicemapper（Red Hat在Fedora / RHEL / CentOS上提供和支持），btrfs和zfs。我有一个blog post比较和对比可能感兴趣的各种选项。