Mi a különbség a Microservice és a Konténerek között?
A konténerek és a microservice-ek lehetővé teszik a fejlesztők számára, hogy gyorsan és egyszerűen építsenek robusztus, könnyen skálázható alkalmazásokat.
Habár a “konténer” és a “microservice” nem ugyanazt jelenti, mégis gyakran egy mondatban emlegetjük őket.
A különbség
A microservice egy szoftverarchitektúra dizájn, ahol az alkalmazás több különálló független egységre van bontva, ezáltal könnyebben skálázható, tesztelhető illetve karbantartható.
A konténer egy szoftverkörnyezet ahol alkalmazásunk minden függőségével együtt futtatható, a host rendszer környezetétől függetlenül.
Adott a kérdés, hol futtassuk microservice alapú alkalmazásunkat? Erre a kérdésre nyújt gyors és egyszerű megoldást a konténerizáció és a konténerorkesztrációs rendszerek (Kubernetes).
Ki lesz a Nagy-Konténerháború győztese?
Jelen pillanatban az alkalmazások túlnyomó többsége Docker konténerekben fut. Azonban a Kubernetes számára nem fontos,hogy milyen konténerben futtatjuk alkalmazásunk, mindaddig amíg az támogatja a CRI-t (Container Runtime Interface). Felmerül bennünk a kérdés hogy mi is a CRI?
A Container Runtime Interface a Kubernetes 1.5-ös verziójával lett bevezetve. Az 1.5-ös verzió előtt a kubelet és a konténer runtime meglehetősen egybefonódott. Ez meglehetősen sok fejlesztési erőforrást vett igénybe, ahogy új konténer alternatívák jelentek meg. A CRI bevezetésével a Kubernetes fejlesztői egy jól definiált standardizált interface-t hoztak létre, hogy ezen keresztül a kubelet kommunikálhasson a különböző konténer technológiákkal.
Mint említettük a legtöbb alkalmazás Docker konténerben futva működik a Kubernetes alatt. A Docker azonban közvetlenül nem használja a CRI-t. A Docker az évek során a monolitikus felépítésből fokozatosan microservice architektúrára váltott, így bizonyos funkcionalitások saját projectekbe költöztek mint például a containerd, ami a high-level image-ek kezelésért felelős, vagy például a runc, ami a low-level konténer runtime-ért felel. Manapság amikor Dockert használunk tulajdonképpen egy stack-et használunk ahol a docker daemon intéz hívásokat a containerd felé ami kommunikál a runc-vel. A Docker a másik irányba, a Kubernetes felé a dockershim-en keresztül kommunikál.
A dockershim azonban mindig is csak egy átmeneti megoldásként volt létrehozva ezért a Kubernetes 1.20-as frisstésében a dockershim támogatása megszűnik. Nem kell azonban aggódnunk mivel számos alternatív konténer technológia jött létre az évek során ami kompatibilis a Kubernetes-el.
Containerd
Amint az előző részben említettük a containerd egy high-level önálló konténer runtime. Képes továbbá image-ek kezelésére (push/pull) valamint képes irányítani a futó konténerek élettartamát a runc-vel együttműködve. A containerd-t használhatjuk a ctr-rel, ami egy CLI eszköz. A Kubernetes alatt pedig helyettesíthetünk egy Docker alapú megoldást egy cri-containerd megoldással. Továbbá a containerd OCI kompatibilis mind image, mind runtime szempontból (ugyancsak a runc-vel együttműködve).
Nabla
A Nabla egy IBM kutatási projektként jött létre. Ugyan a Nabla runtime-ja OCI kompatibilis, azonban mivel a Nabla többek között Unikernel-t is használ a konténerizáció kivitelezéséhez, ezért a Nabla image maga már nem OCI kompatibilis.
Kata
A Kata egy OpenStack kezdeményezés. Akárcsak a Nabla, a Kata is saját OCI kompatibilis runtime-mal rendelkezik, ez a kata-runtime. A különbség, hogy a runc-vel ellentétben a kata-runtime képes OCI kompatibilis image-eket (így nem kell hozzányúlnunk a már meglévő Dockerfile-jainkhoz) futtatni. A Kata mindezek mellett CNI kompatibilis is.
Konklúzió
Ahogy láthatjuk, számos konténer alternatíva létezik a Docker mellett, sőt igazából a Docker is egy stack különböző eszközökkel felvértezve. Fontos megemlíteni, hogy mindegyik konténer alternatíva rendelkezik előnyökkel és hátrányokkal, így a felhasználó kiválaszthatja a saját stack-je számára legmegfelelőbb megoldást. A verseny erős de már látszik – mint ahogy a Kubernetesnél is – melyik megoldás mögé fognak beállni a nagyok és fogja tovább vinni a konténer legacy-t.
Ez a weboldal sütiket használ az Ön élményének javítása érdekében. Feltételezzük, hogy ez Önt nem zavarja, de ha szeretné, lemondhat róla. Cookie beállításokELFOGAD
Adatvédelmi és sütikre vonatkozó szabályzat
Adatvédelmi áttekintés
Ez a weboldal cookie-kat használ, hogy javítsa a felhasználói élményt, miközben a weboldalon navigál. Ezek közül a sütik közül a szükségesnek minősített sütiket tárolja az Ön böngészője, mivel ezek elengedhetetlenek a weboldal alapvető funkcióinak működéséhez. Emellett harmadik féltől származó sütiket is használunk, amelyek segítenek elemezni és megérteni, hogyan használja ezt a weboldalt. Ezeket a cookie-kat csak az Ön hozzájárulásával tároljuk az Ön böngészőjében. Önnek lehetősége van arra is, hogy lemondjon ezekről a cookie-król. De néhány ilyen cookie lemondása hatással lehet a böngészési élményére.
A szükséges sütik elengedhetetlenek a weboldal megfelelő működéséhez. Ebbe a kategóriába csak olyan sütik tartoznak, amelyek biztosítják a weboldal alapvető funkcióit és biztonsági tulajdonságait. Ezek a sütik nem tárolnak személyes adatokat.
Nem szükséges sütiknek nevezzük azokat a sütiket, amelyek nem feltétlenül szükségesek a weboldal működéséhez, és amelyeket kifejezetten a felhasználók személyes adatainak gyűjtésére használnak elemzések, hirdetések és egyéb beágyazott tartalmak segítségével. Ezen sütik weboldalon történő futtatása előtt kötelező a felhasználó beleegyezését beszerezni.
