Docker konténerek helyes leállítása adatvesztés nélkül

Van egy fajta bizalmatlanság a Docker konténerekkel szemben, aminek az egyik oka az is lehet, hogy ha a Docker image-et nem jól készítjük el, vagy az indításkor rosszul használjuk a paramétereket, akár olyan jelenséghez is vezethet, hogy a konténer leállításakor adatok sérülnek és az alkalmazás legközelebb akár el sem indul. Ez persze nem egy mindennapos dolog, de tény, hogy aki konténerekben szeretne programokat futtatni, jobban meg kell ismerkedjen a Linuxszal, a processzek közti kommunikációval, signalok kezelésével és azzal, hogy ezeket hogyan befolyásolják a Dockerfile-ban definiált SHELL, ENTRPYOINT és CMD direktívák. Ha te is szeretnéd elkerülni az említett problémát, vagy csak régóta töprengsz azon, mi történik a Docker konténerek leállításakor, akkor ez a cikk neked készült.

Tartalomjegyzék

• Stop timeout
• Signal küldése
• 1-es processzazonosító
• PID névtér elhagyása
• Init processz használata
  • Tini program használata
  • Init flag használata
• A HTTPD szerver kezeli a signalokat
• HTTPD wrapper szkript
  • HTTPD shell szkriptbe ágyazva hibásan
  • HTTPD shell szkriptbe ágyazva exec-kel
  • HTTPD shell szkriptbe ágyazva trap-pel
• További releváns parancsok
• Végszó

Megjegyzés Ha még nem láttad a shell signal-ok működésével és a konténeren belüli parancs összeállításával kapcsolatos cikkeket/videókat, akkor érdemes azokkal kezdeni.

A cikkben használt forráskódokat megtalálod a GitHub-on:
https://github.com/itsziget/tutorial-linux-signals/tree/step-03

Stop timeout

[Tartalom]

Nézzünk egy teljesen egyszerű példát, amikor Docker konténerben futtatok egy HTTP szervert pythonnal, majd megpróbálom leállítani a konténert. A leállítás parancsot a “time” parancsnak adom át, hogy lássam, pontosan mennyi ideig tart.

Ahelyett, hogy a konténer gyorsan leállna, várni kell 10 másodpercet. A docker stop --help parancsot futtatva láthatjuk, hogy van egy --time paraméter, aminek az alapértelmezett értéke 10 másodperc. Ezért tartott ennyi ideig a leállítás, mivel a HTTP szerver nem volt hajlandó magától leállni, így a Docker erőszakkal állította le. Ez annyit jelent, hogy ha a konténerben futó programnak 11 másodpercig tartott volna szabályosan leállni, erre nem volt lehetősége, viszont a leállításkor felülírható a 10 másodperces timeout. Ha pedig az indításkor tudjuk, hogy mennyi időre van szüksége a programnak általában a leállításhoz, már a docker run-nak is megadható a --stop-timeout paraméter.

Signal küldése

[Tartalom]

Valójában, ha a docker run parancs paraméterei között a "stop"-ra keresünk, akkor találhatunk még egy fontos paramétert:

A --stop-signal tehát azt határozná meg, hogy milyen signalt küldjön a konténerben futó programnak a Docker, amikor a "stop" parancsot kiadjuk. Ez alapértelmezetten a TERM vagy SIGTERM nevű signal. Ezt pedig már bemutattam korábban, tehát akkor nézzük meg, hogy hajlandó-e leállni a HTTP szerver ennek a signalnak a hatására konténer nélkül vagy sem.

Egy új terminálban pedig lekérdezzük a processz azonosítóját és a TERM signal-lal leállítjuk

Erre viszont láthatóan azonnal leállt a szerver, tehát akkor mi a különbség?

1-es processzazonosító

[Tartalom]

Indítsuk el újra a Dockeres verziót és nézzünk be a konténerbe. A következő kódban a COLUMNS változót is átadjuk a konténernek, így a hoszt rendszer termináljának szélességét veszi figyelembe a konténerben futó "ps" a kimenet megjelenítésekor.

