Alkalmazásfejlesztési környezetek kezelése az Azure-beli kezdőzónákban

Cikk
12/13/2023

Ez a cikk azt ismerteti, hogy a felhőplatform-csapatok hogyan implementálhatnak védőkorlátokat az azure-beli célzónák alkalmazáskörnyezeteinek kezeléséhez. Azt is ismerteti, hogyan igazíthatók a különböző alkalmazásfejlesztési környezetek a keretrendszerükhöz. A megfelelő környezet létrehozásához kulcsfontosságú szempont az előfizetések megfelelő felügyeleti csoportokba helyezése.

Az alap beállítása

A fejlesztői csapatoknak szükségük van a gyors iterálási képességre, a felhőszabályozási és platformcsapatoknak pedig nagy léptékben kell kezelni a szervezeti kockázatokat, a megfelelőséget és a biztonságot. Az alkalmazáskörnyezetek megfelelően kezelhetők úgy, hogy két kulcsfontosságú Azure-beli célzóna-tervezési alapelvre összpontosítanak: a szabályzatalapú szabályozásra és az előfizetések demokratizálására. Ezek az alapelvek alapvető védőkorlátokat biztosítanak, és ismertetik, hogyan delegálhat vezérlőket az alkalmazáscsapatoknak. Az alkalmazáscsapatok az Azure Well-Architected Framework útmutatóját használják a számítási feladatok megtervezéséhez. Üzembe helyezik és felügyelik a saját célzóna-erőforrásaikat, és a platformcsapat Azure-szabályzatok hozzárendelésével vezérli az erőforrásokat.

Fontos, hogy tesztkörnyezeti erőforrásokat biztosítson a félig szabályozott erőforrásokhoz, hogy az alkalmazáscsapatok kísérletezhessenek a technológiákkal és képességekkel.

Ha az alkalmazástulajdonosok előfizetéses értékesítés vagy más előfizetés-létrehozási folyamatokat használnak, tudniuk kell, hogyan kérhetnek előfizetéseket több fejlesztési környezethez.

Ez a cikk az Azure-beli célzónát ismerteti, beleértve a felügyeleti csoportokat, szabályzatokat és megosztott platformarchitektúrát, valamint a számítási feladatot vagy az alkalmazás célzónát.

Feljegyzés

A cikkben szereplő útmutatás csak a számítási feladatokra vagy az alkalmazás kezdőzónáira vonatkozik. Az Azure-beli célzónaplatform tesztelésével és a környezet elkülönítésével kapcsolatban lásd az Azure-beli célzónák tesztelési megközelítését, amely a kanári megközelítést ismerteti.

A gyakorlatban bármilyen számú és típusú fázisos környezetet használhat. Ez a cikk a következő szakaszos környezetekre hivatkozik.

Környezet	Leírás	Felügyeleti csoport
Homokozó	A prototípusok gyors innovációjára használt környezet, de nem az éles környezethez kötött konfigurációk	Tesztkörnyezet felügyeleti csoport
Fejlesztés	A potenciális kiadási jelöltek létrehozásához használt környezet	Archetípus-felügyeleti csoport, például corp vagy online
Tesztelés	A teszteléshez használt környezet, beleértve az egységtesztelést, a felhasználói elfogadási tesztelést és a minőségbiztosítási tesztelést	Archetípus-felügyeleti csoport, például corp vagy online
Éles	Az a környezet, amely az ügyfeleknek történő értékszállításhoz használatos	Archetípus-felügyeleti csoport, például corp vagy online

További információkért tekintse meg az alkalmazás-számítási feladatok fejlesztési, tesztelési és éles környezeteinek kezelésével és az Azure-beli előfizetések számával foglalkozó videókat?

Környezetek, előfizetések és felügyeleti csoportok

Ennek a szakasznak az előfeltételeként tekintse meg az erőforrás-szervezet tervezési területét.

Az Azure-beli kezdőzóna-eljárások bevezetésekor megfelelően kell rendszereznie az előfizetéseket. Ideális esetben minden alkalmazáskörnyezetnek saját előfizetéssel kell rendelkeznie. Ez a módszer olyan biztonsági és szabályzatvezérlőket biztosít, amelyek elkülönítik a környezeteket. Lehetséges problémákat tartalmaz egy környezetben.

A különálló előfizetések az archetípus szintjén azonos szabályzatokkal rendelkeznek. Szükség esetén az alkalmazástulajdonosok előfizetés-specifikus szabályzatokat rendelhetnek hozzá az alkalmazás- és környezetspecifikus viselkedés kényszerítéséhez.

