2.2 Lister les conteneurs (la commande qu'on tape tout le temps)

Bien, la toute première commande utile que l'on va utiliser est docker ps. Elle va vous permettre d'afficher les différents conteneurs actuellement présents et lancés sur votre machine.

Si vous venez d'installer Docker, ça donnera simplement ça :

➜  ~ docker ps
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

On retient plusieurs choses. Il s'agit d'un tableau qui va vous montrer différentes informations cruciales :

• CONTAINER ID : L'identifiant unique du conteneur (ultra utile pour le cibler avec d'autres commandes par la suite).
• IMAGE : L'image utilisée par le conteneur pour tourner (ex : mysql:8.0).
• COMMAND : La commande exécutée par défaut au démarrage du conteneur.
• CREATED : La date de création du conteneur.
• STATUS : Le statut actuel du conteneur (s'il tourne, depuis combien de temps, ou s'il a planté).
• PORTS : Les ports ouverts pour permettre la communication.
• NAMES : Le nom du conteneur (que vous avez défini, ou que Docker a généré aléatoirement si vous n'avez rien dit).

Cette commande de base est redoutable. Elle vous permet, en un seul coup d'œil, de voir tout ce qui tourne sur votre machine.

Un exemple concret

Voici un exemple avec un conteneur PostgreSQL qui tournerait en ce moment même sur votre machine :

CONTAINER ID   IMAGE         COMMAND                  CREATED      STATUS         PORTS                                       NAMES
c9bbfccc565d   postgres:18   "docker-entrypoint.s…"   5 days ago   Up 2 seconds   0.0.0.0:5432->5432/tcp, [::]:5432->5432/tcp   monolith_database

Là, on peut observer pas mal de choses intéressantes :

• CONTAINER ID -> c9bbfccc565d (L'ID sera toujours généré aléatoirement et ne sera jamais identique à un autre).
• IMAGE -> postgres:18
• COMMAND -> "docker-entrypoint.s…"
• CREATED -> 5 days ago
• STATUS -> Up 2 seconds (Il a été créé il y a 5 jours, mais vient tout juste d'être redémarré il y a 2 secondes !)
• NAMES -> monolith_database

Voir les fantômes : les conteneurs arrêtés

Quand vous allez multiplier les manipulations et les expérimentations (surtout lors de vos futurs travaux pratiques ou labs), vous allez vite vous rendre compte d'un détail : la commande docker ps ne vous dit pas tout.

En fait, elle ne montre que les conteneurs qui sont actuellement en cours d'exécution.

Mais que se passe-t-il si votre conteneur a planté au démarrage ? Ou s'il a simplement terminé sa tâche (comme un script d'installation) et s'est arrêté ? Il disparaît de l'écran radar. Pourtant, il n'est pas supprimé : il est toujours là, sur votre machine, dans un état "dormant".

Pour voir absolument tous vos conteneurs, qu'ils soient en pleine forme ou complètement éteints, on ajoute une petite option magique : le -a (pour all).

Bash

➜  ~ docker ps -a

Ce qui vous donnera un tableau similaire à ce qu'on a vu précédemment, mais avec quelques différences notables dans la colonne STATUS :

Bash

CONTAINER ID   IMAGE         COMMAND                  CREATED       STATUS                     PORTS     NAMES
c9bbfccc565d   postgres:18   "docker-entrypoint.s…"   5 days ago    Up 2 hours                 5432/tcp  monolith_database
a1b2c3d4e5f6   ubuntu:22.04  "bash"                   10 days ago   Exited (0) 5 days ago                test_ubuntu
f9e8d7c6b5a4   my_app:v1     "npm start"              2 hours ago   Exited (1) 2 hours ago               buggy_app

Décrypter le statut "Exited"

C'est ici que ça devient super intéressant, notamment pour comprendre ce qui cloche dans votre architecture :

• Exited (0) : Tout s'est bien passé ! Le conteneur a fait son travail et s'est arrêté proprement, sans aucune erreur. C'est typiquement le cas d'un conteneur qui devait juste lancer une commande ponctuelle.
• Exited (1) (ou tout autre chiffre) : Aïe. Le processus a rencontré une erreur fatale et a crashé. C'est le signal qu'il va falloir enquêter.

Sortir la boîte noire : lire les logs d'un conteneur

On a vu juste avant que notre conteneur buggy_app avait crashé lamentablement avec un statut Exited (1). C'est le quotidien du développeur, pas de panique. Mais comment savoir ce qui s'est passé à l'intérieur de cette boîte isolée avant qu'elle ne rende l'âme ?

C'est là qu'intervient la commande salvatrice : docker logs.

Pour l'utiliser, c'est très simple, il suffit de lui donner l'ID du conteneur (ou son nom) que vous avez récupéré grâce à votre docker ps -a.

➜  ~ docker logs buggy_app

Et là, Docker va vous recracher tout ce que l'application a écrit dans le terminal avant de planter. Imaginons par exemple que cette application soit un petit agent de monitoring codé en Go qui essaie de parler à notre base de données :

2026/07/28 11:55:01 Starting Go monitoring agent...
2026/07/28 11:55:01 Loading configuration from .env...
2026/07/28 11:55:02 FATAL: could not connect to PostgreSQL on port 5432: dial tcp 127.0.0.1:5432: connect: connection refused

Boum ! Le mystère est résolu. L'application a crashé parce qu'elle n'a pas réussi à se connecter à la base de données. Sans cette commande, vous auriez pu chercher l'erreur pendant des heures.

Les options indispensables pour ne pas devenir fou

Si votre conteneur tourne depuis des mois, taper un simple docker logs risque de vous afficher des milliers de lignes d'un coup et de bloquer votre terminal. Voici les deux options que vous allez utiliser tous les jours :

• Le mode "Direct" (-f ou --follow) : Exactement comme un tail -f sous Linux, cette option permet de s'accrocher aux logs en temps réel. Parfait pour regarder ce qui se passe quand vous testez votre API. Bash

  docker logs -f mon_api_laravel
  

• Le mode "Juste la fin" (--tail) : Si vous voulez juste voir les 50 dernières lignes pour comprendre le dernier bug sans polluer votre écran : Bash

  docker logs --tail 50 mon_api_laravel