Composition multi-services

L'application démarre, se connecte à la base, et échoue : ECONNREFUSED. On relance, et cette fois tout marche. Le diagnostic est immédiat — la base n'était pas encore prête — et le correctif qui vient à l'esprit est presque toujours le même :

1command: sh -c "sleep 10 && node serveur.js"

Il fonctionne sur le portable de son auteur. Il échoue en intégration continue, où la machine est plus lente. On passe à sleep 30, ce qui ralentit chaque démarrage de trente secondes et échoue quand même le jour où la base met trente-cinq secondes à ouvrir ses fichiers.

Ce chapitre fait tenir plusieurs conteneurs ensemble, et le fait proprement — ce qui commence par renoncer au sleep.

Un fichier, une commande

docker compose décrit une application à plusieurs services dans un fichier versionné, puis la démarre entière.

1services:2  appli:3    build: .4    ports:5      - "8080:3000"6    environment:7      DATABASE_URL: postgres://app:secret@basededonnees:5432/app8      REDIS_URL: redis://cache:63799    depends_on:10      basededonnees:11        condition: service_healthy12 13  basededonnees:14    image: postgres:16-alpine15    environment:16      POSTGRES_PASSWORD: secret17    volumes:18      - donnees:/var/lib/postgresql/data19    healthcheck:20      test: ["CMD-SHELL", "pg_isready -U app"]21      interval: 5s22      retries: 1023 24  cache:25    image: redis:7-alpine26 27volumes:28  donnees:

Quatre points se lisent directement dans ce fichier.

Les noms de services sont des noms d'hôtes. L'application atteint la base à basededonnees:5432 : Compose crée un réseau et y inscrit chaque service sous son nom. C'est la découverte de service du chapitre 3, et elle explique pourquoi la chaîne de connexion ne contient aucune adresse IP.

Seul ce qui doit sortir est publié. appli publie un port, la base et le cache n'en publient aucun : ils sont joignables entre conteneurs et invisibles de l'extérieur. Publier le port de la base « pour pouvoir s'y connecter » est le réflexe à combattre — c'est une base exposée sur la machine.

Le volume nommé porte les données. Il survit à docker compose down, contrairement aux conteneurs, et c'est bien le but.

build contre image. On construit ce qu'on écrit, on tire ce qu'on consomme. En production, l'application aussi sera une image tirée d'un registre — construite par le pipeline du chapitre 5.

Le vrai problème : l'ordre de démarrage

C'est le cœur du chapitre, et il faut être précis sur ce que depends_on fait.

depends_on seul n'attend pas que le service soit prêt. Il attend qu'il soit démarré, c'est-à-dire que son processus existe. Or un PostgreSQL démarré met encore quelques secondes à accepter les connexions. La dépendance est respectée, et l'application échoue quand même.

D'où la sonde de santé (healthcheck) : une commande que Docker exécute périodiquement dans le conteneur, et dont le code de retour dit si le service est utilisable. Combinée à condition: service_healthy, elle donne enfin l'attente correcte.

1healthcheck:2  test: ["CMD-SHELL", "pg_isready -U app"]3  interval: 5s        # tous les 5 secondes4  timeout: 3s         # au-delà, c'est un échec5  retries: 10         # 10 échecs d'affilée → conteneur « unhealthy »6  start_period: 20s   # délai de grâce initial, sans compter les échecs

Trois qualités d'une bonne sonde, qu'on retrouvera au chapitre 9 avec Kubernetes. Elle doit tester ce dont l'appelant a besoin — pg_isready teste l'acceptation de connexions, pas seulement l'existence du processus. Elle doit être rapide et sans effet de bord : une sonde qui écrit en base ou interroge un service tiers transforme un incident distant en panne locale. Et start_period doit couvrir le démarrage normal, faute de quoi un service lent est déclaré malade avant d'avoir eu sa chance.

Reste une nuance essentielle, et c'est celle que les étudiants manquent : la sonde règle le démarrage, pas la vie du système. En production, une base redémarre, un réseau se coupe, un service devient indisponible dix secondes. Une application qui ne survit pas à cela est fragile quel que soit l'ordre de démarrage.

La réponse robuste est donc dans l'application : tenter la connexion, échouer, réessayer avec un délai croissant. Compose garantit un démarrage propre ; la reprise sur erreur, elle, est une propriété du code. Les deux se cumulent, et la seconde est la seule qui tienne en production.

Un environnement de développement reproductible

C'est le bénéfice quotidien du chapitre, et il se mesure à une phrase : git clone puis docker compose up, et l'on a un environnement complet qui tourne.

Ce que cela remplace : une page de documentation d'installation, périmée, qui demande la bonne version de PostgreSQL, la bonne version de Redis, et trois variables d'environnement dont l'une n'est mentionnée nulle part. Un nouvel arrivant devient productif en dix minutes au lieu de deux jours, et surtout tout le monde travaille sur les mêmes versions — ce qui supprime une classe entière de bogues « chez moi ça marche ».

Deux mécanismes servent à adapter sans dupliquer. Les fichiers de surcharge : compose.override.yml est lu automatiquement en plus du fichier principal, ce qui permet de monter le code en développement — pour éditer sans reconstruire — sans polluer la définition commune. Et les profils, qui permettent de ne démarrer qu'une partie des services : l'outillage d'observation du chapitre 10 n'a pas à tourner pour écrire une fonctionnalité.

