Comment fonctionnent les vérifications de santé Docker et pourquoi sont-elles importantes ?

Question

Accepted Answer

Une **vérification de santé** indique à Docker (ou à un orchestrateur) comment déterminer si l'application d'un conteneur **fonctionne réellement**, et ne fait pas que s'exécuter. Le processus d'un conteneur peut être actif tandis que l'application est cassée (figée, ne peut pas atteindre sa base de données) — les vérifications de santé détectent cela afin que la plateforme puisse réagir.

## Définir une vérification de santé

```dockerfile
# in a Dockerfile
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD curl -f http://localhost:3000/health || exit 1
# → Docker runs this command periodically; exit 0 = healthy, non-zero = unhealthy
```

```yaml
# in docker-compose.yml
healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
  interval: 30s
  timeout: 3s
  retries: 3
  start_period: 10s    # grace period on startup before failures count
```

Docker exécute périodiquement la commande de vérification de santé ; l'état du conteneur devient `healthy` ou `unhealthy` selon le résultat (visible dans `docker ps`).

## En exécution vs sain (la distinction clé)

```text
RUNNING → the container's process is alive (but the APP might be hung/broken)
HEALTHY → the health check confirms the app actually WORKS (responds correctly)
→ A container can be RUNNING but NOT HEALTHY (e.g. the app deadlocked, lost its DB).
  Without a health check, the platform only knows "running" — and keeps sending traffic
  to a broken container.
```

## Pourquoi les vérifications de santé importent sur le plan opérationnel

```text
✓ ORCHESTRATORS use them: restart unhealthy containers; route traffic only to healthy ones
✓ Compose depends_on: condition: service_healthy → wait for real readiness
✓ LIVENESS (is it alive? restart if not) vs READINESS (ready for traffic? hold traffic if not)
  → Kubernetes uses liveness + readiness probes (the same concept, more granular)
✓ Prevents serving requests from broken-but-running containers
```

## Pourquoi c'est important

Comprendre les vérifications de santé Docker est important pour **exécuter des applications conteneurisées fiables**, ce qui en fait une connaissance opérationnelle précieuse.

L'idée cruciale est la distinction entre **en exécution et sain** : le processus d'un conteneur peut être **actif alors que l'application est réellement cassée** (figée, en deadlock, incapable d'atteindre sa base de données) — et sans vérification de santé, la plateforme sait seulement que le conteneur « s'exécute » et **continuera à acheminer le trafic vers un conteneur cassé**, ce qui causera des défaillances.

Les vérifications de santé résolvent cela en définissant comment vérifier que l'application **fonctionne réellement** (par exemple, en contactant un endpoint `/health`), afin que l'état du conteneur reflète la santé réelle, et non seulement la vivacité du processus.

Cela importe **opérationnellement** parce que les orchestrateurs et les outils agissent en fonction : ils **redémarrent les conteneurs non sains** (récupération automatique des figements/deadlocks) et **acheminent le trafic uniquement vers les conteneurs sains** (évitant d'envoyer des requêtes aux instances cassées), et la condition `depends_on: condition: service_healthy` de Compose utilise les vérifications de santé pour attendre une véritable disponibilité (résolvant les conditions de course au démarrage).

Comprendre la distinction connexe **liveness vs readiness** (est-il actif et devrait-il être redémarré, vs est-il prêt à recevoir du trafic) est important, car **Kubernetes utilise des sondes de liveness et de readiness** construites sur ce même concept — donc la compréhension des vérifications de santé Docker se transfère directement aux environnements orchestrés.

Puisqu'une opération fiable nécessite de distinguer « en exécution » de « fonctionne réellement » et de réagir aux conteneurs cassés-mais-en-exécution (les redémarrer, retenir le trafic), et puisque les vérifications de santé sont le mécanisme permettant cela — utilisé par les orchestrateurs pour l'auto-guérison et l'acheminement du trafic — comprendre les vérifications de santé Docker est une connaissance précieuse et pratiquement importante pour exécuter les conteneurs de manière fiable, une pratique clé pour la résilience en production qui prévient le problème courant des conteneurs cassés continuant silencieusement à recevoir du trafic, et un concept fondamental pour la façon dont les orchestrateurs maintiennent la santé des applications.