A Small Tip to Reduce Your Docker Images Size by Almost Half | by Christian Toscano | May, 2022

Optimize your Docker pictures

At present I need to clarify a small tip I just lately came upon to scale back the Docker pictures measurement, in my case I used to be in a position to scale back the dimensions by half!

Let’s assume that you’re working with a language like Ruby or Python, even when these languages should not compiled they typically want some system libraries to work correctly, specifically, if you’re working with databases (MySQL, SQLite, Postgres) it’s essential compile the gem or the library for the precise structure of your machine.

In my case, I’m working with Ruby and I’m making an attempt to put in the SQLite gem that, sadly, requires the build-base system library.

Right here is the venture I’m engaged on: Faenz Analytics

So I believed to put in it, compile the SQLite gem and uninstall all the things I don’t want anymore, right here is my Dockerfile:

FROM ruby:3.0.4-alpine3.15
WORKDIR /faenz-analytics
RUN apk replace &&
apk add make &&
apk add build-base && # this takes 200Mb of area!!
apk add sqlite-dev

# ...some directions

RUN bundle set up # putting in Ruby gems
RUN apk del build-base

# ...another directions

Simple, proper? We put in build-base, compiled, and put in the gems and eliminated build-base to scale back the picture measurement.

The issue is that this doesn’t work! The picture measurement is identical as if we didn’t take away build-base. Let’s uncover why.

We wrote three RUN directions, every one generates a layer and these layers are put collectively by Docker to create the ultimate picture:

  1. the primary RUN installs the system libraries
  2. the second RUN set up the gems/libraries by Ruby or no matter language you’re utilizing
  3. the third RUN removes the system libraries

since we put in the system libraries in one of many layer they’ll take some area and can improve the picture measurement, there’s no manner we are able to scale back the picture measurement with the subsequent layers.

It’s like a sum with no adverse numbers. The scale can solely improve or keep the identical from one layer to a different.

What? Don’t hand over, we acquired this

Right here is the answer: put these operations in the identical layer!

FROM ruby:3.0.4-alpine3.15
WORKDIR /faenz-analytics
RUN apk replace &&
apk add make &&
apk add sqlite-dev

# ...some directions

RUN apk add build-base &&
bundle set up &&
apk del build-base

# ...another directions

Grouping the operations in only one RUN instruction avoids Docker to waste area to retailer the build-base in a layer. The layer is generated on the finish of the instruction so we’re going to set up, use the build-base and promptly take away it in order that the layer is not going to include it in any respect.

With this little tip, my picture measurement went from 400MB to 170MB, lower than half!

If you wish to exaggerate with the micro-optimizations, you possibly can apply the identical answer to apk replace (or apt-get replace for Debian/ubuntu pictures) by deleting the cache created by this command:

RUN apk replace && 
add build-base &&
# set up different dependencies right here...
bundle set up &&
apk del build-base &&
rm -rf /var/cache/apk &&
rm -rf tmp/cache

As somebody has already identified, we are able to additionally repair this drawback with a multi-stage construct: putting in this dependency in an intermediate construct after which transferring the gems into the ultimate picture construct. I feel this strategy is absolutely more durable for this particular drawback as a result of you must monitor many information and transfer them to a different construct.

Certainly I’ve been utilizing the multi-stage construct in the exact same venture, I beforehand linked, to construct the frontend property and transfer them to the ultimate picture construct.

I’m not a Docker knowledgeable, so, if you recognize a greater answer or need to share related tricks to scale back the picture measurement please go away a remark, I’m all ears

More Posts