Az alkalmazásplatform finomítása

Miután megismerte a platformmérnöki folyamat során először kezelni kívánt problémákat, előfordulhat, hogy az alkalmazásplatformmal kapcsolatos kihívásokat kell megoldania. Ez a cikk néhány tippet tartalmaz arra vonatkozóan, hogyan teheti ezt meg. Többet tudhat meg a jól felépítésű alkalmazásplatformok létrehozásának gyakran elmulasztott vagy elfelejtett aspektusairól. Konkrétan az infrastruktúra-kezelés, a biztonság, a költségkezelés, a szabályozás és a megfigyelhetőség.

Annak eldöntése, hogy mikor és hol érdemes befektetni

Ha ma egy vagy több alkalmazásplatformja van, nehéz lehet eldönteni, hogy mikor és hol érdemes befektetni az azonosított problémákat megoldó fejlesztésekbe. Ha most kezdi a friss építést, az Azure Architecture Center számos lehetséges mintával rendelkezik, amelyet kiértékelhet. Ezen kívül azonban íme néhány megfontolandó kérdés, amikor elkezdi megtervezni, hogy mit szeretne tenni:

A meglévő alkalmazásplatform-befektetések adaptálása jó módszer lehet a kezdésre. Amikor frissítéseket készít, érdemes lehet új alkalmazásokkal kezdeni, hogy egyszerűbbé tegye a próbaüzemi ötleteket a bevezetés előtt. A változás tényezője az IaC és az alkalmazás templating révén. Az egyedi igényeknek megfelelő egyéni megoldásokba nagy hatású, nagy értékű területeken fektet be. Ellenkező esetben próbáljon meg egy polcon kívüli megoldást használni. A mérnöki rendszerekhez hasonlóan a kiépítés, a nyomon követés és az üzembe helyezés automatizálására kell összpontosítania ahelyett, hogy egy merev utat feltételezve segítenek a változás kezelésében az idő múlásával.

Tervezési és architektúrabeli szempontok

Bár számos lehetséges alkalmazásplatform-mintát használhat, íme néhány gyakori terület, amelyek kritikus fontosságúak, de gyakran kimaradnak a tervezés során.

Infrastruktúra-kezelés

Amint azt a Szoftvermérnöki rendszerek alkalmazása című témakörben említettük, az IaC- és automatizálási eszközök kombinálhatók sablonokkal az infrastruktúra és az alkalmazások üzembe helyezésének szabványosításához. A végfelhasználó platformspecifikus jellemzőinek csökkentése érdekében elvonja a platform részleteit úgy, hogy a választási lehetőségeket átlátható elnevezési konvenciókra bontja, például:

• Erőforrástípus-kategóriák (magas számítás, magas memória)
• Erőforrás-méretkategóriák (pólóméretezés, kis közepes és nagy).)

A cél az, hogy olyan sablonokkal rendelkezzenek, amelyek általános követelményeket képviselnek, amelyeket előre beállított konfigurációkkal teszteltek, így a fejlesztői csapatok azonnal megkezdhetik a minimális paraméterek megadását, és nem kell áttekinteniük a beállításokat. Vannak azonban olyan alkalmak, amikor a csapatoknak több lehetőséget kell módosítaniuk a közzétett sablonokon, mint amennyi elérhető vagy kívánatos. Egy jóváhagyott tervnek például szüksége lehet egy olyan konfigurációra, amely kívül esik a támogatott sablon alapértelmezett beállításain. Ebben az esetben a műveleti vagy platformmérnöki csapatok létrehozhatnak egy egyszeri konfigurációt, majd eldönthetik, hogy a sablonnak be kell-e építenie ezeket a módosításokat alapértelmezettként.

