Az Azure DevTest Labs-infrastruktúra szabályozása

Ez a cikk a szervezeten belüli DevTest Labs-erőforrások igazításával és kezelésével foglalkozik.

Források

DevTest Labs-erőforrások igazítása egy Azure-előfizetésen belül

Mielőtt egy szervezet elkezdené használni az Azure-t az általános alkalmazásfejlesztéshez, az informatikai tervezőknek először át kell tekinteniük, hogyan vezetik be a képességet a teljes szolgáltatási portfóliójuk részeként. A felülvizsgálatra váró területeknek a következő problémákkal kell foglalkozniuk:

• Hogyan mérhető az alkalmazásfejlesztési életciklushoz kapcsolódó költség?
• Hogyan igazítja a szervezet a javasolt szolgáltatásajánlatot a vállalati biztonsági szabályzathoz?
• Szükség van szegmentálásra a fejlesztési és éles környezetek elkülönítéséhez?
• Milyen vezérlőket vezetnek be a hosszú távú könnyű kezelés, a stabilitás és a növekedés érdekében?

Az első ajánlott eljárás a szervezetek Azure-osztályozásának áttekintése, ahol az éles és a fejlesztési előfizetések közötti megosztások körvonalazódnak. Az alábbi ábrán a javasolt osztályozás lehetővé teszi a fejlesztési/tesztelési és éles környezetek logikai elkülönítését. Ezzel a megközelítéssel a szervezetek számlázási kódokat vezethetnek be az egyes környezetekhez kapcsolódó költségek külön-külön történő nyomon követéséhez. További információ: Előíró előfizetés-szabályozás. Emellett Azure-címkék használatával is rendszerezheti az erőforrásokat nyomon követés és számlázás céljából.

A második ajánlott eljárás a DevTest-előfizetés engedélyezése az Azure Enterprise Portalon. Lehetővé teszi a szervezet számára, hogy olyan ügyfél operációs rendszereket futtasson, amelyek általában nem érhetők el egy Azure nagyvállalati előfizetésben. Ezután olyan vállalati szoftvereket használjon, ahol csak a számításért kell fizetnie, és ne aggódjon a licencelés miatt. Biztosítja, hogy a kijelölt szolgáltatások, köztük az IaaS katalógusképei, például a Microsoft SQL Server számlázása csak a használaton alapul. Az Azure DevTest-előfizetéssel kapcsolatos részletek itt találhatók Nagyvállalati Szerződés (EA) ügyfelek számára, és itt a használatalapú fizetéses ügyfelek számára.

Ez a modell rugalmasságot biztosít a szervezet számára az Azure DevTest Labs nagy léptékű üzembe helyezéséhez. A szervezetek több száz tesztkörnyezetet támogathatnak különböző üzleti egységekhez 100–1000 párhuzamosan futó virtuális géppel. Elősegíti a központi vállalati tesztkörnyezeti megoldás fogalmát, amely a konfigurációkezelés és a biztonsági vezérlők ugyanazon alapelveivel rendelkezik.

Ez a modell azt is biztosítja, hogy a szervezet ne merítse ki az Azure-előfizetéséhez társított erőforráskorlátokat. Az előfizetéssel és a szolgáltatáskorlátokkal kapcsolatos részletekért tekintse meg az Azure előfizetési és szolgáltatási korlátait, kvótáit és korlátozásait. A DevTest Labs kiépítési folyamata nagy számú erőforráscsoportot képes felhasználni. Az Azure DevTest-előfizetésben egy támogatási kéréssel kérheti a korlátok növelését. Az éles előfizetésen belüli erőforrásokat nem érinti a fejlesztési előfizetés használatban való növekedése. A DevTest Labs skálázásával kapcsolatos további információkért lásd : Kvóták és korlátok méretezése a DevTest Labsban.

