该文档没有详细说明该主题.它说:
最小化层数
在Docker 17.05之前,甚至更多,在Docker 1.10之前,最小化图像中的层数非常重要.以下改进减轻了这种需求:
在Docker 1.10及更高版本中,只有RUN,COPY和ADD指令可以创建图层.其他指令创建临时中间图像,不再直接增加构建的大小.
Docker 17.05及更高版本增加了对多阶段构建的支持,允许您仅将所需的工件复制到最终图像中.这允许您在中间构建阶段中包含工具和调试信息,而不会增加最终图像的大小.
看起来最新的Docker版本无法解决处理多个层的问题.他们宁愿努力减少最终图像中的数量.最重要的是,文档并没有说明为什么很多层都不好.
我知道42层的AUFS限制.对于广泛使用的图像来说保持较小的层数是有意义的,因为它有助于构建在其上的其他图像符合限制.但是,还有其他存储驱动程序和图像用于其他目的.
保持图像较小也是一个明显的原因 - 它们占用磁盘空间和网络带宽.但是,我不认为链接RUN语句并因此将多个层压缩为一个有助于一般.如果不同的RUN更新文件系统的不同部分,则一层和多层的大小应该大致相同.
另一方面,许多层允许更快地使用缓存和重建图像.它们也是平行拉动的.
我在一个拥有私有Docker注册表的小团队中工作.我们永远不会满足42层限制,主要关注性能和开发速度.
如果是这样,我应该最小化泊坞窗层的数量吗？
Python中的字符串是不可变的,并且支持缓冲区接口.因此,在使用切片或split()方法时,不返回新字符串,而是返回旧字符串的部分是有效的.但是,据我所知,每次都会构造新的字符串对象.为什么会这样？我看到的唯一原因是它可以使垃圾收集变得更加困难.
是的:在常规的语言中,内存开销是线性的,并不明显:复制速度很快,我相信,分配也是如此.但是在python中做太多事情只是说它不值得努力!
编辑:
似乎使用这种方式会使内存管理变得更加复杂.在这种情况下,只使用1/5的任意字符串,并且我们无法解除分配整个字符串,这是一个简单的例子.我们可以改进内存分配器,因此它可以部分地释放字符串,但它可能主要是反驳.如果内存使用非常重要,那么无论如何都可以使用缓冲区或内存视图模拟所有标准函数.是的,代码不会那么简洁,但我们必须放弃一些东西才能得到一些东西.