Projet : passer Mini-Carnet à Compose et diagnostiquer une panne

Étape 7 : ajouter Redis et la persistance

Reprenez le dossier projet-mini-carnet du guide précédent. Mettez à jour server.js et package.json pour utiliser Redis comme au guide 24, si ce n'est pas déjà fait dans vos fichiers.

Étape 8 : écrire compose.yaml

Écrivez un fichier compose.yaml complet, avec les deux services mini-carnet et redis, un volume pour protéger les données de Redis, sans avoir besoin de déclarer de réseau explicitement.

Indice

Regardez du côté des guides 23, 24 et 25. Le service mini-carnet a besoin de build, ports, environment et depends_on ; le service redis a besoin de image et volumes.

Étape 9 : tester

Lancez docker compose up -d --build, visitez la page plusieurs fois, puis relancez docker compose down suivi de docker compose up -d. Le compteur doit continuer là où il s'était arrêté, comme au guide 25.

Étape 10 : diagnostiquer une panne plausible

Remplacez maintenant votre compose.yaml par celui-ci, volontairement modifié, et relancez docker compose up -d --build :

compose.yaml (version cassée)

services:

mini-carnet:

build: .

ports:

- "4000:3000"

environment:

PORT: "4000"

APP_NAME: Le carnet de Sam

depends_on:

- redis

redis:

image: redis:alpine

volumes:

- redis-data:/data

volumes:

redis-data:

Ouvrez http://localhost:4000 : la page ne répond pas, ou affiche une erreur de connexion. Avant de continuer à lire, essayez de diagnostiquer vous-même, avec les outils du guide 19.

Démarche de diagnostic

Premier réflexe face à une application qui ne répond pas : consulter ses logs.

terminal

$ docker compose logs mini-carnet

Le carnet de Sam est démarré sur le port 4000

L'application a bien démarré, et confirme elle-même écouter sur le port 4000, pas 3000. C'est la variable d'environnement PORT: "4000", ajoutée dans cette version cassée, qui a changé le port réellement utilisé à l'intérieur du conteneur.

Or la ligne ports: - "4000:3000" relie toujours le port 4000 de votre ordinateur au port 3000 du conteneur, un port sur lequel plus rien n'écoute désormais. C'est exactement la même logique que le guide 16 : les deux nombres de -p (ou de ports dans Compose) doivent rester cohérents avec le port réellement écouté par l'application à l'intérieur du conteneur.

Corriger la panne

Deux corrections sont possibles, et les deux sont valides : soit retirer la variable PORT pour revenir au port 3000 par défaut, soit aligner le second nombre de ports sur 4000 pour qu'il corresponde au nouveau port interne. La seconde option :

compose.yaml (corrigé)

ports:

- "4000:4000"

environment:

PORT: "4000"

Relancez docker compose up -d --build. La page répond de nouveau.

Bravo

Vous venez de dockeriser une application de bout en bout, de comprendre pourquoi un service annexe a besoin d'un réseau et d'un volume, et de diagnostiquer puis corriger une vraie panne, exactement comme cela arrive sur un vrai projet. C'est précisément l'objectif que ce parcours s'était fixé au tout premier guide.

Vérifiez que vous avez compris

Dans la version cassée, docker compose logs a montré que l'application avait bien démarré, sans erreur visible dans son propre code. Est-ce que ça écarte l'hypothèse d'un problème de configuration Docker ?

Non, c'est même l'inverse de ce que ce guide vient de montrer. Une application peut démarrer parfaitement bien, sans la moindre erreur dans son propre code, tout en restant inaccessible à cause d'une configuration Docker incohérente autour d'elle, ici un port mal aligné entre la variable d'environnement et la correspondance de ports. Les logs applicatifs et la configuration Docker sont deux sources de vérité distinctes, qu'il faut souvent croiser pour diagnostiquer une panne.