Zarządzanie infrastrukturą usługi Azure DevTest Labs

Ten artykuł dotyczy wyrównania zasobów usługi DevTest Labs i zarządzania nimi w organizacji.

Zasoby

Dostosowywanie zasobów usługi DevTest Labs w ramach subskrypcji platformy Azure

Zanim organizacja zacznie używać platformy Azure do ogólnego tworzenia aplikacji, planiści IT powinni najpierw przejrzeć sposób wprowadzenia możliwości w ramach ogólnego portfolio usług. Obszary do przeglądu powinny rozwiązać następujące problemy:

• Jak zmierzyć koszt związany z cyklem życia tworzenia aplikacji?
• W jaki sposób organizacja dostosowuje proponowaną ofertę usług do zasad zabezpieczeń firmowych?
• Czy segmentacja jest wymagana do oddzielenia środowisk deweloperskich i produkcyjnych?
• Jakie mechanizmy kontroli są wprowadzane w celu zapewnienia długoterminowej łatwości zarządzania, stabilności i wzrostu?

Pierwszą zalecaną praktyką jest przejrzenie taksonomii platformy Azure organizacji, w której opisano podziały między subskrypcjami produkcyjnymi i deweloperskimi. Na poniższym diagramie sugerowana taksonomia umożliwia logiczne rozdzielenie środowisk programistycznych/testowych i produkcyjnych. Dzięki takiemu podejściu organizacja może wprowadzać kody rozliczeniowe do śledzenia kosztów skojarzonych z poszczególnymi środowiskami oddzielnie. Aby uzyskać więcej informacji, zobacz Preskrypcyjny ład subskrypcji. Ponadto możesz użyć tagów platformy Azure do organizowania zasobów na potrzeby śledzenia i rozliczeń.

Drugą zalecaną praktyką jest włączenie subskrypcji DevTest w witrynie Azure Enterprise Portal. Umożliwia to organizacji uruchamianie systemów operacyjnych klienta, które nie są zwykle dostępne w subskrypcji przedsiębiorstwa platformy Azure. Następnie użyj oprogramowania dla przedsiębiorstw, w którym płacisz tylko za obliczenia i nie martw się o licencjonowanie. Gwarantuje to, że rozliczenia dla wyznaczonych usług, w tym obrazów galerii w usłudze IaaS, takich jak program Microsoft SQL Server, są oparte tylko na użyciu. Szczegółowe informacje na temat subskrypcji Azure DevTest można znaleźć tutaj dla klientów Umowa Enterprise (EA) i tutaj w przypadku klientów z płatnością zgodnie z rzeczywistym użyciem.

Ten model zapewnia organizacji elastyczność wdrażania usługi Azure DevTest Labs na dużą skalę. Organizacja może obsługiwać setki laboratoriów dla różnych jednostek biznesowych z 100 do 1000 maszyn wirtualnych działających równolegle. Promuje pojęcie scentralizowanego rozwiązania laboratorium przedsiębiorstwa, które może współdzielić te same zasady zarządzania konfiguracją i mechanizmów kontroli zabezpieczeń.

Ten model zapewnia również, że organizacja nie wyczerpała limitów zasobów skojarzonych z subskrypcją platformy Azure. Aby uzyskać szczegółowe informacje na temat limitów subskrypcji i usług, zobacz Limity, przydziały i ograniczenia subskrypcji i usług platformy Azure. Proces aprowizacji usługi DevTest Labs może zużywać dużą liczbę grup zasobów. Możesz poprosić o zwiększenie limitów za pośrednictwem żądania pomocy technicznej w subskrypcji Azure DevTest. Zasoby w ramach subskrypcji produkcyjnej nie mają wpływu, ponieważ subskrypcja deweloperów rośnie w użyciu. Aby uzyskać więcej informacji na temat skalowania usługi DevTest Labs, zobacz Skalowanie przydziałów i limitów w usłudze DevTest Labs.

