Mi az a natív felhő?

Jótanács

Ez a tartalom a „Az Azure-hoz készült natív felhőalapú .NET-alkalmazások tervezése” című eBookból egy részlet, amely elérhető a .NET Docs oldalán, vagy ingyenesen letölthető PDF fájlként, amely offline módban is olvasható.

PDF letöltése

Állítsa le a munkát, és kérje meg munkatársait, hogy definiálják a "Natív felhő" kifejezést. Jó eséllyel több különböző választ is kaphat.

Kezdjük egy egyszerű definícióval:

A natív felhőbeli architektúra és technológiák a felhőbe épített számítási feladatok tervezésének, felépítésének és működtetésének egyik megközelítése, és teljes mértékben kihasználják a felhőalapú számítási modell előnyeit.

A Cloud Native Computing Foundation a következő hivatalos definíciót biztosítja:

A natív felhőtechnológiák segítségével a szervezetek skálázható alkalmazásokat hozhatnak létre és futtathatnak modern, dinamikus környezetekben, például nyilvános, privát és hibrid felhőkben. A tárolók, a szolgáltatáshálók, a mikroszolgáltatások, a nem módosítható infrastruktúra és a deklaratív API-k szemléltetik ezt a megközelítést.

Ezek a technikák lehetővé teszik a lazán összekapcsolt rendszereket, amelyek rugalmasak, kezelhetők és megfigyelhetők. A robusztus automatizálással kombinálva lehetővé teszik a mérnökök számára, hogy a nagy hatású módosításokat gyakran és kiszámíthatóan, minimális terheléssel hajtják végre.

A natív felhő a sebességről és az agilitásról szól. Az üzleti rendszerek az üzleti képességek lehetővé tételétől a stratégiai átalakulás fegyvereiig fejlődnek, amelyek felgyorsítják az üzleti sebességet és a növekedést. Elengedhetetlen, hogy azonnal új ötleteket szerezzünk be a piacra.

Ugyanakkor az üzleti rendszerek is egyre összetettebbé váltak, mivel a felhasználók egyre többet követelnek. Gyors válaszkészséget, innovatív funkciókat és nulla állásidőt várnak. A teljesítményproblémák, az ismétlődő hibák és a gyors mozgás képtelensége már nem elfogadható. A felhasználók felkeresik a versenytársát. A felhőszolgáltatások a gyors változást, a nagy léptéket és a rugalmasságot szem előtt tartva lettek kialakítva.

Íme néhány vállalat, akik natív felhőbeli technikákat alkalmaztak. Gondoljon az elért sebességre, rugalmasságra és méretezhetőségre.

Cég	Élmény
Netflix	Éles környezetben több mint 600 szolgáltatás működik. Naponta 100-szor telepít.
Uber	1,000+ szolgáltatás van a gyártási környezetben. Hetente több ezer alkalommal telepítik.
WeChat	Több mint 3000 szolgáltatása van élesben. Naponta 1000 alkalommal helyezi üzembe.

Mint látható, a Netflix, az Uber és a WeChat olyan natív felhőrendszereket tesz elérhetővé, amelyek számos független szolgáltatásból állnak. Ez az architektúrastílus lehetővé teszi számukra, hogy gyorsan reagáljanak a piaci feltételekre. Azonnal frissítik az élő, összetett alkalmazások kis területeit, teljes újratelepítés nélkül. Igény szerint egyenként méretezik a szolgáltatásokat.

A natív felhő alappillérei

A natív felhő sebessége és rugalmassága számos tényezőből ered. Elsősorban a felhőinfrastruktúra. De van még más is: Az 1–3. ábrán látható öt alappillér a natív felhőrendszerek alapkövét is biztosítja.

1. ábra 3 Natív felhőbeli alappillérek

Szánjunk egy kis időt, hogy jobban megértsük az egyes pillérek jelentőségét.

A felhő

A natív felhőrendszerek teljes mértékben kihasználják a felhőszolgáltatás-modellt.

A dinamikus, virtualizált felhőkörnyezetekben való boldogulásra tervezett rendszerek széles körben használják a Platform mint Szolgáltatás (PaaS) számítási infrastruktúrát és felügyelt szolgáltatásokat. Az alapul szolgáló infrastruktúrát az automatizáláson keresztül eldobhatóként kezelik – percek alatt kiépítve, átméretezve, skálázva vagy megsemmisítve igény szerint.

Fontolja meg a különbséget a háziállatok és az áruk kezelése között. Egy hagyományos adatközpontban a kiszolgálókat háziállatokként kezelik: egy fizikai gépet, amely értelmes nevet ad, és gondoskodik a kezelésről. A méretezéshez több erőforrást kell hozzáadnia ugyanahhoz a géphez (felskálázás). Ha a kiszolgáló megbetegszik, ápolni kell, amíg egészséges nem lesz. Ha a kiszolgáló elérhetetlenné válik, mindenki észreveszi.

