Megosztás:

Független szoftverszállítói (ISV) szempontok az Azure-beli célzónákhoz

Számos szervezet számára az Azure-beli célzónák elméleti architektúrája jelenti a felhőbevezetési folyamat célját. A célzónák azt írják le, hogyan hozhat létre azure-környezetet több előfizetéssel. Minden kezdőzóna skálázási, biztonsági, irányítási, hálózatkezelési és identitáskezelési feladatokat biztosít, és számos ügyfél visszajelzésén és tanulságán alapul.

Jótanács

Hasznos lehet úgy gondolni az Azure-beli célzónákra, mint a városi tervekre. A kezdőzónában üzembe helyezett számítási feladatok architektúrája olyan, mint egy város épületeinek tervei.

A város víz-, gáz-, villamosenergia- és közlekedési rendszereinek mind a helyükön kell lenniük, mielőtt épületeket építenek. Hasonlóképpen, az Azure-beli célzóna összetevőinek, beleértve a felügyeleti csoportokat, szabályzatokat, előfizetéseket és szerepköralapú hozzáférés-vezérlést (RBAC) is, mindnek a helyén kell lennie, mielőtt bármilyen éles számítási feladat üzembe helyezhető lenne.

Független szoftverszállítóként (ISV) a megoldás azure-beli létrehozásakor és üzemeltetése során a következő erőforrásokra kell hivatkoznia:

Az Azure-beli célzónák segítenek az általános Azure-környezet irányának kiválasztásában. Az ISV, SaaS-szolgáltató vagy startup esetében azonban a konkrét megvalósítási igények eltérhetnek a szokásos ügyfélforgatókönyvektől. Az alábbiakban csak néhány különböző megvalósítási forgatókönyvet mutatunk be:

  • Olyan szoftvereket hozhat létre, amelyeket az ügyfelek a saját előfizetéseikbe helyeznek üzembe.
  • Saját vezérlősíkja van, és automatizálási szkripteket vagy szoftvereket használ az Azure-erőforrások SaaS-megoldásokhoz való üzembe helyezéséhez és konfigurálásához.
  • Ön egy kis isv- vagy startup, és a lehető legalacsonyabb költséggel szeretne kezdeni, és nem feltétlenül szeretne kezdetben olyan szolgáltatásokat használni, mint az Azure Firewall és az Azure DDoS Protection.
  • Ön egy nagy SaaS ISV, és azt tervezi, hogy felosztja az SaaS-alkalmazást több előfizetésre a skálázáshoz. Az előfizetéseket úgy is csoportosítani szeretné, hogy azok megfeleljenek a fejlesztési, tesztelési, előkészítési és éles környezeteknek.
  • A szervezet működési modellje elkülöníti a vállalati informatikai csapat és az SaaS-termékcsapatok szerepköreit. A szervezet vállalati informatikai csapata kezelheti az olyan erőforrásokat, mint a Microsoft Office 365 és a Microsoft Teams, és az SaaS-termékcsapat feladata lehet az SaaS-termék létrehozása és üzemeltetése (beleértve annak központi platformját és identitásösszetevőit).

Megjegyzés:

Az ISV-k néha csak egyetlen Azure-előfizetéssel szeretnének kezdeni, amely magában foglalja a platform "megosztott szolgáltatások" szempontjait és a tényleges számítási feladatok erőforrásait is. Bár ez technikailag lehetséges, később nehézségekbe ütközik, amikor erőforrásokat kell áthelyeznie az előfizetések között, és azt tapasztalja, hogy nem minden erőforrástípus helyezhető át. Tekintse át a tervezési eltérések hatását , hogy megértse, milyen eltérések lehetségesek és milyen kockázati szinteket jelentenek.

ISV üzembehelyezési modellek

Az ISV-megoldások gyakran három üzemi modell egyikébe illeszkednek: tiszta SaaS, ügyfél által üzembe helyezett vagy kettős üzembe helyezésű SaaS. Ez a szakasz az egyes modellek azure-beli kezdőzónákkal kapcsolatos különböző szempontjait ismerteti.

Tiszta SaaS

A tiszta SaaS-modellben a szoftver teljes mértékben csak az Azure-előfizetésekben lesz üzembe helyezve. A végfelhasználók a saját Azure-előfizetéseikben való üzembe helyezés nélkül használják a szoftvert. Az alábbi ábrán a felhasználók egy isV által biztosított tiszta SaaS-alkalmazást használnak:

Egy tiszta SaaS-üzemi modellt bemutató ábra. A felhasználó közvetlenül az I S V Azure-előfizetésében üzembe helyezett alkalmazást használja.

A tiszta SaaS-szoftverek közé tartozik például a szolgáltatásként nyújtott e-mail, a Kafka szolgáltatásként, a felhőbeli adattárház szolgáltatásként, valamint számos SaaS-lista az Azure Marketplace-en.

Ha Ön egy kis SaaS ISV,előfordulhat, hogy nem kell több Azure-előfizetést használnia az erőforrások azonnal üzembe helyezéséhez. A méretezéskor azonban az Azure előfizetési korlátai hatással lehetnek arra, hogy egy előfizetésen belül skálázhat. Tekintse át a nagyvállalati szintű célzóna tervezési alapelveit, különösen az előfizetések demokratizálását, és ismerkedjen meg a több-bérlős tervezés architekturális megközelítéseivel a jövőbeli növekedés megtervezése érdekében.

A tiszta SaaS-megoldásokat építő független szoftvergyártóknak a következő kérdéseket kell figyelembe venniük:

  • Az SaaS-megoldást alkotó összes Azure-erőforrásnak egy Azure-előfizetésben kell lennie, vagy több Azure-előfizetésben kell particionálnia?
  • Minden ügyfelet saját dedikált Azure-előfizetésben kell üzemeltetnünk, vagy létrehozhatunk erőforrásokat egy vagy néhány megosztott előfizetésen belül?
  • Hogyan alkalmazhatjuk az üzembehelyezési bélyeg (méretezési egység) mintáját a megoldás összes szintjére?
  • Hogyan használhatjuk az Azure-erőforrás-szervezetet több-bérlős megoldásokban , hogy ne szembesüljünk a skálázási kihívásokkal és az Azure-előfizetés korlátaival?

Ügyfél által üzembe helyezett

Az ügyfél által üzembe helyezett modellben a végfelhasználók megvásárolják Öntől a szoftvert, majd üzembe helyezik a saját Azure-előfizetéseikben. Kezdeményezhetik az üzembe helyezést az Azure Marketplace-ről, vagy manuálisan hajthatják végre az utasításokat követve és az Ön által megadott szkriptek használatával.

Az alábbi ábrán az ISV egy szoftvercsomagot vagy Azure Marketplace-katalógusterméket biztosít, és a felhasználók ezt az erőforrást a saját Azure-előfizetéseikben helyezik üzembe a többi számítási feladat mellett:

Egy ügyfél által üzembe helyezett üzembehelyezési modellt bemutató ábra. Az ügyfél üzembe helyezi az ISV által biztosított erőforrásokat a saját Azure-előfizetésében, és a felhasználók ezeket az erőforrásokat használják.

A diagram másik számítási feladateleme az ügyfél saját számítási feladatát vagy egy másik, az ügyfél által az Azure-előfizetésében üzembe helyezett ISV-terméket jelölheti. Az ügyfelek gyakran helyeznek üzembe több különböző ISV-ből származó terméket az Azure-előfizetéseikben. Ezeket az egyes termékeket kombinálják a megoldások létrehozásához. Előfordulhat például, hogy egy ügyfél egy adatbázisterméket helyez üzembe az egyik ISV-ből, egy másik isV-ből származó hálózati virtuális berendezést, egy harmadik ISV-ből származó webalkalmazást.

