Optimiser la taille de vos images Docker pour gagner en efficacité

1. Les images Docker

1.1 Explication des principes

Les images de conteneurs utilisent un système de fichiers particulier (union-capable file system) comme OverlayFS, qui permet d’utiliser plusieurs couches dans le système de fichiers, un peu comme un oignon, ou comme vous pouvez le voir sur la figure 1 avec l’empilement des différentes couches.

La création d’une image passe par l’utilisation d’un fichier appelé Dockerfile. Il s’agit d’un simple fichier texte qui décrit la façon de construire l’image. L’utilisation d’un fichier texte permet de rendre les images facilement compréhensibles et automatisables. Les images sont toujours créées à partir d’une image source (qui peut être vide) sur laquelle on ajoute des configurations (fichiers, variable d’environnement, etc.).

Lors de l’exécution d’un conteneur, les fichiers de l’image vont être utilisés, en lecture seule, et le Docker Engine va créer une nouvelle couche du système de fichiers qui sera, elle, en lecture/écriture. Le système de fichiers va alors utiliser le principe de Copy on Write (CoW), tel qu’illustré sur la figure 2.

Cette dernière couche du système de fichiers est considérée comme éphémère, car elle ne sera pas sauvegardée en cas d’arrêt/redémarrage du conteneur.

1.2 Bénéfices de réduire la taille des images Docker

La taille des images Docker a plusieurs impacts :

• Lors du téléchargement des images, en plus de la latence et la bande passante disponible, le temps de téléchargement est directement lié à la taille des images.
• Une fois téléchargées, il faut stocker les images, que ce soit dans une registry ou dans le cache du nœud Docker sur lequel on exécute l’image. Le nombre d’images que l’on pourra stocker dépendra de leur taille.
• Lors de l’exécution et en particulier dans un cluster orchestré par Docker Swarm, Kubernetes ou d’autres solutions, lors d’un incident, un conteneur doit être redémarré sur un nouveau nœud. Le temps de redémarrage va dépendre directement du téléchargement et du chargement en mémoire de l’image qui sont également liés à la taille de l‘image. Ce temps a donc un impact sur le temps de retour à la situation nominale en cas d’incident.
• Lors des phases de développement et de tests de l’application, le temps de construction et d’exécution des conteneurs est un temps pendant lequel le développeur ne peut pas tester les résultats de ses modifications et est en attente. Il faut donc essayer de le limiter au maximum pour améliorer l’efficacité des développeurs.
• Enfin, d’un point de vue sécurité, la surface potentielle d’attaque sur le conteneur est d’autant plus réduite qu’il ne contient que le minimum d’outils et de librairies à l’intérieur de l’image de conteneurs.

Toutes ces raisons devraient vous pousser à essayer d’optimiser au mieux vos images de conteneurs.

1.3 Prérequis pour les exercices pratiques

Pour pouvoir reproduire les exercices pratiques de la suite de cet article, il faut que vous disposiez d’un ordinateur avec une architecture processeur compatible (comme x86_64).

Il faut ensuite disposer de l’outil Docker.

Si vous utilisez un système d’exploitation macOS ou Windows 10, je vous conseille d’installer Docker Desktop : https://www.docker.com/products/docker-desktop.

Si vous êtes sous Linux, vous devrez installer Docker Engine : https://docs.docker.com/engine/install/.

Suivez les étapes d’installation et faites un test avec la commande docker version dans un terminal. Ce test devrait normalement être concluant maintenant et vous devriez voir un résultat similaire à l’exemple ci-dessous :

1.4 Premiers pas sur quelques images

Pour un premier test, on va utiliser une première image publique « toute faite ». Pour cela, on va la télécharger avec la commande suivante :

On peut déjà voir sur cette simple commande que l’image de base nginx contient déjà 6 couches pour une image fournissant un simple serveur web.

On peut analyser sa taille avec la commande suivante :

Cette image a une taille de 133 MB, soit beaucoup plus petite que la taille d’une machine virtuelle, mais encore assez grosse pour un conteneur.

Si l’on souhaite analyser plus en détail, il faudrait connaître la taille de chaque couche et son contenu.

Pour cela, on peut utiliser la commande suivante :

On peut voir ici les commandes issues du Dockerfile ayant permis de construire cette image nginx.

On identifie les commandes ayant un impact sur la taille de l’image. Si on commence par le bas, on voit d’abord l’ajout d’un ensemble de fichiers pour 69.3 MB. Ceci correspond à l’image de base utilisée dans le conteneur avec un ensemble de fichiers système.

Ensuite, la deuxième couche ayant un impact est celle commençant par la commande /bin/sh -c set -x && addgroup pour une taille de 63.9 MB. Pour avoir le détail de cette commande, on peut utiliser la commande suivante :

Ici, on peut observer la phase d’installation du package nginx et ses dépendances avec le gestionnaire de package apt sur l’image de base précédemment utilisée.

Pour résumer ce premier test, on peut voir que les images que l’on utilise sans les construire peuvent être plus ou moins optimisées et qu’il est intéressant de comprendre le processus utilisé pour les construire et les outils inclus dans ces images.

On va essayer avec un deuxième exemple sur une première application Java et une image de conteneur que l’on va construire.

Voici le code de notre application :

Voici le Dockerfile :

