Infrastruktura jako kod
Infrastruktura jako kod (IaC) to kluczowa praktyka DevOps obejmująca zarządzanie infrastrukturą, taką jak sieci, usługi obliczeniowe, bazy danych, magazyny i topologia połączeń w modelu opisowym. IaC umożliwia zespołom szybsze opracowywanie i wydawanie zmian oraz większe zaufanie. Zalety IaC obejmują:
- Zwiększone zaufanie do wdrożeń
- Możliwość zarządzania wieloma środowiskami
- Ulepszone zrozumienie stanu infrastruktury
Aby uzyskać więcej informacji na temat zalet używania infrastruktury jako kodu, zobacz Powtarzalna infrastruktura.
Narzędzia
Istnieją dwa podejścia, które można podjąć podczas implementowania infrastruktury jako kodu.
- Infrastruktura imperatywne jako kod obejmuje pisanie skryptów w językach, takich jak powłoka Bash lub program PowerShell. Jawnie określasz polecenia, które są wykonywane w celu wygenerowania żądanego wyniku. W przypadku korzystania z wdrożeń imperatywnych można zarządzać sekwencją zależności, kontrolą błędów i aktualizacjami zasobów.
- Deklaratywna infrastruktura jako kod obejmuje napisanie definicji, która definiuje sposób, w jaki środowisko ma wyglądać. W tej definicji określisz żądany wynik, a nie sposób, w jaki ma zostać osiągnięty. Narzędzia dowiesz się, jak dokonać wyniku, sprawdzając bieżący stan, porównując go ze stanem docelowym, a następnie stosując różnice.
Szablony usługi ARM
Przejrzyj informacje o szablonach usługi Azure Resource Manager (szablony usługi ARM).
Bicep
Bicep to język specyficzny dla domeny (DSL), który używa składni deklaratywnej do wdrażania zasobów platformy Azure. W plikach Bicep zdefiniujesz infrastrukturę, którą zamierzasz wdrożyć i jej właściwości. W porównaniu z szablonami usługi ARM pliki Bicep są łatwiejsze do odczytania i zapisu dla odbiorców innych niż deweloperzy, ponieważ używają zwięzłej składni.
param location string = resourceGroup().location
param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}'
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = {
name: storageAccountName
location: location
sku: {
name: 'Standard_LRS'
}
kind: 'StorageV2'
properties: {
accessTier: 'Hot'
}
}
Terraform
Przejrzyj informacje o programie Terraform.
Interfejs wiersza polecenia platformy Azure
Przejrzyj informacje o interfejsie wiersza polecenia platformy Azure.
Infrastruktura jako moduły kodu
Jednym z celów używania kodu do wdrażania infrastruktury jest unikanie duplikowania pracy lub tworzenia wielu szablonów dla tych samych lub podobnych celów. Moduły infrastruktury powinny być wielokrotnego użytku i elastyczne i powinny mieć jasny cel.
Moduły są niezależnymi plikami, zwykle zawierającymi zestaw zasobów przeznaczonych do wdrożenia razem. Moduły umożliwiają podzielenie złożonych szablonów na mniejsze, bardziej zarządzane zestawy kodu. Każdy moduł koncentruje się na określonym zadaniu i że wszystkie moduły są wielokrotnego użytku dla wielu wdrożeń i obciążeń.
Moduły Bicep
Bicep umożliwia tworzenie i wywoływanie modułów. Po utworzeniu modułów można ich używać z dowolnego innego szablonu Bicep. Moduł Bicep wysokiej jakości powinien definiować wiele powiązanych zasobów. Na przykład podczas definiowania funkcji platformy Azure zazwyczaj wdrażasz określoną aplikację, plan hostingu dla tej aplikacji i konto magazynu dla metadanych tej aplikacji. Te składniki są definiowane oddzielnie, ale tworzą logiczne grupowanie zasobów, dlatego należy rozważyć zdefiniowanie ich razem jako modułu.
Często używane moduły Bicep:
- Parametry do akceptowania wartości z modułu wywołującego.
- Wartości wyjściowe zwracające wyniki do modułu wywołującego.
- Zasoby do zdefiniowania co najmniej jednego obiektu infrastruktury dla modułu do zarządzania.
Publikowanie modułów Bicep
Istnieje kilka opcji publikowania i udostępniania modułów Bicep.
- Rejestr publiczny: Rejestr modułów publicznych jest hostowany w rejestrze kontenerów firmy Microsoft (MCR). Jego kod źródłowy i zawarte w nim moduły są przechowywane w usłudze GitHub.
- Rejestr prywatny: Rejestr kontenerów platformy Azure umożliwia publikowanie modułów w rejestrze prywatnym. Aby uzyskać informacje na temat publikowania modułów w rejestrze w potoku ciągłej integracji/ciągłego wdrażania, zobacz Bicep i GitHub Actions lub jeśli wolisz, Bicep i Azure Pipelines.
- Specyfikacja szablonu: Do publikowania modułów Bicep można użyć specyfikacji szablonu . Specyfikacje szablonów mają być kompletne szablony, ale Bicep umożliwia wdrażanie modułów przy użyciu specyfikacji szablonu.
- System kontroli wersji: Moduły można ładować bezpośrednio z narzędzi kontroli wersji, takich jak GitHub lub Azure DevOps.
Moduły programu Terraform
Narzędzie Terraform umożliwia tworzenie i wywoływanie modułów. Każda konfiguracja programu Terraform ma co najmniej jeden moduł, znany jako jego moduł główny, składający się z zasobów zdefiniowanych w .tf
plikach w głównym katalogu roboczym. Każdy moduł może wywoływać inne moduły, co umożliwia dołączanie modułów podrzędnych do głównego pliku konfiguracji. Moduły mogą być również wywoływane wiele razy w ramach tej samej konfiguracji lub z różnych konfiguracji.
Moduły są definiowane ze wszystkimi tymi samymi pojęciami dotyczącymi języka konfiguracji. Najczęściej są one używane:
- Zmienne wejściowe do akceptowania wartości z modułu wywołującego.
- Wartości wyjściowe zwracające wyniki do modułu wywołującego.
- Zasoby do zdefiniowania co najmniej jednego obiektu infrastruktury dla modułu do zarządzania.
Publikowanie modułów programu Terraform
Istnieje kilka opcji publikowania i udostępniania modułów programu Terraform:
- Rejestr publiczny: HashiCorp ma własny rejestr modułów Terraform, który umożliwia użytkownikom generowanie współużytkowalnych modułów terraform. Obecnie w rejestrze modułów programu Terraform opublikowano kilka modułów platformy Azure .
- Rejestr prywatny: Moduły programu Terraform można bezproblemowo publikować w prywatnym repozytorium, na przykład terraform Cloud Private Registry lub Azure Container Registry.
- System kontroli wersji: Moduły prywatne można ładować bezpośrednio z narzędzi kontroli wersji, takich jak GitHub. Aby uzyskać informacje na temat obsługiwanych źródeł, zobacz Terraform module sources (Źródła modułów narzędzia Terraform).
Zagadnienia dotyczące projektowania
Rozważ użycie IaC podczas wdrażania zasobów strefy docelowej na platformie Azure. Usługa IaC w pełni realizuje optymalizację wdrażania, zmniejsza nakład pracy nad konfiguracją i automatyzuje wdrożenia całego środowiska.
Określ, czy należy podjąć podejście imperatywne lub deklaratywne IaC.
W przypadku podejścia imperatywnego jawnie uruchamiane polecenia, które generują żądany wynik.
Jeśli przyjmujesz podejście deklaratywne, określ żądany wynik, a nie sposób, w jaki chcesz to zrobić.
Rozważ zakresy wdrożenia. Dobrze zrozumieć poziomy zarządzania i hierarchię platformy Azure. Każde wdrożenie IaC musi znać zakres wdrażania zasobów platformy Azure.
Ustal, czy należy użyć natywnego narzędzia IaC platformy Azure, czy platformy Azure. Oto niektóre ważne kwestie:
Narzędzia natywne platformy Azure, takie jak interfejs wiersza polecenia platformy Azure, szablony usługi ARM i Bicep, są w pełni obsługiwane przez firmę Microsoft, co umożliwia szybsze integrowanie nowych funkcji.
Narzędzia inne niż natywne, takie jak Terraform, umożliwiają zarządzanie infrastrukturą jako kodem dla wielu dostawców chmury, takich jak AWS lub GCP. Jednak nowe funkcje platformy Azure mogą zająć trochę czasu, aby można je było uwzględnić w środowisku nie natywnym. Jeśli Twoja organizacja jest wielochmurowa lub twoja organizacja już używa i dobrze zorientowana w narzędziu Terraform, rozważ użycie narzędzia Terraform do wdrożenia stref docelowych platformy Azure.
Ponieważ moduły umożliwiają podzielenie złożonych szablonów na mniejsze zestawy kodu, rozważ użycie modułów IaC dla zasobów, które są często wdrażane razem. Każdy moduł koncentruje się na określonym zadaniu i jest wielokrotnego użytku dla wielu wdrożeń i obciążeń.
Rozważ wdrożenie strategii publikowania dla modułów IaC, wybierając między rejestrami publicznymi, prywatnymi rejestrami lub systemem kontroli wersji, takimi jak repozytorium Git.
Rozważ użycie potoku ciągłej integracji/ciągłego wdrażania dla wdrożeń IaC. Potok wymusza ustawiony proces wielokrotnego użytku, aby zapewnić jakość wdrożeń i środowiska platformy Azure.
Zalecenia dotyczące projektowania
Zastosuj podejście IaC do wdrażania wdrożeń strefy docelowej platformy Azure, zarządzania nimi i zarządzania nimi.
Użyj narzędzi natywnych platformy Azure dla IaC w następujących scenariuszach:
Chcesz używać tylko narzędzi natywnych platformy Azure. Twoja organizacja może mieć wcześniejsze środowisko wdrażania szablonu arm lub Bicep.
Twoja organizacja chce mieć natychmiastową pomoc techniczną dla wszystkich wersji zapoznawczych i ogólnie dostępnej wersji usług platformy Azure.
W następujących scenariuszach użyj narzędzi innych niż natywne dla IaC:
Twoja organizacja obecnie używa narzędzia Terraform do wdrażania infrastruktury w innych chmurach, takich jak AWS lub GCP.
Twoja organizacja nie musi mieć natychmiastowej pomocy technicznej dla wszystkich wersji zapoznawczych i ogólnie dostępnej wersji usług platformy Azure.
Użyj modułów IaC wielokrotnego użytku, aby uniknąć powtarzalnej pracy. Moduły można udostępniać w całej organizacji, aby wdrażać wiele projektów lub obciążeń i zarządzać mniej złożonym kodem.
Publikowanie i używanie modułów IaC z publicznych rejestrów w następujących scenariuszach:
Chcesz użyć modułów dla strefy docelowej platformy Azure, która została już opublikowana w publicznych rejestrach. Aby uzyskać więcej informacji, zobacz moduł Terraform stref docelowych platformy Azure.
Chcesz używać modułów obsługiwanych, aktualizowanych i obsługiwanych przez firmy Microsoft, Terraform lub innych dostawców modułów.
- Upewnij się, że sprawdzasz instrukcję pomocy technicznej od dowolnego dostawcy modułu, który oceniasz.
Publikowanie i używanie modułów IaC z prywatnych rejestrów lub systemów kontroli wersji w następujących scenariuszach:
Chcesz utworzyć własne moduły na podstawie wymagań organizacji.
Chcesz mieć pełną kontrolę nad wszystkimi funkcjami i konserwować, aktualizować i publikować nowe wersje modułów.
Użyj potoku ciągłej integracji/ciągłego wdrażania, aby wdrożyć artefakty IaC i zapewnić jakość wdrożeń i środowisk platformy Azure.