Styrning av Azure DevTest Labs-infrastruktur

Den här artikeln behandlar anpassning och hantering av resurser för DevTest Labs i din organisation.

Resurser

Justera DevTest Labs-resurser i en Azure-prenumeration

Innan en organisation börjar använda Azure för allmän programutveckling bör IT-planerare först granska hur du introducerar funktionen som en del av deras övergripande tjänsteportfölj. Områden för översyn bör ta itu med följande problem:

• Hur mäter jag kostnaden som är associerad med livscykeln för programutveckling?
• Hur anpassar organisationen det föreslagna tjänsterbjudandet efter företagets säkerhetsprincip?
• Krävs segmentering för att separera utvecklings- och produktionsmiljöerna?
• Vilka kontroller införs för långsiktig enkel hantering, stabilitet och tillväxt?

Den första rekommenderade metoden är att granska organisationens Azure-taxonomi där uppdelningarna mellan produktions- och utvecklingsprenumerationer beskrivs. I följande diagram möjliggör den föreslagna taxonomi en logisk uppdelning av utvecklings-/testnings- och produktionsmiljöer. Med den här metoden kan en organisation införa faktureringskoder för att spåra kostnader som är associerade med varje miljö separat. Mer information finns i Förebyggande prenumerationsstyrning. Dessutom kan du använda Azure-taggar för att organisera resurser i spårnings- och faktureringssyfte.

Den andra rekommenderade metoden är att aktivera DevTest-prenumerationen i Azure Enterprise-portalen. Det gör att en organisation kan köra klientoperativsystem som vanligtvis inte är tillgängliga i en Azure Enterprise-prenumeration. Använd sedan företagsprogram där du bara betalar för beräkningen och inte bryr dig om licensiering. Det säkerställer att faktureringen för avsedda tjänster, inklusive galleribilder i IaaS, till exempel Microsoft SQL Server, endast baseras på förbrukning. Information om Azure DevTest-prenumerationen finns här för ugovor za preduzeća kunder (EA) och här för Betala per användning-kunder.

Den här modellen ger en organisation flexibiliteten att distribuera Azure DevTest Labs i stor skala. En organisation kan stödja hundratals labb för olika affärsenheter med 100 till 1 000 virtuella datorer som körs parallellt. Det främjar begreppet en centraliserad företagslabblösning som kan dela samma principer för konfigurationshantering och säkerhetskontroller.

Den här modellen säkerställer också att organisationen inte överskrider sina resursgränser som är associerade med deras Azure-prenumeration. Mer information om prenumerations- och tjänstgränser finns i Azure-prenumerations- och tjänstgränser, kvoter och begränsningar. DevTest Labs-etableringsprocessen kan använda ett stort antal resursgrupper. Du kan begära att gränserna ökas genom en supportbegäran i Azure DevTest-prenumerationen. Resurserna i produktionsprenumerationen påverkas inte när utvecklingsprenumerationen växer i bruk. Mer information om hur du skalar DevTest Labs finns i Skala kvoter och gränser i DevTest Labs.

En vanlig gräns på prenumerationsnivå som måste redovisas är hur nätverks-IP-intervalltilldelningar allokeras för att stödja både produktions- och utvecklingsprenumerationer. Dessa tilldelningar bör ta hänsyn till tillväxt över tid (förutsatt lokal anslutning eller en annan nätverkstopologi som kräver att företaget hanterar sin nätverksstack i stället för att som standard använda Azures implementering). Den rekommenderade metoden är att ha några virtuella nätverk som har ett stort IP-adressprefix tilldelat och delat med många stora undernät i stället för att ha flera virtuella nätverk med små undernät. Med 10 prenumerationer kan du till exempel definiera 10 virtuella nätverk (ett för varje prenumeration). Alla labb som inte kräver isolering kan dela samma undernät i prenumerationens virtuella nätverk.

Antal användare per labb och labb per organisation

Affärsenheter och utvecklingsgrupper som är associerade med samma utvecklingsprojekt bör associeras med samma labb. Det gör att samma typer av principer, bilder och avstängningsprinciper kan tillämpas på båda grupperna.

Du kan också behöva överväga geografiska gränser. Utvecklare i nordöstra USA (USA) kan till exempel använda ett labb som etablerats i USA, östra 2. Och utvecklare i Dallas, Texas och Denver, Colorado kan instrueras att använda en resurs i USA, södra centrala. Om det finns ett samarbete med en extern tredje part kan de tilldelas till ett labb som inte används av interna utvecklare.

