增量docker图像保存<图像> | xz -zc – > images.tar.xz`

我们有一个docker-compose项目，其中包括各种服务，其中一些共享共同的基础图像。 在构build所有图像之后，构build作业的后期构build步骤之一是将docker image save <images> | xz -zc - >images.tar.xz docker image save <images> | xz -zc - >images.tar.xz创build所有图像的单个压缩存档 – 用于离线部署的后备策略（所以我们可以通过USB或CD介质而不是docker工具来传输这些图像-registry）。 未压缩的docker image save <images> tar-stream大小约为2GB。 在通过xzpipe道后，压缩的images.tar.xz只有大约500MB。

这个构build作业经常运行，大部分时间只有less数图像会发生变化。 不过，前面提到的docker … | xz … docker … | xz … pipeline将总是重新创buildimages.tar.xz ，这在整个构build工作中需要最多的时间。 我想优化。

有没有办法加快增量构build？

我想了解docker image save <imageN> | xz -zc - >imageN.tar.xz docker image save <imageN> | xz -zc - >imageN.tar.xz每个图像，所以我只能保存修改的图像，但这将导致大约两倍的所需存储，因为docker image save将包括重复的基本图像之间的个别调用。

我非常希望能够使用单个docker image save <images>调用，但只更新或重新压缩先前images.tar.xz的实际更改。 我知道，由于tar.xz是如何构造的，小的改变 – 特别是在stream的开始处 – 将需要重新创build整个文件。 然而，我很高兴看到另一个解决scheme，涉及合理地分裂焦油stream，使个别部分可以更新。

注意：除了最后一些meta / manifest文件外，tar-stream还包含一堆图层文件夹，每个文件夹都包含一个layer.tar和一些元文件，对应于所有已保存的（重复删除的）图层图像，例如：

$ xz -dc images.tar.xz | tar t 0166389787802d9a6c19a832fcfe976c30144d2430e798785110d8e8e562dab6/ 0166389787802d9a6c19a832fcfe976c30144d2430e798785110d8e8e562dab6/VERSION 0166389787802d9a6c19a832fcfe976c30144d2430e798785110d8e8e562dab6/json 0166389787802d9a6c19a832fcfe976c30144d2430e798785110d8e8e562dab6/layer.tar ...(~100x4)... fa498ee40da8c70be99b8f451813d386b45da891353d7184cdb8dd1b40efca03/ fa498ee40da8c70be99b8f451813d386b45da891353d7184cdb8dd1b40efca03/VERSION fa498ee40da8c70be99b8f451813d386b45da891353d7184cdb8dd1b40efca03/json fa498ee40da8c70be99b8f451813d386b45da891353d7184cdb8dd1b40efca03/layer.tar ffb2e673ba3e63b6b5922a482783b072759f0b83335a5ffab0b36dc804a24b93/ ffb2e673ba3e63b6b5922a482783b072759f0b83335a5ffab0b36dc804a24b93/VERSION ffb2e673ba3e63b6b5922a482783b072759f0b83335a5ffab0b36dc804a24b93/json ffb2e673ba3e63b6b5922a482783b072759f0b83335a5ffab0b36dc804a24b93/layer.tar manifest.json repositories

PS：在压缩过程中，我已经使用pxz而不是xz来利用所有的CPU核心，但是这仍然需要相当长的时间。