我应该尽量减lessdocker层的数量？
文档没有详细阐述这个话题。 它说：
最小化层数
在Docker 17.05之前，甚至在Docker 1.10之前，重要的是尽量减less图像中的图层数量。 以下改进缓解了这种需求：
在Docker 1.10及更高版本中，只有RUN，COPY和ADD指令创build图层。 其他说明会创build临时中间图像，不再直接增加构build的大小。
Docker 17.05及更高版本增加了对多阶段构build的支持，允许您只将需要的构件复制到最终的图像中。 这允许您在中间构build阶段包含工具和debugging信息，而不增加最终图像的大小。
它看起来像最新的Docker版本不能解决处理许多层的问题。 他们宁愿努力减less最终形象的数量。 最重要的是，文档没有说明为什么很多层是坏的。
我知道42层的AUFS限制 。 保留广泛使用的图像的层数是有意义的，因为这有助于在其上构build其他图像以适应限制。 但是，还有其他的存储驱动程序和图像用于其他目的。
保留图像很小是很好的一个显而易见的原因 – 占用磁盘空间和networking带宽。 但是，我不认为链接RUN语句 ，从而将许多层压缩成一个整体。 如果不同的RUN更新文件系统的不同部分，则一个层和多个层的大小应该大致相同。
另一方面，许多层允许使用caching并更快地重build图像。 他们也被平行拉。
我在一个拥有私人Dockerregistry的小团队中工作。 我们永远不会遇到42层限制，关心性能和开发速度。
如果是这样，我应该尽量减lessdocker层的数量？
我在一个拥有私人Dockerregistry的小团队中工作。 我们永远不会遇到42层限制，关心性能和开发速度。
如果是这样，我应该尽量减lessdocker层的数量？
在你的情况下，不。
需要最小化的是构build时间，这意味着：
- 确保最常用的步骤和最长的步骤，然后将caching，允许你摆动Dockerfile的最后一行（最具体的命令），同时有一个快速的重build时间。
- 确保最长的RUN命令先到达并在自己的层（再次被caching），而不是与其他RUN命令链接：如果其中一个失败，长命令将不得不重新执行。 如果这个长命令是独立的（Dockerfile行）/图层，它将被caching。
这就是说， 你提到的文档来自docker/docker.github.io ，正是PR 4992和PR 4854 ，在docker/docker.github.io docker build LABEL部分之后 。
所以这一节就是关于LABEL一个类似的说法，只是强调创build图层的命令。
再次，在你的情况下，这并不重要。
我只是想看看两个图像有什么区别，一个是用多个RUN构build的，另一个是用一个RUN级联命令构build的。
在第一种情况下，图像是做平凡的操作（创build和删除文件）。
“单层”图像的内容：
FROM busybox RUN echo This is the 1 > 1 \ && rm -f 1 \ && echo This is the 2 > 2 \ && rm -f 2 \ # ... for about 70 commands
多层图像的内容：
FROM busybox RUN echo This is the 1 > 1 RUN rm -f 1 RUN echo This is the 2 > 2 RUN rm -f 2 # ... for about 70 layers
构build时间是非常不同的（倍数：0分34,973秒，单数：0分0.568秒）。 集装箱启动时间也不同，但不太明显（倍数：0m0,435s，单数：0m0,378s）。 我运行了不同的图像时间，但时代不会改变那么多。
关于空间，我已经看到多层情况下的最坏情况的目的，如预期的那样，多层图像比单层更大。
在另一个testing中，我将只添加内容的图层连接起来。 构build时间与以前的情况没有变化，但是运行时间情况显示了一些不同的情况：多层图像比单层图像启动更快。 关于空间，相同的结果。
我不认为这certificate了任何东西，但是我乐于这样做：P
减less层数本身就不是一个目标。 相反，您需要关注的是减less构build时间，并减less图像大小。
通过保持在Dockerfile顶部很less更改的通用图层或基本图像，可以缩短构build时间。 这允许图层在以后的版本中被caching和重用。 这不是关于减less图层数量的问题，更多的是关于如何对图层进行sorting。
减less映像大小有助于减lessregistry服务器上的磁盘使用情况，当CI系统上的每个版本都存储映像时，会对磁盘造成很大影响。 这也减less了传输图像的networking时间。 当你有一个图层下载一个大的临时文件，并在另一个图层中删除它时，这个图层的结果就是将文件留在第一层，通过networking发送并存储在磁盘上，即使它在里面不可见你的容器。 更改文件的权限还会导致文件被复制到具有新权限的当前图层，使该文件的磁盘空间和networking带宽增加一倍。
在上述情况下减less图像大小的标准解决scheme是链接RUN命令，以便临时文件不会存储到图像层。 这具有减less图像层数量的副作用。
最后一个问题是过度caching。 这在Debian映像中的apt-get update和apt-get install ...命令中很常见。 如果不将这些命令链接在一起，那么对apt-get install命令的更新将重新使用来自先前的apt-get update命令的可能过时的caching，并且在几个月后将无法find所需的包时会失败。 因此，即使增加构build时间，也应该链接这些命令，因为另一个选项是将来会出现构build失败。
因此，更多的是减less图层的副作用，而不是为了减less图层而减less图层。