Zalecenia dotyczące używania infrastruktury jako kodu

  • Artykuł

Dotyczy tej rekomendacji dotyczącej listy kontrolnej doskonałości operacyjnej platformy Azure Well-Architected Framework:

OE:05 Przygotowywanie zasobów i ich konfiguracji przy użyciu standardizowanej infrastruktury jako kodu (IaC). Podobnie jak w przypadku innego kodu, projektowanie IaC ze spójnymi stylami, odpowiednią modularzacją i zapewnieniem jakości. W razie możliwości preferuj podejście deklaratywne.

W tym przewodniku opisano zalecenia dotyczące używania IaC jako standardu wdrożeń infrastruktury. Korzystanie z rozwiązania IaC umożliwia integrację wdrożeń infrastruktury i zarządzania z istniejącymi praktykami programowania oprogramowania. Zapewnia spójną, standardową metodologię programowania i wdrażania dla wszystkich składników obciążenia. Poleganie na wdrożeniach ręcznych naraża obciążenie na ryzyko niespójnych konfiguracji i potencjalnie niezabezpieczonego projektu.

Definicje

Okres Definicja
Narzędzia deklaratywne Kategoria narzędzi definiujących stan końcowy wdrożenia i polega na systemie w celu określenia sposobu wdrażania zasobów w celu dopasowania do zdefiniowanego stanu końcowego.
Niezmienna infrastruktura Infrastruktura, która ma zostać zastąpiona nową infrastrukturą, która uruchamia nową konfigurację przy każdym wdrożeniu. Nie można go zmienić.
Narzędzia imperatywne Kategoria narzędzi, które zawierają listę kroków wykonywania, które powodują żądany stan końcowy.
Moduł Jednostka abstrakcji dzielenia grup zasobów w celu uproszczenia złożonych wdrożeń.
Niezmienna infrastruktura Infrastruktura, która ma zostać zmieniona. Wdrożenia zmieniają konfigurację infrastruktury, zamiast zastępować ją nową infrastrukturą.

Kluczowe strategie projektowania

Zgodnie z opisem w przewodnikach dotyczących łańcucha dostaw i standaryzacji narzędzi i procesów należy mieć ścisłą zasadę wdrażania zmian infrastruktury (w tym zmian konfiguracji) tylko za pomocą kodu. Należy wdrożyć IaC za pośrednictwem potoków ciągłej integracji i ciągłego dostarczania (CI/CD). Wdrożenie tych zasad wymusza spójność procesów we wszystkich wdrożeniach IaC, minimalizuje ryzyko dryfu konfiguracji w środowiskach i zapewnia spójność infrastruktury w środowiskach. Ponadto należy ustandaryzować narzędzia i procesy i narzędzia i procesy programowania IaC w przewodniku stylu. Zalecenia dotyczące przewodnika stylu obejmują:

Preferuj deklaratywne narzędzia imperatywne. Narzędzia deklaratywne i skojarzone z nimi pliki są lepszym ogólnym wyborem do wdrażania IaC i zarządzania nimi niż narzędzi imperatywnych. Narzędzia deklaratywne używają prostszej składni dla plików definicji, definiując tylko żądany stan środowiska po zakończeniu wdrażania. Narzędzia imperatywne zależą od definiowania kroków wymaganych do uzyskania żądanego stanu końcowego, dzięki czemu pliki mogą być znacznie bardziej złożone niż pliki deklaratywne. Deklaratywne pliki definicji pomagają również zmniejszyć dług techniczny utrzymywania kodu imperatywnego, takiego jak skrypty wdrażania, które mogą być naliczane w czasie.

Użyj natywnych narzędzi platformy w chmurze i innych sprawdzonych w branży narzędzi, które natywnie integrują się z platformą. Platforma w chmurze udostępnia narzędzia umożliwiające łatwe i proste wdrażanie IaC. Skorzystaj z tych narzędzi i innych narzędzi innych firm, które mają natywną integrację, na przykład Terraform, zamiast tworzyć własne rozwiązania. Narzędzia natywne są obsługiwane przez platformę i obejmują wbudowane funkcje dla większości Twoich potrzeb. Są one stale aktualizowane przez dostawcę platformy, co czyni je bardziej przydatnymi w miarę rozwoju platformy.

Uwaga