Du kan också använda ett labb för ett specifikt projekt i Azure DevOps Projects. Sedan tillämpar du säkerhet via en angiven Microsoft Entra-grupp, vilket ger åtkomst till båda uppsättningarna resurser. Det virtuella nätverk som tilldelats labbet kan vara en annan gräns för att konsolidera användare.

Förhindra borttagning av resurser

Ange behörigheter på labbnivå så att endast behöriga användare kan ta bort resurser eller ändra labbprinciper. Utvecklare bör placeras i gruppen DevTest Labs-användare . Den ledande utvecklaren eller infrastrukturledaren bör vara DevTest Labs-ägare. Vi rekommenderar att du bara har två labbägare. Den här principen sträcker sig mot kodlagringsplatsen för att undvika skador. Lab använder har behörighet att använda resurser men kan inte uppdatera labbprinciper. Se följande artikel som visar de roller och rättigheter som varje inbyggd grupp har i ett labb: Lägg till ägare och användare i Azure DevTest Labs.

Hantera kostnader och ägarskap

Kostnader och ägarskap är primära problem när du funderar på att skapa utvecklings- och testmiljöer. I det här avsnittet hittar du information som hjälper dig att optimera för kostnader och anpassa ägarskapet i din miljö.

Optimera för kostnad

Flera inbyggda funktioner i DevTest Labs hjälper dig att optimera för kostnader. Se artiklar om kostnadshantering, tröskelvärden och principer för att begränsa användarnas aktiviteter.

Om du använder DevTest Labs för utvecklings- och testarbetsbelastningar bör du överväga att använda enterprise dev/test-prenumerationsförmånen som ingår i din ugovor za preduzeća. Eller om du är en Betala per användning-kund bör du överväga DevTest-erbjudandet Betala per användning.

Den här metoden ger flera fördelar:

• Särskilda lägre Dev/Test-priser på virtuella Windows-datorer, molntjänster, HDInsight, App Service och Logic Apps
• Ea-priser (Great ugovor za preduzeća) för andra Azure-tjänster
• Tillgång till exklusiva avbildningar för utveckling/testning i galleriet, inklusive Windows 8.1 och Windows 10

Endast aktiva Visual Studio-prenumeranter (standardprenumerationer, årliga molnprenumerationer och månatliga molnprenumerationer) kan använda Azure-resurser som körs i en Dev/Test-prenumeration för företag. Slutanvändarna kan dock komma åt programmet för att ge feedback eller utföra godkännandetester. Du kan endast använda resurser i den här prenumerationen för att utveckla och testa program. Det finns ingen garanti för drifttid.

Om du väljer att använda DevTest-erbjudandet använder du den här förmånen enbart för utveckling och testning av dina program. Användning i prenumerationen har inte ett ekonomiskt säkerhetskopierat serviceavtal, förutom användning av Azure DevOps och HockeyApp.

Definiera rollbaserad åtkomst i hela organisationen

Den centrala IT-avdelningen ska bara äga det som behövs och göra det möjligt för projekt- och programteamen att ha den kontrollnivå som krävs. Vanligtvis innebär det att den centrala IT-avdelningen äger prenumerationen och hanterar grundläggande IT-funktioner, till exempel nätverkskonfigurationer. Uppsättningen ägare för en prenumeration ska vara liten. Dessa ägare kan nominera andra ägare när det finns ett behov eller tillämpa principer på prenumerationsnivå, till exempel "Ingen offentlig IP-adress".

Det kan finnas en delmängd användare som kräver åtkomst i en prenumeration, till exempel stöd för nivå 1 eller nivå 2. I det här fallet rekommenderar vi att du ger dessa användare deltagaråtkomst så att de kan hantera resurserna, men inte ge användaren åtkomst eller justera principer.

DevTest Labs-resursägare bör vara nära projektet eller programteamet. Dessa ägare förstår maskin- och programvarukraven. I de flesta organisationer är ägaren av DevTest Labs-resursen projekt- eller utvecklingsledare. Den här ägaren kan hantera användare och principer i labbmiljön och hantera alla virtuella datorer i DevTest Labs-miljön.

Lägg till projekt- och programteammedlemmar i rollen DevTest Labs-användare. Dessa användare kan skapa virtuella datorer i enlighet med labb- och prenumerationsnivåprinciper. Användare kan också hantera sina egna virtuella datorer, men kan inte hantera virtuella datorer som tillhör andra användare.

Mer information finns i Azure Enterprise scaffold – förebyggande prenumerationsstyrning.

Företagets policy och efterlevnad