A hálózati IP-címtartomány-hozzárendelések leosztása az éles és a fejlesztési előfizetések támogatására szolgáló általános előfizetési szintű korlát. Ezeknek a hozzárendeléseknek figyelembe kell venniük az időbeli növekedést (feltételezve, hogy a helyszíni kapcsolat vagy egy másik hálózati topológia megköveteli, hogy a vállalat kezelje a hálózati vermet az Azure implementációjának alapértelmezett beállítása helyett). Az ajánlott eljárás az, hogy néhány virtuális hálózathoz nagy IP-címelőtag van hozzárendelve, és sok nagy alhálózattal van elosztva, nem pedig több kis alhálózattal rendelkező virtuális hálózattal. 10 előfizetéssel például 10 virtuális hálózatot definiálhat (előfizetésenként egyet). Minden olyan tesztkörnyezet, amely nem igényel elkülönítést, ugyanazt az alhálózatot használhatja az előfizetés virtuális hálózatán.

Felhasználók száma laboronként és tesztkörnyezetenként szervezetenként

Az ugyanahhoz a fejlesztési projekthez társított üzleti egységeket és fejlesztési csoportokat ugyanahhoz a laborhoz kell társítani. Lehetővé teszi, hogy mindkét csoportra azonos típusú szabályzatok, rendszerképek és leállítási szabályzatok legyenek alkalmazva.

Előfordulhat, hogy figyelembe kell vennie a földrajzi határokat is. Az észak-keleti Egyesült Államok (USA) fejlesztői például használhatnak egy, az USA 2. keleti régiójában kiépített labort. A Colorado állambeli Dallas, Texas és Denver fejlesztői pedig az USA déli középső régiójában lévő erőforrások használatára irányíthatók. Ha egy külső külső féllel közösen dolgoznak, akkor egy olyan laborhoz rendelhetők, amelyet nem használnak belső fejlesztők.

Egy tesztkörnyezetet is használhat egy adott projekthez az Azure DevOps-projekteken belül. Ezután egy megadott Microsoft Entra-csoporton keresztül alkalmazza a biztonságot, amely mindkét erőforráskészlethez hozzáférést biztosít. A tesztkörnyezethez rendelt virtuális hálózat egy másik határ lehet a felhasználók összevonásához.

Az erőforrások törlésének megakadályozása

Állítsa be az engedélyeket a tesztkörnyezet szintjén, hogy csak a jogosult felhasználók törölhessenek erőforrásokat, vagy módosíthassák a tesztkörnyezet szabályzatait. A fejlesztőknek a DevTest Labs Felhasználói csoportjában kell lenniük. Az érdeklődő fejlesztőnek vagy az infrastruktúra-érdeklődőnek a DevTest Labs tulajdonosának kell lennie. Javasoljuk, hogy csak két labortulajdonosa legyen. Ez a szabályzat a kódtárra terjed ki a sérülés elkerülése érdekében. A tesztkörnyezet erőforrások használatára vonatkozó jogosultságokkal rendelkezik, de nem tudja frissíteni a laborszabályzatokat. Tekintse meg a következő cikket, amely felsorolja azokat a szerepköröket és jogosultságokat, amelyekkel minden beépített csoport rendelkezik egy tesztkörnyezetben: Tulajdonosok és felhasználók hozzáadása az Azure DevTest Labsban.

Költség és tulajdonjog kezelése

A költségek és a tulajdonjog elsődleges szempont a fejlesztési és tesztelési környezetek létrehozásakor. Ebben a szakaszban olyan információkat talál, amelyek segítenek optimalizálni a költségeket, és a tulajdonjogot a környezethez igazítani.

Költségoptimalizálás

A DevTest Labs számos beépített funkciója segít a költségek optimalizálásában. A felhasználók tevékenységeinek korlátozásához tekintse meg a költségkezelést, a küszöbértékeket és a szabályzatokat ismertető cikkeket.

Ha a DevTest Labst használja a fejlesztési és tesztelési számítási feladatokhoz, fontolja meg a Nagyvállalati Szerződés részét képező Nagyvállalati fejlesztési/tesztelési előfizetési juttatás használatát. Vagy ha Ön használatalapú fizetéses ügyfél, fontolja meg a használatalapú DevTest-ajánlatot.

