Docker : pourquoi un container 'up' peut cacher un service mort

Un matin, impossible d'accéder à son Nextcloud auto-hébergé, alors que tous les voyants sont au vert côté Docker. L'auteur venait de se faire avoir par une mise à jour automatique du container Nextcloud via Watchtower (l'outil qui update tout seul tes images Docker) : la nouvelle version du code n'était plus compatible avec le schéma de la base de données, et il fallait lancer une migration manuelle. Résultat, le container tournait parfaitement bien... mais l'appli à l'intérieur était cassée net.

Le souci, c'est que Docker ne surveille que le cycle de vie du processus principal, pas ce qui se passe réellement dedans. Un container peut afficher "running" alors que le service qu'il héberge renvoie une erreur 500 en boucle. L'auteur a même reproduit le bug en deux minutes avec un container Nginx jetable : docker ps affichait tout vert, alors qu'un simple curl montrait que ça plantait.

Pour corriger le tir, il a fait l'inventaire de ses 28 containers : seuls 10 avaient déjà un health check natif configuré (avec des délais de détection parfois énormes, genre 15 minutes pour Immich). Pour les 18 autres, dont Nextcloud, il a ajouté ses propres health checks dans les fichiers docker-compose, en s'appuyant sur curl ou wget quand c'était possible.

Dernière étape : un petit script maison qui tourne en permanence et surveille l'état de santé de tous les containers, pour redémarrer automatiquement ceux qui déconnent. Résultat, son homelab répare maintenant lui-même ses services cassés sans attendre qu'il s'en aperçoive au petit matin devant son café.