Det här avsnittet innehåller vägledning om hur du styr företagets policy och efterlevnad för Azure DevTest Labs-infrastrukturen.

Offentlig eller privat artefaktlagringsplats

Den offentliga artefaktlagringsplatsen innehåller en första uppsättning programvarupaket som används oftast. Det hjälper till med snabb distribution utan att behöva investera tid för att återskapa vanliga utvecklarverktyg och tillägg. Du kan välja att distribuera en egen privat lagringsplats. Du kan använda en offentlig och en privat lagringsplats parallellt. Du kan också välja att inaktivera den offentliga lagringsplatsen. Kriterierna för att distribuera en privat lagringsplats bör styras av följande frågor och överväganden:

• Har organisationen ett krav på att ha företagslicensierad programvara som en del av sitt DevTest Labs-erbjudande? Om svaret är ja ska en privat lagringsplats skapas.
• Utvecklar organisationen anpassad programvara som tillhandahåller en specifik åtgärd, vilket krävs som en del av den övergripande etableringsprocessen? Om svaret är ja ska en privat lagringsplats distribueras.
• Om organisationens styrningsprincip kräver isolering och externa lagringsplatser inte hanteras direkt av organisationen bör en privat artefaktlagringsplats distribueras. Som en del av den här processen kan en första kopia av den offentliga lagringsplatsen kopieras och integreras med den privata lagringsplatsen. Sedan kan den offentliga lagringsplatsen inaktiveras så att ingen i organisationen längre kan komma åt den. Den här metoden tvingar alla användare i organisationen att bara ha en enda lagringsplats som är godkänd av organisationen och minimera konfigurationsavvikelsen.

Enskild lagringsplats eller flera lagringsplatser

Som en del av organisationens övergripande strategi för styrning och konfigurationshantering rekommenderar vi att du använder en centraliserad lagringsplats. När du använder flera lagringsplatser kan de bli silor av ohanterad programvara över tid. Med en central lagringsplats kan flera team använda artefakter från den här lagringsplatsen för sina projekt. Det framtvingar standardisering, säkerhet, enkel hantering och eliminerar duplicering av arbete. Som en del av centraliseringen rekommenderas följande åtgärder för långsiktig hantering och hållbarhet:

• Associera Azure Repos med samma Microsoft Entra-klientorganisation som Azure-prenumerationen använder för autentisering och auktorisering.
• Skapa en grupp med namnet Alla DevTest Labs-utvecklare i Microsoft Entra-ID som hanteras centralt. Utvecklare som bidrar till artefaktutveckling bör placeras i den här gruppen.
• Samma Microsoft Entra-grupp kan användas för att ge åtkomst till Azure Repos-lagringsplatsen och till labbet.
• I Azure Repos ska förgrening eller förgrening användas för att separera en lagringsplats under utveckling från den primära produktionslagringsplatsen. Innehållet läggs bara till i huvudgrenen med en pull-begäran efter en korrekt kodgranskning. När kodgranskaren har godkänt ändringen sammanfogar en leadutvecklare, som ansvarar för underhåll av huvudgrenen, den uppdaterade koden.

Företagets säkerhetsprinciper

En organisation kan tillämpa företagets säkerhetsprinciper genom att:

• Utveckla och publicera en omfattande säkerhetsprincip. Principen uttrycker reglerna för acceptabel användning som är associerade med användning av programvara, molntillgångar. Den definierar också vad som tydligt bryter mot principen.
• Utveckla en anpassad avbildning, anpassade artefakter och en distributionsprocess som möjliggör orkestrering inom säkerhetssfären som definieras med Active Directory. Den här metoden tillämpar företagsgränsen och anger en gemensam uppsättning miljökontroller. Dessa kontroller mot miljön som en utvecklare kan tänka på när de utvecklar och följer en säker utvecklingslivscykel som en del av sin övergripande process. Målet är också att tillhandahålla en miljö som inte är alltför restriktiv och som kan hindra utvecklingen, utan en rimlig uppsättning kontroller. Grupprinciperna på organisationsenheten (OU) som innehåller virtuella labbdatorer kan vara en delmängd av de totala grupprinciper som finns i produktion. Alternativt kan de vara en annan uppsättning för att på ett korrekt sätt minimera eventuella identifierade risker.

Dataintegritet

En organisation kan säkerställa dataintegritet för att säkerställa att fjärrkommunikationsutvecklare inte kan ta bort kod eller införa skadlig kod eller icke-godkänd programvara. Det finns flera lager av kontroll för att minska hotet från externa konsulter, entreprenörer eller anställda som tar sig in för att samarbeta i DevTest Labs.

