incremental `docker image save <images> | xz -zc - >images.tar.xz` -
we have docker-compose project including various services, of share common base-images. after building images, 1 of our build job's post-build-steps docker image save <images> | xz -zc - >images.tar.xz
create single compressed archive of images – used in offline-deployment fallback-strategy (so can transport these images via usb- or cd-media rather docker-registry). uncompressed docker image save <images>
tar-stream 2gb in size. after piping through xz
, compressed images.tar.xz
500mb.
this build job run often, , of time few images have changed. however, aforementioned docker … | xz …
pipeline recreate images.tar.xz
in entirety, requires time in overall build job. i'd optimize that.
is there way speed incremental builds?
i thought docker image save <imagen> | xz -zc - >imagen.tar.xz
each image individually, can save modified images, result in twice required storage, because docker image save
include duplicate base images between individual calls.
i able use single docker image save <images>
invocation, update or re-compress actual changes in previous images.tar.xz
. know that, because of how tar.xz
structured, small changes – @ beginning of stream – require recreate whole file non-the-less. however, i'd gladly see solution involves splitting tar stream reasonably, such individual parts can updated.
note: aside meta/manifest files @ end, tar-stream contains bunch of layer folders, each of contains layer.tar
, meta files, corresponding (de-duplicated) layers of saved images, e.g.:
$ 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: i'm using pxz
instead of xz
utilize cpu cores during compression, still takes considerable amount of time.
Comments
Post a Comment