我们有一个包含各种服务的docker-compose项目，其中一些服务共享公共基础图像。在构建完所有图像之后，我们的构建工作之一的构建后步骤是docker image save <images> | xz -zc - >images.tar.xz创建所有图像的单个压缩存档 - 用于离线部署后备策略（所以我们可以通过USB或CD媒体而不是docker-registry传输这些图像。未压缩的docker image save <images> tar-stream大小约为2GB。通过xz管道后，压缩的images.tar.xz只有大约500MB。
此构建作业经常运行，并且大多数情况下只有少量图像会发生变化。但是，上述docker … | xz …管道将始终完整地重新创建images.tar.xz，这需要整个构建作业中的大部分时间。我想优化它。
有没有办法加快增量构建？
我单独考虑了docker image save <imageN> | xz -zc - >imageN.tar.xz每个图像，因此我只能保存已修改的图像，但这将导致所需存储量的两倍，因为docker image save将在各个调用之间包含重复的基本图像。
我非常希望能够使用单个docker image save <images>调用，但只更新或重新压缩先前images.tar.xz中的实际更改。我知道，由于tar.xz的结构如何，小的变化 - 特别是在流的开头 - 将需要重建整个文件。但是，我很高兴看到另一个解决方案，即合理地拆分tar流，以便更新各个部分。
注意：除了最后的一些元/清单文件之外，tar-stream包含一堆 layer 文件夹，每个文件夹包含一个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内核，但仍需要相当长的时间。