3.5Dépannage Compose : redémarrages et volumes orphelins
L'essentiel en 30 secondes
- « Restarting » : lire avant de recréer : compose ps repère le malade, logs du service l'accuse — on corrige le FICHIER, puis up -d ne recrée que ce qui change.
- Port occupé : on déplace le gauche : 8080 already in use = squatteur sur l'hôte — on change le port hôte (gauche), jamais l'interne ; docker ps global démasque.
- Vieux builds, volumes orphelins : cibler : up -d --build après modif du code, volume ls pour les orphelins — down -v ne touche que CE projet, avec prudence.
Mini-cas filé — Idir et le port fantôme
Idir, devops junior à Alger, lance son stack un lundi : l'api boucle en Restarting, « port already allocated ». Au lieu de tout raser, il diagnostique : compose ps repère l'api, compose logs accuse le port, docker ps global démasque un vieux run manuel oublié sur 8080. Il change le port HÔTE en 8082 dans le compose, up -d — le stack démarre, les données intactes. Le fantôme manuel est nettoyé après, chirurgicalement. Depuis, Idir lit avant de recréer.
Ce même cas revient dans le cours, le schéma, le script et le défi 48h.
1. Restarting et port occupé : ps repère, logs accuse
Service en « Restarting » : on LIT avant de recréer. docker compose ps repère le malade, logs nom-du-service l'accuse — variable manquante, volume au mauvais chemin, port occupé. On corrige le FICHIER, puis up -d : Compose ne recrée que ce qui change, le reste continue de tourner. Le déclaratif est chirurgical par nature : on soigne la description, pas les conteneurs.
Le port déjà utilisé (8080 already in use) : un autre service — ou un ancien run hors Compose — occupe le port HÔTE. Solution : changer le port hôte (le gauche, "8082:80"), jamais le port conteneur ; docker ps global démasque le squatteur. Deux stacks qui se mélangent, c'est souvent le même nom de projet (dossier) ou les mêmes ports hôtes : isolez avec -p et des ports distincts.
2. Vieux builds et volumes orphelins : cibler, pas raser
Le code ne se met pas à jour après un up ? L'image n'a pas été reconstruite : up -d --build, pas un rm furieux. Renommer un service ou un projet crée des volumes orphelins (anciennes données dormantes) : docker volume ls les montre, et compose down -v ne touche que CE projet — avec prudence, car il efface ses volumes. Nettoyer, c'est identifier d'abord.
Les trois réflexes du médecin du stack : nommer les projets (-p) en cas de doublons, lire les logs du service (pas tout le stack), corriger le fichier puis relancer. Et l'interdit absolu : down -v en panique — on ne rase jamais pour diagnostiquer. Idir a collé la séquence au mur : ps → logs → corriger → up -d.
🔎 Exemple concret — Port occupé par un fantôme : diagnostic complet
Idir déroule la séquence ps → logs → docker ps → correction du fichier.
docker compose ps # api : Restarting ?
docker compose logs api # Error: port déjà utilisé ?
docker ps # un vieux run manuel sur 8080 ?
# Corriger le port HÔTE dans compose.yml : "8082:80"
docker compose up -d # ne recrée que ce qui changeLecture : le squatteur était un run manuel oublié — démasqué par le ps global.
Leçon : on change le port hôte (gauche), jamais l'interne ; on nettoie le fantôme après.
Vocabulaire de la section
- Orphelin
- Volume ou projet abandonné après un renommage : anciennes données dormantes à identifier avant tout nettoyage.
Exemple simple : L'ancien pgdata d'Idir après renommage du service.
Ce que ce n'est pas : un volume actif du projet courant.
Réflexe : volume ls d'abord, supprimer en connaissance de cause.
- Squatteur
- Processus occupant déjà le port hôte visé : vieux run manuel ou second stack sur le même port.
Exemple simple : Le run manuel oublié sur 8080.
Ce que ce n'est pas : un problème dans l'image du service.
Réflexe : docker ps global pour démasquer.
- --build
- Forcer la reconstruction des images au up : le code modifié est vraiment pris en compte.
Exemple simple : Le up -d --build d'Idir après chaque changement d'api.
Ce que ce n'est pas : un rm furieux des conteneurs pour « forcer ».
Réflexe : code changé = --build, systématique.
- Nom de projet
- Préfixe isolant les ressources d'un stack (-p, dossier par défaut) : deux projets, deux mondes.
Exemple simple : Idir isole maquette et bac avec -p.
Ce que ce n'est pas : deux stacks qui se mélangent sur les mêmes ports.
Réflexe : nommer en cas de doublons sur une machine.
- Recréer (ciblé)
- up -d ne recrée que les services modifiés : la chirurgie du déclaratif, le reste tourne.
Exemple simple : Seule l'api recréée après le changement de port.
Ce que ce n'est pas : raser tout le stack « pour être sûr ».
Réflexe : corriger le fichier, relancer, vérifier.
En pratique — Casser puis réparer, au scalpel
- Provoquez un port occupé : run manuel + compose sur le même port hôte.
- Diagnostiquez : compose ps, compose logs du service, docker ps global.
- Corrigez le port hôte dans le fichier et relancez (up -d) : seul le service change.
- Nettoyez le fantôme manuel (rm -f) et vérifiez : stack vert, données intactes.
Script prêt à dire — annoncer la panne et le remède (30 s)
« L'api bouclait : port hôte squatté par un vieux run manuel oublié. J'ai déplacé le port gauche en 8082 dans le compose, relancé — seul le service a été recréé, données intactes, fantôme nettoyé après. Pas de down -v, pas de perte. »
À dire en point d'équipe ; montrer la séquence ps → logs → correction.
Modèle copier-coller — compose après correction du port
# Après diagnostic : port hôte déplacé (gauche), interne inchangé.
services:
web:
image: nginx:1.27
ports:
- "8082:80"
networks:
- front
bdd:
image: postgres:16.4
environment:
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
volumes:
- pgdata:/var/lib/postgresql/data
networks:
- front
volumes:
pgdata:
networks:
front:
# Diagnostique : compose ps, logs du service, docker ps global.Indépendant
La séquence ps → logs → corriger → up -d et vos lundis matins redeviennent calmes.
PME à Alger
Idir affiche la séquence au mur : l'équipe diagnostique avant de raser.
Équipe projet
Interdire le down -v hors stack jetable ; exiger le log du service dans chaque ticket panne.
Débutant
Cette semaine : provoquez un port occupé sur du jetable et réparez-le au scalpel.
✓ Bonnes pratiques
- Lisez les logs du service précis, pas tout le stack en vrac.
- Corrigez le fichier, relancez : Compose ne recrée que ce qui change.
- Nommez les projets (-p) dès que deux stacks partagent une machine.
✗ Pièges fréquents
- down -v en panique : les données du projet sont effacées.
- Changer le port conteneur (droite) au lieu du port hôte (gauche).
- Oublier --build après modif du code : l'ancienne image tourne toujours.
Points clés à retenir
- PS repère, LOGS accuse, le FICHIER corrige : lire avant de recréer.
- PORT occupé → on déplace le port HÔTE (gauche) ou on tue le squatteur.
- DOWN -v = reset du projet, avec prudence — jamais un diagnostic.
- --BUILD après chaque changement d'image ; -p pour isoler les doublons.
Défi 48h — appliquez demain
Provoquez 1 panne sur du jetable (port occupé) et réparez-la sans -v, en notant chaque étape du diagnostic.
- Je diagnostique ps → logs avant toute action.
- Je déplace le port hôte, jamais l'interne.
- Je ne rase jamais : -v seulement sur reset décidé.
Questions fréquentes
Pourquoi deux stacks se mélangent-ils ?
Même NOM DE PROJET (le dossier par défaut) ou mêmes PORTS HÔTES : les ressources se chevauchent. Isolez avec -p nom-projet et des ports hôtes distincts. compose ps par projet montre alors deux mondes séparés — et docker ps global reste l'arbitre en cas de doute.
Faut-il tout recréer quand un service change ?
NON : up -d ne recrée que les services modifiés — c'est toute la valeur du déclaratif. Corrigez le fichier, relancez, vérifiez : le reste continue de tourner, les volumes restent. Raser tout « pour être sûr » détruit ce que le déclaratif préserve.
Compose affiche « port already allocated ». Que changez-vous ?