Pourquoi la vérification d’état d’un conteneur échoue-t-elle alors que l’application s’ouvre toujours ?

Un conteneur peut rester utilisable alors que sa vérification d’état échoue, car la sonde teste une commande, une adresse, un utilisateur ou une condition de disponibilité différente de ceux utilisés par votre navigateur.

Sur un serveur domestique, l’application peut être accessible via un proxy inverse alors que Docker exécute la commande de vérification à l’intérieur du conteneur, en ciblant localhost, un utilitaire absent, le mauvais port ou une dépendance temporairement indisponible. Commencez par reproduire la sonde exacte dans le conteneur, puis comparez sa cible et son résultat attendu avec le parcours réel de l’utilisateur avant d’augmenter le nombre de tentatives ou de désactiver la vérification d’état.

Comparez ce que teste le navigateur avec ce que teste la vérification d’état

Notez l’URL et le chemin réseau qui permettent d’ouvrir l’application. Précisez si le navigateur passe par un proxy inverse, un port hôte publié, une adresse IP locale ou accède directement au conteneur.

Docker exécute la sonde configurée à l’intérieur du conteneur : elle peut donc tester un point de terminaison différent de celui du navigateur. Un cas signalé sur la communauté Docker montrait qu’une vérification d’état échouait parce que l’image ne contenait pas la commande curl utilisée par la sonde, même si le processus du service pouvait continuer à fonctionner.

Si le parcours réussi dans le navigateur passe par un autre proxy ou un autre port, ne considérez pas ce résultat comme la preuve que la cible interne de la sonde est correcte. Notez les deux parcours et identifiez le premier composant qui diffère.

Exécutez la commande exacte de vérification dans le conteneur

Copiez exactement la commande de vérification d’état, y compris sa forme shell, son URL, ses options, ses identifiants et ses variables d’environnement. Exécutez-la dans le conteneur en cours d’exécution avec le même utilisateur, puis relevez le code de sortie et la sortie affichée.

Un conteneur marqué comme non sain peut néanmoins avoir un processus en cours, car l’état de santé reflète le résultat de la sonde et non la possibilité pour les utilisateurs de charger une page. Le processus de diagnostic de Netdata distingue l’échec de la sonde de l’échec du processus avant de modifier le comportement de redémarrage.

Si la commande réussit manuellement, comparez l’utilisateur d’exécution, le shell, le répertoire de travail, l’environnement et le délai utilisés par la vérification automatique. Si elle échoue manuellement, l’erreur indique alors la couche suivante sans attendre un nouvel intervalle de vérification.

Vérifiez l’outil de la sonde, le shell, le PATH et l’utilisateur

Vérifiez que chaque exécutable de la commande de vérification existe dans l’image actuelle et peut être exécuté par l’utilisateur du conteneur. Les images minimales peuvent ne pas inclure curl, wget, bash, les outils DNS ou les magasins de certificats.

Les sondes utilisant la forme shell et celles utilisant la forme exec se comportent différemment. Les guillemets, les tubes, l’expansion des variables et les commandes composées nécessitent un shell disponible, tandis qu’une commande directe doit utiliser le chemin complet de l’exécutable lorsque l’environnement de vérification dispose d’un PATH limité.

Exécutez la commande avec un chemin absolu et l’utilisateur de service prévu. Corrigez l’image ou la sonde plutôt que d’installer des outils de manière interactive, car toute modification manuelle du conteneur disparaîtra lors de la prochaine reconstruction.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Vérifiez l’adresse, le port et le protocole internes

Inspectez le service d’écoute de l’application dans le conteneur et comparez-le à l’URL de la sonde. Un port hôte publié comme 8080:80 ne signifie pas que le service écoute sur le port 8080 à l’intérieur du conteneur.

Les vérifications d’état doivent tester l’état de l’application que le conteneur contrôle. Le guide pratique de Dash0 précise qu’une sonde peut appeler un point de terminaison HTTP ou inspecter un processus, mais que ce point de terminaison doit refléter l’état réel de disponibilité du conteneur, plutôt qu’une route accessible uniquement via un proxy externe.

Testez 127.0.0.1, l’adresse d’écoute du conteneur et le nom du service uniquement lorsque chacun est approprié. Si l’application se lie uniquement à un socket Unix ou à une autre interface, modifiez la sonde pour utiliser le véritable point d’entrée interne.

Distinguez un démarrage lent d’un échec permanent

Mesurez le temps nécessaire à l’application, à la migration de la base de données, au préchauffage du cache ou au chargement du modèle avant que le point de terminaison correct ne réponde. Comparez cette durée à start_period, interval, timeout et retries.

Compose peut bloquer les services dépendants lorsqu’une dépendance est encore marquée comme non saine, même si elle devient disponible par la suite. Une régression signalée dans Compose montrait qu’un service ne devenait sain qu’après que l’échec de la dépendance avait déjà arrêté la pile, révélant une fenêtre de démarrage de la vérification d’état trop étroite.

Augmentez les délais uniquement lorsque les journaux prouvent que l’application progresse normalement. Des tentatives plus nombreuses ne doivent pas masquer un port incorrect, une migration échouée, un certificat manquant ou une base de données inaccessible.

Gardez la sonde ciblée et vérifiez la récupération

Déterminez si la vérification d’état doit représenter la disponibilité du processus, la disponibilité de l’application locale ou une chaîne de dépendances plus profonde. Ne rendez pas un conteneur local non sain simplement parce qu’une API externe facultative est indisponible.

Le guide ZimaSpace consacré à l’identification de la première dépendance en échec constitue l’étape suivante lorsque l’application ne peut pas devenir disponible sans une base de données, un cache ou un service réseau.

Le problème est résolu lorsque la sonde automatique exacte réussit après un démarrage normal, que le conteneur reste sain lors des redémarrages de ses dépendances et que le fonctionnement réel de l’application reste accessible. Gardez la sonde suffisamment stricte pour détecter un service défaillant, mais suffisamment ciblée pour éviter les faux échecs liés à des systèmes indépendants.