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

  • 10 мин

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

  • Портал Azure
  • Azure CLI
  • Azure PowerShell
  • Шаблоны Azure Resource Manager (JSON и Bicep)

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

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

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

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

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

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

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

Diagram that shows the infrastructure as code process using a source code repository with a template that deploys Azure resources.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В 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 подход декларативного кода выполняется с помощью шаблонов. Существует множество типов шаблонов, которые можно использовать, в том числе:

  • JSON
  • Bicep
  • Ansible от RedHat;
  • Terraform от HashiCorp.

Примечание.

Этот модуль посвящен использованию шаблонов Bicep.

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

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-05-01' = {
  name: 'mystorageaccount'
  location: 'eastus'
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    accessTier: 'Hot'
    supportsHttpsTrafficOnly: true
  }
}

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

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