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.

Egész szám használata ciklusváltozóként sok programnyelvben gyakori, de minden programnyelven egy kicsit másképp történhet és más buktatói lehetnek. Ebben a rövid cikkben egy olyan, Bash-ben felmerülő buktatóról írok, amit talán még te sem ismertél. Tudtad-e például, hogy egy egyszerű inkrementálás vagy dekrementálás a szkript leállását okozhatja? Mondtam én...

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.

A WSL2-ről már többször volt szó, mivel lehetőséget ad Windowson a Linuxos Docker konténerek erőforrástakarékosabb használatára. A Docker telepítésével viszont még nem végeztünk a konfigurációval, mert sajnos, hacsak nem Docker desktoppal telepíted a Dockert, a konténerek hálózata ütközhet a WSL 2-es gép aktuális hálózati beállításával. Erre ugyan nincs tökéletes megoldás egyelőre, én viszont találtam egy kerülőutat, amit most meg is osztok veled.

Gyakorlati példákon keresztül bemutatom, hogyan lehet konténereket létrehozni és mi a különbség konténer és virtuális gép között. Mivel szeretném, ha mindenki számára nyilvánvaló lenne, hogy nem csak Docker konténerek léteznek, ezért az LXD-t fogom telepíteni, amivel LXC konténerket és virtuális gépeket is lehet kezelni.

A korábbi WSL-es Docker cikk folytatásaként most a frissen telepített gépek elmentésével folytatom, így bármikor vissza lehet állni egy korábbi verzióra. Beállítom az alapértelmezett felhasználót is, amit az exportáláskor elfelejt a gép, illetve végig mutatom azt is, milyen állapotai lehetnek a WSl gépeknek. Ha mentést nem is szeretnél a gépeidről, de ugyanabból a disztribúcióból többet is szeretnél telepíteni különböző célokra, akkor is érdemes tovább olvasni. A videón pedig gyakorlatban is követheted a beállításokat.

Bár a WSL 2 telepítéséhez nincs szükség Hyper-V -re, mint a Docker Desktophoz, de a VirtualMachinePlatform engedélyezése is befolyásolja a többi virtualizáló szoftver működését, mint a VirtualBox vagy a VMWare Workstation. VirtualBox esetén például le kellhet tiltani a VT-x/AMD-V opciót, vagy a következő üzenet fogadhat:

Failed to open a session for the virtual machine ubuntu-dev
Cannot enable nested VT-x/AMD-V without nested paging and unrestricted guest execution

Windows 10-ben a legegyszerűbben a Docker Desktop telepítésével futtathatsz Docker konténereket. Az előnye még, hogy nem csak Linux vagy Windows konténereket tudsz vele futtatni, hanem egyidőben mindkettőt. Bár egyszerre csak az egyiket támogatja, de a konténereid nem vesznek el, amikor a két mód között átváltasz, csak a docker parancs a kiválasztott módnak megfelelő docker démont fogja látni alapértelmezetten. Előfordulhat, hogy nem akarod engedélyezni a Hyper-V feature-t, de az alapértelmezett telepítés szerint az kötelező. Én viszont mutatok egy módszert ennek kikerülésére, persze ára is van. Ha nem szeretsz olvasni, azs em gond. Dőlj hátra és élvezd az oktatóvideót.