Należy pamiętać, że ponieważ dostawcy usług w chmurze i deweloperzy innych firm aktualizują swoje narzędzia i interfejsy API, możesz uruchomić ryzyko nieprzewidzianych problemów podczas korzystania z najnowszej wersji obciążenia. Przed ich wdrożeniem należy dokładnie przetestować nowe wersje narzędzi i interfejsów API. Podobnie należy unikać używania flagi "latest" podczas wywoływania narzędzia lub interfejsu API w kodzie wdrożenia. Należy celowo wywołać najnowszą znaną dobrą wersję obciążenia.

Użyj odpowiednich narzędzi do określonych zadań i typów infrastruktury. Wiele zadań, poza wdrożeniami, jest zaangażowanych w cykl życia infrastruktury. Konfiguracja musi być stosowana i utrzymywana, na przykład, a narzędzie używane do wdrażania skryptów, takich jak Bicep, może nie być najlepszym narzędziem dla każdej operacji zarządzania.

Podobnie zastosowanie konfiguracji żądanego stanu (DSC) dla różnych typów infrastruktury może wymagać różnych narzędzi. Na przykład istnieją określone narzędzia, takie jak Ansible do zarządzania dsC dla maszyn wirtualnych, natomiast platforma Flux jest dobrym narzędziem do zarządzania dsC w klastrach Kubernetes. Usługi platformy jako usługi (PaaS) mogą zapewniać różne narzędzia do zarządzania konfiguracją (na przykład Azure App Configuration), które mogą być obsługiwane za pośrednictwem IaC. Usługi oprogramowania jako usługi (SaaS) mogą być bardziej ograniczone, ponieważ są one ściślej kontrolowane przez platformę.

Pomyśl o wszystkich zadaniach i typach infrastruktury, które są w zakresie praktyk IaC i ustandaryzuj narzędzia, które wykonują zadania, które są potrzebne do wykonania i można je zintegrować z praktykami programowania i zarządzania.

Skrypty i szablony powinny być wystarczająco elastyczne, aby łatwo wdrożyć różne środowiska. Użyj parametrów, zmiennych i plików konfiguracji, aby wdrożyć standardowy zestaw zasobów, które można zmodyfikować w celu wdrożenia dowolnego środowiska w stosie podwyższania poziomu kodu. Ustawienia abstrakcyjne, takie jak rozmiar zasobu, liczba, nazwa, lokalizacje do wdrożenia i niektóre ustawienia konfiguracji. Uważaj jednak, aby nie abstrakować zbyt wiele. Istnieją ustawienia, które można abstrakcjonować za pomocą parametru lub zmiennej, które mogą nie ulec zmianie w trakcie cyklu życia obciążenia lub które mogą ulec rzadko zmianie. Nie powinny być abstrakcyjne.

Uwaga

Unikaj używania różnych zasobów IaC dla różnych środowisk. Nie należy na przykład mieć różnych plików programu Terraform dla środowisk produkcyjnych i testowych. Wszystkie środowiska powinny używać jednego pliku. W razie potrzeby można manipulować tym plikiem w celu wdrożenia w różnych środowiskach.

Strategizowanie i standaryzacja użycia modułów. Podobnie jak parametry i zmienne, moduły mogą powtarzać wdrożenia infrastruktury. Bądź jednak przemyślany, o tym, jak ich używasz. Ustandaryzowana strategia abstrakcji pomaga zapewnić, że moduły są tworzone w celu spełnienia określonych, uzgodnionych celów. Użyj modułów, aby hermetyzować złożone konfiguracje lub kombinacje zasobów. Unikaj modułów, jeśli używasz tylko domyślnej konfiguracji zasobu. Ponadto należy być rozsądnym w tworzeniu nowych modułów. Używaj utrzymywanych modułów typu open source, jeśli jest to konieczne, na przykład w scenariuszach niewrażliwych.

Standardy dokumentu dotyczące kroków ręcznych. Mogą istnieć kroki związane z wdrażaniem i konserwowaniem infrastruktury, które są szczególnie w danym środowisku i które wymagają interwencji ręcznej. Upewnij się, że te kroki są możliwie najbardziej zminimalizowane i udokumentowane. W przewodniku stylowym i standardowych procedurach operacyjnych ustandaryzuj kroki ręczne, aby zapewnić bezpieczne i spójne wykonywanie zadań.