Az árutőzsdei szolgáltatási modell eltérő. Minden példányt egy virtuális gépként vagy tárolóként konfigurálsz. Azonosak, és hozzárendeltek egy rendszerazonosítót, például a Service-01-et, a Service-02-t stb. Azáltal skálázhat, hogy további példányokat hoz létre (horizontális felskálázás). Senki sem veszi észre, ha egy példány elérhetetlenné válik.

Az árumodell nem módosítható infrastruktúrát használ. A kiszolgálók nincsenek javítva vagy módosítva. Ha az egyik meghibásodik vagy frissítést igényel, az megsemmisül, és kiépít egy újat – mindezt automatizálással.

A natív felhőrendszerek az árutőzsdei szolgáltatási modellt is magukba foglalják. Az infrastruktúra skálázása során továbbra is futnak, tekintet nélkül arra, hogy melyik gépeken futnak.

Az Azure-felhőplatform automatikus skálázási, önjavítási és monitorozási képességekkel támogatja az ilyen típusú rugalmas infrastruktúrát.

Modern kialakítás

Hogyan tervezne natív felhőbeli alkalmazást? Hogyan nézne ki az architektúra? Milyen alapelveket, mintákat és ajánlott eljárásokat követne? Milyen infrastruktúra- és üzemeltetési problémák lennének fontosak?

Az Twelve-Factor alkalmazás

A felhőalapú alkalmazások létrehozásának széles körben elfogadott módszertana a Twelve-Factor alkalmazás. A cikk olyan alapelveket és gyakorlatokat ír le, amelyeket a fejlesztők követnek a modern felhőkörnyezetekhez optimalizált alkalmazások létrehozásához. Különös figyelmet fordítanak a környezetek közötti hordozhatóságra és a deklaratív automatizálásra.

Bár bármely webalapú alkalmazásra alkalmazható, számos szakember úgy véli, hogy Twelve-Factor szilárd alapot a natív felhőbeli alkalmazások létrehozásához. Az ezen elvekre épülő rendszerek gyorsan üzembe helyezhetők és méretezhetők, és olyan funkciókat adhatnak hozzá, amelyek gyorsan reagálnak a piaci változásokra.

Az alábbi táblázat a Twelve-Factor módszertant emeli ki:

Tényező	Magyarázat
1 – Kódbázis	Egyetlen kódbázis minden mikroszolgáltatáshoz, amely a saját adattárában van tárolva. A verziókövetés nyomon követésével több környezetben is üzembe helyezhető (minőségbiztosítási, előkészítési, éles).
2 – Függőségek	Minden mikroszolgáltatás elkülöníti és csomagolja a saját függőségeit, és a változásokat a teljes rendszer befolyásolása nélkül átfogja.
3 – Konfigurációk	A konfigurációs információk a mikroszolgáltatásból kerülnek ki, és a kódon kívüli konfigurációkezelő eszközön keresztül kerülnek külsőre. Ugyanaz az üzembe helyezés több környezetben is elterjedhet a megfelelő konfiguráció alkalmazásával.
4 – Háttérszolgáltatások	A kiegészítő erőforrásokat (adattárakat, gyorsítótárakat, üzenetközvetítőket) egy címezhető URL-címen kell elérhetővé tenni. Ezzel leválasztja az erőforrást az alkalmazásról, és lehetővé teszi, hogy felcserélhető legyen.
5 - Összeállítás, kiadás, futtatás	Minden kiadásnak szigorú elkülönítést kell kikényszerítenie a buildelési, kiadási és futtatási szakaszokban. Mindegyiknek egyedi azonosítóval kell rendelkeznie, és támogatnia kell a visszaállítás lehetőségét. A modern CI/CD rendszerek segítenek ennek az alapelvnek a teljesítésében.
6 – Folyamatok	Minden mikroszolgáltatásnak a saját folyamatában kell futnia, elkülönítve más futó szolgáltatásoktól. A szükséges állapot külsősítése egy háttérszolgáltatásba, például elosztott gyorsítótárba vagy adattárba.
7 – Portkötés	Minden mikroszolgáltatásnak önállónak kell lennie a saját portján elérhető interfészeivel és funkcióival. Ez elkülöníti a többi mikroszolgáltatást.
8 – Egyidejűség	Ha a kapacitást növelni kell, horizontálisan skálázza ki a szolgáltatásokat több azonos példány (másolat) között, szemben azzal, hogy egyetlen nagy példányt méretez felfelé a rendelkezésre álló legerősebb gépen. Úgy fejlesztheti az alkalmazást, hogy egyidejűleg skálázható legyen a felhőkörnyezetekben.
9 – Eltűnés	A szolgáltatáspéldányoknak eldobhatónak kell lenniük. A gyors indítás érdekében növelje a méretezhetőségi lehetőségeket és a kecses leállításokat, hogy a rendszer megfelelő állapotban maradjon. A Docker-tárolók és a vezénylő eredendően megfelelnek ennek a követelménynek.
10 – Fejlesztési/Gyártási Környezetegyenértékűség	Tartsa a környezeteket az alkalmazás életciklusa során a lehető leginkább hasonlónak, elkerülve a költséges kiskapukat. Itt a tárolók bevezetése nagyban hozzájárulhat ugyanahhoz a végrehajtási környezethez.
11 – Naplózás	Kezelje a mikroszolgáltatások által létrehozott naplókat eseménystreamekként. Feldolgozzuk őket egy esemény-összesítővel. A naplóadatok propagálása adatbányászati/naplókezelési eszközökre, például az Azure Monitorra vagy a Splunkra, végül pedig hosszú távú archiválásra.
12 – Rendszergazdai folyamatok	Egyszeri folyamatként futtassa a felügyeleti/felügyeleti feladatokat, például az adattisztítást vagy a számítástechnikai elemzést. Használjon független eszközöket ezen feladatok megidézésére az éles környezetből, az alkalmazástól külön.

A könyvben Kevin Hoffman író az Twelve-Factor alkalmazáson túl az eredeti 12 tényező mindegyikét részletezi (2011-ben írták). Emellett három további tényezőt is bemutat, amelyek a mai modern felhőalkalmazás-kialakítást tükrözik.

Új tényező	Magyarázat
13 – ELSŐ API	Minden legyen szolgáltatás. Tegyük fel, hogy a kódot egy előtérbeli ügyfél, átjáró vagy egy másik szolgáltatás fogja használni.
14 – Telemetriai adatok	Egy munkaállomáson mélyen átlátja az alkalmazást és annak viselkedését. A felhőben nem. Győződjön meg arról, hogy a kialakítás magában foglalja a figyelési, tartományspecifikus és állapot-/rendszeradatok gyűjtését.
15 – Hitelesítés/ engedélyezés	Az identitás implementálása az elejétől kezdve. Fontolja meg a nyilvános felhőkben elérhető RBAC(szerepköralapú hozzáférés-vezérlés) funkciókat.

Ebben a fejezetben és az egész könyvben több mint 12 tényezőre fogunk hivatkozni.

Az Azure Jól Megtervezett Keretrendszere

A felhőalapú számítási feladatok tervezése és üzembe helyezése kihívást jelenthet, különösen a natív felhőbeli architektúra megvalósításakor. A Microsoft iparági szabványoknak megfelelő ajánlott eljárásokkal segíti Önt és csapatát a robusztus felhőmegoldások biztosításában.

A Microsoft Well-Architected-keretrendszer olyan vezérelveket biztosít, amelyek a natív felhőbeli számítási feladatok minőségének javítására használhatók. A keretrendszer az architektúra kiválóságának öt pilléréből áll:

Elvek	Leírás
Cost Management	Összpontosítson a növekményes érték korai létrehozására. A Build-Measure-Learn alapelvek alkalmazásával felgyorsíthatja a piacra kerülést, és elkerülheti a tőkeigényes megoldásokat. Használatalapú fizetéses stratégiával fektessen be, miközben felskálázza rendszerét, ahelyett, hogy nagy befektetést hajtana végre előre.
Működésbeli kiválóság	Automatizálja a környezetet és a műveleteket a sebesség növelése és az emberi hibák csökkentése érdekében. A probléma frissítéseit gyorsan visszavonhatja vagy előremozdíthatja. A monitorozás és a diagnosztikák implementálása az elejétől kezdve.
Teljesítményhatékonyság	Hatékonyan kielégítheti a számítási feladatokra vonatkozó igényeket. Előnyben részesítheti a horizontális skálázást (horizontális felskálázást), és megtervezheti azt a rendszerekben. Folyamatosan végezzen teljesítmény- és terheléstesztelést a lehetséges szűk keresztmetszetek azonosítása érdekében.
Megbízhatóság	Rugalmas és elérhető számítási feladatokat hozhat létre. A rugalmasság lehetővé teszi, hogy a számítási feladatok helyreálljanak a hibákból, és továbbra is működjenek. A rendelkezésre állás biztosítja, hogy a felhasználók mindig hozzáférjenek a számítási feladathoz. Tervezze meg az alkalmazásokat, hogy hibákra számítson, és helyreállítsa őket.
biztonság	A biztonság megvalósítása az alkalmazás teljes életciklusa során, a tervezéstől a megvalósításon át az üzembe helyezésig és a műveletekig. Ügyeljen az identitáskezelésre, az infrastruktúra-hozzáférésre, az alkalmazásbiztonságra, valamint az adatok szuverenitására és titkosítására.

Az első lépésekhez a Microsoft online értékeléseket biztosít, amelyek segítenek felmérni az aktuális felhőbeli számítási feladatokat az öt jól felépítésű alappillér alapján.

Mikroszolgáltatások

A natív felhőrendszerek a mikroszolgáltatásokat, a modern alkalmazások készítésének népszerű architekturális stílusát ölelik fel.

A megosztott hálón keresztül kommunikáló kis, független szolgáltatások elosztott készleteként készült mikroszolgáltatások a következő jellemzőkkel rendelkeznek:

• Mindegyik egy adott üzleti képességet valósít meg egy nagyobb tartománykörnyezetben.

• Mindegyik önállóan lett kifejlesztve, és egymástól függetlenül is üzembe helyezhető.

• Mindegyik önállóan foglalja magában a saját adattárolási technológiáját, függőségeit és programozási platformját.