Ez a megközelítés számos előnnyel jár:

• Speciális alacsonyabb dev/test arány Windows rendszerű virtuális gépeken, felhőszolgáltatásokon, HDInsighton, App Service-en és Logic Appsen
• Nagy Nagyvállalati Szerződés (EA) díjak más Azure-szolgáltatások esetében
• Hozzáférés a katalógus exkluzív fejlesztési/tesztelési lemezképeihez, többek között a Windows 8.1- és Windows 10-lemezképekhez

Csak az aktív Visual Studio-előfizetők (standard előfizetések, éves felhő-előfizetések és havi felhő-előfizetések) használhatják a nagyvállalati dev/test előfizetésen belül futó Azure-erőforrásokat. A végfelhasználók azonban hozzáférhetnek az alkalmazáshoz visszajelzések küldéséhez vagy elfogadási teszteléshez. Az előfizetés erőforrásait csak alkalmazások fejlesztésére és tesztelésére használhatja. Nincs üzemidőre vonatkozó garancia.

Ha úgy dönt, hogy a DevTest-ajánlatot használja, használja ezt az előnyt kizárólag az alkalmazások fejlesztéséhez és teszteléséhez. Az előfizetésen belüli használat nem rendelkezik pénzügyileg támogatott SLA-val, kivéve az Azure DevOps és a HockeyApp használatát.

Szerepköralapú hozzáférés definiálása a szervezeten belül

A központi informatikai rendszernek csak a szükséges elemeket kell birtokolnia, és lehetővé kell tennie, hogy a projekt- és alkalmazáscsapatok rendelkezzenek a szükséges szintű vezérléssel. Ez általában azt jelenti, hogy a központi informatikai rendszer az előfizetés tulajdonosa, és kezeli az alapvető informatikai funkciókat, például a hálózati konfigurációkat. Az előfizetés tulajdonosi csoportjának kicsinek kell lennie. Ezek a tulajdonosok jelölhetnek más tulajdonosokat, ha szükség van rá, vagy előfizetési szintű szabályzatokat alkalmazhatnak, például "Nincs nyilvános IP-cím".

Előfordulhat, hogy a felhasználók egy részhalmaza hozzáférést igényel egy előfizetésen keresztül, például az 1. réteg vagy a 2. réteg támogatása. Ebben az esetben azt javasoljuk, hogy adja meg ezeknek a felhasználóknak a közreműködői hozzáférést, hogy kezelni tudják az erőforrásokat, de ne biztosítsanak felhasználói hozzáférést vagy módosítsa a szabályzatokat.

A DevTest Labs-erőforrástulajdonosoknak közel kell lenniük a projekthez vagy az alkalmazás csapatához. Ezek a tulajdonosok tisztában vannak a gép- és szoftverkövetelményekkel. A legtöbb szervezetben a DevTest Labs-erőforrás tulajdonosa a projekt vagy a fejlesztési vezető. Ez a tulajdonos kezelheti a tesztkörnyezet felhasználóit és szabályzatait, és kezelheti a DevTest Labs-környezet összes virtuális gépét.

Projekt- és alkalmazáscsapattagok hozzáadása a DevTest Labs Users szerepkörhöz. Ezek a felhasználók a tesztkörnyezeti és előfizetési szintű szabályzatoknak megfelelően hozhatnak létre virtuális gépeket. A felhasználók saját virtuális gépeket is kezelhetnek, de más felhasználókhoz tartozó virtuális gépeket nem.

További információ: Azure Enterprise scaffold – prescriptive subscription governance.

Vállalati szabályzat és megfelelőség

Ez a szakasz útmutatást nyújt az Azure DevTest Labs-infrastruktúra vállalati szabályzatának és megfelelőségének szabályozásához.

Nyilvános és privát összetevő-adattár

