Comment optimiser vos images de conteneurs Docker

Docker est devenu un standard de fait pour l’hébergement des services internet. Il vient avec bien des avantages mais il s’accompagne aussi d’une insidieuse tendance, la croissance incontrôlée des images Docker ou Docker Bloat.

Dans cet article nous allons vous présenter comment vous prémunir de cette tendance qui peut sembler inévitable en optimisant vos images Docker. Optimiser dans ce contexte implique de réduire la taille des images en perdant un minimum de fonctionnalités ce faisant.

Le Docker bloat vient avec des coûts cachés souvent difficile à prévenir et à identifier : ralentissement des temps de build et de déploiement, consommation de plus de bande passante et de stockage et si la perte de contrôle va trop loin, augmentation des risques de sécurité en augmentant la surface d’attaque.

Il n’est pas rare de voir des images atteindre 1Go ou plus. Multiplié par autant de microservices, cela représente plusieurs Gigaoctets à transférer régulièrement.

Mettre en place une politique rationnelle d’optimisation permet de réduire ce risque et vous garanti des coûts opérationnels sous contrôle.

Bien choisir l’image de base Docker

Tout commence par la sélection de l’image de base Docker que vous allez utiliser.

Vous le savez sans doute, toutes les images n’ont pas le même poids et ne viennent pas toutes avec le même niveau de garantie lorsqu’il sagit du rythme et de la qualité de la maintenance.

Il est préférable de choisir des images officielles. Elles sont généralement plus fiables, mieux documentées et bien maintenues.

Docker pousse d’ailleurs les images Alpine (qui pèsent 6 Mo) qui sont bien plus économes en taille que les images Debian et Ubuntu.

Et si Debian-slim est beaucoup moins lourd que l’image Debian standard, elle reste bien plus grosse qu’Alpine, surtout après installations supplémentaires.

Évidemment, faire le choix de la légèreté ne vient pas sans compromis. Chez Bearstech, nous faisons le choix d’une image Debian modifiée et maintenue par nos soins. Cela nous permet de nous appuyer sur l’éco-système très complet de Debian.

Exploiter les builds multi-stage

Les builds multi-stage méritent une attention particulière, ils peuvent avoir un impact sur les performances de votre image Docker. En substance, il s’agit de séparer la phase de compilation de la phase d’exécution.

Un Dockerfile multi-stage utilise plusieurs directives ‘FROM’ successives, chacune définissant une étape de construction. La dernière étape produit l’image finale, les précédentes servant à préparer les artefacts. Cela permet de séparer l’environnement de build de l’environnement d’exécution.

Par exemple, lors de la première étape, on utilise une image avec tous les outils requis pour construire l’application. On y copie le code source et on lance les commandes de compilation. Une fois cette étape terminée, on obtient les artefacts nécessaires. La deuxième étape part d’une image de base minimale et on y copie depuis l’étape de build uniquement ces artefacts. On obtient ainsi une image finale répondant strictement aux besoins de la phase de run sans la compilation ni le code source complet.

Suivi et maintenance des images dans le temps

L’optimisation des images Docker ne doit pas être un effort ponctuel, il doit être un effort continu. Il faut surveiller en continu l’évolution de vos images au fil des versions.

Il faut inspecter régulièrement la taille de vos images pour détecter toute dérive. Il est conseillé d’automatiser ce suivi : par exemple, ajouter une étape à vos pipelines CI qui utilise ‘docker inspect’ pour signaler la taille de l’image produite et la comparer à un seuil ou à la version précédente. Surveiller régulièrement la taille des images Docker est essentiel pour identifier ce qu’il faut optimiser.

Maîtriser les dépendances et nettoyer les caches

Pour limiter la taille de vos images, il est préférable d’installer uniquement les paquets nécessaires et utiliser les options ‘–no‑install‑recommends’ ou ‘–no-cache’ pour éviter les dépendances inutiles.

Pensez aussi à nettoyer les caches de gestionnaires de paquets dans la même instruction ‘RUN’ afin qu’ils n’alourdisent pas les couches. Groupez autant que faire se peut les commandes dans une seule instruction RUN afin de réduire le nombre de couches et supprimez le cache à la fin.

Réduire le contexte de build

Comprenez que Docker envoie tout le contenu du répertoire comme contexte. Excluez les fichiers inutiles (dépôts Git, tests, documentation, caches) via un fichier ‘.dockerignore’ pour éviter qu’ils ne se retrouvent dans l’image. Cela accélèrera la construction et diminuera la taille du résultat.

Un conteneur, un service

Ne regroupez pas plusieurs services dans une même image.

Déployer une image par service simplifie les mises à jour et limite l’accumulation de dépendances inutiles.

Conclusion

En appliquant ces principes, vous obtiendrez des images beaucoup plus compactes et rapides à déployer.

Des images légères réduisent la surface d’attaque, accélèrent les téléchargements et diminue les ressources consommées.