🐳 Le début du régime de votre image Docker : Découvrir son historique avec docker history
Il arrive parfois qu'après avoir déployé une application apparemment légère, la taille de l'image dépasse allègrement 1 Go. On se dit : "Mais qu'est-ce que j'ai bien pu y mettre ?" C'est là qu'il faut plonger dans l'historique de l'image.
"Mais qu'est-ce qui t'a fait grossir comme ça ?"
Une image Docker, c'est comme un oignon avec ses multiples couches. La commande docker history est un outil précieux, tel un rayon X, pour éplucher ces couches une par une et démasquer les coupables.
Son utilisation de base est très simple :
# Utilisation de base
docker history [options] <nom_image:tag>
# Exemple : vérifier l'historique de mon application
docker history my-app:latest
Lorsque vous exécutez cette commande, l'historique de l'image s'affiche, en commençant par la couche la plus récente jusqu'à l'image de base.
IMAGE CREATED CREATED BY SIZE
a6215f271958 5 minutes ago /bin/sh -c #(nop) CMD ["/bin/sh"] 0B
<missing> 7 weeks ago /bin/sh -c #(nop) ADD file:f28242cf608f6... 7.81MB
Observez attentivement la colonne SIZE. Si vous voyez des centaines de Mo là où vous attendez 0B, alors vous avez trouvé un candidat pour le régime ! Avec l'expérience, vous développerez un "flair" pour repérer les couches suspectes.
**💡 Astuce utile :
--no-trunc**Par défaut, la sortie tronque les commandes trop longues. L'option
--no-truncpermet d'afficher la commande complète, ce qui est essentiel pour une analyse précise.
docker history --no-trunc my-app:latest
Cas pratique : "Le coupable était chown"
Laissez-moi vous raconter une histoire vraie que j'ai vécue. J'avais un projet de 150 Mo que je compilais, et l'image résultante dépassait étrangement les 300 Mo. Le coupable ? Deux lignes de Dockerfile qui semblaient tout à fait inoffensives.
[Méthode inefficace : création de 2 couches]
# 1. Copie des fichiers (par défaut, ils sont copiés avec le propriétaire root)
COPY . .
# 2. Changement de propriétaire pour des raisons de sécurité (exécuté comme une commande séparée)
RUN chown -R appuser:appgroup /app
Après avoir compilé cela, voici le résultat obtenu avec docker history :
IMAGE CREATED BY SIZE
<layer_id_2> /bin/sh -c chown -R appuser:appgroup /app 150MB <-- (Le point problématique !)
<layer_id_1> /bin/sh -c #(nop) COPY dir:abc in /app 150MB
C'est là que la nature des couches Docker révèle son côté insidieux. À l'étape 1, la copie des fichiers de 150 Mo crée une couche. Mais à l'étape 2, lorsque chown est exécuté, Docker se dit : "Tiens ? Les informations de fichier (propriété) ont changé ? Alors, je vais créer une nouvelle couche avec l'état modifié !" et copie les 150 Mo existants pour empiler une nouvelle couche.
Au final, le contenu est identique, mais les fichiers avec une propriété différente sont stockés en double, doublant ainsi la taille de l'image.
La solution : un régime en une seule ligne !
La solution est simple : il suffit de spécifier le propriétaire dès la copie pour fusionner les couches en une seule.
[Méthode efficace : création de 1 couche]
# Copiez et spécifiez le propriétaire en même temps !
COPY --chown=appuser:appgroup . .
En modifiant le Dockerfile de cette manière et en refaisant un docker history, le résultat est spectaculaire :
IMAGE CREATED BY SIZE
<layer_id_1> /bin/sh -c #(nop) COPY --chown=appuser... dir:abc 150MB
Vous voyez ? Une seule couche a été créée, et la taille de l'image est redevenue mince, à 150 Mo. En fusionnant deux commandes en une seule ligne, la taille a été réduite de moitié.
Conclusion : Toujours vérifier l'historique après le build !
N'oubliez jamais que pour les images Docker, chaque commande correspond à une couche.
Tout comme vous testez votre code après l'avoir écrit, prenez l'habitude d'exécuter docker history --no-trunc après chaque build. Des questions comme "Pourquoi cet apt-get est-il si lourd ?", ou "Pourquoi cette couche a-t-elle été séparée ?" vous amèneront, de fil en aiguille, à construire des systèmes de plus en plus légers et efficaces.
Les couches inutiles sont l'ennemi de votre système !
Cela vous a été utile ? Si oui, n'hésitez pas à laisser un J'aime !
Lisez aussi les articles connexes.
Articles connexes
Comprendre parfaitement la mémoire partagée Docker (shm_size et ipc)
Docker : Communiquer entre conteneurs via le port hôte sans partage réseau