Skalowanie w górę infrastruktury usługi Azure DevTest Labs

Organizowanie pomyślnej implementacji usługi DevTest Labs w skali przedsiębiorstwa wymaga rozważenia kluczowych punktów decyzyjnych i zaplanowania podejścia do szybkiego wdrażania i wdrażania usługi Azure DevTest Labs.

W tym artykule opisano kluczowe kwestie decyzyjne, które należy wziąć pod uwagę podczas planowania implementacji, i przedstawiono zalecane podejście do wdrożenia.

Kluczowe punkty decyzyjne

Przed wdrożeniem usługi DevTest Labs w skali przedsiębiorstwa istnieje kilka kluczowych punktów decyzyjnych. Zrozumienie tych punktów decyzyjnych na wysokim poziomie pomaga organizacji w podejmowaniu decyzji projektowych w przyszłości. Jednak te punkty nie powinny powstrzymać organizacji od rozpoczęcia weryfikacji koncepcji.

Trzy najważniejsze obszary do początkowego planowania skalowania w górę to:

• Sieć i zabezpieczenia
• Topologia subskrypcji
• Role i obowiązki

Sieć i zabezpieczenia

Sieci i zabezpieczenia są podstawą dla wszystkich organizacji. Chociaż wdrożenie w całym przedsiębiorstwie wymaga znacznie dokładniejszej analizy, istnieje ograniczona liczba wymagań, aby pomyślnie zrealizować weryfikację koncepcji. Oto kilka kluczowych obszarów zainteresowania:

• Subskrypcja platformy Azure — aby wdrożyć usługę DevTest Labs, musisz mieć dostęp do subskrypcji platformy Azure z odpowiednimi uprawnieniami do tworzenia zasobów. Istnieje kilka sposobów uzyskiwania dostępu do subskrypcji platformy Azure, w tym Umowa Enterprise i płatności zgodnie z rzeczywistym użyciem. Aby uzyskać więcej informacji na temat uzyskiwania dostępu do subskrypcji platformy Azure, zobacz Licencjonowanie platformy Azure dla przedsiębiorstwa.
• Dostęp do zasobów lokalnych — niektóre organizacje wymagają dostępu do zasobów lokalnych w usłudze DevTest Labs. Potrzebujesz bezpiecznego połączenia ze środowiska lokalnego na platformę Azure. Ważne jest skonfigurowanie i skonfigurowanie połączenia sieci VPN lub usługi Azure ExpressRoute przed rozpoczęciem pracy. Aby uzyskać więcej informacji, zobacz Omówienie sieci wirtualnych.
• Inne wymagania dotyczące zabezpieczeń — inne wymagania dotyczące zabezpieczeń, takie jak zasady maszyny, dostęp do publicznych adresów IP, nawiązywanie połączenia z Internetem to scenariusze, które mogą być konieczne przed wdrożeniem weryfikacji koncepcji.

Topologia subskrypcji

Topologia subskrypcji to krytyczna kwestia projektowania podczas wdrażania usługi DevTest Labs w przedsiębiorstwie. Nie jest jednak wymagane, aby utrwalić wszystkie decyzje dopiero po zakończeniu weryfikacji koncepcji. Podczas oceniania liczby subskrypcji wymaganych do wdrożenia przedsiębiorstwa istnieją dwie skrajności:

• Jedna subskrypcja dla całej organizacji
• Subskrypcja na użytkownika

Następnie wyróżniamy zalety każdego podejścia.

Jedna subskrypcja

Często podejście jednej subskrypcji nie jest możliwe do zarządzania w dużym przedsiębiorstwie. Jednak ograniczenie liczby subskrypcji zapewnia następujące korzyści:

• Prognozowanie kosztów dla przedsiębiorstw. Budżetowanie staje się znacznie łatwiejsze w jednej subskrypcji, ponieważ wszystkie zasoby znajdują się w jednej puli. Takie podejście umożliwia prostsze podejmowanie decyzji, kiedy w danym momencie w okresie rozliczeniowym należy wykonywać środki kontroli kosztów.
• Łatwość zarządzania maszynami wirtualnymi, artefaktami, formułami, konfiguracją sieci, uprawnieniami i zasadami jest łatwiejsza, ponieważ wszystkie aktualizacje są wymagane tylko w jednej subskrypcji, w przeciwieństwie do wprowadzania aktualizacji w wielu subskrypcjach.
• Nakład pracy w sieci jest prostszy w jednej subskrypcji dla przedsiębiorstw, w których wymagana jest łączność lokalna. Połączenie sieci wirtualnych w subskrypcjach (model piasty i szprych), wymagane z dodanymi subskrypcjami, wymagają większej liczby konfiguracji, zarządzania i przestrzeni adresowych IP.
• Współpraca zespołowa jest łatwiejsza, gdy wszyscy pracują w tej samej subskrypcji. Na przykład łatwiej jest ponownie przypisać maszynę wirtualną do współpracownika lub udostępnić zasoby zespołu.

