## Introduction Les healthchecks Docker sont un outil essentiel pour s'assurer que vos conteneurs ne font pas que tourner, mais fonctionnent réellement correctement. Sans eux, Docker ne peut que vous dire si le processus du conteneur est vivant ; il ne peut pas savoir si votre application est bloquée dans une boucle infinie, a perdu sa connexion à la base de données ou est autrement en mauvaise santé. Les healthchecks vous permettent de définir une commande que Docker exécute à l'intérieur du conteneur à intervalles réguliers pour déterminer si le conteneur est sain. Lorsqu'un healthcheck échoue, Docker marque le conteneur comme malsain et peut même le redémarrer automatiquement (selon les politiques de redémarrage). Cependant, les healthchecks sont souvent mal configurés, ce qui entraîne des messages d'erreur déroutants, des conteneurs qui oscillent entre les états sain et malsain, ou des healthchecks qui ne signalent jamais le succès. Ces erreurs peuvent provoquer des redémarrages inutiles des conteneurs, ou pire, les faire considérer comme sains alors qu'ils sont en réalité défectueux. Cet article vous aidera à diagnostiquer et à corriger les erreurs courantes des healthchecks Docker avec des exemples pratiques. Nous aborderons le fonctionnement des healthchecks, les erreurs de configuration typiques, les modèles de configuration sûrs, les étapes de vérification, les modes de défaillance et la récupération, ainsi qu'une liste de contrôle opérationnelle pour garder vos conteneurs en bonne santé en production. À la fin de cet article, vous serez en mesure de : - Comprendre le mécanisme de healthcheck et comment il rapporte l'état. - Identifier les messages d'erreur courants et leurs causes. - Configurer les healthchecks en toute sécurité dans Dockerfile et Docker Compose. - Vérifier les healthchecks localement et interpréter les résultats. - Récupérer après un échec de healthcheck et éviter les pièges courants. Commençons. ## Inventaire des versions et de l'environnement Avant de commencer à corriger les healthchecks, établissons une base claire. Le comportement des healthchecks peut varier légèrement selon les versions de Docker, il est donc utile de savoir avec quoi vous travaillez. Cette section couvre les détails essentiels de version et d'environnement que vous devez collecter. Prérequis : - Docker Engine 1.12 ou version ultérieure (la fonctionnalité de healthcheck a été introduite dans la version 1.12). - Familiarité de base avec les commandes Docker et la syntaxe Dockerfile. - Une image de conteneur pour les tests (nous utiliserons nginx et postgres comme exemples). Vérifiez votre version de Docker : Exécutez la commande suivante sur votre hôte Docker : ```bash docker version ``` Extrait de sortie attendu : ``` Client: Docker Engine - Community Version: 24.0.5 API version: 1.43 ... Server: Docker Engine - Community Engine: Version: 24.0.5 API version: 1.43 (minimum version 1.12) ... ``` Assurez-vous que la version de votre serveur est au moins 1.12 pour prendre en charge les healthchecks. Topologie de l'environnement : Pour cet article, nous supposons un hôte Docker unique exécutant des conteneurs Linux (les exemples sont applicables aux conteneurs Windows avec des ajustements mineurs de chemin). Nous utiliserons la CLI Docker et Docker Compose v2. Aucune orchestration externe comme Kubernetes n'est nécessaire ; les concepts de healthcheck sont natifs à Docker. Images de conteneur d'exemple : Nous utiliserons l'image officielle nginx car elle inclut curl dans les versions récentes (nécessaire pour les healthchecks basés sur HTTP), et postgres car elle inclut pg_isready. Si votre image ne dispose pas d'une commande de healthcheck appropriée, vous devrez peut-être installer des outils comme curl ou wget dans votre image (abordé plus loin). Maintenant que notre environnement est configuré, comprenons comment les healthchecks sont configurés. ## Chemin de configuration sûr Configurer un healthcheck semble simple : fournissez une commande qui renvoie 0 pour sain et non zéro pour malsain. Cependant, de nombreuses erreurs proviennent d'une configuration incorrecte. Dans cette section, nous couvrirons la syntaxe, les erreurs courantes et les modèles sûrs pour écrire des healthchecks dans les Dockerfiles et les fichiers Docker Compose. ### Syntaxe du healthcheck dans le Dockerfile L'instruction HEALTHCHECK dans un Dockerfile a deux formes : - `HEALTHCHECK [OPTIONS] CMD command` - exécute une commande à l'intérieur du conteneur. - `HEALTHCHECK NONE` - désactive tout healthcheck hérité de l'image de base. Les options incluent : - `--interval=DURATION` (défaut : 30s) - `--timeout=DURATION` (défaut : 30s) - `--start-period=DURATION` (défaut : 0s) - `--retries=N` (défaut : 3) Extrait de Dockerfile d'exemple : ```dockerfile FROM nginx:alpine HEALTHCHECK --interval=5m --timeout=3s \ CMD curl -f http://localhost/ || exit 1 ``` Erreur courante : commande introuvable. Si la commande de healthcheck repose sur un outil qui n'est pas installé dans l'image, vous verrez une erreur dans la sortie de `docker inspect` comme : ```json "Health": { "Status": "unhealthy", "FailingStreak": 1, "Log": [ { "Start": "2023-09-01T12:00:00.000Z", "End": "2023-09-01T12:00:00.500Z", "ExitCode": 127, "Output": "/bin/sh: curl: not found\n" } ] } ``` Le code de sortie 127 signifie commande introuvable. Pour corriger, installez l'outil (`RUN apk add --no-cache curl` pour Alpine) ou utilisez une alternative intégrée. Par exemple, si votre image a wget, utilisez `wget -q --spider http://localhost/`. Modèle sûr pour un healthcheck HTTP : ```dockerfile FROM nginx:alpine RUN apk add --no-cache curl HEALTHCHECK --interval=30s --timeout=5s --retries=3 \ CMD curl -f http://localhost/ || exit 1 ``` Remarque : `-f` fait échouer curl avec un code de sortie non nul en cas d'erreurs HTTP (4xx/5xx). ### Syntaxe du healthcheck dans Docker Compose Dans Docker Compose, vous définissez le healthcheck sous le service : ```yaml services: web: image: nginx:alpine healthcheck: test: ["CMD", "curl", "-f", "http://localhost/"] interval: 30s timeout: 5s retries: 3 start_period: 10s ``` Le `test` peut être une chaîne ou une liste. S'il s'agit d'une chaîne, il est exécuté avec `/bin/sh -c` ; s'il s'agit d'une liste, il est exécuté directement sans shell (recommandé pour plus de clarté et éviter les problèmes d'interprétation du shell). Erreur courante : mauvaise interprétation des codes de sortie dans la forme liste. Lorsque vous utilisez une liste, la commande est exécutée sans shell. Donc `["CMD", "curl -f http://localhost/"]` échouerait car il essaie d'exécuter un binaire nommé `curl -f http://localhost/` comme un seul argument. Utilisez des arguments séparés : `["CMD", "curl", "-f", "http://localhost/"]`. Modèle sûr pour un healthcheck Compose : ```yaml services: web: image: nginx:alpine healthcheck: test: ["CMD", "curl", "-f", "http://localhost/"] interval: 30s timeout: 5s retries: 3 start_period: 30s ``` `start_period` donne au conteneur le temps de démarrer avant que les healthchecks ne commencent à échouer et à compter dans les tentatives. ### Healthcheck pour Dockerfile vs Compose Si les deux sont définis, Compose remplace le healthcheck du Dockerfile. Il est recommandé de définir le healthcheck dans le Dockerfile pour les images réutilisables, et de le remplacer dans Compose uniquement lorsque c'est nécessaire. Erreur courante : utilisation involontaire de `HEALTHCHECK NONE`. Si vous héritez d'une image de base avec un healthcheck et que vous définissez `HEALTHCHECK NONE` dans votre Dockerfile, vous désactivez le healthcheck hérité. Cela peut être intentionnel, mais parfois les développeurs copient un extrait de Dockerfile sans s'en rendre compte. Assurez-vous de vouloir réellement le désactiver. ### Exemple : healthcheck sûr pour une base de données Pour un conteneur PostgreSQL, utilisez `pg_isready` : ```yaml services: db: image: postgres:15-alpine environment: POSTGRES_PASSWORD: example healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"] interval: 10s timeout: 5s retries: 5 ``` `pg_isready` renvoie 0 si le serveur accepte les connexions, non nul sinon. Maintenant que nous avons des configurations sûres, vérifions-les. ## Vérification et diagnostic Une fois que vous avez configuré un healthcheck, vous devez vérifier qu'il fonctionne comme prévu. Cette section explique comment observer l'état du healthcheck, interpréter la sortie et diagnostiquer les problèmes. ### Affichage de l'état de santé du conteneur Exécutez `docker ps` pour voir une colonne d'état de santé : ```bash docker ps --format "table {{.Names}}\t{{.Status}}" ``` Exemple de sortie : ``` NAMES STATUS my-web Up 12 seconds (health: starting) my-db Up 30 seconds (healthy) ``` Un conteneur peut être dans l'un des trois états de santé : - `starting` : état initial, ou pendant la période de démarrage. - `healthy` : la commande de healthcheck renvoie 0. - `unhealthy` : la commande de healthcheck échoue plus que le nombre de tentatives autorisé. ### Inspection des journaux de healthcheck Pour voir les journaux détaillés du healthcheck, utilisez `docker inspect` : ```bash docker inspect --format='{{json .State.Health}}' my-web | jq ``` Exemple de sortie : ```json { "Status": "unhealthy", "FailingStreak": 1, "Log": [ { "Start": "2023-09-01T12:00:00.000Z", "End": "2023-09-01T12:00:00.500Z", "ExitCode": 1, "Output": "curl: (7) Failed to connect to localhost port 80: Connection refused\n" } ] } ``` Cela vous indique exactement ce qui ne va pas. Dans ce cas, le serveur web n'était pas prêt lorsque le healthcheck a été exécuté. La solution consiste à définir une `start_period` appropriée pour laisser le temps au démarrage. ### Test manuel de la commande de healthcheck Vous pouvez tester la commande de healthcheck en l'exécutant à l'intérieur d'un conteneur en cours d'exécution : ```bash docker exec my-web curl -f http://localhost/ ``` Si elle renvoie un code de sortie 0 et affiche la page, la commande fonctionne. Si elle échoue, vous pouvez déboguer la commande elle-même. ### Résultats attendus d'un healthcheck correct Pour un healthcheck correctement configuré, vous devriez voir : - `docker ps` affiche `(healthy)` après la période de démarrage. - `docker inspect` affiche `"Status": "healthy"` et `"FailingStreak": 0`. - Les entrées de journal ont `ExitCode: 0`. ### Vérification du healthcheck dans Compose Compose inclut l'état de santé dans `docker compose ps` : ```bash docker compose ps ``` Exemple : ``` NAME COMMAND SERVICE STATUS PORTS myproject-web-1 "/docker-entrypoint...." web running (healthy) myproject-db-1 "docker-entrypoint.s..." db running (healthy) ``` Examinons maintenant les modes de défaillance et comment s'en remettre. ## Modes de défaillance et récupération Les healthchecks peuvent échouer pour de nombreuses raisons : commande incorrecte, dépendances manquantes, problèmes réseau, bogues d'application ou paramètres mal configurés. Cette section catégorise les modes de défaillance courants et fournit des étapes de récupération. ### Mode de défaillance 1 : Commande de healthcheck manquante ou incorrecte Symptôme : Les journaux de healthcheck montrent un code de sortie 127 (commande introuvable) ou 126 (commande non exécutable). Cause : La commande spécifiée ou son interpréteur n'est pas installé dans l'image, ou le chemin est erroné. Récupération : - Identifiez l'outil manquant : `docker exec which ` (si `which` est disponible) ou essayez de l'exécuter. - Modifiez le healthcheck pour utiliser un outil qui existe dans l'image, ou ajoutez l'outil à l'image via le Dockerfile (par exemple, `RUN apt-get update && apt-get install -y curl`). - Reconstruisez l'image et redéployez. Exemple : Supposons que votre image soit basée sur alpine et que votre healthcheck utilise `wget`, mais que `wget` ne soit pas installé. Ajoutez `RUN apk add --no-cache wget` au Dockerfile. ### Mode de défaillance 2 : Le healthcheck expire Symptôme : Le journal de healthcheck montre un code de sortie 124 (délai dépassé) ou l'état reste starting pendant longtemps. Cause : La commande de healthcheck prend plus de temps que `--timeout` pour se terminer. Cela peut se produire si le point de terminaison est lent ou si la commande se bloque. Récupération : - Augmentez la valeur de `--timeout`, mais examinez aussi pourquoi la commande est lente. - Assurez-vous que la commande a une exécution bornée. Par exemple, utilisez curl avec un délai : `curl --max-time 5 -f http://localhost/`. - Vérifiez les performances de l'application ; peut-être que le point de terminaison est légitimement lent. Exemple : Original : `HEALTHCHECK --interval=30s --timeout=3s CMD curl -f http://localhost/slow-endpoint` Le point de terminaison prend 10 secondes pour répondre, donc le healthcheck expire. Changez pour `--timeout=15s` ou utilisez `curl --max-time 10`. ### Mode de défaillance 3 : Le healthcheck oscille entre sain et malsain Symptôme : `docker inspect` montre des états sain/malsain en alternance ; FailingStreak se réinitialise. Cause : La commande de healthcheck est intermittente, peut-être en raison de conditions de course, de limitations de ressources ou d'instabilité du réseau. Récupération : - Examinez les journaux de healthcheck pour voir si les échecs sont groupés ou aléatoires. - Augmentez `--interval` pour réduire la charge, ou `--retries` pour tolérer les échecs transitoires. - Corrigez le problème sous-jacent : par exemple, assurez-vous que l'application a assez de mémoire, ou que le point de terminaison du healthcheck ne fait pas de travail lourd. Exemple : Un healthcheck qui exécute `ps aux | grep myapp` peut échouer si la liste des processus est momentanément incohérente. Utilisez un healthcheck plus stable comme vérifier un fichier ou un point de terminaison léger. ### Mode de défaillance 4 : Le healthcheck signale sain mais l'application est malsaine Symptôme : Le conteneur apparaît sain, mais l'application ne répond pas correctement aux requêtes. Cause : La commande de healthcheck ne reflète pas précisément la santé de l'application. Par exemple, vérifier seulement que le processus est en cours d'exécution, ou vérifier une page statique qui fonctionne même lorsque le backend est en panne. Récupération : - Concevez un healthcheck qui exerce un chemin critique de votre application. - Pour une application web, utilisez un point de terminaison qui effectue une requête de base de données et renvoie un code de succès. - Mettez à jour la commande de healthcheck en conséquence. Exemple : Au lieu de `curl -f http://localhost/`, utilisez `curl -f http://localhost/health`, où `/health` vérifie la connexion à la base de données et renvoie 200 seulement si toutes les dépendances sont OK. ### Mode de défaillance 5 : Le healthcheck interfère avec le démarrage de l'application Symptôme : Le conteneur redémarre de façon répétée pendant le démarrage car le healthcheck échoue avant que l'application ne soit prête. Cause : `start_period` manquant ou insuffisant. La période de démarrage par défaut est 0s, donc les healthchecks commencent immédiatement et comptent les échecs tout de suite. Récupération : - Définissez `start_period` à une valeur généreuse (par exemple, 30s ou plus selon le temps de démarrage). - Surveillez les journaux de démarrage pour déterminer combien de temps l'application met pour être prête. - Augmentez `start_period` en conséquence. Exemple : Une application Java met 60 secondes à démarrer. Définissez `start_period=90s` pour éviter les échecs prématurés. ### Mode de défaillance 6 : La commande de healthcheck renvoie non zéro sur un avertissement Symptôme : Le healthcheck échoue même si l'application semble aller bien ; le journal montre un code de sortie 1 avec un message d'avertissement. Cause : Certaines commandes renvoient non zéro pour les avertissements. Par exemple, `curl` sans `-f` renvoie 0 pour une HTTP 404, mais avec `-f` renvoie 22 pour toute erreur HTTP. Récupération : - Ajustez la commande pour accepter 0 pour les avertissements non fatals attendus. - Utilisez un script personnalisé qui gère les codes de sortie attendus. Exemple : Si votre point de terminaison de healthcheck est `/health` et qu'il renvoie 404 lorsque le service n'est pas prêt, utiliser `curl -f` le marquera immédiatement comme malsain. Vous préférerez peut-être autoriser 404 comme état de démarrage et échouer seulement sur d'autres erreurs : ```bash curl -s -o /dev/null -w '%{http_code}' http://localhost/health | grep -q '200\|404' ``` Puis sortez avec 0 uniquement si le code est 200 ou 404. ### Étapes générales de récupération Lorsqu'un healthcheck échoue, suivez cette séquence de récupération : 1. Inspectez les journaux de healthcheck pour obtenir la sortie exacte et le code de sortie. 2. Exécutez manuellement la commande à l'intérieur du conteneur (`docker exec`) pour reproduire. 3. Évaluez si la commande est correcte pour l'état de l'application et ses dépendances. 4. Ajustez les paramètres : modifiez `interval`, `timeout`, `start_period` et `retries`. 5. Redéployez avec la configuration corrigée. 6. Surveillez la santé du conteneur pour confirmer la stabilité. N'oubliez pas de toujours tester les changements localement avant de les déployer en production. ## Pièges courants et comment les éviter Même les utilisateurs Docker expérimentés peuvent tomber dans des pièges lors de la configuration des healthchecks. Voici quelques pièges à surveiller, pourquoi ils se produisent, et comment les éviter ou s'en remettre. ### Piège 1 : Utiliser un healthcheck qui dépend de services externes Pourquoi cela arrive : Vous pouvez configurer un healthcheck qui interroge un point de terminaison externe (par exemple, une API tierce) pour vérifier la connectivité. Si le service externe tombe en panne, votre conteneur est marqué comme malsain, même si votre application fonctionne bien. Comment éviter : Gardez les healthchecks centrés sur la santé propre du conteneur. Si vous devez vérifier des dépendances externes, faites-le dans le point de terminaison de santé de votre application, mais évitez les appels externes directs dans le healthcheck. Comment récupérer : Si vous devez vérifier la connectivité externe, utilisez un délai court et des tentatives généreuses, et assurez-vous que le healthcheck lui-même ne se bloque pas. ### Piège 2 : La commande de healthcheck produit trop de sortie Pourquoi cela arrive : Certaines commandes de healthcheck, comme l'exécution d'un script qui journalise des informations de débogage, peuvent générer beaucoup de sortie à chaque vérification. Cela peut gonfler les journaux et consommer de l'espace disque. Comment éviter : Assurez-vous que la commande de healthcheck est silencieuse. Utilisez des indicateurs comme `-s` pour curl ou redirigez la sortie vers /dev/null si approprié. Par exemple : ```bash curl -s -o /dev/null http://localhost/health ``` Comment récupérer : Si la sortie est déjà excessive, modifiez la commande pour supprimer la sortie et redéployez. ### Piège 3 : Ne pas définir de start_period pour les applications à démarrage lent Pourquoi cela arrive : De nombreuses applications, en particulier celles avec des tâches d'initialisation ou des migrations de base de données, prennent du temps pour être prêtes. Sans start_period, Docker peut les marquer comme malsaines avant qu'elles aient fini de démarrer, provoquant des redémarrages inutiles. Comment éviter : Toujours définir un start_period plus long que le temps de démarrage attendu. Pour les applications dont le temps de démarrage est variable, préférez un start_period plus long. Comment récupérer : Si vous observez des échecs précoces, augmentez start_period et retries, puis redéployez. ### Piège 4 : Intervalle de healthcheck trop court, provoquant une utilisation élevée du processeur Pourquoi cela arrive : Un `--interval` très court (par exemple, 1 seconde) fait que la commande de healthcheck s'exécute fréquemment, pouvant consommer beaucoup de CPU et de mémoire, surtout si la commande n'est pas légère. Comment éviter : Choisissez un intervalle qui équilibre réactivité et utilisation des ressources. Généralement, 10 à 30 secondes est raisonnable. Pour les services critiques, vous pouvez descendre plus bas, mais surveillez la consommation de ressources. Comment récupérer : Si vous remarquez une utilisation élevée du CPU, augmentez l'intervalle et simplifiez la commande de healthcheck. ### Piège 5 : Ignorer l'état de santé dans l'orchestration Pourquoi cela arrive : Dans Docker Swarm ou d'autres orchestrateurs, l'état de santé peut être utilisé pour les mises à jour progressives et l'auto-réparation. Si vous ne configurez pas correctement les politiques de redémarrage ou les configurations de mise à jour, les conteneurs malsains risquent de ne pas être remplacés. Comment éviter : Assurez-vous que votre orchestrateur respecte l'état de santé. Par exemple, dans Docker Compose avec `docker stack deploy`, définissez `restart_policy` et l'ordre de mise à jour pour utiliser les healthchecks. Comment récupérer : Passez en revue votre configuration de déploiement et ajoutez des politiques de redémarrage appropriées. ## Liste de contrôle opérationnelle Maintenir des conteneurs en bonne santé nécessite une attention continue. Cette liste de contrôle fournit des étapes répétables pour exploiter et examiner les healthchecks dans votre environnement. Attribuez un responsable unique pour chaque tâche afin de garantir la responsabilisation. Le responsable suggéré est un exemple ; ajustez-le à la structure de votre équipe. ### Opérations quotidiennes - [ ] Vérifiez `docker ps` et `docker compose ps` pour tout conteneur qui n'est pas dans un état sain. **Responsable : Ingénieur de garde (par exemple, Alex Johnson)**. À examiner quotidiennement lors de la passation de service. - [ ] Pour les conteneurs malsains, inspectez les journaux avec `docker inspect --format='{{json .State.Health}}' `. **Responsable : Ingénieur de garde**. À examiner immédiatement lorsqu'un état malsain est détecté. - [ ] Confirmez que les conteneurs malsains sont redémarrés ou remplacés conformément à la politique. **Responsable : Ingénieur de garde**. À examiner quotidiennement. ### Revue hebdomadaire - [ ] Examinez les journaux de healthcheck pour détecter des échecs constants ou des délais dépassés qui peuvent indiquer une dégradation des performances. **Responsable : Responsable du service (par exemple, Priya Shah, responsable backend)**. À examiner chaque lundi matin. - [ ] Vérifiez que les commandes de healthcheck sont toujours précises pour l'application (par exemple, les points de terminaison existent toujours, les dépendances incluses). **Responsable : Responsable du service**. À examiner chaque semaine. - [ ] Assurez-vous que les périodes de démarrage sont appropriées aux temps de démarrage de l'application (surtout après les mises à jour de l'application). **Responsable : Responsable du service**. À examiner après chaque déploiement ou chaque semaine. ### Changements de configuration - [ ] Lors de la modification de Dockerfile ou docker-compose.yml, testez le healthcheck localement avec `docker compose up -d` et observez l'état. **Responsable : Développeur effectuant le changement**. À tester avant le commit. - [ ] Utilisez le contrôle de version pour les fichiers de configuration et gardez les définitions de healthcheck dans le même dépôt que l'application. **Responsable : Développeur**. En continu. - [ ] Documentez le comportement attendu du healthcheck pour chaque service. **Responsable : Responsable du service**. Mettre à jour la documentation après les changements ; revoir trimestriellement. ### Vérifications de capacité et de ressources - [ ] Surveillez l'utilisation des ressources ; si les healthchecks provoquent une utilisation élevée du CPU ou de la mémoire, envisagez d'augmenter l'intervalle ou de simplifier la commande. **Responsable : SRE (par exemple, Marcus Lee)**. À examiner mensuellement. - [ ] Assurez-vous que les commandes de healthcheck ne surchargent pas l'application (par exemple, évitez les requêtes de base de données coûteuses dans le healthcheck). **Responsable : Développeur**. À examiner lors de la revue de code. ### Sécurité - [ ] Évitez d'exposer des informations sensibles dans la sortie du healthcheck ; les journaux peuvent être collectés de manière centralisée. **Responsable : Ingénieur sécurité (par exemple, Sarah Chen)**. À examiner trimestriellement. - [ ] Assurez-vous que les points de terminaison de healthcheck ne sont pas accessibles publiquement à moins que ce ne soit prévu, et qu'ils ne révèlent pas de détails sensibles. **Responsable : Ingénieur sécurité**. À examiner après tout changement réseau. ### Réponse aux incidents - [ ] Lorsqu'un conteneur devient malsain, rassemblez immédiatement les journaux de healthcheck. **Responsable : Commandant d'incident**. Pendant l'incident. - [ ] Préservez la sortie de `docker inspect` pour l'analyse post-incident. **Responsable : Commandant d'incident**. Pendant l'incident. - [ ] Avant de redémarrer, essayez de déterminer la cause profonde ; si sûr, exécutez manuellement la commande de healthcheck à l'intérieur du conteneur. **Responsable : Commandant d'incident**. Pendant l'incident. ### Automatisation - [ ] Intégrez la surveillance des healthchecks dans votre système d'alerte (par exemple, utilisez l'état de santé Docker dans les métriques des conteneurs). **Responsable : Responsable de l'équipe de surveillance (par exemple, David Kim)**. À configurer initialement, revoir trimestriellement. - [ ] Utilisez des outils d'orchestration qui respectent l'état de santé pour les mises à jour progressives ou l'auto-réparation (par exemple, Docker swarm mode, Nomad, etc.) mais notez que Docker autonome ne s'auto-répare pas sans politiques de redémarrage ; assurez-vous que les politiques de redémarrage sont définies de manière appropriée. **Responsable : Ingénieur plateforme (par exemple, Emily Zhang)**. À examiner après les changements d'infrastructure. ## Conclusion Les healthchecks Docker sont un outil puissant pour maintenir la fiabilité des applications, mais ils nécessitent une configuration et une surveillance minutieuses. Nous avons couvert les fondamentaux de la syntaxe des healthchecks, les erreurs courantes telles que les commandes manquantes, les délais dépassés, les oscillations et les faux positifs, et fourni des modèles de configuration sûrs pour Dockerfile et Compose. Nous avons également vu comment vérifier les healthchecks à l'aide de `docker inspect` et `docker exec`, et décrit les étapes de récupération pour divers modes de défaillance. Enfin, nous avons fourni une liste de contrôle opérationnelle pour garder vos healthchecks efficaces dans le temps. Pour aller de l'avant : - Passez en revue vos conteneurs existants et identifiez ceux qui n'ont pas de healthchecks ; ajoutez-les là où c'est applicable. - Pour les healthchecks existants, inspectez les journaux pour vous assurer qu'ils fonctionnent correctement ; corrigez les erreurs en utilisant les modèles de cet article. - Établissez une routine pour surveiller l'état de santé et revoir les configurations périodiquement. Avec une stratégie de healthcheck solide, vous pouvez détecter les problèmes tôt, réduire les temps d'arrêt et garantir que vos conteneurs sont toujours dans un état connu et sain. Commencez par un healthcheck étroit et mesurable pour chaque service critique, testez localement et itérez en fonction des diagnostics observés. Bonne conteneurisation !