Typowym limitem poziomu subskrypcji, który należy uwzględnić, jest sposób przydzielania przypisań zakresu adresów IP sieci do obsługi subskrypcji produkcyjnych i deweloperskich. Te przypisania powinny uwzględniać wzrost w czasie (przy założeniu łączności lokalnej lub innej topologii sieci, która wymaga od przedsiębiorstwa zarządzania stosem sieciowym zamiast domyślnej implementacji platformy Azure). Zalecaną praktyką jest posiadanie kilku sieci wirtualnych, które mają przypisany duży prefiks adresu IP i są podzielone z wieloma dużymi podsieciami, a nie z wieloma sieciami wirtualnymi z małymi podsieciami. Na przykład w przypadku 10 subskrypcji można zdefiniować 10 sieci wirtualnych (po jednym dla każdej subskrypcji). Wszystkie laboratoria, które nie wymagają izolacji, mogą współużytkować tę samą podsieć w sieci wirtualnej subskrypcji.

Liczba użytkowników na laboratoria i laboratoria na organizację

Jednostki biznesowe i grupy deweloperskie skojarzone z tym samym projektem programistycznym powinny być skojarzone z tym samym laboratorium. Umożliwia zastosowanie tych samych typów zasad, obrazów i zasad zamykania do obu grup.

Może być również konieczne rozważenie granic geograficznych. Na przykład deweloperzy w północno-wschodniej Stany Zjednoczone (USA) mogą używać laboratorium aprowizowania w regionie Wschodnie stany USA 2. Deweloperzy w Dallas, Teksasie i Denver mogą być kierowani do korzystania z zasobu w południowo-środkowym usa. Jeśli istnieje współpraca z zewnętrzną stroną zewnętrzną, może zostać przypisana do laboratorium, które nie jest używane przez deweloperów wewnętrznych.

Możesz również użyć laboratorium dla określonego projektu w usłudze Azure DevOps Projects. Następnie stosujesz zabezpieczenia za pośrednictwem określonej grupy Microsoft Entra, która umożliwia dostęp do obu zestawów zasobów. Sieć wirtualna przypisana do laboratorium może być kolejną granicą konsolidowania użytkowników.

Zapobieganie usuwaniu zasobów

Ustaw uprawnienia na poziomie laboratorium, aby tylko autoryzowani użytkownicy mogli usuwać zasoby lub zmieniać zasady laboratorium. Deweloperzy powinni zostać umieszczeni w grupie Użytkownicy usługi DevTest Labs. Główny deweloper lub główny lider infrastruktury powinien być właścicielem usługi DevTest Labs. Zalecamy, aby mieć tylko dwóch właścicieli laboratorium. Te zasady rozszerzają się na repozytorium kodu, aby uniknąć uszkodzenia. W laboratorium są używane prawa do używania zasobów, ale nie można zaktualizować zasad laboratorium. Zapoznaj się z następującym artykułem, który zawiera listę ról i praw, które każda wbudowana grupa ma w laboratorium: Dodawanie właścicieli i użytkowników w usłudze Azure DevTest Labs.

Zarządzanie kosztami i własnością

Koszty i własność są podstawowymi problemami, które należy wziąć pod uwagę podczas tworzenia środowisk programistycznych i testowych. W tej sekcji znajdziesz informacje ułatwiające optymalizację kosztów i wyrównanie własności w całym środowisku.

Optymalizowanie pod kątem kosztów

Kilka wbudowanych funkcji usługi DevTest Labs ułatwia optymalizację pod kątem kosztów. Zobacz artykuły dotyczące zarządzania kosztami, progów i zasad , aby ograniczyć działania użytkowników.

Jeśli używasz usługi DevTest Labs na potrzeby obciążeń programistycznych i testowych, rozważ użycie korzyści z subskrypcji Tworzenie i testowanie w przedsiębiorstwie, która jest częścią Umowa Enterprise. Lub jeśli jesteś klientem z płatnością zgodnie z rzeczywistym użyciem, rozważ ofertę Usługi DevTest z płatnością zgodnie z rzeczywistym użyciem.

Takie podejście zapewnia kilka zalet:

• Specjalne niższe stawki za tworzenie i testowanie na maszynach wirtualnych z systemem Windows, usługach w chmurze, usłudze HDInsight, usłudze App Service i usłudze Logic Apps
• Doskonałe stawki Umowa Enterprise (EA) w innych usługach platformy Azure
• Dostęp do specjalnych obrazów na potrzeby tworzenia/testowania w galerii, w tym obrazów systemu Windows 8.1 i Windows 10

Tylko aktywni subskrybenci programu Visual Studio (subskrypcje standardowe, roczne subskrypcje w chmurze i miesięczne subskrypcje w chmurze) mogą używać zasobów platformy Azure działających w ramach subskrypcji tworzenia i testowania przedsiębiorstwa. Jednak użytkownicy końcowi mogą uzyskiwać dostęp do aplikacji w celu przekazywania opinii lub testowania akceptacyjnego. Zasoby w ramach tej subskrypcji można używać tylko do tworzenia i testowania aplikacji. Nie ma gwarancji czasu pracy.

Jeśli zdecydujesz się korzystać z oferty DevTest, skorzystaj z tej korzyści wyłącznie na potrzeby tworzenia i testowania aplikacji. Użycie w ramach subskrypcji nie ma objętej finansowo umową SLA, z wyjątkiem korzystania z usług Azure DevOps i HockeyApp.

Definiowanie dostępu opartego na rolach w organizacji

Centralny zespół IT powinien posiadać tylko to, co jest niezbędne, i umożliwić zespołom projektu i aplikacji posiadanie wymaganego poziomu kontroli. Zazwyczaj oznacza to, że centralny zespół IT jest właścicielem subskrypcji i obsługuje podstawowe funkcje IT, takie jak konfiguracje sieci. Zestaw właścicieli subskrypcji powinien być mały. Ci właściciele mogą nominować innych właścicieli, gdy jest potrzebna, lub stosować zasady na poziomie subskrypcji, na przykład "Brak publicznego adresu IP".

Może istnieć podzbiór użytkowników, którzy wymagają dostępu w ramach subskrypcji, takiej jak obsługa warstwy 1 lub warstwa 2. W takim przypadku zalecamy nadanie tym użytkownikom dostępu współautora , aby mogli zarządzać zasobami, ale nie zapewniać dostępu użytkowników ani dostosowywać zasad.

Właściciele zasobów usługi DevTest Labs powinni być blisko zespołu ds. projektu lub aplikacji. Właściciele ci rozumieją wymagania dotyczące maszyn i oprogramowania. W większości organizacji właścicielem zasobu usługi DevTest Labs jest kierownik projektu lub programowania. Ten właściciel może zarządzać użytkownikami i zasadami w środowisku laboratoryjnym oraz zarządzać wszystkimi maszynami wirtualnymi w środowisku usługi DevTest Labs.

Dodaj członków zespołu ds. projektu i aplikacji do roli Użytkownicy usługi DevTest Labs. Ci użytkownicy mogą tworzyć maszyny wirtualne zgodnie z zasadami na poziomie laboratorium i subskrypcji. Użytkownicy mogą również zarządzać własnymi maszynami wirtualnymi, ale nie mogą zarządzać maszynami wirtualnymi należącymi do innych użytkowników.

Aby uzyskać więcej informacji, zobacz Szkielet przedsiębiorstwa platformy Azure — nakazowy ład subskrypcji.

Zasady i zgodność firmy

Ta sekcja zawiera wskazówki dotyczące zarządzania zasadami firmy i zgodnością infrastruktury usługi Azure DevTest Labs.

Repozytorium artefaktów publicznych i prywatnych

Publiczne repozytorium artefaktów udostępnia początkowy zestaw pakietów oprogramowania, które są najczęściej używane. Pomaga to w szybkim wdrażaniu bez konieczności poświęcania czasu na odtworzenie typowych narzędzi deweloperskich i dodatków. Możesz wybrać wdrożenie własnego repozytorium prywatnego. Możesz użyć publicznego i prywatnego repozytorium równolegle. Możesz również wyłączyć repozytorium publiczne. Kryteria wdrażania repozytorium prywatnego powinny być oparte na następujących pytaniach i zagadnieniach:

• Czy organizacja musi mieć licencjonowane oprogramowanie firmowe w ramach oferty DevTest Labs? Jeśli odpowiedź brzmi tak, należy utworzyć repozytorium prywatne.
• Czy organizacja opracowuje niestandardowe oprogramowanie, które zapewnia określoną operację, która jest wymagana w ramach ogólnego procesu aprowizacji? Jeśli odpowiedź brzmi tak, należy wdrożyć prywatne repozytorium.
• Jeśli zasady ładu organizacji wymagają izolacji, a repozytoria zewnętrzne nie są objęte bezpośrednim zarządzaniem konfiguracją przez organizację, należy wdrożyć prywatne repozytorium artefaktów. W ramach tego procesu można skopiować i zintegrować początkową kopię repozytorium publicznego z repozytorium prywatnym. Następnie można wyłączyć repozytorium publiczne, aby nikt w organizacji nie mógł już uzyskać do niego dostępu. Takie podejście wymusza, aby wszyscy użytkownicy w organizacji mieli tylko jedno repozytorium zatwierdzone przez organizację i zminimalizować dryf konfiguracji.

Pojedyncze repozytorium lub wiele repozytoriów

W ramach ogólnej strategii zarządzania ładem i konfiguracją organizacji zalecamy użycie scentralizowanego repozytorium. W przypadku korzystania z wielu repozytoriów mogą one stać się silosami niezarządzanego oprogramowania w czasie. Dzięki centralnej repozytorium wiele zespołów może korzystać z artefaktów z tego repozytorium dla swoich projektów. Wymusza standaryzację, bezpieczeństwo, łatwość zarządzania i eliminuje duplikowanie wysiłków. W ramach centralizacji zalecane są następujące działania dotyczące długoterminowego zarządzania i zrównoważonego rozwoju:

• Skojarz usługę Azure Repos z tą samą dzierżawą firmy Microsoft Entra, która jest używana przez subskrypcję platformy Azure na potrzeby uwierzytelniania i autoryzacji.
• Utwórz grupę o nazwie Wszyscy deweloperzy usługi DevTest Labs w identyfikatorze Entra firmy Microsoft, która jest centralnie zarządzana. Każdy deweloper, który przyczynia się do tworzenia artefaktów, powinien zostać umieszczony w tej grupie.
• Tej samej grupy Firmy Microsoft Entra można użyć do zapewnienia dostępu do repozytorium Azure Repos i do laboratorium.
• W usłudze Azure Repos rozgałęzianie lub rozwidlenie powinno być używane do oddzielnego repozytorium w środowisku deweloperskim z podstawowego repozytorium produkcyjnego. Zawartość jest dodawana tylko do gałęzi głównej z żądaniem ściągnięcia po odpowiednim przeglądzie kodu. Gdy recenzent kodu zatwierdzi zmianę, główny deweloper, który jest odpowiedzialny za konserwację gałęzi głównej, scala zaktualizowany kod.

Zasady zabezpieczeń firmy

Organizacja może stosować firmowe zasady zabezpieczeń, wykonując następujące działania:

• Opracowywanie i publikowanie kompleksowych zasad zabezpieczeń. Zasady określa reguły dopuszczalnego użycia skojarzone z używaniem oprogramowania, zasobów w chmurze. Definiuje również, co wyraźnie narusza zasady.
• Tworzenie niestandardowego obrazu, artefaktów niestandardowych i procesu wdrażania, który umożliwia aranżację w obszarze zabezpieczeń zdefiniowanym za pomocą usługi Active Directory. Takie podejście wymusza granicę korporacyjną i określa wspólny zestaw mechanizmów kontroli środowiska. Te mechanizmy kontroli w środowisku, które deweloper może wziąć pod uwagę podczas opracowywania i wykonywania bezpiecznego cyklu projektowania w ramach ogólnego procesu. Celem jest również zapewnienie środowiska, które nie jest nadmiernie restrykcyjne, które może utrudniać rozwój, ale rozsądny zestaw kontroli. Zasady grupy w jednostce organizacyjnej zawierającej maszyny wirtualne laboratorium mogą być podzbiorem całkowitych zasad grupy znalezionych w środowisku produkcyjnym. Alternatywnie mogą one być kolejnym zestawem, aby prawidłowo ograniczyć wszelkie zidentyfikowane zagrożenia.