A változások nyomon követéséhez IaC-eszközökkel végezhet eltolódásészlelési funkciókat, amelyek automatikusan orvosolhatják az eltolódást (GitOps). Ilyen eszközök például a Terraform és a natív felhőbeli IaC-eszközök (például Cluster API, Crossplane, Azure Service Operator v2). Az IaC-eszközök sodródásán kívül vannak olyan felhőkonfigurációs eszközök, amelyek lekérdezhetik az erőforrás-konfigurációkat, például az Azure Resource Graph. Ezek két előnyt jelenthetnek; figyeli az infrastruktúra kódján kívüli módosításokat, és áttekinti a módosított előre beállított konfigurációkat. A túl merevség elkerülése érdekében előre meghatározott korlátozásokkal is implementálhat tűréshatárokat az üzemelő példányokban. A Azure Policy például korlátozhatja az üzembe helyezéshez használható Kubernetes-csomópontok számát.

Önkiszolgáló vagy felügyelt?

Nyilvános felhőkben választhat, hogy saaS-t, PaaS-t vagy IaaS-t használ. Az SaaS-ről, a PaaS-ről és az IaaS-ről további információt a Felhőfogalmak ismertetése című képzési modulban talál. A PaaS-szolgáltatások egyszerűsített fejlesztési élményt nyújtanak, de az alkalmazásmodelljeikhez jobban kapcsolódnak. Végső soron kompromisszum van a könnyű használat és az ellenőrzés között, amelyet értékelnie kell.

A platform tervezése során értékelje ki és rangsorolja azokat a szolgáltatásokat, amelyeket kínálni szeretne vagy át szeretne helyezni. Ha például közvetlenül az Azure Kubernetes Service (AKS) vagy az Azure Container Apps (ACA) használatával hoz létre alkalmazásokat, az a szolgáltatásra vonatkozó követelményektől, valamint a belső kapacitástól és képességkészlettől függ. Ugyanez vonatkozik a függvénystílusú szolgáltatásokra is, például Azure Functions vagy Azure App Service. Az ACA, Azure Functions és App Service csökkentik az összetettséget, míg az AKS nagyobb rugalmasságot és vezérlést biztosít. Az olyan kísérleti alkalmazásmodellek, mint az OSS Radius inkubációs projekt, megpróbálnak egyensúlyt teremteni a kettő között, de általában az érettség korábbi szakaszaiban vannak, mint a teljes körű támogatást nyújtó felhőszolgáltatások és a meglévő IaC-formátumok jelenléte.

A tervezett állapotban azonosított problémák segítenek felmérni, hogy a skálázás melyik vége megfelelő az Ön számára. A döntés meghozatalakor mindenképpen vegye figyelembe a saját belső, meglévő képességcsoportokat.

Megosztott és dedikált erőforrások

A tulajdonán belül számos olyan erőforrás van, amelyet több alkalmazás is megoszthat a kihasználtság és a költséghatékonyság növelése érdekében. A megosztható erőforrások mindegyikének saját szempontjai vannak. Ezek például a K8s-fürtök megosztásának szempontjai, de néhány más típusú erőforrásra is vonatkozik:

• Szervezet: Az erőforrások, például a fürtök szervezeti határok közötti megosztása javíthatja a szervezeti irányhoz, követelményekhez, prioritáshoz stb. való igazodás módját.
• Alkalmazás-bérlő: Az alkalmazások különböző bérlői elkülönítési követelményekkel rendelkezhetnek; Ha az alkalmazás más alkalmazásokkal együtt is működik, át kell tekintenie az egyes alkalmazások biztonságát és a jogszabályi megfelelőséget. A Kubernetesben például az alkalmazások használhatnak névtérelkülönítést. A különböző környezettípusok esetében azonban érdemes megfontolnia az alkalmazások bérlői használatát is. Gyakran érdemes például elkerülni, hogy a tesztalkalmazások és az ugyanazon a fürtön futó éles alkalmazások keveredjenek, így elkerülhetők a helytelen konfigurációk vagy biztonsági problémák miatti váratlan hatások. Vagy dönthet úgy is, hogy először teszteli és hangolja a dedikált Kubernetes-fürtöket, hogy ezeket a problémákat a megosztott fürtön való üzembe helyezés előtt nyomon kövesse. Függetlenül attól, hogy a konzisztencia a megközelítés a kulcs a félreértések és hibák elkerülése érdekében.
• Erőforrás-felhasználás: Megismerheti az egyes alkalmazáserőforrás-használatokat, a szabad kapacitásokat, és vetületet hajthat végre annak becslésére, hogy a megosztás működőképes-e. Tisztában kell lennie a felhasznált erőforrások korlátaival is (adatközpont kapacitási vagy előfizetési korlátok). A cél az, hogy elkerülje az alkalmazás és a függőségek áthelyezését egy megosztott környezetben lévő erőforrás-korlátozások vagy a kapacitáskihasználtság miatti élő webhelyesemények miatt. Az erőforráskorlátok, a reprezentatív tesztelés, a riasztások figyelése és a jelentéskészítés segítségével azonosíthatja az erőforrás-használatot, és megvédheti azokat az alkalmazásokat, amelyek túl sok erőforrást fogyasztanak, amelyek hatással lehetnek más alkalmazásokra.
• Megosztott konfigurációk optimalizálása: A megosztott erőforrások, például a megosztott fürtök további megfontolandó szempontokat és konfigurációt igényelnek. Ezek a szempontok közé tartozik a keresztterhelés, az erőforrás-kiosztás, az engedélyek kezelése, a számítási feladatok tulajdonjoga, az adatmegosztás, a frissítés koordinációja, a számítási feladatok elhelyezése, az alapkonfiguráció létrehozása, kezelése és iterálása, a kapacitáskezelés és a számítási feladatok elhelyezése. A megosztott erőforrásoknak vannak előnyei, de ha a standard konfigurációk túl korlátozóak, és nem fejlődnek, akkor elavulttá válnak.

Néhány ilyen problémát a PaaS-megoldások egyszerűsítenek, de ezek közül sok olyanra is vonatkozik, mint egy adatbázis megosztása. A megosztásnak mind a fel-, mind a lefelé oldala van, ezért alaposan meg kell fontolnia a kompromisszumokat.

A cikk Kubernetes-fürtjének aspektusáról további információt a Azure Kubernetes Service (AKS) több-bérlős dokumentációjában talál.

Cégirányítás

A szabályozás kulcsfontosságú része az önkiszolgáló és védőkorlátokkal történő engedélyezésnek, de a megfelelőségi szabályok olyan módon történő alkalmazása, amely nem befolyásolja az alkalmazások üzleti értékére vonatkozó időt, gyakori kihívás. A szabályozás széles körű téma, de ha ez a probléma merül fel, tartsa szem előtt ennek a területnek mindkét aspektusát:

• Kezdeti üzembe helyezési megfelelőség (kezdés jobbra): Ez a katalógusokon keresztül elérhető szabványos IaC-sablonokkal érhető el, engedélykezeléssel és szabályzatokkal, amelyek biztosítják, hogy csak az engedélyezett erőforrások és konfigurációk helyezhetők üzembe.
• A megfelelőség fenntartása (maradjon jobb): A szabályzatalapú eszközök megakadályozhatják vagy riasztást kaphatnak, ha erőforrás-módosítások történnek. Az alapinfrastruktúra mellett fontolja meg, hogy az eszközök a tárolókban vagy virtuális gépeken használt operációs rendszerekkel együtt az erőforrásokon, például a K8-ban is támogatják a megfelelőséget. Előfordulhat például, hogy zárolt operációsrendszer-konfigurációt szeretne kikényszeríteni, vagy olyan biztonsági szoftvereszközöket szeretne telepíteni, mint a Windows Csoportházirend, SELinux, AppArmor, Azure Policy vagy Kyverno. Ha a fejlesztők csak IaC-adattárakhoz rendelkeznek hozzáféréssel, jóváhagyási munkafolyamatokat adhat hozzá a javasolt módosítások áttekintéséhez és az erőforrás-vezérlési síkokhoz (például az Azure-hoz) való közvetlen hozzáférés megakadályozásához.

