Docker : diagnostiquer un conteneur qui redémarre en boucle

Docker relance le conteneur après l’arrêt de son processus principal. Remplacez mon-conteneur par son nom et app par le service Compose concerné.

Lire l’erreur avant le redémarrage

docker ps -a
docker logs --tail 100 --timestamps mon-conteneur
docker inspect --format '{{json .State}}' mon-conteneur
docker inspect --format '{{.RestartCount}}' mon-conteneur

Regardez les dernières lignes avant chaque arrêt. State expose notamment ExitCode, Error, OOMKilled et les dates de démarrage et de fin.

Avec Compose, vous pouvez utiliser docker compose logs --tail 100 --timestamps app. Si aucun log n’apparaît, l’application peut écrire dans un fichier interne ou utiliser un pilote de logs qui ne permet pas cette lecture ; vérifiez sa configuration de journalisation.

Interpréter les indices

Un code 137 seul ne prouve pas un manque de mémoire : un arrêt forcé peut produire le même résultat. Ces codes concernent surtout les conteneurs Linux.

Vérifier la configuration qui provoque l’arrêt

Dans le dossier du projet Compose :

docker compose config --quiet

Vérifiez les variables obligatoires, le chemin du programme, le répertoire de travail et les montages de volumes. Un montage peut masquer des fichiers présents dans l’image. Pour afficher la configuration résolue, utilisez docker compose config en local ; elle peut contenir des secrets.

Le serveur doit rester au premier plan comme processus principal. Évitez les scripts qui lancent le serveur avec & puis se terminent. Pour un script Linux, contrôlez aussi le shebang, le droit d’exécution et les fins de ligne LF.

Si le conteneur s’arrête trop vite pour docker exec, un service Compose dont l’image contient sh peut être examiné dans un conteneur temporaire :

docker compose run --rm --no-deps --entrypoint sh app

Ce shell contourne le démarrage habituel. Il ne fonctionne pas avec une image sans shell et réutilise les volumes et variables du service : modifier un fichier monté peut toucher les données réelles. Quittez avec exit.

Si la mémoire manque

docker stats --no-stream mon-conteneur
docker inspect --format '{{.HostConfig.Memory}}' mon-conteneur

La limite affichée est en octets ; 0 signifie qu’aucune limite mémoire explicite n’est fixée à ce niveau. La machine, Docker Desktop ou un autre niveau de gestion peut toujours imposer une limite. docker stats est un instantané : il peut manquer le pic ayant causé le crash.

Vérifiez la limite du service, la mémoire disponible et une éventuelle fuite applicative. Augmentez la limite seulement si la machine dispose de la capacité nécessaire.

Si une dépendance n’est pas prête

Une base peut être démarrée sans accepter encore les connexions. Ajoutez un healthcheck adapté et une dépendance condition: service_healthy, puis gardez une logique de reconnexion côté application. La procédure Connexion refusée entre conteneurs détaille ce cas.

Un état unhealthy n’est pas équivalent à un processus arrêté : Docker Engine ne redémarre pas automatiquement un conteneur uniquement parce que son healthcheck échoue. Un orchestrateur ou un outil externe peut le faire.

Corriger et observer

Pour arrêter la boucle pendant l’intervention, utilisez docker compose stop app ou docker stop mon-conteneur, selon la manière dont le conteneur est géré. Cela interrompt le service.

Après correction du fichier Compose ou du Dockerfile :

docker compose up -d --build app
docker compose ps -a
docker compose logs --since 2m --follow app

--build concerne les services construits depuis un Dockerfile ; une image préconstruite se met à jour selon votre procédure de déploiement. Observez plusieurs cycles, reproduisez une requête et vérifiez que le compteur de redémarrages reste stable. Ctrl+C quitte le suivi des logs sans arrêter le service.

N’utilisez pas docker compose down -v pour résoudre un crash : cette commande peut supprimer les volumes et leurs données.

Ressources

• Docker — politiques de redémarrage
• Docker — contraintes de mémoire
• Docker — logs
• Docker — commande Compose run