2.3Versionner et publier ses images
L'essentiel en 30 secondes
- Taguer au build, compte inclus : compte/image:version est l'adresse complète — sans namespace, pas de push.
- Immuable par livraison : un tag figé et testé par version (1.2.0), jamais réécrit — les alias mouvants ne servent qu'au confort.
- Jamais de secret poussé : tout ce qui entre dans l'image part au push — un push public est irréversible.
Mini-cas filé — Idir et la prod qui tirait latest
L'image maigre d'Idir (2.2) tourne en local, mais l'équipe la partage à la main, en latest, sans version : la prod a déjà dérivé deux fois. Idir tague au build avec le compte (moncompte/mon-app:1.2.0 plus alias 1.2), se connecte au registre, pousse les deux tags, puis fait tirer la 1.2.0 sur une autre machine : build ici, run ailleurs, version figée. Il vérifie la visibilité du dépôt avant de pousser. En 2.4, il rendra cette image configurable ; en 2.5, il vérifiera qu'elle ne contient aucun secret avant tout nouveau push.
Suite du fil rouge 2.2 : l'image maigre d'Idir voyage avec un numéro de version — et continue en 2.4 et 2.5.
1. Taguer comme un pro
On tague au build (-t moncompte/mon-app:1.2.0) et on ajoute des alias utiles (1.2, latest en dev). Règle : un tag immuable par livraison (1.2.0), jamais réécrit ; les alias mouvants ne servent qu'au confort. La prod tire toujours le tag figé et testé, jamais latest. Idir fige la 1.2.0 et laisse la 1.2 suivre les correctifs.
2. Publier : login, push, pull
docker login authentifie, docker push moncompte/mon-app:1.2.0 publie, n'importe quelle machine la récupère par pull. Le nom compte/image:tag est l'adresse complète : sans compte (namespace), le push est refusé. Idir pousse ses deux tags puis, sur une autre machine (ou après un rmi local), tire la 1.2.0 et la lance : la preuve que l'image voyage.
3. Public ou privé ?
Par défaut sur le Hub, un dépôt est public : parfait pour l'open source, interdit pour le code interne. Pour l'interne, dépôt privé (Hub payant, GHCR, registre d'entreprise). Et jamais de secret dans l'image : un secret COPY ou ENV reste dans les couches et part au push — un push public est irréversible. Idir contrôle la visibilité avant chaque push et garde les secrets hors image (2.5).
🔎 Exemple concret — 🔎 Exemple concret — Publier la 1.2.0
L'image d'Idir, de la machine locale au registre :
docker build -t moncompte/mon-app:1.2.0 -t moncompte/mon-app:1.2 .
docker login
docker push moncompte/mon-app:1.2.0
docker push moncompte/mon-app:1.2
# sur une autre machine :
docker pull moncompte/mon-app:1.2.0Lecture : la 1.2.0 est figée et testée, la 1.2 suit les correctifs, latest reste un confort de dev.
Leçon : la prod tire la 1.2.0, jamais latest — reproductible et traçable.
Vocabulaire de la section
- Namespace
- Le compte ou l'organisation devant l'image (moncompte/mon-app) : l'adresse complète exigée pour pousser.
Exemple simple : Idir préfixe par son compte dès le build.
Ce que ce n'est pas : le tag de version seul.
Réflexe : pas de namespace = pas de push.
- Tag immuable
- Une version figée et jamais réécrite (1.2.0) : ce que la prod tire pour rester reproductible.
Exemple simple : Idir fige la 1.2.0 testée pour la prod.
Ce que ce n'est pas : un alias mouvant comme latest.
Réflexe : une livraison = un tag figé.
- Alias
- Un tag mouvant de confort (1.2, latest) qui suit les correctifs ; pratique en dev, interdit comme référence de prod.
Exemple simple : Idir laisse 1.2 suivre les patchs, latest pour les essais.
Ce que ce n'est pas : la référence déployée en production.
Réflexe : confort en dev, jamais en prod.
- push / pull
- Publier vers le registre (push) et récupérer depuis le registre (pull) : le trio du partage avec login.
Exemple simple : Idir pousse la 1.2.0 et la tire sur une autre machine.
Ce que ce n'est pas : un build local jamais partagé.
Réflexe : login, push, pull : partager versionné.
En pratique — En pratique — Publier votre app
- Rebuildez votre app avec deux tags (1.0.0 figé et 1.0 alias).
- Connectez-vous au registre (docker login).
- Poussez les deux tags (docker push), visibilité vérifiée.
- Sur une autre machine (ou après rmi), tirez la 1.0.0 et lancez-la.
Script prêt à dire — imposer le tag figé (30 s)
« On ne déploie plus latest : chaque livraison a son tag figé, testé, jamais réécrit — la 1.2.0 tourne en prod, on sait exactement quoi. Les alias comme 1.2 ou latest restent pour le confort en dev. Build ici, pull ailleurs, même version partout. »
À dire en montrant le pull de la 1.2.0 d'Idir sur une seconde machine.
Modèle copier-coller — taguer et publier
docker build -t moncompte/mon-app:1.2.0 -t moncompte/mon-app:1.2 .
docker login
docker push moncompte/mon-app:1.2.0
docker push moncompte/mon-app:1.2
docker pull moncompte/mon-app:1.2.0Push refusé
Push « denied » : Idir vérifie le login, le namespace compte/image et ses droits sur le dépôt.
Interne en public
Code interne poussé en dépôt public : Idir repasse en privé (ou registre d'entreprise) avant le push.
Tag réécrit
Une 1.2.0 repoussée différemment après déploiement : Idir fige 1.2.1 au lieu de réécrire l'histoire.
Push à chaque commit
Chaque essai poussé pollue le registre : Idir ne pousse que les versions testées, la CI triera (niveau 4).
✓ Bonnes pratiques
- Un tag immuable par livraison, jamais réécrit.
- Préfixer par le compte dès le build.
- Vérifier la visibilité (public/privé) avant le push.
✗ Pièges fréquents
- Réécrire un tag déjà déployé (dérive de prod).
- Pousser en public du code interne.
- Inclure des secrets dans l'image poussée.
Points clés à retenir
- On tague au build, compte inclus (adresse complète).
- Immuable par livraison (1.2.0), alias (1.2, latest) pour le confort.
- login → push → pull : le trio du partage versionné.
- Jamais de secret dans une image poussée (push public irréversible).
Défi 48h — appliquez demain
Publiez votre image maigre (2.2) : build à deux tags (1.0.0 + 1.0), login + push visibilité vérifiée, puis pull + run de la 1.0.0 ailleurs.
- Je peux taguer au build (immuable + alias, compte inclus).
- Je sais publier (login, push) et récupérer (pull) ailleurs.
- Je contrôle public/privé et j'exclus les secrets avant tout push.
Questions fréquentes
Pourquoi mon push est refusé (denied) ?
Souvent un nom sans namespace, ou pas de login, ou pas de droits sur le dépôt. Vérifiez docker login, le nom compte/image:tag et vos droits d'écriture sur le dépôt avant de recommencer.
Faut-il pousser à chaque commit ?
Non : on pousse les versions testées (tags figés), pas chaque essai. La CI (niveau 4) automatisera ce tri : elle build à chaque commit mais ne publie que les versions validées.
Quelle politique de tags pour la production ?