3.2Piloter le stack : up, down, logs, ps
L'essentiel en 30 secondes
- up -d crée tout : réseaux et volumes, build/pull des images, démarrage dans l'ordre — --build force la reconstruction après un changement de code.
- Observer par service, préfixé compose : compose ps liste le stack, logs -f bdd suit un service, exec web sh entre dedans — jamais le docker ps global qui mélange tout.
- down garde, -v détruit : down stoppe et supprime conteneurs + réseau en gardant les volumes ; down -v efface aussi les volumes — reset volontaire uniquement.
Mini-cas filé — Idir et le down de trop
Idir, devops junior à Alger, « nettoie » son poste avec un docker compose down -v avant une démo — et efface la base de test remplie la veille par son collègue. Il adopte le cycle sûr : up -d, compose ps, logs -f bdd, exec web sh, down SANS -v par défaut. Au second up, la base est intacte : il a compris que down seul est un arrêt sûr, et que -v est un reset qui se décide, jamais un nettoyage.
Ce même cas revient dans le cours, le schéma, le script et le défi 48h.
1. up : construire et démarrer, voir : ps, logs, exec
docker compose up -d crée les réseaux et volumes, télécharge ou construit les images, puis démarre les services dans l'ordre — en fond (-d). Sans -d, les logs s'attachent au terminal : pratique en développement pour voir naître le stack, bloquant en service. Après un changement de code, --build force la reconstruction : sans lui, Compose réutilise l'image existante et votre nouveau code n'est pas pris.
Pour VOIR : docker compose ps liste les conteneurs DU projet, logs -f bdd suit les journaux d'un service en direct (sans nom, tout le stack, chaque ligne préfixée), exec web sh entre dans un conteneur. Règle d'or : toujours préfixer par compose — docker ps mélange tous les projets de la machine et fait diagnostiquer le mauvais conteneur.
2. down : arrêter sûr par défaut, reset sur décision
docker compose down stoppe et supprime conteneurs + réseau, mais GARDE les volumes : vos données survivent, le second up les retrouve. C'est l'arrêt sûr, celui du quotidien. down -v efface EN PLUS les volumes : reset volontaire pour repartir de zéro (base de test à réinitialiser), à réserver à un stack jetable ou assumé.
En cas de doute : sans -v. Le drame classique — down -v « pour nettoyer » avant une démo — s'évite par ce défaut. Idir s'est fait une règle tatouée : down seul pour arrêter, -v uniquement quand il peut citer ce qu'il accepte de perdre. Le cycle up → observer → down (sans -v) est sûr par construction.
Le nettoyage de trop
Nettoyer, c'est down seul ; -v, c'est déménager.
🔎 Exemple concret — Cycle complet : la base survit au redémarrage
Idir enchaîne le cycle sûr sur son stack web + base.
docker compose up -d
docker compose ps
docker compose logs -f bdd
docker compose exec web sh
docker compose down
docker compose up -d # les données sont là
# Reset VOLONTAIRE sur stack jetable uniquement :
# docker compose down -vLecture : le second up retrouve la base intacte — down seul préserve.
Leçon : down sans -v = arrêt sûr ; avec -v = reset décidé, jamais un nettoyage.
Vocabulaire de la section
- up
- Créer et démarrer tout le stack : réseaux, volumes, images (build/pull), conteneurs dans l'ordre — -d pour le fond.
Exemple simple : Le up -d d'Idir chaque matin sur la maquette.
Ce que ce n'est pas : démarrer chaque conteneur à la main dans le bon ordre.
Réflexe : --build après chaque changement de code.
- down
- Stopper et supprimer conteneurs + réseau en GARDANT les volumes : l'arrêt sûr du quotidien.
Exemple simple : Le down du soir d'Idir, base intacte le lendemain.
Ce que ce n'est pas : un arrêt qui efface la base.
Réflexe : down seul par défaut, toujours.
- down -v
- down + suppression des VOLUMES : reset volontaire pour repartir de zéro, jamais un nettoyage.
Exemple simple : Le reset assumé d'une base de test jetable.
Ce que ce n'est pas : un « nettoyage » avant une démo avec de vraies données.
Réflexe : citer ce qu'on accepte de perdre avant tout -v.
- ps (compose)
- Lister les conteneurs DU projet uniquement — le périmètre juste pour diagnostiquer.
Exemple simple : compose ps montre le stack d'Idir, rien d'autre.
Ce que ce n'est pas : docker ps global qui mélange tous les projets.
Réflexe : toujours préfixer par compose.
- logs -f / exec
- Suivre les journaux d'un service en direct (logs -f bdd) et entrer dans un conteneur (exec web sh).
Exemple simple : Idir suit la base au démarrage puis inspecte le web.
Ce que ce n'est pas : deviner la panne sans lire les journaux.
Réflexe : ps repère, logs accuse, exec vérifie.
En pratique — Maîtriser le cycle sans risquer les données
- Démarrez votre stack en -d et listez-le avec compose ps (comparez avec docker ps global).
- Suivez les logs de la base (logs -f bdd) et entrez dans le web (exec web sh).
- Stoppez avec down, relancez : vérifiez que les données ont survécu.
- Testez down -v sur un stack JETABLE uniquement, et constatez la perte — une fois suffit.
Script prêt à dire — expliquer le cycle à un nouvel arrivant (30 s)
« up -d pour démarrer, compose ps et logs pour observer ton stack — jamais le ps global. Et pour arrêter : down seul, les données survivent. Le -v, c'est un reset qui efface les volumes : uniquement sur du jetable, jamais pour nettoyer. »
À dire en onboarding ; faire exécuter le cycle une fois ensemble.
Modèle copier-coller — stack jetable d'entraînement
# Stack JETABLE : pour vous entraîner (down -v) sans risque.
services:
web:
image: nginx:1.27
ports:
- "8080:80"
networks:
- bacnet
bdd:
image: postgres:16.4
environment:
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
volumes:
- bacdata:/var/lib/postgresql/data
networks:
- bacnet
volumes:
bacdata:
networks:
bacnet:Indépendant
Le cycle up → compose ps/logs → down seul et vos démos survivent aux redémarrages.
PME à Alger
Idir forme son collègue : down seul le soir, base intacte le matin.
Équipe projet
Règle d'équipe : -v interdit hors stack jetable nommé (bac, test).
Débutant
Cette semaine : un cycle complet + un reset -v sur du jetable, pour sentir la différence.
✓ Bonnes pratiques
- Toujours compose + verbe (ps, logs, exec) pour rester dans le périmètre projet.
- down sans -v par défaut ; -d en service, attaché seulement en debug.
- Ajoutez --build après chaque changement de code, ou montez le code en bind en dev.
✗ Pièges fréquents
- down -v « pour nettoyer » : les données du projet sont effacées.
- docker ps au lieu de compose ps : on diagnostique le mauvais conteneur.
- Oublier --build après un changement de code : l'ancienne image tourne toujours.
Points clés à retenir
- UP crée tout (-d en fond) ; --build force la reconstruction après changement de code.
- PS / LOGS / EXEC par service, toujours préfixés compose (périmètre projet).
- DOWN garde les volumes (arrêt sûr) ; -v les détruit (reset volontaire uniquement).
- Le cycle up → observer → down (sans -v) est sûr par construction.
Défi 48h — appliquez demain
Exécutez 1 cycle complet sur votre stack (up -d, ps, logs, exec, down, re-up) et prouvez que les données survivent.
- Je démarre en fond et reconstruis avec --build quand le code change.
- J'observe par service dans le périmètre compose.
- J'arrête avec down seul ; -v seulement sur du jetable assumé.
Questions fréquentes
up ne prend pas mon nouveau code, pourquoi ?
Parce que l'image n'est PAS reconstruite : Compose réutilise l'image existante par défaut. Ajoutez --build (up -d --build) après chaque changement de code, ou montez le code en bind mount en développement pour un rechargement direct. Vérifiez avec compose ps que le conteneur vient d'être recréé.
Comment suivre plusieurs services à la fois ?
Lancez docker compose logs -f sans nom de service : tout le stack défile, chaque ligne préfixée du nom du service. Idéal au démarrage pour voir l'ordre réel et repérer qui échoue. Ensuite, zoomez avec logs -f bdd sur le suspect, puis exec pour entrer dedans.
Vous voulez arrêter le stack en gardant la base. Quelle commande ?