1.5Observer et déboguer : logs, exec, inspect
L'essentiel en 30 secondes
- logs : écouter le malade : docker logs bdd lit le journal, -f le suit en direct, --tail 50 n'en prend que la fin — un conteneur en boucle raconte toujours sa cause.
- exec : entrer pour vérifier : docker exec -it web sh ouvre un shell dans le vivant (fichier, ping, env) — diagnostic, jamais d'installation durable.
- ps → logs → exec/inspect : docker ps -a donne l'état et le code de sortie, inspect révèle tout (variables, montages, réseaux) — sans deviner.
Mini-cas filé — Idir autopsie un web muet
Le jour de la démo, le web d'Idir ne répond plus. Au lieu de tout recréer à l'aveugle, il applique la méthode : docker ps -a montre un Exited (1), docker logs web accuse un port déjà utilisé, docker inspect web confirme le conflit de publication. Il libère le port, relance — la page revient. Cinq minutes, zéro devinette : son responsable retient surtout qu'Idir a nommé la cause avant de corriger.
Fin du cas 1.1-1.4 — Idir boucle le niveau : diagnostiquer avant de corriger.
1. logs : écouter le malade
docker logs bdd lit le journal, -f le suit en direct, --tail 50 n'en prend que la fin. Un conteneur qui redémarre en boucle raconte toujours sa cause dans ses logs (mot de passe manquant, port occupé, volume au mauvais chemin).
Sur les services bavards, on limite avec --tail : lire la fin, pas des kilomètres. Si logs est vide, l'appli loggue peut-être ailleurs (fichier interne : entrer avec exec) ou meurt avant d'écrire (inspect + config).
2. exec : entrer pour vérifier
docker exec -it web sh ouvre un shell dans le vivant : vérifier un fichier, tester une connexion (ping bdd), lire une variable (env). Pour un one-shot sans shell : docker exec web ls /usr/share/nginx/html. On n'installe rien durablement ainsi : c'est du diagnostic.
Modifier à la main dans le conteneur est perdu au run suivant : exec constate, il ne répare pas durablement.
3. inspect et ps : l'état civil
docker ps -a donne l'état (Up, Exited, Restarting) et le code de sortie. docker inspect révèle tout : commande, variables, montages, réseaux, ports. Méthode : ps → logs → exec/inspect, dans cet ordre, sans deviner.
Et on note la cause réelle, pas le symptôme : « port déjà utilisé » plutôt que « ça ne marche pas ».
Le recréeur en boucle (ne faites jamais ça)
Moralité : recréer sans lire, c'est perdre sept fois contre la même ligne de log.
🔎 Exemple concret — 🔎 Exemple concret — Un web qui ne répond pas
L'autopsie du web muet d'Idir, étape par étape.
docker ps -a # Exited (1) ? Restarting ?
docker logs web # ex. : port déjà utilisé
docker inspect web # vérifier ports et réseaux
docker exec -it web sh # fouiller de l'intérieurLecture : l'état oriente, les logs accusent, l'inspection confirme.
Leçon : 90 % des pannes se résolvent sans recréer à l'aveugle.
Vocabulaire de la section
- logs
- Le journal capté par le daemon ; se lit avec -f (direct) et --tail (fin).
Exemple simple : docker logs web --tail 30 révèle le port occupé chez Idir.
Ce que ce n'est pas : un fichier modifiable à la main.
Réflexe : toujours lire avant de recréer.
- exec
- Exécuter une commande dans un conteneur vivant (shell -it ou one-shot).
Exemple simple : docker exec -it web sh pour fouiller le web vivant.
Ce que ce n'est pas : la création d'un nouveau conteneur (run).
Réflexe : exec = vivant ; arrêté = inspect ou run --rm.
- inspect
- Le dossier complet JSON d'un conteneur, image ou réseau (variables, montages, ports).
Exemple simple : docker inspect web confirme le conflit de ports.
Ce que ce n'est pas : une devinette sur la configuration.
Réflexe : la config réelle, pas celle qu'on croit.
- Code de sortie
- Le 0 (OK) ou non-zéro (erreur) laissé par le processus, visible dans ps -a.
Exemple simple : Exited (1) oriente Idir vers les logs.
Ce que ce n'est pas : un numéro de port.
Réflexe : non-zéro = lire les logs aussitôt.
En pratique — En pratique — Autopsie guidée
- Lancez volontairement un conteneur mal configuré (mauvais -e).
- Relevez son état exact avec ps -a.
- Lisez ses 30 dernières lignes de logs et nommez la cause.
- Confirmez avec inspect (variables, montages), puis corrigez.
Script prêt à dire — autopsier en 5 minutes (30 s)
« Mon conteneur est en Exited (1) : je lis ses trente dernières lignes de logs, je nomme la cause — port déjà utilisé. Je confirme avec inspect : ports et réseaux. Je corrige la cause, pas le symptôme, et je la note. »
À dire en enchaînant ps, logs --tail puis inspect ; montrer la cause nommée avant la correction.
Modèle copier-coller — check-list d'autopsie
docker ps -a # 1. ÉTAT : Up ? Exited (code) ? Restarting ?
docker logs NOM --tail 50 # 2. CAUSE : lire la fin, nommer (port, -e, volume)
docker inspect NOM # 3. PREUVE : variables, montages, réseaux, ports
docker exec -it NOM sh # 4. si VIVANT : fouiller (fichier, ping, env)
# 5. CORRIGER la cause, NOTER (pas le symptôme). Jamais recréer à l'aveugle.Web muet d'Idir
Comme ci-dessus : Exited (1) → logs → port occupé → inspect → libération → relance. Cinq minutes, zéro devinette.
Base en Restarting
Boucle de redémarrage : les logs contiennent la cause (souvent -e manquant ou mauvais chemin de volume) — on lit avant d'agir.
Logs vides
Appli qui loggue dans un fichier interne : entrer avec exec pour le lire, ou inspect + config si le conteneur meurt avant d'écrire.
One-shot sans shell
docker exec web ls /usr/share/nginx/html : vérifier un contenu sans ouvrir de shell — rapide et sans risque.
✓ Bonnes pratiques
- Toujours lire les logs avant de recréer.
- Limiter avec --tail sur les services bavards.
- Noter la cause réelle (pas le symptôme).
✗ Pièges fréquents
- Recréer en boucle sans lire (même erreur).
- Modifier à la main dans le conteneur (perdu au run suivant).
- Confondre exec (vivant) et run (nouveau).
Points clés à retenir
- ps donne l'état, logs la cause.
- exec entre, inspect révèle tout.
- L'ordre ps → logs → exec/inspect ne change pas.
- On corrige la cause, pas le symptôme.
Défi 48h — appliquez demain
Sabotez volontairement un conteneur (mauvais -e), relevez son état ps -a, lisez 30 lignes de logs, nommez la cause, confirmez par inspect — puis corrigez et notez.
- Je relève l'état exact (ps -a) avant toute hypothèse.
- Je lis les logs pour nommer la cause.
- Je confirme par inspect/exec et je corrige la cause.
Questions fréquentes
logs est vide, que faire ?
Soit l'appli loggue ailleurs (fichier interne : entrez avec exec), soit le conteneur meurt avant d'écrire (inspect + config). Vérifiez aussi le pilote de logs.
exec refuse : « container not running » ?
Normal : exec exige un conteneur vivant. Démarrez-le, ou utilisez run --rm pour une inspection jetable de l'image.
Un conteneur est en « Restarting ». Premier réflexe ?