A nyilvános összetevő-adattár a leggyakrabban használt szoftvercsomagok kezdeti készletét biztosítja. Segít a gyors üzembe helyezésben anélkül, hogy időt kellene szánnia a gyakori fejlesztői eszközök és bővítmények reprodukálására. Dönthet úgy, hogy saját privát adattárat helyez üzembe. Egy nyilvános és egy privát adattárat párhuzamosan is használhat. Dönthet úgy is, hogy letiltja a nyilvános adattárat. A magánadattárak üzembe helyezésének feltételeit az alábbi kérdéseknek és szempontoknak kell figyelembe vennie:

• A szervezetnek követelménye, hogy a DevTest Labs-ajánlat részeként vállalati licenccel rendelkező szoftverrel rendelkezzen? Ha a válasz igen, akkor létre kell hozni egy privát adattárat.
• Fejleszt a szervezet olyan egyéni szoftvereket, amelyek egy adott műveletet biztosítanak, amely az általános kiépítési folyamat részeként szükséges? Ha a válasz igen, akkor egy privát adattárat kell üzembe helyezni.
• Ha a szervezet szabályozási szabályzata elkülönítést igényel, és a külső adattárak nincsenek a szervezet közvetlen konfigurációkezelése alatt, egy privát összetevő-adattárat kell üzembe helyezni. Ennek a folyamatnak a részeként a nyilvános adattár kezdeti példánya másolható és integrálható a privát adattárral. Ezután le lehet tiltani a nyilvános adattárat, hogy a szervezeten belül senki ne férhessen hozzá többé. Ez a megközelítés arra kényszeríti a szervezet összes felhasználóját, hogy csak egyetlen, a szervezet által jóváhagyott adattárral rendelkezzenek, és minimalizálják a konfiguráció eltérését.

Egy vagy több adattár

A szervezet általános irányítási és konfigurációkezelési stratégiájának részeként javasoljuk, hogy egy központosított adattárat használjon. Ha több adattárat használ, azok idővel nem felügyelt szoftverek silójává válhatnak. Egy központi adattárral több csapat is felhasználhatja az adattárból származó összetevőket a projektjeikhez. Kényszeríti a szabványosítást, a biztonságot, a könnyű kezelhetőséget, és kiküszöböli az erőfeszítések duplikálását. A központosítás részeként a következő intézkedések ajánlott eljárások a hosszú távú felügyelet és a fenntarthatóság érdekében:

• Az Azure-adattárak társítása ugyanazzal a Microsoft Entra-bérlővel, amelyet az Azure-előfizetés használ hitelesítéshez és engedélyezéshez.
• Hozzon létre egy minden DevTest Labs-fejlesztő nevű csoportot a Központilag felügyelt Microsoft Entra-azonosítóban. Minden fejlesztőt, aki hozzájárul az összetevők fejlesztéséhez, ebbe a csoportba kell helyezni.
• Ugyanaz a Microsoft Entra-csoport használható az Azure-adattárhoz és a laborhoz való hozzáférés biztosításához.
• Az Azure-adattárakban az elágaztatást vagy az elágaztatást kell használni egy fejlesztési adattárnak az elsődleges éles adattártól való elválasztásához. A tartalom csak a megfelelő kódvizsgálat után lesz hozzáadva a fő ághoz lekéréses kérelemmel. Miután a kód véleményezője jóváhagyta a módosítást, a főág karbantartásáért felelős vezető fejlesztő egyesíti a frissített kódot.

Vállalati biztonsági szabályzatok

A szervezetek a következő lépésekkel alkalmazhatnak vállalati biztonsági szabályzatokat:

• Átfogó biztonsági szabályzat kidolgozása és közzététele. A szabályzat ismerteti a szoftver- és felhőeszközökkel társított elfogadható használati szabályokat. Azt is meghatározza, hogy mi sérti egyértelműen a szabályzatot.
• Egyéni rendszerkép, egyéni összetevők és üzembe helyezési folyamat fejlesztése, amely lehetővé teszi az Active Directoryval definiált biztonsági területen belüli vezénylést. Ez a megközelítés kikényszeríti a vállalati határt, és beállítja a környezeti ellenőrzések közös készletét. Ezek a környezettel szembeni vezérlők, amelyeket a fejlesztők a teljes folyamat részeként megfontolhatnak, és biztonságos fejlesztési életciklust követnek. A cél az is, hogy olyan környezetet biztosítsunk, amely nem túlzottan korlátozó, amely akadályozhatja a fejlesztést, hanem ésszerű kontrollkészletet biztosít. A tesztkörnyezeti virtuális gépeket tartalmazó szervezeti egység (szervezeti egység) csoportszabályzatai az éles környezetben található összes csoportszabályzat részhalmaza lehetnek. Alternatív megoldásként egy másik készlet is lehet, amely megfelelően mérsékeli az azonosított kockázatokat.

