Planowanie środowisk

Ukończone

Majątek platformy Azure składa się z wielu składników, takich jak podstawowa konfiguracja, zasoby i ustawienia całej organizacji oraz obciążenia aplikacji. Prawdopodobnie masz również rozpowszechnienie majątku w wielu środowiskach, z których każda ma inny cel.

W tej lekcji poznasz korzyści wynikające z spójnego używania kodu dla wszystkich wdrożeń i konfiguracji. Następnie należy wziąć pod uwagę poziomy kontroli i automatyzacji, które można zastosować do każdego środowiska. Należy również rozważyć postęp zmian na każdym etapie procesu wdrażania oraz mechanizmy kontroli i typów ładu, które należy obsługiwać wybraną strategię wdrażania.

Definiowanie infrastruktury jako kodu

Wdrażanie i konfiguracja platformy Azure obejmują znacznie więcej niż aplikacje, maszyny wirtualne, usługi magazynu i sieć. Na przykład każdy z następujących elementów jest formą konfiguracji z odpowiednimi zasobami platformy Azure:

• Organizowanie zasobów przez utworzenie grup zasobów, subskrypcji i grup zarządzania.
• Kontrolowanie sposobu konfigurowania innych zasobów przez definiowanie i stosowanie definicji, inicjatyw i przypisań usługi Azure Policy.
• Przypisywanie ról w celu umożliwienia użytkownikom, grupom i tożsamościom obciążeń uzyskiwania dostępu do zasobów platformy Azure.
• Konfigurowanie monitorowania, w tym alertów, w celu obserwowania zasobów platformy Azure i zapewnienia, że zachowują się zgodnie z oczekiwaniami.

Po pierwszym rozpoczęciu definiowania infrastruktury jako kodu może nie być świadomych wszystkich elementów, które można zdefiniować w szablonach lub definicjach. Jednak w miarę dojrzewania stosowania automatyzacji dobrym rozwiązaniem jest zdefiniowanie wszystkich elementów dotyczących środowiska jako kodu. Dzięki temu można użyć spójnego, przetestowanego i zatwierdzonego procesu dla całej konfiguracji platformy Azure. Ponieważ kod jest wersjonowany i śledzony w repozytorium Git, możesz sprawdzić, jak środowisko platformy Azure zmieniło się wraz z upływem czasu. Możesz użyć repozytorium Git do śledzenia historii każdej zmiany.

Załóżmy na przykład, że musisz skonfigurować alerty usługi Azure Monitor. Na początku można pomyśleć, że użycie automatyzacji do wdrażania alertów nie miałoby sensu. Alerty są jednak ważną częścią konfiguracji platformy Azure. Jeśli alert nie został poprawnie utworzony, możesz przegapić powiadomienia o krytycznych problemach produkcyjnych. Definiując alerty w kodzie:

• Członkowie zespołu mogą przeglądać alerty i ich konfigurację.
• Alerty można najpierw wdrożyć w środowiskach nieprodukcyjnych, aby można je było przetestować.
• Masz pełną możliwość śledzenia zmian konfiguracji platformy Azure.

Środowiska

Jeśli planujesz automatyczne wdrażanie infrastruktury, warto wyświetlić listę środowisk, które mają być używane. Wiele organizacji ma różne typy środowisk, z których każda ma różne cechy. Na przykład:

• Niektóre środowiska uruchamiają kod produkcyjny, podczas gdy inne uruchamiają wersje nieprodukcyjne tego samego kodu, być może z różnymi konfiguracjami.
• Niektóre środowiska są długotrwałe i nigdy nie mają być usuwane. Inne są efemeryczne: tworzone automatycznie i niszczone, gdy nie są już używane.
• Niektóre środowiska są używane przez zespół ds. infrastruktury lub tworzenia oprogramowania. Inne osoby są używane przez zespół ds. zabezpieczeń, a nawet przez zespół ds. sprzedaży, gdy musi zademonstrować produkt potencjalnym klientom.

