În mod implicit, Docker consideră că un container este ‘sănătos’ și funcțional atâta timp cât procesul său principal (PID 1) nu a crăpat. Cu toate acestea, o aplicație Java sau Node.js poate fi blocată într-o buclă infinită, o conexiune la baza de date poate fi căzută sau serverul se poate afla încă în procesul lung de încărcare de 30 de secunde.
Directiva HEALTHCHECK instruiește motorul Docker să ruleze periodic o comandă de verificare în interiorul containerului (de exemplu: o cerere HTTP pe un endpoint intern de tip `/healthz` prin curl sau wget).
Dacă verificarea returnează succes (exit code 0), containerul este marcat ca `healthy`. Dacă eșuează de un număr configurabil de ori, starea devine `unhealthy`, permițând orchestratoarelor (Docker Compose, Docker Swarm, Kubernetes) să redirecționeze traficul sau să repornească automat containerul defect.
Sintaxă, opțiuni și concepte cheie
| Opțiune / Concept | Descriere practică |
|---|---|
--interval= |
Frecvența de rulare a verificării (implicit: 30s). |
--timeout= |
Timpul maxim acordat comenzii înainte de a fi considerată eșuată (implicit: 30s). |
--start-period= |
Perioada de grație la pornire în care eșecurile nu sunt contorizate (ex: 40s pentru inițializare). |
--retries= |
Numărul de eșecuri consecutive necesare pentru a declara starea `unhealthy` (implicit: 3). |
CMD curl -f http://localhost:8080/health || exit 1 |
Comanda tipică de testare cu returnare de cod de eroare Unix. |
Exemple practice și cod
Exemplul 1: Configurarea HEALTHCHECK în Dockerfile pentru o aplicație web
Sintaxa corectă cu perioadă de grație la pornire.
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
# Verificare la fiecare 20s cu perioadă de grație de 15s la pornire:
HEALTHCHECK --interval=20s --timeout=5s --start-period=15s --retries=3 \
CMD wget --no-verbose --tries=1 --spider http://127.0.0.1:3000/api/health || exit 1
CMD ["node", "server.js"]Rezultat & Impact
Docker afișează starea 'healthy' și garantează că aplicația răspunde corect la cereri.Greșeli frecvente și bune practici
- Folosirea utilitarului `curl` în imagini alpine ultra-ușoare unde curl nu este instalat, ceea ce face ca verificarea să eșueze permanent din lipsa binarului (folosiți `wget` sau un script Node/Python).
- Setarea unui timeout prea scurt pe aplicații cu timpi mari de inițializare, cauzând marcarea prematură ca `unhealthy` și cicluri infinite de restart.