shell-signal

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.

Az előző alkalommal végigjártuk a konfigurációs fájlok újratöltésének módját SHELL szkriptekben, amihez a HUP signalt használtuk, de ennél sokkal több signal létezik. A videóbann bemutatok néhányat, amit talán még nem is hallottál, valamint arra is látsz majd példát, hogyan lehet az egyik processzből továbbítani egy másik felé a jeleket. Ez felhasználható arrra is, hogy egy több processzt indító szkript a leszármazottakat is leállítsa megfelelően, vagy éppen a leszármazottak jelezzenek a szülőnek, hogy már leállhat ő is.

Korábban megmutattam, hogy tölti újra az NginX proxy a konfigurációs fájlt, miután a docker-gen újragenerálta. Ezt a módszert saját szkripteknél is lehet alkalmazni, de a használt parancs nem működik automatikusan, hanem az egyes programoknak maguknak kell lekezelni, hogy mit kezdenek a nekik küldött utasítással. Utasítások alatt pedig most a signalokat, magyarul jeleket értjük, amikből több is létezik, most viszont kifejezetten arra fogunk koncentrálni, amit a háttérben futó démon programoknál jellemzően a konfigurációs fájl újratöltésére használunk. A videóban megmutatom, hogyan tudsz saját szkriptet írni, ami menet közben képes utasításra leálllás nélkül változtatni a beállításain.