Integralność danych

Organizacja może zapewnić integralność danych, aby upewnić się, że deweloperzy zdalni nie mogą usuwać kodu ani wprowadzać złośliwego oprogramowania ani niezatwierdzonego oprogramowania. Istnieje kilka warstw kontroli w celu ograniczenia zagrożenia ze strony zewnętrznych konsultantów, wykonawców lub pracowników komunikacji w celu współpracy w usłudze DevTest Labs.

Jak wspomniano wcześniej, pierwszy krok musi mieć zaakceptowane zasady użytkowania opracowane i zdefiniowane, które wyraźnie określają konsekwencje, gdy ktoś narusza politykę.

Pierwszą warstwą kontroli dostępu zdalnego jest zastosowanie zasad dostępu zdalnego za pośrednictwem połączenia sieci VPN, które nie jest bezpośrednio połączone z laboratorium.

Druga warstwa kontrolek polega na zastosowaniu zestawu obiektów zasad grupy, które uniemożliwiają kopiowanie i wklejanie za pośrednictwem pulpitu zdalnego. Zasady sieci można zaimplementować, aby nie zezwalać na wychodzące usługi ze środowiska, takie jak usługi FTP i RDP z środowiska. Routing zdefiniowany przez użytkownika może wymusić powrót całego ruchu sieciowego platformy Azure do środowiska lokalnego, ale routing nie może uwzględniać wszystkich adresów URL, które mogą zezwalać na przekazywanie danych, chyba że jest kontrolowany za pośrednictwem serwera proxy do skanowania zawartości i sesji. Publiczne adresy IP mogą być ograniczone w sieci wirtualnej obsługującej usługę DevTest Labs, aby nie zezwalać na mostkowanie zewnętrznego zasobu sieciowego.

Ostatecznie należy zastosować te same ograniczenia w całej organizacji, co wymagałoby również uwzględnienia wszystkich możliwych metod nośnika wymiennego lub zewnętrznych adresów URL, które mogłyby zaakceptować wpis zawartości. Skontaktuj się z specjalistą ds. zabezpieczeń, aby przejrzeć i wdrożyć zasady zabezpieczeń. Aby uzyskać więcej zaleceń, zobacz Microsoft Cyber Security.

Migrowanie i integracja aplikacji

Po ustanowieniu środowiska laboratorium programistycznego/testowego należy zastanowić się nad następującymi pytaniami:

• Jak używasz środowiska w zespole projektu?
• Jak upewnić się, że są zgodne z wymaganymi zasadami organizacyjnymi i zachować elastyczność, aby dodać wartość do aplikacji?

Obrazy witryny Azure Marketplace a obrazy niestandardowe

Witryna Azure Marketplace powinna być używana domyślnie, chyba że masz określone obawy lub wymagania organizacyjne. Oto niektóre typowe przykłady:

• Złożona konfiguracja oprogramowania, która wymaga dołączenia aplikacji jako części obrazu podstawowego.
• Instalacja i instalacja aplikacji może potrwać wiele godzin, co nie jest efektywnym wykorzystaniem czasu obliczeniowego do dodania na obrazie witryny Azure Marketplace.
• Deweloperzy i testerzy wymagają szybkiego dostępu do maszyny wirtualnej i chcą zminimalizować czas instalacji nowej maszyny wirtualnej.
• Warunki zgodności lub przepisów (na przykład zasady zabezpieczeń), które muszą być spełnione dla wszystkich maszyn.

