A (hopefully) complete guide on how to make Docker images even smaller

Over the weekend, our CI failed to merge changes because our CI Docker image got too big. While trying to fix that, I looked at existing guides on how to slim container images down. However, those felt really incomplete. Most of them did not explain how one debugs problems, or they just missed a lot of details. That is why I tried to write a new complete guide on how to slim down container images which contains all my findings, and with our CI image as a running example.

Since I had a pretty rough time over the weekend, I'd like to share that with you. I would appreciate your feedback, and if you know something that is missing, please let me know!

[https://symflower.com/en/company/blog/2022/complete-guide-on-shrinking-container-images/](https://symflower.com/en/company/blog/2022/complete-guide-on-shrinking-container-images/)

11 thoughts on “A (hopefully) complete guide on how to make Docker images even smaller”

  1. I always prefer to be explicit about which files or directories I am excluding from the build context, rather than excluding everything by default and then explicitly negating files that should be sent to the build context.

    Reply
  2. Nice guide! Very complete.

    I’d say your 3rd point is the most important and where you should focus your work to get the better results. Split into several images, no way you need everything all the time.

    Reply
  3. I undertook a similar quest not too long ago. I was able to reduce our python backend docker image from 600MB to 250MB.

    The biggest optimization was doing a multistage build.
    The last optimization was to skip installing all pip dependencies at build time, instead they are installed at runtime. This way our registry contains just an image ready to run the backend server.

    The only downside is that startup of newly deployed images takes some time to finish downloading (mostly from pypi), before running, but we attach docker volumes to them to speed up the process somewhat.

    Next plan of action is to simply mount the downloaded dependencies as a volume to the container. The volumes can be created separately from the images and will only need to be updated once in a while.

    Reply
  4. Great read. Honestly I would have lead with the obvious solution of splitting the image, limiting the added files and using a slimmer base image. In most cases this is enough and doesn’t warrant a deeper dive like you showed in the prior steps. Of course with the added disclaimer that it might complicate other aspects of the development.

    Reply

Leave a Comment