Som tidigare nämnts måste det första steget ha en godtagbar användningsprincip utarbetad och definierad som tydligt beskriver konsekvenserna när någon bryter mot principen.

Det första lagret med kontroller för fjärråtkomst är att tillämpa en fjärråtkomstprincip via en VPN-anslutning som inte är direkt ansluten till labbet.

Det andra lagret av kontroller är att tillämpa en uppsättning grupprincipobjekt som förhindrar kopiering och klistra in via fjärrskrivbord. En nätverksprincip kan implementeras för att inte tillåta utgående tjänster från miljön, till exempel FTP- och RDP-tjänster från miljön. Användardefinierad routning kan tvinga all Azure-nätverkstrafik tillbaka till den lokala miljön, men routningen kunde inte ta hänsyn till alla URL:er som kan tillåta uppladdning av data om den inte styrs via en proxy för att genomsöka innehåll och sessioner. Offentliga IP-adresser kan begränsas i det virtuella nätverket som stöder DevTest Labs för att inte tillåta bryggning av en extern nätverksresurs.

I slutändan måste samma typ av begränsningar tillämpas i hela organisationen, som också måste ta hänsyn till alla möjliga metoder för flyttbara medier eller externa URL:er som kan acceptera ett inlägg med innehåll. Kontakta säkerhetspersonalen för att granska och implementera en säkerhetsprincip. Fler rekommendationer finns i Microsoft Cyber Security.

Migrering och integrering av program

När din utvecklings-/testlabbmiljö har upprättats måste du tänka på följande frågor:

• Hur använder du miljön i projektteamet?
• Hur ser du till att du följer nödvändiga organisationsprinciper och behåller flexibiliteten för att lägga till värde i ditt program?

Azure Marketplace-avbildningar jämfört med anpassade avbildningar

Azure Marketplace bör användas som standard om du inte har specifika problem eller organisatoriska krav. Några vanliga exempel är;

• Komplex programvarukonfiguration som kräver att ett program inkluderas som en del av basavbildningen.
• Installationen och installationen av ett program kan ta många timmar, vilket inte är en effektiv användning av beräkningstiden som ska läggas till på en Azure Marketplace-avbildning.
• Utvecklare och testare behöver snabbt åtkomst till en virtuell dator och vill minimera installationstiden för en ny virtuell dator.
• Efterlevnads- eller regelvillkor (till exempel säkerhetsprinciper) som måste finnas för alla datorer.

Överväg att använda anpassade avbildningar noggrant. Anpassade avbildningar ger extra komplexitet eftersom du nu måste hantera VHD-filer för de underliggande basavbildningarna. Du måste också regelbundet korrigera dessa basavbildningar med programuppdateringar. Dessa uppdateringar omfattar nya operativsystemuppdateringar (OS) och eventuella uppdateringar eller konfigurationsändringar som behövs för själva programvarupaketet.

Formel jämfört med anpassad avbildning

Vanligtvis är den avgörande faktorn i det här scenariot kostnad och återanvändning.

Du kan minska kostnaderna genom att skapa en anpassad avbildning om:

• Många användare eller labb kräver avbildningen.
• Den nödvändiga avbildningen har mycket programvara ovanpå basavbildningen.

Den här lösningen innebär att du skapar avbildningen en gång. En anpassad avbildning minskar installationstiden för den virtuella datorn. Du debiteras inte kostnader för att köra den virtuella datorn under installationen.

En annan faktor är frekvensen för ändringar i programvarupaketet. Om du kör dagliga versioner och kräver att programvaran finns på användarnas virtuella datorer bör du överväga att använda en formel i stället för en anpassad avbildning.

Mönster för att konfigurera nätverkskonfiguration

När du ser till att utveckling och testning av virtuella datorer inte kan nå det offentliga Internet finns det två aspekter att tänka på – inkommande och utgående trafik.

Inkommande trafik – Om den virtuella datorn inte har någon offentlig IP-adress kan internet inte nå den. En vanlig metod är att ange en princip på prenumerationsnivå som ingen användare kan skapa en offentlig IP-adress.

Utgående trafik – Om du vill förhindra att virtuella datorer går direkt till det offentliga Internet och tvingar trafik via en företagsbrandvägg kan du dirigera trafik lokalt via Azure ExpressRoute eller VPN med hjälp av tvingad routning.

Kommentar

Om du har en proxyserver som blockerar trafik utan proxyinställningar ska du inte glömma att lägga till undantag till labbets artefaktlagringskonto, .

