Kuinka Docker-terveystarkistukset toimivat ja miksi ne ovat tärkeitä?

Question

Accepted Answer

**Terveystarkistus** kertoo Dockerille (tai orkestroijalle), kuinka määrittää, onko säiliön sovellus todella **toiminnassa**, ei vain käynnissä. Säiliön prosessi voi olla käynnissä samalla kun sovellus on rikki (jumittunut, ei pääse tietokantaansa) — terveystarkistukset havaitsevat tämän, jotta alusta voi reagoida.

## Terveystarkistuksen määrittäminen

```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 suorittaa terveystarkistuskomentoa säännöllisesti; säiliön tila muuttuu `healthy` tai `unhealthy` -tilaksi tuloksen perusteella (näkyvissä `docker ps` -komennossa).

## Käynnissä vs terve (ratkaiseva ero)

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

## Miksi terveystarkistukset ovat tärkeitä operatiivisesti

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

## Miksi se on tärkeää

Docker-terveystarkistusten ymmärtäminen on tärkeää **luotettavien konteilla toimivien sovellusten ajamiselle**, joten se on arvokas operatiivinen tieto.

Ratkaiseva oivallus on ero **käynnissä ja terve** -tilojen välillä: säiliön prosessi voi olla **elossa samalla kun sovellus on todella rikki** (jumittunut, deadlock, ei pääse tietokantaansa) — ja ilman terveystarkistusta alusta tietää vain, että säiliö on "käynnissä" ja **jatkaa liikenteen reitittämistä rikkinäiseen säiliöön**, mikä aiheuttaa häiriöitä.

Terveystarkistukset ratkaisevat tämän määrittelemällä, kuinka varmistaa, että sovellus **todella toimii** (esim. osumalla `/health` -päätepisteeseeen), jotta säiliön tila heijastaa todellista terveyttä, ei vain prosessin elinkaarta.

Tämä on **operatiivisesti** tärkeää, koska orkestroijat ja työkalut toimivat sen perusteella: ne **käynnistävät uudelleen epäterveita säiliöitä** (automaattinen palautuminen jumituksista/deadlokkeista) ja **reitittävät liikenteen vain terveisiin säiliöihin** (välttäen pyyntöjen lähettämisen rikkinäisiin instansseihin), ja Composen `depends_on: condition: service_healthy` käyttää terveystarkistuksia odottaessaan todellista valmiutta (ratkaisee käynnistyskilpailut).

Siihen liittyvän **elinkaari vs valmiuden** erottelun ymmärtäminen (onko se elossa ja pitääkö se käynnistää uudelleen, vs onko se valmiina vastaanottamaan liikennettä) on tärkeää, koska **Kubernetes käyttää elinkaari- ja valmiustutkimuksia** samaan käsitteeseen perustuen — joten Docker-terveystarkistusten ymmärtäminen siirtyy suoraan orkestroiduihin ympäristöihin.

Koska luotettava toiminta vaatii eron tekemisen "käynnissä" ja "todella toiminnassa" välille ja reagoimisen rikkinäisiin mutta käynnissä oleviin säiliöihin (käynnistämällä ne uudelleen, pidättämällä liikennettä), ja koska terveystarkistukset ovat mekanismi, joka mahdollistaa tämän — jota orkestroijat käyttävät itsekorjaamiseen ja liikenteen reitittämiseen — Docker-terveystarkistusten ymmärtäminen on arvokas, käytännöllisesti tärkeä tieto säiliöiden luotettavalle ajamiselle, keskeinen käytäntö tuotannon kestävyydelle, joka estää yleisen ongelman, jossa rikkinäiset säiliöt jatkavat vaietaan liikenteen vastaanottamista, ja käsite, joka on perustavanlaatuinen sille, kuinka orkestroijat ylläpitävät sovelluksen terveyttä.