6.2Problèmes récurrents (playbook)
L'essentiel en 30 secondes
- Diagnostiquer : un symptôme = des causes probables = une séquence d'actions — on ne corrige pas au hasard.
- Racines : variables, ports, volumes, rebuild oublié, healthcheck, droits, cache, login — 90 % des blocages.
- Vérifier : ps, logs, config et preuve sur volume réel, pas seulement sur un run isolé.
Fil Idir — le tableau scotché à côté de l'écran
Idir garde ce tableau à côté de son écran à Alger. Verdict après un trimestre : trois lignes l'ont le plus servi — le conteneur en Restarting, le port déjà alloué, et les données perdues après rm. Pour chacune, il a fini par appliquer la séquence (symptôme, causes, actions) au lieu de relancer au hasard.
Symptôme observé, causes vérifiées, actions dans l'ordre : le réflexe tient en trois temps.
Un réflexe par symptôme
La plupart des blocages Docker sont des grands classiques. Relier chaque symptôme à ses causes probables et à une séquence d'actions fait gagner un temps précieux.
| Symptôme | Causes probables | Actions |
|---|---|---|
| Conteneur en Restarting | variable -e manquante, volume au mauvais chemin, port occupé | compose ps, logs du service, corriger le fichier, up -d |
| port already allocated | squatteur (vieux run), deux stacks même port hôte | docker ps global, changer le port hôte (gauche) |
| Données perdues après rm | aucun volume, montage au mauvais chemin | ajouter un volume nommé, prouver par rm + relance |
| up ignore le nouveau code | image non reconstruite | up -d --build (ou bind en dev) |
| Base « pas prête » au démarrage | depends_on sans condition, pas de retry | healthcheck + condition healthy + retry appli |
| Permission denied sur volume | montage root, USER non-root sans chown | chown au build / aligner UID, ne pas revenir root |
| Image énorme / build lent | COPY . . en premier, pas de .dockerignore | dépendances d'abord + .dockerignore + multi-stage |
| Push denied | pas de login, nom sans namespace, pas de droits | login, nom compte/image, droits |
| down a tout effacé | down -v sur données voulues | down sans -v par défaut ; sauvegardes + restauration testée |
Script prêt à dire — diagnostiquer sans relancer au hasard (30 s)
« Mon symptôme : [Restarting / port alloué / données perdues / base pas prête]. Je vérifie la cause probable du tableau (ps, logs, config, chemins), j'applique l'action ciblée et je prouve (relance, down/up, restauration). »
Modèle copier-coller — diagnostic Docker
docker compose ps
docker compose logs -f api
docker ps -a
docker compose config
docker compose up -d --buildTPE / petit budget
Pas de tableau formel : un symptôme, la cause probable, l'action et qui prouve, notés.
PME Alger
Intégrer les réalités locales au diagnostic : machine réelle, ports déjà pris, référent connu.
Remote / hybride
Ajouter les traces écrites aux actions : à distance, un log et une preuve down/up consignés évitent les doublons.
Interculturel
Expliciter les constats par écrit : ce qui semble évident (quel service, quel port) ne l'est pas pour tous.
Défi 48h — appliquez demain
Repérez 1 symptôme actuel (Restarting, port, données, base pas prête), appliquez la ligne du tableau (symptôme nommé + cause vérifiée + action ciblée) et prouvez.
- Je sais relier un symptôme à ses causes probables.
- Je vérifie ps, logs et config avant de corriger.
- Je prouve chaque correction (relance, down/up, restauration).
Le conteneur d'Idir boucle en Restarting. Quel réflexe applique le tableau ?
Réflexe : diagnostiquer le symptôme, identifier la cause, appliquer l'action ciblée — ne pas relancer au hasard.