Что такое "Инфраструктура как код"?

  • 10 мин

Оцените, может ли инфраструктура как код быть ценным подходом к подготовке ресурсов в вашей компании. Вы просматриваете доступные варианты развертывания, включая:

  • Портал Azure
  • Azure CLI (Интерфейс командной строки для Azure)
  • Azure PowerShell
  • Шаблоны Azure Resource Manager (JSON и Bicep)
  • Терраформирование

Вы ищете воспроизводимый вариант, а также вам нужно решить, какую технологию использовать для развертывания инфраструктуры Azure.

В этом уроке описывается, почему инфраструктура как код поможет вам развернуть инфраструктуру Azure автоматически и повторяемо.

Команды Azure CLI используются для иллюстрации концепций. В этом уроке рассматриваются команды для развертывания ресурсов в других модулях схемы обучения Terraform.

Определение подхода "Инфраструктура как код"

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

Подход "Инфраструктура как код" можно представить в виде руководства по эксплуатации для вашей инфраструктуры. В руководстве содержатся подробные сведения о конечной конфигурации ресурсов и о способе достижения этого состояния конфигурации.

Инфраструктура как код — это процесс автоматизации подготовки инфраструктуры. В нем используется декларативный язык программирования и система управления версиями, аналогичная тому, что используется для исходного кода. При создании приложения исходный код создает один и тот же результат для каждой компиляции. Развертывания на основе подхода "инфраструктура как код" точно так же автоматизированы, согласованы и воспроизводимы. Инфраструктура как код может автоматизировать развертывание ваших ресурсов. Такие как виртуальные сети, виртуальные машины, приложения, хранилище и даже репозитории GitHub или учетные записи пользователей.

Схема, показывающая инфраструктуру как процесс кода с помощью репозитория исходного кода с модулем, который развертывает ресурсы Azure.

Вспомним, что руководство по эксплуатации новой игрушки можно написать разными способами. Один из вариантов — подробно описать каждый этап процесса сборки. Другой вариант — показать развернутое представление элементов и частей, необходимых для сборки игрушки. В этом уроке рассматриваются различия между императивным и декларативным кодом и тем, как они связаны с инструкциями вашей компании.

Зачем использовать подход "Инфраструктура как код"?

Внедрение подхода "Инфраструктура как код" предоставляет множество преимуществ для подготовки ресурсов. С помощью этого подхода можно:

  • повысить доверительный уровень в развертываниях;
  • управлять несколькими окружениями;
  • лучше понять облачные ресурсы.

Повышение доверительного уровня

Одним из преимуществ использования подхода "Инфраструктура как код" является доверительный уровень, который вы получаете при развертывании за счет улучшения согласованности и безопасности.

  • Интеграция с текущими процессами: если ваша организация уже использует стандартные методики разработки программного обеспечения, вы можете внедрить те же процессы для развертываний инфраструктуры. Например, проверки одноранговых узлов и статический анализ могут помочь в обнаружении проблем в конфигурациях, которые могут быть трудно обнаружить при внесении изменений вручную.

  • Согласованность. Внедрение подхода "Инфраструктура как код" помогает вашей команде следовать хорошо зарекомендовавшим себя процессам для развертывания инфраструктуры. Следуя этим процессам, ответственность переходит от небольшой группы лиц к процессу автоматизации и средствам. Подход "Инфраструктура как код" позволяет уменьшить воздействие человеческого фактора при подготовке ресурсов и обеспечить согласованные развертывания.

  • Автоматическое сканирование: инфраструктура как сканирование кода с помощью автоматических проверок ошибок в коде. Автоматизированное средство также может просматривать предлагаемые изменения, чтобы обеспечить соблюдение рекомендаций по обеспечению безопасности и производительности.

  • Управление секретами. Во многих решениях требуются секреты, такие как строки подключения, ключи шифрования, секреты клиента и сертификаты. В Azure Хранилище ключей Azure — это служба, используемая для безопасного хранения этих секретов. Многие средства инфраструктуры как кода могут интегрироваться с Key Vault для безопасного доступа к этим секретам во время развертывания. Или еще лучше, используйте федерацию удостоверений рабочей нагрузки и управляемые удостоверения.

  • Управление доступом. Развертывания подхода "Инфраструктура как код" позволяют использовать управляемые удостоверения или учетные записи служб для автоматизации подготовки ресурсов. Блокировка доступа пользователей предотвращает неправильные конфигурации, развернутые в рабочей среде. При необходимости вы можете переопределить этот процесс с помощью учетной записи аварийного доступа (часто называемой учетной записью разбиения) или с помощью функции управление привилегированными пользователями идентификатора Microsoft Entra.

  • Избегайте смещения конфигурации: Idempotence — это термин, связанный с инфраструктурой в качестве кода. Если операция идемпотентна, это означает, что она обеспечивает одинаковый результат для каждого запуска. При выборе средств, использующих идемпотентные операции, можно избежать отклонения конфигурации.