On peut ensuite construire l’image et regarder sa taille :

On obtient une image de 467 MB pour afficher un « hello world ».

2. Optimisation des images

2.1 Bien choisir son image de base

Nous allons reprendre le premier exemple utilisé ci-dessus et modifier l’image de base utilisée.

L’image nginx préconstruite utilisée dans cet exemple utilisait en image de base, une image Debian 10 minimaliste.

Voyons ce que l’on obtient si on remplace cette image de base par une image Alpine https://alpinelinux.org/. Pour cela, nul besoin de reconstruire soi-même l’image, voilà ce que l’on peut obtenir simplement en modifiant le tag utilisé pour télécharger l’image :

Ce simple ajout d’un tag sur l’image téléchargée nous a permis de passer de 133 MB à 22.6 MB pour le même serveur web. L’image de base a en fait été remplacée par Alpine à la place de Debian, les librairies utilisées ne sont pas forcément les mêmes, par exemple musl au lieu de glibc.

Ce changement sur les librairies peut provoquer des comportements différents dans des situations très spécifiques, mais la plupart du temps, il sera invisible d’un point de vue du service.

Le deuxième changement est sur les outils disponibles à l’intérieur du conteneur lorsqu’on a besoin de s’y connecter pour investiguer sur un éventuel problème lors du démarrage ou de l’exécution du conteneur. Cependant, il existe d’autres moyens pour investiguer sans nécessairement avoir à se connecter dans le conteneur, car cela peut impacter son fonctionnement et son intégrité. En effet, un conteneur doit normalement fonctionner sans aucune intervention manuelle au cours de son exécution, car il doit pouvoir être déclenché par un orchestrateur comme Docker Swarm ou Kubernetes.

2.2 Optimiser son process de build

Nous allons maintenant reprendre le deuxième exemple utilisé ci-dessus, sur la même application Java, et modifier la construction de notre application.

Pour cela, nous allons à la fois utiliser une image de base optimisée (Alpine) et une possibilité de Docker qui est le Multi-stage builds. Cela permet de compiler son code dans une image et d’en extraire l’exécutable et les librairies pour créer une image finale allégée sans les outils de compilation.

Ici, dans le cas de Java, nous allons, dans une première image de conteneurs, utiliser l’outil jlink pour créer un Java Runtime Environment (JRE) minimaliste. Nous allons ensuite compiler notre application. Enfin, il nous suffit d’exporter dans notre image de base optimisée (Alpine), le JRE minimaliste et le bytecode de notre application Java (le fichier .class) pour pouvoir l’exécuter, en utilisant le moins de ressources possible.

Voici ce que cela donne :

Cette méthode nous a permis de passer d’une image de 467 MB à une image de 40.2 MB pour la même application Java de type « hello world », grâce à la modification de l’image de base et l’optimisation du process de build notamment grâce au multi-stage build et l’utilisation d’un JRE minimaliste.

2.3 Optimisation à l’extrême

Pour certains langages, on peut pousser ce processus à l’extrême. En effet, on peut compiler certains langages comme C ou Go en un exécutable auto porteur, qui n’a donc pas besoin de prérequis au-delà du noyau pour fonctionner. Il n’est donc pas nécessaire d’avoir certaines librairies comme un prérequis à l’exécution. Du coup, dans un format conteneur, on peut utiliser une image de base spécifique appelée scratch, qui ne contient aucun fichier.

Voici un exemple sur une application en C :

Une fois l’application Java recodée en C, et en utilisant le multi-stage build et l’image de base scratch, on arrive à descendre à 707 kB pour notre image conteneur.

Ceci est la forme la plus optimisée, à l’extrême. Cependant, elle ne contient aucun outil pour aider à comprendre ce qu’il se passe si l’image de conteneur ne réagit pas comme cela est attendu. Il faut donc avoir d’autres moyens d’analyse, mais cela dépasse le cadre de cet article.

Conclusion

Cet article vous a guidé à travers la découverte ou la redécouverte de la technologie Docker et en particulier des images Docker et de leurs optimisations avec quelques exemples simples pour comprendre les différentes approches et les options disponibles.

J’espère que vous avez apprécié la démarche progressive de l’apprentissage.

Dans cet article, je suis resté concentré sur les méthodes de construction d’images de conteneurs incluses dans Docker. Il existe également de nombreux autres outils permettant de construire ses images Docker sans utiliser la commande docker build comme par exemple : Jib, Kaniko, Bazel, Buildah, BuildKit, img, pouch…

Si vous souhaitez étendre ce sujet, je vous conseille de jeter un œil sur les Cloud Native Buildpacks https://buildpacks.io/ : ils permettent de créer une image de conteneurs sans avoir à écrire un Dockerfile, tout en intégrant de l’automatisation et des bonnes pratiques pour optimiser et sécuriser les images obtenues. Cet outil est même supporté dans des langages comme Spring Boot : https://spring.io/blog/2020/08/14/creating-efficient-docker-images-with-spring-boot-2-3.

Enfin, si vous voulez aller encore plus loin dans l’optimisation, je vous conseille cette série d’articles de blog par Jérôme Petazzoni, intitulée « Chérie, j'ai rétréci Docker » en 3 parties : https://enix.io/fr/blog/cherie-j-ai-retreci-docker-part1/.