Az ügyfél által üzembe helyezett ISV-termékek közé tartoznak például az Azure Marketplace-en található számos virtuálisgép-rendszerkép (például hálózati és tárolási virtuális berendezések) és Azure-alkalmazások .

Egyes ügyfél által üzembe helyezett megoldások esetében a szervezet az Azure Lighthouse vagy az Azure Managed Applications használatával biztosíthatja a végfelhasználói Azure-előfizetésekben üzembe helyezett megoldás kezelését és frissítéseit. Az ISV-k, a megoldás-integrátorok (SI-k) és a felügyelt szolgáltatók (MSP-k) mind használhatják ezt a stratégiát, ha megfelelnek az igényeiknek.

Az ügyfél által üzembe helyezett ISV-megoldások az Azure-beli kezdőzónák szempontjából standard alkalmazásterhelésnek minősülnek. Vegye figyelembe az Azure-beli célzónák útmutatását , amikor úgy tervezi meg a terméket, hogy az Azure-ügyfelek által alkalmazott Azure-beli célzónák tervezési alapelveivel működjön együtt.

Különösen fontos, hogy a meglévő ügyfelek számítási feladatainak Azure-ba való migrálása során jól megértse az Azure célzóna-fogalmakat.

Az ügyfél által üzembe helyezett megoldásokat építő független szoftvergyártóknak az alábbi kérdéseket kell figyelembe venniük:

  • Üzembe kell helyeznie a megoldást a saját dedikált előfizetésében, vagy egy meglévő előfizetésben, amely kapcsolódó számítási feladatokat tartalmaz?
  • Hogyan hozhatják létre az ügyfelek a hálózati kapcsolatot a meglévő számítási feladatok (az Azure-on belül és kívül) és a megoldás között?
  • A megoldás támogatja a Microsoft Entra ID hitelesítési mechanizmusait, vagy más protokollokat, például LDAP-t vagy Kerberost igényel?
  • Hogyan csökkenthetők vagy kiküszöbölhetők az Azure Policy-szabálysértések, például a megoldássablonok és az ügyfél Azure-szabályzatai közötti ütközések?

Az Azure-szabályzatok megsértését okozó ügyfél-Azure-szabályzatok közé tartoznak például a "Minden alhálózatnak hálózati biztonsági csoporttal kell rendelkeznie", és "Nyilvános IP-címek nem csatolhatók a vállalati célzóna hálózati adaptereihez". Az üzembe helyezés megtervezése során tartsa szem előtt az ütközést okozó szabályzatok lehetőségeit.

Kettős üzembe helyezésű SaaS

Egyes SaaS-megoldások az ügyfelek Azure-előfizetéseiben üzembe helyezett erőforrásokat használják vagy használják. Ezt az üzembehelyezési modellt néha kettős üzembe helyezésű SaaS-nek vagy SaaShibridnek is nevezik. Az alábbi ábrán az ISV egy üzemeltetett SaaS-megoldást biztosít, amely a végfelhasználó Azure-előfizetésében üzembe helyezett erőforrásokat használja:

Kettős üzembe helyezésű SaaS-üzemi modellt bemutató ábra.

A kettős üzembe helyezésű SaaS valós példája a Microsoft Power BI, egy SaaS-szolgáltatás, amely opcionálisan használhat egy helyszíni Power BI-adatátjárót, amelyet egy ügyfél Azure-előfizetésében lévő virtuális gépen helyeznek üzembe.

A kettős üzembe helyezésű SaaS-forgatókönyvek további példái a következők:

  • A szervezet felépíti a Virtual Desktop Managert, amely egy SaaS-konzolfelületet biztosít az Azure Virtual Desktop-erőforrások vezérléséhez az egyes ügyfelek Azure-előfizetésében.
  • A szervezet egy SaaS-konzolt biztosít az adatelemzéshez, és dinamikusan létrehozza és törli a számítási csomópont virtuális gépeket az egyes ügyfelek Azure-előfizetésében.

