A "felhőorientált" (cloud native) vagy egyszerűen "felhős" alkalmazásokat kifejezetten felhőinfrastruktúrákon való működéshez alakítják ki. Általában ezeket gyengén összekapcsolt mikroszolgáltatások halmazaként építik fel, amelyeket konténerekbe csomagolnak, és amelyek irányítását a felhőplatform végzi. Az ilyen alkalmazások alapértelmezés szerint készen állnak a hibákra, tehát megbízhatóan működnek és skálázhatók még komoly infrastruktúra szintű meghibásodások esetén. A másik oldalon vannak a felhőplatform által a konténeres alkalmazásokra kivetett korlátozások (szerződések), amelyek lehetővé teszik számukra az automatikus kezelését.
Tisztában lévén a felhőalapú alkalmazásokra való áttérés szükségességével és fontosságával, sok szervezet még mindig nem tudja, hol kezdje. Ebben a bejegyzésben egy sor elvet fogunk áttekinteni, amelyek betartása a konténeres alkalmazások fejlesztése során lehetővé teszi a felhőplatformok potenciáljának kihasználását, és biztosítja az alkalmazások megbízható működését és skálázását még súlyos IT-infrastruktúra szintű meghibásodások esetén. Az itt bemutatott elvek végső célja, hogy megtanuljuk olyan alkalmazások készítését, amelyeket automatikusan kezelhetnek olyan felhőplatformok, mint a Kubernetes.
Szoftvertervezési elvek
A programozás világában az elvek általában meglehetősen általános szabályokat jelentenek, amelyeket a szoftver fejlesztése során be kell tartani. Ezek bármely programozási nyelv esetében alkalmazhatók. Minden elvnek megvannak a maga céljai, amelyeket általában minták és gyakorlatok eszközként használnak a megvalósítása. Ezenkívül számos alapelv létezik a minőségi szoftver fejlesztéséhez, amelyekből minden más elv származik. Íme néhány alapelv példája:
- (Keep it simple, stupid) – ne bonyolítsuk túl;
- (Don’t repeat yourself) – ne ismételjük meg magunkat;
- (You aren’t gonna need it) – ne hozzunk létre olyat, amire nincs közvetlen szükség;
- (Separation of concerns) – a felelősségek szétválasztása.
Kétségtelen, hogy ezek az elvek nem határoznak meg konkrét szabályokat, hanem a józan ész alapján hozott, gyakorlati tapasztalatokra alapozott megfontolások, amelyeket számos fejlesztő oszt meg és hivatkozik rájuk rendszeresen.
Ezen kívül létezik – az objektum-orientált programozás és tervezés első öt alapelvének összessége, amelyet Robert Martin fogalmazott meg. A SOLID általános és szabadon értelmezhető, kiegészítő elveket tartalmaz, amelyek – ha együttesen alkalmazzuk őket – segítenek magasabb minőségű szoftverrendszerek létrehozásában és azok hosszú távú támogatásában.
A SOLID elvek az OOP területéhez tartoznak, és olyan fogalmak és koncepciók nyelvén fogalmazódnak meg, mint a osztályok, interfészek és öröklés. Analóg módon felhőalapú alkalmazásokhoz is megfogalmazhatók fejlesztési elvek, csak itt az alapvető elem nem osztály, hanem konténer. Ezeknek az elveknek a követésével konténer alapú alkalmazásokat lehet létrehozni, amelyek jobban illeszkednek a Kubernetes-szerű felhőplatformok céljaihoz és feladataihoz.
Felhőorientált konténerek: Red Hat megközelítése
Ma a konténerekbe viszonylag könnyen becsomagolható szinte bármilyen alkalmazás. De ahhoz, hogy az alkalmazásokat hatékonyan automatizálják és orkestrálják egy Kubernetes típusú felhőplatform keretein belül, további erőfeszítéseket kell tenni.
Az alábbi ötletek alapját a következő metodológia képezi és számos egyéb munka, amelyek a webalkalmazások létrehozásának különböző aspektusairól szólnak, a forráskód kezelésétől a skálázási modellekig. A leírt elvek kizárólag konténer alapú alkalmazásokra vonatkoznak, amelyek mikroservizek alapján készültek és felhőplatformokhoz, például Kuberneteshez készültek. Gondolataink alapvető eleme a konténer kép, és a célkörnyezet, amelyben a konténerek futnak, a konténerek orkestrálásának platformját jelenti. A felvetett elvek célja, hogy olyan konténerek létrehozása, amelyek esetében a legtöbb orkestráló platformon automatizálható a feladatok ütemezése (scheduling – A gazdagép kiválasztása a konténer példányának futtatására), skálázás és monitorozás. Az elvek tetszőleges sorrendben kerülnek előadásra.
A ruházott feladat elve (Single Concern Principle, SCP)
Ez az elv nagymértékben hasonlít az egyetlen felelősség elvéhez (Single Responsibility Principle, ), amely a SOLID elveinek része, és azt mondja, hogy minden objektumnak egyetlen felelősséggel kell rendelkeznie, és ezt a felelősséget teljes mértékben egy osztályba kell encapzulálni. Az SRP lényege, hogy minden felelősség egy ok a változtatásokra, és az osztálynak egyetlen egyetlen okból kell változni.
Az SCP esetében a 'felelősség' (responsibility) helyett a 'feladat' (concern) szót használjuk, hogy egy magasabb absztrakciós szintet és egy tágabb értelemben vett szerepet jelöljünk, mint az OOP osztály. És ha az SRP célja, hogy csak egy okot legyen a változásra, akkor az SCP mögött az a szándék áll, hogy növelje a konténerek újrahasználhatóságát és cserélhetőségét. Az SRP-t követve és olyan konténert létrehozva, amely csak egyetlen feladatot old meg, funkcionálisan befejezett módon, növeled annak esélyét, hogy a konténer képét különböző alkalmazási kontextusokban újrahasználod.
Az SCP elve azt mondja, hogy minden konténernek egyetlen feladatot kell megoldania, és ezt jól kell tennie. Ezenkívül az SCP az konténerek világában könnyebben elérhető, mint az SRP az OOP világában, mivel a konténerek általában egyetlen folyamatot hajtanak végre, és a legtöbb időt az a folyamat egyetlen feladat megoldására fordítja.
Ha egy konténer mikroszolgáltatásnak több feladatot kellene megoldania, akkor azt egyfeladatos konténerekre lehet bontani, és egy pod-ba (a konténerplatform telepítési egysége) összegyűjteni oldalkonfigurációs és init-konténerekkel. Ezenkívül az SCP megkönnyíti egy régi konténer (például egy webszerver vagy egy üzenet közvetítő) cseréjét egy újra, ami ugyanezt a feladatot oldja meg, de bővített funkcionalitással vagy jobb skálázhatósággal rendelkezik.
A magas megfigyelhetőség elve (High Observability Principle, HOP)
Kontejnerként történő alkalmazáscsomagolás és futtatás esetén az alkalmazások maguk is "fekete dobozként" működnek. Azonban, ha felhőalapú konténerekről van szó, akkor speciális API interfészeket kell biztosítaniuk a futtatási környezet számára, hogy szabályozni tudják a konténerek épségét, és szükség esetén megfelelő intézkedéseket tudjanak tenni. Enélkül nem lehetséges a konténerek frissítéseinek automatizálásának egységesítése és életciklusuk kezelésének, ami viszont rontja a szoftveres rendszer megbízhatóságát és használhatóságát.
A gyakorlatban a konténeres alkalmazásnak legalább API-val kell rendelkeznie a különböző típusú épségvizsgálatokhoz: életerő-teszt (liveness) és készenléti teszt (readiness) végzésére. Ha az alkalmazás többre hivatott, más állapotellenőrzési eszközöket is kell biztosítania. Például fontos események naplózását STDERR és STDOUT segítségével a naplók aggregálásához Fluentd, Logstash és hasonló eszközök használatával. Továbbá integrálódnia kell nyomkövetési és metrikagyűjtő könyvtárakkal, mint például OpenTracing, Prometheus stb.
Általánosságban véve az alkalmazás továbbra is "fekete dobozként" szemlélhető, de minden szükséges API-t fel kell szerelni, amely lehetővé teszi a platform számára, hogy a lehető legjobban figyelemmel kísérje és kezelje azt.
Életciklus Konformitási Elv (Life-cycle Conformance Principle, LCP)
Az LCP a HOP ellentéte. Míg a HOP arra utal, hogy a konténernek API-kat kell biztosítania a platform számára az olvasásra, az LCP megköveteli az alkalmazástól, hogy képes legyen fogadni információt a platformról. Ráadásul a konténernek nemcsak eseményeket kell kapnia, hanem reageálnia is kell rájuk. Itt származik a név, amely a platform számára API-kat követel meg az íráshoz.
A platformok különféle eseménytípusokkal rendelkeznek, amelyek segítik a konténer életciklusának kezelését. De annak eldöntése, hogy melyeket fogadja el és hogyan reagáljon, magának az alkalmazásnak kell lennie.
Nyilvánvaló, hogy egyes események fontosabbak, mint mások. Például, ha egy alkalmazás rosszul kezeli a vészhelyzeti leállítást, akkor köteles fogadni a signal: terminate (SIGTERM) üzeneteket, és a lehető leggyorsabban elindítani a leállítási eljárását, hogy még a signal: kill (SIGKILL) érkezése előtt be tudja fejezni a működését, amely a SIGTERM után következik.
Ezenkívül az alkalmazás életciklusához olyan események is fontosak lehetnek, mint a PostStart és a PreStop. Például az alkalmazás elindítása után bizonyos időre szüksége lehet a "bemelegítésre", mielőtt válaszolni tudna a kérésekre. Vagy az alkalmazásnak valamilyen különleges módon kell felszabadítania az erőforrásokat a leállításkor.
A konténerkép változatlanságának elve (Image Immutability Principle, IIP)
Általános szabály, hogy a konténeralkalmazásoknak a létrehozás után változatlannak kell maradniuk, függetlenül attól, hogy különböző környezetekben futnak. Ezért szükséges az adatok tárolásának külső forrásokra való kiszervezése futásidőben (más szóval, külső eszközök használata), valamint a külső, adott futási környezethez igazított konfigurációkra támaszkodni, ahelyett, hogy minden környezethez egyedi konténereket hoznának létre vagy módosítanának. Bármilyen változtatás után az alkalmazás konténerképet újra kell építeni, és az összes használt környezetben telepíteni kell. Érdekesség, hogy az IT-rendszerek kezelésében hasonló elvet alkalmaznak, amelyet a szerverek és az infrastruktúra változatlanságának elve néven ismernek.
Az IIP célja, hogy megakadályozza a külön konténerképek létrehozását különböző futási környezetekhez, és mindenhol ugyanazt a képet használja a megfelelő konfigurációval a konkrét környezethez. Ezen elv követése lehetővé teszi az olyan fontos felhőautomatikai gyakorlatok megvalósítását, mint az alkalmazások visszaállítása (roll-back) és frissítések alkalmazása (roll-forward).
A folyamatok egyszeri használatának elve (Process Disposability Principle, PDP)
A konténer egyik legfontosabb jellemzője az efemeritás: a konténerpéldány könnyen létrehozható és könnyen elpusztítható, így bármikor könnyen kicserélhető egy másik példányra. Ennek a cserének számos oka lehet: a funkcionalitás tesztjeinek meghiúsulása, az alkalmazás skálázása, másik hosztra való áthelyezés, a platform erőforrásainak kimerülése vagy más helyzetek.
Ennek következtében a konténeres alkalmazásoknak valamilyen külső eszköz segítségével kell megőrizniük állapotukat, vagy belső elosztott séma redundanciát kell alkalmazniuk erre. Továbbá, az alkalmazásnak gyorsan kell elindulnia és befejeződnie, valamint fel kell készülnie a hirtelen hardverhiba okozta végzetes leállásra.
Az egyik gyakorlat, amely segít megvalósítani ezt az elvet, hogy kis méretű konténereket hozzunk létre. A felhőalapú környezetek automatikusan kiválasztják a gazdagépet a konténerpéldány futtatásához, így minél kisebb a konténer mérete, annál gyorsabban elindul – egyszerűen gyorsabban másolható a célgazdára a hálózaton.
A függetlenség elve (Self-containment Principle, S-CP)
Ennek az elvnek megfelelően a konténer összes szükséges összetevőjét a gyártás során be kell építeni. A konténert úgy kell felépíteni, hogy a rendszerben csak egy tiszta Linux mag van, ezért minden szükséges könyvtárat a konténerben kell elhelyezni. Itt kell lennie a megfelelő programozási nyelv futtatókörnyezetének, az alkalmazásplatformnak (ha szükséges) és egyéb függőségeknek, amelyekre a konténeres alkalmazás működése során szükség lesz.
Kivételek csak azok számára készülnek, amelyek környezettől függően változnak, és ezeket futás közben kell biztosítani, például a Kubernetes ConfigMap segítségével.
Az alkalmazás több konténerizált összetevőt is tartalmazhat, például egy külön adatbázis-konténert egy konténeralapú webalkalmazás részeként. Az S-CP elv szerint ezeket a konténereket nem szabad egyesíteni, hanem úgy kell kialakítani, hogy az adatbázis-konténer tartalmazza az összes szükséges dolgot az adatbázis működéséhez, míg a webalkalmazás-konténer tartalmazza a webalkalmazás működéséhez szükséges összes dolgot, beleértve a webszervert is. Ennek eredményeként a webalkalmazás konténer futás közben az adatbázis konténerre támaszkodik, és szükség szerint hívja azt.
A futásidejű korlátozás elve (Runtime Confinement Principle, RCP)
Az S-CP elv alapján határozzuk meg, hogy miként kell összegyűjteni a konténert, és mit kell tartalmaznia a bináris képnek. De a konténer nem csupán egy "fekete doboz", amelynek csak egy jellemzője van - a fájl mérete. A futás során a konténer további dimenziókkal bővül: a felhasznált memória mennyisége, a processzoridő és egyéb rendszerszolgáltatások.
Itt hasznos a RCP elv, amely szerint a konténernek decapacitálnia kell a rendszerszolgáltatásokra vonatkozó követelményeit, és át kell adnia azokat a platformnak. A platform optimálisan tudja végezni a konténerek erőforrás-igényprofiljának (mennyi CPU, memória, hálózati és tárolóerőforrásra van szükség) kezelését, automatikus skálázást végezni, irányítja az IT erőforrásokat, és fenntartja a SLA szintjeit a konténerek számára.
A konténer erőforrás-követelményeinek kielégítése mellett az alkalmazásnak is fontos, hogy ne lépje túl az általa meghatározott kereteket. Ellenkező esetben, ha erőforráshiány lép fel, a platform nagyobb valószínűséggel állítja le vagy migrálja az alkalmazást.
A felhőorientáltságról beszélve elsősorban a munkamódszerről van szó.
Előzőleg felvázoltunk néhány általános elvet, amelyek metodológiai alapot képeznek a minőségi konténeres alkalmazások felépítéséhez felhőalapú környezetben.
Fontos megjegyezni, hogy e közös elvek mellett további fejlett módszerekre és technikákra is szükséged lesz a konténerek kezelésében. Ezen kívül van néhány rövid ajánlásunk, amelyek specifikusabb jellegűek, és a helyzettől függően kell alkalmazni (vagy nem alkalmazni) őket:
- Próbálj meg minimalizálni a képek méretét: távolítsd el a ideiglenes fájlokat, és ne telepíts fölösleges csomagokat – minél kisebb a konténer mérete, annál gyorsabb a létrehozása és átkonfigurálása a célhostra a hálózaton.
- Kezelj véletlenszerű User-ID-kat: ne használd a sudo parancsot vagy különleges userid-t a konténereid futtatásához.
- Jelöld meg a fontos portokat: a portszámokat futás közben is meg lehet határozni, de a legjobb, ha az EXPOSE parancs segítségével adod meg őket – másoknak és programoknak könnyebb lesz használni a képeidet.
- Tartsa meg az állandó adatokat köteteken: azokat az adatokat, amelyeknek a konténer megsemmisítése után is meg kell maradniuk, kötetekre kell menteni.
- Adja meg a képek metadatáját: a címkék, megjegyzések és annotációk megkönnyítik a képek használatát – a többi fejlesztő hálás lesz érte.
- Szinkronizálja a hostot és a képeket: egyes konténeralkalmazásokhoz szükség van a konténer szinkronizálására a hosttal bizonyos attribútumok, például az idő vagy a gépid száma szerint.
- Összegzésként megosztjuk a sablonokat és a legjobb gyakorlatokat, amelyek segítenek a fent említett elvek hatékonyabb megvalósításában:
Június 11-én 11:00-kor
Mit fog tanulni:
- Immutable Red Hat Enterprise Linux CoreOS
- OpenShift service mesh
- Operator framework
- Knative framework
Forrás: habr.com