A megfelelőség fenntartásához eszközökre van szükség a problémák eléréséhez, jelentéséhez és kezeléséhez. A Azure Policy például számos Azure-szolgáltatással használható naplózáshoz, jelentéskészítéshez és szervizeléshez. Emellett különböző módokon is rendelkezik, például a Naplózás, a Megtagadás és a DeployIfNotExists az igényeitől függően.

Bár a szabályzatok kikényszeríthetik a megfelelőséget, az alkalmazásokat is váratlanul megszakíthatják. Ezért fontolja meg a szabályzatok kódként (PaC) történő kialakítását a nagy léptékű működés során. A PaC az első lépések és a helyes megközelítés kulcsfontosságú része:

• Központilag felügyelt szabványok
• A szabályzatok verziókövetése
• Automatizált tesztelés & ellenőrzés
• Rövidebb idő a bevezetéshez
• Folyamatos üzembe helyezés

A PaC segíthet minimalizálni a potenciálisan rossz szabályzat robbanási sugarát olyan képességekkel, mint például:

• A szabályzatdefiníciók kódként vannak tárolva egy áttekintett és jóváhagyott adattárban.
• Automatizálás teszteléshez és ellenőrzéshez.
• A szabályzatok köralapú fokozatos bevezetése & meglévő erőforrások szervizelése segít minimalizálni a potenciálisan rossz szabályzatok robbanási sugarát.
• A szervizelési feladat beépített biztonsággal rendelkezik, és olyan vezérlőkkel rendelkezik, mint a szervizelési feladat leállítása, ha az üzemelő példányok több mint 90 százaléka meghibásodik.

Megfigyelhetőség

Az alkalmazások és az infrastruktúra támogatásához megfigyelhetőségre és naplózásra lesz szüksége a teljes veremben, amelyet a platform mérnöki, üzemeltetési és fejlesztői csapatai használhatnak a történések megtekintéséhez.

A követelmények azonban szerepkörenként eltérőek. A platformmérnöki és üzemeltetési csapat például megköveteli, hogy az irányítópultok megfelelő riasztásokkal felülvizsgálják az infrastruktúra állapotát és kapacitását. A fejlesztőknek alkalmazásmetrikákra, naplókra és nyomkövetésekre van szükségük az alkalmazások és az infrastruktúra állapotát megjelenítő hibaelhárítási és testre szabott irányítópultok hibaelhárításához és testreszabásához. Ezeknek a szerepköröknek az egyik problémája az lehet, hogy a kognitív túlterheltség túl sok információtól vagy a hasznos információk hiánya miatti tudáshiánytól származik.

A kihívások megoldásához vegye figyelembe a következőket:

• Szabványok: A naplózási szabványok alkalmazásával egyszerűbbé teheti a szabványos irányítópultok létrehozását és újrafelhasználását, valamint leegyszerűsítheti a betöltési feldolgozást az OpenTelemetry megfigyelhetőségi keretrendszeréhez hasonló módon.
• Engedélyek: Fontolja meg a csapat- vagy alkalmazásszintű irányítópultok biztosítását a Grafana-hoz hasonló módon, hogy összesített adatokat biztosítson az érdeklődők számára, valamint egy olyan létesítményt, amellyel az alkalmazáscsapatok megbízható tagjai biztonságosan hozzáférhetnek a naplókhoz, ha szükséges.
• Visszatartás: A naplók és metrikák megőrzése költséges lehet, és nem kívánt kockázatokat vagy megfelelőségi szabálysértéseket okozhat. Hozza létre a megőrzési alapértelmezett beállításokat, és tegye közzé őket az első helyes útmutató részeként.
• Erőforráskorlátok monitorozása: Az üzemeltetési csapatoknak képesnek kell lenniük az adott típusú erőforrásra vonatkozó korlátozások azonosítására és nyomon követésére. Ha lehetséges, ezeket a korlátozásokat IaC-sablonokban vagy szabályzatokban kell figyelembe venni olyan eszközökkel, mint a Azure Policy. A műveleteknek ezután proaktívan monitorozniuk kell az irányítópultokat a Grafana-ban, és ki kell bővíteni a megosztott erőforrásokat, ahol az automatikus skálázás nem lehetséges vagy engedélyezve van. Figyelheti például a kapacitáshoz tartozó K8s-fürtcsomópontok számát, mivel az alkalmazások előkészítése és módosítása az idő múlásával történik. Riasztásra van szükség, és ezeket a definíciókat kódként kell tárolni, hogy programozott módon hozzá lehessen adni őket az erőforrásokhoz.
• A legfontosabb kapacitás- és állapotmetrikák azonosítása: Az operációs rendszer és a megosztott erőforrások (például cpu, memória, tárolás) monitorozása és riasztása a metrikagyűjtemények éhezésére a Prometheus vagy az Azure Container Insights használatával. Figyelheti a használatban lévő szoftvercsatornákat/portokat, a csevegőalkalmazások hálózati sávszélesség-felhasználását és a fürtön üzemeltetett állapotalapú alkalmazások számát.

Biztonság

A biztonság minden rétegben szükséges, a kódtól, a tárolótól, a fürttől és a felhőtől/infrastruktúrától kezdve. Minden szervezetnek megvannak a saját biztonsági követelményei, de magas szinten ezeket a szempontokat érdemes figyelembe vennie a platformjához:

• Kövesse a minimális jogosultság elvét.
• A DevOps biztonsági felügyeletének egységesítése több folyamaton keresztül.
• Győződjön meg arról, hogy a környezetfüggő elemzések a legkritikusabb kockázat azonosításához és elhárításához láthatók.
• Engedélyezze a modern fenyegetések észlelését és elhárítását a felhőbeli számítási feladatokban futásidőben.

Az ezen a területen felmerülő problémák megoldásához olyan eszközökre lesz szüksége, amelyek a mérnöki és alkalmazásrendszerekben, erőforrásokban és szolgáltatásokban működnek felhőkben és hibrid rendszerekben (például Microsoft Defender a felhőben). Az alkalmazásbiztonságon túl a következő szempontokat kell kiértékelnie:

• Külső támadási felület kezelése a Microsoft Defender külső támadásifelület-kezelő (Defender EASM) használatával.
• Hálózati biztonsági szolgáltatások – Alkalmazások és felhőbeli számítási feladatok védelme a hálózatalapú kibertámadások ellen az Azure Network Securityhez hasonló szolgáltatásokkal.
• Intelligens biztonsági elemzés – Biztonsági információ- és eseménykezelési (SIEM) megoldás, például a Microsoft Sentinel használata
• Az adattulajdon biztonságos szabályozásának, védelmének, megjelenítésének és kezelésének módjai, mint a Microsoft Purview
• A kód lehetséges biztonsági réseinek vizsgálatára, a titkos kódok észlelésére, a függőségek ( például GitHub Advanced Security és az Azure DevOps GitHub Advanced Security ) áttekintésére szolgáló módszerek.
• A szoftverellátási lánc kezelése, különösen a tárolók esetében (például a Tárolók biztonságos ellátási lánc keretrendszerének alkalmazása).

Az engedélykövetelmények környezetenként eltérhetnek. Egyes szervezetekben például az egyes csapatok nem férhetnek hozzá az éles erőforrásokhoz, és az új alkalmazások nem telepíthetők automatikusan, amíg a felülvizsgálatok be nem fejeződnek. Fejlesztői és tesztelési környezetekben azonban engedélyezett lehet az automatizált erőforrás- és alkalmazástelepítés, valamint a fürthöz való hozzáférés hibaelhárítás céljából.