Egyes alkalmazásarchitektúrák megkövetelik, hogy a szolgáltatások meg legyenek osztva a környezetek között. Ha ez a helyzet, több környezethez is használhat egyetlen előfizetést. Javasoljuk, hogy a számítási feladatok tulajdonosai a felhőplatform-csapatokkal együttműködve határozzák meg, hogy szükség van-e egyetlen előfizetésre több környezethez.

Használjon egyetlen előfizetést több alkalmazáskörnyezethez, ha:

A környezetek nem különíthetők el a saját előfizetéseikben.
A környezetekben ugyanazok a csapatok vannak hozzárendelve funkcionális szerepkörökhöz, például hálózati operátorokhoz.
A környezetek ugyanazokat a szabályzatokat használhatják.

Ha egy alkalmazás vagy szolgáltatás számítási feladatának egyetlen előfizetésben kell lennie, és módosítania kell az egyes környezetekre vonatkozó szabályzatokat, a következőket teheti:

Hozzon létre egy új archetípushoz igazított felügyeleti csoportot a kezdőzónák felügyeleti csoportja alatt. További információ: A felügyeleti csoport hierarchiája ebben a cikkben.
Fejlesztési tevékenységekhez használjon tesztkörnyezet-előfizetéseket. A tesztkörnyezetek kevésbé korlátozó házirendkészlettel rendelkeznek.
A felügyeleti csoport szintjén helyett az előfizetés szintjén alkalmazott szabályzatokat használhatja. A szabályzatdefiníciókban címkéket adhat hozzá, amelyek segítenek a szabályzatok szűrésében és a megfelelő környezetben való alkalmazásában. A szabályzatokat hozzárendelheti vagy kizárhatja adott erőforráscsoportokból.

Az előfizetés-létrehozási folyamat során szabályzatokat rendelhet hozzá a előfizetéses értékesítés részeként.

A költségek szabályozásához implementálandó szabályzatok esetében szükség esetén alkalmazza a szabályzatdefiníciót előfizetési szinten. Vagy a célzóna tulajdonosát is felelőssé teheti a költségekért, ami valódi autonómiát biztosít. További információ: Platformautomatizálás és DevOps.

Figyelmeztetés

A felügyeleti csoport szintjén a szabályzatokkal és vezérlőkkel ellentétben az előfizetés-alapú szabályzatokat és címkéket az előfizetéshez emelt szintű engedélyekkel rendelkező személyek módosíthatják. Rendszergazda megfelelő szerepkörrel rendelkező felhasználók megkerülhetik ezeket a vezérlőket a szabályzatok kizárásával, a szabályzatok módosításával vagy az erőforrások címkéinek módosításával.

Ennek eredményeképpen nem szabad címkéket alkalmazni a biztonságközpontú szabályzatok definícióiban. Emellett az alábbi műveletekhez ne rendeljen hozzá mindig aktív engedélyeket:

Microsoft.Authorization/policyAssignments/*
Microsoft.Authorization/policyDefinitions/*
Microsoft.Authorization/policyExemptions/*
Microsoft.Authorization/policySetDefinitions/*

Ezeket a műveleteket a Privileged Identity Management (PIM) használatával szabályozhatja.

Felügyeleti csoport hierarchiája

Kerülje a bonyolult felügyeleti csoportok hierarchiáját. Gyakori módosítást, nem hatékony skálázást és értékhiányt igényelhetnek. A lehetséges problémák elkerülése érdekében az Azure-beli célzóna-felügyeleti csoportok a számítási feladatok archetípus-igazítását képezik. További információ: Felügyeleti csoport és előfizetés-szervezet.

Az archetípus-igazítás azt jelenti, hogy a felügyeleti csoportok csak meghatározott számítási feladatok archetípusaihoz jönnek létre. A fogalmi architektúrában például a kezdőzónák felügyeleti csoportja corp és online gyermekfelügyeleti csoportokkal rendelkezik. Ezek a gyermekfelügyeleti csoportok összhangban vannak az általuk használt számítási feladatok különböző archetípus-mintáival. A gyermekfelügyeleti csoportok a hibrid kapcsolatra (VPN/Azure ExpressRoute) vonatkozó követelményekre összpontosítanak, például csak belső és nyilvános elérésű alkalmazásokra és szolgáltatásokra.

A tesztkörnyezetek kivételével a különböző alkalmazáskörnyezeteknek ugyanazt az archetípust kell használniuk az üzembe helyezéshez. Még akkor is, ha a környezetek több előfizetésre vannak osztva, a felügyeleti csoport archetípusa és a követelmények alapján ugyanabban a felügyeleti csoportban (corp vagy online) vannak tárolva.

A tesztkörnyezet-előfizetéseket strukturálatlan fejlesztéshez, például személyes tesztkörnyezetekhez vagy olyan számítási feladatokhoz használhatja, amelyek nem rendelkeznek archetípussal. Egy alkalmazás- vagy szolgáltatásprofil-csapat tesztkörnyezet-felügyeleti csoportot használ a különböző Azure-szolgáltatások teszteléséhez, hogy megállapítsa, mi felel meg a legjobban a követelményeknek. A szolgáltatások kiválasztása után kiépíthetik a kezdőzónát (a kezdőzónák felügyeleti csoport hierarchiájában a megfelelő számítási feladatok archetípushoz igazított felügyeleti csoportjában) a csapat számára.

A tesztkörnyezetek adott alkalmazásokhoz használhatók, vagy a számítási feladatok csapata használhatja őket kísérletezéshez.

További információkért lásd:

Környezetalapú felügyeleti csoportokkal kapcsolatos kihívások

Az archetípusokon belüli környezetek felügyeleti csoportjai felügyeleti többletterhelést adhatnak hozzá, és minimális értéket biztosíthatnak.

A kezdőzónák felügyeleti csoportjának olyan univerzális szabályzatokkal kell rendelkeznie, amelyek mind a corp, mind az online gyermekfelügyeleti csoportok számára kényszerítik a védőkorlátokat. A corp és az online olyan egyedi szabályzatokkal rendelkezik, amelyek a nyilvános és magánjellegű számítási feladatokhoz kapcsolódó vállalati irányelveket kényszerítik ki.

Számos szervezet külön felügyeleti csoportokat hoz létre a számítási feladatok szoftverfejlesztési életciklusának (SDLC) környezeteihez a környezeti szabályzatok és vezérlők hozzárendeléséhez. A gyakorlatban ez a módszer több kihívást jelent a számítási feladatokat végző csapatok számára, mint amennyit megold. Az SDLC-környezeteknek nem szabad eltérő szabályzatokkal rendelkezniük, ezért nem javasoljuk külön felügyeleti csoportok használatát.

Az alkalmazástulajdonosok módosíthatják a számítási feladatok topológiáját vagy erőforrás-konfigurációját, hogy igazodjanak az előléptetett több SDLC-környezet szabályzataihoz. Ez a módszer növeli a kockázatot. Az egyes környezetekre jellemző szabályok rossz fejlesztési élményt eredményezhetnek a fejlesztői és minőségbiztosítási csapatok számára. Problémák akkor is felmerülhetnek, ha egy alkalmazás egy környezetben működő védőkorlát-szabályzatokkal rendelkezik, és az alkalmazás az előléptetési ciklus későbbi szakaszában egy másik szabályzatkészletnek lesz kitéve. Előfordulhat, hogy módosítania kell egy alkalmazást, ha a vezérlők megváltoznak.

A további munka elkerülése érdekében hozzon létre egységes szabályzatokat a kód előléptetése során SDLC-környezetekben. Ne hozzon létre házirendeket az egyes környezetekhez, hanem konzisztens készletet biztosítson az összes fejlesztési környezethez, kivéve a tesztkörnyezeteket.

Tegyük fel például, hogy egy szervezet olyan szabályzatot határoz meg, amely megköveteli, hogy a tárfiókok meghatározott tűzfalszabályokkal legyenek konfigurálva, hogy megakadályozzák a nyilvános hálózatokból érkező bejövő forgalmat. Ehelyett a tárfiókok privát végpontokat használnak az Azure-beli célzóna-hálózatokon belül a kommunikációhoz. Ha a fejlesztői környezet nem rendelkezik ilyen szabályzattal, a számítási feladat tesztelése nem találja a nyilvános hozzáférést lehetővé tevő tárfiók helytelen konfigurációját. A teszttelepítések a fejlesztési környezetben működnek, és a rendszer tovább van kapcsolva. Ha a megoldás előléptethető egy másik olyan környezetbe, amely rendelkezik a tárfiók-szabályzattal, az üzembe helyezés a kényszerített szabályzat miatt meghiúsul.

Ennek eredményeképpen az alkalmazásfejlesztési csapatnak át kell végeznie az üzembe helyezést és az architektúrát, miután már jelentős erőfeszítéseket tett. Ez a példa bemutatja, hogy a különböző környezetekben lévő különböző szabályzatok hogyan okozhatnak problémákat.

Feljegyzés

Az alábbi egyenlet bemutatja, hogy miért nem skálázható jól egy külön felügyeleti csoport az egyes környezetekhez vagy számítási feladatokhoz: N számítási feladatok x Z felügyeleti csoportok = összes felügyeleti csoport.

Ha egy szervezet 30 olyan számítási feladattal rendelkezik, amelyekhez egy felügyeleti csoportra és egy gyermekfelügyeleti csoportra van szükség a fejlesztési, tesztelési és éles környezetekhez, a szervezet a következőkkel marad:

N = a számítási feladatok/alkalmazások száma = 30

Z = a számítási feladatok és környezetek felügyeleti csoportjainak száma (1 a számítási feladathoz + 3 a környezetekhez) = 4

N (30) x Z (4) = 120 teljes felügyeleti csoport

Előfordulhat, hogy az alkalmazástulajdonosoknak másként kell alkalmazniuk a szabályzatokat több környezetre. Előfordulhat például, hogy az alkalmazástulajdonosok biztonsági mentési konfigurációkat igényelnek az éles környezetekhez, más környezetekhez azonban nem.

Egyes szabályzatok naplózási szabályzatként engedélyezhetők a felügyeleti csoport szintjén. Az alkalmazáscsapatok határozzák meg a vezérlő implementálását. Ez a módszer nem akadályozza meg az üzembe helyezéseket, de tudatosságot teremt, és lehetővé teszi az alkalmazáscsapatok számára egyedi igényeik kezelését. Ezután létrehozhatnak alszintű szabályzatokat, vagy beépíthetik ezeket a követelményeket az infrastruktúrájukba kód(IaC) üzembehelyezési modulokként.

Ebben a megosztott felelősségi modellben a platformcsapat ellenőrzi a gyakorlatokat, és az alkalmazás csapata kezeli a megvalósítást. Ez a modell javíthatja az üzemelő példányok rugalmasságát.

A platformüzemeltetőknek minden alkalmazás- vagy szolgáltatásterhelési csapattal (kezdőzóna-tulajdonosokkal) együtt kell működniük a követelmények megértéséhez. A platformüzemeltetők az alkalmazáskövetelmények és csomagok alapján biztosíthatnak előfizetéseket. A platformüzemeltetők dönthetnek úgy is, hogy terméksorokat jelölnek ki a különböző típusú számítási feladatokhoz, hogy előfizetés-létrehozási folyamatokat és eszközöket építhessenek ki az alkalmazás- vagy szolgáltatásterhelési csapatok általános követelményei alapján.

Forgatókönyv: Virtuálisgép-alapú számítási feladatok

Az Azure-beli kezdőzónák korai számítási feladatai gyakran Azure-beli virtuális gépekből állnak. Ezeket a számítási feladatokat üzembe helyezheti az Azure-ban, vagy migrálhatja őket meglévő adatközpontokból.

Ahelyett, hogy virtuális gépeket helyez üzembe több környezetben egyetlen előfizetésben, a következőket teheti:

Hozzon létre előfizetéseket az egyes alkalmazáskörnyezetekhez, és helyezze őket ugyanabban az archetípus-felügyeleti csoportban.
Helyezzen üzembe egy virtuális hálózatot minden alkalmazáskörnyezethez a megfelelő előfizetésben. A virtuális hálózat méretét az alkalmazáskörnyezet mérete alapján határozhatja meg.
Helyezze üzembe a virtuális gépeket a megfelelő előfizetésben. A virtuális gépek különböző termékváltozatokat és különböző rendelkezésre állási konfigurációkat használhatnak az egyes környezetekhez, ha szükséges.

A különböző alkalmazáskörnyezeti erőforrásokat különböző hozzáférési vezérlők védik. Ennek eredményeképpen, amikor az alkalmazásfejlesztők üzembehelyezési folyamatokat állítanak be, az egyes folyamatok identitása a környezetre korlátozható. Ez a konfiguráció segít megvédeni a környezeteket a véletlen üzemelő példányoktól.

Forgatókönyv: Azure-alkalmazás szolgáltatás

Az App Service-t használó környezeti előfizetésekkel rendelkező számítási feladatok kihívást jelenthetnek. Az alkalmazásfejlesztők számára az App Service ajánlott eljárása az üzembehelyezési pontok használata a webalkalmazások módosításainak és frissítéseinek kezeléséhez.

Ez a funkció azonban csak az App Service-csomagban lévő alkalmazással használható, amely csak egyetlen előfizetésen belül tud élni. Ha a platformüzemeltetők azt kérik, hogy az alkalmazástulajdonosok külön előfizetéseket használjanak fejlesztési, tesztelési és éles környezetekhez, az alkalmazás üzembe helyezési életciklusa nehezebb lehet.

Ebben a példában a legjobb megoldás egyetlen előfizetés az alkalmazás- vagy szolgáltatásterheléshez. Az alkalmazástulajdonosok az azure-beli szerepköralapú hozzáférés-vezérlést (RBAC) az erőforráscsoport szintjén használhatják a PIM használatával a nagyobb biztonság érdekében.

Megosztás a következőn keresztül: