Hogyan indítsunk újra automatikusan egy leállt Docker konténert?

A modern szoftverfejlesztés világában a konténerizáció, és ezen belül is a Docker, mára megkerülhetetlen technológiává vált. Segítségével a fejlesztők egységes, izolált környezetben futtathatják alkalmazásaikat, garantálva a „működik nálam” ígéret teljesülését a tesztkörnyezettől egészen az éles szerverig. Azonban az alkalmazások stabilitásának és folyamatos rendelkezésre állásának biztosítása nem ér véget a konténer elindításával. Mi történik, ha egy konténer valamilyen okból kifolyólag leáll? Egy váratlan hiba, egy memóriaprobléma, vagy akár egy rendszerfrissítés okozta újraindítás mind-mind okozhatja egy kritikus szolgáltatás leállását, ami komoly üzleti károkat eredményezhet. Ebben a cikkben részletesen bemutatjuk, hogyan biztosíthatjuk a Docker konténerek automatikus újraindítását, minimalizálva ezzel a leállások idejét és garantálva a szolgáltatások folyamatos működését.

Ahhoz, hogy megértsük, miért fontos az automatikus újraindítás, képzeljük el, hogy egy weboldal szolgáltatásáért felelős konténerünk éjszaka összeomlik. Ha nincs beállítva automatikus újraindítás, a weboldal egészen addig elérhetetlen marad, amíg valaki manuálisan újra nem indítja a konténert. Ez akár órákig tartó kiesést is jelenthet. A Docker beépített mechanizmusai, valamint külső eszközök segítségével azonban proaktívan kezelhetjük ezeket a helyzeteket, biztosítva a magas rendelkezésre állást és a zavartalan felhasználói élményt.

A Docker újraindítási politikái (Restart Policies): A stabilitás alapkövei

A Docker a konténerek újraindításának kezelésére beépített politikákat kínál, amelyek a legegyszerűbb és leggyakrabban használt módszerek közé tartoznak. Ezekkel a politikákkal megadhatjuk, hogyan viselkedjen a Docker démon, ha egy konténer leáll, vagy ha maga a démon újraindul. Négy alapvető politika létezik:

no (alapértelmezett)
Ez a politika az alapértelmezett, és azt jelenti, hogy a Docker nem próbálja meg automatikusan újraindítani a konténert, ha az leáll. Ha a konténer hibával lép ki, vagy manuálisan leállítják, az leállt állapotban marad. Ez a beállítás gyakran elegendő fejlesztési környezetben, ahol a felhasználó közvetlenül felügyeli a konténereket és szándékosan indítja vagy állítja le azokat. Éles környezetben azonban ritkán megfelelő.
on-failure
Az on-failure politika csak akkor indítja újra a konténert, ha az egy nem nulla kilépési kóddal áll le. A nulla kilépési kód általában sikeres befejezést jelez, míg a nem nulla kód valamilyen hibát. Ez a politika hasznos lehet olyan batch feladatoknál, amelyeknek hiba esetén újra kell indulniuk. Lehetőség van a maximális újraindítási próbálkozások számának megadására is a max-retries paraméterrel (pl. on-failure:3). Ez megakadályozza, hogy egy folyamatosan hibázó konténer végtelen újraindítási spirálba kerüljön és feleslegesen terhelje a rendszert.
always
Ez a politika biztosítja, hogy a konténer mindig újrainduljon, amíg explicit módon le nem állítjuk. Ez magában foglalja azokat az eseteket is, amikor a konténer hibával lép ki, vagy ha maga a Docker démon újraindul. Még akkor is újraindul, ha manuálisan leállítottuk a konténert (docker stop), majd utána újraindult a Docker démon. Ez egy agresszív politika, amely a legtöbb alkalmazáshoz megfelelő, ahol a folyamatos működés kritikus.
unless-stopped
Az unless-stopped politika hasonló az always politikához, de egy fontos különbséggel: ha a konténert manuálisan leállítják (docker stop), akkor az nem indul újra automatikusan, még akkor sem, ha a Docker démon újraindul. Ha azonban a konténer valamilyen más okból (pl. hiba, erőforrás-probléma) áll le, vagy a Docker démon újraindul anélkül, hogy a konténert előzetesen leállították volna, akkor automatikusan újraindul. Ez a politika gyakran a legjobb választás éles környezetekben, mivel biztosítja az automatikus helyreállítást, de lehetővé teszi a manuális beavatkozást és a konténer végleges leállítását, ha szükséges.

Hogyan konfiguráljuk az újraindítási politikákat? Gyakorlati példák

A fenti politikákat többféleképpen is beállíthatjuk, attól függően, hogy milyen eszközzel indítjuk a Docker konténereket.

1. `docker run` paranccsal

Amikor egyetlen konténert indítunk a docker run paranccsal, a --restart flag segítségével adhatjuk meg az újraindítási politikát.


# Nincs automatikus újraindítás
docker run --name my-app --restart=no my-image

# Hiba esetén újraindul, maximum 3 alkalommal
docker run --name my-app --restart=on-failure:3 my-image

# Mindig újraindul, kivéve ha expliciten leállították, mielőtt a Docker démon újraindulna
docker run --name my-app --restart=unless-stopped my-image

# Mindig újraindul, még manuális leállítás után is, ha a Docker démon újraindul
docker run --name my-app --restart=always my-image

Fontos megjegyezni, hogy ha már futó konténeren szeretnénk módosítani az újraindítási politikát, azt a docker update paranccsal tehetjük meg:


docker update --restart unless-stopped my-app

2. `Docker Compose` használatával

A Docker Compose, amely többkonténeres alkalmazások definiálására és futtatására szolgál, szintén támogatja az újraindítási politikákat. Ezt a szolgáltatások konfigurációjában, a restart kulcs alatt tehetjük meg a docker-compose.yml fájlban.


version: '3.8'
services:
  web:
    image: nginx:latest
    ports:
      - "80:80"
    restart: unless-stopped # Az Nginx konténer újraindul, kivéve ha manuálisan leállítják

  db:
    image: postgres:13
    environment:
      POSTGRES_DB: mydb
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
    restart: on-failure:5 # Az adatbázis konténer hiba esetén maximum 5-ször újraindul
    volumes:
      - db-data:/var/lib/postgresql/data

  worker:
    image: my-worker-app
    restart: always # A worker konténer mindig újraindul
    # A worker konténer konfigurációja

volumes:
  db-data:

A fenti példában az nginx szolgáltatás unless-stopped politikával fut, a postgres adatbázis on-failure politikával (max. 5 újraindítással), míg a worker alkalmazás always politikával. Amikor a docker-compose up -d parancsot futtatjuk, a Compose gondoskodik a megadott újraindítási politikák érvényesítéséről.

Túl a beépített politikákon: Fejlettebb stratégiák és eszközök

Bár a Docker beépített újraindítási politikái hatékonyak, bizonyos esetekben további eszközökre és stratégiákra lehet szükség a még robusztusabb megoldásokhoz.

1. Systemd integráció

Linux rendszereken a Systemd egy népszerű inicializációs rendszer, amely a rendszer szolgáltatásainak kezeléséért felel. A Docker konténereket is regisztrálhatjuk Systemd szolgáltatásként, ami lehetővé teszi, hogy a konténer automatikusan elinduljon a rendszer indításakor, és a Systemd felügyelje az újraindítását.

Ez különösen hasznos, ha a Docker démon maga is újraindul, vagy ha a teljes szerver újraindul. A Systemd jobban integrálódik a rendszer többi részével, és egységes felügyeleti pontot biztosít.

Létrehozunk egy .service fájlt (pl. /etc/systemd/system/my-app.service):


[Unit]
Description=My Docker App
Requires=docker.service
After=docker.service

[Service]
ExecStartPre=-/usr/bin/docker stop my-app
ExecStartPre=-/usr/bin/docker rm my-app
ExecStart=/usr/bin/docker run --name my-app --restart=unless-stopped my-image
ExecStop=/usr/bin/docker stop my-app
Restart=on-failure
RestartSec=10
TimeoutStartSec=0

[Install]
WantedBy=multi-user.target

Ebben a konfigurációban a Restart=on-failure beállítás biztosítja, hogy a Systemd újraindítsa a szolgáltatást, ha az hibával lép ki. A RestartSec=10 megadja, hogy 10 másodpercet várjon az újraindítás előtt. Az ExecStartPre parancsok gondoskodnak arról, hogy a konténer ne ütközzön névvel, ha már létezik. Fontos, hogy a Docker --restart flagje mellett a Systemd is felügyelje az újraindítást, így kettős védelmet kapunk.

A szolgáltatás engedélyezése és elindítása:


sudo systemctl enable my-app.service
sudo systemctl start my-app.service

2. Konténer-orkesztrációs platformok (Kubernetes, Docker Swarm)

Nagyobb léptékű, komplexebb alkalmazások esetén, ahol több tíz, vagy száz konténer fut, a Systemd vagy a docker run paraméterek már nem elegendőek. Ekkor lépnek be a képbe a konténer-orkesztrációs platformok, mint például a Kubernetes vagy a Docker Swarm. Ezek a platformok alapvetően úgy vannak tervezve, hogy a konténerek életciklusát automatikusan kezeljék, beleértve az újraindítást, skálázást, terheléselosztást és öngyógyítást.

