¿Cómo funcionan los health checks de Docker y por qué son importantes?

Question

Accepted Answer

Un **health check** le dice a Docker (u orquestador) cómo determinar si la aplicación de un contenedor está realmente **funcionando**, no solo ejecutándose. El proceso de un contenedor puede estar activo mientras la aplicación está rota (colgada, sin poder alcanzar su base de datos) — los health checks detectan esto para que la plataforma pueda reaccionar.

## Definiendo un health check

```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 ejecuta periódicamente el comando de health check; el estado del contenedor se vuelve `healthy` o `unhealthy` según el resultado (visible en `docker ps`).

## Ejecutándose vs healthy (la distinción clave)

```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.
```

## Por qué es importante

```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
```

## Por qué es importante

Entender los health checks de Docker es importante para **ejecutar aplicaciones containerizadas confiables**, por lo que es un conocimiento operativo valioso.

La idea crucial es la distinción entre **ejecutándose y healthy**: el proceso de un contenedor puede estar **vivo mientras la aplicación está realmente rota** (colgada, en deadlock, sin poder alcanzar su base de datos) — y sin un health check, la plataforma solo sabe que el contenedor está "ejecutándose" y **seguirá enrutando tráfico a un contenedor roto**, causando fallos.

Los health checks resuelven esto definiendo cómo verificar que la aplicación **realmente funciona** (p. ej. accediendo a un endpoint `/health`), de modo que el estado del contenedor refleje la salud real, no solo la vivacidad del proceso.

Esto importa **operativamente** porque los orquestadores y herramientas actúan en base a esto: **reinician contenedores unhealthy** (recuperación automática de cuelgues/deadlocks) y **enrutan tráfico solo a los healthy** (evitando enviar solicitudes a instancias rotas), y la condición `depends_on: condition: service_healthy` de Compose utiliza health checks para esperar a que haya verdadera disponibilidad (resolviendo carreras de inicio).

Entender la distinción relacionada **liveness vs readiness** (¿está vivo y debe ser reiniciado, vs está listo para recibir tráfico) es importante, ya que **Kubernetes utiliza liveness y readiness probes** construidas en este mismo concepto — así que entender los health checks de Docker se transfiere directamente a entornos orquestados.

Ya que la operación confiable requiere distinguir entre "ejecutándose" y "realmente funcionando" y reaccionar a contenedores rotos pero en ejecución (reiniciarlos, negar tráfico), y ya que los health checks son el mecanismo que habilita esto — utilizado por orquestadores para auto-recuperación y enrutamiento de tráfico — entender los health checks de Docker es conocimiento valioso y prácticamente importante para ejecutar contenedores de manera confiable, una práctica clave para la resiliencia en producción que previene el problema común de contenedores rotos continuando silenciosamente recibiendo tráfico, y un concepto fundamental para cómo los orquestadores mantienen la salud de la aplicación.