EDU::GAMF::Felhőalapú-szolgáltatások::Docker

Mi az a Docker?

A Docker a konténer technológiák egyike. A konténerek és a virtuális gépek rokonságban állnak egymással, de mégis nagy különbség van közöttük: a konténerek pehelykönnyűek.

De hogyan válik egy virtuális gép pehelykönnyűvé? A válasz az, hogy Docker esetében nincs hardvervirtualizáció, így kisebb az erőforrásigénye - nem kell az eszközökre "memory map"-ot létrehozni a felmerülő biztonsági problémák kezelésére és nem kell minden hozzáférésnél azokat forwardolni - és a benne futó operációs rendszerek is a lehető legminimálisabb konfigurációval rendelkeznek.

Tekintsük meg egy virtuális gép szintjeit (lásd: VM szintek):

1. A fizikai vas szintje fölé telepítünk valamilyen hypervisort, azaz virtualizációs környezetet
   • itt jön létre az említett "memory map"
   • a virtuális gépek az itt beállított hardverkörnyezetet fogják látni, ami akár fals információ is lehet, eltérhet a valóságtól (kompatibilitások miatt szokás átverni a felsőbb szinteket)
2. A Virtualizált OS szintje, saját kernellel és driverekkel
3. A virtuális gépben telepített alkalmazások szintje

Ezzel szemben tekintsük meg a Docker szintjeit (lásd: Docker szintek vagy VM vs Docker

1. A fizikai vas szintje fölé telepítjük a HOST operációs rendszert, ami többnyire valamilyen linux alapú operációs rendszer
2. Az operációs rendszeren telepítünk egy konténerizációs alkalmazást (esetünkben docker daemon-t)
3. Az elindított konténerek a telepített konténerizációs alkalmazással kommunikálnak számukra ez az API a HOST operációs rendszere felé.

Végső soron a nagy különbséget az jelenti, hogy a konténerek esetén a kernelt nem virtualizáljuk, hanem felhasználjuk a HOST operációs rendszerét, így mindent, ami az alatti szinten található ki vehetjük a virtuális környezet menedzseléséből.

Egyéb konténer technológiák

Szerencsés megjegyezni, hogy bár a piac nagy részét jelenleg a Docker birtokolja a konténerek világában, azért nem nevezhetjük egyeduralkodónak. Vannak egyéb fejlesztések is, amelyek bizonyos esetekben célravezetőbbek lehetnek, bár ezek felhasználási területei jóval szegényesebbek.

A teljesség igénye nélkül egy pár nevesebb (a többit lásd: Docker alternatívák 2022-ben):

• LXC / LXD, azaz Linux Container, amelyet többet között a Proxmox is támogat (a proxmox egy ESXi-hez hasonló virtuális gép vezérlő operációs rendszer, amelyet a VPS szolgáltatók (is) használnak).
• Podman
• RunC
• Containerd

Érdemes tájékozódni, mielőtt egy technológiát ténylegesen ajánlatba adunk, gyorsan fejlődik az iparág, így könnyedén jelenhetnek meg újabb szereplők is, akik lesöprik a megszokott dolgokat!

Docker előfordulásai

A docker mára annyira kinőtte magát, hogy a legtöbb cég az alkalmazásait ilyen környezetben telepíti, ezzel ténylegesen időt spórolva magának.

Hogyan spórolhat időt egy olyan technológia, ami újabb üzemeltetési kérdéseket vet fel?
Képzeljünk el egy olyan szervert, amely 5db weboldalt futtat, azaz 5 különböző virtual host létezik rajta. Az egyik nginx alatt fut, a másik nodejs, a harmadik php7-es verzióval, a negyedik php8-as verzióval fut és még nem is említettük, hogy adatokat is szeretnénk tárolni mssql, mysql, postgresql esetleg sqlite adatbázisokban, akármilyen kombinációban. Érezzük, hogy ennek a szervernek az üzemeltetése nem kis feladat, de ha csak a különböző verziót igénylő PHP-s weboldalakat szeretnénk egy szerveren elhelyezni, azzal is rendkívül érdekes feladatokba ütközhetünk (természetesen lehetséges és meg van rá a bejáratott módszer, hiszen ez a docker előtt is probléma volt).
Ha ezt tekintjük és ezzel állítjuk szembe azt a többlet feladatot, hogy a docker daemon-t is üzemeltetni, frissíteni kell, akkor már nem is tűnik rossz ötletnek: ha egy-egy alkalmazás külön-külön konténerekbe kerülne, akkor nem kellene sem az egy szerveren futtatott többféle verzió problémájával, sem a különböző adatbázis szükségletekkel, sem a különböző webszerver szükségletekkel foglalkoznunk, gyakorlatilag mindenki olyan technológiát használ, amilyet szeretne és úgy frissíti a konténeren belül azokat, amilyen ütemben szeretné, a többire nem lesz hatással.

Mi a helyzet a konténerek okozta többlet teljesítmény szükséglettel?
A korábbi fejezetben tárgyaltak alapján a konténer nem fogyaszt sokat, így az overhead rendkívül kicsi. Természetesen van némi többlet CPU idő, memória és tárhely felhasználás - ha csak azt vesszük, hogy egyetlen SQL szerver helyett minden konténerbe külön fel lesz telepítve, így töbszörösen tároljuk a szerver konfigurációs állományait stb.), de mindez manapság bőven ellensúlyozható viszonylag alacsony költségen: nem okoz akkora költség többletet, mint amekkora veszteséget okozna egy frissítést követően összeomlott vegyes rendszer, tehát mondhatjuk, hogy bár teljesítmény vesztés jelentkezik, azt mégis megéri bevállalni az előnyei miatt (a virtuális gépet ugyanerre a célra például nem érte meg bevetni).

Az üzemeltetés gyorsításán túl használják felhő kialakítására is, hiszen a daemon-ba épített swarm-nak köszönhetően automatikusan skálázhatunk dockereket akár több szerveren is, amik ráadásul pár másodperc alatt elérhetővé válnak, így a bootolási időt is megspóroljuk. Hozzá kell tenni, hogy a swarm-nál manapság létezik jobb és barátságosabb orchestrator is, pl.: Kubernetes.

Nem csak az üzemeltetést könnyíti meg vagy javítja a rendelkezésreállást, hanem a fejlesztési időn is javít.
Természetesen ne gondoljunk olyanokra, hogy a programot helyettünk lefejleszti egy konténer, de azzal nagyon sokat nyerünk, hogy ha egy konténerben lefejlesztünk valamit és működik, akkor a konténert egy másik gépre másolva is működni fog, függetlenül attól, hogy esetleg platformot váltottunk (windwos->linux vagy fordítva), hogy verziót váltottunk vagy hogy milyen csomagok érhetők el a cél szerveren. Ezek a kérdések sok esetben plusz fejlesztési időt jelentenek, hogy valamelyest dinamikus legyen.

Docker registry

Ez a szolgáltatás tárolja az elérhető képfájlokat. A docker egyéb információ hiányában a docker.com webhelyre feltöltött fájlok között keres és innen tölti le a találatokat, de telepíthetünk sajátot is (erről később lesz szó).

A docker.com-ra a regisztráció ingyenes, egy privát projektet hozhatunk létre és bármennyit publikusan. Ez magában foglalja a veszélyt is: bárki feltölthet például egy webszervert, amelyben kiskapuk vannak stb.
Minidg ügyeljünk rá, hogy megbízható helyről származzon, amit letöltünk!