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.
Docker
A Dockeren kívül semmire nincs szükség ahhoz, hogy egy egyszerűbb alkalmazást elindíts, vagy akár egy sajátot elkészíts és becsomagolj. A világ egyik legegyszerűbb dolga kiadni a parancsot, ami letölt egy image-et és elindít belőle egy konténert. Az is gyerekjáték, ha a saját fájljaidat szeretnéd megosztani a konténerrel. Például azért, mert a weboldalad forráskódja vagy akár már egy lefordított Java alkalmazás számára indítottad a konténert. Ennél azért sok esetben sokkal többről van szó. Többről, mert általában nem egy konténerről szól a történet, hanem egyszerre több konténerből áll egy alkalmazás. Ezt nevezzük "Stack"-nek.
A Stack-en belül viszont szükség lehet a konténerek között kapcsolatot létesíteni. Ezek egymástól való függést jelentenek és a stack élete során az indítástól a leállításig gondoskodni kell a saját hálózatról, közös tárterületről és ezek megszüntetéséről is. Mindezt úgy, hogy közben a különböző stack-ek egymást ne zavarják, de ha szükséges, azok között is lehessenek nyitott kapcsolatok.
Előfordulhat, hogy egy konténerből több példányt is szeretnél elindítani, hogy azok között megoszthasd a terhelést vagy a terhelés növekedésétől függően újabb "dolgozókat" állíthass munkába.
Mindezt megoldani külön segédprogramok nélkül, például bash szkriptekkel vagy saját, direkt erre a célra írt szoftverrel nem egyszerű és felesleges is, hiszen vannak már rá megoldások. Azokra persze nem mindig van szükség, tehát a Dockert önmagában is érdemes ismerni.
Nem egy darab futtatható programként kell elképzelni. Valójában több részből áll. Egy szerveroldali démonból azon a gépen, amelyiken a konténerek és minden más lesz, egy REST API-ból, amin keresztül tetszőleges programnyelven utasítani lehet a démont és egy alapértelmezett, parancssori kliensből. Vagyis az, hogy egy gépen a docker parancssori klienssel kiadsz egy utasítást, nem jelenti azt, hogy azon a gépen kell is lennie démonnak. Hogy melyik gépen levő démonnal kommunikáljon a kliens, az beállítható. Valójában, amikor Windows 10-ben Linux konténereket indítasz, akkor is egy virtuális géppel fog beszélgetni a kliens.
A fentiekkel fontos tisztában lenni, mert ez azt jelenti, hogy a gazda rendszer fájlrendszerét nem éred el egy az egyben és a hálózati interfészek is különbözni fognak. Az elérhető memória is attól függ, hogy mennyit kapott a virtuális gép. Tehát bizonyos esetekben az, hogy elrejti előled a tényt, mi szerint nem is natívan, a gazdán fut a Docker, előnyből hátránnyá válhat.
Docker Compose
Az előző pontban írt függőségi problémákra és bizonyos feladatok automatizálására megoldást ad a Docker Compose. Egy YAML fájlban minden felsorolható, amit a szolgáltatásokról és kapcsolatukról tudni kell. Jól látod, szolgáltatásokról beszélek, nem csak konténerekről. Nem ritka ugyanis, hogy egy alkalmazásból több példányt is elindítunk egyszerre akár különböző szervereken, amik között megoszlik a terhelés. Ilyenkor nem közvetlenül a konténer felé tereljük a kéréseket, hanem előbb egy úgynevezett "load balancer" szolgáltatás kapja meg, ami aztán továbbítja azokat valamilyen algoritmus szerint az alkalmazás példányai, tehát a konténerek felé. Ráadásul a Docker Compose még ezt is megoldja. Az azonos hálózatban levő, azonos szolgáltatásnévvel ellátott konténereket egy szolgáltatásnak veszi. Emiatt pedig oda kell figyelni, mert van az a helyzet, amikor a különböző projekteket, vagy legalábbis egyes szolgáltatásait azonos hálózatba kell tenni, hogy lássák egymást. Ha ráadásul a szolgáltatásoknak azonos nevük van, akkor a terhelés különböző projektek között is megoszlik, ami viszont nem cél.
Bár a Docker Compose-ról nem igazán több gépes klasztereknél beszélünk, a kérések számától függően egy gépnél is lehet értelme a példányszámok növelésének. Nem beszélve arról, hogy több példány esetén azok együttműködéséről is gondoskodni kell, függetlenül attól, hogy fizikailag hány gépre vannak elosztva. Gondolj csak PHP munkamenetekre. Így tehát fejlesztésnél is hasznos a lehetőség, de szem előtt kell tartani, hogy míg egy gép esetén, főleg egyetlen felhasználóval egy megosztott, helyi mappa is megteszi, klaszternél már nem ennyire egyszerű a dolog, tehát eleve komolyabb megoldásokon kell gondolkodni.
A Docker Compose egy olyan eszköz, amit mindenképpen tudok javasolni fejlesztéshez. Egyszerűen telepíthető, könnyen tanulható és könnyen használható.
Docker Swarm
A Docker Swarm ma már a Docker része. Ennek segítségével, ha aktiváltad a "Swarm módot", klaszterben indíthatsz szolgáltatásokat, vagyis akár több gépen elosztva indulhatnak a konténerek. Hogy melyik konténer melyik szerveren indul, azt a Swarm eldönti, bár befolyásolható szabályok megadásával.
A másik előny, hogy elfogad Docker Compose konfigurációs fájlt is, bár egy kicsit eltérő paraméterezéssel, ami annak is köszönhető, hogy más beállításoknak van értelme klaszterben, mint anélkül.
Van még egy érdekes jellemzője a Swarm-nak. Amikor a Docker Compose hozza létre a stack hálózatát, az IP cím minden esetben kileshető a konténer adataiból az "inspect" utasítással. A Docker Swarm esetén viszont többféle hálózat is képbe kerül és bizonyos körülményektől függően vagy egyik vagy másik hálózatán kapott IP címe látható a konténer IP címeként. Ezekről a körülményekről majd a hálózatok leírásánál írok bővebben. Ez azért érdekes, mert lehetnek olyan segédprogramok, amik a konténer IP címének lekérdezésére támaszkodnak. Amihez viszont az eddigi tapasztalataim szerint 17.09-es verziónál nem biztos, hogy mindig elég a "docker container inspect" utasítás.
Nem kell mindenképpen több gép a Docker Swarm teszteléséhez. Ráadásul mellette "hagyományos" módon is indulhatnak konténerek, Swarm mód nélkül, így érdemes lehet ezzel is ismerkedni, ha az alapok már mennek.
Kubernetes
A Kubernetes sem új fiú. Valójában már a Swarm népszerűsödése előtt jelen volt, és hasonló célt szolgál. Az őse a Borg volt, mint a Google saját fejlesztése. Ismerős lehet a kifejezés a Star Trek rajongóknak a Voyager sorozatból, ahol a Borg egy félelmetes ellenség volt, ahonnan "Hetes"-t sikerült megszöktetni. A Kubernetes kezdeti kódneve pedig "Seven" volt, vagyis "Hetes".
Mikor a Swarm bekerült a Docker Engine-be és így egyszerűbbé vált a használata, nagyon felkapták. Konferencián is elhangzott, hogy már nincs is szükség semmi másra a Docker-en kívül. A dolgok persze nem ilyen egyszerűen működnek. A törekvés nyilvánvalóan az volt, hogy feleslegessé tegye a Kubernetest és társait, de a jelek szerint nem sikerült. Annyira, hogy a Docker fejlesztői bejelentették, hogy támogatni fogják a Kubernetest is a Swarm mellett. Bár számomra még nem világos, hogy ez pontosan hogyan fog működni a gyakorlatban, de fejlesztésnél egyelőre ez nem is olyan fontos.
A Kubernetes előnye, hogy nem csak a Dockerrel működik, bár alapértelmezetten Docker konténerekkel dolgozik. Megadható viszont, hogy Rocket konténerekkel működjön. A Docker és a Rocket tehát különböző lehetőség konténerek indítására. A Swarm a Docker konténerek klaszterben indítását és menedzselését teszi lehetővé, a Kubernetes viszont nem csak a Docker konténerekre specializálódik.
Hogy mi a tanulság? Éles környezetben a Kubernetesre láthatóan igény van, így ha komolyan foglalkozol majd a témával, ezt sem hagyhatod ki. Ráadásul nagyon könnyen kipróbálhatod a Minikube segítségével egy egygépes klasztert (tudom, furcsán hangzik) létrehozva. Képes közvetlenül a linux gazdán is elindítani a Kubernetes működéséhez szükséges konténereket, de a "--vm-driver" opciót megadva akár VirtualBox vagy más virtualizáció is választható. Ekkor viszont kicsit másképp lehet böngészőből elérni a konténereket. Persze, erre is ad megoldást automatikus portátirányítással. Mindez megtalálható a leírásában.
Portainer
A Portainer egy egyszerű webes adminisztrációs felület a Docker konténerek kezelésére akár Swarm klaszterben. Természetesen konténerben indítható és igen egyszerűen konfigurálható. Első indításkor egy admin felhasználót kell létrehozni, de további felhasználók is megadhatók. Akár LDAP autentikációra is van lehetőség. Mivel pofon egyszerű feldobni fejlesztői gépre is, ha még nem próbálkoztál webes admin felületekkel, nyugodtan kezdheted ezzel. Távoli gépet is tud akár kezelni.
Portus
Előbb utóbb készítened kell saját Docker image-eket, amiket nem akarsz a nyilvánosság elé kitenni, de nem is csak a laptopodon volna rá szükség. Ilyenkor jól jön egy saját Docker Registry. Ebben segít a Portus. Bár a beállítása elsőre küzdelmes lehet, nem csak webes admin felületet ad a Registry kezelésére, hanem az autentikációt is lehetővé teszi a konténerek le és feltöltéséhez. Ezt már csak akkor javaslom próbálgatni, ha már tisztában vagy az alapokkal és továbblépnél egy szintet.
További szoftverek
Rancher és az OpenShift tanulmányozását is. Eközben rengeteg további fogalom fog szembe jönni.
Források
- Docker vs. Kubernetes vs. Apache Mesos: Why What You Think You Know is Probably Wrong
- https://kubernetes.io/
- Kubernetes vs Docker Swarm
- Borg: The Predecessor to Kubernetes
- Moby and Kubernetes
- Introducing Container Runtime Interface (CRI) in Kubernetes
- Minikube
- Using rkt with Kubernetes (aka "rktnetes")
- Kubernetes has won. Docker Enterprise Edition will support rival container-wrangling tech
