Lors de la distribution d'applications Python dans un environnement Docker, il est fréquent d'observer des temps de build d'image excessivement longs ou des échecs de build dus à des problèmes de dépendance avec des compilateurs comme gcc. Une des solutions les plus efficaces est d'utiliser les Wheels Python.
Dans cet article, nous allons explorer le concept et les avantages des Wheels Python, ainsi que la manière de les utiliser dans un Dockerfile pour optimiser le processus de build.
1. Qu'est-ce qu'une Wheel Python ?
Wheel (.whl) est un format de distribution binaire (Built Distribution) pour Python.
En général, les packages Python sont distribués sous deux formes.
-
Distribution source (
sdist,.tar.gz) : sous forme de code source. Il est nécessaire de compiler lors de l'installation sur l'ordinateur de l'utilisateur. -
Distribution binaire (
bdist_wheel,.whl) : sous forme binaire précompilée. L'installation se termine en copiant simplement les fichiers sans compilation supplémentaire.
Pour faire une analogie simple, la distribution source est un « meuble à assembler », tandis que la Wheel est un « meuble déjà assemblé ». Utiliser une Wheel élimine le temps d'assemblage et le besoin d'outils (compilateurs).
2. Différence avec une installation pip classique
Lorsque nous exécutons la commande pip install <package>, cela fonctionne en interne avec la priorité suivante.
-
Si un fichier Wheel existe : le binaire est téléchargé et installé immédiatement. (très rapide)
-
Si un fichier Wheel n'existe pas : le fichier source (
tar.gz) est téléchargé, puis compilé localement et installé. (lent, nécessite des outils de compilation)
Tableau récapitulatif des différences
| Type | Distribution source (sdist) | Wheel (whl) |
|---|---|---|
| Extension | .tar.gz, .zip |
.whl |
| Processus d'installation | Téléchargement -> Compilation -> Installation | Téléchargement -> Installation |
| Vitesse d'installation | Lent (temps de compilation requis) | Très rapide |
| Outils nécessaires | Compilateur (gcc, g++, fichiers d'en-tête, etc.) |
Aucun (seulement pip nécessaire) |
| Dépendance OS | Selon l'environnement au moment de la compilation | Dépend de l'OS/architecture construit |
3. Raisons d'utiliser Wheel dans un Dockerfile (avantages)
Dans un environnement Docker, en particulier avec Multi-stage Build, l'utilisation de Wheel présente plusieurs avantages clairs.
-
Amélioration considérable de la vitesse de build : il n'est plus nécessaire de compiler à chaque fois des bibliothèques lourdes écrites en C/C++ telles que
pandasetnumpy. -
Réduction de la taille de l'image : l'image d'exécution finale n'a pas besoin d'inclure des outils de compilation lourds comme
gccoubuild-essential. -
Assurance de stabilité : cela empêche les échecs de build dus à des problèmes de réseau ou des pannes temporaires de dépôts externes, et permet d'utiliser des fichiers précompilés localement.
4. Comment rédiger et utiliser un Dockerfile
Un build Docker utilisant Wheel se compose principalement de la génération d'un fichier Wheel dans la phase Builder, suivie de son installation dans la phase Final.
Exemple : Dockerfile utilisant un Multi-stage Build
Voici un modèle efficace pour installer un package dépendant de bibliothèques C.
# [Phase 1] Builder : Création du fichier Wheel
FROM python:3.9-slim as builder
# Installation des packages essentiels pour la compilation (non inclus dans l'image finale)
RUN apt-get update && apt-get install -y \
build-essential \
gcc \
&& rm -rf /var/lib/apt/lists/*
WORKDIR /app
# Copie du requirements.txt
COPY requirements.txt .
# Création des fichiers .whl dans le répertoire /wheels avec pip wheel
# -w : spécifie le chemin de stockage des fichiers wheel
RUN pip wheel --no-cache-dir --no-deps --wheel-dir /app/wheels -r requirements.txt
# [Phase 2] Final : Image d'exécution
FROM python:3.9-slim
WORKDIR /app
# Copie uniquement des fichiers Wheel créés dans la phase Builder
COPY --from=builder /app/wheels /wheels
COPY --from=builder /app/requirements.txt .
# Installation des packages en utilisant les fichiers Wheel
# --no-index : ignore les index PyPI et cherche uniquement les fichiers locaux
# --find-links : spécifie le chemin pour trouver les packages à installer
RUN pip install --no-cache --no-index --find-links=/wheels -r requirements.txt \
&& rm -rf /wheels
# Copie du code de l'application
COPY . .
CMD ["python", "main.py"]
Explication des commandes clés
-
pip wheel: génère des fichiers.whladaptés à l'environnement sans installer le package. -
--wheel-dir: emplacement où les fichiers Wheel seront sauvegardés. -
--find-links=/wheels: indique de chercher les packages dans le chemin local spécifié plutôt que de les télécharger depuis le serveur PyPI (Internet).
Conclusion
Utiliser les Wheels Python lors des builds Docker n'est pas qu'une option, c'est une technique d'optimisation presque indispensable. Dans un environnement où des builds répétitifs se produisent, comme dans une pipeline CI/CD, réduire le temps de build et la taille de l'image peut entraîner des économies considérables.
Si votre Dockerfile actuel inclut l'installation de gcc, envisagez de passer à un build multi-stage utilisant Wheel.

Aucun commentaire.