Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.

When the Docker revolution started, one argument among many in favor of using containers instead of virtual machines was their size. Container images were supposed to be small.

However, several anti-patterns quickly emerged in the early days of Docker. First, most people wanted to treat containers just like VMs, hence they wanted an SSH server in them, they wanted to run multiple processes in them and they wanted their regular Linux distributions.

This quickly ballooned the size of Docker images that could be pulled from the Docker Hub. Official Ubuntu and CentOS images used to be above 600 MB. Once dependencies and application code got added, it was not rare to see several GB Docker images around.

Alpine Linux indeed allows you to create very small Docker images. It is based on busybox and muslc libc. It is rooted in embedded Linux. While very useful for testing and development, I believe that Alpine is challenging in an enterprise setting used to CentOS and Debian, where package provenance and patching is critical and where code may break unexpectedly with muslc.

But if we leave those concerns aside, is it really that small?

Comparing Official Images

If you pull the latest official images of well-known distribution you get the following sizes:

`centos:7` = 191 MB

`debian:jessie` = 194 MB

`debian:jessie-slim` = 80 MB

`ubuntu:16.04` = 129 MB

`alpine:3.4` = 4.8 MB

The first reaction is that Alpine is super small. The second reaction is that the CentOS and Debian community have reacted very well from the early days and shrank their images. The third reaction is: What is actually in those images?

"But wait," you say. "If we just compare image sizes, aren't we comparing apples and oranges?"

I will leave chasing the source of the Dockerfile(s) that makes those base images for another post. This is another rabbit hole that really scared me. But I am a Python guy, so let's see how to run Python with those images.

But it is not in the Debian or Ubuntu or Alpine images. If we look at the official Python images from the Docker Hub (which is a recommended best practice), we see that they are based on Debian (via `FROM buildpack-deps`). Let's pull a few and check their sizes:

`python:2.7` = 676 MB

`python:2.7-slim` = 181 MB

`python:2.7-alpine` = 72 MB

And there, big surprise, the official image is huge. The Alpine jumps to 72 MB compared to 4.5 MB when empty. And the `slim` image is at 181 MB — really close to the 191 MB of straight up `centos:7`.

Caveat: I did look a bit deeper into the `buildpack`images. It is interesting, as the `python:2.7-slim` is actually not based on the official `debian:jessie-slim`. If you were to use that official Debian image, you would get a 131 MB Python image, only 2x up from Alpine.

Using Minideb

Now for the last step of this post.

Let's say that you are not happy with a 191 MB official CentOS image or a 131 MB Debian-based image, solely because they are 2x or 3x bigger than the Alpine-based Python image (muslc and APK packages aside). Could we shrink a Python image?

That's where minideb, from the folks at Bitnami, comes into play. It is a minimalist, Debian-based Docker image built using debootstrap.

It sits at 50 MB, giving you standard glibc and access to standard Debian packages. It also has a convenience script to install packages and clean the cache, remove pages, etc., in order to keep images small.