В качестве примера идемпотенса рассмотрим следующую команду Azure CLI. Команда создает группу ресурсов Azure с именем storage-resource-group в регионе "Восточная часть США".

az group create \
  --name storage-resource-group \
  --location eastus

При выполнении этой команды во второй раз вы получите те же выходные данные, так как эта команда Azure CLI была разработана для идемпотентной. Вы не получаете ошибку или дубликат группы ресурсов.

Когда вы используете подход "Инфраструктура как код", вы можете повторно развернуть окружение при каждом выпуске решения. Эти выпуски могут содержать небольшие изменения конфигурации или даже значительные обновления. Этот процесс позволяет избежать отклонения конфигурации. При случайном изменении ресурса его можно исправить, повторно развернув конфигурацию. Следуя этому подходу, вы документируете свое окружение с помощью кода.

Управление несколькими средами

Многие организации поддерживают несколько окружений приложений. Разработчики в вашей компании могут иметь несколько версий кода приложения, поэтапного в репозитории для выпуска в разных средах. Это могут быть окружения для разработки, тестирования, а также рабочие среды. Некоторые организации поддерживают несколько рабочих сред для приложений, которые распределены глобально. Другие организации, такие как независимые поставщики программного обеспечения (ISV), поддерживают несколько сред клиента для своих клиентов.

Ниже приведены некоторые основные способы, с помощью которых подход "Инфраструктура как код" может помочь в управлении окружениями.

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

  • Непроизводственные среды: распространенные проблемы организации сталкиваются с различиями между производственными и непроизводственных средами. При подготовке ресурсов вручную в отдельных средах возможно, что конечные конфигурации не совпадают. Примером является развертывание новой функции в непроизводственных средах, отличающихся от рабочей среды. Возможно, что новая функция не работает должным образом в рабочей среде из-за различий между двумя средами. Использование подхода "Инфраструктура как код" позволяет уменьшить эти проблемы. Вы можете использовать одни и те же файлы конфигурации для каждого окружения, но предоставить различные входные параметры, чтобы создать уникальность. Кроме того, вы можете быть экономичными, отключая непроизводственные среды, когда они не используются.

  • Аварийное восстановление. В некоторых ситуациях подход "Инфраструктура как код" можно использовать как часть плана аварийного восстановления организации. Например, вам может понадобиться повторно создать окружение в другом регионе из-за сбоя службы. Используя подход "Инфраструктура как код", можно быстро подготовить новый экземпляр, чтобы выполнить отработку отказа, вместо того чтобы вручную все развертывать и перенастраивать.

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

