Alpine compile les builds Docker pour Python 50 fois plus lentement et les images sont 2 fois plus lourdes

Alpine compile les builds Docker pour Python 50 fois plus lentement et les images sont 2 fois plus lourdes

Alpine Linux est souvent recommandé comme image de base pour Docker. On vous dit que l’utilisation d’Alpine réduira la taille de vos builds et accélérera votre processus de build.

Mais si vous utilisez Alpine Linux pour les applications Python, alors :

  • Rend vos builds beaucoup plus lents
  • Agrandit vos images
  • Perdre ton temps
  • Et au final, cela peut provoquer des erreurs d'exécution


Voyons pourquoi Alpine est recommandé, mais pourquoi vous ne devriez toujours pas l'utiliser avec Python.

Pourquoi les gens recommandent-ils Alpine ?

Supposons que nous ayons besoin de gcc dans notre image et que nous souhaitions comparer Alpine Linux à Ubuntu 18.04 en termes de vitesse de construction et de taille d'image finale.

Tout d'abord, téléchargeons deux images et comparons leurs tailles :

$ 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

Comme vous pouvez le constater, l’image de base d’Alpine est beaucoup plus petite. Essayons maintenant d'installer gcc et de démarrer avec 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/*

Écrire le Dockerfile parfait dépasse le cadre de cet article.

Mesurons la vitesse d'assemblage :

$ 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

On répète la même chose pour Alpine (Dockerfile) :

FROM alpine
RUN apk add --update gcc

On s'assemble, on regarde l'heure et la taille de l'assemblage :

$ 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

Comme promis, les images basées sur Alpine sont collectées plus rapidement et sont plus petites : 15 secondes au lieu de 30 et la taille de l'image est de 105 Mo contre 150 Mo. C'est plutôt bon!

Mais si nous passons à la création d'une application Python, alors tout n'est pas si rose.

Image Python

Les applications Python utilisent souvent pandas et matplotlib. Par conséquent, une option consiste à prendre l’image officielle basée sur Debian en utilisant ce Dockerfile :

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

Récupérons-le :

$ 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

Nous obtenons une image de 363 Mo.
Ferons-nous mieux avec Alpine ? Essayons:

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

Qu'est-ce qui se passe?

Alpine ne prend pas en charge les roues

Si vous regardez la version, basée sur Debian, vous verrez qu'elle télécharge matplotlib-3.1.2-cp38-cp38-manylinux1_x86_64.tout.

C'est un binaire pour wheel. Alpine télécharge les sources `matplotlib-3.1.2.tar.gz` puisqu'il ne prend pas en charge la norme Les roues molles.

Pourquoi? La plupart des distributions Linux utilisent la version GNU (glibc) de la bibliothèque standard C, qui est en fait requise par tout programme écrit en C, y compris Python. Mais Alpine utilise « musl », et comme ces binaires sont conçus pour « glibc », ils ne sont tout simplement pas une option.

Par conséquent, si vous utilisez Alpine, vous devez compiler tout le code écrit en C dans chaque package Python.

Oh, oui, vous devrez rechercher la liste de toutes ces dépendances qui doivent être compilées vous-même.
Dans ce cas on obtient ceci :

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

Et le temps de construction prend...

... 25 minutes 57 secondes ! Et la taille de l'image est de 851 Mo.

Les images basées sur Alpine prennent beaucoup plus de temps à créer, elles sont plus grandes et vous devez toujours rechercher toutes les dépendances. Vous pouvez bien sûr réduire la taille de l'assemblage en utilisant constructions en plusieurs étapes mais cela signifie qu’il reste encore du travail à faire.

Ce n'est pas tout!

Alpine peut provoquer des bugs inattendus lors de l'exécution

  • En théorie, musl est compatible avec la glibc, mais en pratique les différences peuvent poser de nombreux problèmes. Et s’ils le sont, ils seront probablement désagréables. Voici quelques problèmes qui peuvent survenir :
  • Alpine a une taille de pile de threads plus petite par défaut, ce qui peut conduire à erreurs en Python
  • Certains utilisateurs ont constaté que Les applications Python sont plus lentes à cause de la façon dont musl alloue la mémoire (différente de la glibc).
  • Un des utilisateurs trouvé une erreur lors du formatage de la date

Ces erreurs ont sûrement déjà été corrigées, mais qui sait combien il y en aura d’autres.

N'utilisez pas d'images Alpine pour Python

Si vous ne voulez pas vous embêter avec des builds volumineux et longs, recherchant des dépendances et des erreurs potentielles, n'utilisez pas Alpine Linux comme image de base. Choisir une bonne image de base.

Source: habr.com

Ajouter un commentaire