• Mindegyik a saját folyamatában fut, és olyan szabványos kommunikációs protokollokkal kommunikál, mint a HTTP/HTTPS, a gRPC, a WebSockets vagy az AMQP.

• Együtt alkotnak egy alkalmazást.

Az 1–4. ábra egy monolitikus alkalmazás megközelítést hasonlít egy mikroszolgáltatás-megközelítéshez. Figyelje meg, hogy a monolit egy rétegzett architektúrából áll, amely egyetlen folyamat során fut. Általában relációs adatbázist használ. A mikroszolgáltatás-megközelítés azonban elkülöníti a funkciókat független szolgáltatásokra, amelyek mindegyike saját logikával, állapottal és adatokkal rendelkezik. Minden mikroszolgáltatás saját adattárat üzemeltet.

1-4. ábra. Monolitikus és mikroszolgáltatási architektúra

Figyelje meg, hogy a mikroszolgáltatások hogyan támogatják a folyamatok elvét a fejezet korábbi részében tárgyalt Twelve-Factor alkalmazásból.

A 6. faktor a következőt adja meg: "Minden mikroszolgáltatásnak a saját folyamatában kell futnia, elkülönítve más futó szolgáltatásoktól."

Miért a mikroszolgáltatások?

A mikroszolgáltatások rugalmasságot biztosítanak.

A fejezet korábbi részében egy monolitikusként létrehozott e-kereskedelmi alkalmazást hasonlítottunk össze a mikroszolgáltatásokkal. A példában egyértelmű előnyöket láthattunk:

• Minden mikroszolgáltatás önálló életciklusokkal rendelkezik, és önállóan fejlődhet és gyakran üzembe helyezhető. Nem kell megvárnia, amíg egy negyedéves kiadás üzembe helyez egy új funkciót vagy frissítést. Az élő alkalmazások egy kis területét frissítheti, és kisebb a kockázata annak, hogy megzavarja a teljes rendszert. A frissítés az alkalmazás teljes újbóli üzembe helyezése nélkül is megvalósítható.

• Minden mikroszolgáltatás egymástól függetlenül skálázható. A teljes alkalmazás egyetlen egységként való skálázása helyett csak azokat a szolgáltatásokat skálázza fel, amelyek nagyobb feldolgozási teljesítményt igényelnek a kívánt teljesítményszintek és szolgáltatási szintű szerződések teljesítéséhez. A részletes skálázás nagyobb ellenőrzést biztosít a rendszer felett, és segít csökkenteni a teljes költségeket, miközben a rendszer egyes részeit skálázza, nem mindent.

A mikroszolgáltatások megértéséhez kiváló referencia-útmutató a .NET Microservices: Architecture for Containerized .NET Applications. A könyv részletesen foglalkozik a mikroszolgáltatások tervezésével és architektúrával. A Microsofttól ingyenesen letölthető teljes körű mikroszolgáltatás-referenciaarchitektúra társa.

Mikroszolgáltatások fejlesztése

A mikroszolgáltatások bármilyen modern fejlesztési platformon létrehozhatók.

A Microsoft .NET platform kiváló választás. Ingyenes és nyílt forráskódú, számos beépített funkcióval rendelkezik, amelyek leegyszerűsítik a mikroszolgáltatások fejlesztését. A .NET platformfüggetlen. Az alkalmazások Windowson, macOS-en és a Linux legtöbb verzióján is felépíthetők és futtathatók.

A .NET nagy teljesítményű, és jól teljesített a Node.js és más konkurens platformokhoz képest. Érdekes módon a TechEmpower számos webalkalmazási platform és keretrendszer esetében végzett kiterjedt teljesítményteszteket. .NET szerepelt az első tíz helyen - jóval meghaladva a Node.js-t és más versenytárs platformokat.

A .NET-et a Microsoft és a GitHub .NET-közössége tartja karban.

A mikroszolgáltatások kihívásai

Bár az elosztott natív felhőbeli mikroszolgáltatások óriási rugalmasságot és sebességet biztosíthatnak, számos kihívást jelentenek:

Kommunikáció

Hogyan kommunikálnak az előtérbeli ügyfélalkalmazások a háttérrendszerbeli alapvető mikroszolgáltatásokkal? Engedélyezi a közvetlen kommunikációt? Vagy elvonhatja a háttérbeli mikroszolgáltatásokat egy olyan átjáróhomlokzattal, amely rugalmasságot, felügyeletet és biztonságot nyújt?

Hogyan kommunikálnak egymással a háttérrendszeri alapvető mikroszolgáltatások? Engedélyezi a közvetlen HTTP-hívásokat, amelyek növelhetik az összekapcsolást, és befolyásolhatják a teljesítményt és a rugalmasságot? Vagy megfontolhatja az aszinkron üzenetküldést sor- és tématechnológiákkal?

A kommunikációt a natív felhőbeli kommunikációs minták fejezete ismerteti.

rugalmasság

A mikroszolgáltatás-architektúra a folyamatban lévő rendszerről a folyamaton kívüli hálózati kommunikációra helyezi át a rendszert. Elosztott architektúrában mi történik, ha a B szolgáltatás nem válaszol az A szolgáltatásból érkező hálózati hívásra? Vagy mi történik, ha a C szolgáltatás átmenetileg elérhetetlenné válik, és az azt meghívó egyéb szolgáltatások le lesznek tiltva?

