Comment identifier la dépendance de conteneur à l’origine d’une boucle de redémarrage

Identifiez la première dépendance qui devient indisponible avant que l’application ne s’arrête, plutôt que de considérer chaque conteneur qui redémarre comme la cause première.

Dans une pile Docker Compose, l’application visible peut boucler parce qu’une base de données est encore en cours de démarrage, que Redis est inaccessible, que le DNS renvoie vers le mauvais service, qu’un montage bind est absent, qu’un secret a changé, qu’une migration a échoué ou que l’application est arrêtée en raison d’une pression mémoire. Pour diagnostiquer rapidement le problème, capturez la première sortie et la première erreur de dépendance, suspendez les redémarrages automatiques, puis testez chaque service requis depuis le même réseau et avec les mêmes identifiants que ceux utilisés par le conteneur défaillant.

Trouvez le premier conteneur qui échoue, pas celui qui fait le plus de bruit

Répertoriez le nombre de redémarrages, l’état actuel, l’état de santé, le dernier code de sortie et l’heure de démarrage de chaque service de la pile. Classez la chronologie afin que l’échec le plus précoce apparaisse avant que les conteneurs secondaires ne commencent à se reconnecter ou à redémarrer.

Le guide de Netdata sur les boucles de redémarrage montre comment les codes de sortie et les états permettent de distinguer les arrêts dus à un manque de mémoire, les erreurs de segmentation, les arrêts normaux et les arrêts liés à l’état de santé. Un signal OOMKilled ou un code de sortie peut rendre inutile le dépannage des dépendances si l’application manque en réalité de mémoire ou plante en interne.

Si une dépendance échoue en premier, examinez-la avant l’application. Si l’application s’arrête d’abord avec des erreurs de connexion refusée, de délai d’attente, d’authentification ou de fichier manquant, associez ce message à la dépendance exacte qu’elle tentait d’utiliser.

Suspendez la tempête de redémarrages et capturez un échec propre

Désactivez temporairement la stratégie de redémarrage du service concerné ou remplacez-la, puis exécutez-le une fois au premier plan ou consultez l’intégralité de ses journaux pour une seule tentative de démarrage. Conservez les horodatages du démon Docker et de chaque dépendance.

Les redémarrages automatiques répétés peuvent remplacer la première erreur significative par des erreurs de connexion ultérieures. Un conteneur qui redémarre toutes les quelques secondes peut également surcharger sa base de données, son résolveur DNS ou son volume de journaux et créer des symptômes secondaires.

Ne supprimez pas les conteneurs, les volumes ou les bases de données pendant cette capture. Arrêtez uniquement la tempête de redémarrages, reproduisez le problème une fois, puis enregistrez l’environnement, les montages, les connexions réseau, la commande et l’état de sortie avant de modifier la configuration.

Cartographiez toutes les dépendances nécessaires au démarrage de l’application

Notez la base de données, le cache, la file de messages, le stockage d’objets, le résolveur DNS, le fournisseur d’identité, les fichiers montés, les secrets et les API externes requis par l’application. Indiquez également le nom de service, le port, le protocole, le nom d’utilisateur, la base de données et le chemin attendus.

Dash0 explique que l’ordre de démarrage de Compose ne signifie pas automatiquement que le processus d’une dépendance est prêt ; une application peut démarrer alors que Postgres est encore en cours d’initialisation. La solution consiste à attendre l’état sain d’une dépendance, plutôt que son simple état d’exécution.

Classez les dépendances comme indispensables ou facultatives. L’absence d’un service facultatif de métriques ne devrait pas redémarrer l’application principale, tandis que l’indisponibilité d’une base de données peut nécessiter une attente contrôlée, de nouvelles tentatives ou un arrêt.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Testez chaque dépendance depuis le réseau du conteneur défaillant

Utilisez un conteneur de diagnostic temporaire connecté au même réseau ou lancez un shell compatible avant que l’application ne s’arrête. Testez dans cet ordre la résolution DNS du nom de service, le port TCP, TLS, l’authentification, la requête à la base de données et le chemin requis.

Le guide de Last9 sur les vérifications d’état dans Compose indique que les contrôles de disponibilité empêchent les services dépendants de démarrer tant que les composants critiques ne peuvent pas réellement répondre. Un contrôle utile valide l’opération du service dont les clients ont besoin, plutôt que de confirmer uniquement qu’un processus existe.

Si le DNS échoue, examinez l’appartenance au réseau et les alias. Si la connexion TCP s’établit mais que l’authentification échoue, comparez les secrets et les utilisateurs. Si la connexion fonctionne mais que le schéma, le compartiment, la file ou le répertoire attendu est absent, corrigez l’initialisation plutôt que le réseau.

Vérifiez les montages, les secrets et les migrations comme des dépendances

Comparez les montages bind actuels, les volumes nommés, les autorisations, le propriétaire, les fichiers d’environnement, les fichiers de secrets et la version de l’application avec ceux du dernier déploiement fonctionnel. Un conteneur peut accéder à sa base de données tout en redémarrant parce qu’un fichier de configuration est en lecture seule ou qu’une migration ne peut pas écrire.

Une étude de cas sur le démarrage d’un conteneur montre qu’un ordre de dépendance fondé sur l’état de santé peut empêcher une application de planter avant que sa base de données ne soit prête. La séquence de démarrage conditionnelle devient particulièrement importante lors du premier démarrage et des migrations.

Exécutez les migrations une seule fois avec les journaux visibles et sauvegardez la base de données avant de réessayer des étapes destructives. Si la version de l’application a changé, vérifiez que la version de la dépendance et le chemin de mise à niveau du schéma sont pris en charge.

Réactivez les services dans l’ordre des dépendances et vérifiez leur stabilité

Démarrez d’abord la dépendance de niveau inférieur, attendez son véritable contrôle d’état, puis démarrez la couche suivante et enfin l’application. Relevez le nombre de redémarrages et les transitions d’état de santé pendant plusieurs intervalles de contrôle.

Le guide ZimaSpace consacré aux défaillances DNS côté conteneur décrit un chemin de dépendance qui peut apparaître uniquement dans l’environnement de l’application.

Le problème n’est résolu que lorsque l’application démarre une fois, que toutes les dépendances indispensables restent saines, que les migrations se terminent et qu’un redémarrage volontaire d’une dépendance déclenche une nouvelle tentative ou une récupération contrôlée, plutôt qu’une nouvelle boucle. Ne rétablissez la stratégie de redémarrage qu’une fois la défaillance racine observable et maîtrisée.