Rozważ środowiska, których twoja firma może używać w twojej witrynie internetowej:

Po wprowadzeniu i zatwierdzeniu zmian w aplikacji lub w infrastrukturze potok wdraża zmiany w sekwencji środowisk nieprodukcyjnych: programowania, testowania i przemieszczania. W niektórych punktach mogą być również wykonywane ręczne kroki zatwierdzania, dzięki czemu zdefiniowani członkowie zespołu mogą zweryfikować konfigurację lub przejrzeć dziennik potoku przed kontynuowaniem wdrażania. Następnie potok ostatecznie wdraża zmiany w środowisku produkcyjnym.

Oprócz tych środowisk twój zespół ds. sprzedaży ma własne środowisko demonstracyjne używane do rozmowy z klientami. Zespół ds. sprzedaży tworzy kopię środowiska produkcyjnego. Zespoły ds. zabezpieczeń i testów od czasu do czasu tworzą tymczasowe kopie środowiska produkcyjnego na potrzeby testowania penetracyjnego i testowania wydajnościowego.

Twój zespół programistyczny ma również własne zestawy środowisk. Ma piaskownice, których członkowie zespołu deweloperów mogą używać podczas eksplorowania nowych funkcji lub eksperymentowania z usługami platformy Azure. Zespół programistyczny tworzy również środowiska przeglądu żądań ściągnięcia dla każdego żądania ściągnięcia usługi GitHub, które przegląda i scala.

Kontrolowane środowiska

W niektórych z tych środowisk warto wymagać formalnego procesu przeglądania i stosowania zmian. Środowiska tego typu są nazywane środowiskami kontrolowanymi. Środowisko produkcyjne powinno być zawsze kontrolowane. Dobrym rozwiązaniem jest zastosowanie kontrolek do niektórych środowisk nieprodukcyjnych. W ten sposób można zagwarantować, że wszelkie ograniczenia nakładane przez kontrole są dobrze zrozumiałe i przetestowane przed wdrożeniem produkcyjnym.

Z kolei środowiska niekontrolowane nie mają wielu ani żadnych formalnych mechanizmów kontroli. Mogą mieć ten sam kod i podobną konfigurację do innych środowisk, ale umożliwiają one bardziej eksperymentowanie i zmiany konfiguracji ad hoc. W środowisku niekontrolowanym użytkownicy mogą modyfikować konfigurację przy użyciu witryny Azure Portal lub bezpośrednio uruchamiając polecenia interfejsu wiersza polecenia platformy Azure/programu Azure PowerShell. Mogą oni również tworzyć zasoby bez korzystania z zatwierdzonego procesu organizacji. Zmiany wprowadzone w niekontrolowanych środowiskach muszą być przechwytywane w kodzie, zanim będą mogły zostać zastosowane do kontrolowanych środowisk, takich jak środowisko produkcyjne.

Uwaga

Czasami środowisko może rzeczywiście reprezentować wiele środowisk fizycznych lub wdrożeń. Na przykład podczas tworzenia środowisk efemerycznych dla przeglądów żądań ściągnięcia wiele oddzielnych środowisk może być aktywnych w tym samym czasie, ponieważ zespół ma wiele otwartych żądań ściągnięcia. Jednak w celu planowania środowisk można je wziąć pod uwagę jako równoważne, ponieważ mają te same cechy i kontrolki.

Po kilku dyskusjach z zespołem wyznaczysz, które środowiska są kontrolowane i niekontrolowane. Decydujesz również, kto jest właścicielem każdego środowiska.

