Mese a Dockerről

Amikor az ember megpróbál egy teljesen új témát bevezetni, problémát jelenthet, hogyan is kezdjen neki, mennyire induljon az alapoktól. Én is így jártam az előző, és egyben első, Dockerről szóló bejegyzésemnél. A visszajelzések felhívták rá a figyelmem, hogy valószínűleg nem volt teljesen érthető és világos, hogy mi is az a Docker és miért jó ez neked. Április 21-én előadást tartok a témában Szegeden a Networkshop konferencián, aminek főpróbájaként a könyvtáros kollégáknak is volt lehetőségem bemutatni a témát. Erre az alkalomra egy olyan, érthetőbb bevezetővel kezdődő prezentációt készítettem, ami ábrákkal teszi felfoghatóbbá a Dockert és annak világát. Ezt a bevezetőt hoztam el cikk formájában.

A kikötőmunkás

Kezdjük az elejétől. A Docker szó jelentése angolul dokkmunkás, kikötőmunkás. Erre utaltam az előző cikk címével is. Ezt a koncepciót követve a többi fogalom is a kikötővel kapcsolatos. Mi történik egy kikötőben? Például különféle gyártók, cégek árukat visznek szállítás céljából. A "shipping", azaz szállítás fogalom a fejlesztésnél sem ismeretlen, csak itt az áru a szoftver, ami a fejlesztőtől eljut a végfelhasználókig. A hajó, azaz "ship" az egyszerűség és a példa kedvéért legyen most csak a szerver. A dokkmunkások összeszedik az árut és valamilyen rendszer alapján (pl. külön konténerben XY Rt. és külön YX Rt. termékei.) feltöltik az üres konténereket, amiket aztán átemelnek a hajóra, ami a célállomásra viszi a termékeket. A konténereket aztán felnyitják és az áruházba vagy már a felhasználóhoz viszik a tartalmukat. Ez a logika nagy részt ráhúzható a Dockerre is.

A Docker előtt

A fejlesztőtől minden esetben el kell jutnia a programnak a felhasználóig. De hogyan történik ez leegyszerűsítve egy Docker nélküli világban, vagy legalábbis hasonló technológia hiányában?

• A fejlesztő elkészíti a webalkalmazást, amit szépen "bedobozol", mellékelve a telepítési útmutatót és a program rendszerigényeit.
• A rendszergazda, vagy aki a program telepítéséért felel, megteremti a körülményeket. Választ egy szervert,
  vagy, ha még nincs megfelelő, akkor létrehoz egyet. Ez nem mindig egyszerű, így erősen gondolkodóba eshet.
• Az alkalmazás felkerül egy szerverre, ahonnét majd a felhasználók elérhetik.

A sorrend persze annyiban módosulhat, hogy amennyiben a program végső helye előre ismert, előfordulhat, hogy a programozónak ezt a környezetet szem előtt tartva kell elkészítenie a terméket. Akárhogy is nézzük, valaki szívni fog.

De mi változik a Dockerrel?

Dockerrel

• A fejlesztő tudja, hogy miként lehet az alkalmazása a leghatékonyabb és így készíti el a programot. Ismeri a program igényeit, függőségeit, és ezeket leírja egy fájlban. Ez a fájl a Dockerfile. A Dockerfile tartalma utasítások sora, mint egy TODO lista. Magába foglalja a telepítési lépéseket és a futó programkörnyezet egyes jellemzőit.
• Mr. Docker remekül tud olvasni ezen a nyelven, ezért megérti a fájl tartalmát és elkészíti a csomagot, ami tartalmazza a fejlesztő munkáját és annak összes függőségét, például a webszerver szoftvert (HTTPD, NginX, stb...). Ezt a csomagot hívjuk "image"-nek. Ez egyfajta sablon.
• A rendszergazda már könnyebb helyzetben van, mert optimális esetben szinte gondolkodnia sem kell, csak letölti a Docker által elkészített csomagot, majd ezt elindítja bármelyik szerveren, amelyiken a Docker telepítve van.
• Ami ekkor elindul, azt hívjuk konténernek, amibe be van zárva minden benne futó program.

Itt visszautalnék a korábban említett példára, ahol a konténerből a dokkmunkások kipakolták az árut. A szoftverkonténereknél ez a lépés elmarad. A konténer az a végső állapot, amiben a program leéli életét. Ez egy biztonságosabb, rugalmasabb környezet. Ennek szemléltetésére rövid ideig felhagynék a "konténer" elnevezéssel és tekints rá úgy, mint egy buborékra.

Konténer, mint buborék

A szerverről belelátsz a buborékba, de abból semmi nem lát ki. Szükség esetén ajtókat nyithatsz a buborékon meghatározott célok felé. Ez lehet egy másik buborék, illetve annak tartalma, vagy akár a külvilág, de mindig csak arra nyílik ajtó, amerre te megnyitod.

