Container images are usually stored and transferred as compressed tarballs (tar+gzip or tar+zstd).
It improves the storage efficiency on the registry side and also decreases the pull/push time.
However, sometimes uncompressing the images on the client can become the bottleneck. For instance, with large ML/LLM images transferred over a fast internal network, the local disk I/O during the decompression can become the actual limiting factor ( 1, 2 ).
In this challenge, you will practice building and publishing an uncompressed container image.
You can find the application you need to package at ~/app.
It already comes with a Dockerfile, so you won't have to write one from scratch.
Using this Dockerfile,
build a container image and publish it to the remote repository registry.iximiuz.com/app using the v1.0.0 tag.
The pushed image should not be compressed.
Hint 1 💡
The standard docker build and docker push commands may not be enough to produce an uncompressed image.
You need to dive into the more powerful docker buildx alternative,
in particular its various exporter capabilities.
Hint 2 💡
The local Docker daemon typically stores images uncompressed (because it optimizes for the container startup time and not the most efficient storage of images). When you build the challenge's image with Docker, make sure it doesn't go to the local Docker daemon - export it straight to the remote repository. This way, you'll keep the highest level of control over the image format.
Check out the --output option of the docker buildx build command,
in particular the type and push parameters.
Hint 3 💡
The --output parameter you're looking for is called compression.
The docs mention only the gzip and zstd variants,
but there is a third option - uncompressed.
Hint 4 💡
If you've already built an image using a certain compression algorithm,
you may need to force the re-compression by adding force-compression=true to the --output flag.
Otherwise, Docker may silently ignore the compression algorithm you specified,
especially if some cached layers from the previous build are present.
Hint 5 💡
Another sneaky docker buildx quirk - if you haven't created a builder instance explicitly,
a whole bunch of output options may be silently ignored.
If a seemingly right output combination keeps producing a compressed image,
make sure to create (and activate) a builder instance explicitly using the following command:
docker buildx create --driver docker-container --use
Level up your Server Side game — Join 9,500 engineers who receive insightful learning materials straight to their inbox