Standardy dokumentów do obsługi oddzielonych zasobów. W zależności od narzędzi używanych do zarządzania konfiguracją i ich ograniczeń może wystąpić czas, gdy określony zasób nie jest już potrzebny przez obciążenie, a narzędzia IaC nie mogą automatycznie usuwać zasobu. Załóżmy na przykład, że przenosisz się z maszyn wirtualnych do usługi PaaS dla niektórych funkcji, a narzędzia IaC nie mają logiki usuwania wycofanych zasobów. Te zasoby mogą zostać oddzielone, jeśli zespół obciążeń nie pamięta o ich ręcznym usunięciu. Aby obsłużyć te scenariusze, ustandaryzuj strategię skanowania pod kątem oddzielonych zasobów i usuń je. Należy również rozważyć, jak upewnić się, że szablony są aktualne. Zapoznaj się z ograniczeniami narzędzi IaC, aby zrozumieć, co może być konieczne, aby zaplanować w tych sytuacjach.

Inne strategie IaC

Weź pod uwagę następujące zalecenia dotyczące używania IaC dla obciążenia:

Użyj podejścia warstwowego, aby dopasować potoki IaC do stosu obciążenia. Rozdzielenie potoków IaC na warstwy ułatwia zarządzanie złożonymi środowiskami. Wdrażanie kilkudziesięciu lub setek zasobów jako pakietu monolitycznego jest nieefektywne i może powodować wiele problemów, takich jak uszkodzone zależności. Korzystanie z wielu potoków, które są dopasowane do warstw złożonych z zasobów, których cykle życia wdrożenia lub czynniki, takie jak funkcje, ściśle pasują, ułatwiają zarządzanie wdrożeniami IaC.

Podstawowa infrastruktura, taka jak zasoby sieciowe, rzadko wymaga zmian bardziej złożonych niż aktualizacje konfiguracji, więc te zasoby powinny stanowić potok IaC o niskim dotyku . W zależności od złożoności obciążenia może istnieć jeden lub więcej potoków IaC o średnim dotyku i wysokiej dotyku . Użycie stosu aplikacji opartego na platformie Kubernetes jako przykład jednej warstwy średniej dotyku może składać się z klastrów, zasobów magazynu i usług bazy danych. Warstwy o dużym dotyku składają się z kontenerów aplikacji, które są bardzo często aktualizowane w trybie ciągłego dostarczania.

Traktuj kod IaC i aplikację tak samo. Traktowanie artefaktów IaC tak samo jak artefakty kodu aplikacji pomaga zastosować ten sam zestaw do zarządzania kodem we wszystkich potokach. Ponadto praktyki programistyczne i wdrażania IaC powinny odzwierciedlać praktyki aplikacji. Standardy kontroli wersji, rozgałęziania, podwyższania poziomu kodu i jakości powinny być identyczne. Rozważ również sortowanie zasobów IaC wraz z zasobami kodu aplikacji. Dzięki temu można zagwarantować, że te same procesy są wykonywane wraz z każdym wdrożeniem i pomaga uniknąć problemów, takich jak przypadkowo wdrażanie infrastruktury przed wymaganym kodem aplikacji lub na odwrót.

Współpracuj z innymi zespołami w organizacji w celu standaryzacji i ponownego użytku. Duże organizacje mogą czasami mieć wiele zespołów tworzących i obsługujących obciążenia. Współpraca między zespołami w celu uzgodnienia standardów ułatwia ponowne używanie bibliotek, szablonów i modułów w celu uzyskania wydajności i spójności w środowiskach obciążeń. Podobnie narzędzia IaC powinny być ustandaryzowane w całej organizacji w zakresie, w jakim jest to praktyczne.

Zastosuj zasadę "zabezpieczenia jako kod", aby upewnić się, że zabezpieczenia są częścią potoku wdrażania. Uwzględnianie skanowania luk w zabezpieczeniach i wzmacniania zabezpieczeń konfiguracji w ramach procesu programowania IaC. Skanuj repozytoria IaC pod kątem kluczy i wpisów tajnych, które są widoczne. Jedną z zalet korzystania z uwierzytelniania IaC jest to, że członkowie zespołu skoncentrowani na zabezpieczeniach mogą przeglądać kod przed wdrożeniem, aby upewnić się, że konfiguracja zatwierdzona do wydania przez zabezpieczenia jest rzeczywiście tym, co zostało wdrożone w środowisku produkcyjnym. Aby uzyskać szczegółowe wskazówki, zobacz Zalecenia dotyczące zabezpieczania cyklu życia programowania.

