Инфраструктура как код
Инфраструктура как код (IaC) — это ключевая практика DevOps, которая включает в себя управление инфраструктурой, например сетями, вычислительными службами, базами данных, хранилищами и топологией подключений, в описательной модели. IaC позволяет командам разрабатывать и выпускать изменения быстрее и с большей уверенностью. Преимущества IaC:
- Повышение доверия к развертываниям
- Возможность управления несколькими средами
- Улучшенное понимание состояния инфраструктуры
Дополнительные сведения о преимуществах использования инфраструктуры как кода см. в разделе Повторяемая инфраструктура.
Инструментарий
Существует два подхода, которые можно использовать при реализации инфраструктуры как кода.
- Императивная инфраструктура как код включает написание скриптов на таких языках, как Bash или PowerShell. Вы явно указываете команды, которые выполняются для получения желаемого результата. При использовании императивных развертываний вы можете управлять последовательностью зависимостей, контролем ошибок и обновлениями ресурсов.
- Декларативная инфраструктура как код включает в себя написание определения, определяющего, как будет выглядеть среда. В этом определении вы указываете желаемый результат, а не способ его выполнения. Инструментарий определяет, как добиться результата, проверяя текущее состояние, сравнивая его с целевым состоянием, а затем применяя различия.
Шаблоны ARM
Ознакомьтесь со сведениями о шаблонах Resource Manager Azure (ARM).
Bicep
Bicep — это предметно-ориентированный язык (DSL), который использует декларативный синтаксис для развертывания ресурсов Azure. В файлах Bicep вы определяете инфраструктуру, которую планируется развернуть, и ее свойства. По сравнению с шаблонами ARM файлы Bicep проще читать и записывать для аудитории, не являющейся разработчиком, так как они используют краткий синтаксис.
param location string = resourceGroup().location
param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}'
resource storageAccount 'Microsoft.Storage/storageAccounts@2021-06-01' = {
name: storageAccountName
location: location
sku: {
name: 'Standard_LRS'
}
kind: 'StorageV2'
properties: {
accessTier: 'Hot'
}
}
Terraform
Просмотрите сведения о Terraform.
Azure CLI
Ознакомьтесь со сведениями об Azure CLI.
Модули инфраструктуры как кода
Одна из целей использования кода для развертывания инфраструктуры заключается в том, чтобы избежать дублирования работы или создания нескольких шаблонов для одинаковых или схожих целей. Модули инфраструктуры должны быть многократно используемыми и гибкими и иметь четкую цель.
Модули — это независимые файлы, обычно содержащие набор ресурсов, предназначенных для совместного развертывания. Модули позволяют разбить сложные шаблоны на небольшие, более управляемые наборы кода. Вы можете убедиться, что каждый модуль посвящен определенной задаче и что все модули можно повторно использовать для нескольких развертываний и рабочих нагрузок.
Модули Bicep
Bicep позволяет создавать и вызывать модули. После создания модулей их можно использовать из любого другого шаблона Bicep. Высококачественный модуль Bicep должен определять несколько связанных ресурсов. Например, при определении функции Azure обычно развертывается определенное приложение, план размещения для этого приложения и учетная запись хранения для метаданных этого приложения. Эти компоненты определяются отдельно, но они образуют логическую группу ресурсов, поэтому их следует определить вместе как модуль.
Модули Bicep обычно используют:
- Параметры для приема значений из вызывающего модуля.
- Выходные значения для возврата результатов в вызывающий модуль.
- Ресурсы для определения одного или нескольких объектов инфраструктуры для управляемого модуля.
Публикация модулей Bicep
Существует несколько вариантов публикации и совместного использования модулей Bicep.
- Общедоступный реестр: Общедоступный реестр модулей размещается в реестре контейнеров Майкрософт (MCR). Его исходный код и содержащиеся в нем модули хранятся в GitHub.
- Частный реестр: Реестр контейнеров Azure можно использовать для публикации модулей в частном реестре. Сведения о публикации модулей в реестре в конвейере CI/CD см. в статье Bicep и GitHub Actions или, если вы предпочитаете, Bicep и Azure Pipelines.
- Спецификация шаблона:Спецификации шаблонов можно использовать для публикации модулей Bicep. Спецификации шаблонов — это полные шаблоны, но Bicep позволяет использовать спецификации шаблонов для развертывания модулей.
- Система управления версиями: Вы можете загружать модули непосредственно из средств управления версиями, таких как GitHub или Azure DevOps.
Модули Terraform
Terraform позволяет создавать и вызывать модули. Каждая конфигурация Terraform имеет по крайней мере один модуль, известный как корневой модуль, состоящий из ресурсов, определенных в .tf
файлах в main рабочем каталоге. Каждый модуль может вызывать другие модули, что позволяет включать дочерние модули в файл конфигурации main. Модули также можно вызывать несколько раз в одной конфигурации или из разных конфигураций.
Модули определяются с одинаковыми понятиями языка конфигурации. Чаще всего в них используются:
- Входные переменные для приема значений из вызывающего модуля.
- Выходные значения для возврата результатов в вызывающий модуль.
- Ресурсы для определения одного или нескольких объектов инфраструктуры для управляемого модуля.
Публикация модулей Terraform
Существует несколько вариантов публикации и совместного использования модулей Terraform:
- Общедоступный реестр: HashiCorp имеет собственный реестр модулей Terraform, который позволяет пользователям создавать общие модули Terraform. В настоящее время в реестре модулей Terraform опубликовано несколько модулей Azure .
- Частный реестр: Вы можете легко публиковать модули Terraform в частном репозитории, например в частном реестре Terraform Cloud или Реестр контейнеров Azure.
- Система управления версиями: Частные модули можно загрузить непосредственно из средств управления версиями, таких как GitHub. Сведения о поддерживаемых источниках см. в разделе Источники модуля Terraform.
Рекомендации по проектированию
Рассмотрите возможность использования IaC при развертывании ресурсов целевой зоны в Azure. IaC полностью реализует оптимизацию развертывания, сокращает затраты на настройку и автоматизирует развертывание всей среды.
Определите, следует ли использовать императивный или декларативный подход IaC.
Если вы используете императивный подход, явно указывайте выполняемые команды, которые дают желаемый результат.
Если вы используете декларативный подход, укажите нужный результат, а не способ его выполнения.
Рассмотрим области развертывания. Хорошо разобравшись в уровнях управления и иерархии Azure. Каждое развертывание IaC должно знать область, в котором развертываются ресурсы Azure.
Определите, следует ли использовать собственное средство IaC Azure или средство Azure, не являющееся собственным. Учитывайте следующие факторы.
Собственные средства Azure, такие как Azure CLI, шаблоны ARM и Bicep, полностью поддерживаются корпорацией Майкрософт, что позволяет быстрее интегрировать новые функции.
Неуправляемые средства, такие как Terraform, позволяют управлять инфраструктурой как кодом нескольких поставщиков облачных служб, таких как AWS или GCP. Однако для включения новых функций Azure может потребоваться некоторое время. Если ваша организация является многооблачной или ваша организация уже использует и хорошо разбирается в Terraform, рассмотрите возможность использования Terraform для развертывания целевых зон Azure.
Так как модули позволяют разбить сложные шаблоны на небольшие наборы кода, рассмотрите возможность использования модулей IaC для ресурсов, которые обычно развертываются вместе. Вы можете убедиться, что каждый модуль посвящен определенной задаче и можно повторно использовать для нескольких развертываний и рабочих нагрузок.
Рассмотрите возможность внедрения стратегии публикации для модулей IaC, выбрав между общедоступными реестрами, частными реестрами или системой управления версиями, например репозиторием Git.
Рассмотрите возможность использования конвейера CI/CD для развертываний IaC. Конвейер применяет повторно используемый процесс, который вы задали, чтобы обеспечить качество развертываний и среды Azure.
Рекомендации по проектированию
Применяйте подход IaC к развертыванию, управлению, администрированию и поддержке развертываний целевой зоны Azure.
Используйте собственные средства Azure для IaC в следующих сценариях:
Вы хотите использовать только собственные средства Azure. В вашей организации может быть предварительное развертывание шаблона ARM или Bicep.
Ваша организация хочет получить немедленную поддержку для всех предварительных и общедоступных версий служб Azure.
Используйте не машинные средства для IaC в следующих сценариях:
В настоящее время ваша организация использует Terraform для развертывания инфраструктуры в других облаках, таких как AWS или GCP.
Вашей организации не требуется немедленная поддержка всех предварительных и общедоступных версий служб Azure.
Используйте многократно используемые модули IaC, чтобы избежать повторяющихся работ. Вы можете совместно использовать модули в организации для развертывания нескольких проектов или рабочих нагрузок и управления менее сложным кодом.
Публикуйте и используйте модули IaC из общедоступных реестров в следующих сценариях:
Вы хотите использовать модули для целевой зоны Azure, уже опубликованные в общедоступных реестрах. Дополнительные сведения см. в статье Модуль Terraform целевых зон Azure.
Вы хотите использовать модули, которые поддерживаются, обновляются и поддерживаются корпорацией Майкрософт, Terraform или другими поставщиками модулей.
- Убедитесь, что вы проверка заявление о поддержке от любого поставщика модуля, который вы оцениваете.
Публикуйте и используйте модули IaC из частных реестров или систем управления версиями в следующих сценариях:
Вы хотите создать собственные модули в соответствии с требованиями организации.
Вы хотите иметь полный контроль над всеми функциями и поддерживать, обновлять и публиковать новые версии модулей.
Используйте конвейер CI/CD для развертывания артефактов IaC и обеспечения качества развертывания и сред Azure.