Alpine builds Docker builds for Python 50x slower and images 2x heavier

Alpine builds Docker builds for Python 50x slower and images 2x heavier

Alpine Linux is often recommended as the base image for Docker. You are being told that using Alpine will make your builds smaller and the build process faster.

But if you are using Alpine Linux for Python applications, then it:

  • Makes your builds much slower
  • Makes your images bigger
  • Wasting your time
  • And as a result, it can cause runtime errors


Let's take a look at why Alpine is recommended, but why you shouldn't use it with Python anyway.

Why do people recommend Alpine?

Let's say we need gcc as part of our image and want to compare Alpine Linux vs Ubuntu 18.04 in terms of build speed and final image size.

First, let's download two images and compare their size:

$ docker pull --quiet ubuntu:18.04
docker.io/library/ubuntu:18.04
$ docker pull --quiet alpine
docker.io/library/alpine:latest
$ docker image ls ubuntu:18.04
REPOSITORY          TAG        IMAGE ID         SIZE
ubuntu              18.04      ccc6e87d482b     64.2MB
$ docker image ls alpine
REPOSITORY          TAG        IMAGE ID         SIZE
alpine              latest     e7d92cdc71fe     5.59MB

As you can see, the base image for Alpine is much smaller. Let's now try to install gcc and start with Ubuntu:

FROM ubuntu:18.04
RUN apt-get update && 
    apt-get install --no-install-recommends -y gcc && 
    apt-get clean && rm -rf /var/lib/apt/lists/*

Writing the perfect Dockerfile is beyond the scope of this article.

Let's measure the build speed:

$ time docker build -t ubuntu-gcc -f Dockerfile.ubuntu --quiet .
sha256:b6a3ee33acb83148cd273b0098f4c7eed01a82f47eeb8f5bec775c26d4fe4aae

real    0m29.251s
user    0m0.032s
sys     0m0.026s
$ docker image ls ubuntu-gcc
REPOSITORY   TAG      IMAGE ID      CREATED         SIZE
ubuntu-gcc   latest   b6a3ee33acb8  9 seconds ago   150MB

We repeat the same for Alpine (Dockerfile):

FROM alpine
RUN apk add --update gcc

We collect, look at the time and size of the assembly:

$ time docker build -t alpine-gcc -f Dockerfile.alpine --quiet .
sha256:efd626923c1478ccde67db28911ef90799710e5b8125cf4ebb2b2ca200ae1ac3

real    0m15.461s
user    0m0.026s
sys     0m0.024s
$ docker image ls alpine-gcc
REPOSITORY   TAG      IMAGE ID       CREATED         SIZE
alpine-gcc   latest   efd626923c14   7 seconds ago   105MB

As promised, Alpine-based images build faster and are smaller on their own: 15 seconds instead of 30 and an image size of 105MB versus 150MB. It's pretty good!

But if we switch to building a Python application, then things are not so rosy.

Python image

Python applications often use pandas and matplotlib. Therefore, one option is to grab the official Debian-based image using the following Dockerfile:

FROM python:3.8-slim
RUN pip install --no-cache-dir matplotlib pandas

Collecting it:

$ docker build -f Dockerfile.slim -t python-matpan.
Sending build context to Docker daemon  3.072kB
Step 1/2 : FROM python:3.8-slim
 ---> 036ea1506a85
Step 2/2 : RUN pip install --no-cache-dir matplotlib pandas
 ---> Running in 13739b2a0917
Collecting matplotlib
  Downloading matplotlib-3.1.2-cp38-cp38-manylinux1_x86_64.whl (13.1 MB)
Collecting pandas
  Downloading pandas-0.25.3-cp38-cp38-manylinux1_x86_64.whl (10.4 MB)
...
Successfully built b98b5dc06690
Successfully tagged python-matpan:latest

real    0m30.297s
user    0m0.043s
sys     0m0.020s

We get an image with a size of 363MB.
Can we do better with Alpine? Let's try:

FROM python:3.8-alpine
RUN pip install --no-cache-dir matplotlib pandas

$ docker build -t python-matpan-alpine -f Dockerfile.alpine .                                 
Sending build context to Docker daemon  3.072kB                                               
Step 1/2 : FROM python:3.8-alpine                                                             
 ---> a0ee0c90a0db                                                                            
Step 2/2 : RUN pip install --no-cache-dir matplotlib pandas                                                  
 ---> Running in 6740adad3729                                                                 
Collecting matplotlib                                                                         
  Downloading matplotlib-3.1.2.tar.gz (40.9 MB)                                               
    ERROR: Command errored out with exit status 1:                                            
     command: /usr/local/bin/python -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/
tmp/pip-install-a3olrixa/matplotlib/setup.py'"'"'; __file__='"'"'/tmp/pip-install-a3olrixa/matplotlib/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'rn'"'"', '"'"'n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info --egg-base /tmp/pip-install-a3olrixa/matplotlib/pip-egg-info                              

...
ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.
The command '/bin/sh -c pip install matplotlib pandas' returned a non-zero code: 1

What's happening?

Alpine does not support wheels

If you look at the Debian-based build, you will see that it downloads matplotlib-3.1.2-cp38-cp38-manylinux1_x86_64.whl.

This is a binary for wheel. Alpine downloads the `matplotlib-3.1.2.tar sources.gz` as it does not support the standard wheels.

Why? Most Linux distributions use the GNU version (glibc) of the C standard library, which is in fact required by every program written in C, including Python. But Alpine uses `musl`, and since those binaries are for `glibc`, they are simply not an option.

Therefore, if you are using Alpine, you need to compile all code written in C in every Python package.

Oh yes, you will have to look for a list of all such dependencies that need to be compiled.
In this case, we get this:

FROM python:3.8-alpine
RUN apk --update add gcc build-base freetype-dev libpng-dev openblas-dev
RUN pip install --no-cache-dir matplotlib pandas

And the build takes time ...

… 25 minutes 57 seconds! And the size of the image is 851MB.

Alpine-based images take much longer to build, they are larger in size, and you still have to look for all the dependencies. You can of course reduce the build size using multi-stage builds but that means more work to be done.

That's not all!

Alpine can cause unexpected runtime bugs

  • In theory musl is compatible with glibc, but in practice the differences can cause many problems. And if they are, then they are probably unpleasant. Here are some problems that may arise:
  • Alpine has a smaller thread stack size by default, which can result in errors in Python
  • Some users have found that Python applications run slower because of how musl allocates memory (different from glibc).
  • One of the users found an error while formatting the date

Surely these errors have already been fixed, but who knows how many more.

Don't use Alpine images for Python

If you don't want to deal with large and lengthy builds, looking for dependencies and potential bugs, don't use Alpine Linux as your base image. Choosing a good base image.

Source: habr.com

Add a comment