A „felhőben natív” vagy egyszerűen „felhő” alkalmazások kifejezetten felhőalapú infrastruktúrákban való használatra készültek. Jellemzően konténerekbe csomagolt, lazán összekapcsolt mikroszolgáltatások halmazaként épülnek fel, amelyeket viszont egy felhőplatform kezel. Az ilyen alkalmazások alapból fel vannak készülve a hibákra, ami azt jelenti, hogy megbízhatóan működnek és skálázhatóak még súlyos infrastruktúra-szintű hibák esetén is. Az érem másik oldala a korlátozások (szerződések) halmazai, amelyeket a felhőplatform a konténeres alkalmazásokra támaszt annak érdekében, hogy ezeket automatikusan kezelni tudja.
Bár teljes mértékben tudatában van a felhőalapú alkalmazásokra való átállás szükségességének és fontosságának, sok szervezet még mindig nem tudja, hol kezdje. Ebben a bejegyzésben számos olyan alapelvet fogunk megvizsgálni, amelyek betartása a konténeres alkalmazások fejlesztése során lehetővé teszi a felhőplatformokban rejlő lehetőségek kiaknázását és az alkalmazások megbízható működését és skálázását az IT infrastruktúra súlyos meghibásodása esetén is. szint. Az itt felvázolt alapelvek végső célja, hogy megtanulják, hogyan készítsenek olyan alkalmazásokat, amelyeket automatikusan felügyelhetnek a felhőplatformok, például a Kubernetes.
Szoftvertervezési alapelvek
A programozási világban az elvek meglehetősen általános szabályokra vonatkoznak, amelyeket a szoftverfejlesztés során be kell tartani. Bármilyen programozási nyelven használhatók. Minden alapelvnek megvannak a maga céljai, amelyek elérésének eszközei általában sablonok és gyakorlatok. A jó minőségű szoftverek létrehozásának számos alapelve is létezik, amelyekből az összes többi kiindul. Íme néhány példa az alapvető elvekre:
- (Keep it simple, stupid) – ne bonyolítsd;
- (Ne ismételd magad) - ne ismételd magad;
- (Nem lesz rá szükséged) - ne hozz létre olyat, amire nincs azonnal szükség;
- A gondok szétválasztása – a felelősség megosztása.
Mint látható, ezek az alapelvek nem határoznak meg konkrét szabályokat, hanem a gyakorlati tapasztalatokon alapuló, úgynevezett józan ész megfontolások kategóriájába tartoznak, amelyeket sok fejlesztő osztozik, és amelyre rendszeresen hivatkoznak.
Ezen kívül van – Az objektum-orientált programozás és tervezés első öt alapelvének készlete, amelyet Robert Martin fogalmazott meg. A SOLID tág, nyílt végű, egymást kiegészítő alapelveket tartalmaz, amelyek együttes alkalmazásuk esetén jobb szoftverrendszereket hozhatnak létre, és hosszú távon jobb karbantarthatók.
A SOLID elvek az OOP területéhez tartoznak, és olyan fogalmak és fogalmak nyelvén fogalmazódnak meg, mint az osztályok, interfészek és öröklődés. Hasonlatosan a felhőalkalmazásokhoz is megfogalmazhatók fejlesztési elvek, csak itt nem egy osztály lesz az alapelem, hanem egy konténer. Ezen elvek követésével olyan konténeres alkalmazásokat hozhat létre, amelyek jobban megfelelnek a felhőplatformok, például a Kubernetes céljainak és célkitűzéseinek.
Felhőben natív konténerek: a Red Hat megközelítés
Ma már szinte minden alkalmazás viszonylag könnyen konténerekbe csomagolható. De ahhoz, hogy az alkalmazások hatékonyan automatizálhatók és hangszerelhetők legyenek egy felhőplatformon, például a Kubernetesen belül, további erőfeszítésekre van szükség.
Az alábbiakban felvázolt elképzelések alapja a módszertan volt és sok más munka a webalkalmazások felépítésének különböző aspektusairól, a forráskód kezelésétől a méretezési modellekig. A leírt alapelvek csak olyan konténeres alkalmazások fejlesztésére vonatkoznak, amelyek mikroszolgáltatásokra épülnek, és felhőplatformokhoz, például a Kuberneteshez készültek. Beszélgetésünk alapeleme a konténerkép, a céltároló futási környezet pedig a konténer-hangszerelési platform. A javasolt elvek célja olyan konténerek létrehozása, amelyeknél az ütemezési, skálázási és figyelési feladatok a legtöbb hangszerelési platformon automatizálhatók. Az alapelvek nincsenek meghatározott sorrendben bemutatva.
Egyablakos ügylet elve (SCP)
Ez az elv sok tekintetben hasonlít az Egységes Felelősség elvéhez. ), amely a SOLID készlet része, és kimondja, hogy minden objektumnak egy felelősséggel kell rendelkeznie, és ezt a felelősséget teljesen egy osztályba kell foglalni. Az SRP lényege, hogy minden felelősség oka a változásnak, és egy osztálynak egy és egyetlen oka kell legyen a változásra.
Az SCP-ben a „felelősség” szó helyett az „aggodalom” szót használjuk, hogy jelezzük a konténer magasabb absztrakciós szintjét és szélesebb célját az OOP osztályhoz képest. És ha az SRP célja, hogy csak egyetlen oka legyen a változtatásnak, akkor az SCP mögött a konténerek újrafelhasználásának és cseréjének lehetőségének bővítése áll. Ha követi az SRP-t, és olyan tárolót hoz létre, amely egyetlen problémát megold, és azt funkcionálisan teljes mértékben végzi el, növeli annak esélyét, hogy a tárolókép különböző alkalmazási környezetekben újra felhasználható legyen.
Az SCP elve kimondja, hogy minden konténernek egyetlen problémát kell megoldania, és azt jól kell csinálnia. Ráadásul az SCP a konténer világban könnyebben elérhető, mint az SRP az OOP világban, mivel a konténerek általában egyetlen folyamatot futtatnak, és ez a folyamat legtöbbször egyetlen feladatot old meg.
Ha egy konténer mikroszolgáltatásnak egyszerre több problémát kell megoldania, akkor egyfeladatos konténerekre osztható, és oldalkocsis és init konténer sablonok segítségével egy podban (a konténerplatform telepítési egységében) kombinálható. Ezenkívül az SCP megkönnyíti egy régi tároló (például webszerver vagy üzenetközvetítő) cseréjét egy újra, amely megoldja ugyanazt a problémát, de bővített funkcionalitással vagy jobban skálázható.
Magas megfigyelhetőségi elv (HOP)
Ha a konténereket az alkalmazások csomagolásának és futtatásának egységes módjaként használják, magukat az alkalmazásokat fekete dobozként kezeli a rendszer. Ha azonban ezek felhőtárolók, akkor speciális API-kat kell biztosítaniuk a futtatókörnyezet számára a tárolók állapotának figyeléséhez, és szükség esetén meg kell tenniük a megfelelő lépéseket. E nélkül nem lehet egységesíteni a konténerek frissítésének és életciklusuk kezelésének automatizálását, ami viszont rontja a szoftverrendszer stabilitását és használhatóságát.
A gyakorlatban egy konténeres alkalmazásnak legalább egy API-val kell rendelkeznie különféle típusú állapotfelmérésekhez: életképességi tesztekhez és készenléti tesztekhez. Ha egy alkalmazás többre kívánkozik, akkor más módot kell biztosítania állapota nyomon követésére. Például fontos események naplózása STDERR-en és STDOUT-on keresztül a naplóösszesítéshez Fluentd, Logstash és más hasonló eszközök segítségével. Valamint integráció nyomkövetési és metrikagyűjtő könyvtárakkal, mint például az OpenTracing, Prometheus stb.
Általánosságban elmondható, hogy az alkalmazás továbbra is fekete dobozként kezelhető, de minden olyan API-val kell rendelkeznie, amelyre a platformnak szüksége van, hogy a lehető legjobban tudja figyelni és kezelni.
Életciklus-megfelelőségi elv (LCP)
Az LCP a HOP ellentéte. Míg a HOP kimondja, hogy a tárolónak olvasási API-kat kell kitennie a platform számára, az LCP megköveteli, hogy az alkalmazás képes legyen információkat fogadni a platformról. Sőt, a konténernek nemcsak fogadnia kell az eseményeket, hanem alkalmazkodnia is kell, vagyis reagálnia kell rájuk. Innen ered az elv neve, amely a platform írási API-kkal való ellátásának követelményének tekinthető.
A platformok különböző típusú eseményekkel segítik a tárolók életciklusának kezelését. De magának az alkalmazásnak kell eldöntenie, hogy melyiket érzékeli és hogyan reagál.
Nyilvánvaló, hogy egyes események fontosabbak, mint mások. Például, ha egy alkalmazás nem tolerálja jól az összeomlásokat, el kell fogadnia a Sign: terminate (SIGTERM) üzeneteket, és a lehető leggyorsabban el kell indítania a lezárási rutint, hogy elkapja a SIGTERM után érkező jelet: kill (SIGKILL).
Ezenkívül az olyan események, mint a PostStart és a PreStop, fontosak lehetnek egy alkalmazás életciklusa szempontjából. Például egy alkalmazás elindítása után némi bemelegedési időre lehet szükség, mielőtt válaszolni tudna a kérésekre. Vagy az alkalmazásnak valamilyen speciális módon erőforrásokat kell felszabadítania leállításkor.
A kép megváltoztathatatlanságának elve (IIP)
Általánosan elfogadott, hogy a konténeres alkalmazásoknak változatlannak kell maradniuk a felépítés után, még akkor is, ha különböző környezetben futnak. Ez szükségessé teszi az adattárolás külsővé tételét futás közben (vagyis külső eszközöket kell használni ehhez), és külső, futásidő-specifikus konfigurációkra kell hagyatkozni, nem pedig egyedi konténereket kell módosítani vagy létrehozni az egyes környezetekhez. Az alkalmazás bármilyen módosítása után a tároló lemezképet újra kell építeni, és minden használt környezetben telepíteni kell. Az informatikai rendszerek kezelésekor egyébként hasonló elvet alkalmaznak, a szerverek és az infrastruktúra megváltoztathatatlanságának elvét.
Az IIP célja, hogy megakadályozza a különböző futási környezetekhez különálló konténerképek létrehozását, és mindenhol ugyanazt a lemezképet használja a megfelelő környezet-specifikus konfigurációval együtt. Ezen elv követése lehetővé teszi a felhőrendszerek automatizálása szempontjából olyan fontos gyakorlatok megvalósítását, mint az alkalmazásfrissítések visszagörgetése és előregörgetése.
Process Disposability Principle (PDP)
A konténerek egyik legfontosabb jellemzője a mulandósága: egy konténer példánya könnyen létrehozható és könnyen megsemmisíthető, így bármikor könnyen lecserélhető egy másik példányra. Az ilyen cserének számos oka lehet: a használhatósági teszt meghiúsulása, az alkalmazás méretezése, egy másik gazdagépre való átvitel, a platform erőforrásainak kimerülése vagy egyéb helyzetek.
Ennek következtében a konténeres alkalmazásoknak valamilyen külső eszközzel kell fenntartaniuk állapotukat, vagy ehhez redundanciával rendelkező belső elosztott sémákat kell használniuk. Ezenkívül az alkalmazásnak gyorsan el kell indulnia és gyorsan le kell állnia, és fel kell készülnie a hirtelen végzetes hardverhibákra.
Az egyik gyakorlat, amely segít ennek az elvnek a megvalósításában, az, hogy a tartályokat kicsiben kell tartani. A felhőkörnyezetek automatikusan kiválaszthatnak egy gazdagépet a tárolópéldány indításához, így minél kisebb a tároló, annál gyorsabban indul – egyszerűen gyorsabban másol a célállomásra a hálózaton keresztül.
Önelzáródási elv (S-CP)
Ennek az elvnek megfelelően az összeszerelési szakaszban minden szükséges alkatrészt tartalmaz a tartály. A tárolót abból a feltételezésből kell megépíteni, hogy a rendszernek csak tiszta Linux kernelle van, tehát az összes szükséges további könyvtárat magába a konténerbe kell helyezni. Tartalmaznia kell olyan dolgokat is, mint a megfelelő programozási nyelv futási ideje, az alkalmazásplatform (ha szükséges), és egyéb függőségek, amelyekre a tárolóalkalmazás futásakor szükség lesz.
Kivételt képeznek az olyan konfigurációk, amelyek környezetenként változnak, és futás közben kell megadni őket, például a Kubernetes ConfigMap segítségével.
Egy alkalmazás több konténeres komponenst tartalmazhat, például egy különálló DBMS-tárolót egy konténeres webalkalmazáson belül. Az S-CP elv szerint ezeket a konténereket nem szabad egybe vonni, hanem úgy kell elkészíteni, hogy a DBMS konténerben minden az adatbázis működéséhez szükséges, a webalkalmazás konténerben pedig minden a web működéséhez szükséges. alkalmazás, ugyanaz a webszerver . Ennek eredményeként a webalkalmazás-tároló futás közben a DBMS-tárolótól függ, és szükség szerint hozzáférhet.
Runtime Confinement Principle (RCP)
Az S-CP elv határozza meg, hogy a konténer hogyan épüljön fel, és mit tartalmazzon a bináris kép. De a konténer nem csak egy „fekete doboz”, amelynek egyetlen jellemzője van - a fájlméret. A végrehajtás során a tároló más dimenziókat vesz fel: a felhasznált memória mennyiségét, a CPU-időt és egyéb rendszererőforrásokat.
És itt jól jön az RCP-elv, amely szerint a konténernek le kell fejelnie a rendszererőforrásokra vonatkozó igényeit, és át kell vinnie a platformra. Az egyes tárolók erőforrásprofiljaival (mekkora CPU-, memória-, hálózati és lemezerőforrásra van szüksége) a platform optimálisan hajthatja végre az ütemezést és az automatikus skálázást, kezelheti az IT-kapacitást, és karbantarthatja a tárolók SLA-szintjét.
Amellett, hogy megfelel a konténer erőforrásigényének, az is fontos, hogy az alkalmazás ne lépje túl a saját határait. Ellenkező esetben, amikor erőforráshiány lép fel, a platform nagyobb valószínűséggel veszi fel a leállítandó vagy áttelepítendő alkalmazások listájára.
Amikor arról beszélünk, hogy az első helyen állunk a felhőben, akkor a munkamódszerről beszélünk.
Fentebb számos általános alapelvet fogalmaztunk meg, amelyek megalapozzák a felhőkörnyezetek számára kiváló minőségű konténeralkalmazások készítésének módszertani alapjait.
Vegye figyelembe, hogy ezeken az általános elveken kívül további fejlett módszerekre és technikákra is szüksége lesz a tárolókkal való munkavégzéshez. Ezen kívül van néhány rövid ajánlásunk, amelyek konkrétabbak, és a helyzettől függően alkalmazni kell (vagy nem kell alkalmazni):
- Próbálja csökkenteni a képek méretét: törölje az ideiglenes fájlokat, és ne telepítse a szükségtelen csomagokat – minél kisebb a tároló mérete, annál gyorsabban kerül összeállításra és a célállomásra másolásra a hálózaton keresztül.
- Összpontosítson a tetszőleges felhasználói azonosítókra: ne használja a sudo parancsot vagy semmilyen speciális felhasználói azonosítót a tárolók elindításához.
- Jelölje meg a fontos portokat: A portszámokat futás közben is beállíthatja, de jobb, ha az EXPOSE paranccsal adja meg őket – így mások és programok is könnyebben használhatják a képeket.
- Állandó adatok tárolása a köteteken: Azokat az adatokat, amelyeknek a tároló megsemmisítése után is meg kell maradniuk, a kötetekbe kell írni.
- Írjon kép metaadatokat: a címkék, címkék és megjegyzések megkönnyítik a képek használatát – a többi fejlesztő megköszöni.
- Gazdagép és képek szinkronizálása: Egyes konténeres alkalmazások megkövetelik, hogy a tároló szinkronizáljon a gazdagéppel bizonyos attribútumok, például idő vagy gépazonosító alapján.
- Végezetül megosztunk olyan sablonokat és bevált gyakorlatokat, amelyek segítenek a fent felsorolt elvek hatékonyabb megvalósításában:
június 11-án 11.00 órakor
Mit fogsz tanulni:
- Megváltozhatatlan Red Hat Enterprise Linux CoreOS
- OpenShift szolgáltatásháló
- Operátori keretrendszer
- Knatív keret
Forrás: will.com