Tenemos un proyecto Docker Compose que incluye varios servicios, algunos de los cuales comparten imágenes base comunes. Después de compilar todas las imágenes, uno de los pasos posteriores a la compilación de nuestro trabajo de compilación es docker image save <images> | xz -zc - >images.tar.xz para crear un único archivo comprimido de todas las imágenes, que se usará en una estrategia alternativa de implementación fuera de línea (para que podamos transportar estas imágenes a través de medios USB o CD en lugar de un Docker registro).
La docker image save <images> tar-stream tiene un tamaño aproximado de 2 GB. Después de canalizarlo a través de xz , el comprimido images.tar.xz tiene solo unos 500 MB.
Este trabajo de compilación se ejecuta con mucha frecuencia y, en la mayoría de los casos, solo habrán cambiado unas pocas imágenes. Sin embargo, el mencionado docker … | xz … la canalización siempre recreará el images.tar.xz en su totalidad, lo que requiere la mayor parte del tiempo en el trabajo de compilación general. Me gustaría optimizar eso.
¿Hay alguna manera de acelerar las compilaciones incrementales?
Pensé en docker image save <imageN> | xz -zc - > imageN.tar.xz cada imagen individualmente, por lo que solo puedo guardar imágenes modificadas, pero esto dará como resultado aproximadamente el doble de almacenamiento requerido, porque docker image save incluirá imágenes base duplicadas entre llamadas individuales.
Me gustaría mucho poder usar una sola docker image save <images> , pero solo actualizar o volver a comprimir los cambios reales en un images.tar.xz anterior. Sé que, debido a cómo está estructurado tar.xz , los pequeños cambios, especialmente al comienzo de la transmisión, requerirán volver a crear todo el archivo. Sin embargo, me encantaría ver otra solución que implique dividir el flujo de alquitrán de manera razonable, de modo que las partes individuales puedan actualizarse.
Nota: Aparte de algunos archivos meta/manifiesto al final, el flujo tar contiene un montón de carpetas de capas , cada una de las cuales contiene una layer.tar y algunos archivos meta, correspondientes a las capas (desduplicadas) de todos los archivos guardados imágenes, por ejemplo:
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 PD: ya estoy usando pxz en lugar de xz para utilizar todos los núcleos de la CPU durante la compresión, pero aún lleva una cantidad considerable de tiempo.