🐳 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.

Régime pour les couches Docker

"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-trunc permet 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

Maîtriser la mémoire partagée Docker (shm_size et ipc) pour les charges de travail AI/data

Docker : Communiquer entre conteneurs via les ports de l'hôte sans partage de réseau

Pourquoi copier un volume Docker ?