Kettős üzembe helyezésű ISV-ként az Azure-beli célzónára kell hivatkoznia, amely két területen nyújt útmutatást: saját Azure-környezet strukturálása az SaaS-szolgáltatás üzemeltetéséhez, valamint a megfelelő interakció biztosítása az ügyfelek Azure-előfizetéseiben és az ügyfelek kezdőzónáiban található üzemelő példányok között.

A kettős üzembe helyezésű SaaS-megoldásokat építő független szoftvergyártóknak az alábbi kérdéseket kell figyelembe venniük:

  • Áttekintettük a tiszta SaaS-megoldások és az ügyfél által üzembe helyezett megoldások létrehozásának összes szempontjait?
  • A megoldás mely összetevőit kell üzemeltetni az Azure-előfizetéseinkben, és mely összetevőket kell üzembe helyezni az ügyfél számára?
  • Hogyan biztosíthatjuk az ügyfelek Azure-előfizetéseiben üzembe helyezett erőforrások biztonságos kiépítését és interakcióit?

Az Azure célzóna tervezési alapelvei és implementációi

Az Azure kezdőzónájának tervezési alapelvei azt javasolják, hogy igazodjanak az Azure natív platform képességeihez, például a Log Analyticshez, az Azure Monitorhoz és az Azure Firewallhoz. A célzóna útmutatása konkrét Azure-beli célzóna-megvalósítási lehetőségeket is biztosít.

ISV-ként dönthet úgy, hogy saját célzóna-környezeteket implementál. Előfordulhat, hogy az Azure-erőforrások előfizetések közötti üzembe helyezéséhez saját automatizálást kell használnia. Vagy érdemes lehet továbbra is használnia azokat az eszközöket, amelyeket már használ a naplózáshoz, a monitorozáshoz és más platformszintű szolgáltatásokhoz.

Ha saját célzóna-környezeteket implementál, javasoljuk, hogy referenciaként használja az Azure-beli célzóna-útmutatókat és minta implementációkat, és igazítsa a megközelítést a bevált Azure-beli célzóna-kialakításokhoz.

Microsoft Entra-bérlők

Minden Azure-kezdőzóna és felügyeleti hierarchiája egyetlen Microsoft Entra-bérlőben gyökerezik. Ez azt jelenti, hogy az első döntést meg kell hoznia, hogy melyik Microsoft Entra-bérlőt használja identitásforrásként az Azure-erőforrások kezeléséhez. A Microsoft Entra-azonosító identitásai közé tartoznak a felhasználók, a csoportok és a szolgáltatásnevek.

Jótanács

A kezdőzónához kiválasztott Microsoft Entra-tennant nem befolyásolja az alkalmazásszintű hitelesítést. Továbbra is használhat más identitásszolgáltatókat, például a Microsoft Entra külső azonosítóját, függetlenül attól, hogy melyik bérlőt választja.

Az Azure-beli kezdőzónákra és a Microsoft Entra-bérlőkre vonatkozó útmutató kifejezetten egyetlen Microsoft Entra-bérlő használatát javasolja, és a legtöbb esetben ez a helyes megközelítés. SaaS ISV-ként azonban okkal használhat két bérlőt.

Egyes SaaS ISV-k esetében egy csapat felügyeli a vállalati erőforrásokat, és egy külön csapat működteti az SaaS-megoldást. Ez a szétválasztás működési okokból vagy a jogszabályi követelményeknek való megfelelésből állhat. Előfordulhat, hogy a vállalati informatikai csapat nem kezelheti az SaaS-hez kapcsolódó előfizetéseket és erőforrásokat, így nem lehetnek a Microsoft Entra-bérlő rendszergazdái. Ha ez a forgatókönyv vonatkozik Önre, fontolja meg két különálló Microsoft Entra-bérlő használatát: egy bérlőt a vállalati informatikai erőforrásokhoz, például az Office 365-öt, és egy bérlőt az Azure-erőforrásokhoz, amelyek az SaaS-megoldást alkotják.

Minden Microsoft Entra-bérlőnek saját tartománynévvel kell rendelkeznie. Ha a szervezet két bérlőt használ, a következő ábrán látható módon választhatja ki a vállalati Microsoft Entra-bérlőhöz és contoso.com az SaaS Microsoft Entra-bérlőhöz hasonló contoso-saas-ops.com nevet.

Diagram, amely a Microsoft Entra-bérlői lehetőségeket mutatja be egyetlen vállalati bérlővel rendelkező ISV-khez, vagy a vállalati és az SaaS Ops-bérlők elkülönítését.

Figyelmeztetés

Ha több Microsoft Entra-bérlőt használ, a felügyeleti többletterhelés nő. Ha a Microsoft Entra ID P1 vagy P2 szolgáltatásait használja, mint például a Kiváltságos Identitás Kezelést, minden egyes Microsoft Entra tenanthez külön licenceket kell vásárolnia. A legjobb, ha csak több Microsoft Entra-bérlőt használ, ha a helyzet valóban megköveteli.

Ne használjon különálló Microsoft Entra bérlőket a tesztelési és éles környezetekhez. Az helyett, hogy olyan bérlőket hozna létre, mint a contoso-saas-ops-preprod.com és contoso-saas-ops-prod.com, amelyek különálló Azure-előfizetéssel rendelkeznek, létre kell hoznia egy Microsoft Entra-bérlőt. A felügyeleti csoportok és az Azure RBAC segítségével szabályozhatja az előfizetésekhez és erőforrásokhoz való hozzáférést ebben az egyetlen bérlőben.

További információ a több Microsoft Entra-bérlő használatáról: Azure-beli kezdőzónák és több Microsoft Entra-bérlő és erőforrás-elkülönítés több bérlővel.

Felügyeleti csoportok

Az Azure-beli kezdőzóna referenciaarchitektúrája egy adott felügyeleticsoport-hierarchia használatát javasolja. Az ISV-k azonban más követelményekkel rendelkezhetnek, mint más szervezetek. Ez a szakasz bemutatja, hogyan dönthet úgy az ISV-szervezet, hogy a célzóna fogalmi architektúrájához képest eltérő eljárásokat alkalmaz.

Felső szintű felügyeleti csoport

A felügyeleti csoport hierarchiája az Azure által létrehozott bérlői gyökércsoport felügyeleti csoport alá van ágyazva. Nem használja közvetlenül a bérlő gyökércsoportját .

A platformot és megosztott szolgáltatásokat (például naplózást, hálózatkezelést, identitást és biztonságot) kezelő központi vállalati informatikai csapattal rendelkező standard szervezet általában egy legfelső szintű felügyeleti csoportot hoz létre az Azure által létrehozott bérlői gyökércsoport alatt, és az alatta lévő többi felügyeleti csoportot telepíti. Ezt a legfelső szintű felügyeleti csoportot általában magáról a szervezetről (például a Contoso-ról) nevezik el.

SaaS ISV-ként előfordulhat, hogy egy SaaS-terméke van, vagy néhány különálló SaaS-terméke vagy üzletága van. Bár általában ugyanazt a Microsoft Entra-bérlőt kell használnia az Azure-erőforrások kezeléséhez az összes termékén (a Microsoft Entra-bérlők szakaszban leírtak szerint), bizonyos esetekben több felügyeleticsoport-hierarchiát is üzembe helyezhet.

Fontolja meg, hogy termékei mennyire függetlenek egymástól, és kérdezze meg magát:

  • Termékeink ugyanazokat a platformokat használják a DevOpshoz, az identitáshoz, a biztonsághoz, a kapcsolatokhoz és a naplózáshoz?
  • Ezeket a megosztott szolgáltatásokat egyetlen központi csapat üzemelteti?