Nazwa środowiska	opis	Właściciel	Okres istnienia	Poziom kontroli
Opracowywanie zawartości	Integruje zmiany z wielu deweloperów w jednym środowisku.	Zespół operacyjny	Długie życie	Kontrolowane
Test	Środowisko do uruchamiania testów ręcznych i automatycznych pod kątem zmian.	Zespół operacyjny	Długie życie	Kontrolowane
Przygotowanie	Końcowe środowisko nieprodukcyjne, w którym zmiany są wdrażane przed produkcją, z konfiguracją przypominającą środowisko produkcyjne.	Zespół operacyjny	Długie życie	Kontrolowane
Produkcyjne	Uruchamia obciążenia produkcyjne.	Zespół operacyjny	Długie życie	Kontrolowane
Demonstracja	Używany przez zespół sprzedaży do zademonstrowania produktu nowym klientom.	Zespół ds. sprzedaży	Długie życie	Niekontrolowane
Testowanie wydajności	Dynamicznie tworzone jako duplikat środowiska produkcyjnego do uruchamiania testów wydajnościowych i obciążeniowych, a następnie usuwane po zakończeniu testów.	Zespół testowy	Krótkotrwałe	Niekontrolowane
Testy penetracyjne	Dynamicznie tworzone jako duplikat środowiska produkcyjnego do uruchamiania testów penetracyjnych i zabezpieczeń, a następnie usuwane po zakończeniu testów.	Zespół ds. zabezpieczeń	Krótkotrwałe	Niekontrolowane
Przeglądy żądań ściąg	Dynamicznie tworzone dla każdego żądania ściągnięcia tworzonego przez członka zespołu w celu zmiany aplikacji lub infrastruktury. Środowisko jest usuwane po zamknięciu żądania ściągnięcia.	Zespół programistyczny	Krótkotrwałe	Niekontrolowane
Piaskownice programowania	Utworzone przez członków zespołu deweloperów w celu eksperymentowania lub eksplorowania, a następnie usuwania, gdy nie są już potrzebne.	Zespół programistyczny	Krótkotrwałe	Niekontrolowane

Poprzednia lista środowisk jest tylko przykładem. We własnej organizacji musisz zdecydować, które środowiska są używane, jakie mają być ich okresy istnienia, oraz jaki poziom kontroli musi mieć poszczególne środowiska.

Napiwek

Znacznie łatwiej jest dodawać, testować i przeglądać kod infrastruktury podczas stosowania tych procesów na wczesnym etapie wdrożeń, zamiast dodawać je później i trzeba naprawić wiele uszkodzonych kodu.

Podobnie znacznie łatwiej jest pracować z mechanizmami kontroli zabezpieczeń, gdy są obecne od samego początku, a kiedy są one również stosowane do niektórych środowisk nieprodukcyjnych. W ten sposób twój zespół przyzwyczai się do pracy w kontrolowanym środowisku.

W ramach ścieżek szkoleniowych wprowadziliśmy niektóre z tych pojęć stopniowo. Często dobrym pomysłem jest dodanie tych elementów do procesu wdrażania tak szybko, jak to możliwe.

Izolacja każdego środowiska

Ważne jest, aby oddzielić poszczególne środowiska i uczynić je samodzielnymi wszędzie tam, gdzie to możliwe. Korzystanie z dedykowanych subskrypcji platformy Azure dla każdego środowiska może pomóc, ale nadal należy zachować ostrożność, aby zapewnić oddzielenie środowisk.

Unikaj nawiązywania połączenia z jednego środowiska z innym. Na przykład nie należy łączyć sieci wirtualnej środowiska produkcyjnego z siecią wirtualną środowiska nieprodukcyjnego. Jeśli to zrobisz, ktoś może przypadkowo zmienić dane produkcyjne z poziomu środowiska nieprodukcyjnego lub wyciek poufnych danych produkcyjnych do środowiska nieprodukcyjnego.

Kontrole i bramy

Po kontynuowaniu procesu wdrażania należy uruchomić serię kontroli, aby zwiększyć zaufanie do wdrożenia. Należy określić testy, które mają sens dla każdego środowiska, przez które są wykonywane wdrożenia.