Subskrypcja na użytkownika

Oddzielna subskrypcja na użytkownika zapewnia równe szanse dla alternatywnego spektrum. Korzyści wynikające z posiadania wielu subskrypcji obejmują:

• Limity przydziału skalowania platformy Azure nie utrudniają wdrażania. Na przykład na potrzeby pisania tego artykułu platforma Azure zezwala na 200 kont magazynu na subskrypcję. Istnieją limity przydziałów operacyjnych dla większości usług na platformie Azure (wiele z nich można dostosować, a niektóre nie mogą). W tym modelu subskrypcji na użytkownika jest bardzo mało prawdopodobne, aby osiągnięto większość przydziałów. Aby uzyskać więcej informacji na temat bieżących przydziałów skalowania platformy Azure, zobacz Limity subskrypcji i usług platformy Azure, limity przydziału i ograniczenia.
• Obciążenia zwrotne grup lub poszczególnych deweloperów stają się znacznie łatwiejsze, dzięki czemu organizacje mogą uwzględniać koszty przy użyciu ich bieżącego modelu.
• Prawa własności i uprawnienia środowisk DevTest Labs są proste. Deweloperzy zapewniają deweloperom dostęp na poziomie subskrypcji i są one w 100% odpowiedzialne za wszystkie elementy, w tym konfigurację sieci, zasady laboratorium i zarządzanie maszynami wirtualnymi.

W przedsiębiorstwie może istnieć wystarczająca liczba ograniczeń dotyczących skrajności spektrum. W związku z tym może być konieczne skonfigurowanie subskrypcji w sposób, który znajduje się w środku tych skrajności. Najlepszym rozwiązaniem jest, aby organizacja korzystała z minimalnej możliwej liczby subskrypcji. Należy pamiętać o wymuszaniu funkcji, które zwiększają łączną liczbę subskrypcji. Aby powtórzyć, topologia subskrypcji ma kluczowe znaczenie dla wdrożenia usługi DevTest Labs w przedsiębiorstwie, ale nie powinna opóźniać weryfikacji koncepcji. Więcej szczegółów znajduje się w artykule Dotyczącym ładu dotyczącego sposobu decydowania o szczegółowości subskrypcji i laboratorium w organizacji.

Role i obowiązki

Dowód koncepcji usługi DevTest Labs ma trzy role podstawowe ze zdefiniowanymi obowiązkami — właściciel subskrypcji, właściciel usługi DevTest Labs, użytkownik usługi DevTest Labs i opcjonalnie współautor.

• Właściciel subskrypcji — właściciel subskrypcji ma uprawnienia do administrowania subskrypcją platformy Azure, w tym przypisywania użytkowników, zarządzania zasadami, tworzenia topologii sieci i zarządzania nią oraz żądania zwiększenia limitu przydziału. Aby uzyskać więcej informacji, zobacz ten artykuł.
• Właściciel usługi DevTest Labs — właściciel usługi DevTest Labs ma pełny dostęp administracyjny do laboratorium. Ta osoba jest odpowiedzialna za dodawanie/usuwanie użytkowników, zarządzanie ustawieniami kosztów, ogólne ustawienia laboratorium i inne zadania oparte na maszynie wirtualnej/artefaktach. Właściciel laboratorium ma również wszystkie prawa użytkownika usługi DevTest Labs.
• Użytkownik usługi DevTest Labs — użytkownik usługi DevTest Labs może tworzyć i korzystać z maszyn wirtualnych w laboratorium. Te osoby mają pewne minimalne możliwości administracyjne na tworzonych maszynach wirtualnych (uruchamianie/zatrzymywanie/usuwanie/konfigurowanie maszyn wirtualnych). Użytkownicy nie mogą zarządzać maszynami wirtualnymi innych użytkowników.

Orkiestracja implementacji usługi DevTest Labs

Ta sekcja zawiera zalecane podejście do szybkiego wdrażania i wdrażania usługi Azure DevTest Labs. Na poniższej ilustracji przedstawiono ogólny proces jako normatywne wskazówki, jednocześnie obserwując elastyczność obsługi różnych wymagań branżowych i scenariuszy.

Założenia

W tym artykule założono, że przed wdrożeniem pilotażu usługi DevTest Labs masz następujące elementy:

• Subskrypcja platformy Azure: zespół pilotażowy ma dostęp do wdrażania zasobów w subskrypcji platformy Azure. Jeśli obciążenia są przeznaczone tylko do programowania i testowania, zaleca się wybranie oferty Enterprise DevTest dla dodatkowych dostępnych obrazów i niższych stawek na maszynach wirtualnych z systemem Windows.
• Dostęp lokalny: w razie potrzeby dostęp lokalny został już skonfigurowany. Dostęp lokalny można uzyskać za pośrednictwem połączenia sieci VPN typu lokacja-lokacja lub za pośrednictwem usługi Express Route. Połączenie ivity za pośrednictwem usługi Express Route zazwyczaj może potrwać wiele tygodni, zaleca się, aby usługa Express Route była włączona przed rozpoczęciem projektu.
• Zespoły pilotażowe: zidentyfikowano początkowe zespoły projektów programistycznych, które korzystają z usługi DevTest Labs, wraz z odpowiednimi działaniami deweloperskimi lub testowymi oraz ustanowią wymagania/cele/cele dla tych zespołów.

