Problème : le conteneur s'arrête immédiatement après `docker run`

Décrypter le mystère du conteneur éphémère

Un scénario particulièrement déroutant pour les débutants avec Docker est le suivant : vous lancez un conteneur avec `docker run`, la commande semble réussir (pas de message d'erreur immédiat), mais lorsque vous vérifiez avec `docker ps`, le conteneur n'apparaît pas. En utilisant `docker ps -a`, vous le trouvez bien dans la liste, mais avec le statut `Exited` (Terminé), souvent quelques secondes à peine après son lancement. Qu'est-ce qui a bien pu se passer ?

Ce comportement, bien que frustrant, a une explication logique liée au fonctionnement fondamental des conteneurs Docker. Un conteneur Docker est conçu pour exécuter un processus principal (défini par les instructions `CMD` ou `ENTRYPOINT` dans le Dockerfile). Le conteneur reste actif tant que ce processus principal est en cours d'exécution. Si ce processus se termine (normalement ou à cause d'une erreur), le conteneur s'arrête aussitôt.

Comprendre cette relation directe entre la durée de vie du processus principal et celle du conteneur est la clé pour diagnostiquer pourquoi votre conteneur s'arrête prématurément.

Causes courantes de l'arrêt immédiat

Plusieurs raisons peuvent expliquer pourquoi le processus principal d'un conteneur se termine rapidement :

1. Le processus est conçu pour être court : Si l'instruction `CMD` ou `ENTRYPOINT` de l'image lance une commande qui effectue une tâche rapide puis se termine (par exemple, `echo 'Hello World'`, un script de migration de base de données, ou une simple commande `ls`), il est tout à fait normal que le conteneur s'arrête une fois la tâche accomplie. Ce n'est un problème que si vous vous attendiez à ce que le conteneur exécute un service de longue durée (comme un serveur web).

2. Erreur au démarrage de l'application : C'est la cause la plus fréquente pour les services censés tourner en continu. L'application principale (serveur web, base de données, application custom) rencontre une erreur fatale dès son lancement et "crash". Cela peut être dû à une mauvaise configuration, un fichier manquant, une variable d'environnement incorrecte, un bug dans le code, etc. Le processus s'arrête, et donc le conteneur aussi.

3. Commande principale incorrecte : Le `CMD` ou `ENTRYPOINT` spécifié dans le Dockerfile ou via la commande `docker run` est peut-être erroné, introuvable dans le conteneur, ou ne fait pas ce que vous attendez.

4. Absence de processus au premier plan : Si l'instruction `CMD`/`ENTRYPOINT` lance un processus en arrière-plan (un démon) mais ne maintient pas un processus actif au premier plan, Docker peut considérer que le travail principal est terminé et arrêter le conteneur. C'est pourquoi de nombreuses images de services utilisent un script wrapper ou lancent le service en mode "foreground".

Stratégies de diagnostic et de résolution

Face à un conteneur qui s'arrête immédiatement, voici une démarche systématique pour trouver la cause :

1. Consulter les logs (`docker logs`) : C'est la première et la plus importante étape. Même si le conteneur s'est arrêté, ses logs sont généralement conservés. Trouvez l'ID du conteneur arrêté avec `docker ps -a`, puis utilisez `docker logs `. Les dernières lignes affichées correspondent souvent au message d'erreur qui a provoqué l'arrêt du processus principal. C'est là que vous trouverez des indices cruciaux (ex: `FileNotFoundError`, `Configuration error`, `Port already bound inside container`, etc.).

# Lister tous les conteneurs, y compris arrêtés
docker ps -a
# CONTAINER ID   IMAGE     COMMAND       CREATED          STATUS                     PORTS     NAMES
# a1b2c3d4e5f6   my_app    "python app.py"  5 seconds ago    Exited (1) 4 seconds ago             sad_panda

# Récupérer les logs du conteneur arrêté
docker logs a1b2c3d4e5f6

2. Exécuter en mode interactif (`-it`) : Essayez de lancer le conteneur en mode interactif pour voir directement la sortie ou obtenir un shell. Si l'image a un `ENTRYPOINT` défini, vous devrez peut-être le surcharger.

# Essayer de lancer interactivement (si CMD est le problème)
docker run -it --rm my_image [args...]

# Si l'ENTRYPOINT pose problème, essayez d'obtenir un shell
docker run -it --rm --entrypoint sh my_image
# Une fois dans le shell, essayez de lancer manuellement la commande prévue par CMD/ENTRYPOINT

3. Maintenir le conteneur actif pour inspection (`tail -f /dev/null`) : Si les logs ne sont pas clairs ou si vous avez besoin d'explorer l'environnement du conteneur après son démarrage (mais avant qu'il ne crashe), vous pouvez le forcer à rester actif en surchargeant la commande principale avec quelque chose qui ne se termine jamais, comme `tail -f /dev/null`.

# Lance le conteneur et le maintient actif
docker run -d --name debug_container --entrypoint tail my_image -f /dev/null

# Maintenant, exécutez un shell à l'intérieur
docker exec -it debug_container bash # ou sh

# Une fois dedans, naviguez, vérifiez les fichiers, essayez de lancer le processus manuellement
# N'oubliez pas de supprimer le conteneur après : docker rm -f debug_container

4. Vérifier la configuration : Relisez attentivement votre `Dockerfile` (surtout `FROM`, `WORKDIR`, `COPY`, `RUN`, `CMD`, `ENTRYPOINT`) et votre commande `docker run` (mappages de volumes, variables d'environnement, ports) pour détecter d'éventuelles erreurs ou oublis.

En appliquant ces étapes, vous pourrez généralement isoler la raison pour laquelle le processus principal se termine (erreur applicative, fin normale de tâche, mauvaise configuration) et ainsi corriger le problème pour que votre conteneur s'exécute comme prévu.