Adatintegritás

A szervezet biztosíthatja az adatintegritást annak érdekében, hogy a fejlesztők ne távolíthassák el a kódot, és ne vezessenek be kártevőket vagy nem jóváhagyott szoftvereket. A külső tanácsadók, alvállalkozók vagy alkalmazottak által a DevTest Labsban való együttműködés érdekében több ellenőrzési réteg is rendelkezésre áll.

Ahogy korábban már említettük, az első lépésnek egy elfogadható használati szabályzatot kell összeállítania, és meg kell határoznia, amely egyértelműen felvázolja a szabályzat megsértésének következményeit.

A távelérés első vezérlőrétege egy távelérési szabályzat alkalmazása olyan VPN-kapcsolaton keresztül, amely nem kapcsolódik közvetlenül a laborhoz.

A vezérlők második rétege olyan csoportházirend-objektumok készletének alkalmazása, amelyek megakadályozzák a másolást és beillesztést a távoli asztalon. Egy hálózati szabályzat implementálható, amely nem engedélyezi a környezetből érkező kimenő szolgáltatásokat, például az FTP- és RDP-szolgáltatásokat a környezetből. A felhasználó által definiált útválasztás az Összes Azure-beli hálózati forgalmat vissza kényszerítheti a helyszínire, de az útválasztás nem tudta figyelembe venni az összes OLYAN URL-címet, amely lehetővé teheti az adatok feltöltését, kivéve, ha proxyn keresztül vezérelve van a tartalom és a munkamenetek vizsgálata. A Nyilvános IP-címek korlátozhatók a DevTest Labst támogató virtuális hálózaton belül, hogy ne engedélyezze a külső hálózati erőforrások áthidalását.

Végső soron ugyanazokat a korlátozásokat kell alkalmazni a szervezeten belül, amelyeknek figyelembe kell venniük a cserélhető adathordozók vagy külső URL-címek minden lehetséges módszerét, amelyek elfogadhatják a tartalom közzétételét. Biztonsági szabályzatok áttekintéséhez és implementálásához forduljon biztonsági szakemberéhez. További javaslatokért lásd: Microsoft Cyber Security.

Alkalmazások migrálása és integrációja

A fejlesztési/tesztkörnyezet létrehozása után a következő kérdésekre kell gondolnia:

• Hogyan használhatja a környezetet a projektcsapaton belül?
• Hogyan biztosíthatja, hogy betartsa a szükséges szervezeti szabályzatokat, és fenntartsa az agilitást az alkalmazás értékének hozzáadásához?

Azure Marketplace-rendszerképek és egyéni rendszerképek

Alapértelmezés szerint az Azure Marketplace-t kell használni, kivéve, ha konkrét aggályai vagy szervezeti követelményei vannak. Néhány gyakori példa:

• Összetett szoftverbeállítás, amely megköveteli, hogy egy alkalmazás szerepeljen az alaprendszerkép részeként.
• Egy alkalmazás telepítése és beállítása több órát is igénybe vehet, ami nem hatékony számítási idő az Azure Marketplace-rendszerképhez való hozzáadásához.
• A fejlesztőknek és tesztelőknek gyorsan hozzá kell férniük egy virtuális géphez, és minimalizálni szeretnék az új virtuális gépek beállítási idejét.
• Megfelelőségi vagy szabályozási feltételek (például biztonsági szabályzatok), amelyeknek minden gépen érvényben kell lenniük.