Punkt kontrolny 1: Ustanawianie początkowej topologii sieci i projektu

Pierwszym obszarem zainteresowania podczas wdrażania rozwiązania Azure DevTest Labs jest ustanowienie planowanej łączności dla maszyn wirtualnych. W poniższych krokach opisano niezbędne procedury:

1. Zdefiniuj początkowe zakresy adresów IP przypisane do subskrypcji usługi DevTest Labs na platformie Azure. Ten krok wymaga prognozowania oczekiwanego użycia w liczbie maszyn wirtualnych, aby zapewnić wystarczająco duży blok do przyszłego rozszerzenia.
2. Zidentyfikuj metody żądanego dostępu do usługi DevTest Labs (na przykład dostęp zewnętrzny/wewnętrzny). Kluczowym punktem w tym kroku jest określenie, czy maszyny wirtualne mają publiczne adresy IP (czyli dostępne bezpośrednio z Internetu).
3. Identyfikowanie i ustanawianie metod łączności z resztą środowiska chmury platformy Azure i środowiska lokalnego. Jeśli wymuszony routing z usługą Express Route jest włączony, prawdopodobnie maszyny wirtualne potrzebują odpowiednich konfiguracji serwera proxy w celu przejścia przez zaporę firmową.
4. Jeśli maszyny wirtualne mają być przyłączone do domeny, ustal, czy dołączają do domeny opartej na chmurze (na przykład usługi Microsoft Entra Directory Services) czy domeny lokalnej. W przypadku środowiska lokalnego określ jednostkę organizacyjną (OU) w usłudze Active Directory, do której dołączają maszyny wirtualne. Ponadto upewnij się, że użytkownicy mają dostęp do przyłączenia (lub ustanów konto usługi, które ma możliwość tworzenia rekordów maszyny w domenie)

Punkt kontrolny 2: Wdrażanie laboratorium pilotażowego

Po utworzeniu topologii sieci można utworzyć pierwsze/pilotażowe laboratorium, wykonując następujące czynności:

1. Utwórz początkowe środowisko usługi DevTest Labs.
2. Określ dozwolone obrazy i rozmiary maszyn wirtualnych do użycia z laboratorium. Zdecyduj, czy obrazy niestandardowe można przekazać na platformę Azure do użycia z usługą DevTest Labs.
3. Bezpieczny dostęp do laboratorium przez utworzenie początkowej kontroli dostępu opartej na rolach (RBAC) platformy Azure dla laboratorium (właściciele laboratorium i użytkownicy laboratorium). Zalecamy używanie zsynchronizowanych kont usługi Active Directory z identyfikatorem Entra firmy Microsoft na potrzeby tożsamości z usługą DevTest Labs.
4. Skonfiguruj usługę DevTest Labs, aby używać zasad, takich jak harmonogramy, zarządzanie kosztami, maszyny wirtualne z możliwością oświadczeń, obrazy niestandardowe lub formuły.
5. Ustanów repozytorium online, takie jak Azure Repos/Git.
6. Zdecyduj o użyciu repozytoriów publicznych lub prywatnych albo kombinacji obu tych repozytoriów. Organizowanie szablonów JSON na potrzeby wdrożeń i długoterminowego utrzymania.
7. W razie potrzeby utwórz artefakty niestandardowe. To krok jest opcjonalny.

Punkt kontrolny 3: Dokumentacja, pomoc techniczna, nauka i ulepszanie

Początkowe zespoły pilotażowe mogą wymagać dogłębnej pomocy technicznej dotyczącej rozpoczęcia pracy. Skorzystaj z ich środowisk, aby zapewnić odpowiednią dokumentację i pomoc techniczną w celu ciągłego wdrażania usługi Azure DevTest Labs.

1. Wprowadzenie zespołów pilotażowych do nowych zasobów usługi DevTest Labs (pokazy, dokumentacja)
2. Na podstawie środowisk zespołów pilotażowych, planuj i dostarczaj dokumentację zgodnie z potrzebami
3. Formalizowanie procesu dołączania nowych zespołów (tworzenie i konfigurowanie laboratoriów, zapewnianie dostępu itp.)
4. Na podstawie początkowego wychwytu sprawdź, czy oryginalna prognoza przestrzeni adresów IP jest nadal rozsądna i dokładna
5. Upewnij się, że zostały ukończone odpowiednie przeglądy zgodności i zabezpieczeń

Następne kroki

Zobacz następny artykuł z tej serii: Governance of Azure DevTest Labs infrastructure (Zarządzanie infrastrukturą usługi Azure DevTest Labs)