A Composer a PHP függőségkezelője, ami szintén PHP nyelven lett megírva, és jellemzően egy composer.phar nevű fájl telepítésével használjuk a projekt gyökeréből vagy rendszermappából. Éles környezetben nem szükséges a webszerveren lennie, csak a függőségek letöltéséhez szükséges. De akkor miért is kérdés egyáltalán a Dockerrel használata? Ha tovább olvasod a cikket, hamarosan megtudod.
A programozás világában vannak olyan eszközök vagy megoldások, amiket csak egy bizonyos réteg használ vagy akár ismer. A többi programnyelven vagy adott szintű feladat esetén nincsen rá szükség. A verziókezelés nem ilyen. Gyakorlatilag a legalacsonyabb szinteken is használunk valamilyen verziókezelő szoftvert hosszú évek óta, és bár a verziókezelés a szoftverfejlesztésből indult ki, más területeken is alkalmazzák, például szöveges dokumentumok verzióinak követésére. Nem azt mondom, hogy ez az első dolog, amivel mindenkinek kezdenie kell egy fejlesztést, de leginkább nem arra kell okot keresnem, hogy miért használjam, hanem arra, hogy miért ne. Utoljára 2011-ben írtam cikket a témában, de azzal ellentétben, ebben a cikkben a verziókezelés szükségességét és értelmét próbálom körüljárni, ezzel motivációt próbálva adni azok számára, akik még mindig azt a kérdést teszik fel, hogy "mi ez és miért kezdjek neki?"
Az előző részben megmutattam, hogyan lehet statikus tartalmakat, kliensoldali webes alkalmazásokat fejleszteni és közzétenni Docker konténerben, most viszont a szerveroldali programokon a sor. Ebben az esetben az komplikálja a feladatot, hogy már nem elég a kliensnek odaadni a programfájlokat, azokat szerveroldalon kell értelmezni. Ez persze nem feltétlen jelentene önmagában problémát, mivel az értelmező és a szerver lehet egy konténerben is. PHP alkalmazásnál viszont érdemes külön konténerben futtatni a PHP értelmezőt és a webszervert. Az alábbiakban ennek mikéntjéről fogok írni.
Alap szinten nem sokat kell tudni arról, hogy milyen hálózattípusok vannak a Docker konténerek esetén. Rá lehet bízni a Dockerre, hogy hozza létre, ami szükséges, hiszen neked az eredmény kell, nem az oda vezető út. Mégis érdemes kicsit elmélyedni benne, mivel több olyan kérdésre választ adhatnak, amire nem is gondolnád, hogy kíváncsi vagy. Még nem... Olyan szituációkra gondolok, hogy miért ilyen IP-t kapott a konténer, miért nem látod az IP címét, miért nem éred el úgy, mint máskor és mi az ördög az az ingress vagy overlay és miért volt baj, hogy letörölted. Ahogy próbáltam megérteni a hálózatok működését, magam is úgy jöttem rá, hogy eddig tévedésben éltem. Úgy gondolom, hogy most már tisztábban látok, és ezt fogom összegezni a következőkben.
Amióta a témával foglalkozom, hallottam olyan véleményt, hogy a Docker csak fejlesztésre jó, élesben nem. De olyat is, hogy élesben jó, de fejlesztésre alkalmatlan. Az igazság az, hogy mindkettőre jó, de egy sor olyan dolog van, amit másképp kell csinálni. Az is igaz, hogy karddal sem kenünk kenyeret és papírvágó késsel sem vágunk fát, tehát észben kell tartani a célt és ki kell választani a legjobb eszközt. Általánosan viszont nem jelenthető ki az alkalmatlanság. Ha valaki komolyabb webfejlesztéshez szeretné használni a Dockert, előbb tisztában kell lennie a működésével, az alapjaival, és azt is el kell fogadnia, hogy a komolyabb munkákra felkészüléshez talán sokat kell dolgoznia. Egy összetettebb webalkalmazás akár több konténerből is állhat, de most az Apache HTTPD konténerrel való munkát fogom bemutatni egyszerűbb, szerveroldali szkriptet és adatbázist nem igénylő statikus oldalakkal, kliensoldali alkalmazásokkal és azok jelszóval védésével.
Különböző operációs rendszereken különböző módon telepíthető a Docker és némelyik esetben valójában egy virtuális gép indul el a háttérben, amire a Docker démon kerül, miközben a gazda operációs rendszeren van a kliens. A telepítésről a dokumentációban részletes leírás található, de fejlesztés közben a legegyszerűbb, amikor a saját desktop Linuxodon telepíted és megúszod a virtuális gépek okozta hálózati és a fájlszinkronizációs problémákat. Ha viszont Windowson futtatsz Linux konténert, elkerülhetetlen a virtuális gép. Megfelelő erőforrás esetén egy virtuális desktop Linux telepítése is megoldás lehet, de hogy egy másik hasznos szoftvert is bemutassak, ami ráadásul hasonlít a Dockerhez bizonyos szempontból, a Vagrantot fogom segítségül hívni, hogy leírjam a Docker telepítését. A gépet előre elkészítettem és elérhetővé tettem a Vagrant Cloud‑on. Az elkészítéséhez szükséges forráskódot pedig a GitHub-on. A cikkben ismertetem a Vagrant fontosabb tulajdonságait, hibalehetőségeket és a desktop Ubuntu 16.04-ben, Vagranttal telepített, Dockert tartalmazó gép telepítésének menetét.
Megjegyzés: Ubuntu 16.04 felhasználók a Vagrant telepítését és a virtuális gép használatát akár ki is hagyhatják.
A Docker újoncai között gyakran nem egészen tiszta, hogy függ össze a futtatandó alkalmazás, akár webes szolgáltatás és a működését biztosító webszerver, illetve az ahhoz szükséges komponensek, mint például a PHP értelmező. Hol találkoznak egymással és milyen szoros kapcsolat van közöttük. Az a gondolkodásmód már nem működik, hogy összeállítasz egy vagy több webszervert és szépen egymás mellé sorakoztatod a weboldalakat virtuális hosztok segítségével. Persze, meg lehet oldani, de lemondanál a Docker legnagyobb előnyeiről. A kulcs az, hogy a szoftver szemszögéből közelíted meg a problémát. A kérdés pedig, hogy ebben az esetben miből mennyire van szükség és egyáltalán miért. Túl a különböző verziószámokon kényelmi és teljesítmény kérdések is befolyásolják a döntést. Nézzük, hogyan!
Miután az ember eldönti, hogy a webszerverek és egyéb programok telepítéséhez, a saját programjainak futtatásához Dockert fog használni, még mindig kérdés, hogy ehhez mit kell telepíteni. Mik azok a programok, amikkel akár több projekt fejlesztése, tesztelése is kezelhető igény szerint párhuzamosan vagy egymás után. Természetesen az sem mindegy, hogy hol lesz a Docker telepítve. Egyáltalán magad telepíted, vagy valahol már adottak a lehetőségek és azokhoz kell alkalmazkodni. Arról, hogy hol lehet magát a Dockert üzemeltetni, korábban már írtam. Most viszont arról lesz szó, milyen programok, eszközök állnak rendelkezésre, amit érdemes ismerni, mielőtt megpróbálsz ezzel a technológiával fejleszteni.
Magyarázatból sosem elég. Mindenki más szavakból és hasonlatokból ért. Nekem pedig eltökélt szándékom volt mindig, hogy érthetővé tegyem az érthetetlent. Most ismét a híres kék bálnát, a Dockert. Fontos, hiszen az informatikusnak sem mindig informatikust kell meggyőznie egy eszköz hasznosságáról és bevezetéséről. Volt már kikötőmunkás és buborék is, de most egy talán életközelibb szemszögből szeretném megközelíteni. Képzeljük el, hogy nem is kell tudni informatikusul és még csak túlzottan elvont képekben sem kell gondolkodni, csak megérteni a való világot. Annak egy olyan szeletét, amit azért legtöbben ismerünk, vagy egy részéről reméljük, csak hallottunk. Ezután már csak el kell hinni, hogy a Docker ezt jelenti az informatikusoknak. Most nem az a célom ezzel a cikkel, hogy szakmabelieket világosítsak fel, bár lehet, közülük is hasznosítani tudja valaki a következőket. Sokkal inkább szeretném olyan módon leegyszerűsíteni a témát, hogy csak minimális, ha nem nulla informatikai előismeret kelljen hozzá.
Konténer vagy sem, a fejlesztett weblapoknak kell egy hely, ahol azok futhatnak. Erről általánosan már írtam korábban a Teszt weblap elhelyezése című cikkben, ám konténereknél egy kicsit másképp működik a dolog. Amennyire én tudom, a teljesen ingyenes szolgáltatásokat rögtön ki is húzhatjuk a lehetőségek listájáról. Leszámítva a próbaverziókat. De akkor mik az alternatívák?
Itt is minden attól függ, mire van keret és persze mi a cél. Amíg csak otthon, fejlesztéshez kell, egyszerűbb megoldások is vannak. De mi van, ha fel kell készülni arra, hogy egy nap nem csak saját gépen kell jól működnie a programnak? Mivel a konténerek, mikroszervizek esetén a program különböző részei más-más konténerben és akár gépen lehetnek, ennek van jelentősége. Tanulási fázisában persze még nem ez a cél. Mutatom, miket érdemes ismerni.