Ha mindkét kérdésre igennel válaszolt, hozzon létre egy legfelső szintű SaaS-termékfelügyeleti csoportot a bérlő gyökércsoportja alatt.

Ha ehelyett nemmel válaszolt, és minden SaaS-termékét külön platformcsapatok felügyelik és üzemeltetik, érdemes lehet minden termékhez külön felső szintű felügyeleti csoportot létrehozni, például a két felső szintű felügyeleti csoportot, az SaaS Product-01-et és az SaaS Product-02-t.

Jótanács

Nem ritka, hogy egy független szoftverszállító több mint néhány legfelső szintű felügyeleti csoportokkal rendelkezik. Gyakran több termék kombinálható a kezelésük és üzemeltetésük hasonlósága miatt.

Ez a felügyeleti megközelítés hasonló a nagyvállalati szintű kezdőzónák tesztelési megközelítéséhez. A Contoso és a Contoso-Canarybérlői gyökércsoport alatti létrehozása helyett azonban ebben a megközelítésben a példavállalat inkább a termékspecifikus Contoso-SaaS-Product-01, Contoso-SaaS-Product-02 és Contoso-SaaS-Product-03 felső szintű felügyeleti csoportokat hozza létre. Ezt a forgatókönyvet az alábbi diagram szemlélteti:

Diagram, amely a felső szintű felügyeleti csoport beállításait mutatja be egyetlen felügyeleti csoporttal és az egyes SaaS-termékekhez tartozó különálló felügyeleti csoportokkal

Platformkezelési csoport

Az Azure-beli kezdőzóna erőforrás-szervezeti hierarchiájában a platformfelügyeleti csoport tartalmazza az összes Olyan Azure-előfizetést, amely a kezdőzóna-előfizetések számítási feladatai által használt összetevőket és megosztott szolgáltatásokat üzemelteti. A platformon és a megosztott szolgáltatások előfizetésében üzembe helyezett összetevők közé tartoznak például a központosított naplózási infrastruktúra (például Log Analytics-munkaterületek), a DevOps, a biztonság, az automatizálási eszközök, a központi hálózati erőforrások (például a központi virtuális hálózat és a DDos Protection-csomagok) és az ISV vezérlősík-szolgáltatásai.

A platformfelügyeleti csoportot gyakran particionálják identitás-, felügyeleti és kapcsolati gyermekcsoportokra, így kényelmesen elkülöníthetők a szerepkörök és szabályzatok a vállalati ügyfelek számára.

Előfordulhat, hogy a szervezetben egyetlen csapat felügyeli az összes megosztott platform-összetevőt, például az identitást, a hálózatkezelést és a felügyeletet. Ha igen, és nem tervezi, hogy több csapat között különítse el a felügyeletet, fontolja meg egyetlen platformfelügyeleti csoport használatát.

Ha ehelyett külön csapatokat fog használni, amelyek a központosított platform különböző részeit kezelik, akkor a platformfelügyeleti csoport alatt további szinteket kell üzembe helyeznie a felügyeleti csoport hierarchiájában. Ez lehetővé teszi, hogy külön szabályzatokat rendeljen a központosított platform minden részéhez.

Az alábbi ábra a platformkezelési csoport két lehetséges implementációját mutatja be. Az A lehetőség egy átfogóbb forgatókönyvet mutat be, amelyben a platformfelügyeleti csoport három gyermekfelügyeleti csoportot tartalmaz: Felügyelet és DevOps, Identitás és biztonság, valamint Kapcsolat. Minden gyermekfelügyeleti csoport tartalmaz egy előfizetést a megfelelő erőforrásokkal. A B lehetőség egy egyszerűbb forgatókönyvet jelenít meg, amelyben a platformfelügyeleti csoport egyetlen platform-előfizetést tartalmaz.

Megjegyzés:

Vegye figyelembe, hogy az Azure-beli célzónához nemrég hozzáadott biztonsági felügyeleti csoport jelenleg nem jelenik meg az alábbi ábrákon. Ajánlott azonban külön biztonsági felügyeleti csoportot felvenni az ISV-k platformfelügyeleti csoportjába, ugyanúgy, mint a Felügyeleti felügyeleti csoport.