Például Kubernetesben egy Deployment automatikusan biztosítja, hogy a megadott számú konténerpéldány mindig fusson. Ha egy konténer leáll, a Kubernetes automatikusan elindít egy újat helyette. Ez egy sokkal robusztusabb és skálázhatóbb megoldás a nagyvállalati környezetek számára.

Legjobb gyakorlatok és fontos szempontok az automatikus újraindításhoz

Az automatikus újraindítás beállítása önmagában nem elegendő. Fontos, hogy figyelembe vegyünk néhány további szempontot és legjobb gyakorlatot, hogy a rendszerünk valóban stabil és megbízható legyen.

1. Idempotencia és állapotmentesség

A konténereknek idempotensnek kell lenniük, ami azt jelenti, hogy többször is elindíthatók és leállíthatók anélkül, hogy mellékhatásokat okoznának. Kerüljük az állapot tárolását a konténer fájlrendszerén belül; ehelyett használjunk külső adatbázisokat, üzenetsorokat vagy csatlakoztatott köteteket (volumes). Így egy konténer újraindítása esetén nem veszítünk adatot, és a konténer mindig tiszta állapotból indul.

2. Egészségellenőrzések (Health Checks)

Az automatikus újraindítás csak azt garantálja, hogy a konténer folyamat elindul. Azonban egy elindult konténer sem feltétlenül egészséges, vagyis az alkalmazás a konténeren belül nem feltétlenül működik megfelelően. Például egy webserver konténer elindulhat, de ha az adatbázis nem elérhető, a weboldal továbbra sem fog működni. Erre a problémára nyújtanak megoldást az egészségellenőrzések (Health Checks).

A Docker lehetővé teszi, hogy egy HEALTHCHECK utasítást adjunk meg a Dockerfile-ban, vagy a healthcheck kulcsot a docker-compose.yml-ben. Ez egy parancs, amelyet a Docker rendszeresen futtat a konténeren belül, hogy ellenőrizze az alkalmazás állapotát. Ha a parancs egy bizonyos ideig nem tér vissza nulla kilépési kóddal, a Docker a konténert „unhealthy” (egészségtelen) állapotúnak jelöli.

Példa Dockerfile-ban:


HEALTHCHECK --interval=30s --timeout=10s --retries=3 --start-period=5s 
    CMD curl --fail http://localhost/health || exit 1

Ez a health check 30 másodpercenként fut, 10 másodperc a timeout, 3 sikertelen próba után jelöli a konténert egészségtelennek, és 5 másodpercet vár a konténer indítása után az első ellenőrzésig.

Példa docker-compose.yml-ben:


services:
  web:
    image: my-web-app
    healthcheck:
      test: ["CMD", "curl", "--fail", "http://localhost/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 5s

Az orkesztrációs platformok (Kubernetes) ezt továbbfejlesztik liveness és readiness probékkal, amelyek még kifinomultabb vezérlést biztosítanak.

3. Naplózás és monitorozás

Az automatikus újraindítás csökkenti a kézi beavatkozás szükségességét, de nem oldja meg a mögöttes problémát. Ha egy konténer folyamatosan újraindul, az egy hiba jele. A naplózás és a monitorozás elengedhetetlen ahhoz, hogy kiderítsük az újraindítás okát.

Használjunk centralizált naplókezelő rendszereket (pl. ELK stack, Grafana Loki), hogy könnyen áttekinthessük a konténerek naplóit.
Monitorozzuk a konténerek erőforrás-használatát (CPU, memória, I/O) olyan eszközökkel, mint a Prometheus és Grafana, hogy észrevegyük az anomáliákat.
Állítsunk be riasztásokat, ha egy konténer egészségtelen állapotba kerül, vagy túl sokszor indul újra rövid időn belül.

A docker logs <konténer_neve> parancs az első lépés a hibakeresésben.

4. Erőforrás-korlátok

Egy folyamatosan újrainduló, hibás konténer akár az összes rendszererőforrást is lefoglalhatja, destabilizálva ezzel a teljes gazdagépet. Fontos, hogy beállítsunk erőforrás-korlátokat (CPU, memória) a konténerek számára, hogy elkerüljük az ilyen „erőforrás-mérgezést”.


# docker run példa
docker run --name my-app --memory="512m" --cpus="0.5" my-image


# docker-compose.yml példa
services:
  my-app:
    image: my-image
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: '0.5'

5. Graceful Shutdown (Elegáns leállás)

Amikor a Docker leállít egy konténert (pl. a démon leállása, vagy docker stop parancs hatására), egy SIGTERM jelet küld az első folyamatnak a konténerben. Az alkalmazásoknak úgy kell megíródniuk, hogy ezt a jelet kezelni tudják, és gracefully (elegánsan) fejezzék be a feladataikat, mentsék el az állapotukat, és zárják be a kapcsolatokat, mielőtt kilépnének. Ha az alkalmazás egy bizonyos időn belül nem reagál a SIGTERM jelre, a Docker egy SIGKILL jellel kényszeríti a leállást, ami adatvesztéssel járhat.

A stop_grace_period beállítással a docker-compose.yml-ben megnövelhetjük a várakozási időt a SIGTERM és a SIGKILL között:


services:
  my-app:
    image: my-image
    stop_grace_period: 30s # 30 másodpercet ad az alkalmazásnak a tiszta leállásra

6. Függőségek kezelése

Gyakran előfordul, hogy egy alkalmazás konténer függ egy adatbázis konténertől. Ha az adatbázis konténer leáll és újraindul, az alkalmazás konténernek képesnek kell lennie kezelni ezt az átmeneti kiesést és újra kell tudnia csatlakoznia. A docker-compose depends_on kulcsa segít a szolgáltatások indítási sorrendjének meghatározásában, de nem garantálja a függő szolgáltatás működőképességét, csupán az indítását. Éppen ezért elengedhetetlen, hogy az alkalmazások robusztusak legyenek a függőségek átmeneti elérhetetlenségével szemben (pl. újrapróbálkozásokkal).


services:
  web:
    image: my-web-app
    depends_on:
      db:
        condition: service_healthy # Indulás csak akkor, ha a 'db' szolgáltatás healthy
    # ...
  db:
    image: postgres
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5
    # ...

Gyakori problémák és hibaelhárítás

Végtelen újraindítási spirál: Ez a leggyakoribb probléma. A konténer elindul, azonnal hibával leáll, és az újraindítási politika miatt azonnal újra próbálkozik. Ez rendszererőforrás-pazarláshoz vezet.
- Megoldás: Ellenőrizze a konténer naplóit (docker logs <konténer_neve>). A hibát a logokban kell keresni. Lehet hiányzó fájl, konfigurációs hiba, nem megfelelő környezeti változó, vagy rosszul beállított health check. Érdemes az on-failure politikát használni max-retries paraméterrel, hogy elkerüljük a végtelen ciklust.
Konténer nem indul újra rendszerindításkor:
- Megoldás: Ellenőrizze, hogy a --restart unless-stopped vagy --restart always flaget használta-e. Ha Docker Compose-t használ, győződjön meg róla, hogy a restart kulcs megfelelően be van állítva, és a docker-compose up -d parancsot futtatta. Ha Systemd-t használ, ellenőrizze a .service fájlt és győződjön meg róla, hogy a szolgáltatás engedélyezve (systemctl enable) van.
on-failure nem a várt módon működik: A konténer leáll, de nem indul újra.
- Megoldás: Ellenőrizze a konténer kilépési kódját (docker inspect <konténer_neve> | grep ExitCode). Ha a kilépési kód nulla, akkor az on-failure politika nem fogja újraindítani, mivel sikeres kilépésnek minősül. Ez esetben valószínűleg egy másik restart policy-re van szükség (pl. unless-stopped vagy always).

Összegzés: A stabilitás kulcsa a tudatos konfiguráció

A Docker konténerek automatikus újraindításának képessége alapvető fontosságú a modern, elosztott rendszerek stabilitásának és rendelkezésre állásának biztosításához. A beépített restart politikák (no, on-failure, always, unless-stopped) egyszerű, de hatékony eszközöket kínálnak a konténerek életciklusának menedzselésére. A unless-stopped politika különösen népszerű, mivel egyensúlyt teremt az automatikus helyreállítás és a manuális kontroll között.

Azonban a puszta újraindítási stratégia önmagában nem elegendő. A robusztus konténer üzemeltetés megköveteli az idempotens alkalmazásfejlesztést, a gondosan beállított egészségellenőrzéseket, a hatékony naplózást és monitorozást, az ésszerű erőforrás-korlátokat, a graceful shutdown támogatását és a függőségek tudatos kezelését. Nagyobb léptékben a Systemd integráció vagy a konténer-orkesztrációs platformok (mint a Kubernetes) nyújtanak még átfogóbb megoldásokat. Az említett hibaelhárítási tippek pedig segítenek gyorsan reagálni a felmerülő problémákra.

A tudatos tervezés és konfigurálás révén elkerülhetjük a váratlan leállásokat, biztosíthatjuk szolgáltatásaink folyamatos működését, és minimalizálhatjuk a kézi beavatkozás szükségességét. Így a Docker konténerek valóban gondtalanul futhatnak, hozzájárulva a modern IT infrastruktúra megbízhatóságához.