Zalecenia dotyczące używania infrastruktury jako kodu
Dotyczy tego zalecenia z listy kontrolnej dotyczącej doskonałości operacyjnej platformy Azure Well-Architected Framework:
OE:05 | Przygotowanie zasobów i ich konfiguracji przy użyciu standardowej infrastruktury jako kodu (IaC). Podobnie jak w przypadku innego kodu, projektowanie IaC ze spójnymi stylami, odpowiednią modułizacją i zapewnieniem jakości. Preferuj podejście deklaratywne, jeśli jest to możliwe. |
---|
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 tworzenia 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, które definiują stan końcowy wdrożenia i polegają 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 dzieląca grupy zasobów w celu uproszczenia złożonych wdrożeń. |
Infrastruktura modyfikowalna | Infrastruktura, która ma zostać zmieniona. Wdrożenia zmieniają konfigurację infrastruktury, zamiast zastępować ją nową infrastrukturą. |
Kluczowe strategie projektowania
Zgodnie z opisem w łańcuchu dostaw i przewodnikach dotyczących standaryzacji narzędzi i procesów należy stosować ścisłą politykę 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 dla wszystkich wdrożeń IaC, minimalizuje ryzyko dryfu konfiguracji w środowiskach i zapewnia spójność infrastruktury w środowiskach. Ponadto należy standaryzacji narzędzi i procesów i narzędzi i procesów 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 nim 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. Pliki definicji deklaratywnych pomagają również zmniejszyć dług techniczny utrzymywania kodu imperatywnego, takiego jak skrypty wdrażania, które mogą być naliczane w czasie.
Używanie natywnych i branżowych narzędzi
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 zwiększa ich użyteczność w miarę rozwoju platformy.
Uwaga
Należy pamiętać, że jako dostawcy usług w chmurze i deweloperzy innych firm aktualizują swoje narzędzia i interfejsy API, możesz ryzykować nieprzewidziane problemy 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ływać najnowszą znaną dobrą wersję obciążenia.
Użyj odpowiedniego narzędzia dla zadania
Użyj odpowiednich narzędzi dla 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. Istnieją na przykład konkretne narzędzia, takie jak Rozwiązanie Ansible do zarządzania dsc dla maszyn wirtualnych, natomiast platforma Flux jest dobrym narzędziem do zarządzania dsc w klastrach Kubernetes. Usługi typu platforma jako usługa (PaaS) mogą udostępniać różne narzędzia do zarządzania konfiguracją (na przykład aplikacja systemu Azure 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 standaryzacji narzędzi, które wykonują zadania potrzebne do wykonania i można je zintegrować z praktykami programowania i zarządzania.
Obsługa wielu środowisk
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 mogą być abstrakcyjne z parametrem lub zmienną, które mogą faktycznie nie ulec zmianie w trakcie cyklu życia obciążenia lub które mogą się rzadko zmieniać. Nie powinny być abstrakcyjne.
Uwaga
Unikaj używania różnych zasobów IaC w różnych środowiskach. 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. Możesz manipulować tym plikiem w celu wdrożenia w różnych środowiskach zgodnie z potrzebami.
Używanie właściwej równowagi podczas hermetyzacji funkcji
Strategiyzacja i standaryzacja użycia modułów. Podobnie jak parametry i zmienne, moduły mogą powtarzać wdrożenia infrastruktury. Bądź jednak przemyślany, jak ich używasz. Ustandaryzowana strategia abstrakcji pomaga zagwarantować, ż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.
Dokumentowanie kroków ręcznych
Standardy dokumentów 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 jak najbardziej zminimalizowane i jasno udokumentowane. W przewodniku stylowym i standardowych procedurach operacyjnych należy standaryzacji ręcznych kroków, aby zapewnić bezpieczne i spójne wykonywanie zadań.
Dokumentowanie standardów obsługi oddzielonych zasobów. W zależności od narzędzi używanych do zarządzania konfiguracją i ich ograniczeń mogą wystąpić czasy, gdy określony zasób nie jest już potrzebny przez obciążenie, a narzędzia IaC nie mogą automatycznie usunąć 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, standaryzacja strategii skanowania pod kątem oddzielonych zasobów i ich usuwania. 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.
Rozważ następujące zalecenia dotyczące używania IaC dla obciążenia.
Używanie podejścia warstwowego dla potoków IaC
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 składających się z zasobów, których cykle życia wdrożenia lub czynniki takie jak funkcje są ściśle zgodne, 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 dotknięciu . W zależności od złożoności obciążenia może istnieć co najmniej jeden potok IaC o średnim dotyku i 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 baz danych. Warstwy o wysokim dotknięciu składają się z kontenerów aplikacji, które są bardzo często aktualizowane w trybie ciągłego dostarczania.
Traktuj kod IaC i aplikacji w taki sam sposób
Traktowanie artefaktów IaC tak samo jak artefakty kodu aplikacji pomaga zastosować ten sam rygor 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 elementami zawartości kodu aplikacji. Dzięki temu można upewnić się, że te same procesy są wykonywane przy każdym wdrożeniu i pomagają uniknąć problemów, takich jak przypadkowo wdrażanie infrastruktury przed wymaganym kodem aplikacji lub odwrotnie.
Korzystanie ze scentralizowanych standardów i zasobów
Współpracuj z innymi zespołami w organizacji w celu standaryzacji i możliwości ponownego zastosowania. 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 to robi, jest praktyczne.
Wymuszanie zabezpieczeń w kodzie IaC
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. Przeskanuj repozytoria IaC pod kątem kluczy i wpisów tajnych, które są widoczne. Jedną z zalet korzystania z IaC jest to, że członkowie zespołu skoncentrowanego na zabezpieczeniach mogą przejrzeć 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 projektowania.
Testowanie rutynowych i nie rutynowych działań. Wdrożenia testowe, aktualizacje konfiguracji i procesy odzyskiwania, w tym procesy wycofywania wdrożenia.
Wdrażanie niezmiennego modelu wdrażania
Wybór między wdrażaniem modyfikowalnej a niezmienną infrastrukturą zależy od kilku czynników. Jeśli obciążenie ma krytyczne znaczenie dla działania firmy, najlepiej użyć 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 praktyki wdrażania dyktują, że stopniowe wdrażanie przy użyciu wdrożeń, gdy wystąpią problemy z wdrażaniem z możliwością stosowania niezmiennego, jest preferowaną opcją. W takim przypadku prawdopodobnie zaktualizujesz infrastrukturę.
Kwestie wymagające rozważenia
Zwiększona specjalizacja: W niektórych przypadkach wprowadzenie nowych języków w zespole roboczym 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 chmury.
Zwiększenie nakładu pracy konserwacyjnego: konserwacja bazy kodu i narzędzi jest wymagana, aby zapewnić aktualność i bezpieczeństwo implementacji IaC. Właściwie śledzić dług techniczny i wspierać kulturę, w której jest nagradzane zmniejszenie zadłużenia.
Zwiększony czas wprowadzania 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ść modułyzacji: 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 platformy Azure
Szablony usługi Azure Resource Manager (szablony arm) i Bicep to natywne narzędzia platformy Azure do wdrażania infrastruktury przy użyciu składni deklaratywnej. Szablony usługi ARM są zapisywane w formacie JSON, natomiast Bicep jest językiem specyficznym dla domeny. Oba można łatwo zintegrować z potokami platformy Azure lub potokami ciągłej integracji/ciągłego wdrażania funkcji GitHub Actions.
Terraform to inne 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 dla Chmury można odnajdywać błędy konfiguracji w usłudze IaC.
Przykład
Zobacz architekturę akceleratora strefy docelowej usługi Azure Virtual Desktop i skojarzoną 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 usługi Resource Manager, Bicep lub Terraform.
Pokrewne łącza
- Co to jest infrastruktura jako kod (IaC)?
- Infrastruktura przedsiębiorstwa jako kod przy użyciu Bicep i usługi Azure Container Registry
- Odnajdywanie błędów konfiguracji w usłudze IaC
- Zalecenia dotyczące projektowania łańcucha dostaw dla obciążeń
- Zalecenia dotyczące standaryzacji narzędzi i procesów
- Zalecenia dotyczące zabezpieczania cyklu życia programowania
- Zalecenia dotyczące używania bezpiecznych praktyk wdrażania
- Wzorzec sygnatur wdrażania
- Szablony usługi Azure Resource Manager (szablony usługi ARM)
- Bicep
- Potoki platformy Azure
- Funkcja GitHub Actions
- Terraform
Lista kontrolna doskonałości operacyjnej
Zapoznaj się z pełnym zestawem zaleceń.