A biztonsági felügyeleti csoport megjelenik a dokumentum későbbi frissítéseiben és a kapcsolódó diagramokban.

Két felügyeleti csoporthierarchiát bemutató diagram. Az

Kezdőzónák felügyeleti csoportja

A célzónák felügyeleti csoportja tartalmazza azOkat az Azure-előfizetéseket, amelyek az SaaS-megoldás tényleges alrendszereit és számítási feladatait üzemeltetik.

Ez a felügyeleti csoport egy vagy több gyermekfelügyeleti csoportot tartalmaz. A kezdőzónák alatti gyermekfelügyeleti csoportok mindegyike egy számítási feladatot vagy alrendszer archetípust jelöl, konzisztens szabályzattal és hozzáférési követelményekkel, amelyek az összes előfizetésre vonatkoznak. Több archetípus használatának okai a következők:

  • Engedékenység: Ha az SaaS-termék egy alrendszerének megfelelőnek kell lennie PCI-DSS, érdemes lehet létrehozni egy PCI DSS archetípusú gyermekfelügyeleti csoportot a kezdőzónák alatt. A PCI-DSS megfelelőség hatókörébe tartozó erőforrásokat tartalmazó Összes Azure-előfizetést ebben a felügyeleti csoportban kell elhelyezni.
  • Szintek: Fontolja meg külön kezdőzóna-archetípusok létrehozását a SaaS-szolgáltatás megoldásának dedikált rétegű ügyfelei és ingyenes rétegű ügyfelei számára. Minden gyermekfelügyeleti csoport különböző Azure Policy-beállításokat tartalmaz. Az ingyenes szinten lévő szabályzatok például korlátozhatják az üzemelő példányokat, hogy csak adott virtuálisgép-termékváltozatokat engedélyezzenek, a dedikált szinten lévő szabályzatok pedig erőforrásokat igényelhetnek adott régiókban való üzembe helyezéshez.

Környezetspecifikus felügyeleti csoportok

Az SaaS ISV-k gyakran rendszerezik a felhőkörnyezeteiket a szoftverfejlesztési életciklus-környezetek sorozatban történő modellezésével. Ehhez általában először egy fejlesztési , majd egy tesztkörnyezetbe , majd egy átmeneti környezetbe, végül pedig egy éles környezetbe kell üzembe helyezést végezni.

A környezetek közötti egyik gyakori különbség az Azure RBAC-szabályok, például az, hogy ki férhet hozzá az előfizetések egyes csoportjaihoz. Előfordulhat például, hogy a DevOps, az SaaSOps, a fejlesztési és a tesztelési csapatok különböző szintű hozzáféréssel rendelkeznek a különböző környezetekhez.

Fontos

A legtöbb Azure-ügyfél több száz alkalmazásból áll, és mindegyik alkalmazáscsoporthoz külön Azure-előfizetést használ. Ha minden alkalmazás saját fejlesztési, tesztelési, előkészítési és produkciós kezelési csoportokkal rendelkezne, nagy számú, közel azonos szabályzatokkal rendelkező kezelési csoportok lennének. A legtöbb ügyfél számára a Enterprise-Scale Landing Zone FAQ azt javasolja, hogy ne használjanak külön felügyeleti csoportokat minden környezethez. Javasoljuk, hogy ehelyett külön előfizetéseket használjon egyetlen felügyeleti csoportban.

Az SaaS ISV-k azonban eltérő követelményekkel rendelkezhetnek, mint a legtöbb Más Azure-ügyfél, és bizonyos helyzetekben érdemes lehet környezetspecifikus felügyeleti csoportokat használni.

