Registre et cycle de vie des images

Prérequis : cours 2.1 (multi-stage) et compose production.

Pourquoi

« Ça marchait sur ma machine » meurt le jour où l'image testée est l'image déployée. Le registre (le coffre à images : Docker Hub, GitLab Registry…) est la source de vérité : la CI y pousse des images immuables, le serveur ne fait que tirer.

Concepts

• Tag immuable (1.4.2) : un contenu figé pour toujours, déployable et rollbackable. À l'inverse, latest change chaque semaine : on ne sait jamais ce qui tourne.
• Appel métier : une requête qui exerce la vraie logique (ex. GET /api/health qui teste aussi la base), par opposition au simple ping. C'est lui qui prouve que « ça marche ».
• Reproductible : rebuildable à l'identique dans 6 mois (bases épinglées, dépendances lockées).

Exemple : le cycle, bout à bout

1. Merge sur main → validate (lint, tests, build).
2. Tag v1.4.2 → build_images → push registry/...:1.4.2.
3. Serveur : docker compose pull && docker compose up -d (il ne build jamais).
4. Preuves : docker ps (healthy), curl public, appel métier.
5. Nettoyage : docker image prune -a --filter "until=720h" — en gardant l'ancien tag pour le retour.

Cas réel

Incident à 22h, cause inconnue, suspicion sur la release : 1.4.2 tourne, 1.4.1 est gardée. Rollback = pull 1.4.1 + up -d en 2 minutes, diagnostic demain. Sans l'ancien tag : rebuild + stress + 40 minutes.

Pièges

• La version du tag ≠ version du code (1.4.3 qui contient le code de 1.4.2) : le pipeline doit vérifier l'égalité.
• Pruner juste avant un rollback potentiel : on jette sa propre bouée.
• En dev, oublier --env-file .env.dev : le compose doit échouer (variables DEV_* requises) plutôt que pomper la conf prod.

À retenir

Même image du test à la prod, tags immuables, serveur qui tire, ancien tag gardé, appel métier comme preuve.