Ha már ezekben a buborékokban szoftverek vannak, általában egy gépen nem csak egy szoftver működik. Sőt, nem csak egy komponensből állhat egy szoftver, amiket szintén indokolt lehet külön egységbe zárni a biztonság és a könnyebb változtatás, skálázhatóság kedvéért.

A buborékok tehát elkezdenek szépen osztódni, szaporodni, ahogy egyre több program fut a gépen. Ráadásul nem csak, hogy több komponensből állhat egy alkalmazás, hanem egy komponensből is szükség lehet több példányra a terhelés elosztása érdekében. Ezek a példányok még csak nem is kell, hogy ugyanazon a gépen legyenek fizikailag, mégis megtalálják azokat a velük kommunikáló programok.

Oké, ha már volt konténer és buborék, akkor vegyünk példát a való életből is. Amikor egy szupermarketben egy sor pénztár van, és egyre több vásárló érkezik, akkor nyitnak egy új pénztárt, majd bemondják a kihangosítóban, hogy "Kedves vásárlóink! Megnyitottuk a 2-es pénztárt is." Ezzel odairányítva az új vásárlókat, de lehet, hogy az 1-es pénzártól is átcsábulnak vásárlók, látva, hogy a 2-esnél rövidebb a sor. Így pedig eloszlik a terhelés. Ha valamit csak egy bizonyos pénztáros tudna elvégezni, akkor klónozni kellene őt. Ez a komponensek több példányban futtatása.

Következtetés

Mint minden példa, ez sem tökéletes, hiszen egy ideális esetet modellez, de ez a kiindulópont. Ahogy a két, folyamatokat ábrázoló képből is kitűnik, a Dockeres verzióban látszólag hosszabb az út a fejlesztőtől a felhasználóig, de mindenkinek tisztább a feladata, és a saját területén nagyobb a szabadsága. A folyamatok nagy része automatizálható és a környezet reprodukálható.

Az egyes szoftverek kipróbálása annyival egyszerűsödik, hogy egy-egy fogalommal, technológiával jóval előbb megismerkedhetsz és ehhez nincs szükséged speciális ismeretekre. Persze a komolyabb felhasználáshoz kénytelen leszel megtanulni, de addigra már lesz motiváció.

Jó, jó, de mire jó?

Jólvan, szövegeltem eleget, de gondolom, mindenki a csattanót várja, hogy konkrétan miért is jó ez az egész. Miért lehet ezzel jobban dolgozni, ha egyáltalán jobban lehet. Ezt szerintem példák útján lehet megérteni, mert a Docker sem egy aranytojást tojó tyúk, de még csak nem is arany buborékot tojik. Nem attól lesz egyértelműen jobb egy program, hogy azt Docker image-ként készítették el, de egyértelműen ad egy módot arra, hogy sok szempontból megkönnyítsd az életed.

• Ha kedved tartja, elindítasz egy PHP 7.1-et igénylő parancssori programot, majd megszabadulsz a felesleges verziótól, ha kell a hely:
  
  docker run --rm -v `pwd`:`pwd`:ro --workdir `pwd` php:7.1 test.php
  docker rmi php:7.1

  Ha ez a program valami aljas módon fájlokat akart volna törölni, írni a gépen, nem tudott volna, mert az "ro" kapcsolóval csak read only módban kapta meg a mappát.

• Bonyolultnak találtam a hivatalos PHP image-eket, mert tudni kell előre egyedi modulok telepítésénél azok függőségeit, ezért elkészítettem a saját verzióm, ami ezt kiterjeszti további szkriptekkel. Ez automatikusan frissül, amikor a hivatalos image-hez hibajavítás érkezik.
• Elkészítettem egy saját HTTPD image-et is, amit még nem publikáltam, de a saját projektjeimhez egyszerűbben fel tudom használni, így nem kell ugyanazokat a lépéseket újra és újra megtennem. Egyszer elkészült és azt bármikor, bármelyik projektnél alkalmazom.
• Ha kijön egy frissítés a PHP-hez, és az én verzióm is frissül, akkor az azt használó projekt frissítése ennyiből áll:
  
  docker-compose pull
  docker-compose up -d
• Ha kiderül, hogy bármelyik komponensből új verziót kell használnod, akkor kicseréled az image-et a konfigurációs fájlban, és kipróbálod teszt környezetben. Lefuttatod rá a teszteket, és ha minden rendben van, akkor használhatod.
• Ha rájössz, hogy az a program mégsem kell, egy mozdulattal letörlöd, és nyoma sem marad.
• Minden image rétegekből épül fel, és több image is épülhet ugyanarra az alap rétegre. Így lehet, hogy már letöltötted a 300 megás image-et, de egy másik már csak 15 megát tölt le, mert a többit korábban letöltötte.

A következő cikkekben konkrét image-eket mutatok be, ami alapján további kérdéseidre is választ kaphatsz. Kérlek, jelezd, ha bármilyen észrevételed, kívánságod van és igyekszem a folytatást annak fényében alakítani, ahogy ezzel a cikkel is történt.