Rozważ uważnie użycie obrazów niestandardowych. Obrazy niestandardowe wprowadzają dodatkową złożoność, ponieważ teraz musisz zarządzać plikami VHD dla tych podstawowych obrazów podstawowych. Należy również rutynowo zastosować poprawki tych obrazów podstawowych za pomocą aktualizacji oprogramowania. Te aktualizacje obejmują nowe aktualizacje systemu operacyjnego i wszelkie aktualizacje lub zmiany konfiguracji wymagane dla samego pakietu oprogramowania.

Formuła a obraz niestandardowy

Zazwyczaj decydującym czynnikiem w tym scenariuszu jest koszt i ponowne użycie.

Możesz obniżyć koszty, tworząc obraz niestandardowy, jeśli:

• Wielu użytkowników lub laboratoriów wymaga obrazu.
• Wymagany obraz zawiera wiele oprogramowania na podstawie obrazu podstawowego.

To rozwiązanie oznacza, że obraz jest tworzony raz. Obraz niestandardowy skraca czas instalacji maszyny wirtualnej. Podczas instalacji nie są naliczane koszty związane z uruchamianiem maszyny wirtualnej.

Innym czynnikiem jest częstotliwość zmian pakietu oprogramowania. Jeśli uruchamiasz codzienne kompilacje i wymagasz, aby oprogramowanie było na maszynach wirtualnych użytkowników, rozważ użycie formuły zamiast obrazu niestandardowego.

Wzorce konfigurowania konfiguracji sieci

Jeśli upewnisz się, że tworzenie i testowanie maszyn wirtualnych nie może nawiązać połączenia z publicznym Internetem, należy wziąć pod uwagę dwa aspekty — ruch przychodzący i wychodzący.

Ruch przychodzący — jeśli maszyna wirtualna nie ma publicznego adresu IP, internet nie może nawiązać z nim połączenia. Typowym podejściem jest ustawienie zasad na poziomie subskrypcji, których żaden użytkownik nie może utworzyć publicznego adresu IP.

Ruch wychodzący — jeśli chcesz uniemożliwić maszynom wirtualnym przejście bezpośrednio do publicznego Internetu i wymusić ruch przez zaporę firmową, możesz kierować ruch lokalnie za pośrednictwem usługi Azure ExpressRoute lub sieci VPN przy użyciu routingu wymuszonego.

Uwaga

Jeśli masz serwer proxy, który blokuje ruch bez ustawień serwera proxy, nie zapomnij dodać wyjątków do konta magazynu artefaktów laboratorium, .

Można również użyć sieciowych grup zabezpieczeń dla maszyn wirtualnych lub podsieci. Ten krok dodaje kolejną warstwę ochrony w celu zezwalania na ruch lub blokowania go.

Nowa a istniejąca sieć wirtualna

Jeśli maszyny wirtualne muszą korzystać z istniejącej infrastruktury, należy rozważyć użycie istniejącej sieci wirtualnej w środowisku usługi DevTest Labs. Jeśli używasz usługi ExpressRoute, zminimalizuj liczbę sieci wirtualnych i podsieci, aby nie fragmentować przestrzeni adresów IP przypisanej do subskrypcji. Rozważ również użycie wzorca komunikacji równorzędnej sieci wirtualnych w tym miejscu (model piasty i szprych). Takie podejście umożliwia komunikację sieci wirtualnej i podsieci między subskrypcjami w danym regionie.

Każde środowisko usługi DevTest Labs może mieć własną sieć wirtualną, ale istnieją limity liczby sieci wirtualnych na subskrypcję. Wartość domyślna to 50, chociaż ten limit można podnieść do 100.

Udostępniony, publiczny lub prywatny adres IP

Jeśli używasz sieci VPN typu lokacja-lokacja lub usługi Express Route, rozważ użycie prywatnych adresów IP, aby maszyny były dostępne za pośrednictwem sieci wewnętrznej i niedostępne za pośrednictwem publicznego Internetu.

Uwaga

Właściciele laboratoriów mogą zmienić te zasady podsieci, aby upewnić się, że nikt przypadkowo nie tworzy publicznych adresów IP dla swoich maszyn wirtualnych. Właściciel subskrypcji powinien utworzyć zasady subskrypcji uniemożliwiające tworzenie publicznych adresów IP.

