Compose pour la production

Objectifs

À la fin de cette leçon, vous saurez :

• superposer des fichiers compose (dev/prod) ;
• configurer restart policies, limites et logs rotatifs ;
• déployer une mise à jour sans coupure inutile.

🔗 Pour vous rafraîchir la mémoire : variables d'environnement du shell

La superposition : base commune + surcharges

docker compose -f compose.yaml -f compose.prod.yaml up -d

Compose fusionne dans l'ordre : le second fichier complète/écrase le premier.

# compose.yaml (commun)
services:
  api:
    build: .
    environment:
      DATABASE_URL: ${DATABASE_URL}
    depends_on:
      postgres:
        condition: service_healthy

# compose.prod.yaml (spécifique production)
services:
  api:
    image: registry.exemple.fr/todo-api:1.4.2   # image construite en CI, PAS de build local
    restart: unless-stopped
    deploy:
      resources:
        limits:
          memory: 512m
          cpus: "1.5"
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

Pourquoi l'image vient d'un registry plutôt que d'un build local : la prod exécute exactement ce que la CI a testé et signé — jamais « ce qui traîne sur le serveur ». C'est la continuité du pipeline du chapitre déploiement.

Les réglages qui manquent souvent

Réglage	Sans lui	Avec
restart: unless-stopped	app morte après crash/reboot	redémarrage automatique
deploy.resources.limits	un conteneur affamé tue les voisins	plafond garanti
logging max-size/max-file	disque rempli par les logs	rotation bornée

Trois lignes chacun, trois incidents classiques évités.

Mise à jour sans mauvaise surprise

docker compose pull api          # récupérer la nouvelle image
docker compose up -d api         # recrée SEULEMENT ce conteneur
docker compose ps                # vérifier healthy
docker compose logs -f api       # surveiller le démarrage

up -d api ne touche ni postgres ni les volumes. Couplé au SIGTERM gracieux du chapitre Docker, le redémarrage est propre. Rollback :

# modifier le tag d'image dans compose.prod.yaml vers la version précédente
docker compose up -d api

Le healthcheck qui protège le déploiement

healthcheck:
  test: ["CMD", "wget", "-qO-", "http://localhost:3000/api/health"]
  interval: 10s
  retries: 3
  start_period: 15s

start_period laisse le temps de démarrer sans compter les échecs ; ensuite, 3 échecs = unhealthy = visible immédiatement dans docker ps. Votre script de déploiement peut même attendre le statut healthy avant de déclarer succès.

Exercice

1. Structurez votre todo en compose.yaml + compose.dev.yaml + compose.prod.yaml.
2. Ajoutez limites, rotation de logs et healthcheck ; vérifiez avec inspect et docker ps.
3. Déployez une v2 puis simulez un rollback vers v1.
4. Pourquoi ne pas builder directement sur le serveur de prod ?

Résumé

• Superposition de fichiers : base partagée, environnements spécialisés.
• Image du registry + restart + limites + rotation = prod sérieuse.
• up -d <service> pour une mise à jour ciblée ; rollback = retag.