Déboguer un conteneur

Quatre commandes suffisent à traiter la quasi-totalité des situations, et l'ordre compte.

docker compose logs -f service en premier, toujours. Un conteneur qui s'arrête immédiatement a presque toujours écrit pourquoi.

docker compose ps montre l'état et le code de sortie. Un service qui redémarre en boucle y est visible, et le code de sortie oriente : 0 arrêt normal — donc le processus principal s'est terminé, ce qui est une erreur de conception —, 1 erreur applicative, 137 tué par SIGKILL, typiquement une limite de mémoire dépassée.

docker compose exec service sh ouvre un interpréteur dans le conteneur en marche. C'est là qu'on vérifie ce que l'application voit vraiment : variables d'environnement présentes, fichier de configuration au bon endroit, base joignable par son nom.

docker inspect donne la configuration effective — réseaux, volumes, variables — quand on soupçonne un écart entre ce qui est écrit et ce qui tourne.

Un piège récurrent mérite d'être nommé : un conteneur s'arrête quand son processus principal s'arrête. Une image dont la commande est un script qui lance un service en arrière-plan puis se termine produit un conteneur qui « ne veut pas rester allumé ». Il n'y a rien à réparer côté Docker : le processus doit tourner au premier plan.

À vous

L'exercice simule le démarrage d'une pile à plusieurs services et rend visible ce qui, en vrai, se manifeste par un message d'erreur intermittent.

D'abord la course : trois services, des temps de démarrage variables, et une application qui se connecte dès qu'elle est lancée. Vous ferez varier la vitesse de la machine et compterez les échecs — c'est ce qui explique qu'un sleep 10 marche sur un portable et échoue en intégration.

Ensuite les trois correctifs, comparés sur les mêmes scénarios : le sleep fixe, la sonde de santé, et la reprise avec délai croissant côté application. Vous constaterez que seule la dernière survit au cas « la base redémarre en cours de vie », que les deux autres ne traitent pas du tout.

La dernière partie résout l'ordre de démarrage à partir du graphe de dépendances, et détecte le cas où quelqu'un a introduit un cycle — ce que Compose refuse, avec un message qu'il vaut mieux savoir lire.

// ── Une pile à trois services ─────────────────────────────────────────────
// pret : instant (en secondes) où le service accepte des connexions.
const PILE = {
  cache:         { pret: 0.4, depend: [] },
  basededonnees: { pret: 6.0, depend: [] },
  appli:         { pret: 0.3, depend: ["basededonnees", "cache"] },
};

// Un démarrage : l'appli se connecte dès qu'elle est lancée.
function demarrer(pile, strategie, lenteur, evenements = []) {
  const journal = [];
  const pret = {};
  for (const [nom, s] of Object.entries(pile)) pret[nom] = s.pret * lenteur;

  let instantAppli;
  if (strategie.type === "naif") instantAppli = pret.appli;
  if (strategie.type === "sleep") instantAppli = strategie.secondes;
  if (strategie.type === "healthy") instantAppli = 0;   // ← à écrire
  if (strategie.type === "reprise") instantAppli = pret.appli;

  // L'application tente de se connecter ; selon la stratégie, elle réessaie.
  let t = instantAppli, essais = 0, connecte = false, attente = 0.5;
  while (essais < 8) {
    essais++;
    const baseDisponible = t >= pret.basededonnees && !evenements.some(
      (e) => e.quoi === "panne base" && t >= e.de && t < e.a);
    journal.push("t=" + t.toFixed(1) + "s  essai " + essais +
                 (baseDisponible ? "  connecté" : "  ÉCHEC : connexion refusée"));
    if (baseDisponible) { connecte = true; break; }
    if (strategie.type !== "reprise") break;      // les autres abandonnent
    t += attente; attente *= 2;                    // délai croissant
  }
  return { connecte, t, essais, journal };
}

// ── À VOUS ────────────────────────────────────────────────────────────────
// 1. Écrivez la stratégie « healthy » : l'appli démarre quand la base est
//    RÉELLEMENT prête, quelle que soit la lenteur de la machine.
// 2. Comparez les quatre stratégies sur une machine rapide (lenteur 1) puis
//    lente (lenteur 3). Laquelle tient dans les deux cas ?
// 3. Ajoutez l'événement « la base redémarre à t = 40 s pendant 8 s ».
//    Laquelle des quatre survit ?
// 4. Écrivez l'ordre de démarrage à partir du graphe, et détectez un cycle.

const r = demarrer(PILE, { type: "naif" }, 1);
console.log(r.journal.join("\n"));

En travaux pratiques

Ce que la suite en fait

Le bloc III automatise ce que ce chapitre a rendu reproductible : le pipeline du chapitre 5 construira l'image du chapitre 3 et lancera les tests dans une pile Compose, ce qui donne des tests d'intégration réalistes sans machine dédiée.

Et les sondes de santé reviendront au chapitre 9, où elles cessent d'être un confort de démarrage pour devenir le mécanisme qui décide si un exemplaire reçoit du trafic. C'est la même idée, avec des conséquences bien plus grandes.

À retenir