W przypadku korzystania z udostępnionych publicznych adresów IP maszyny wirtualne w laboratorium współużytkuje publiczny adres IP. Takie podejście może być przydatne, gdy musisz uniknąć naruszenia limitów dotyczących publicznych adresów IP dla danej subskrypcji.

Limity laboratorium

Istnieje kilka limitów laboratorium, o których należy pamiętać. Te limity opisano w poniższych sekcjach.

Limity laboratoriów na subskrypcję

Nie ma określonego limitu liczby laboratoriów, które można utworzyć na subskrypcję. Jednak ilość zasobów używanych w ramach subskrypcji jest ograniczona. Możesz dowiedzieć się więcej o limitach i limitach przydziałów dla subskrypcji platformy Azure oraz o sposobie zwiększania tych limitów.

Limity maszyn wirtualnych na laboratorium

Nie ma określonego limitu liczby maszyn wirtualnych, które można utworzyć na laboratorium. Jednak zasoby (rdzenie maszyn wirtualnych, publiczne adresy IP itd.), które są używane, są ograniczone na subskrypcję. Możesz dowiedzieć się więcej o limitach i limitach przydziałów dla subskrypcji platformy Azure oraz o sposobie zwiększania tych limitów.

Limity liczby maszyn wirtualnych na użytkownika lub laboratorium

W przypadku rozważenia liczby maszyn wirtualnych na użytkownika lub laboratorium istnieją trzy główne kwestie:

• Całkowity koszt , który zespół może wydać na zasoby w laboratorium. Łatwo jest uruchomić wiele maszyn. Aby kontrolować koszty, jednym z mechanizmów jest ograniczenie liczby maszyn wirtualnych na użytkownika lub na laboratorium
• Łączna liczba maszyn wirtualnych w laboratorium ma wpływ na dostępne limity przydziału na poziomie subskrypcji. Jednym z górnych limitów jest 800 grup zasobów na subskrypcję. Usługa DevTest Labs obecnie tworzy nową grupę zasobów dla każdej maszyny wirtualnej (chyba że są używane udostępnione publiczne adresy IP). Jeśli w ramach subskrypcji istnieje 10 laboratoriów, laboratoria mogą zmieścić około 79 maszyn wirtualnych w każdym laboratorium (800 wyższej granicy — 10 grup zasobów dla samych 10 laboratoriów) = 79 maszyn wirtualnych na laboratorium.
• Jeśli laboratorium jest połączone ze środowiskiem lokalnym za pośrednictwem usługi Express Route (na przykład), istnieją zdefiniowane przestrzenie adresowe IP dostępne dla sieci wirtualnej/podsieci. Aby upewnić się, że nie można utworzyć maszyn wirtualnych w laboratorium (błąd: nie można uzyskać adresu IP), właściciele laboratoriów mogą określić maksymalną liczbę maszyn wirtualnych na laboratorium dopasowane do dostępnej przestrzeni adresowej IP.

Korzystanie z szablonów usługi Resource Manager

Wdróż szablony usługi Resource Manager, wykonując kroki opisane w artykule Używanie usługi Azure DevTest Labs dla środowisk testowych. Zasadniczo sprawdzasz szablony usługi Resource Manager w repozytorium Git Usługi Azure Repos lub GitHub, a następnie dodasz prywatne repozytorium szablonów do laboratorium.

Ten scenariusz może nie być przydatny, jeśli używasz usługi DevTest Labs do hostowania maszyn deweloperskich. Użyj tego scenariusza, aby utworzyć środowisko przejściowe, które jest reprezentatywne dla środowiska produkcyjnego.

Liczba maszyn wirtualnych na laboratorium lub na użytkownika ogranicza tylko liczbę maszyn utworzonych natywnie w samym laboratorium. Ta opcja nie ogranicza tworzenia przez żadne środowiska przy użyciu szablonów usługi Resource Manager.