Observer un conteneur : logs et exec
Un conteneur qui tourne en arrière-plan (-d) devient invisible. Voici comment aller y regarder de plus près.
docker logs : lire ce que le conteneur affiche
Depuis le guide 8, vous lancez Mini-Carnet avec -d, en arrière-plan. Son console.log de démarrage, dans server.js, s'affiche pourtant bien quelque part : Docker le conserve, même invisible dans votre terminal. La commande docker logs permet de le consulter à tout moment.
Tout ce qu'une application affiche normalement dans un terminal (via console.log en JavaScript, ou l'équivalent dans un autre langage) se retrouve dans les logs de son conteneur. C'est souvent le tout premier réflexe à avoir quand une application ne se comporte pas comme attendu.
Suivre les logs en direct avec -f
L'option -f, pour « follow », garde le terminal ouvert et affiche chaque nouvelle ligne de log au fur et à mesure qu'elle apparaît, sans qu'il faille retaper la commande :
Pour quitter ce mode de suivi sans arrêter le conteneur, un simple Ctrl+C dans le terminal suffit : il n'arrête que l'affichage des logs, pas le conteneur lui-même, qui continue de tourner en arrière-plan.
docker exec : entrer dans un conteneur en marche
Les logs racontent ce qu'un conteneur a affiché, mais pas forcément l'état actuel de son système de fichiers. Pour aller voir directement à l'intérieur d'un conteneur en cours d'exécution, la commande docker exec ouvre une session interactive dans ce conteneur, un peu comme un second terminal, mais situé à l'intérieur de son isolement.
-it combine deux options déjà rencontrées dans le vocabulaire Docker : -i garde l'entrée clavier ouverte, -t alloue un vrai terminal interactif. sh, à la fin, est le programme à lancer à l'intérieur du conteneur : un interpréteur de commandes.
L'image de base utilisée par Mini-Carnet, node:22-alpine, repose sur Alpine Linux, une distribution volontairement minimale qui n'inclut pas bash par défaut, contrairement à beaucoup d'autres images Linux. Utilisez sh, presque toujours disponible, plutôt que bash, qui renverrait une erreur du type « executable file not found » sur ce type d'image.
Quand utiliser l'un plutôt que l'autre
docker logs reste le premier réflexe : rapide, sans effet de bord, il suffit dans l'immense majorité des cas. docker exec devient utile quand les logs ne suffisent pas à comprendre un problème, par exemple pour vérifier qu'un fichier existe réellement au bon endroit, ou tester une commande directement dans l'environnement du conteneur.
Vérifiez que vous avez compris
Vous tapez exit après être entré dans un conteneur avec docker exec -it mon-carnet sh. Le conteneur s'arrête-t-il ?
Non. exit ferme uniquement la session ouverte par docker exec, celle du sh que vous avez lancé. Le processus principal du conteneur, celui démarré par CMD au tout premier lancement, continue de tourner normalement, exactement comme avant d'être entré dans le conteneur.