Πώς λειτουργούν οι Docker health checks και γιατί είναι σημαντικοί;

Question

Accepted Answer

Ένα **health check** λέει στο Docker (ή σε έναν orchestrator) πώς να προσδιορίσει εάν η εφαρμογή ενός container λειτουργεί πραγματικά, όχι απλώς εκτελείται. Η διεργασία ενός container μπορεί να είναι ενεργή ενώ η εφαρμογή να είναι broken (κρεμασμένη, δεν μπορεί να φτάσει τη βάση δεδομένων της) — τα health checks ανιχνεύουν αυτό, ώστε η πλατφόρμα να μπορέσει να αντιδράσει.

## Ορισμός ενός 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 εκτελεί περιοδικά την εντολή health-check· η κατάσταση του container γίνεται `healthy` ή `unhealthy` με βάση το αποτέλεσμα (ορατό στο `docker ps`).

## Running vs healthy (η κύρια διάκριση)

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

## Γιατί τα health checks έχουν σημασία λειτουργικά

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

## Γιατί έχει σημασία

Η κατανόηση των Docker health checks είναι σημαντική για την **εκτέλεση αξιόπιστων containerized εφαρμογών**, οπότε είναι πολύτιμη λειτουργική γνώση.

Η κρίσιμη σκέψη είναι η διάκριση μεταξύ **running και healthy**: η διεργασία ενός container μπορεί να είναι **ζωντανή ενώ η εφαρμογή είναι πραγματικά broken** (κρεμασμένη, deadlocked, δεν μπορεί να φτάσει τη βάση δεδομένων της) — και χωρίς ένα health check, η πλατφόρμα γνωρίζει μόνο ότι το container "τρέχει" και θα **συνεχίσει να δρομολογεί κίνηση προς ένα broken container**, προκαλώντας αποτυχίες.

Τα health checks λύνουν αυτό καθορίζοντας πώς να επαληθευτεί ότι η εφαρμογή **λειτουργεί πραγματικά** (π.χ. hitting ένα `/health` endpoint), ώστε η κατάσταση του container να αντικατοπτρίζει πραγματική υγεία, όχι απλώς process liveness.

Αυτό έχει σημασία **λειτουργικά** επειδή οι orchestrators και τα εργαλεία ενεργούν σε αυτό: **επανεκκινούν unhealthy containers** (αυτόματη ανάκαμψη από κρεμάσματα/deadlocks) και **δρομολογούν κίνηση μόνο σε healthy containers** (αποφεύγοντας την αποστολή αιτημάτων σε broken instances), και το `depends_on: condition: service_healthy` του Compose χρησιμοποιεί health checks για να περιμένει πραγματική readiness (λύνοντας startup races).

Η κατανόηση της σχετικής διάκρισης **liveness vs readiness** (είναι ζωντανό και πρέπει να επανεκκινηθεί, έναντι είναι έτοιμο να λάβει κίνηση) είναι σημαντική, καθώς το **Kubernetes χρησιμοποιεί liveness και readiness probes** χτισμένα σε αυτήν την ίδια έννοια — οπότε η κατανόηση των Docker health checks μεταφέρεται απευθείας σε orchestrated περιβάλλοντα.

Επειδή η αξιόπιστη λειτουργία απαιτεί διάκριση "running" από "πραγματικά λειτουργεί" και αντίδραση σε broken-but-running containers (επανεκκίνησή τους, στέρηση κίνησης), και επειδή τα health checks είναι ο μηχανισμός που επιτρέπει αυτό — χρησιμοποιούμενο από orchestrators για self-healing και traffic routing — η κατανόηση των Docker health checks είναι πολύτιμη, πρακτικά-σημαντική γνώση για την αξιόπιστη εκτέλεση containers, μια κύρια πρακτική για production resilience που αποτρέπει το κοινό πρόβλημα των broken containers να συνεχίζουν σιωπηλά να λαμβάνουν κίνηση, και μια έννοια θεμελιώδης στο πώς οι orchestrators διατηρούν την υγεία της εφαρμογής.