Поделиться через


Инфраструктура как код

Совет

Это содержимое является фрагментом из электронной книги, архитектора облачных собственных приложений .NET для Azure, доступных в .NET Docs или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.

Cloud Native .NET apps for Azure eBook cover thumbnail.

Облачные системы принимают микрослужбы, контейнеры и современную систему для достижения скорости и гибкости. Они предоставляют автоматизированные этапы сборки и выпуска, чтобы обеспечить согласованный и качественный код. Но, это только часть истории. Как подготовить облачные среды, в которых выполняются эти системы?

Современные облачные приложения принимают широко принятую практику инфраструктуры как код или IaC. С помощью IaC вы автоматизируете подготовку платформы. Вы, по сути, применяете такие методики проектирования программного обеспечения, как тестирование и управление версиями к вашим методикам DevOps. Инфраструктура и развертывания являются автоматизированными, согласованными и повторяемыми. Так же, как непрерывная доставка автоматизирована традиционная модель ручного развертывания, инфраструктура как код (IaC) развивается способ управления средами приложений.

Такие инструменты, как Azure Resource Manager (ARM), Terraform и интерфейс командной строки Azure (CLI), позволяют декларативно создавать скрипты необходимой облачной инфраструктуры.

Шаблоны диспетчера ресурсов Azure

ARM обозначает Azure Resource Manager. Это модуль подготовки API, встроенный в Azure и предоставляемый в качестве службы API. ARM позволяет развертывать, обновлять, удалять ресурсы, содержащиеся в группе ресурсов Azure, в одной согласованной операции. Модуль предоставляет шаблон на основе JSON, указывающий необходимые ресурсы и их конфигурацию. ARM автоматически управляет развертыванием в правильном порядке с учетом зависимостей. Модуль обеспечивает идемпотентность. Если требуемый ресурс уже существует с той же конфигурацией, подготовка будет игнорироваться.

Шаблоны Azure Resource Manager — это язык на основе JSON для определения различных ресурсов в Azure. Базовая схема выглядит примерно так же, как рис. 10-14.

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "",
  "apiProfile": "",
  "parameters": {  },
  "variables": {  },
  "functions": [  ],
  "resources": [  ],
  "outputs": {  }
}

Рис. 10-14 . Схема шаблона Resource Manager

В этом шаблоне можно определить контейнер хранилища в разделе ресурсов, как показано ниже.

"resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "name": "[variables('storageAccountName')]",
      "location": "[parameters('location')]",
      "apiVersion": "2018-07-01",
      "sku": {
        "name": "[parameters('storageAccountType')]"
      },
      "kind": "StorageV2",
      "properties": {}
    }
  ],

Рис. 10-15 . Пример учетной записи хранения, определенной в шаблоне Resource Manager

Шаблон ARM можно параметризовать с помощью динамической среды и сведений о конфигурации. Это позволяет повторно использовать его для определения различных сред, таких как разработка, QA или рабочая среда. Как правило, шаблон создает все ресурсы в одной группе ресурсов Azure. При необходимости можно определить несколько групп ресурсов в одном шаблоне Resource Manager. Все ресурсы в среде можно удалить, удалив саму группу ресурсов. Анализ затрат также может выполняться на уровне группы ресурсов, что позволяет быстро с учетом стоимости каждой среды.

Существует множество примеров шаблонов ARM, доступных в проекте шаблонов быстрого запуска Azure на GitHub. Они могут помочь ускорить создание нового шаблона или изменение существующего.

Шаблоны Resource Manager можно запускать различными способами. Возможно, самым простым способом является просто вставить их в портал Azure. Для экспериментальных развертываний этот метод может быть быстрым. Они также могут выполняться как часть процесса сборки или выпуска в Azure DevOps. Существуют задачи, которые будут использовать подключения к Azure для запуска шаблонов. Изменения шаблонов Resource Manager применяются постепенно, что означает, что для добавления нового ресурса требуется просто добавить его в шаблон. Инструменты будут согласовывать различия между текущими ресурсами и теми, которые определены в шаблоне. Затем ресурсы будут созданы или изменены, чтобы они соответствовали определенным в шаблоне.

Terraform

Облачные приложения часто создаются cloud agnosticдля создания. Это означает, что приложение не тесно связано с конкретным поставщиком облака и может быть развернуто в любом общедоступном облаке.

Terraform — это коммерческое средство шаблонов, которое может подготавливать облачные приложения для всех основных облачных игроков: Azure, Google Cloud Platform, AWS и AliCloud. Вместо использования JSON в качестве языка определения шаблона используется немного более terse HCL (язык конфигурации Hashicorp).

Пример файла Terraform, который соответствует предыдущему шаблону Resource Manager (рис. 10-15), показан на рис. 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}"

}

Рис. 10-16 . Пример шаблона Resource Manager

Terraform также предоставляет интуитивно понятные сообщения об ошибках для шаблонов проблем. Существует также удобное задание проверки, которое можно использовать на этапе сборки для перехвата ошибок шаблона рано.

Как и в шаблонах Resource Manager, средства командной строки доступны для развертывания шаблонов Terraform. Существуют также задачи, созданные сообществом, в Azure Pipelines, которые могут проверять и применять шаблоны Terraform.

Иногда Terraform и шаблоны ARM выводятся значимые значения, например строка подключения в только что созданную базу данных. Эти сведения можно записать в конвейере сборки и использовать в последующих задачах.

Скрипты и задачи Azure CLI

Наконец, вы можете использовать Azure CLI для декларативного скрипта облачной инфраструктуры. Скрипты Azure CLI можно создавать, находить и совместно использовать для подготовки и настройки практически любого ресурса Azure. Интерфейс командной строки прост для использования с мягкой кривой обучения. Скрипты выполняются в PowerShell или Bash. Они также просты в отладке, особенно при сравнении с шаблонами ARM.

Скрипты Azure CLI хорошо работают, когда необходимо разорвать и повторно развертывать инфраструктуру. Обновление существующей среды может быть сложной задачей. Многие команды CLI не являются идемпотентными. Это означает, что они будут повторно создавать ресурс при каждом запуске, даже если ресурс уже существует. Всегда можно добавить код, который проверка для существования каждого ресурса перед его созданием. Но, делая это, ваш сценарий может стать большим и трудным для управления.

Эти скрипты также могут быть внедрены в конвейеры Azure DevOps как Azure CLI tasks. Выполнение конвейера вызывает скрипт.

На рисунке 10-17 показан фрагмент YAML, который содержит версию Azure CLI и сведения о подписке. Обратите внимание, как команды Azure CLI включены в встроенный скрипт.

- 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

Рис. 10-17 . Сценарий Azure CLI

В статье " Что такое инфраструктура как код, автор Сэм Гукенхаймер описывает, как"Teams, реализующие IaC, могут быстро и масштабировать стабильные среды. Teams избегают ручной настройки сред и обеспечивают согласованность путем представления требуемого состояния сред с помощью кода. Развертывания инфраструктуры с помощью модели IaC являются повторяемыми и предотвращают проблемы во время выполнения, вызванные смещением конфигурации или отсутствием зависимостей. Команды DevOps могут работать вместе с единым набором методик и инструментов для доставки приложений и их вспомогательной инфраструктуры быстро, надежно и в масштабе".