Contrôles de santé Docker : un laboratoire local avec des exemples pratiques

Introduction

Les contrôles de santé Docker sont un mécanisme intégré qui permet de déterminer si un conteneur est réellement sain, et pas seulement en cours d'exécution. Un conteneur peut être actif alors que son application est bloquée, redémarre en boucle en interne ou n'arrive pas à joindre une dépendance. Les contrôles de santé permettent à Docker et aux orchestrateurs de détecter cet état et d'agir en conséquence, par exemple en redémarrant le conteneur ou en détournant le trafic.

Cet article est un guide pratique pour construire un laboratoire local où vous pourrez expérimenter les contrôles de santé Docker en toute sécurité. Il couvre l'inventaire des versions et de l'environnement, la configuration sécurisée, la vérification, les modes de défaillance et la récupération, ainsi qu'une liste de contrôle opérationnelle. Chaque section comprend des commandes concrètes, les résultats attendus et les décisions de récupération. L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le périmètre d'impact, protéger les secrets, vérifier les résultats et documenter comment récupérer si l'état attendu n'est pas atteint.

Inventaire des versions et de l'environnement

Avant de configurer les contrôles de santé, identifiez ce avec quoi vous travaillez. Exécutez :

docker version

Le résultat attendu inclut les versions du client et du serveur, par exemple Client : Docker Engine - Community 24.0.5 et Serveur : Docker Engine - Community 24.0.5. La prise en charge des contrôles de santé existe depuis Docker 1.12, mais les versions plus récentes peuvent inclure des correctifs ou des options supplémentaires. La syntaxe des contrôles de santé de Docker Compose est cohérente entre les formats de fichier Compose v2 et v3, mais si vous utilisez une ancienne version de Compose, vérifiez la compatibilité.

Pour voir ce qui est actuellement en cours d'exécution et si des contrôles de santé sont déjà utilisés :

docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"

Recherchez des statuts comme Up 5 minutes (healthy) ou Up 5 minutes (unhealthy). Si vous voyez (healthy) ou (unhealthy), un contrôle de santé est déjà défini. Si vous voyez seulement Up 5 minutes, il n'y a pas de contrôle de santé.

Pour un examen plus approfondi de la configuration d'un conteneur, des points de montage, des réseaux et de l'état de santé, utilisez :

docker inspect <conteneur> | grep -A 10 Health

Cela affiche la définition du contrôle de santé et les derniers résultats. Pour les projets Compose, utilisez :

docker compose ps

pour voir la santé des services, et :

docker compose logs -f <service>

pour suivre les journaux et détecter les échecs de contrôle de santé en temps réel.

Vérification de la persistance des données

Un test de type production que vous devriez exécuter localement est un test de redémarrage. Si votre application stocke des données, confirmez où les fichiers sont écrits avant de modifier quoi que ce soit. Un volume nommé comme app_data:/var/lib/app est géré par Docker et plus facile à réutiliser lors de reconstructions de conteneurs. Un montage bind comme ./data:/var/lib/app mappe directement un répertoire hôte et est pratique pour le développement, mais peut causer des problèmes de permissions, de portabilité et de sauvegarde si le même chemin n'existe pas sur une autre machine.

Pour tester la persistance, arrêtez le conteneur, recréez-le et vérifiez si les données sont toujours présentes :

docker stop mon_appli
docker run -d --name mon_appli -v app_data:/var/lib/app mon_image
docker exec mon_appli ls /var/lib/app

Si le répertoire est vide, le service écrivait probablement dans le système de fichiers du conteneur au lieu du volume.

Chemin de configuration sécurisé

Après avoir compris votre environnement, ajoutez un contrôle de santé à un conteneur. La méthode la plus sûre consiste à modifier le Dockerfile ou le fichier Compose plutôt que de surcharger au moment de l'exécution, afin que le contrôle de santé soit versionné et reproductible.

Contrôle de santé dans le Dockerfile

Voici un contrôle de santé simple dans un Dockerfile pour un service web utilisant curl :

FROM nginx:alpine
RUN apk add --no-cache curl
HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
  CMD curl -f http://localhost/ || exit 1

Explication :

• interval=30s : exécute la vérification toutes les 30 secondes.
• timeout=3s : chaque vérification doit se terminer en moins de 3 secondes.
• start-period=10s : laisse 10 secondes au conteneur pour démarrer avant de considérer les échecs.
• retries=3 : après 3 échecs consécutifs, marque le conteneur comme non sain.
• CMD curl -f http://localhost/ || exit 1 : la commande de contrôle ; curl -f échoue sur les erreurs HTTP.

Contrôle de santé dans Docker Compose

Si vous utilisez Compose, les contrôles de santé peuvent être définis par service :

services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/"]
      interval: 30s
      timeout: 3s
      retries: 3
      start_period: 10s

Assurez-vous que la commande de contrôle de santé est disponible à l'intérieur du conteneur. Les images Alpine nécessitent souvent l'ajout de curl, tandis que les images basées sur Debian peuvent inclure wget. Testez la commande manuellement avant de vous y fier :

docker exec mon_web curl -f http://localhost/

Si la commande échoue ou est absente, ajustez l'image ou le contrôle de santé.

Options de commande de contrôle de santé

Au-delà de curl, les commandes de contrôle de santé courantes incluent :

• Pour une base de données, utilisez pg_isready -U postgres dans l'image postgres.
• Pour une instance Redis, utilisez redis-cli ping et attendez PONG.
• Pour une application personnalisée, écrivez un petit script qui vérifie un point de terminaison HTTP ou effectue une petite requête SQL.

Rendez toujours le contrôle de santé déterministe et sans effet de bord. Il ne doit pas modifier de données.