Az SaaS ISV-knek néha több előfizetést kell csoportosítania, amelyek ugyanazon alrendszer, alkalmazás vagy számítási feladat szegmenseit vagy partícióit jelölik. Előfordulhat, hogy az előfizetések csoportjaira a szabályzatokat vagy szerepkör-hozzárendeléseket jelentősen eltérő módon kell alkalmaznia, mint az archetípus-felügyeleti csoportban. Ebben az esetben érdemes lehet olyan gyermekfelügyeleti csoportokat létrehozni, amelyek megfelelnek az archetípus-felügyeleti csoport minden környezetének.

Az alábbi ábrák két lehetséges lehetőséget szemléltetnek. Az "A" lehetőség egy olyan forgatókönyvet jelenít meg, amely minden környezethez külön előfizetést tartalmaz, de nincsenek környezetspecifikus felügyeleti csoportok. A B lehetőség egy SaaS ISV-forgatókönyvet jelenít meg, amely környezetspecifikus felügyeleti csoportokat tartalmaz a Normál bélyegek felügyeleti csoport alatt. Minden környezetspecifikus felügyeleti csoport több előfizetést tartalmaz. Az ISV idővel egyre több előfizetésre skálázza azure-erőforrásait az egyes környezetekben, közös szabályzatokkal és szerepkör-hozzárendelésekkel.

Jelölje ki az egyes lapokat a két diagram megtekintéséhez.

Leszerelt és sandbox-kezelési csoportok

Az Azure célzóna erőforrás-szervezési útmutatója azt javasolja, hogy a leszerelési és tesztkörnyezet-felügyeleti csoportokat közvetlenül a felső szintű felügyeleti csoport alatt is tartalmazza.

A leszerelt felügyeleti csoport olyan Azure-előfizetések tárolóhelye, amelyek le vannak tiltva, és végül törlődnek. A már nem használt előfizetéseket áthelyezheti ebbe a felügyeleti csoportba, hogy nyomon kövesse, amíg az előfizetés összes erőforrása véglegesen nem törlődik.

A Tesztkörnyezetek felügyeleti csoport általában olyan Azure-előfizetéseket tartalmaz, amelyeket feltárási célokra használnak , és amelyekre laza vagy nem alkalmazott szabályzatok vonatkoznak. Előfordulhat például, hogy az egyes fejlesztőknek saját előfizetést biztosít a fejlesztéshez és teszteléshez. Elkerülheti a normál szabályzatok és szabályozás alkalmazását ezekre az előfizetésekre, ha a Tesztkörnyezetek felügyeleti csoportjába helyezi őket. Ez növeli a fejlesztők rugalmasságát, és lehetővé teszi számukra, hogy egyszerűen kísérletezhessenek az Azure-ral.

Fontos

A Tesztkörnyezetek felügyeleti csoportjában lévő előfizetéseknek nem lehet közvetlen kapcsolatuk a kezdőzóna-előfizetésekkel. Kerülje a tesztkörnyezet-előfizetések éles számítási feladatokhoz vagy az éles környezeteket tükröző, nem éles környezetekhez való csatlakoztatását.

Az alábbi ábra két lehetséges lehetőséget mutat be. Az A lehetőség nem tartalmazza a leszerelt és a tesztkörnyezet felügyeleti csoportjait, míg a B lehetőséget.

A leszerelt és tesztkörnyezetek felügyeleti csoportjait a Platform és a Célzóna felügyeleti csoportokkal azonos szinten ábrázoló ábra.

Példa ISV-célzónákra

Ez a szakasz két Azure-beli landing zone-struktúrát tartalmaz egy SaaS ISV-hez. Jelölje ki az egyes lapokat a két példa kezdőzónájának összehasonlításához.

Az alábbi ábra egy saaS ISV Azure-beli célzóna-hierarchiát mutat be az alábbi jellemzőkkel:

Az ISV-hez tartozó Azure-beli kezdőzóna-hierarchiát bemutató ábra. A cikk legtöbb összetevőjét kihagyja a rendszer.

Következő lépések

  • Last updated on