Utiliser des images de base légères (ex: alpine)

Le poids des images : pourquoi la légèreté compte

Chaque Dockerfile commence par une instruction `FROM`, qui spécifie l'image de base sur laquelle votre propre image sera construite. Cette image de base fournit le système d'exploitation minimal et les outils fondamentaux nécessaires à l'exécution de votre application. Le choix de cette image de base a un impact considérable sur la taille finale de votre image personnalisée, ainsi que sur d'autres aspects critiques comme les temps de build, les temps de déploiement et la surface de sécurité.

Des images de base volumineuses (comme les versions standard d'Ubuntu ou Debian, qui peuvent peser plusieurs centaines de mégaoctets) contiennent de nombreux outils et bibliothèques qui ne sont pas forcément nécessaires pour votre application spécifique. Chaque mégaoctet supplémentaire signifie plus de temps passé à télécharger l'image (lors du build, du pull par les développeurs ou lors du déploiement), plus d'espace disque consommé (sur votre machine, dans les registres Docker, sur les serveurs de production), et potentiellement plus de vulnérabilités de sécurité dues à la présence de logiciels superflus.

Adopter une stratégie consistant à utiliser des images de base aussi légères que possible est donc une bonne pratique fondamentale. Cela permet de créer des images finales plus petites, plus rapides à manipuler et intrinsèquement plus sûres, car elles embarquent uniquement le strict nécessaire.

Alpine Linux : le champion de la catégorie poids plume

Parmi les images de base légères, Alpine Linux est devenue extrêmement populaire dans l'écosystème Docker. Il s'agit d'une distribution Linux indépendante, conçue spécifiquement pour la sécurité et la légèreté. L'image de base officielle `alpine` pèse généralement autour de 5 à 7 Mo seulement, une fraction minuscule comparée aux images de base de distributions plus traditionnelles.

Cette taille réduite est obtenue grâce à deux choix techniques majeurs :

• Utilisation de musl libc : Au lieu de la bibliothèque C standard GNU (glibc) utilisée par la plupart des distributions Linux, Alpine utilise `musl libc`, une implémentation plus légère.
• Utilisation de BusyBox : BusyBox combine des versions allégées de nombreuses commandes Unix courantes (comme `ls`, `cat`, `cp`, `sh`, etc.) en un seul petit exécutable.

En plus de sa taille, Alpine met l'accent sur la sécurité. Sa nature minimaliste signifie qu'elle embarque par défaut très peu de paquets, réduisant ainsi la surface d'attaque potentielle. Son gestionnaire de paquets, `apk`, est également simple et efficace.

De nombreuses images officielles d'applications et de langages proposent désormais des variantes basées sur Alpine. Par exemple, vous trouverez `python:3.9-alpine`, `node:18-alpine`, `nginx:stable-alpine`, etc. Utiliser ces variantes est souvent le moyen le plus simple de bénéficier de la légèreté d'Alpine pour votre application spécifique.

# Utilisation directe de l'image Alpine
FROM alpine:latest

# Installation de curl via le gestionnaire de paquets apk
# --no-cache évite de conserver le cache apk, réduisant la taille de la couche
RUN apk add --no-cache curl

CMD ["curl", "https://ifconfig.me"]

# Utilisation d'une variante Alpine pour Node.js
FROM node:18-alpine

WORKDIR /usr/src/app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 3000
CMD [ "node", "server.js" ]

Considérations et alternatives possibles

Bien qu'Alpine soit un excellent choix dans de nombreux cas, il est important de connaître quelques contreparties potentielles. La différence de bibliothèque C (`musl` vs `glibc`) peut parfois causer des problèmes de compatibilité avec certains logiciels précompilés qui s'attendent spécifiquement à `glibc`. Bien que cela devienne moins fréquent, c'est un point à vérifier si vous rencontrez des erreurs étranges avec certaines dépendances.

De plus, comme Alpine est très minimaliste, vous devrez souvent installer explicitement des paquets (via `apk add`) que vous trouveriez par défaut dans d'autres distributions (par exemple, `bash`, `ca-certificates`, `build-base` pour la compilation). Si vous devez ajouter de nombreuses dépendances volumineuses, l'avantage initial en taille peut être réduit.

Il existe d'autres approches pour obtenir des images légères :

• Variantes "slim" : Beaucoup d'images officielles proposent aussi une variante `slim` (ex: `python:3.9-slim-buster`). Celles-ci sont basées sur des distributions plus traditionnelles comme Debian, mais ont été allégées en supprimant des paquets non essentiels. Elles sont souvent un bon compromis entre taille et compatibilité (car elles utilisent `glibc`).
• Images "Distroless" : Popularisées par Google, les images "distroless" poussent le minimalisme encore plus loin. Elles contiennent uniquement votre application et ses dépendances d'exécution directes, sans gestionnaire de paquets, sans shell, ni aucun autre utilitaire standard. C'est excellent pour la sécurité et la taille, mais rend le débogage (`docker exec`) plus difficile. Elles sont souvent utilisées en conjonction avec des builds multi-étapes.

En conclusion, pour débuter, considérer les variantes `-alpine` des images officielles de vos langages ou applications est une excellente pratique. Si vous rencontrez des problèmes de compatibilité, les variantes `-slim` sont une bonne alternative. L'objectif principal est de choisir consciemment votre image de base en gardant à l'esprit l'impact sur la taille, la vitesse et la sécurité.