Ten artykuł zawiera podejście architektury do przygotowania usługi Azure DevTest Labs (DTL lub Lab) w strefie docelowej w skali przedsiębiorstwa (ESLZ) z uwzględnieniem wytycznych projektowych.
Architektura
W architekturze biblioteki DTL w przedsiębiorstwie podstawy platformy są zwykle konfigurowane przez administratora platformy zgodnie z wytycznymi podanymi w witrynie ESLZ na potrzeby scentralizowanej sieci, tożsamości i ładu. Aby uzyskać informacje na temat konfigurowania platformy ESLZ, zobacz Implementowanie stref docelowych w skali przedsiębiorstwa na platformie Azure.
Zespół aplikacji ponosi odpowiedzialność za aprowizowanie podstawowych zasobów DTL w subskrypcjach DevTest, jak pokazano w prawym dolnym rogu poniższego diagramu. W tym celu użyto już skonfigurowanej podstawy. Zasady stosowane do grup zarządzania są przenoszone do subskrypcji i zasobów DevTest.
Chociaż sama biblioteka DTL nie ma wbudowanych limitów, inne zasoby platformy Azure używane w laboratorium mogą wykraczać poza limity subskrypcji platformy Azure. W takich przypadkach może być konieczne użycie wielu subskrypcji platformy Azure w celu pokrycia dużych wdrożeń biblioteki DTL.
Pobierz plik programu Visio z tą architekturą.
Przepływ danych
- Administracja istrator sieci tworzy sieć wirtualną szprychy i inne zasoby sieciowe, takie jak sieciowa grupa zabezpieczeń, trasa zdefiniowana przez użytkownika w sieciowej grupie zasobów, która jest równorzędna z siecią wirtualną koncentratora. Komunikacja równorzędna jest tworzona przez zasady platformy Azure przypisane do grupy zarządzania Corp zgodnie z automatyzacją ESLZ. Ta komunikacja równorzędna umożliwia użytkownikom firmowym dostęp do maszyn wirtualnych laboratorium za pośrednictwem sieci VPN/usługi ExpressRoute przy użyciu prywatnego adresu IP.
- Właściciel laboratorium konfiguruje wbudowane zasady laboratorium zgodnie z wymaganiami projektu. Wszystkie dostępne zasady można przejrzeć w temacie Zarządzanie wszystkimi zasadami dla laboratorium w usłudze Azure DevTest Labs. Oto kilka zasad istotnych dla tego artykułu:
- Skonfiguruj ustawienie sieci wirtualnej, aby wszystkie maszyny wirtualne laboratorium zostały utworzone w sieci wirtualnej będącej szprychą.
- Skonfiguruj ustawienia laboratorium, aby wszystkie maszyny wirtualne laboratorium zostały utworzone w wyznaczonej grupie zasobów laboratorium. W ten sposób nie będą one dystrybuowane między wieloma grupami zasobów.
- Włącz Połączenie przeglądarki, aby użyć hosta usługi Bastion wdrożonego w sieci wirtualnej koncentratora w celu zabezpieczenia dostępu RDP/SSH do maszyn wirtualnych laboratorium za pośrednictwem Internetu bez publicznego adresu IP.
- Skonfiguruj użytkowników laboratorium i przypisz odpowiednie role na podstawie najniższych uprawnień. Funkcja DTL udostępnia trzy wbudowane role: Właściciel, Współautor i Użytkownik.
- Skonfiguruj artefakt przyłączania do domeny jako obowiązkowy artefakt w laboratorium, jeśli istnieje wymóg przyłączenia domeny do maszyny wirtualnej laboratorium.
- Skonfiguruj prywatne repozytorium Github/ADO w laboratorium pod kątem artefaktów i szablonów środowiska. Repozytorium może służyć również do przechowywania bazy kodu aplikacji.
- Zespół ds. aplikacji może ręcznie uruchomić zasoby laboratorium (maszyny wirtualne i środowiska PaaS) lub skonfigurować usługę Azure Pipelines w celu wdrażania zasobów przy użyciu zadań DTL.
Topologia zasobów
W ramach subskrypcji DevTest usprawnianie organizacji grupy zasobów dla laboratoriów zwiększa łatwość utrzymania zasobów. Tradycyjnie w przedsiębiorstwie zasoby związane z siecią są kontrolowane przez administratorów sieci i są odizolowane od zasobów aplikacji przy użyciu oddzielnych grup zasobów.
Zasoby laboratorium można dystrybuować w dwóch grupach zasobów w ramach subskrypcji DevTest, jak pokazano na powyższym diagramie:
- Sieciowa grupa zasobów (rg-network-dtl) zawierająca sieć wirtualną, sieciową grupę zabezpieczeń, trasy. Zasoby sieciowe można udostępniać w wielu laboratoriach w ramach tej samej subskrypcji.
- Grupa zasobów laboratorium (rg-team-lab1) zawierająca podstawowe zasoby laboratorium. Domyślnie DTL tworzy grupę zasobów dla każdej nowej maszyny wirtualnej i jest dobra, jeśli chcesz tej izolacji. Jeśli nie, możesz zmienić tę konfigurację, aby wdrożyć wszystkie maszyny wirtualne w tej samej grupie zasobów. Wiele zespołów może udostępniać bibliotekę DTL lub uruchamiać oddzielną bibliotekę DTL na podstawie wymagań zespołu lub projektu.
Podczas aprowizacji biblioteki DTL następujące zasoby infra są tworzone automatycznie:
- Key Vault: użytkownicy DTL mogą używać usługi KeyVault do przechowywania hasła dla maszyny wirtualnej z systemem Windows, publicznego klucza SSH dla maszyny wirtualnej z systemem Linux lub osobistego tokenu dostępu w celu sklonowania repozytorium Git za pomocą artefaktu.
- Konto magazynu: DTL używa kont magazynu do następujących celów:
- Przechowywanie dokumentów formuł, których można użyć do tworzenia maszyn wirtualnych
- Przechowywanie wyników artefaktów, w tym dzienników wdrażania i rozszerzeń generowanych na podstawie stosowania artefaktów
- Przekazywanie wirtualnych dysków twardych (VHD) w celu utworzenia niestandardowych obrazów w laboratorium
- Buforowanie często używanych artefaktów i szablonów usługi Azure Resource Manager w celu szybszego pobierania podczas tworzenia maszyny wirtualnej i środowiska
- Sieć wirtualna: DTL tworzy domyślną sieć wirtualną, chyba że zostanie udostępniona istniejąca sieć wirtualna. W tej architekturze zalecana jest istniejąca sieć wirtualna szprychy równorzędna z siecią wirtualną piasty.
Elementy
- Strefa docelowa o skali przedsiębiorstwa (ESLZ) to podejście architektoniczne i implementacja referencyjna, która umożliwia efektywne konstruowanie i operacjonalizacja stref docelowych na platformie Azure na dużą skalę. Strefy docelowe platformy Azure to dane wyjściowe środowiska platformy Azure z wieloma subskrypcjami, które odpowiada za skalowanie, zabezpieczenia, ład, sieć i tożsamość. Bibliotekę DTL można wdrożyć w strefie docelowej devTest lub subskrypcji piaskownicy zgodnie z opisem w temacie Zarządzanie grupą i topologią subskrypcji.
- Azure DevTest Labs (DTL) to w pełni zarządzana usługa używana przez deweloperów i testerów do szybkiego aprowizowania środowisk deweloperskich i testowych. Funkcja DTL umożliwia użytkownikom tworzenie maszyn wirtualnych i zasobów PaaS. Chociaż tworzenie maszyny wirtualnej jest obsługiwane natywnie, tworzenie zasobów PaaS można osiągnąć przy użyciu szablonów środowiska.
- Zasady DTL umożliwiają kontrolowanie kosztów i minimalizowanie strat w laboratoriach przez zarządzanie zasadami (ustawieniami) dla każdego laboratorium. Korzystając z zasad DTL, można zminimalizować straty laboratorium, określając, które rozmiary maszyn wirtualnych są dozwolone w laboratorium. Jeśli te zasady są aktywne, tylko rozmiary maszyn wirtualnych z listy mogą służyć do tworzenia maszyn wirtualnych.
- Konfiguracje piasty i szprych zapewniają korzyści, które obejmują oszczędności kosztów, przekroczenie limitów subskrypcji i izolację obciążenia. Sieć wirtualna piasty pełni rolę centralnego punktu łączności z wieloma sieciami wirtualnymi szprych i sieciami lokalnymi. Sieci wirtualne będące szprychami są równorzędne z piastą i mogą służyć do izolowania obciążeń. DTL można umieścić w sieci szprych, aby przedsiębiorstwa mogły mieć centralną kontrolę nad funkcjami zabezpieczeń, takimi jak zapora w centrum jako strefa DMZ, łączność usługi Express Route/VPN i segregowane zarządzanie obciążeniem. Tradycyjnie sieci wirtualne, w tym sieć wirtualna będącej szprychą, są udostępniane przez administratora platformy. Zespół aplikacji może aprowizować bibliotekę DTL w określonej podsieci. Więcej szczegółów znajduje się w temacie Topologia sieci.
- Azure Bastion to w pełni zarządzana usługa, która zapewnia bezpieczniejszy i bezproblemowy dostęp do protokołu RDP (Remote Desktop Protocol) i protokołu SSH (Secure Shell Protocol) do maszyn wirtualnych bez żadnego ujawnienia za pośrednictwem publicznych adresów IP. Usługa DTL może używać hosta bastionu do bezpiecznego połączenia RDP/SSH z maszynami wirtualnymi bez ujawniania ich bezpośrednio przez Internet zgodnie z opisem w temacie Topologia sieci. Domyślnie DTL umożliwia łączność z maszyną wirtualną za pośrednictwem publicznego adresu IP lub udostępnionego publicznego adresu IP.
- Artefakty DTL umożliwiają określenie akcji wykonywanych podczas aprowizowania maszyny wirtualnej, takich jak uruchamianie skryptów programu Windows PowerShell, uruchamianie poleceń powłoki Bash i instalowanie oprogramowania. Parametry artefaktu umożliwiają dostosowanie artefaktu dla danego scenariusza. Publiczne repozytorium artefaktów obsługiwane przez usługę DevTest Labs udostępnia wiele popularnych narzędzi dla systemów Windows i Linux. Link do tego repozytorium jest automatycznie dodawany do laboratorium.
- Formuła w usłudze Azure DevTest Labs to lista domyślnych wartości właściwości używanych do tworzenia maszyny wirtualnej.
- Środowiska DTL umożliwiają użytkownikom wdrażanie złożonych infrastruktur w spójny sposób w obrębie laboratorium. Szablony usługi Azure Resource Manager umożliwiają tworzenie środowisk z zestawami zasobów w usłudze DevTest Labs. Te środowiska mogą zawierać dowolne zasoby platformy Azure, które mogą tworzyć szablony usługi Resource Manager.
Alternatywy
Klienci mogą tworzyć rozwiązanie podobne do usługi DevTest Labs, łącząc wiele usług z funkcjami natywnymi platformy Azure, takimi jak zasady, grupy kontroli dostępu opartej na rolach, rozszerzenia maszyn wirtualnych i automatyzacja.
Główną zaletą korzystania z usługi DevTest Labs jest wbudowana zintegrowana funkcja i intuicyjny interfejs, co ułatwia nowym użytkownikom (Administracja s i deweloperom), którzy nie mają głębokich umiejętności na platformie Azure. W ten sposób DTL oszczędza czas i nakład pracy w implementacji i konserwacji.
Szczegóły scenariusza
Funkcja DTL pomaga deweloperom w zespołach wydajnie samodzielnie zarządzać maszynami wirtualnymi i zasobami PaaS bez oczekiwania na zatwierdzenia, zapewniając bezpłatne samoobsługowe środowisko. Zwiększa to dużą wartość w przypadku kluczowych scenariuszy, szczególnie w przypadku rozpoczynania pracy na platformie Azure, takich jak komputery stacjonarne deweloperów, środowiska testowe, sesje szkoleniowe i badania w trybie piaskownicy. Wbudowane zasady i progi laboratorium pomagają bez wysiłku zmniejszyć koszty. Aby dowiedzieć się więcej na temat podstawowych pojęć dotyczących biblioteki DTL, zobacz Pojęcia dotyczące usługi DevTest Labs.
Ten artykuł zawiera zalecenia dotyczące topologii grupy zarządzania i subskrypcji, sieci, tożsamości, ofert Umowa Enterprise, automatyzacji aplikacji i zabezpieczeń dla obciążeń DevTest w kontekście biblioteki DTL.
Przedsiębiorstwa migrujące obciążenia DevTest na dużą skalę mogą korzystać z konfigurowania tej architektury w skali przedsiębiorstwa i mogą osiągnąć następujące korzyści:
- Zmniejszone obciążenie operacyjne zespołów aplikacji, ponieważ mogą skupić się na tworzeniu/testowaniu aplikacji za pomocą biblioteki DTL i pozostawić wszystkie funkcje zarządzania platformami, sieci, zabezpieczeń i tożsamości za pomocą centralnego zespołu IT.
- Scentralizowane wymuszanie zgodności organizacyjnej w ramach obciążeń DevTest.
Potencjalne przypadki użycia
Ta architektura jest przydatna w przypadku organizacji, które wymagają:
- Od samego początku w pełni zintegrowana płaszczyzna sterowania operacjami dla obciążeń DevTest.
- Wyraźne rozdzielenie problemów między obciążeniami platformy i aplikacji.
Tradycyjnie ta architektura będzie stanowić punkt wyjścia dla wdrożeń obciążeń DevTest na dużą skalę w ramach subskrypcji.
Kwestie wymagające rozważenia
Te zagadnienia implementują filary struktury Azure Well-Architected Framework, która jest zestawem wytycznych, które mogą służyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.
Zabezpieczenia
Zabezpieczenia zapewniają ochronę przed celowymi atakami i nadużyciami cennych danych i systemów. Aby uzyskać więcej informacji, zobacz Omówienie filaru zabezpieczeń.
Ten punkt odniesienia zabezpieczeń stosuje wskazówki z testu porównawczego zabezpieczeń platformy Azure w wersji 2.0 do listy DTL.
Zarządzanie i zgodność
Poniższe linki dotyczą ładu i zgodności biblioteki DTL:
- Odpowiada na zarządzanie zasobami i zarządzanie nimi w usłudze DTL
- Zawiera wskazówki dotyczące zarządzania zasadami firmy i zgodnością infrastruktury DTL
- Zawiera informacje ułatwiające dopasowanie własności do środowiska DTL
- Omówienie ładu związanego z migracją aplikacji i integracją dla biblioteki DTL
Zarządzanie tożsamościami i dostępem
Organizacje przedsiębiorstwa zwykle stosują podejście o najniższych uprawnieniach do dostępu operacyjnego zaprojektowane za pomocą identyfikatora Microsoft Entra ID, kontroli dostępu opartej na rolach (RBAC) platformy Azure i niestandardowych definicji ról. Role RBAC umożliwiają zarządzanie zasobami DTL, takimi jak tworzenie maszyn wirtualnych, tworzenie środowisk i uruchamianie, zatrzymywanie, ponowne uruchamianie, usuwanie i stosowanie artefaktów.
- Dostęp do laboratoriów można skonfigurować tak, aby rozdzielić obowiązki w zespole na różne role. Trzy z tych ról RBAC to Właściciel, Użytkownik usługi DevTest Labs i Współautor. Zasób DTL powinien być własnością tych, którzy rozumieją wymagania dotyczące projektu i zespołu dla budżetu, maszyn i wymaganego oprogramowania. Typowym modelem jest kierownik projektu lub administrator aplikacji jako właściciel laboratorium i członkowie zespołu jako użytkownicy laboratorium. Rolę Współautor można przypisać do członków infrastruktury aplikacji, którzy potrzebują uprawnień do zarządzania zasobami laboratorium. Właściciel laboratorium jest odpowiedzialny za konfigurowanie zasad i dodawanie wymaganych użytkowników do laboratorium.
- W przypadku przedsiębiorstw, które wymagają od użytkowników połączenia z tożsamościami opartymi na domenie, kontroler domeny dodany do subskrypcji platformy może służyć do przyłączania maszyn wirtualnych DTL do domeny. Artefakty DTL umożliwiają automatyczne dołączanie maszyn wirtualnych do domeny. Domyślnie maszyny wirtualne DTL używają konta administratora lokalnego.
- Biblioteka DTL obsługuje tożsamości zarządzane dla swoich zasobów platformy Azure. Użyj tożsamości zarządzanych z funkcją DTL, aby uzyskać dostęp do usługi Key Vault, magazynu oraz do wdrażania maszyn wirtualnych i zasobów PaaS. Przypisz tożsamości zarządzane przypisane przez użytkownika na maszynach wirtualnych laboratorium w usłudze DTL, aby umożliwić użytkownikom laboratorium uzyskiwanie dostępu do zasobów platformy Azure przez użytkowników laboratorium.
Topologia sieci
Organizacje często działają z regionalną topologią sieci piasty i szprych, gdzie piasta i szprychy są wdrażane w oddzielnych sieciach wirtualnych i subskrypcjach są połączone za pośrednictwem komunikacji równorzędnej.
Jak pokazano na powyższym diagramie architektury, zasoby DTL używają istniejących sieci wirtualnych szprych, które są równorzędne z siecią wirtualną piasty. Sieć wirtualna koncentratora, która jest częścią subskrypcji platformy, umożliwia bezpieczną łączność za pośrednictwem dostępu RDP/SSH do:
- Maszyny wirtualne DTL korzystające z prywatnego adresu IP dla użytkowników wewnętrznych za pośrednictwem sieci VPN/ER. Połączenie ivity do środowisk lokalnych jest również wymagany w scenariuszach aplikacji hybrydowych, w których niektóre z wymaganych składników są nadal lokalne, takie jak baza danych i domena usługi Active Directory.
- Maszyny wirtualne DTL korzystające z prywatnego adresu IP dla użytkowników zewnętrznych za pośrednictwem hosta usługi Bastion przez Internet. Organizacje mogą również skonfigurować bramę pulpitu zdalnego w usłudze DTL zamiast używać tradycyjnego połączenia RDP przez Internet, jeśli nie wolą łączyć się za pośrednictwem przeglądarki za pośrednictwem usługi Bastion.
Projekt piasty i szprych pomaga zminimalizować bezpośrednie narażenie zasobów DTL na publiczny Internet, zapewnia izolację obciążeń i sprawia, że architektura jest rozszerzalna. Niektóre zasoby, takie jak zapora i dns, mogą być współużytkowane w sieciach szprych.
DTL zapewnia również możliwość bezpośredniego łączenia się z maszynami wirtualnymi za pośrednictwem publicznego adresu IP lub udostępnionego adresu IP , jeśli jest to dozwolone przez zgodność organizacji.
Optymalizacja kosztów
Optymalizacja kosztów dotyczy sposobów zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Omówienie filaru optymalizacji kosztów.
- Sama usługa Azure DevTest Labs jest bezpłatna. Jednak koszty są przypisywane innym zasobom platformy Azure utworzonym w laboratorium, takim jak magazyn, usługa Key Vault i maszyny wirtualne. Szczegóły cennika są dostępne w cenniku usługi Azure DevTest Labs. Możesz również użyć kalkulatora kosztów platformy Azure, aby oszacować koszt.
- Link zawiera informacje na temat sposobu, w jaki wbudowane funkcje usługi DevTest Labs ułatwiają optymalizowanie, śledzenie i kontrolowanie kosztów.
- Optymalizowanie kosztów przy użyciu zasad
- Śledzenie i kontrolowanie kosztów
- Dalsze optymalizowanie kosztów dzięki korzyściom devTest
- Dobrze zaprojektowana struktura platformy Azure zawiera wskazówki dotyczące zarządzania kosztami w celu zmaksymalizowania dostarczonej wartości
Umowa Enterprise dla metodyki DevTest
Umowa Enterprise klienci mają doskonały sposób uruchamiania obciążeń programistycznych i testowych na platformie Azure przez zarejestrowanie się w celu uzyskania niższych stawek dla obciążeń deweloperskich/testowych zgodnie z opisem w temacie Enterprise — tworzenie i testowanie. Włączenie subskrypcji DevTest w witrynie Azure Enterprise Portal umożliwia organizacji:
- Uruchamianie systemów operacyjnych klienta, które nie są zwykle dostępne w subskrypcji przedsiębiorstwa platformy Azure
- Korzystanie z oprogramowania przedsiębiorstwa, w którym płaci tylko za obliczenia
- Poczucie pewności co do licencjonowania
Doskonałość operacyjna
Doskonałość operacyjna obejmuje procesy operacyjne, które wdrażają aplikację i działają w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Omówienie filaru doskonałości operacyjnej.
Application Automation i DevOps
W kontekście biblioteki DTL automatyzacja obejmuje:
- Inicjowanie obsługi administracyjnej wystąpienia biblioteki DTL. Spójne i powtarzalne wdrażanie biblioteki DTL z zasadami przy użyciu szablonów ARM/Bicep przechowywanych w repozytorium GIT. Automatyzację można osiągnąć za pomocą dowolnej platformy ciągłej integracji/ciągłego wdrażania.
- Aprowizowanie zasobów w usłudze DTL przy użyciu usługi Azure DevOps. Automatyzacja za pomocą rozszerzenia witryny Azure Pipelines Marketplace, zadań usługi Azure DevTest Labs w celu tworzenia i usuwania maszyn wirtualnych laboratorium, obrazów niestandardowych i środowisk.
- Aprowizowanie artefaktów i środowisk PaaS za pomocą wbudowanej automatyzacji DTL. Skonfiguruj prywatne repozytorium niestandardowe (ADO lub GitHub) w laboratorium lub użyj zawartości repozytorium Community usługi Azure Lab Services dostępnej do przechowywania i automatyzowania artefaktów i szablonów środowiska.
Istnieje wiele innych sposobów automatyzowania usług Azure i DevTest Labs, w tym interfejsów API REST, programu PowerShell, interfejsu wiersza polecenia platformy Azure i zestawu Azure SDK.
Integracja biblioteki DTL z usługą Azure DevOps na potrzeby programowania i operacji została opisana w temacie Integrowanie usług Azure DevTest Labs i Azure DevOps. Ponadto centrum architektury platformy Azure zawiera artykuł dotyczący metodyki DevTest i DevOps dla IaaS.
Topologia grupy zarządzania i subskrypcji
Dobrze zaprojektowana topologia grup zarządzania i subskrypcji wraz ze strukturą organizacyjną i wymaganiami dotyczącymi zgodności zapewnia odpowiednią izolację oraz maksymalną elastyczność przyszłego rozwoju. Konfiguracja grupy zarządzania i subskrypcji to właściciel platformy, który zapewnia wymagany dostęp do administratora aplikacji lub właściciela laboratorium w celu aprowizacji laboratorium.
Jak pokazano na powyższym diagramie architektury, zespoły aplikacji mogą wdrażać bibliotekę DTL w subskrypcji w ramach grupy zarządzania strefą docelową lub grupy zarządzania piaskownicą w oparciu o następujące kilka punktów decyzyjnych:
- Jeśli globalna zgodność organizacji zdefiniowana w grupie zarządzania strefą docelową jest prawidłowa dla obciążeń DevTest, można wdrożyć bibliotekę DTL w subskrypcji strefy docelowej nieprodukcyjnej w ramach grupy zarządzania Corp lub Online na podstawie wymagania dotyczącego łączności ze środowiskiem lokalnym. W takim przypadku wszystkie zasady platformy Azure stosowane do grup zarządzania strefy docelowej pod kątem zgodności będą dziedziczone przez wszystkie subskrypcje w ramach tej usługi. Obejmuje to zasoby DTL wraz ze skonfigurowanymi przez administratora zasadami.
- Bibliotekę DTL można również skonfigurować w środowisku piaskownicy na potrzeby eksploracji, trenowania i badania. W takim przypadku można wdrożyć bibliotekę DTL w subskrypcji w ramach grupy zarządzania piaskownicą, która ma minimalne ograniczenia i umożliwia użytkownikom swobodę eksplorowania.
Współautorzy
Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.
Główny autor:
- Vidya Narasimhan | Starszy architekt rozwiązań w chmurze
Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.
Następne kroki
- Aby uzyskać wskazówki dotyczące konfigurowania strefy docelowej w skali przedsiębiorstwa, zobacz Implementowanie stref docelowych w skali przedsiębiorstwa.
- Ustanowienie początkowej topologii i projektu sieci pokazuje, jak szybko wdrożyć usługę Azure DevTest Labs.