A HTTP szerver az 1-es azonosítót kapta. Linuxon az 1-es piddel rendelkező processz egyfajta mindenható a saját kis univerzumában, ami jelen esetben a konténer. Nem lehet csak úgy leállítani, hacsak közvetlenül le nem kezeli a TERM signalt. Ezt pedig a Pythonból futtatott HTTP szerver nem teszi meg, így erőszakkal kellett leállítani a KILL signallal.

Mi lehet akkor a megoldás?

• Vagy le kell kezelnünk a saját programunkban a signalokat
• Vagy el kell érnünk, hogy a program ne az 1-es azonosítót kapja, de mégis megkapja a „docker stop” által küldött signalt is.

PID névtér elhagyása

[Tartalom]

A konténerben a processz (PID) névtér miatt van, hogy 1-essel kezdődik újra a processzeknek a számozása és a gépen levő többi processzt nem is láthatjuk a konténerből. Kérhetjük viszont a hoszt rendszer PID névterét, bár ezzel elveszítünk egy fajta izolációt.

Emiatt a http szerverünk nem lesz még a konténeren belül sem 1-es azonosítójú, tehát működik az alapértelmezett action a TERM signalra.

Init processz használata

[Tartalom]

A hoszt rendszer processz névterének használata nem lehet mindig megoldás, hiszen nem véletlenül szeretnénk a hosztot elrejteni a konténerekben futó programok elől. Nyilván egy általunk írt programnál le tudjuk kezelni a signalokat, de már kész binárisokat nem fogunk módosítani. Marad tehát, hogy egy olyan processzt indítunk, ami az 1-es azonosítót kaphatja, és elindítja a signalokat nem kezelő programot egy 1-nél nagyobb pid-del. Erre pedig vannak kész megoldások.

Tini program használata

[Tartalom]

Először is szükségünk lesz egy Dockerfile-ra mondjuk a „docker/tini” mappában.

Ezzel telepítjük a „tini” programot és beállítjuk entrypoint-nak azért, hogy akár a CMD direktívában megadott, akár a „docker run” -nak átadott utasítás a tininek legyen átadva paraméterként. De nem muszáj így írni, akár a CMD-nek is átadhatnánk együtt az egész parancsot. Ezután pedig nincs más hátra, mint buildelni az image-et, futtatni és megnézni, mik futnak a konténerben.

A tini program megkapja az 1-es azonosítót, de el is kapja a signalokat és továbbítja a htttp szerver felé, ami már leállhat az alapértelmezett action hatására.

Init flag használata

[Tartalom]

Valójában még a tini programot sem kell telepíteni a konténerben. A Docker 1.13-as verziója óta, tehát 2017-től létezik a „docker run”-hoz az --init flag, ami gondoskodik a tini elindításáról.

Itt viszont már „docker-init” néven szerepel a tini.

A HTTPD szerver kezeli a signalokat

[Tartalom]

Vannak olyan programok, amiknél nem kell trükköznünk, mert alapból kezelik a signalokat. Ilyen például a httpd. A következő kód pedig megmutatja, hogy bár 1-es azonosítót kapott, mégis gyorsan leállt. A HTTPD dokumentációja pontosan leírja, melyik signal milyen célt szolgál.

HTTPD wrapper szkript

[Tartalom]

Előfordulhat viszont viszont, hogy szeretnénk a httpd indítása előtt elvégezni pár módosítást, esetleg konfigurációs fájl beállítást, vagy jelen példában egyszerűen csak az index.html lecserélését. Erre is van megoldás, de sajnos el is lehet rontani egy már jól működő image-et. Mutatok pár példát jó és rossz megoldásra is. A Dockerfile a következő lesz a "docker/httpd" mappában:

• A procps csomag telepítésével lesz "ps" parancs a konténerben, amivel nézegethetjük a processzek listáját.
• Az ARG direktívával a docker build-nek adhatunk át paramétereket, amivel különböző image-eket tudunk generálni.
• A VERSION alapján a "start-wrong.sh", "start-exec.sh" vagy "start-trap.sh" lesz felmásolv az image-be.
• A STOPSIGNAL direktívának az azonos nevű build agumentum változóját adjuk át, ezzel a "docker run"-nál is megadtahtó stop signalt előre definiálva. Ez már az eredeti image-ben is benne van fix értékkel, de szükségünk lesz majd később a változtatására

A "test.sh" szkript, ami a konténerek törlésében, buildelésében és indításában segít, a következőképpen néz ki:

Itt tehát a signal nevében a "SIG" prefix elhagyható lesz a második paraméterben, az első paraméter pedig a felmásolandó script nevének vége (wrong, exec vagy trap).

HTTPD szerver shell szkriptbe ágyazva hibásan

[Tartalom]

Lehetne egy ilyen start szkriptet írni "start-wrong.sh" néven:

Semmi mást nem tesz, mind módosítja az index.html tartalmát, majd elindítja a HTTPD szervert. A baj csak az, hogy a signalokat a "docker stop"-tól a bash szkript kapja meg, az viszont nem kapja el őket és így nem is továbbítja a HTTPD felé. Ez ki is derül, amint indítjuk a konténert a test.sh szkripttel:

Így ismét 10 másodperc alatt áll le a szerver, mivel az 1-es számú processz a bash szkript, tehát ez tényleg egy rossz megoldás volt, de jöjjenek a jók!

HTTPD szerver shell szkriptbe ágyazva exec-kel

[Tartalom]

Az előző problémára megoldás a bash-ban az „exec” utasítás használata. Az új, „start-exec.sh” nevű start szkript-ben a httpd indítását tehát "exec" utasítással kell kezdeni a "start-exec.sh" szkriptben:

Ennek hatására a httpd át fogja venni a szülő processz helyét az 1-es azonosítóval. A következő parancsokkal indítva a konténert, majd a processzeket listázva látható is, hogy a "bash" szkriptnek már nyoma sincs, így a "httpd" a saját módszerével kezelheti a signalokat:

Ahogy pedig az várható volt, a konténer rövid időn belül leállt.

HTTPD shell szkriptbe ágyazva trap-pel

[Tartalom]

Igazából az exec utasítás használata már megoldotta minden problémánkat, amennyiben az execnek átadott program kezeli a signalokat, de ha nem ez a helyzet és nem elég az --init flag mert indításkori módosításra is szükség van, vagy egynél több programot szeretnél a háttérben indítani, akkor jó tudni, hogy exec hiányban hogyan működik a wrapper szkript. Igaz, a több processz indítását érdemes elkerülni, de ha mégsem lehet, akkor is használható a "supervisord".

A HTTPD ugyan kezeli a signalokat, de ha nem ő az 1-es processz, akkor továbbítani kell neki minden signalt. Ehhez nem elég a trap és a kill parancs használata, ahogyan korábban bemutattam. Nézzük a problémákat.

• A HTTPD docker konténer nem a TERM, hanem a WINCH signalra áll le, amit a HTTPD arra használ, hogy a leállás előtt megvárja az éppen folyamatban levő HTTP kérések befejezését, például egy nagy fájl letöltését.
• Az init szkriptünket életben kell tartani, különben az egész konténer leáll
• Az életben tartáshoz a ciklusban futó sleep helyett a beépített wait parancsot használjuk, ami várakozik a háttérben futó processzekre anélkül, hogy akadályozná, késleltetné a signalok kezelését.
• A wait parancs viszont akkor is leáll, ha egy trap-pel kezelt signalt küldünk, ezért ezt kezelni kell és egy újabb wait-et indítani.
• A WINCH signal az esetünkben a fentiek mellett is (amennyire én tudom) csak akkor lesz kezelve, ha a kérdéses processz már terminált, ami nyilván nem segít, ezért a WINCH signalt egy másikra kell cserélni a Dockerile STOPSIGNAL direktívájában, majd átalakítani WINCH-re.