A rugalmasságról a natív felhőbeli rugalmasság fejezet foglalkozik .

Elosztott adatok

A tervezés során minden mikroszolgáltatás magában foglalja a saját adatait, és nyilvános felületen teszi közzé a műveleteket. Ha igen, hogyan kérdezhet le adatokat, vagy hogyan valósíthat meg tranzakciót több szolgáltatáson keresztül?

Az elosztott adatokat a natív felhőbeli adatminták fejezet ismerteti.

Titkos kódok

Hogyan tárolják és kezelik biztonságosan a mikroszolgáltatások a titkos kulcsokat és a bizalmas konfigurációs adatokat?

A titkok részletesen ismertetve vannak a felhőalapú biztonság során.

Összetettség kezelése a Dapr használatával

A Dapr egy elosztott, nyílt forráskódú alkalmazás futtatókörnyezete. A csatlakoztatható összetevők architektúrája jelentősen leegyszerűsíti az elosztott alkalmazások mögötti vízvezetékeket . Dinamikus ragasztót biztosít, amely összekapcsolja az alkalmazást az előre elkészített infrastruktúra-képességekkel és összetevőkkel a Dapr futtatókörnyezetből. Az 1-5. ábrán Dapr látható 20 000 lábról.

1–5. ábra. Dapr 20 000 láb magasan.

Az ábra felső sorában figyelje meg, hogy a Dapr hogyan biztosít nyelvspecifikus SDK-kat a népszerű fejlesztési platformokhoz. A Dapr v1 támogatja a .NET, a Go, a Node.js, a Python, a PHP, a Java és a JavaScript használatát.

Bár a nyelvspecifikus SDK-k növelik a fejlesztői élményt, a Dapr platformfüggő. A motorháztető alatt a Dapr programozási modellje szabványos HTTP/gRPC kommunikációs protokollokkal teszi elérhetővé a képességeket. Bármely programozási platform meghívhatja a Daprt a natív HTTP- és gRPC API-kkal.

Az ábra közepén lévő kék dobozok a Dapr építőelemeket jelölik. Mindegyik előre elkészített vízvezeték-kódot tesz elérhetővé egy elosztott alkalmazásképességhez, amelyet az alkalmazás felhasználhat.

Az összetevők sor számos előre definiált infrastruktúra-összetevőt jelöl, amelyeket az alkalmazás felhasználhat. Az összetevőket olyan infrastruktúra-kódnak tekintheti, amelyeket nem kell írnia.

Az alsó sor kiemeli a Dapr hordozhatóságát és azokat a különböző környezeteket, amelyeken futtatható.

Előretekintve a Dapr potenciálisan jelentős hatással lehet a natív felhőbeli alkalmazások fejlesztésére.

Tartályok

Természetes, hogy minden natív felhőbeli beszélgetésben a tároló kifejezés hallható. A könyvben Cornelia Davis, a Cloud Native Patterns szerzője megjegyzi, hogy "A tárolók nagyszerűen teszik lehetővé a natív felhőbeli szoftvereket." A Cloud Native Computing Foundation első lépésként helyezi el a mikroszolgáltatás-tárolók használatát aCloud-Native Trail Mapben – útmutatást nyújt a natív felhőbeli utazást kezdő vállalatoknak.

A mikroszolgáltatások konténerizálása egyszerű. A kód, a függőségek és a futtatókörnyezet egy tárolórendszerképnek nevezett bináris fájlba van csomagolva. A lemezképeket egy konténer-regisztrációs adatbázisban tárolják, amely képtárként működik. A beállításjegyzék a fejlesztői számítógépen, az adatközpontban vagy egy nyilvános felhőben is elhelyezhető. Maga a Docker egy nyilvános regisztrációs adatbázist tart fenn a Docker Hubon keresztül. Az Azure-felhő egy privát tárolóregisztrációs adatbázissal rendelkezik, amely tárolólemezképeket tárol az őket futtató felhőalkalmazásokhoz közel.

Amikor egy alkalmazás elindul vagy skáláz, a tárolórendszerképet egy futó tárolópéldánysá alakítja át. A példány minden olyan számítógépen fut, amelyen telepítve van egy konténer futtatókörnyezet. A tárolóalapú szolgáltatásnak szükség szerint annyi példánya lehet.

Az 1–6. ábra három különböző mikroszolgáltatást mutat be, mindegyik a saját tárolójában található, és mindegyik egyetlen gazdagépen fut.

Az 1–6. ábra. Több konténer fut egy konténer gazdagépen

Figyelje meg, hogy az egyes tárolók hogyan tartják fenn a saját függőségek és futtatókörnyezetek készletét, amelyek eltérhetnek egymástól. Itt a Termék mikroszolgáltatás különböző verziói futnak ugyanazon a gazdagépen. Minden tároló a mögöttes gazdagép operációs rendszerének, memóriájának és processzorának egy szeletét osztja meg, de elkülönítve van egymástól.

