Wenn Sie Python-Anwendungen in einer Docker-Umgebung bereitstellen, kommt es häufig vor, dass die Bildbauzeit übermäßig lange dauert oder der Bau aufgrund von Abhängigkeiten zu Kompilierern wie gcc fehlschlägt. Eine der effektivsten Lösungen in solchen Fällen besteht darin, Python Wheel zu verwenden.

In diesem Artikel erfahren Sie, was Python Wheel ist, seine Vorteile und wie Sie es in einem Dockerfile zur Optimierung des Bauprozesses verwenden können.


1. Was ist Python Wheel?



Wheel(.whl) ist das binäre Verteilungsformat (Built Distribution) für Python.

In der Regel werden Python-Pakete in zwei Formen verteilt.

  1. Source Distribution (sdist, .tar.gz): Dies ist die Form des Quellcodes. Bei der Installation ist auf dem Computer des Benutzers ein Kompilierungsprozess erforderlich.

  2. Built Distribution (bdist_wheel, .whl): Dies ist die Form eines vorcompilierten Binaries. Bei der Installation wird lediglich die Datei kopiert und die Installation ist abgeschlossen, ohne dass eine separate Kompilierung erforderlich ist.

Man könnte es einfach mit 'Möbel, die zusammengebaut werden müssen', vergleichen, während Wheel 'fertige Möbel' sind. Mit Wheel brauchen Sie keine Zeit und kein Werkzeug (Compiler) für den Zusammenbau.


2. Unterschiede zur normalen pip-Installation

Wenn wir den Befehl pip install <package> ausführen, funktioniert er intern in der folgenden Priorität.

  1. Wenn Wheel-Dateien vorhanden sind: Es wird die entsprechende Binärdatei heruntergeladen und sofort installiert. (sehr schnell)

  2. Wenn keine Wheel-Datei vorhanden ist: Es wird die Quelldatei (tar.gz) heruntergeladen, anschließend wird im lokalen Umfeld eine Kompilierung (Build) durchgeführt und installiert. (langsam, Kompilierungswerkzeuge erforderlich)

Zusammenfassung der Unterschiede

Kategorie Source Distribution (sdist) Wheel (whl)
Dateiendung .tar.gz, .zip .whl
Installationsprozess Download -> Kompilierung -> Installation Download -> Installation
Installationsgeschwindigkeit Langsam (benötigt Kompilierungszeit) Sehr schnell
Benötigte Werkzeuge Kompilierer (gcc, g++, Header-Dateien etc.) Keine (nur pip notwendig)
Betriebssystemabhängigkeit Abhängig von der Umgebung zur Kompilierungszeit Abhängig vom gebauten OS/Architektur

3. Gründe für die Verwendung von Wheel im Dockerfile (Vorteile)



Die Verwendung von Wheel in einer Docker-Umgebung, insbesondere bei Multi-stage Builds, bietet folgende klare Vorteile.

  1. Drastische Verbesserung der Baugeschwindigkeit: Sie müssen schwere Bibliotheken wie pandas und numpy, die in C/C++ geschrieben sind, nicht ständig kompilieren.

  2. Gewichtsreduktion des Images: Im endgültigen Ausführungs-Image (Runtime Image) müssen keine schweren Kompilierungswerkzeuge wie gcc und build-essential enthalten sein.

  3. Gewährleistung der Stabilität: Dies verhindert den Ausfall des Builds aufgrund von Netzwerkproblemen oder temporären Störungen externer Speicherorte, sodass Sie auch lokal vorab gebaute Dateien verwenden können.


4. Erstellen und Verwenden des Dockerfiles

Docker-Bauten, die Wheel verwenden, werden hauptsächlich im Builder-Stadium erstellt, indem Wheel-Dateien generiert werden, und im Final-Stadium werden diese zur Installation verwendet.

Beispiel: Dockerfile mit Multi-stage Build

Unten ist ein Muster zum effizienten Installieren von Paketen mit Abhängigkeiten von C-Bibliotheken.

# [Stage 1] Builder: Erzeugen von Wheel-Dateien
FROM python:3.9-slim as builder

# Installation der erforderlichen Pakete für die Kompilierung (wird nicht im endgültigen Image enthalten)
RUN apt-get update && apt-get install -y \
    build-essential \
    gcc \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /app

# Kopieren der requirements.txt
COPY requirements.txt .

# Erzeugen von .whl-Dateien im Verzeichnis /wheels mit dem pip wheel-Befehl
# -w: gibt den Speicherort für die Wheel-Dateien an
RUN pip wheel --no-cache-dir --no-deps --wheel-dir /app/wheels -r requirements.txt


# [Stage 2] Final: Ausführungs-Image
FROM python:3.9-slim

WORKDIR /app

# Nur die in Builder-Stadium erzeugten Wheel-Dateien kopieren
COPY --from=builder /app/wheels /wheels
COPY --from=builder /app/requirements.txt .

# Installation der Pakete mithilfe der Wheel-Dateien
# --no-index: Ignoriert den PyPI-Index und sucht nur lokale Dateien
# --find-links: Gibt den Speicherort für die zu installierenden Pakete an
RUN pip install --no-cache --no-index --find-links=/wheels -r requirements.txt \
    && rm -rf /wheels

# Anwendungs-Code kopieren
COPY . .

CMD ["python", "main.py"]

Erläuterungen zu den Schlüsselbefehlen

  • pip wheel: Generiert eine .whl-Datei für die entsprechende Umgebung, ohne Pakete zu installieren, und speichert sie im angegebenen Verzeichnis.

  • --wheel-dir: Der Speicherort, an dem die erzeugten Wheel-Dateien gespeichert werden.

  • --find-links=/wheels: Weist an, nach Paketen im angegebenen lokalen Speicherort zu suchen, anstatt sie vom PyPI-Server (Internet) herunterzuladen.


Fazit

Die Verwendung von Python Wheel bei Docker-Bauten ist nicht nur eine Option, sondern vielmehr eine unverzichtbare Optimierungstechnik. Insbesondere in Umgebungen, in denen CI/CD-Pipelines wiederholte Bauten durchführen, können Sie durch die Verkürzung der Bauzeit und die Reduzierung der Bildgröße erhebliche Kosteneinsparungen erzielen.

Wenn Ihr aktuelles Dockerfile den Installationsprozess von gcc umfasst, sollten Sie auf einen Multi-Stage-Bau mit Wheel umsteigen.

python-wheel-concept-image