Conteneurs et registres : de l'image au tag

L'image : un artefact reproductible

Un conteneur package le code + ses dépendances + son runtime en une image immuable, qui tourne identiquement en local, en CI, en prod. Le Dockerfile de cette plateforme (et des projets étudiés) suit les règles qui comptent :

FROM node:22-alpine                    # base légère, version pinée (pas :latest)
WORKDIR /app
COPY package.json package-lock.json ./  # 1. deps d'abord (change rarement)
RUN npm ci                              #    → layer caché tant que le lock ne bouge pas
COPY . .                                # 2. code ensuite (change souvent)
RUN npm run build
CMD ["node", ".output/server/index.mjs"]

L'ordre des layers EST l'optimisation : ce qui change rarement (dépendances) avant ce qui change souvent (code). Un rebuild ne réinstalle pas les deps si seul le code a changé — c'est ce qui rend nos deploys rapides (et ce qu'on a payé quand on l'ignorait). Le multi-stage pousse plus loin : un stage build lourd (compilateur, dev-deps), un stage final qui ne copie que l'artefact — l'image finale reste mince (rappel cours Stack IA : les poids de modèle HORS image).

Le registre : où vivent les images

Une image buildée est poussée vers un registre (Scaleway, AWS ECR, GitLab, GCP Artifact Registry) d'où le runtime la tire au déploiement. Les règles d'hygiène :

• tags immuables : :v15, ou mieux le SHA du commit / un semver 0.0.25-<sha> (les projets étudiés) — jamais :latest en prod (leçon vécue : l'alias flottant OCR qui changeait les scores sans déploiement !). Un tag = un artefact figé, traçable, rollbackable ;
• le login au registre (docker login) : credentials en secret, jamais en clair ;
• le déploiement = pointer un tag : container update image=…:v15 puis deploy — exactement le geste répété tout au long de la construction de cette plateforme.

Le lien avec la reproductibilité

L'image tague le trio « code + deps + runtime » à un instant T ; le registre l'archive ; le déploiement en sélectionne une version. C'est la reproductibilité du cours ML (module 1) rendue opérationnelle : n'importe quel déploiement passé est re-déployable à l'identique en pointant son tag. Le rollback n'est pas une procédure d'urgence complexe — c'est deploy sur le tag précédent.