infra / docker
Lister et inspecter les conteneurs
Explication
Ce que vous allez apprendre
- Filtrer et formater la sortie de
docker pspour retrouver rapidement un conteneur précis - Extraire un champ précis de la configuration d'un conteneur avec
docker inspect --format - Observer la consommation CPU/mémoire en temps réel avec
docker stats - Voir les processus qui tournent réellement à l'intérieur d'un conteneur avec
docker top - Visualiser les fichiers modifiés dans un conteneur par rapport à son image d'origine avec
docker diff
Dans quel contexte ?
Un administrateur système reçoit une alerte comme quoi la machine hôte est à court de mémoire. Avant d'agir, il doit savoir précisément lequel des dix conteneurs qui tournent est responsable. docker stats lui montre en temps réel que mon-api consomme 1,2 Go alors que sa limite prévue était de 512 Mo — un signe clair de fuite mémoire à investiguer, plutôt que de redémarrer la machine entière au hasard.
Voir ce qui tourne réellement
Une fois qu'on a lancé quelques conteneurs, une question revient sans cesse : lequel tourne encore, avec quelle configuration, et consomme-t-il trop de ressources ? C'est exactement le rôle des commandes d'inspection. Elles ne modifient rien : elles se contentent d'interroger l'état que Docker maintient pour chaque conteneur.
| Commande | Ce qu'elle montre |
|---|---|
docker ps -a | Liste et statut de tous les conteneurs |
docker inspect --format | Un champ précis de la configuration (JSON) |
docker stats | Consommation CPU/mémoire/réseau en temps réel |
docker top | Processus internes au conteneur |
docker diff | Fichiers ajoutés/modifiés/supprimés vs l'image |
Prérequis
Cette leçon suppose que tu es à l'aise avec le cycle de vie de base d'un conteneur (docker run, docker ps, docker stop) vu dans la leçon précédente.
Pourquoi ne pas se contenter de docker ps
docker ps donne un aperçu rapide (nom, image, statut, ports), mais chaque conteneur possède en réalité une fiche d'identité bien plus complète : adresse IP interne, variables d'environnement injectées, limites de mémoire, points de montage, nombre de redémarrages, etc. Cette fiche complète est accessible via docker inspect, qui renvoie un gros document JSON. Apprendre à en extraire un seul champ précis (avec l'option --format) plutôt que de lire tout le JSON à la main permet de scripter des vérifications automatiques — par exemple s'assurer qu'un conteneur a bien démarré avec la bonne adresse IP avant de continuer un script de déploiement.
Une vue en temps réel
docker ps et docker inspect donnent un instantané figé. Pour observer l'évolution de la consommation CPU/mémoire dans le temps, il faut un outil qui se rafraîchit en continu, comme le ferait un gestionnaire de tâches sur un ordinateur classique : c'est le rôle de docker stats. C'est souvent le premier réflexe quand un conteneur semble ralentir toute la machine.
Voir les changements apportés à un conteneur
Un conteneur peut, une fois lancé, écrire ou modifier des fichiers par rapport à l'image d'origine (logs, fichiers temporaires, config modifiée à la main). Pouvoir visualiser précisément ce qui a changé — ce qui a été ajouté, modifié ou supprimé — est très utile pour comprendre un comportement inattendu ou pour repérer qu'un conteneur a été modifié "à la main" plutôt que via l'image, ce qui est en général un signe qu'il faudrait plutôt corriger le Dockerfile.
Piège courant
Beaucoup de débutants tapent docker ps sans le -a et concluent à tort qu'un conteneur a "disparu" alors qu'il est simplement arrêté.
Piège fréquent
docker stats et docker inspect donnent un instantané ou un flux, mais ne remplacent jamais docker logs pour comprendre POURQUOI un conteneur consomme trop : ils montrent le symptôme (mémoire haute), pas la cause (une requête qui boucle, une fuite dans le code). Combine toujours les deux avant de conclure.
Cette leçon prolonge directement la précédente : après avoir appris à lancer des conteneurs, il faut apprendre à les observer correctement avant de savoir les déboguer.
Commandes & code
Lister et inspecter les conteneurs
docker ps # id, image, commande, statut, ports, nom
docker ps -a # inclut les conteneurs arrêtés
docker ps -q # uniquement les ID (utile en scripting)
docker ps --filter "status=exited" # filtre par statut
docker ps --filter "name=api" # filtre par nom (préfixe)
docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}" # format personnalisé
# Inspection détaillée : toute la config d'un conteneur en JSON
docker inspect mon-nginx
docker inspect --format '{{.State.Status}}' mon-nginx # extrait un seul champ
docker inspect --format '{{.NetworkSettings.IPAddress}}' mon-nginx
docker inspect --format '{{.HostConfig.Memory}}' mon-nginx
docker inspect --format '{{json .Mounts}}' mon-nginx | python3 -m json.tool
# État et ressources en temps réel
docker stats # CPU/mémoire/réseau/IO de tous les conteneurs
docker stats mon-nginx --no-stream # un seul relevé, pas de rafraîchissement continu
# Voir les processus tournant DANS un conteneur (vue depuis l'hôte)
docker top mon-nginx
# Historique des couches d'une image (voir la leçon optimisation pour creuser)
docker history nginx
# Métadonnées utiles pour du debug ou du scripting
docker inspect --format '{{.Config.Env}}' mon-nginx # variables d'environnement
docker inspect --format '{{.Config.Cmd}}' mon-nginx # commande de démarrage
docker inspect --format '{{.RestartCount}}' mon-nginx # nombre de redémarrages
# Différences entre l'image d'origine et l'état actuel du conteneur
docker diff mon-nginx # A = ajouté, C = modifié, D = supprimé, par rapport à l'imageRésumé
docker ps(avec-a,--filter,--format) est l'outil quotidien pour lister et cibler des conteneurs.docker inspect --formatextrait un champ JSON précis, très utile pour scripter des vérifications.docker statsetdocker topdonnent une vue temps réel des ressources et processus d'un conteneur.
Exercices pratiques
Mission : identifier le conteneur responsable d'une fuite mémoire
Objectif : Utiliser les outils d'inspection pour identifier un conteneur suspect et vérifier s'il a été modifié en dehors de son image.
Contexte
L'hôte de production alerte sur une utilisation mémoire anormale. Dix conteneurs tournent dessus. Tu dois utiliser les outils d'observation (pas les logs) pour repérer le coupable, puis vérifier s'il a été modifié à la main plutôt que via son image.