Testowanie rutynowych i nie rutynowych działań. Wdrożenia testowe, aktualizacje konfiguracji i procesy odzyskiwania, w tym procesy wycofywania wdrożenia.

Modyfikowalna a niezmienna infrastruktura

Wybór między wdrażaniem modyfikowalnej a niezmiennej infrastruktury zależy od kilku czynników. Jeśli obciążenie ma krytyczne znaczenie dla działania firmy, najlepiej używać niezmiennej infrastruktury. Podobnie, jeśli masz dojrzały projekt infrastruktury oparty na sygnaturach wdrażania, użycie niezmiennej infrastruktury może mieć sens, ponieważ można niezawodnie wdrożyć kod aplikacji i nową infrastrukturę. Z drugiej strony użycie infrastruktury modyfikowalnej może być lepszym wyborem, jeśli bezpieczne rozwiązania wdrażania określają, że przechodzenie do przodu z wdrożeniami w przypadku wystąpienia problemów z wdrażaniem niezmiennym jest preferowaną opcją. W takim przypadku prawdopodobnie zaktualizujesz infrastrukturę.

Zagadnienia do rozważenia

Zwiększona specjalizacja: W niektórych przypadkach wprowadzenie nowych języków w zespole ds. obciążeń wiąże się z krzywą szkoleniową, a blokada dostawcy może sprawić, że będzie to słaby wybór. Wymagane jest szkolenie członków zespołu i analizowanie odpowiedniego narzędzia na podstawie obsługi narzędzi dostawców usług w chmurze.

Zwiększenie nakładu pracy konserwacyjnego: Aby zapewnić aktualność i bezpieczeństwo implementacji IaC, wymagana jest konserwacja bazy kodu i narzędzi. Właściwie śledź swój dług techniczny i wspieraj kulturę, w której zmniejszanie długu jest nagradzane.

Zwiększony czas zmian konfiguracji: Wdrażanie infrastruktury przy użyciu instrukcji wiersza polecenia lub bezpośrednio z portalu nie wymaga czasu kodowania i/lub testowania artefaktów. Zminimalizuj czas wdrażania, postępując zgodnie z zalecanymi rozwiązaniami, takimi jak przeglądy kodu i praktyki zapewniania jakości.

Zwiększona złożoność modularyzacji: Użycie większej liczby modułów i parametryzacji zwiększa czas potrzebny do debugowania i dokumentowania systemu oraz dodaje warstwę abstrakcji. Równoważenie użycia modułyzacji w celu zmniejszenia złożoności i uniknięcia nadmiernej inżynierii.

Ułatwienia dla platformy Azure

Szablony usługi Azure Resource Manager (szablony usługi ARM) i Bicep to natywne narzędzia platformy Azure do wdrażania infrastruktury przy użyciu składni deklaratywnej. Szablony usługi ARM są pisane w formacie JSON, natomiast Bicep jest językiem specyficznym dla domeny. Oba te rozwiązania można łatwo zintegrować z potokami platformy Azure lub potokami ciągłej integracji/ciągłego wdrażania GitHub Actions.

Terraform to kolejne deklaratywne narzędzie IaC, które jest w pełni obsługiwane na platformie Azure. Może służyć do wdrażania infrastruktury i zarządzania nią oraz można ją zintegrować z potokiem ciągłej integracji/ciągłego wdrażania.

Za pomocą Microsoft Defender for Cloud można odnajdywać błędy konfiguracji w IaC.

Przykład

Zobacz architekturę akceleratora strefy docelowej usługi Azure Virtual Desktop i powiązaną implementację referencyjną, aby zapoznać się z przykładem implementacji usługi Virtual Desktop, którą można wdrożyć za pośrednictwem udostępnionych plików Resource Manager, Bicep lub Terraform.

Lista kontrolna doskonałości operacyjnej

Zapoznaj się z pełnym zestawem zaleceń.

Lista kontrolna doskonałości operacyjnej