Images immuables et registre

Prérequis : cours 2.3 (cycle de vie) et 5.1 (pipeline).

Pourquoi

Si l'image change entre le test et la prod, le test ne prouve rien. L'immuabilité (un tag = un contenu figé pour toujours) fait du registre — le coffre à images (Docker Hub, GitLab Registry…) — une source de vérité : on sait exactement ce qui tourne et on peut y revenir.

Concepts

• Tag immuable (1.4.2) : seul déployable en prod. latest : raccourci dev interdit en prod (il change chaque semaine : laquelle tourne ?). Tags de CI (build-123) : pour tester une MR, nettoyés ensuite.
• Reproductible : rebuildable à l'identique dans 6 mois. Ça exige : base épinglée (node:24-alpine, pas node:alpine), dépendances lockées (package-lock.json commité).
• Pousser/tirer : la CI pousse (docker push), le serveur tire (docker pull) puis up -d. Personne ne build sur le serveur : pas d'outils, pas de sources, pas de surprise.

Exemple : le cycle et le retour

main → validate → tag v1.4.2 → build + push 1.4.2 → pull + up -d → 3 voyants verts

Nettoyage : docker image prune -a --filter "until=720h", en gardant l'ancien tag : incident à 22h, suspicion release → pull 1.4.1 + up -d en 2 minutes, diagnostic demain. Sans lui : rebuild + stress + 40 minutes.

Cas réel

Rebuild « à l'identique » 6 mois plus tard avec node:alpine flottant : Node 22 au lieu de 24, une dépendance native qui ne compile plus, 3 heures perdues. Avec base épinglée + lock : rebuild parfait du premier coup.

Pièges

• Pruner juste avant un rollback potentiel : on jette sa propre bouée.
• Tag écrasé (« on repousse 1.4.2 corrigée ») : immuable veut dire immuable — sinon c'est 1.4.3.
• En dev, oublier --env-file .env.dev : le compose doit échouer (variables DEV_* requises) plutôt que pomper la conf prod.

À retenir

Tags immuables jamais écrasés, bases épinglées, même image du test à la prod, ancien tag gardé, 3 voyants verts.