不会压扁/压扁docker镜像会对registrycaching产生不利影响吗?

假设你有一个docker图像,并将其压平或压扁以减小尺寸。 这对于运行时工件是有利的,所以它们可以消耗最less的资源用于存储和推/拉。

但是我想知道在压缩图像进行存储时,是否在压缩(生成单个压扁的图层)和在容器registry部分发生的图层重用之间进行权衡。

下面是一个例子:假设你有一个图像,有几层 – 一个普通的老的Docker镜像 – 大小可能是500MB。 您可以使用压扁或压扁来将其压缩到一个大小为250 MB的单个图层中。

现在让我们假设你需要改变你的图像,创build一个版本2.版本2是在容器的最后一层的一个很小的改变,也许在CMD指令之前改变一个设置文件的名字。

在你将一堆扩展图层推送到registry的情况下,当你推送这个新的图像时,只有不同的最后一层需要被存储在registry的caching中,这可能意味着总的大小(对于初始图像和你的新版本2图像一起)将会是,比如说550 MB或者什么,取决于最后一层发生了变化。

与此同时,在平铺的情况下,您的新版本2图像只是一些全新的单层图像,与原始容器没有共同的历史logging。 (也许你的本地 Docker实例可以看到与展平相关的图层历史logging,但是registry没有这个)。

在这种情况下,您必须在registry中存储大约500 MB的内容:第一个和第二个版本的图像每个需要250 MB。

显然,只要我们第三次这样做,平坦图像的总空间实际上大于对扩展图像的增量变化的空间。

有什么我错过了这个工作的方式吗? 它build议你只想在将容器运送到最终目的地之前执行压扁操作,但在存储在registry中时通常希望进行压扁操作。

可能会出现这样的情况:基础图像太大,扁平化会导致尺寸缩小,这是值得的,但是我想了解一般情况,而我找不到讨论图层扁平化的特定方面的文档。

压缩图像确实会消除使用caching图像图层的function,并增加了当您拥有多个图像副本时使用的磁盘空间。 出于这个原因,我还没有看到它与我的客户使用。 执行此操作的首选方法是configurationDockerfile以最大限度地重用图像以前版本的caching。

如果你看到一个壁球的图像大小减less了50%,通常有更好的方法来构造Dockerfile以避免图层膨胀。 我知道压缩的一个普遍情况是,当你需要从COPY上下文中拷贝一个大文件,然后在未来的RUN命令中修改或者以后删除这个文件。 没有办法将COPYRUN命令链接在一起。 您可以将COPY转换为RUN curl http://local-artifact-repo/... 或者在多阶段构build中,现在可以在一个阶段执行所有的COPY和其他RUN命令,然后将结果COPY到最终的图像中。 最后一个COPY会导致一个全新的层,即使你只做了一个小小的改动,但是在RUN链接命令也是如此。