Sprawdzanie infrastruktury często obejmuje:

• Przeglądy kodu.
• Wdrożenie kodu w przeglądzie w środowiskach efemerycznych i uruchamianie zautomatyzowanych lub ręcznych testów w środowiskach.
• Linting.
• Walidacja wstępna.
• Testowanie ręczne.
• Zatwierdzanie ręczne.
• Zautomatyzowane testowanie funkcjonalne.
• Zautomatyzowane testowanie weryfikacyjne kompilacji.
• Oczekiwanie na sygnały kondycji z poprzedniego środowiska przed przejściem do następnego środowiska.

Niektóre z tych testów można uruchomić wiele razy w procesie wdrażania, na przykład dla każdego kontrolowanego środowiska.

Napiwek

Podczas projektowania procesu wdrażania wyświetl listę wszystkich kroków, które należy wykonać, niezależnie od tego, jak mały lub oczywisty. Być tak szczegółowo, jak to możliwe. Możesz nie zdecydować się na zautomatyzowanie wszystkiego na początku, ale wykonanie tej praktyki pomoże Ci utworzyć strategię dla zautomatyzowanych procesów wdrażania w przyszłości.

Brama jest automatycznym lub ręcznym sprawdzaniem, które musi zakończyć się pomyślnie, aby wdrożenie było kontynuowane.

Interwencja ręczna

Dobrym pomysłem jest zautomatyzowanie jak największej liczby testów podczas przeglądu kodu i procesów wdrażania. Jednak organizacja może wymagać ręcznego zatwierdzenia wdrożenia w środowisku produkcyjnym lub w innych kontrolowanych środowiskach.

Jeśli do wdrożeń są używane bramy ręcznego zatwierdzania, wykonaj następujące zalecane rozwiązania:

• Jasno określ, kto może zatwierdzić wdrożenie. Użyj grup Firmy Microsoft Entra, aby zdefiniować osoby zatwierdzające, zamiast określać poszczególnych użytkowników. Możesz łatwo zmienić listę osób zatwierdzających w przyszłości.
• Proces wdrażania awaryjnego. Zaplanuj, kto może zatwierdzić wdrożenie, jeśli normalne osoby zatwierdzające nie są dostępne. Wdrożenie awaryjne może być konieczne w środku nocy lub w okresie urlopowym.
• Ogranicz interwencję człowieka, aby po prostu zatwierdzać lub odrzucać wdrożenie. Unikaj konieczności uruchamiania dowolnej operacji wdrażania przez ludzi, chyba że istnieje krok, którego nie można zautomatyzować.

Ład korporacyjny

Platforma Azure udostępnia narzędzia i możliwości ułatwiające zarządzanie środowiskiem, w tym:

• Usługa Azure Policy umożliwia wykrywanie zasobów skonfigurowanych w sposób, który nie pasuje do wymagań organizacji. Może również pomóc zapobiec tworzeniu lub ponownemu konfigurowaniu zasobów w sposób, który powoduje ich brak zgodności.
• Blokuje, aby zapobiec zmianom lub usuwaniu ważnych zasobów.
• Grupy zarządzania ułatwiające organizowanie subskrypcji platformy Azure i spójne konfigurowanie kontroli dostępu opartej na rolach i zasad w środowiskach.
• Usługa Azure Monitor umożliwia rejestrowanie metryk i dzienników z zasobów, prezentowanie ich na pulpitach nawigacyjnych i automatyczne zgłaszanie alertów, gdy odbiegają od oczekiwanych wartości.

Podczas tworzenia majątku platformy Azure rozważ użycie stref docelowych platformy Azure. Korzystając ze strefy docelowej, można od samego początku tworzyć ład w środowisku. Wiele stref docelowych obejmuje wstępnie utworzone pliki Bicep i Terraform, które ułatwiają konfigurowanie środowiska. Link do dodatkowych informacji znajduje się w podsumowaniu.