Alpine kompiliert Docker-Builds für Python 50-mal langsamer und Images sind 2-mal schwerer

Alpine kompiliert Docker-Builds für Python 50-mal langsamer und Images sind 2-mal schwerer

Als Basis-Image für Docker wird oft Alpine Linux empfohlen. Ihnen wird gesagt, dass die Verwendung von Alpine Ihre Builds kleiner und Ihren Build-Prozess schneller macht.

Aber wenn Sie Alpine Linux für Python-Anwendungen verwenden, dann gilt Folgendes:

  • Macht Ihre Builds viel langsamer
  • Vergrößert Ihre Bilder
  • Deine Zeit verschwenden
  • Und am Ende kann es zu Fehlern in der Laufzeit kommen


Schauen wir uns an, warum Alpine empfohlen wird, Sie es aber trotzdem nicht mit Python verwenden sollten.

Warum wird Alpine empfohlen?

Nehmen wir an, wir benötigen gcc als Teil unseres Images und möchten Alpine Linux mit Ubuntu 18.04 hinsichtlich der Build-Geschwindigkeit und der endgültigen Image-Größe vergleichen.

Laden wir zunächst zwei Bilder herunter und vergleichen ihre Größen:

$ 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

Wie Sie sehen können, ist das Basisbild für Alpine viel kleiner. Versuchen wir nun, gcc zu installieren und mit Ubuntu zu beginnen:

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/*

Das Schreiben der perfekten Docker-Datei würde den Rahmen dieses Artikels sprengen.

Lassen Sie uns die Montagegeschwindigkeit messen:

$ 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

Wir wiederholen dasselbe für Alpine (Dockerfile):

FROM alpine
RUN apk add --update gcc

Wir montieren, schauen uns den Zeitpunkt und die Größe der Montage an:

$ 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

Wie versprochen werden Alpine-basierte Bilder schneller erfasst und sind kleiner: 15 Sekunden statt 30 und die Bildgröße beträgt 105 MB gegenüber 150 MB. Es ist sehr gut!

Wenn wir jedoch dazu übergehen, eine Python-Anwendung zu erstellen, ist alles nicht so rosig.

Python-Bild

Python-Anwendungen verwenden häufig Pandas und Matplotlib. Daher besteht eine Möglichkeit darin, das offizielle Debian-basierte Image mithilfe dieser Docker-Datei zu erstellen:

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

Sammeln wir es:

$ 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

Wir erhalten ein Bild mit einer Größe von 363 MB.
Werden wir mit Alpine besser abschneiden? Lass es uns versuchen:

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

Was ist da los?

Alpine unterstützt keine Räder

Wenn Sie sich den Build ansehen, der auf Debian basiert, werden Sie feststellen, dass er matplotlib-3.1.2-cp38-cp38-manylinux1_x86_64 herunterlädt.whl.

Dies ist eine Binärdatei für Wheel. Alpine lädt die Quellen „matplotlib-3.1.2.tar“ herunter.gz` da es den Standard nicht unterstützt Räder.

Warum? Die meisten Linux-Distributionen verwenden die GNU-Version (glibc) der C-Standardbibliothek, die tatsächlich von jedem in C geschriebenen Programm, einschließlich Python, benötigt wird. Aber Alpine verwendet „musl“, und da diese Binärdateien für „glibc“ konzipiert sind, sind sie einfach keine Option.

Wenn Sie Alpine verwenden, müssen Sie daher den gesamten in C geschriebenen Code in jedem Python-Paket kompilieren.

Oh ja, Sie müssen nach der Liste aller dieser Abhängigkeiten suchen, die Sie selbst kompilieren müssen.
In diesem Fall erhalten wir Folgendes:

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

Und die Bauzeit dauert...

... 25 Minuten 57 Sekunden! Und die Bildgröße beträgt 851 MB.

Die Erstellung alpiner Images dauert viel länger, sie sind größer und Sie müssen immer noch nach allen Abhängigkeiten suchen. Sie können die Baugruppengröße natürlich mit reduzieren mehrstufige Aufbauten aber das bedeutet, dass noch mehr Arbeit geleistet werden muss.

Das ist nicht alles!

Alpine kann zur Laufzeit unerwartete Fehler verursachen

  • Theoretisch ist musl mit glibc kompatibel, in der Praxis können die Unterschiede jedoch viele Probleme verursachen. Und wenn ja, werden sie wahrscheinlich unangenehm sein. Hier sind einige Probleme, die auftreten können:
  • Alpine hat standardmäßig eine kleinere Thread-Stapelgröße, was dazu führen kann Fehler in Python
  • Einige Benutzer haben das festgestellt Python-Anwendungen sind langsamer aufgrund der Art und Weise, wie Musl Speicher zuweist (anders als Glibc).
  • Einer der Benutzer Beim Formatieren des Datums ist ein Fehler aufgetreten

Sicherlich wurden diese Fehler bereits korrigiert, aber wer weiß, wie viele es noch sein werden.

Verwenden Sie keine Alpine-Bilder für Python

Wenn Sie sich nicht mit großen und langwierigen Builds herumschlagen und nach Abhängigkeiten und potenziellen Fehlern suchen möchten, verwenden Sie Alpine Linux nicht als Basis-Image. Auswahl eines guten Basisbildes.

Source: habr.com

Kommentar hinzufügen