Figyelje meg, hogy a tárolómodell mennyire támogatja a függőségek elvét az Twelve-Factor alkalmazásból.

A 2. faktor azt határozza meg, hogy "Minden mikroszolgáltatás elkülöníti és csomagolja a saját függőségeit, és a változásokat a teljes rendszer befolyásolása nélkül átfogja."

A tárolók linuxos és Windowsos számítási feladatokat is támogatnak. Az Azure-felhő nyíltan mindkettőt magában foglalja. Érdekes, hogy nem a Windows Server, hanem a Linux lett az Azure népszerűbb operációs rendszere.

Bár számos tárolószállító létezik, a Docker elfoglalta a piac oroszlánrészét. A vállalat vezeti a szoftverkonténerek mozgalmát. Ez a natív felhőbeli alkalmazások csomagolásának, üzembe helyezésének és futtatásának de facto szabványává vált.

Miért a tárolók?

A tárolók hordozhatóságot biztosítanak, és garantálják a környezetek konzisztenciáját. Ha mindent egyetlen csomagba foglal, elkülönítheti a mikroszolgáltatást és annak függőségeit a mögöttes infrastruktúrától.

A tárolót bármely olyan környezetben üzembe helyezheti, amely a Docker futtatókörnyezeti motort üzemelteti. A tárolóalapú számítási feladatok emellett kiküszöbölik az egyes környezetek keretrendszerekkel, szoftverkódtárakkal és futtatókörnyezeti motorokkal való előzetes konfigurálásának költségeit.

A mögöttes operációs rendszer és a gazdagép erőforrásainak megosztásával a konténernek sokkal kisebb a lábnyoma, mint egy teljes virtuális gépnek. A kisebb méret növeli annak sűrűségét, illetve növeli az adott gazdagép által egyszerre futtatható mikroszolgáltatások számát.

Konténerorchesztráció

Bár az olyan eszközök, mint a Docker, lemezképeket hoznak létre és tárolókat futtatnak, a kezelésükhöz eszközökre is szükség van. A tárolókezelés egy speciális, tárolóvezénylőnek nevezett szoftverprogrammal történik. Nagy léptékben történő működés esetén, amikor számos független tároló fut, az orchestration elengedhetetlen.

Az 1–7. ábra a tárolóvezénylők által automatizálható felügyeleti feladatokat mutatja be.

1-7. ábra. A konténer-vezénylők teendői

Az alábbi táblázat a gyakori vezénylési feladatokat ismerteti.

Tevékenységek	Magyarázat
Ütemezés	Automatikusan telepíti a tárolópéldányokat.
Affinitás/affinitás-ellenesség	Tárolók kiépítése egymás közelében vagy távol egymástól, segítve a rendelkezésre állást és a teljesítményt.
Állapotfigyelés	Hibák automatikus észlelése és javítása.
Átállás	A sikertelen példányok automatikus újraépítése egy kifogástalan állapotú gépre.
Skálázás	Tárolópéldány automatikus hozzáadása vagy eltávolítása az igényeknek megfelelően.
Kapcsolatteremtés	Hálózati átfedés kezelése tárolók közötti kommunikációhoz.
Szolgáltatásfelderítés	Tegye lehetővé, hogy a konténerek megtalálják egymást.
Folyamatos frissítések	Fokozatos frissítések koordinálása állásidőmentes bevezetéssel. A problémás módosítások automatikus visszaállítása.

Figyelje meg, hogy a tárolóvezénylők hogyan fogadják el az Twelve-Factor alkalmazásdisposability és concurrency alapelveit.

A 9. faktor azt határozza meg, hogy "A szolgáltatáspéldányoknak eldobhatónak kell lenniük, a gyors indításoknak előnyben részesítve a méretezhetőségi lehetőségeket és a kecses leállításokat, hogy a rendszer megfelelő állapotban maradjon." A Docker-tárolók és egy vezénylő eredendően megfelelnek ennek a követelménynek."

A 8. faktor azt határozza meg, hogy "A szolgáltatások nagy számú kis azonos folyamat (másolat) között skálázhatók fel, szemben azzal, hogy egyetlen nagy példányt skáláznak fel a rendelkezésre álló legerősebb gépen."

Bár számos tárolóvezénylő létezik, a Kubernetes a natív felhőbeli világ de facto szabványává vált. Ez egy hordozható, bővíthető, nyílt forráskódú platform a tárolóalapú számítási feladatok kezeléséhez.

A Kubernetes saját példányát üzemeltetheti, de az erőforrások kiépítéséért és kezeléséért ön felelne – ami összetett is lehet. Az Azure-felhő felügyelt szolgáltatásként tartalmazza a Kubernetes szolgáltatást. Az Azure Kubernetes Service (AKS) és az Azure Red Hat OpenShift (ARO) egyaránt lehetővé teszi a Kubernetes funkcióinak és hatalmának teljes kihasználását felügyelt szolgáltatásként anélkül, hogy telepítenie és karbantartania kellene.

A konténerek orchestrálását részletesen ismerteti a Scaling Cloud-Native Applications.

Háttérszolgáltatások

