Dit artikel bevat een architectuurbenadering voor het voorbereiden van uw Azure DevTest Labs (DTL of Lab) in een Enterprise Scale Landing Zone (ESLZ) met een focus op de ontwerprichtlijnen.
Architectuur
In de architectuur voor DTL in een onderneming wordt de platformbasis doorgaans ingesteld door de platformbeheerder volgens de richtlijnen in ESLZ voor gecentraliseerd netwerken, identiteit en governance. Zie Landingszones op ondernemingsniveau implementeren in Azure voor meer informatie over de installatie van het ESLZ-platform.
De verantwoordelijkheid van het toepassingsteam ligt bij het inrichten van de DTL-kernresources in de DevTest-abonnementen, die rechtsonder in het volgende diagram worden weergegeven. Hierbij wordt de reeds ingestelde basis gebruikt. Het beleid dat op beheergroepen wordt toegepast, wordt naar het DevTest-abonnement en de resources geslepeld.
Hoewel DTL alleen geen ingebouwde limieten heeft, kunnen andere Azure-resources die in het lab worden gebruikt, verder gaan dan de limieten van het Azure-abonnement. In deze gevallen zijn er mogelijk meerdere Azure-abonnementen nodig om grote implementaties van DTL te dekken.
Een Visio-bestand van deze architectuur downloaden.
Gegevensstroom
- De network Beheer istrator maakt een virtueel spoke-netwerk en andere netwerkresources, zoals NSG, UDR in de netwerkresourcegroep die is gekoppeld aan het virtuele hubnetwerk. De peering wordt gemaakt door Azure-beleid dat is toegewezen aan de corp-beheergroep volgens de ESLZ-automatisering. Met deze peering hebben zakelijke gebruikers toegang tot de lab-VM's via VPN/ExpressRoute met een privé-IP-adres.
- De eigenaar van het lab configureert ingebouwde labbeleidsregels per projectvereisten. U kunt alle beschikbare beleidsregels bekijken bij Alle beleidsregels beheren voor een lab in Azure DevTest Labs. Hier volgen enkele beleidsregels die relevant zijn voor dit artikel:
- Configureer de instelling van het virtuele netwerk zodat alle lab-VM's worden gemaakt in het virtuele spoke-netwerk.
- Configureer labinstellingen zodat alle lab-VM's worden gemaakt in de aangewezen labresourcegroep. Op deze manier worden ze niet verdeeld over meerdere resourcegroepen.
- Schakel Browser Verbinding maken in om de Bastion-host te gebruiken die is geïmplementeerd in het virtuele hubnetwerk om RDP-/SSH-toegang tot lab-VM's via internet te beveiligen zonder openbaar IP-adres.
- Configureer labgebruikers en wijs de juiste rollen toe op basis van minimale bevoegdheden. DTL biedt drie ingebouwde rollen: Eigenaar, Inzender en Gebruiker.
- Configureer het artefact voor domeindeelname als een verplicht artefact in het lab als er een vereiste is om lid te worden van het domein van de virtuele lab-machine.
- Configureer een privé-Github/ADO-opslagplaats in het lab voor artefacten en omgevingssjablonen. De opslagplaats kan ook worden gebruikt om toepassingscodebase op te slaan.
- Het toepassingsteam kan handmatig de lab-resources (VM's en PaaS-omgevingen) instellen of Azure Pipelines instellen om resources te implementeren met behulp van DTL-taken.
Resourcetopologie
Binnen het DevTest-abonnement verbetert het stroomlijnen van de organisatie van de resourcegroep voor labs de onderhoudbaarheid van de resources. Traditioneel in een onderneming worden de netwerkresources beheerd door netwerkbeheerders en worden ze geïsoleerd van de toepassingsresources met behulp van afzonderlijke resourcegroepen.
Labresources kunnen worden gedistribueerd binnen twee resourcegroepen binnen het DevTest-abonnement, zoals wordt weergegeven in het bovenstaande diagram:
- Netwerkresourcegroep (rg-network-dtl) met het virtuele netwerk, NSG, Routes. De netwerkbronnen kunnen worden gedeeld in meerdere labs binnen hetzelfde abonnement.
- Labresourcegroep (rg-team-lab1) met de kernlabresources. DTL maakt standaard een resourcegroep voor elke nieuwe virtuele machine en is goed als u deze isolatie wilt. Zo niet, dan kunt u deze configuratie wijzigen om alle VM's in dezelfde resourcegroep te implementeren. Meerdere teams kunnen een DTL delen of een afzonderlijke DTL samenstellen op basis van de team- of projectvereiste.
Bij het inrichten van een DTL worden de volgende infra-resources automatisch gemaakt:
- Key Vault: DTL-gebruikers kunnen KeyVault gebruiken om een wachtwoord op te slaan voor Windows-VM, een openbare SSH-sleutel voor Linux-VM of een persoonlijk toegangstoken om een Git-opslagplaats te klonen via een artefact.
- Opslagaccount: DTL maakt gebruik van opslagaccounts voor de volgende doeleinden:
- Formuledocumenten opslaan die kunnen worden gebruikt om virtuele machines te maken
- Artefactresultaten opslaan, inclusief implementatie- en extensielogboeken die zijn gegenereerd op het toepassen van artefacten
- Virtuele harde schijven (VHD's) uploaden om aangepaste installatiekopieën in het lab te maken
- Veelgebruikte artefacten en Azure Resource Manager-sjablonen opslaan in de cache voor sneller ophalen tijdens het maken van virtuele machines en omgevingen
- Virtueel netwerk: DTL maakt een standaard virtueel netwerk, tenzij er een bestaand virtueel netwerk wordt opgegeven. In deze architectuur wordt een bestaand virtueel spoke-netwerk dat is gekoppeld aan het virtuele hubnetwerk aanbevolen.
Onderdelen
- Landingszone op ondernemingsniveau (ESLZ) is een architectuurbenadering en een referentie-implementatie die effectieve bouw en operationalisatie van landingszones op Azure op schaal mogelijk maakt. Azure Landing Zones zijn de uitvoer van een Azure-omgeving met meerdere abonnementen die accounts maakt voor schaal, beveiliging, governance, netwerken en identiteit. DTL kan worden geïmplementeerd in de DevTest-landingszone of sandbox-abonnement, zoals besproken in de beheergroep en abonnementstopologie.
- Azure DevTest Labs (DTL) is een volledig beheerde service die ontwikkelaars en testers gebruiken om snel ontwikkel- en testomgevingen in te richten. Met DTL kunnen gebruikers virtuele machines en PaaS-resources maken. Hoewel het maken van vm's systeemeigen wordt ondersteund, kan het maken van PaaS-resources worden bereikt met behulp van omgevingssjablonen.
- Met DTL-beleid kunt u kosten beheren en verspilling in uw labs minimaliseren door beleidsregels (instellingen) voor elk lab te beheren. Met behulp van DTL-beleid kunt u labverspilling minimaliseren door op te geven welke VM-grootten zijn toegestaan in het lab. Als dit beleid actief is, kunnen alleen VM-grootten uit de lijst worden gebruikt om VM's te maken.
- Hub- en spoke-configuraties bieden voordelen, waaronder kostenbesparingen, het overwinnen van abonnementslimieten en isolatie van werkbelastingen. Het virtuele hubnetwerk fungeert als een centraal punt van connectiviteit met veel virtuele spoke-netwerken en on-premises netwerken. De virtuele spoke-netwerken peeren met de hub en kunnen worden gebruikt om workloads te isoleren. DTL kan in het spoke-netwerk worden geplaatst, zodat ondernemingen een centrale controle kunnen hebben over beveiligingsfuncties, zoals een firewall in de hub als DMZ, Express Route/VPN-connectiviteit en gescheiden beheer voor de workload. Traditioneel worden de virtuele netwerken, met inbegrip van het virtuele spoke-netwerk, geleverd door de platformbeheerder. Het app-team kan de DTL inrichten in het opgegeven subnet. Meer informatie vindt u in de netwerktopologie.
- Azure Bastion is een volledig beheerde service die veiligere en naadloze RDP-toegang (Remote Desktop Protocol) en Secure Shell Protocol (SSH) biedt tot VM's zonder blootstelling via openbare IP-adressen. DTL kan de Bastion-host gebruiken om veilig RDP/SSH naar VM's te gebruiken zonder ze rechtstreeks via internet weer te geven, zoals besproken in de netwerktopologie. DTL staat standaard connectiviteit met vm toe via een openbaar IP-adres of gedeeld openbaar IP-adres.
- Met DTL-artefacten kunt u acties opgeven die worden uitgevoerd wanneer de virtuele machine wordt ingericht, zoals het uitvoeren van Windows PowerShell-scripts, het uitvoeren van Bash-opdrachten en het installeren van software. Met artefactparameters kunt u het artefact voor uw scenario aanpassen. De opslagplaats voor openbare artefacten, onderhouden door DevTest Labs, biedt veel algemene hulpprogramma's voor Zowel Windows als Linux. Er wordt automatisch een koppeling naar deze opslagplaats toegevoegd aan uw lab.
- Een formule in Azure DevTest Labs is een lijst met standaardeigenschapswaarden die worden gebruikt om een virtuele machine te maken.
- Met DTL-omgevingen kunnen gebruikers complexe infrastructuren op een consistente manier implementeren binnen de grenzen van het lab. U kunt Azure Resource Manager-sjablonen gebruiken om omgevingen te maken met sets resources in DevTest Labs. Deze omgevingen kunnen alle Azure-resources bevatten die Resource Manager-sjablonen kunnen maken.
Alternatieven
Klanten kunnen een oplossing bouwen die vergelijkbaar is met DevTest Labs door meerdere services samen te stellen met systeemeigen Azure-functies, zoals Beleid, RBAC-groepen, VM-extensies en Automation.
Het belangrijkste voordeel van het gebruik van DevTest Labs is de kant-en-klare geïntegreerde functies en intuïtieve interface, waardoor nieuwe gebruikers (Beheer s en ontwikkelaars) die geen diepgaande vaardigheden hebben in Azure. Op deze manier bespaart DTL tijd en moeite in de implementatie en het onderhoud.
Scenariodetails
DTL helpt ontwikkelaars binnen teams efficiënt virtuele machines (VM's) en PaaS-resources te beheren zonder te wachten op goedkeuringen, waardoor een zorgeloze selfserviceomgeving ontstaat. Het biedt een uitstekende waarde voor belangrijke scenario's, met name wanneer u aan de slag gaat met Azure, zoals desktopcomputers voor ontwikkelaars, testomgevingen, trainingssessies en onderzoeken in de sandbox. Het ingebouwde labbeleid en de drempelwaarden helpen moeiteloos de kosten te verlagen. Zie DevTest Labs-concepten voor meer informatie over de kernconcepten van DTL.
Dit artikel bevat aanbevelingen voor beheergroep- en abonnementstopologie, netwerken, identiteit, Enterprise Overeenkomst aanbiedingen, toepassingsautomatisering en beveiliging voor DevTest-workloads in de context van DTL.
Ondernemingen die DevTest-workloads op grote schaal migreren, kunnen profiteren van het instellen van deze architectuur op ondernemingsniveau en kunnen het volgende bereiken:
- Verminderde operationele overhead voor toepassingsteams, omdat ze zich kunnen richten op het ontwikkelen/testen van toepassingen met DTL en al het platformbeheer, netwerken, beveiliging en identiteit instellen met een Centraal IT-team.
- Gecentraliseerde handhaving van de naleving van de organisatie in DevTest-workloads.
Potentiële gebruikscases
Deze architectuur is handig voor organisaties die het volgende nodig hebben:
- Vanaf het begin een volledig geïntegreerd besturingsvlak voor DevTest-workloads.
- Een duidelijke scheiding van zorgen tussen platform- en toepassingsworkloads.
Deze architectuur zou traditioneel fungeren als uitgangspunt voor grootschalige implementaties van DevTest-workloads in abonnementen.
Overwegingen
Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.
Beveiliging
Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie.
Deze beveiligingsbasislijn past richtlijnen toe van Azure Security Benchmark versie 2.0 op DTL.
Governance en naleving
De volgende koppelingen zijn gericht op governance en naleving voor DTL:
- Behandelt de governance en het beheer van resources in DTL
- Biedt richtlijnen voor het beheren van bedrijfsbeleid en naleving voor DTL-infrastructuur
- Biedt informatie waarmee u het eigendom in uw DTL-omgeving kunt uitlijnen
- Behandelt governance met betrekking tot toepassingsmigratie en -integratie voor DTL
Identiteits- en toegangsbeheer
Ondernemingsorganisaties volgen doorgaans een benadering met minimale bevoegdheden voor operationele toegang die is ontworpen via Microsoft Entra ID, op rollen gebaseerd toegangsbeheer van Azure (RBAC) en aangepaste roldefinities. Met de RBAC-rollen kunt u DTL-resources beheren, zoals virtuele machines maken, omgevingen maken en starten, stoppen, opnieuw opstarten, verwijderen en artefacten toepassen.
- Toegang tot labs kan worden geconfigureerd om taken binnen uw team te scheiden in verschillende rollen. Drie van deze RBAC-rollen zijn Eigenaar, DevTest Labs User en Inzender. De DTL-resource moet eigendom zijn van degenen die inzicht hebben in de project- en teamvereisten voor budget, machines en vereiste software. Een algemeen model is de projectleider of de app-beheerder als labeigenaar en de teamleden als labgebruikers. De rol Inzender kan worden toegewezen aan app-infra-leden die machtigingen nodig hebben om labbronnen te beheren. Labeigenaar is verantwoordelijk voor het configureren van het beleid en het toevoegen van de vereiste gebruikers aan het lab.
- Voor ondernemingen waarvoor gebruikers verbinding moeten maken met identiteiten op basis van een domein, kan een domeincontroller die aan het Platform-abonnement is toegevoegd, worden gebruikt voor DTL-VM's die lid zijn van een domein. DTL-artefacten bieden automatisch een manier om VM's toe te voegen aan een domein. Virtuele DTL-machines maken standaard gebruik van een lokaal beheerdersaccount.
- DTL ondersteunt beheerde identiteiten voor de Azure-resources. Gebruik beheerde identiteiten met DTL voor toegang tot Key Vault, Storage en het implementeren van VM's en PaaS-resources. Wijs door de gebruiker toegewezen beheerde identiteiten toe op uw lab-VM's in DTL om lab-VM-gebruikers toegang te geven tot Azure-resources.
Netwerktopologie
Organisaties werken vaak met regionale hub-spoke-netwerktopologie waarbij de hub en spokes worden geïmplementeerd in afzonderlijke virtuele netwerken en abonnementen zijn verbonden via peering.
Zoals u in het voorgaande architectuurdiagram ziet, gebruiken DTL-resources de bestaande virtuele spoke-netwerken die zijn gekoppeld aan het virtuele hubnetwerk. Het virtuele hubnetwerk, dat deel uitmaakt van het Platform-abonnement, maakt beveiligde connectiviteit mogelijk via RDP/SSH-toegang tot:
- Virtuele DTL-machines die gebruikmaken van privé-IP voor interne gebruikers via VPN/ER. Verbinding maken iviteit voor on-premises omgevingen is ook vereist in hybride toepassingsscenario's waarbij sommige van de vereiste onderdelen nog on-premises zijn, zoals database en Active Directory-domein.
- Virtuele DTL-machines die gebruikmaken van privé-IP voor externe gebruikers via Bastion Host via internet. Organisaties kunnen ook extern bureaublad-gateway configureren in DTL in plaats van een traditionele RDP-verbinding via internet te gebruiken als ze liever geen browserverbinding maken via Bastion.
Het hub-spoke-ontwerp helpt de directe blootstelling van DTL-resources aan het openbare internet te minimaliseren, biedt isolatie van workloads en maakt de architectuur uitbreidbaar. Bepaalde resources, zoals een firewall en DNS, kunnen worden gedeeld via spoke-netwerken.
DTL biedt ook de mogelijkheid om rechtstreeks verbinding te maken met VM's via openbaar IP- of gedeeld IP-adres , indien toegestaan door naleving van de organisatie.
Kostenoptimalisatie
Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.
- De Azure DevTest Labs-service is zelf gratis. Kosten worden echter toegeschreven aan andere Azure-resources die zijn gemaakt in het lab, zoals Storage, Key Vault en VM's. Prijsinformatie vindt u in de prijzen van Azure DevTest Labs. U kunt ook de Azure-kostencalculator gebruiken om uw kosten te schatten.
- De koppeling bevat informatie over hoe de ingebouwde functies van DevTest Labs u helpen bij het optimaliseren, bijhouden en beheren van kosten.
- Beleid gebruiken om kosten te optimaliseren
- Kosten bijhouden en beheren
- Kosten verder optimaliseren met DevTest Benefits
- Azure Well-architected framework biedt richtlijnen voor het beheren van kosten om de geleverde waarde te maximaliseren
Enterprise Overeenkomst voor DevTest
Enterprise Overeenkomst klanten een uitstekende manier hebben om hun ontwikkel- en testworkloads in Azure uit te voeren door zich aan te melden voor lagere tarieven voor dev/test-workloads, zoals beschreven op Enterprise Dev/Test. Als u het DevTest-abonnement inschakelt in de Azure Enterprise-portal, kan een organisatie:
- Clientbesturingssystemen uitvoeren die doorgaans niet beschikbaar zijn in een Azure Enterprise-abonnement
- Bedrijfssoftware gebruiken waarin ze alleen betalen voor de rekenkracht
- Vertrouwen in licenties
Operationele uitmuntendheid
Operationele uitmuntendheid omvat de operationele processen die een toepassing implementeren en deze in productie houden. Zie Overzicht van de operationele uitmuntendheidpijler voor meer informatie.
Application Automation en DevOps
In de context van DTL omvat automatisering:
- Inrichten van DTL-exemplaar. Consistente en herhaalbare implementatie van DTL met beleid met behulp van ARM/Bicep-sjablonen die zijn opgeslagen in git-opslagplaats. Automatisering kan worden bereikt via elk CI/CD-framework.
- Het inrichten van resources binnen DTL met behulp van Azure DevOps. Automatisering met de Azure Pipelines Marketplace-extensie, Azure DevTest Labs-taken voor het maken en verwijderen van lab-VM's, aangepaste installatiekopieën en omgevingen.
- Inrichting van artefacten en PaaS-omgevingen met ingebouwde DTL-automatisering. Configureer de persoonlijke aangepaste opslagplaats (ADO of GitHub) in het lab of gebruik de inhoud van de Community-opslagplaats van Azure Lab Services die beschikbaar is voor het opslaan en automatiseren van artefacten en implementatie van omgevingssjablonen.
Er zijn veel andere manieren om Azure en DevTest Labs te automatiseren, waaronder REST API's, PowerShell, Azure CLI en Azure SDK.
Integratie van DTL met Azure DevOps voor ontwikkeling en bewerkingen wordt beschreven in Azure DevTest Labs en Azure DevOps integreren. Azure Architecture Center biedt ook een artikel voor DevTest en DevOps voor IaaS.
Topologie van beheergroep en abonnement
Een goed ontworpen topologie voor beheergroepen en abonnementen, samen met organisatiestructuur en nalevingsvereisten, zorgt voor een juiste isolatie en maximale flexibiliteit voor toekomstige groei. De installatie van de beheergroep en het abonnement is de verantwoordelijkheid van de platformeigenaar die de vereiste toegang biedt tot de toepassingsbeheerder of labeigenaar om het lab in te richten.
Zoals wordt weergegeven in het voorgaande architectuurdiagram, kunnen toepassingsteams DTL implementeren in een abonnement onder een beheergroep voor landingszones of sandbox-beheergroepen, op basis van deze paar beslissingspunten:
- Als de globale naleving van de organisatie die is gedefinieerd in de beheergroep voor landingszones geldig is voor DevTest-workloads, kan de DTL worden geïmplementeerd in een abonnement op een niet-productielandingszone onder een Corp- of Online-beheergroep op basis van de vereiste voor connectiviteit met een on-premises omgeving. In dit geval worden alle Azure-beleidsregels die zijn toegepast op de beheergroepen voor landingszones voor naleving overgenomen door alle abonnementen eronder. Dit omvat DTL-resources samen met het door de beheerder geconfigureerde beleid.
- DTL kan ook worden geconfigureerd in een sandbox-omgeving voor verkenning, training en onderzoek. In dit geval kan DTL worden geïmplementeerd in een abonnement onder een sandbox-beheergroep, die minimale beperkingen heeft en gebruikers de vrijheid biedt om te verkennen.
Bijdragers
Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
Hoofdauteur:
- Vidya Narasimhan | Senior Cloud Solution Architect
Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.
Volgende stappen
- Zie Landingszones op ondernemingsniveau implementeren voor hulp bij het instellen van landingszones op enterprise-schaal.
- Als u een initiële netwerktopologie en -ontwerp tot stand brengt, ziet u hoe u Azure DevTest Labs snel kunt implementeren.