IT Toolbox AI
Docker · Debug et bonnes pratiques

Debug et bonnes pratiques

Diagnostiquez méthodiquement les incidents Docker et appliquez des pratiques adaptées à la production.

Leçon disponible
20 min

Objectifs

  • Collecter l’état, les logs et la configuration d’un container en échec.
  • Diagnostiquer un port inaccessible ou une boucle de redémarrage.
  • Observer processus, ressources, image et stockage.
  • Éviter les nettoyages destructeurs et renforcer l’exploitation en production.

Déboguer Docker avec une méthode reproductible

Un diagnostic Docker fiable commence par des commandes d’observation. Le container n’est qu’une couche du système : l’image, la configuration, les volumes, le réseau, les ressources et les dépendances externes peuvent tous expliquer le symptôme.

Collectez les indices avant de recréer ou supprimer l’objet. Une reproduction contrôlée permet ensuite de vérifier la cause supposée et l’efficacité de la correction.

Observer un container

ps -a montre aussi les containers arrêtés. logs affiche leurs sorties, inspect leur configuration et leur état détaillé, stats les ressources en temps réel et top les processus visibles dans le container.

État, logs et configuration
docker ps -a
docker logs <container>
docker logs -f <container>
docker inspect <container>
Ressources et processus
docker stats
docker top <container>
Ouvrir un shell seulement si l’image en contient un
docker exec -it <container> /bin/sh

Certaines images minimales ne contiennent pas /bin/sh. exec nécessite aussi que le container soit en cours d’exécution.

Méthode de diagnostic en neuf étapes

Suivez un ordre stable afin de ne pas écraser les preuves et de distinguer l’incident de ses conséquences.

  • 1. Vérifier l’état du container avec docker ps -a.
  • 2. Relever le code de sortie dans docker inspect.
  • 3. Consulter les logs autour de l’heure du symptôme.
  • 4. Inspecter la configuration effective.
  • 5. Vérifier ports, adresses et réseaux.
  • 6. Vérifier les volumes, chemins et permissions.
  • 7. Observer CPU et mémoire.
  • 8. Confirmer l’image et le tag réellement utilisés.
  • 9. Reproduire le problème avant toute modification irréversible.
Extraire le code de sortie sans modifier le container
docker inspect --format '{{.State.ExitCode}}' <container>

Container arrêté, port inaccessible ou boucle de redémarrage

Pour un container Exited, corrélez le code de sortie avec les logs et la configuration. Pour un port inaccessible, confirmez le mapping puis vérifiez que le processus écoute réellement dans le container.

En cas de redémarrages en boucle, examinez les logs, la restart policy, le healthcheck s’il existe, la configuration et les dépendances externes. La boucle est souvent un symptôme, pas la cause racine.

Diagnostiquer un container Exited
docker ps -a
docker logs <container>
docker inspect <container>
Vérifier le mapping de ports
docker port <container>
docker inspect <container>

Examiner image et espace disque

docker history aide à comprendre les couches d’une image. docker system df résume l’espace occupé et récupérable sans rien supprimer.

Inventorier images, couches et stockage
docker images
docker history <image>
docker system df
Avertissement : ne jamais automatiser cette suppression sans inventaire et sauvegarde
docker system prune -a --volumes

Cette commande de prune peut supprimer containers arrêtés, réseaux inutilisés, images non utilisées, cache de build et volumes anonymes inutilisés. Commencez par docker system df et supprimez seulement les ressources précisément identifiées.

Bonnes pratiques DevOps / Production

Une image exploitable doit être maintenue, observable et limitée au strict nécessaire. La configuration de runtime doit rendre les incidents compréhensibles sans imposer une connexion interactive dans le container.

  • Choisir des images petites, maintenues et analysées pour les vulnérabilités.
  • Utiliser des tags ou digests explicites et maîtriser les mises à jour.
  • Exécuter en non-root et éviter les privilèges inutiles lorsque possible.
  • Ne jamais stocker de secrets dans un Dockerfile ou une image.
  • Définir un healthcheck pertinent et des limites CPU/mémoire adaptées.
  • Produire des logs structurés et exploitables sur stdout/stderr.
  • Placer les données persistantes dans des volumes sauvegardés.
  • Séparer les applications avec des réseaux dédiés et des ports minimaux.

Mini résumé

  • Commencez par ps -a, inspect et logs avant de modifier l’environnement.
  • Ports, réseaux, volumes et ressources doivent être vérifiés séparément.
  • history et system df aident à examiner image et stockage.
  • Les suppressions globales ne remplacent jamais un diagnostic ciblé.

Analyser les logs d’un container

Copiez un extrait anonymisé de docker logs dans Log Analyzer pour repérer rapidement erreurs, niveaux et motifs fréquents, entièrement côté navigateur.

Ouvrir Log Analyzer

Mini quiz

Trois questions pour vérifier les notions essentielles de la leçon.

1. Un container vient de passer en Exited. Quelle première approche préserve le mieux les indices ?
2. Le mapping de port existe, mais le service reste inaccessible. Que faut-il aussi vérifier ?
3. Pourquoi docker system df doit-il précéder une éventuelle suppression ?