Infrastruktura jako kod

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 Azure Resource Manager

Arm oznacza usługę Azure Resource Manager. Jest to silnik aprowizacji API, który jest wbudowany na platformie Azure i dostępny 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. Dostarczasz silnikowi 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. Silnik 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 ARM dostępnych w projekcie Szablony szybkiego startu Azure na GitHubie. 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.

Terraformowanie

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, korzysta z nieco zwięźlejszego 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 Terraform i szablony ARM generują znaczące wartości, takie jak ciąg połączenia z nowo utworzoną bazą danych. Te informacje mogą być przechwytywane w potoku kompilacji i używane w kolejnych zadaniach.

Skrypty i zadania Azure CLI

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ż łatwe do debugowania, szczególnie w porównaniu z szablonami 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 system będzie odtwarzać zasób każdorazowo podczas uruchamiania, 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ę rozrośnięty i trudny do zarządzania.

Te skrypty można również osadzać w potokach usługi Azure DevOps jako Azure CLI tasks. Wykonanie potoku uruchamia 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 Azure CLI są uwzględniane w skrypcie 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 pożądany stan swoich środowisk za pomocą kodu. Wdrożenia infrastruktury z funkcją IaC są powtarzalne i uniemożliwiają problemy ze środowiskiem uruchomieniowym spowodowane dryfem konfiguracji lub brakującymi zależnościami. 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ę".