Vérification et diagnostic

Une fois un contrôle de santé configuré, vérifiez qu'il fonctionne. Exécutez :

docker ps

En quelques secondes à une minute, vous devriez voir le statut du conteneur passer à (healthy). S'il affiche (unhealthy), investigatez immédiatement.

Consultez les résultats récents du contrôle de santé :

docker inspect --format='{{json .State.Health}}' mon_conteneur | jq

Cela produit un bloc JSON incluant les derniers codes de sortie et sorties. Par exemple :

{
  "Status": "unhealthy",
  "FailingStreak": 3,
  "Log": [
    {
      "Start": "2023-05-01T12:00:00.000000000Z",
      "End": "2023-05-01T12:00:00.500000000Z",
      "ExitCode": 1,
      "Output": "curl: (7) Failed to connect to localhost port 80: Connection refused\n"
    }
  ]
}

Un code de sortie non nul indique que la commande de contrôle a échoué. Le champ Output indique souvent la raison.

Causes d'échec courantes :

• Mauvais port ou chemin.
• Dépendances manquantes (curl non installé).
• Application pas prête dans la période de démarrage.
• Permissions de la commande de contrôle.

Pour déboguer, exécutez la commande de contrôle exacte dans le conteneur :

docker exec mon_conteneur sh -c "curl -f http://localhost/"

Observez le code de sortie et la sortie. Ajustez une variable à la fois, comme l'intervalle ou le délai d'attente, puis revérifiez.

Modes de défaillance et récupération

Les contrôles de santé peuvent eux-mêmes échouer d'une manière qui affecte la disponibilité de l'application. Comprenez ces modes de défaillance et comment s'en remettre.

Faux positifs (sain alors que cassé)

Un contrôle de santé peut réussir même si l'application n'est pas pleinement fonctionnelle. Par exemple, un curl vers / renvoie 200 mais le backend est en panne. Pour éviter cela, faites en sorte que le contrôle de santé exerce un chemin critique, comme un point de terminaison /healthz qui vérifie la connectivité à la base de données.

Récupération : affinez le contrôle de santé pour tester des fonctionnalités plus profondes.

Faux négatifs (non sain alors que fonctionne)

Si le contrôle de santé est trop strict, Docker peut redémarrer un conteneur sain inutilement. Par exemple, un délai d'attente de 1 seconde sur un point de terminaison lent. Cela provoque des redémarrages de conteneurs et des temps d'arrêt potentiels.

Récupération : augmentez le délai d'attente ou l'intervalle, ou rendez la commande de contrôle plus efficace.

Effets de bord de la commande de contrôle de santé

Un contrôle de santé doit être en lecture seule. S'il écrit des données, il peut causer des conflits ou un état incohérent. Par exemple, un contrôle de santé qui exécute une grosse requête ou met à jour une table.

Récupération : remplacez le contrôle de santé par une opération simple en lecture seule.

Interaction entre le contrôle de santé et les politiques de redémarrage

Les politiques de redémarrage Docker (comme --restart=unless-stopped) ne redémarrent pas un conteneur non sain ; elles ne redémarrent que les conteneurs qui se sont arrêtés. Cependant, les outils d'orchestration comme Docker Swarm ou Kubernetes utilisent les contrôles de santé pour replanifier les services non sains. Ne supposez pas qu'une politique de redémarrage gérera les conteneurs non sains.

Récupération : combinez les contrôles de santé avec un gestionnaire de processus ou un orchestrateur qui agit sur l'état de santé.

Pièges courants

1. Oublier la période de démarrage : certaines applications mettent du temps à démarrer. Sans --start-period, le contrôle de santé peut marquer le conteneur comme non sain avant qu'il ne soit prêt, provoquant des redémarrages inutiles. Correctif : définissez une période de démarrage réaliste basée sur le temps de démarrage de votre application.

1. Utiliser une commande de contrôle de santé absente de l'image : de nombreuses images minimales manquent de curl ou wget. Correctif : installez l'outil dans le Dockerfile ou utilisez une autre méthode de contrôle, comme un script ou un binaire intégré.

1. Ne pas tester le contrôle de santé dans un environnement local : déployer des contrôles de santé directement en production sans test local peut conduire à un comportement inattendu. Correctif : testez toujours dans un laboratoire local, observez les transitions de statut et simulez des pannes.

1. Ignorer les journaux du contrôle de santé : le statut de santé seul ne dit pas pourquoi il échoue. Correctif : inspectez les journaux de santé avec docker inspect et incluez la sortie dans votre surveillance.

1. Contrôle de santé trop lourd : un contrôle de santé qui est lourd (par exemple, exécutant une grosse requête) peut ralentir le conteneur. Correctif : gardez-le léger et rapide.

Liste de contrôle opérationnelle

Utilisez cette liste avant et après le déploiement des contrôles de santé.

Conclusion

Les contrôles de santé Docker sont un outil puissant pour améliorer la fiabilité des conteneurs, mais ils doivent être configurés avec soin et testés localement. Cet article a fourni une approche structurée : commencer par un inventaire de l'environnement, configurer les contrôles de santé en toute sécurité, les vérifier, comprendre les modes de défaillance et suivre une liste de contrôle opérationnelle.

Comme prochaine étape, prenez un conteneur de votre environnement local et ajoutez un contrôle de santé en utilisant les exemples ci-dessus. Observez le statut dans docker ps, inspectez les journaux de santé, puis simulez une panne en faisant échouer la commande de contrôle. Documentez le comportement attendu et les étapes de récupération.

Une configuration fiable des contrôles de santé rend les pannes visibles, protège les valeurs sensibles, limite les modifications à la ressource prévue et définit la vérification de la récupération avant qu'un incident ne force la décision.