A szolgáltatásokhoz, alkalmazásokhoz és infrastruktúrához való identitás-hozzáférés nagy léptékű kezelése kihívást jelenthet. Az identitásszolgáltatóknak identitásadatokat kell létrehozniuk, karbantartanak és kezelniük, miközben hitelesítési szolgáltatásokat nyújtanak az alkalmazásoknak és szolgáltatásoknak, és amelyek integrálhatók a szerepköralapú hozzáférés-vezérlési engedélyezési rendszerekkel a nagy léptékű hitelesítéshez és engedélyezéskezeléshez (RBAC). Az Azure RBAC és a Microsoft Entra ID használatával például nagy léptékű hitelesítést és engedélyezést biztosíthat az Olyan Azure-szolgáltatásokhoz, mint a Azure Kubernetes Service anélkül, hogy az engedélyeket közvetlenül minden egyes fürtön be kellene állítania.

Előfordulhat, hogy az alkalmazásoknak hozzáférésre van szükségük egy identitáshoz a felhőalapú erőforrások, például a tárterület eléréséhez. Át kell tekintenie a követelményeket, és fel kell mérnie, hogy az identitásszolgáltató hogyan támogatja ezt a lehető legbiztonságosabb módon. Az AKS-ben például a natív felhőalkalmazások olyan számítási feladat-identitást használhatnak, amely Microsoft Entra ID összevonva lehetővé teszi a tárolóalapú számítási feladatok hitelesítését. Ez a megközelítés lehetővé teszi, hogy az alkalmazások titkos kulcscsere nélkül férhessenek hozzá a felhőbeli erőforrásokhoz az alkalmazáskódon belül.

Metaadatok & költségkezelés

A költség egy másik probléma, amely a platformmérnöki munka csúcsára kerülhet. Az alkalmazásplatform megfelelő kezeléséhez módot kell adnia a számítási feladatok tulajdonosainak azonosítására. Szeretné lekérni a tulajdonosoknak leképzett erőforrások leltárát egy adott metaadatkészlethez. Az Azure-ban például használhatja az AKS-címkéket, az Azure Resource Manager címkéket, valamint az olyan fogalmakat, mint az Azure Deployment Environments projektjei, hogy különböző szinteken csoportosítsa az erőforrásokat. Ahhoz, hogy ez működjön, a választott metaadatoknak kötelező tulajdonságokat (például Azure Policy) kell tartalmazniuk a számítási feladatok és erőforrások üzembe helyezésekor. Ez segít a költségfelosztásban, a megoldáserőforrás-leképezésben, a tulajdonosokban stb. Érdemes lehet rendszeres jelentéskészítést futtatni az árva erőforrások nyomon követéséhez.

Előfordulhat, hogy a nyomon követésen túl az egyes alkalmazáscsoportoknak is hozzá kell rendelnie a költségeket az erőforrás-használatukhoz ugyanazokkal a metaadatokkal, mint például a Microsoft Cost Management. Bár ez a módszer nyomon követi az alkalmazáscsapatok által kiosztott erőforrásokat, nem fedezi a megosztott erőforrások költségeit, például az identitásszolgáltatót, a naplózást & metrikatárolót és a hálózati sávszélesség-használatot. Megosztott erőforrások esetén az üzemeltetési költségeket egyenlően oszthatja el az egyes csapatok között, vagy dedikált rendszereket (például naplózási tárterületet) biztosíthat, ahol nincs egységes használat. Egyes megosztott erőforrástípusok képesek lehetnek betekintést nyújtani az erőforrás-használatba, például a Kubernetes olyan eszközökkel rendelkezik, mint az OpenCost vagy a Kubecost, és segíthetnek.

A költségelemzési eszközöket is érdemes keresnie, ahol áttekintheti az aktuális kiadásokat. A Azure Portal például költségriasztások és költségvetés-riasztások találhatók, amelyek nyomon követhetik egy csoport erőforrásainak felhasználását, és értesítéseket küldhetnek az előre beállított küszöbértékek elérésekor.