Du kan också använda nätverkssäkerhetsgrupper för virtuella datorer eller undernät. Det här steget lägger till ytterligare ett skyddslager för att tillåta eller blockera trafik.

Nytt jämfört med befintligt virtuellt nätverk

Om dina virtuella datorer behöver interagera med befintlig infrastruktur bör du överväga att använda ett befintligt virtuellt nätverk i DevTest Labs-miljön. Om du använder ExpressRoute minimerar du antalet virtuella nätverk och undernät så att du inte delar upp det IP-adressutrymme som tilldelats dina prenumerationer. Överväg också att använda peeringmönstret för virtuella nätverk här (Hub-Spoke-modellen). Den här metoden möjliggör kommunikation mellan virtuella nätverk och undernät mellan prenumerationer inom en viss region.

Varje DevTest Labs-miljö kan ha ett eget virtuellt nätverk, men det finns gränser för antalet virtuella nätverk per prenumeration. Standardbeloppet är 50, men den här gränsen kan höjas till 100.

Delad, offentlig eller privat IP-adress

Om du använder en plats-till-plats-VPN eller Express Route kan du överväga att använda privata IP-adresser så att dina datorer är tillgängliga via ditt interna nätverk och otillgängliga via offentligt Internet.

Kommentar

Labbägare kan ändra den här undernätsprincipen för att säkerställa att ingen av misstag skapar offentliga IP-adresser för sina virtuella datorer. Prenumerationsägaren bör skapa en prenumerationsprincip som förhindrar att offentliga IP-adresser skapas.

När du använder delade offentliga IP-adresser delar de virtuella datorerna i ett labb en offentlig IP-adress. Den här metoden kan vara till hjälp när du behöver undvika att överskrida gränserna för offentliga IP-adresser för en viss prenumeration.

Labbgränser

Det finns flera labbgränser som du bör känna till. Dessa gränser beskrivs i följande avsnitt.

Gränser för labb per prenumeration

Det finns ingen specifik gräns för hur många labb som kan skapas per prenumeration. Mängden resurser som används per prenumeration är dock begränsad. Du kan läsa om begränsningar och kvoter för Azure-prenumerationer och hur du ökar dessa gränser.

Gränser för virtuella datorer per labb

Det finns ingen specifik gräns för hur många virtuella datorer som kan skapas per labb. De resurser (VM-kärnor, offentliga IP-adresser och så vidare) som används är dock begränsade per prenumeration. Du kan läsa om begränsningar och kvoter för Azure-prenumerationer och hur du ökar dessa gränser.

Gränser för antalet virtuella datorer per användare eller labb

När du tänker på antalet virtuella datorer per användare eller per labb finns det tre huvudsakliga problem:

• Den totala kostnaden som teamet kan spendera på resurser i labbet. Det är lätt att starta många datorer. För att kontrollera kostnaderna är en mekanism att begränsa antalet virtuella datorer per användare eller per labb
• Det totala antalet virtuella datorer i ett labb påverkas av tillgängliga kvoter på prenumerationsnivå. En av de övre gränserna är 800 resursgrupper per prenumeration. DevTest Labs skapar för närvarande en ny resursgrupp för varje virtuell dator (såvida inte delade offentliga IP-adresser används). Om det finns 10 labb i en prenumeration kan labb rymma cirka 79 virtuella datorer i varje labb (800 övre gräns – 10 resursgrupper för de 10 labben själva) = 79 virtuella datorer per labb.
• Om labbet är anslutet till lokalt via Express Route (till exempel) finns det definierade IP-adressutrymmen tillgängliga för det virtuella nätverket/undernätet. För att säkerställa att virtuella datorer i labbet inte misslyckas med att skapas (fel: det går inte att hämta IP-adress) kan labbägare ange maximalt antal virtuella datorer per labb i linje med det tillgängliga IP-adressutrymmet.

Använda Resource Manager-mallar

Distribuera dina Resource Manager-mallar med hjälp av stegen i Använda Azure DevTest Labs för testmiljöer. I grund och botten kontrollerar du dina Resource Manager-mallar i en Azure Repos- eller GitHub Git-lagringsplats och lägger till en privat lagringsplats för dina mallar i labbet.

Det här scenariot kanske inte är användbart om du använder DevTest Labs som värd för utvecklingsdatorer. Använd det här scenariot för att skapa en mellanlagringsmiljö som är representativ för produktion.

Antalet virtuella datorer per labb eller per användare begränsar bara antalet datorer som skapats internt i själva labbet. Det här alternativet begränsar inte skapandet av några miljöer med Resource Manager-mallar.