Fontolja meg az egyéni képek körültekintő használatát. Az egyéni rendszerképek további összetettséghez vezetnek, mivel mostantól vHD-fájlokat kell kezelnie az alapul szolgáló alaprendszerképekhez. Ezeket az alaprendszerképeket szoftverfrissítésekkel is rendszeresen javítania kell. Ezek a frissítések közé tartoznak az új operációsrendszer-frissítések, valamint a szoftvercsomaghoz szükséges frissítések vagy konfigurációs módosítások.

Képlet és egyéni kép

Ebben a forgatókönyvben általában a költség és az újrafelhasználás a döntő tényező.

A költségek csökkentése érdekében hozzon létre egy egyéni rendszerképet, ha:

• Sok felhasználónak vagy tesztkörnyezetnek szüksége van a rendszerképre.
• A szükséges rendszerképen sok szoftver található az alaprendszerkép tetején.

Ez a megoldás azt jelenti, hogy egyszer hozza létre a képet. Az egyéni rendszerképek csökkentik a virtuális gép beállítási idejét. A virtuális gép telepítés közbeni futtatása nem jár költségekkel.

Egy másik tényező a szoftvercsomag módosításainak gyakorisága. Ha napi buildeket futtat, és megköveteli, hogy a szoftver a felhasználók virtuális gépein legyen, fontolja meg egy képlet használatát egyéni rendszerkép helyett.

A hálózati konfiguráció beállításának mintái

Ha meggyőződik arról, hogy a virtuális gépek fejlesztése és tesztelése nem éri el a nyilvános internetet, két szempontot kell figyelembe venni: a bejövő és a kimenő forgalmat.

Bejövő forgalom – Ha a virtuális gép nem rendelkezik nyilvános IP-címmel, akkor az internet nem éri el. Gyakori módszer egy olyan előfizetési szintű szabályzat beállítása, amelyet egyetlen felhasználó sem hozhat létre nyilvános IP-címként.

Kimenő forgalom – Ha meg szeretné akadályozni, hogy a virtuális gépek közvetlenül a nyilvános internetre lépjenek, és vállalati tűzfalon keresztül kényszerítse a forgalmat, kényszerített útválasztással irányíthatja a forgalmat a helyszíni azure ExpressRoute-on vagy VPN-en keresztül.

Feljegyzés

Ha proxykiszolgálóval rendelkezik, amely proxybeállítások nélkül blokkolja a forgalmat, ne felejtsen el kivételeket hozzáadni a tesztkörnyezet összetevő-tárfiókjához.

A virtuális gépekhez vagy alhálózatokhoz hálózati biztonsági csoportokat is használhat. Ez a lépés egy újabb védelmi réteget ad hozzá a forgalom engedélyezéséhez vagy letiltásához.

Új és meglévő virtuális hálózat

Ha a virtuális gépeknek a meglévő infrastruktúrával kell kommunikálniuk, érdemes megfontolni egy meglévő virtuális hálózat használatát a DevTest Labs-környezetben. ExpressRoute használata esetén minimalizálja a virtuális hálózatok és alhálózatok számát, hogy ne törje szét az előfizetésekhez rendelt IP-címteret. Fontolja meg a virtuális hálózatok közötti társviszony-létesítési mintát is (küllős modell). Ez a megközelítés lehetővé teszi a virtuális hálózati és alhálózati kommunikációt egy adott régión belüli előfizetések között.

Minden DevTest Labs-környezet rendelkezhet saját virtuális hálózattal, de előfizetésenként korlátozott a virtuális hálózatok száma. Az alapértelmezett érték 50, de ez a korlát 100-ra emelhető.

Megosztott, nyilvános vagy privát IP-cím

Ha helyek közötti VPN-t vagy Express Route-t használ, fontolja meg magánhálózati IP-címek használatát, hogy a gépek a belső hálózaton keresztül elérhetők legyenek, és nyilvános interneten keresztül elérhetetlenek legyenek.

Feljegyzés

A labortulajdonosok módosíthatják ezt az alhálózati házirendet, hogy senki ne hozhasson létre véletlenül nyilvános IP-címeket a virtuális gépeikhez. Az előfizetés tulajdonosának létre kell hoznia egy előfizetési szabályzatot, amely megakadályozza a nyilvános IP-címek létrehozását.

Megosztott nyilvános IP-címek használata esetén a tesztkörnyezet virtuális gépei nyilvános IP-címmel osztoznak. Ez a megközelítés akkor lehet hasznos, ha el kell kerülnie az adott előfizetés nyilvános IP-címeinek korlátait.

Laborkorlátok

Számos tesztkörnyezeti korlátot figyelembe kell vennie. Ezeket a korlátokat a következő szakaszok ismertetik.

A tesztkörnyezetek korlátai előfizetésenként

Az előfizetésenként létrehozható tesztkörnyezetek számára nincs meghatározott korlát. Az előfizetésenként használt erőforrások mennyisége azonban korlátozott. Az Azure-előfizetések korlátairól és kvótáiról, valamint a korlátok növeléséről olvashat.

Virtuális gépek korlátai tesztkörnyezetenként

A tesztkörnyezetenként létrehozható virtuális gépek számának nincs konkrét korlátja. A használt erőforrások (virtuálisgép-magok, nyilvános IP-címek stb.) azonban előfizetésenként korlátozottak. Az Azure-előfizetések korlátairól és kvótáiról, valamint a korlátok növeléséről olvashat.

A virtuális gépek felhasználónkénti vagy laboronkénti számának korlátai

Ha figyelembe veszi a virtuális gépek felhasználónkénti vagy laboronkénti számát, három fő szempont áll fenn:

• Az a teljes költség , amelyet a csapat a labor erőforrásaira költhet. Könnyű sok gépet felpörgetni. A költségek szabályozásához az egyik mechanizmus a virtuális gépek felhasználónkénti vagy laboronkénti számának korlátozása
• A tesztkörnyezetben lévő virtuális gépek teljes számát az elérhető előfizetési szintű kvóták befolyásolják. Az egyik felső korlát előfizetésenként 800 erőforráscsoport. A DevTest Labs jelenleg minden virtuális géphez létrehoz egy új erőforráscsoportot (kivéve, ha megosztott nyilvános IP-címeket használ). Ha egy előfizetésben 10 tesztkörnyezet található, a tesztkörnyezetek körülbelül 79 virtuális gépet tudnak elférni minden laborban (800 felső korlát – 10 erőforráscsoport maguk a 10 tesztkörnyezet esetében) = 79 virtuális gép laboronként.
• Ha a tesztkörnyezet expressz útvonalon keresztül csatlakozik a helyszíni környezethez (például), a virtuális hálózat/alhálózat meghatározott IP-címterei érhetők el . Annak biztosítása érdekében, hogy a tesztkörnyezetben lévő virtuális gépek ne legyenek létrehozva (hiba: nem lehet IP-címet lekérni), a tesztkörnyezet tulajdonosai megadhatják az elérhető IP-címtérhez igazodó tesztkörnyezetenkénti maximális virtuális gépeket.

Resource Manager-sablonok használata

A Resource Manager-sablonok üzembe helyezése az Azure DevTest Labs tesztelési környezetekhez című témakör lépéseit követve. Alapvetően egy Azure-adattárban vagy GitHub Git-adattárban ellenőrizheti a Resource Manager-sablonokat, és hozzáadhat egy privát tárházat a sablonokhoz a laborhoz.

Ez a forgatókönyv nem feltétlenül hasznos, ha fejlesztői gépek üzemeltetésére használja a DevTest Labst. Ezzel a forgatókönyvvel olyan átmeneti környezetet hozhat létre, amely az éles környezetre jellemző.

A tesztkörnyezetenként vagy felhasználónkénti virtuális gépek száma csak a tesztkörnyezetben natívan létrehozott gépek számát korlátozza. Ez a beállítás nem korlátozza a Resource Manager-sablonokkal rendelkező környezetek létrehozását.