Infrastruktura jako kod
Napiwek
Ta zawartość jest fragmentem książki eBook, Architekting Cloud Native .NET Applications for Azure, dostępnej na platformie .NET Docs lub jako bezpłatny plik PDF do pobrania, który można odczytać w trybie offline.
Systemy natywne dla chmury obejmują mikrousługi, kontenery i nowoczesny projekt systemu w celu osiągnięcia szybkości i elastyczności. Zapewniają one zautomatyzowane etapy kompilacji i wydania, aby zapewnić spójny i jakościowy kod. Ale to tylko część historii. Jak aprowizować środowiska chmury, na których działają te systemy?
Nowoczesne aplikacje natywne dla chmury obejmują powszechnie akceptowaną praktykę infrastruktury jako kodu lub IaC. Dzięki usłudze IaC automatyzujesz aprowizację platformy. Zasadniczo stosujesz praktyki inżynieryjne oprogramowania, takie jak testowanie i przechowywanie wersji w praktykach DevOps. Infrastruktura i wdrożenia są zautomatyzowane, spójne i powtarzalne. Podobnie jak ciągłe dostarczanie zautomatyzowało tradycyjny model wdrożeń ręcznych, infrastruktura jako kod (IaC) ewoluuje w sposób zarządzania środowiskami aplikacji.
Narzędzia takie jak Azure Resource Manager (ARM), Terraform i interfejs wiersza polecenia platformy Azure umożliwiają deklaratywne tworzenie skryptów wymaganej infrastruktury w chmurze.
Szablony usługi Azure Resource Manager
Arm oznacza usługę Azure Resource Manager. Jest to aparat aprowizacji interfejsu API, który jest wbudowany na platformie Azure i udostępniany jako usługa interfejsu API. Usługa ARM umożliwia wdrażanie, aktualizowanie, usuwanie i zarządzanie zasobami zawartymi w grupie zasobów platformy Azure w ramach jednej skoordynowanej operacji. Aparat udostępnia szablon oparty na formacie JSON, który określa wymagane zasoby i ich konfigurację. Usługa ARM automatycznie organizuje wdrożenie w prawidłowej kolejności z uwzględnieniem zależności. Aparat zapewnia idempotentność. Jeśli żądany zasób już istnieje z tą samą konfiguracją, aprowizowanie zostanie zignorowane.
Szablony usługi Azure Resource Manager to język oparty na formacie JSON służący do definiowania różnych zasobów na platformie Azure. Podstawowy schemat wygląda podobnie do rysunku 10-14.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "",
"apiProfile": "",
"parameters": { },
"variables": { },
"functions": [ ],
"resources": [ ],
"outputs": { }
}
Rysunek 10–14 — schemat szablonu usługi Resource Manager
W tym szablonie można zdefiniować kontener magazynu wewnątrz sekcji zasobów w następujący sposób:
"resources": [
{
"type": "Microsoft.Storage/storageAccounts",
"name": "[variables('storageAccountName')]",
"location": "[parameters('location')]",
"apiVersion": "2018-07-01",
"sku": {
"name": "[parameters('storageAccountType')]"
},
"kind": "StorageV2",
"properties": {}
}
],
Rysunek 10–15 — przykład konta magazynu zdefiniowanego w szablonie usługi Resource Manager
Szablon usługi ARM można sparametryzować za pomocą informacji o środowisku dynamicznym i konfiguracji. Dzięki temu można używać go ponownie do definiowania różnych środowisk, takich jak programowanie, kontrola jakości lub produkcja. Zwykle szablon tworzy wszystkie zasoby w ramach jednej grupy zasobów platformy Azure. W razie potrzeby można zdefiniować wiele grup zasobów w jednym szablonie usługi Resource Manager. Wszystkie zasoby w środowisku można usunąć, usuwając samą grupę zasobów. Analiza kosztów może być również uruchamiana na poziomie grupy zasobów, co pozwala na szybkie rozliczanie kosztów poszczególnych środowisk.
Istnieje wiele przykładów szablonów usługi ARM dostępnych w projekcie Szablony szybkiego startu platformy Azure w witrynie GitHub. Mogą one pomóc przyspieszyć tworzenie nowego szablonu lub modyfikowanie istniejącego szablonu.
Szablony usługi Resource Manager można uruchamiać na wiele sposobów. Być może najprostszym sposobem jest po prostu wklejenie ich w witrynie Azure Portal. W przypadku wdrożeń eksperymentalnych ta metoda może być szybka. Można je również uruchamiać w ramach procesu kompilacji lub wydania w usłudze Azure DevOps. Istnieją zadania, które będą korzystać z połączeń z platformą Azure do uruchamiania szablonów. Zmiany w szablonach usługi Resource Manager są stosowane przyrostowo, co oznacza, że dodanie nowego zasobu wymaga tylko dodania go do szablonu. Narzędzie będzie uzgadniać różnice między bieżącymi zasobami a tymi zdefiniowanymi w szablonie. Zasoby zostaną następnie utworzone lub zmienione, aby były zgodne z definicją w szablonie.
Terraform
Aplikacje natywne dla chmury są często tworzone jako cloud agnostic. Oznacza to, że aplikacja nie jest ściśle połączona z określonym dostawcą chmury i może zostać wdrożona w dowolnej chmurze publicznej.
Terraform to komercyjne narzędzie do tworzenia szablonów, które umożliwia aprowizowanie aplikacji natywnych dla chmury dla wszystkich głównych graczy w chmurze: Azure, Google Cloud Platform, AWS i AliCloud. Zamiast używać formatu JSON jako języka definicji szablonu, używa nieco bardziej terse HCL (Hashicorp Configuration Language).
Przykładowy plik Programu Terraform, który wykonuje to samo co poprzedni szablon usługi Resource Manager (Rysunek 10-15) jest pokazany na rysunku 10-16:
provider "azurerm" {
version = "=1.28.0"
}
resource "azurerm_resource_group" "testrg" {
name = "production"
location = "West US"
}
resource "azurerm_storage_account" "testsa" {
name = "${var.storageAccountName}"
resource_group_name = "${azurerm_resource_group.testrg.name}"
location = "${var.region}"
account_tier = "${var.tier}"
account_replication_type = "${var.replicationType}"
}
Rysunek 10–16 — przykład szablonu usługi Resource Manager
Narzędzie Terraform udostępnia również intuicyjne komunikaty o błędach dla szablonów problemów. Istnieje również przydatne zadanie sprawdzania poprawności, które może być używane w fazie kompilacji do wczesnego przechwytywania błędów szablonu.
Podobnie jak w przypadku szablonów usługi Resource Manager, narzędzia wiersza polecenia są dostępne do wdrażania szablonów programu Terraform. Istnieją również zadania utworzone przez społeczność w usłudze Azure Pipelines, które mogą weryfikować i stosować szablony programu Terraform.
Czasami narzędzia Terraform i szablony usługi ARM generują znaczące wartości, takie jak parametry połączenia nowo utworzonej bazy danych. Te informacje mogą być przechwytywane w potoku kompilacji i używane w kolejnych zadaniach.
Skrypty i zadania interfejsu wiersza polecenia platformy Azure
Na koniec możesz użyć interfejsu wiersza polecenia platformy Azure do deklaratywnego tworzenia skryptów infrastruktury w chmurze. Skrypty interfejsu wiersza polecenia platformy Azure można tworzyć, znajdować i udostępniać w celu aprowizacji i konfigurowania niemal dowolnego zasobu platformy Azure. Interfejs wiersza polecenia jest prosty w użyciu z łagodną krzywą uczenia. Skrypty są wykonywane w programie PowerShell lub Bash. Są one również proste do debugowania, szczególnie w porównaniu z szablonami usługi ARM.
Skrypty interfejsu wiersza polecenia platformy Azure działają dobrze, gdy trzeba usunąć i ponownie wdrożyć infrastrukturę. Aktualizowanie istniejącego środowiska może być trudne. Wiele poleceń interfejsu wiersza polecenia nie jest idempotentnych. Oznacza to, że będą one tworzone ponownie za każdym razem, gdy są uruchamiane, nawet jeśli zasób już istnieje. Zawsze można dodać kod sprawdzający istnienie każdego zasobu przed jego utworzeniem. Ale w ten sposób skrypt może stać się wzdęty i trudne do zarządzania.
Te skrypty można również osadzać w potokach usługi Azure DevOps jako Azure CLI tasks. Wykonanie potoku wywołuje skrypt.
Rysunek 10-17 przedstawia fragment kodu YAML zawierający listę wersji interfejsu wiersza polecenia platformy Azure i szczegóły subskrypcji. Zwróć uwagę na to, jak polecenia interfejsu wiersza polecenia platformy Azure są uwzględniane w skry skrypicie wbudowanym.
- task: AzureCLI@2
displayName: Azure CLI
inputs:
azureSubscription: <Name of the Azure Resource Manager service connection>
scriptType: ps
scriptLocation: inlineScript
inlineScript: |
az --version
az account show
Rysunek 10–17 — skrypt interfejsu wiersza polecenia platformy Azure
W artykule What is Infrastructure as Code (Co to jest infrastruktura jako kod), Author Sam Guckenheimer opisuje, w jaki sposób "Zespoły, które implementują IaC, mogą szybko i na dużą skalę dostarczać stabilne środowiska. Zespoły unikaj ręcznej konfiguracji środowisk i wymuszają spójność, reprezentując żądany stan swoich środowisk za pośrednictwem kodu. Wdrożenia infrastruktury za pomocą modelu IaC są powtarzalne i zapobiegają problemom w środowisku wykonywania spowodowanym przez dryfowanie konfiguracji lub brakujące zależności. Zespoły DevOps mogą współpracować z ujednoliconym zestawem rozwiązań i narzędzi, aby dostarczać aplikacje i ich infrastrukturę pomocniczą szybko, niezawodnie i na dużą skalę".