A natív felhőrendszerek számos különböző kiegészítő erőforrástól függenek, például adattáraktól, üzenetközvetítőktől, monitorozástól és identitásszolgáltatásoktól. Ezeket a szolgáltatásokat háttérszolgáltatásoknak nevezzük.

Az 1–8. ábra számos olyan gyakori háttérszolgáltatást mutat be, amelyeket a natív felhőbeli rendszerek használnak.

1-8. ábra. Gyakori háttérszolgáltatások

Üzemeltetheti saját háttérszolgáltatásait, de ön lenne a felelős azok licenceléséért, biztosításáért és kezeléséért.

A felhőszolgáltatók számos felügyelt háttérszolgáltatást kínálnak. A szolgáltatás birtoklása helyett egyszerűen használja azt. A felhőszolgáltató nagy léptékben üzemelteti az erőforrást, és a teljesítményért, a biztonságért és a karbantartásért felelős. A monitorozás, a redundancia és a rendelkezésre állás be van építve a szolgáltatásba. A szolgáltatók garantálják a szolgáltatásszintű teljesítményt, és teljes mértékben támogatják a felügyelt szolgáltatásokat – nyisson meg egy jegyet, és kijavítsák a problémát.

A natív felhőrendszerek előnyben részesítik a felhőgyártók által nyújtott felügyelt háttérszolgáltatásokat. Az idő- és munkamegtakarítás jelentős lehet. A saját rendszer üzemeltetésének kockázata, valamint az esetleges problémák gyorsan költségessé válhatnak.

Ajánlott eljárás a háttérszolgáltatás csatolt erőforrásként való kezelése, amely dinamikusan kötődik egy mikroszolgáltatáshoz egy külső konfigurációban tárolt konfigurációs információkkal (URL-címmel és hitelesítő adatokkal). Ezt az útmutatót a fejezet korábbi részében tárgyalt Twelve-Factor-alkalmazás ismerteti.

A 4. faktor azt határozza meg, hogy a háttérszolgáltatásoknak "egy címezhető URL-címen keresztül kell elérhetővé tenni. Ezzel leválasztja az erőforrást az alkalmazásról, és lehetővé teszi, hogy felcserélhető legyen."

A 3. faktor azt adja meg, hogy "A konfigurációs információk a mikroszolgáltatásból kerülnek át, és a kódon kívüli konfigurációkezelő eszközön keresztül kerülnek kivezetésre".

Ezzel a mintával a háttérszolgáltatás kódmódosítások nélkül csatolható és leválasztható. Áthelyezhet egy mikroszolgáltatást a minőségbiztosítási környezetből egy tesztkörnyezetbe. Frissítse a mikroszolgáltatás-konfigurációt, hogy az átmeneti háttérszolgáltatásokra mutasson, és egy környezeti változón keresztül injektálja a beállításokat a tárolóba.

A felhőszolgáltatók API-kat biztosítanak a saját háttérszolgáltatásukkal való kommunikációhoz. Ezek a kódtárak befoglalják a saját belső rendszereket és az összetettséget. A közvetlenül ezekkel az API-kkal folytatott kommunikáció azonban szorosan összekapcsolja a kódot az adott háttérszolgáltatással. Széles körben elfogadott eljárás a szállítói API implementálási részleteinek szigetelése. Bevezethet egy közvetítő réteget vagy köztes API-t, amely általános műveleteket jelenít meg a szolgáltatáskódban, és becsomagolja a szállítói kódot. Ez a laza összekapcsolás lehetővé teszi, hogy felcserélje az egyik háttérszolgáltatást egy másikra, vagy áthelyezhesse a kódot egy másik felhőkörnyezetbe anélkül, hogy módosítania kellene a fővonal szolgáltatáskódját. A korábban tárgyalt Dapr ezt a modellt követi előre összeállított építőelemeivel.

Végső gondolatként a háttérszolgáltatások is támogatják a statelessness elvet az Twelve-Factor alkalmazásból, amelyet a fejezet korábbi részében tárgyaltak.

A 6. faktor a következőt adja meg: "Minden mikroszolgáltatásnak a saját folyamatában kell futnia, elkülönítve más futó szolgáltatásoktól. A szükséges állapotokat egy háttérszolgáltatásba, például elosztott gyorsítótárba vagy adattárba helyezzük át.

A háttérszolgáltatásokat a natív felhőbeli adatmintákban és a natív felhőbeli kommunikációs mintákban tárgyaljuk.

Automatizálás

Mint láthatta, a natív felhőrendszerek a mikroszolgáltatásokat, a tárolókat és a modern rendszertervezést is magukba foglalják a sebesség és a rugalmasság elérése érdekében. De ez csak a történet része. Hogyan építheti ki azokat a felhőkörnyezeteket, amelyeken ezek a rendszerek futnak? Hogyan helyezheti üzembe gyorsan az alkalmazás funkcióit és frissítéseit? Hogyan kerekítetted ki a teljes képet?

Bemutatjuk a kódként megvalósított infrastruktúra, vagyis az IaC széles körben elfogadott gyakorlatát.

