Использование инфраструктуры в качестве кода для обновления целевых зон Azure
В этой статье описываются преимущества использования инфраструктуры в качестве кода (IaC) для обновления целевых зон Azure. Организациям необходимо обновить целевые зоны по мере их работы, чтобы обеспечить правильность конфигураций и реагировать на необходимость изменений.
IaC может управлять целым жизненным циклом и управлять ресурсами, которые он развертывает. Организации должны планировать развертывание целевых зон Azure с помощью IaC. Он требует планирования выравнивания существующих ресурсов, отличных от IaC, с ресурсами IaC, поддерживаемыми с помощью управления состоянием. Необходимо сопоставить существующие ресурсы с требуемым состоянием.
Дополнительные сведения см. в статье "Сохранение актуальной целевой зоны Azure".
Как работает инфраструктура как код
IaC ссылается на практику и средства управления жизненным циклом ресурсов инфраструктуры с помощью файлов определения, доступных для машинного чтения. Определение инфраструктуры записывается, версионируется, развертывается через конвейеры, а затем становится частью развертывания для рабочих нагрузок.
Технологии IaC декларативны, что означает, что при запуске IaC конфигурация задает конфигурацию для того, что описано в коде независимо от его текущего состояния. При настройке инфраструктуры с помощью сценариев, таких как Azure CLI или Azure PowerShell, они обязательны. Императивные скрипты выполняют набор действий, а результат зависит от текущего состояния, а также состояния после действий.
Таким образом, если у вас есть инфраструктура в качестве определения кода для ресурса Azure, вы можете запустить это определение так часто, как нужно, и он создает изменение только в том случае, если:
- Определение изменяет добавление новых ресурсов, удаление ранее развернутых ресурсов или изменение ресурсов, которые ранее были развернуты.
- Развернутый ресурс перемещается из конфигурации, чтобы сбросить конфигурацию на определенную.
Вы можете использовать IaC для восстановления состояния, удалив ресурсы, которые больше не нужны и управляют жизненным циклом ресурсов с помощью многих изменений.
Примечание.
Конкретная механика удаления ресурсов с IaC зависит. Например, Azure Bicep требует использования complete
типа развертывания для устранения область ресурсов. Эта команда работает только в определенных область. Для Terraform ресурсы имеют lifecycle
мета-аргумент, который содержит инструкции по обработке ресурсов Terraform.
Для целевых зон Azure есть два основных варианта инфраструктуры в качестве кода:
- Azure Bicep, который является языком для конкретного домена, который используется для развертывания ресурсов Microsoft, разработанных Корпорацией Azure. Дополнительные сведения см. в статье о целевых зонах Azure — рекомендации по проектированию модулей Bicep.
- Terraform, продукт, созданный Hashicorp, для развертывания инфраструктуры в облаке и локальной среде. Terraform имеет конкретных поставщиков ресурсов Майкрософт для развертывания ресурсов Azure. Дополнительные сведения см. в статье о целевых зонах Azure — рекомендации по проектированию модуля Terraform.
Преимущества обновления ALZ с помощью инфраструктуры в виде кода
Следующие преимущества описывают, почему следует использовать инфраструктуру в качестве кода для обновления целевой зоны.
Сокращение усилий
Это занимает меньше усилий для использования инфраструктуры в качестве кода для выполнения обновлений по сравнению с внесением изменений вручную. Развертывание IaC помогает ответить на следующие вопросы:
- Как на сегодняшний день настроены ресурсы?
- Как оно будет настроено этим обновлением?
- Какие изменения будут вноситься в соответствии с этим обновлением?
При запуске инфраструктуры в виде набора инструментов кода может производиться сравнение или разностное чтение изменений. Просмотрите это чтение перед фиксацией изменений в среде.
Набор инструментов может компилировать сведения об изменении, а не оператор или инженер.
Уменьшение ошибки
Благодаря программному характеру развертываний инфраструктура в виде кода уменьшает человеческую ошибку при внесении изменений. Он изменяет только определенные параметры и имеет параметры предварительной версии, поэтому уменьшает сбои, вызванные сбоем или неполными изменениями. Он также улучшил варианты тестирования.
Управление версиями и журнал
Инфраструктура как развертывания кода поддерживается файлом определения, поэтому для управления версиями определений можно использовать управление версиями определений. В зависимости от используемого метода IaC можно ссылаться на развертывания в Azure для Bicep или в файле состояния Terraform, чтобы просмотреть журнал предыдущих развертываний.
При использовании методик управления версиями создается новая ветвь IaC для добавления изменений и редакций. Журнал ветви в системе управления версиями записывает итерации и изменения. Его можно использовать для развертывания изменений в тестовой среде, пока вы не будете готовы к слиянию и развертыванию изменений в рабочей среде. Дополнительные сведения см. в статье "Тестирование" для целевых зон Azure. На протяжении всего этого цикла записи развертывания фиксируют используемую версию и развернутые ресурсы, обеспечивающие высокую видимость журнала.
Используйте эти методы тестирования с Bicep для общих целей тестирования. С помощью этих методов можно выполнить тестирование перед развертыванием кода и протестировать в непроизводственных средах из ветви.
Тестовые среды
Развертывания IaC повторяются, поэтому вы можете использовать то же определение для развертывания второй (или более) среды на основе развертывания. Этот метод ценен для тестирования изменений.
Например, если вы хотите заменить Брандмауэр Azure с помощью номера SKU уровня "Премиум", можно развернуть тестовую среду и проверить изменения, не изменяя рабочую среду.
Перехват смещения конфигурации
IaC предоставляет уникальный параметр для перехвата смещения конфигурации во время обновлений. Развертывание перехватывает изменения в файле определения и представляет экземпляры, в которых конфигурация ресурсов отличается от определения.
Обновления целевой зоны с помощью IaC могут помочь вам поймать это смещение конфигурации и позволит вам соответствующим образом обновить код, устранить эти неправильные конфигурации через обновление или устранить их другим способом.
При внесении изменений в ресурсы с помощью портала, интерфейса командной строки или метода, отличного от IaC, это изменение реализуется. При следующем запуске развертывания с помощью IaC он помечает сравнение между определенным кодом состоянием и фактическим состоянием на портале с помощью функций what-if или plan. Используйте этот метод, чтобы определить, изменяется ли среда вне файла кода.
После определения несоответствия можно запустить IaC, чтобы попытаться выровнять развертывание с определением. Используйте этот метод для выявления проблем и устранения сценариев в зависимости от характера проблем, характера выполнения и способа внесения изменений. Например, Terraform пытается восстановить базовые показатели для развернутых ресурсов, а Complete
развертывание режима в Bicep удаляет ресурсы в группе ресурсов, которая не является частью определения. Эти средства обнаруживают и восстанавливают смещение конфигурации, но могут не устранять все проблемы.
Дополнительные сведения см. в статье Об изменениях вне диапазона и обнаружении и управлении дрейфом с помощью Terraform.
Изменения, определенные на портале, являются громоздкими для реализации обратно в IaC. Необходимо обновить код, чтобы соответствовать текущему состоянию, которое часто включает в себя просмотр каждого изменения ресурса и обновление его параметров в соответствии с конфигурацией "как есть".
Если вы используете IaC для управления целевой зоной или другими ресурсами, вы должны вносить изменения только за пределами IaC в рамках чрезвычайной ситуации. Меры предосторожности с учетными записями, имеющими доступ к внесению изменений напрямую, например управление привилегированными пользователями.
Ознакомьтесь с общими рекомендациями по автоматизации и безопасности в следующих статьях:
- Общие сведения о дисциплине базовых показателей безопасности
- Обзор дисциплины "Базовый уровень идентификации"
- Рекомендации по соответствию операционным требованиям
- Рекомендации по проектированию автоматизации платформы
Следующие шаги
Ознакомьтесь с общими сведениями о средствах IaC в следующих статьях: