Uw Azure DevTest Labs-infrastructuur omhoog schalen

Het organiseren van een succesvolle implementatie van DevTest Labs op ondernemingsniveau vereist overweging van belangrijke beslissingspunten en het plannen van een aanpak voor snelle implementatie en implementatie van Azure DevTest Labs.

In dit artikel worden de belangrijkste beslissingspunten beschreven die u moet overwegen bij het plannen van uw implementatie en een aanbevolen benadering voor implementatie.

Belangrijke beslissingspunten

Voordat u DevTest Labs op ondernemingsniveau implementeert, zijn er verschillende belangrijke beslissingspunten. Als u deze beslissingspunten op hoog niveau begrijpt, kan een organisatie in de toekomst ontwerpbeslissingen nemen. Deze punten mogen een organisatie echter niet tegenhouden om een proof-of-concept te starten.

De drie belangrijkste gebieden voor de eerste planning voor omhoog schalen zijn:

• Netwerken en beveiliging
• Abonnementstopologie
• Rollen en verantwoordelijkheden

Netwerken en beveiliging

Netwerken en beveiliging zijn hoekstenen voor alle organisaties. Hoewel een implementatie in de hele onderneming een veel diepere analyse vereist, zijn er een beperkt aantal vereisten om een proof-of-concept te bereiken. Enkele belangrijke aandachtsgebieden zijn:

• Azure-abonnement : als u DevTest Labs wilt implementeren, moet u toegang hebben tot een Azure-abonnement met de juiste rechten om resources te maken. Er zijn verschillende manieren om toegang te krijgen tot Azure-abonnementen, waaronder een Enterprise Overeenkomst en Betalen per gebruik. Zie Licentieverlening voor Azure voor de onderneming voor meer informatie over het verkrijgen van toegang tot een Azure-abonnement.
• Toegang tot on-premises resources : sommige organisaties hebben hun resources in DevTest Labs toegang tot on-premises resources nodig. U hebt een beveiligde verbinding van uw on-premises omgeving met Azure nodig. Het is belangrijk om een VPN- of Azure ExpressRoute-verbinding in te stellen en te configureren voordat u aan de slag gaat. Zie het overzicht van virtuele netwerken voor meer informatie.
• Andere beveiligingsvereisten: andere beveiligingsvereisten , zoals computerbeleid, toegang tot openbare IP-adressen, verbinding maken met internet, zijn scenario's die mogelijk moeten worden gecontroleerd voordat een proof-of-concept wordt geïmplementeerd.

Abonnementstopologie

De abonnementstopologie is een kritieke ontwerpoverweging bij het implementeren van DevTest Labs in de onderneming. Het is echter niet vereist om alle beslissingen te versterken totdat een bewijs van concept is voltooid. Bij het evalueren van het aantal abonnementen dat is vereist voor een enterprise-implementatie, zijn er twee uitersten:

• Eén abonnement voor de hele organisatie
• Abonnement per gebruiker

Vervolgens benadrukken we de voordelen van elke benadering.

Eén abonnement

Vaak is de benadering van één abonnement niet beheersbaar in een grote onderneming. Het beperken van het aantal abonnementen biedt echter de volgende voordelen:

• Kosten voor ondernemingen voorspellen. Budgettering wordt veel eenvoudiger in één abonnement, omdat alle resources zich in één pool bevinden. Met deze aanpak kunt u eenvoudiger beslissingen nemen over het uitvoeren van kostenbeheermaatregelen op elk gewenst moment in een factureringscyclus.
• Beheerbaarheid van VM's, artefacten, formules, netwerkconfiguratie, machtigingen en beleidsregels is eenvoudiger, omdat alle updates slechts in één abonnement zijn vereist in plaats van updates te maken in veel abonnementen.
• Netwerkinspanning is eenvoudiger in één abonnement voor ondernemingen waarbij on-premises connectiviteit een vereiste is. Verbinding maken virtuele netwerken tussen abonnementen (hub-spoke-model), vereist met toegevoegde abonnementen, zijn meer configuratie-, beheer- en IP-adresruimten vereist.
• Teamsamenwerking is eenvoudiger wanneer iedereen in hetzelfde abonnement werkt. Het is bijvoorbeeld eenvoudiger om een VIRTUELE machine opnieuw toe te wijden aan een collega of teamresources te delen.

Abonnement per gebruiker

Een afzonderlijk abonnement per gebruiker biedt gelijke kansen voor het alternatieve spectrum. De voordelen van het gebruik van veel abonnementen zijn onder andere:

• Azure-schaalquota belemmeren de acceptatie niet. Op basis van dit schrijven staat Azure bijvoorbeeld 200 opslagaccounts per abonnement toe. Er zijn operationele quota voor de meeste services in Azure (veel kunnen worden aangepast, sommige niet). In dit model van een abonnement per gebruiker is het zeer onwaarschijnlijk dat de meeste quota worden bereikt. Zie azure-abonnements- en servicelimieten, quota en beperkingen voor meer informatie over huidige azure-schaalquota.
• Terugstortingen naar groepen of individuele ontwikkelaars worden veel eenvoudiger, zodat organisaties rekening kunnen houden met kosten met behulp van hun huidige model.
• Eigendom en machtigingen van de DevTest Labs-omgevingen zijn eenvoudig. U geeft ontwikkelaars toegang op abonnementsniveau en ze zijn 100% verantwoordelijk voor alles, waaronder de netwerkconfiguratie, labbeleid en VM-beheer.

In de Onderneming kunnen er voldoende beperkingen zijn voor de extremen van het spectrum. Daarom moet u mogelijk abonnementen instellen op een manier die in het midden van deze extremen valt. Als best practice moet het doel van een organisatie zijn om het minimale aantal abonnementen te gebruiken dat mogelijk is. Houd rekening met het afdwingen van functies die het totale aantal abonnementen verhogen. Om dit nogmaals te herhalen, is de abonnementstopologie essentieel voor een bedrijfsimplementatie van DevTest Labs, maar moet er geen bewijs van concept worden vertraagd. In het artikel Governance vindt u meer informatie over het bepalen van abonnements- en labgranulariteit in de organisatie.

Rollen en verantwoordelijkheden

Een DevTest Labs-proof-of-concept heeft drie primaire rollen met gedefinieerde verantwoordelijkheden: abonnementseigenaar, DevTest Labs-eigenaar, DevTest Labs-gebruiker en optioneel een inzender.

• Abonnementseigenaar : de eigenaar van het abonnement heeft rechten om een Azure-abonnement te beheren, waaronder het toewijzen van gebruikers, het beheren van beleid, het maken en beheren van netwerktopologie en het aanvragen van quotumverhogingen. Zie dit artikel voor meer informatie.
• Eigenaar van DevTest Labs : de eigenaar van DevTest Labs heeft volledige beheerderstoegang tot het lab. Deze persoon is verantwoordelijk voor het toevoegen/verwijderen van gebruikers, het beheren van kosteninstellingen, algemene labinstellingen en andere taken op basis van VM/artefacten. Een labeigenaar heeft ook alle rechten van een DevTest Labs-gebruiker.
• DevTest Labs-gebruiker : de DevTest Labs-gebruiker kan de virtuele machines in het lab maken en gebruiken. Deze personen hebben enkele minimale beheermogelijkheden op VM's die ze maken (starten/stoppen/verwijderen/hun VM's configureren). De gebruikers kunnen geen VM's van andere gebruikers beheren.

De DevTest Labs-implementatie organiseren

Deze sectie biedt een aanbevolen benadering voor snelle implementatie en implementatie van Azure DevTest Labs. In de volgende afbeelding wordt het algehele proces benadrukt als prescriptieve richtlijnen terwijl u de flexibiliteit voor het ondersteunen van verschillende vereisten en scenario's in de branche bekijkt.

Aannames

In dit artikel wordt ervan uitgegaan dat u de volgende items hebt voordat u een DevTest Labs-testfase implementeert:

• Azure-abonnement: het testteam heeft toegang tot het implementeren van resources in een Azure-abonnement. Als de workloads alleen ontwikkel- en testdoeleinden zijn, is het raadzaam om de Enterprise DevTest-aanbieding te selecteren voor aanvullende beschikbare installatiekopieën en lagere tarieven op virtuele Windows-machines.
• On-premises toegang: indien nodig is on-premises toegang al geconfigureerd. De on-premises toegang kan worden bereikt via een site-naar-site-VPN-verbinding of via Express Route. Verbinding maken iviteit via Express Route kan doorgaans veel weken duren om tot stand te brengen, het is raadzaam om de Express Route in te stellen voordat u het project start.
• Testteams: Het eerste ontwikkelingsprojectteam(en) dat gebruikmaakt van DevTest Labs, is geïdentificeerd, samen met de toepasselijke ontwikkelings- of testactiviteiten en stelt vereisten/doelstellingen/doelstellingen voor die teams vast.

Mijlpaal 1: Eerste netwerktopologie en -ontwerp tot stand brengen

Het eerste aandachtsgebied bij het implementeren van een Azure DevTest Labs-oplossing is het tot stand brengen van de geplande connectiviteit voor de virtuele machines. De volgende stappen geven een overzicht van de benodigde procedures:

1. Definieer initiële IP-adresbereiken die zijn toegewezen aan het DevTest Labs-abonnement in Azure. Deze stap vereist het voorspellen van het verwachte gebruik in het aantal VM's, zodat u een groot genoeg blok voor toekomstige uitbreiding kunt bieden.
2. Methoden voor gewenste toegang identificeren in DevTest Labs (bijvoorbeeld externe/interne toegang). Een belangrijk punt in deze stap is om te bepalen of virtuele machines openbare IP-adressen hebben (dat wil gezegd, rechtstreeks toegankelijk via internet).
3. Identificeer en bepaal methoden voor connectiviteit met de rest van de Azure-cloudomgeving en on-premises. Als de geforceerde routering met Express Route is ingeschakeld, hebben de virtuele machines waarschijnlijk de juiste proxyconfiguraties nodig om de bedrijfsfirewall te doorlopen.
4. Als VM's lid moeten zijn van een domein, moet u bepalen of ze lid worden van een clouddomein (bijvoorbeeld Microsoft Entra Directory Services) of een on-premises domein. Bepaal voor on-premises welke organisatie-eenheid (OE) zich in Active Directory bevindt waaraan de virtuele machines deelnemen. Controleer bovendien of gebruikers toegang hebben om lid te worden (of een serviceaccount tot stand te brengen dat de mogelijkheid heeft om computerrecords in het domein te maken)

Mijlpaal 2: Het testlab implementeren

Zodra de netwerktopologie is ingesteld, kan het eerste/testlab worden gemaakt door de volgende stappen uit te voeren:

1. Maak een eerste DevTest Labs-omgeving.
2. Bepaal toegestane VM-installatiekopieën en -grootten voor gebruik met lab. Bepaal of aangepaste installatiekopieën kunnen worden geüpload naar Azure voor gebruik met DevTest Labs.
3. Beveilig de toegang tot het lab door initiële op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) te maken voor het lab (labeigenaren en labgebruikers). U wordt aangeraden gesynchroniseerde Active Directory-accounts te gebruiken met Microsoft Entra ID voor identiteit met DevTest Labs.
4. Configureer DevTest Labs om beleid te gebruiken, zoals planningen, kostenbeheer, claimbare VM's, aangepaste installatiekopieën of formules.
5. Stel een onlineopslagplaats in, zoals Azure-opslagplaatsen/Git.
6. Bepaal het gebruik van openbare of persoonlijke opslagplaatsen of combinatie van beide. Organiseer JSON-sjablonen voor implementaties en langdurige ondersteuning.
7. Maak indien nodig aangepaste artefacten. Deze stap is optioneel.

Mijlpaal 3: Documentatie, ondersteuning, leren en verbeteren

Voor de eerste testteams is mogelijk uitgebreide ondersteuning vereist om aan de slag te gaan. Gebruik hun ervaringen om ervoor te zorgen dat de juiste documentatie en ondersteuning beschikbaar zijn voor een continue implementatie van Azure DevTest Labs.

1. Introduceer de testteams in hun nieuwe DevTest Labs-resources (demo's, documentatie)
2. Op basis van de ervaringen van testteams kunt u zo nodig documentatie plannen en leveren
3. Formaliseer het proces voor het onboarden van nieuwe teams (het maken en configureren van labs, het bieden van toegang, enzovoort)
4. Controleer op basis van de eerste opname of de oorspronkelijke prognose van de IP-adresruimte nog steeds redelijk en nauwkeurig is
5. Zorg ervoor dat de juiste nalevings- en beveiligingsbeoordelingen zijn voltooid

Volgende stappen

Zie het volgende artikel in deze reeks: Governance van de Infrastructuur van Azure DevTest Labs