Az IaC-vel automatizálhatja a platformok kiépítését és az alkalmazások üzembe helyezését. A DevOps-eljárásokra lényegében olyan szoftverfejlesztési eljárásokat alkalmazhat, mint a tesztelés és a verziószámozás. Az infrastruktúra és a telepítések automatizáltak, következetesek és megismételhetők.

Infrastruktúra automatizálása

Az olyan eszközök, mint az Azure Resource Manager, az Azure Bicep, a Terraform a HashiCorpból és az Azure CLI, lehetővé teszik a szükséges felhőinfrastruktúra deklaratív szkriptjét. Az erőforrásnevek, helyek, kapacitások és titkos kódok paraméterezettek és dinamikusak. A szkript verziószámozott, és bekerült a forrásvezérlőbe, mint a projekt egyik összetevője. Lefuttatja a szkriptet, hogy konzisztens és megismételhető infrastruktúrát hozzon létre a rendszerkörnyezetekben, például a minőségbiztosítási, tesztelési és éles környezetekben.

A felszín alatt az IaC idempotens, ami azt jelenti, hogy ugyanaz a szkript többször is futtatható mellékhatások nélkül. Ha a csapatnak módosítást kell végeznie, szerkessze és futtassa újra a szkriptet. Csak a frissített erőforrásokat érinti.

A What is Infrastructure as Code című cikkben Sam Guckenheimer szerző a következőt írja le: "Az IaC-t implementáló csapatok gyorsan és nagy méretekben képesek stabil környezeteket biztosítani. Elkerülik a környezetek manuális konfigurálását, és a konzisztenciát úgy kényszerítik ki, hogy kóddal jelölik a környezetük kívánt állapotát. Az IaC-vel rendelkező infrastruktúra-telepítések megismételhetők, és megakadályozzák a konfigurációs eltérés vagy a hiányzó függőségek által okozott futásidejű problémákat. A DevOps-csapatok egységes gyakorlatokkal és eszközökkel dolgozhatnak együtt az alkalmazások és azok támogató infrastruktúrájának gyors, megbízható és nagy léptékű biztosításához."

Üzembe helyezés automatizálása

A korábban tárgyalt Twelve-Factor alkalmazás külön lépéseket kér a befejezett kód futó alkalmazássá alakításakor.

Az 5. faktor azt határozza meg, hogy "Minden kiadásnak szigorú elkülönítést kell kikényszerítenie a buildelési, kiadási és futtatási szakaszokban. Mindegyiknek egyedi azonosítóval kell rendelkeznie, és támogatnia kell a visszaállítás lehetőségét."

A modern CI/CD rendszerek segítenek ennek az alapelvnek a teljesítésében. Külön összeállítási és kézbesítési lépéseket biztosítanak, amelyek segítenek a felhasználók számára könnyen elérhető egységes és minőségi kód biztosításában.

Az 1–9. ábra az üzembe helyezési folyamat elkülönítését mutatja be.

Ábra 1–9. Üzembe helyezési lépések CI/CD csővezetékben

Az előző ábrán különös figyelmet kell fordítani a feladatok elkülönítésére:

1. A fejlesztő létrehoz egy funkciót a fejlesztői környezetében, és végighalad a kód, a futtatás és a hibakeresés "belső ciklusán".
2. Ha elkészült, a kód le lesz küldve egy kódtárba, például a GitHubba, az Azure DevOpsba vagy a BitBucketbe.
3. A leküldés elindít egy buildelési szakaszt, amely bináris összetevővé alakítja a kódot. A munka egy folyamatos integrációs (CI) folyamattal van implementálva. Automatikusan létrehozza, teszteli és csomagolja az alkalmazást.
4. A kiadási fázis felveszi a bináris összetevőt, külső alkalmazás- és környezetkonfigurációs információkat alkalmaz, és megváltoztathatatlan kiadást hoz létre. A kiadás egy adott környezetben van üzembe helyezve. A munka egy folyamatos kézbesítési (CD) folyamattal van implementálva. Minden kiadásnak azonosíthatónak kell lennie. "Ez az üzembe helyezés az alkalmazás 2.1.1-es kiadását futtatja".
5. Végül a kiadott funkció a célvégrehajtási környezetben fut. A kiadások nem módosíthatók, ami azt jelenti, hogy minden módosításnak létre kell hoznia egy új kiadást.

Ezen eljárások alkalmazásával a szervezetek gyökeresen átalakították a szoftverek szállításának módját. Sokan átálltak a negyedéves kiadásokról az igény szerinti frissítésekre. A cél az, hogy a fejlesztési ciklus korai szakaszában elkapja a problémákat, amikor azok kevésbé költségesek a javításukhoz. Minél hosszabb ideig tart az integráció, annál drágább problémákat kell megoldani. Az integrációs folyamat konzisztenciája miatt a csapatok gyakrabban véglegesíthetik a kódmódosításokat, ami jobb együttműködést és szoftverminőséget eredményez.

Az infrastruktúra mint kód- és üzembehelyezési automatizálás, valamint a GitHub és az Azure DevOps részletes ismertetését a DevOps ismerteti.

ElőzőKövetkező