Container of the Week – debian:jessie-slim

This week we are going to look at a very simple container, but one that I personally did not know about up until a few days ago. It’s a standard base container, but one with an important property that many users of Docker and Kubernetes are concerned about.

A base container is the container image used in the FROM command of your Dockerfile. Base containers are usually a customised minimal install of a full-sized Linux distribution such as Debian, Ubuntu or CentOS. Read on to find out more about the debian:jessie-slim base container.

The debian:jessie-slim container does pretty much what it says on the tin. It’s a slimmed down version of the highly popular debian:jessie container. Pull it down by running the following command:

$ docker pull debian:jessie-slim

According to the docker images command, the debian:jessie-slim container clocks in at 88MB, compared to the full-fat debian:jessie container at 123MB. For reference, the ubuntu:xenial and centos:7 base containers are 130MB and 193MB respectively, where as the alpine base container is only 4MB, as mentioned in my post about the alpine base container.

We can poke around in the official images library git repository and figure out exactly how the jessie-slim container is made smaller. This is an important question, as if you are considering using this container as a base container for other images you should understand whether the slimming down process might cause trouble with your application later on.

If you look at the slim-excludes file from the docker-brew-debian git repo, you can see that the jessie-slim container is identical to the jessie container except that the following directories have been removed.

  • /usr/share/doc/*
  • /usr/share/groff/*
  • /usr/share/info/*
  • /usr/share/linda/*
  • /usr/share/lintian/*
  • /usr/share/locale/*
  • /usr/share/man/*

Simply removing these directories reduces the size of the image by 35MB!

It’s unlikely that the lack of these files will cause issues for most applications. Container images rarely require documentation to be available within the image, so I’m going to go ahead and recommend that you use debian:jessie-slim as your base container image when creating new containers.

In my experience quite a few users of Docker and Kubernetes are concerned about the overall size of the container image. If a container image is too bloated then it takes more time for it to be downloaded, started up, or otherwise manipulated during its lifecycle. There is also some concern about the size taken when there are hundreds to thousands of instances running. The copy-on-write sharing techniques used by the various Docker storage backends such as aufs and devicemapper should not cause this to be a big issue.

So why doesn’t everyone use use the Alpine base container?  After all its size is only 4MB. The base container size is traded off against features that other possible base container images have. For example the Debian, Ubuntu and CentOS base container images all contain a fully-featured version of glibc, the standard C library used in Linux. Using an alternate C library has its advantages, but glibc has decades of development behind it and is what just about every application is built against.

Another feature a base container that uses a convention distribution has is that the packaging system is also available. If your container requires other applications or libraries to be installed from the distribution’s software archive, then this can easily occur with a few “RUN apt-get install foo” or “RUN yum install bar” commands in the Dockerfile. Lack of access to a packaging system and the availability of software can be a big problem.

Finally some base container images, such as Alpine, are missing time zone and internationalisation support. It might be that your application does not need to operate in multiple time zones or to handle a daylight savings transition. It might also not need to present strings to the user in their chosen language. This might be fine but you should be aware whether these features are available in your base container image.

Choosing the right base image can save you time and effort later on as your application matures. Make sure to consider the development and debugging costs that will happen in the future if you choose the wrong base container image.