1.1Images : tags, couches et Docker Hub
L'essentiel en 30 secondes
- Le tag, c'est la version : postgres:16 fige la majeure, postgres:16.4 la mineure, postgres:latest suit la dernière (donc change sans prévenir) — en production, on fige toujours un tag précis et on le note.
- Des couches empilées et partagées : une image = un empilement de couches en lecture seule, mises en cache et partagées entre images — dix images sur la même base ne téléchargent la base qu'une fois.
- Choisir sans se tromper : images officielles (mainteneur vérifié), tags supportés lus dans la doc, date de mise à jour et architecture (amd64/arm64) vérifiées — une image abandonnée depuis deux ans est un risque sécurité.
Mini-cas filé — Idir, devops junior à Alger
Idir, devops junior à Alger, doit conteneuriser la base de données d'une petite application interne. Au lieu de taper « postgres » et de prendre la première proposition, il ouvre la page officielle sur Docker Hub, compare les tags et retient postgres:16.4 : version figée, à jour, disponible en amd64 et arm64. Il note ce choix dans un fichier versions.txt partagé avec son équipe. Six mois plus tard, quand un collègue relance l'environnement sur une autre machine, il obtient exactement le même comportement — parce que le tag n'a pas bougé.
Ce même cas revient dans le cours, le schéma, le script et le défi 48h — et continue en 1.2, 1.3, 1.4 et 1.5.
1. Le tag, c'est la version
Après le « : », le tag désigne la variante de l'image : postgres:16 fige la version majeure, postgres:16.4 la mineure, postgres:latest suit la dernière disponible — donc change sans prévenir. En développement, suivre latest est acceptable ; en production, on fige toujours un tag précis et on le note (Idir l'écrit dans versions.txt).
La règle tient en une phrase : figer en production, suivre en veille. Un déploiement reproductible commence par un tag qui ne bouge pas.
2. Des couches empilées et partagées
Une image est un empilement de couches en lecture seule : chaque instruction du build ajoute une couche, chaque couche est mise en cache et partagée entre images. Télécharger dix images basées sur le même Debian ne télécharge la base qu'une fois : c'est ce qui rend Docker si économe en téléchargements et en disque.
Conséquence pratique : docker images affiche la taille décompressée, mais le téléchargement ne prend que les couches manquantes. D'où l'intérêt de bases partagées — et des variantes slim quand elles existent.
3. Choisir sur Docker Hub sans se tromper
Préférez les images officielles (badge, mainteneur vérifié), lisez les tags supportés et la documentation, vérifiez la date de mise à jour et l'architecture (amd64 pour PC/serveurs, arm64 pour Mac M et Raspberry). Une image obscure non mise à jour depuis deux ans est un risque sécurité, même si elle fait gagner 50 Mo.
Idir applique la grille à chaque nouvelle image : officielle, à jour, documentée — les seules retenues. Le reste ne monte jamais en production.
🔎 Exemple concret — 🔎 Exemple concret — Bien choisir Postgres
Le choix d'Idir pour la base de son application, sans latest en production.
docker pull postgres:16.4
docker images
# à éviter en production :
# docker run postgres:latestLecture : on fige la 16.4, on vérifie sa présence locale, on bannit latest de la prod.
Leçon : six mois plus tard, le même tag redonne le même comportement.
Vocabulaire de la section
- Tag
- Étiquette de version après le « : » (16, 16.4, latest) ; il désigne quelle variante de l'image on récupère.
Exemple simple : Idir fige postgres:16.4 pour sa base de production.
Ce que ce n'est pas : un simple commentaire décoratif.
Réflexe : prod = tag figé et noté, jamais latest.
- Couche (layer)
- Strate en lecture seule de l'image, mise en cache et partagée entre images.
Exemple simple : La base Debian téléchargée une seule fois pour dix images.
Ce que ce n'est pas : une copie complète dupliquée par image.
Réflexe : bases partagées = téléchargements économisés.
- Image officielle
- Image maintenue et vérifiée sur Docker Hub (badge, mainteneur identifié).
Exemple simple : Le postgres officiel choisi par Idir plutôt qu'une copie obscure.
Ce que ce n'est pas : la première image venue avec « postgres » dans le nom.
Réflexe : officielle, à jour, documentée — sinon on s'abstient.
- latest
- Tag mouvant qui suit la dernière version publiée : pratique en dev, instable en prod.
Exemple simple : Idir l'utilise pour tester, jamais pour déployer.
Ce que ce n'est pas : une version figée et reproductible.
Réflexe : latest en dev, tag précis en production.
En pratique — En pratique — Auditer vos images
- Listez vos images locales (docker images) et repérez les latest.
- Pour chacune, trouvez le tag figé équivalent sur Docker Hub.
- Vérifiez l'architecture et la fraîcheur de mise à jour.
- Notez votre choix (image:tag) dans un fichier versions.txt.
Script prêt à dire — justifier son image (30 s)
« Pour la base, je prends l'image officielle postgres, tag 16.4 figé — pas latest, pour rester reproductible. J'ai vérifié la date de mise à jour et l'architecture sur Docker Hub, et je note le choix dans versions.txt pour l'équipe. »
À dire en montrant la page Docker Hub et le fichier versions.txt.
Modèle copier-coller — versions.txt
# versions.txt — Idir, Alger
# Une ligne par image : nom:tag figé + date du choix
postgres:16.4 # base appli interne (choix 2026-10)
nginx:1.27 # frontal web (choix 2026-10)
# Règle : latest interdit en prod. Tout changement = nouvelle ligne datée.Base de données d'Idir
Comme ci-dessus : postgres:16.4 officiel, figé et noté — la base de l'application interne tourne à l'identique sur chaque machine.
Frontal web léger
nginx:1.27 officiel, variante slim si elle couvre le besoin : même grille (officielle, à jour, architecture vérifiée) avant le premier pull.
PC portable arm64
Collègue d'Idir sur Mac M : vérifier que le tag retenu existe bien en arm64 sur Docker Hub avant de promettre la reproductibilité.
Image d'outil ponctuel
ubuntu:24.04 en -it --rm pour bricoler (niveau 1.2) : même en jetable, on fige le tag au lieu de latest pour retrouver le même outil demain.
✓ Bonnes pratiques
- Figer en production, suivre en veille.
- Préférer les variantes slim quand elles existent.
- Lire la page Docker Hub avant le premier pull.
✗ Pièges fréquents
- Déployer latest en production (dérive silencieuse).
- Prendre une image abandonnée pour gagner 50 Mo.
- Ignorer l'architecture (image amd64 lente sur Mac M).
Points clés à retenir
- Le tag fige la version ; latest bouge.
- Les couches sont partagées et cachées.
- Officielles, à jour, documentées : les seules retenues.
- On note ses versions comme du code.
Défi 48h — appliquez demain
Listez vos images avec docker images, traquez les latest, trouvez leur tag figé sur Docker Hub (officiel, à jour, bonne architecture) et écrivez votre versions.txt.
- Je choisis des images officielles, à jour et documentées.
- Je fige un tag précis en production (jamais latest).
- Je note chaque choix image:tag dans versions.txt.
Questions fréquentes
Alpine ou slim, que choisir ?
Les deux allègent : slim enlève l'inutile de l'image officielle, alpine change de libc (musl). Alpine est minuscule mais peut surprendre (DNS, perfs) : testez avant la prod. Dans les deux cas, on fige le tag et on vérifie la fraîcheur.
Combien pèse vraiment une image ?
docker images donne la taille décompressée ; le téléchargement ne prend que les couches manquantes. D'où l'intérêt des bases partagées : empiler dix images sur le même Debian ne coûte la base qu'une fois.
Quelle pratique pour une base de données en production ?