Инкрементное `изображение докера save <images> | xz -zc -> images.tar.xz`
У нас есть проект создания docker, включающий различные сервисы, некоторые из которых имеют общие базовые образы. После создания всех изображений, один из этапов нашей работы по сборке - это docker image save <images> | xz -zc - >images.tar.xz создать единый сжатый архив всех образов - для использования в резервной стратегии автономного развертывания (чтобы мы могли переносить эти образы через USB- или CD-носитель, а не через реестр докеров). Несжатый docker image save <images> Размер tar-потока составляет около 2 ГБ. После прохождения через него xzСжатый images.tar.xz только около 500 МБ.
Это задание на сборку выполняется очень часто, и в большинстве случаев меняются только несколько изображений. Тем не менее, вышеупомянутое 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 структурирован, небольшие изменения - особенно в начале потока - потребуют воссоздания всего файла, тем не менее. Тем не менее, я бы с радостью увидел другое решение, которое включает разумное разделение потока смолы, чтобы отдельные части можно было обновлять.
Примечание. Помимо некоторых файлов meta / manifest в конце, tar-поток содержит несколько папок слоев, каждая из которых содержит 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 использовать все ядра процессора во время сжатия, но это все еще занимает значительное время.