Alpine Linux is often recommended as a base image for Docker. You are told that using Alpine will make your builds smaller and the build process faster.
But if you use Alpine Linux for Python applications, it:
- Makes your builds significantly slower
- Makes your images larger
- Wastes your time
- And can ultimately lead to runtime errors
Letās explore why Alpine is recommended, but why you still might not want to use it with Python.
Why do people recommend Alpine?
Letās assume we need gcc as part of our image and we want to compare Alpine Linux vs Ubuntu 18.04, in terms of build speed and final image size.
First, letās download the two images and compare their sizes:
$ 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. Now, letās try to install gcc, starting 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 goes 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
Build it, then check the time and size of the build:
$ 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 themselves smaller: 15 seconds instead of 30, and an image size of 105MB versus 150MB. Thatās quite good!
But if we switch to building a Python application, things donāt look as bright.
Python image
Python applications often use pandas and matplotlib. Therefore, one option is to take the official Debian-based image, using the following Dockerfile:
FROM python:3.8-slim
RUN pip install --no-cache-dir matplotlib pandas
Build 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 of size 363MB.
Will it be better with Alpine? Let's give it a 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 build based on Debian, you'll see it downloads matplotlib-3.1.2-cp38-cp38-manylinux1_x86_64.whl.
This is the binary for wheel. Alpine downloads the source `matplotlib-3.1.2.tar.gz`, as it does not support standard .
Why? Most Linux distributions use the GNU version (glibc) of the standard C library, which is required by every program written in C, including Python. But Alpine uses `musl`, and since those binaries are intended for `glibc`, they simply won't work.
Therefore, if you are using Alpine, you need to compile all the C code in every Python package.
Oh, and you'll have to find the list of all such dependencies that need to be compiled yourself.
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 time takesā¦
ā¦ 25 minutes 57 seconds! And the image size is 851MB.
Alpine-based images take significantly longer to build, are larger by themselves, and you still need to find all the dependencies. You can reduce the build size using but that means even more work is required.
That's not all!
Alpine may cause unexpected runtime bugs.
- In theory, musl is compatible with glibc, but in practice, the differences can lead to many issues, and if they arise, they are likely to be unpleasant. Here are some problems that may occur:
- Alpine has a smaller thread stack size by default, which can lead to
- Some users have found that due to how musl allocates memory (which differs from glibc).
- One user
These bugs have likely been fixed by now, but who knows how many more there might be.
Do not use Alpine images for Python.
If you don't want to deal with large and lengthy builds, searching for dependencies, and potential bugs ā don't use Alpine Linux as a base image. .
Source: habr.com