Подход "Инфраструктура как код" поможет лучше понять состояние облачных ресурсов:

  • Аудит тропы. Изменения конфигураций инфраструктуры как кода управляются версией так же, как и исходный код приложения. Эти изменения отслеживаются в средствах, как и в журнале версий Git. Этот журнал аудита означает, что вы можете просматривать сведения о каждом изменении, о том, кто его внес и когда. Если вы используете средство непрерывной доставки, вы также можете обратиться к подробным журналам развертывания и увидеть, что произошло в каждом обновлении.

  • Документация. Многие конфигурации на основе подхода "инфраструктура как код" позволяют добавлять метаданные, например комментарии, которые описывают назначение кода в конфигурации. Если ваша организация уже использует процесс документирования кода, рассмотрите возможность внедрения этих же процедур с кодом инфраструктуры.

  • Единая система. Зачастую, если разработчик работает над новой функцией, он должен внести изменения в код приложения и код инфраструктуры. При использовании общей системы ваша организация может лучше понять связь между приложениями и инфраструктурой.

  • Более полное представление об облачной инфраструктуре. При использовании портала Azure для подготовки ресурсов многие из этих процессов абстрагируются от представления. Подход "Инфраструктура как код" позволяет лучше понять, как работает Azure и как устранять проблемы, которые могут возникнуть. Например, при создании виртуальной машины с помощью портала Azure некоторые созданные ресурсы абстрагируются от представления. Управляемые диски и сетевые адаптеры развертываются в фоновом режиме. При развертывании той же виртуальной машины с помощью подхода "Инфраструктура как код" у вас есть полный контроль над всеми созданными ресурсами. При использовании Terraform также есть файл состояния, содержащий множество сведений о развернутых ресурсах, которые можно использовать для получения сведений или использования для обнаружения смещения.

Императивный и декларативный код

Написать руководство по эксплуатации для сборки новой игрушки можно разными способами. При автоматизации развертывания служб и инфраструктуры можно применять два подхода: императивный и декларативный.

  • При использовании императивного кода для достижения конечной конфигурации выполняется последовательность команд в определенном порядке. Этот процесс определяет, что должен выполнять код и как выполнять задачу. Императивный подход похож на пошаговое руководство по эксплуатации.

  • При использовании декларативного кода указывается только конечная конфигурация. Код не определяет, как выполнить задачу. Декларативный подход похож на руководство по эксплуатации с развернутым представлением.

При выборе между использованием императивного и декларативного подхода для подготовки ресурсов следует рассмотреть средства, которые могут уже использоваться в организации. Подумайте также о том, какой подход может соответствовать вашим навыкам.

Императивный код

В Azure подход императивного кода выполняется программно с помощью языка сценариев, такого как Bash или Azure PowerShell. Сценарии выполняют ряд действий для создания, изменения и даже удаления ресурсов.

В этом примере показаны две команды Azure CLI, которые создают группу ресурсов и учетную запись хранения.

#!/usr/bin/env bash
az group create \
  --name storage-resource-group \
  --location eastus

az storage account create \
  --name mystorageaccount \
  --resource-group storage-resource-group \
  --location eastus \
  --sku Standard_LRS \
  --kind StorageV2 \
  --access-tier Hot \
  --https-only true

Первая команда создает группу ресурсов под названием storage-resource-group в регионе "Восточная часть США". Вторая команда создает учетную запись хранения с именем mystorageaccount в storage-resource-group группе ресурсов, созданной в первой команде. Вторая команда также настраивает некоторые свойства для учетной записи хранения, включая тип учетной записи хранения и его уровень доступа.

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

Декларативный код

В Azure декларативный подход к коду осуществляется с помощью шаблонов или модулей. Многие типы доступны для использования, в том числе:

  • Terraform от HashiCorp.
  • Бицепс
  • ARM JSON

Примечание.

В этом модуле основное внимание уделяется использованию модулей Terraform.

Ознакомьтесь со следующим примером модуля Terraform, который настраивает учетную запись хранения. Конфигурация учетной записи хранения соответствует примеру Azure CLI.

resource "azurerm_resource_group" "example" {
  name     = "storage-resource-group"
  location = "eastus"
}

resource "azurerm_storage_account" "example" {
  name                      = "mystorageaccount"
  location                  = azurerm_resource_group.example.location
  resource_group_name       = azurerm_resource_group.example.name
  sku                       = "Standard"
  account_replication_type  = "GRS"
  account_kind              = "StorageV2"
  access_tier               = "Hot"
  enable_https_traffic_only = true
}

Блоки ресурсов определяют конфигурацию группы ресурсов и учетной записи хранения. Блок azurerm_storage_account содержит имя, расположение и свойства учетной записи хранения, включая номер SKU и тип учетной записи.

Вы можете заметить, что модуль Terraform не указывает, как развернуть учетную запись хранения. Он указывает только то, как должна выглядеть учетная запись хранения. Действия по созданию или обновлению этой учетной записи хранения остаются для интерфейса командной строки Terraform и поставщика azurerm Terraform, чтобы решить.