Docker Compose et l'application complète

Objectifs

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

• lire un compose.yaml section par section ;
• orchestrer application + base + volumes ;
• reconnaître votre environnement Devmind.

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

Le problème du multi-conteneurs

Trois commandes run avec réseaux, volumes et variables à synchroniser : ingérable à la main. Compose décrit tout dans un fichier versionné :

services:
  postgres:
    image: postgres:17
    environment:
      POSTGRES_DB: cours_full_stack
      POSTGRES_USER: cours
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}   # vient du .env
    ports:
      - "5433:5432"          # hôte:conteneur
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U cours"]
      interval: 5s

  uploads:
    image: alpine
    volumes: [course-uploads:/data/uploads]

volumes:
  pgdata:
  course-uploads:

Les sections essentielles

Le healthcheck est crucial : « depends_on » seul attend juste le DÉMARRAGE, pas la disponibilité. Avec la condition healthy, votre API n'essaie de se connecter que quand PostgreSQL accepte réellement les connexions.

Le cycle de vie

docker compose up -d        # créer/démarrer tout
docker compose ps           # l'état de chaque service
docker compose logs -f api  # suivre un service
docker compose exec api sh  # entrer dedans
docker compose down         # arrêter (les VOLUMES restent)
docker compose down -v      # arrêter ET effacer les données !

Votre environnement Devmind, relu

compose.yaml Devmind :
├── postgres : 17, port hôte 5433 (5432 occupé par le service natif Windows),
│              volume persistant
├── uploads  : volume course-uploads monté sur /data/uploads
└── .env     : POSTGRES_* et DATABASE_URL lus par les deux apps

Tout ce que vous venez d'étudier s'y retrouve : réseau interne (l'API parle à postgres:5432 via DATABASE_URL), publication sélective (seul 5433 sort), persistance (volumes), secrets hors fichier versionné.

Et le frontend dans tout ça ?

Le programme présente Compose avec le trio classique frontend/backend/base. Dans notre architecture, le choix est assumé et différent : le frontend n'est pas un process à conteneuriser en dev. Il s'agit de fichiers statiques (HTML/CSS/JS construits au chapitre 38), servis soit par un simple serveur statique, soit — en production — directement par le reverse proxy Caddy (chapitre 48), qui distribue dist/ et proxifie /api.

Compose orchestre donc ici les processus qui DOIVENT tourner en continu : l'API, PostgreSQL et le volume d'uploads. Le trio du programme reste réalisable tel quel (un conteneur nginx pour le front, un pour l'API, un pour la base) — vous avez maintenant toutes les pièces pour l'écrire en exercice bonus.

Exercice

1. Écrivez le compose complet de votre todo : api + postgres + volume + healthcheck.
2. Démarrez, vérifiez que l'API répond et que les données survivent à down/up.
3. Cassez volontairement le mot de passe : observez le comportement du healthcheck.

Résumé

• Compose = l'orchestration déclarative, versionnée, reproductible.
• Healthchecks + depends_on : l'ordre qui compte vraiment.
• down garde les volumes ; down -v est destructeur.