Egyéb informatika

A Docker konténerekkel találkozva nem telik el sok idő, míg szembesülünk Go nyelvvel vagy legalább a Go template-tel, mivel a Docker is Go nyelven készült és a Docker kliensnél is használhatunk Go template-et bizonyos kimenetek formázására. Talán már hallottál arról is, hogy lehet készíteni Go-ban olyan programokat is, amikből egyetlen bináris generálható, ami aztán könnyedén használható konténerben is. Ha minden függőségünk benne van ebben a fájlban, mivel a legtöbb esetben a konténerben levő alap Linux fájlrendszert úgysem használjuk ki, azt akár teljesen el is hagyhatjuk és egy "scratch" image-re építve elkészíthetjük az egyetlen binárist tartalmazó Docker image-ünket, így egy nagyon kis méretű image-et eredményezve. Mutatom, hogy build-elheted a legegyszerűbb Go programot, mik azok, amikre valószínűleg még szükséged lehet és mi kell ahhoz, hogy Docker konténerben is működjön a build.

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.

A Docker konténerekben időnként anélkül is el lehet veszni, hogy egy három komponensből álló parancs elemeinek kapcsolatán kellene gondolkodni és megválasztani a helyes megoldást. Bár első ránézésre egyszerűnek tűnik, van azért néhány olyan tényező, amit talán te sem ismertél. A videó befejezése után viszont már te is bevetésre készen állsz majd, hogy mindig pontosan úgy fussanak a programok a konténereidben, ahogy azt megálmodtad.

A Docker konténerekben futó alkalmazások naplóbejegyzéseit általában a "docker logs" paranccsal kérdezhetjük le.
Hogyha ezt lefutattom a parancssorban, akkor minden naplóbejegyzés ki fog kerülni a képernyőre. A kérdés az, hogy hogy kerül ide. Honnan tudja a "docker logs", hogy honnan kell a naplóbejegyzéseket lekérdezni? A mellékelt videóban bemutatom a Docker konténereknél a naplóbejegyzések kezelésének alapjait, majd benézünk a motorháztető alá, miért is működik a logok lekérdezése és hogyan érhetjük el az aktuális logokat akkor is, ha a korábbi logok mentése le van tiltva.

A múlt alkalommal megmutattam, hogyan lehet úgy Docker konténerekkel konfigurálni weboldalakat, hogy előttük van egy NginX proxy, ami a különböző domainekre érkező kéréseket továbbítja különböző konténerek felé. Ezt viszont eddig egy darab konténerrel oldottuk meg, ami tartalmazta egyszerre a "docker-gen"-t, ami generálta a konfigurációs fájlt és az NginX szervert is. A "docker-gen"-nek viszont fel kell csatoltunk a Docker socket fájlt, hogy el tudja érni a Docker API-t, amiből le tud kérni információkat, hogy le tudja generálni a konfigurációs fájlt. Ilyenkor viszont, ha valaki mégis csak be tud jutni az NginX szerveren keresztül a konténerbe, akkor gyakorlatilag minden Docker konténerünkhöz hozzáfér. Ezt elkerülendő szét fogjuk választani a "docke-gen"-t az NginX szervertől két külön konténerbe, és ezek után már csak a "docker-gen" fogja tudni elérni a Docker API-t.

A hosszú tartalmak után végre lehet szusszanni egyet a következő villámtippel. Ha Windows 10-ben szeretnél Linuxos Docker konténert futtatni, akkor a Windows Subsystem For Linux is egy jó megoldás lehet, de az ilyen gépekben kiengedett portokat nem lehet elérni a LAN hálózaton. Vagy mégis? A cikkből és a mellékelt videóból kkiderül.

Minden eddigi megközelítésünk lényege az egyszerűség volt, hogy kis lépésekben haladjunk előre. Eljött az a pont, amikor már elhagyjuk a kényelmes hoszt network-öt és a konténerek saját IP-t kapnak. Ezzel viszont bonyolódik a több weboldal elérése, amennyiben minden weboldalt külön konténerben indítunk. Bár a HTTPD-vel is konfiguráltunk proxy-t, jellemzően nem azt használjuk erre a célra, hanem például NginX-et vagy HAProxy-t. A következőkben az NginX proxy konfigurálását mutatom be dinamikusan generált konfigurációs fájllal, hiszen nem tudjuk előre a konténerek IP címeit, ráadásul meg is változhatnak időnként. Innentől kezdve minden konténert, beleértve az előző alkalmakkor konfigurált fájlfeltöltőt és letöltőt, illetve alapértelmezett weboldalt is ugyanazon a proxy-n keresztül fogjuk elérni. Bár élesben a fájlfeltöltő mögötti PHP sem a parancssori PHP-ból indított webszerverrel fog működni, ezt most hagyjuk, ahogy van és csak a proxy-ra koncentrálunk.

Az előző két cikkben szó volt egyszerű konténer indításáról felcsatolt mappákkal, fájlokkal és Docker image készítéséről. A Docker Compose-zal a felcsatolt mappát is a "volumes" blokkban definiáltuk, de valójában volume-ként inkább arra hivatkozunk, amikor a Dockerre bízzuk a mappa létrehozását, és nem is feltétlenül csak lokális fájlrendszerben lehet gondolkodni. A cikkben és a mellékelt videóban viszont csak lokális volume-okról lesz szó az előző részekben elkészült webszervert kiegészítve egy fájlfeltöltő alkalmazással, ám továbbra is a hoszt rendszer hálózatán futtatva a szolgáltatásokat. Ezért egy rettentő egyszerű HTTPD Proxy-t is konfigurálnunk kell, amivel még egy lépéssel közelebb kerülünk ahhoz a szemlélethez, amit előbb-utóbb mindenkinek meg kell ismernie, aki egyszerre több webes szolgáltatással dolgozik konténerekbe szervezve.

Folytatjuk az utunk az előző részben indított HTTPD Docker konténer után, de már saját Docker image-et is készítünk. Ez az image még egy nagyon egyszerű megoldás lesz a koncepció megértéséhez, ami még nem a végleges, éles környezetre szánt verzió, de innentől nagyon jó úton fogunk haladni afelé. Ez nem jelenti azt, hogy ne lehetne élesben is alkalmazni a leírtakat, de a legtöbb esetben ez még nem elég. Ha viszont egy statikus oldalad van, vagy egy állapotmentes alkalmazásod (pl. webes számológép, konvertáló alkalmazás), esetleg egy demo alkalmazásod, ami nem igényel konfigurációt sem, akkor már ezzel is el tudod készíteni.

Mutattam már az LXC konténereket, amik nagyon jól használhatók virtuális gépek helyett, de nem ez ami folyamatosan és elkerülhetetlenül szembejön ma már nem csak GitHub-on, de szakmai társalgásokban is. Sokkal inkább a Docker. Nem újdonság már, az I.T. szigeten is több oldalnyi cikket találhatsz a témáról. Ha még mindig nem vetted rá magad, hogy megtanuld, akkor itt a remek alkalom. Talán már megpróbálkoztál vele, de bonyolultnak érezted, nem működött. Könnyebb lehet először a hagyományoshoz hasonló módon elindítani egy programot a konténerben, majd haladni egyre konténerbarátabb megoldások felé, ám ezzel egyre inkább eltávolodni a korábban megszokottól. Ebben a cikkben és a mellékelt videóban azt mutatom be, hogyan konfigurálnánk egy Apache HTTPD webszervert több weboldalhoz konténerben futtatva, mégis egy még ismerősebb megoldással, virtuális hosztokkal.