Развертывание облачных инфраструктур больше не является простым приключением в запутанных графических интерфейсах. Вместо этого используются инструменты для описания инфраструктуры как кода. Различные поставщики предлагают проприетарные решения для своих облачных сервисов, такие как CloudFormation для Amazon Web Services (AWS) или Heat для OpenStack. С другой стороны, есть такие решения, как Terraform, которые поддерживают несколько облачных провайдеров. Microsoft также активна в этой области и предлагает услугу Blueprint для своего облака Azure, которая в настоящее время все еще находится в стадии предварительной версии.
В этой статье описывается создание инфраструктуры в Azure с помощью службы Blueprint с использованием шаблонов Azure Resource Management (ARM) и перечислены распространенные ошибки.
Вступление
В начале моего пути к Microsoft Azure Blueprints у меня были некоторые ожидания относительно того, как этот план может работать. Будет ли это сравнимо с Terraform? Не пропустили бы некоторые функции Terraform? После нескольких дней знакомства с сервисом я был немного удивлен тем, как его использовать и какой набор функций доступен.
Архитектура чертежа
Архитектура Blueprint основана на двух основных компонентах: файле blueprint и артефактах. Артефактами могут быть роли, политики и ARM-шаблоны. Все эти файлы написаны в формате json. Как правило, файлы структурированы следующим образом: файл «blueprint.json» находится в корневом каталоге, а артефакты - в папке артефактов. Следующее дерево каталогов иллюстрирует это. Содержание файлов описано ниже.
blueprint.json
Этот файл описывает все группы ресурсов, которые должны быть созданы, и параметры на уровне схемы.
policy.json
В артефакте политики необходимо указать тип. В этом случае используются «policyAssignment» и свойство «policyDefinitionId».
role.json
Во-первых, в этом файле указывается, что это за артефакт. Для назначения роли это «roleAssignment» со свойствами «roleDefinitionId» и «PrincipalIds».
arm-template.json
Термин ARM-шаблон расшифровывается как шаблон Azure Resource Manager. Он описывает ресурсы, которые будут созданы в указанных группах ресурсов. Microsoft описывает точную структуру и синтаксис шаблонов в своей документации.
Пример создания бастиона подсети виртуальной сети
В следующем примере описывается, как создать группу ресурсов с виртуальной сетью (vnet), подсетью и хостом Bastion для управления ресурсами в группе с улучшенной безопасностью. Структура папок выглядит следующим образом. Обратите внимание на цифры в начале json-файлов артефактов. Причина этого описана в следующей главе.
Во-первых, мы начнем с определения параметров уровня чертежа. В следующем списке представлен их обзор.
С помощью описания параметра и файловой структуры чертежа мы можем создать файл «blueprint.json».
Есть разные способы составить артефакты, все ваши ресурсы в одном файле шаблона ARM. Это имеет смысл для небольшого развертывания, но для более крупного я рекомендую другой подход: определение каждого ресурса в отдельном файле. Это дает лучший обзор и упрощает структуру вашего развертывания. Именно так мы и пойдем в этой истории. Создаем файл артефакта для сетевых ресурсов и отдельный файл для хоста-бастиона. Первым файлом будет файл «01_network.json», который включает определение виртуальной сети и подсети.
Вторая часть развертывания включает в себя создание хоста-бастиона, общедоступного IP-адреса и его присвоение хосту. Это будет определено в файле «02_bastion.json».
Как мы видим, раздел ресурсов содержит два ресурса. Во-первых, ресурс общедоступного IP-адреса, а во-вторых, хост-бастион с назначением виртуальной сети и общедоступного IP-адреса.
Обработка чертежей и рабочий процесс
Теперь мы готовы создать план через Rest API или PowerShell в Microsoft Azure. Оба способа выполняют один и тот же процесс с разными командами. Следующие шаги описывают процедуру:
- Создайте чертеж с помощью файла blueprint.json
- Добавьте свои артефакты в файл чертежа по файлу (невозможно импортировать несколько артефактов с помощью одной команды)
- Опубликуйте свой план
- Назначьте план
Эти шаги более подробно описаны в документации Azure для Rest API и PowerShell.
Как уже упоминалось, название артефактов важно. Когда план назначен, артефакты выполняются в алфавитно-цифровом порядке. По этой причине при именовании файлов артефактов необходимо учитывать зависимости от ресурсов. Я рекомендую использовать числовой порядок в начале имени файла.
Важно знать, что большинство функций API и PowerShell недоступны в веб-интерфейсе, а изменения в схеме не проверяются облачной службой в процессе создания. Ошибки будут отображаться только в процессе назначения. Это огромный недостаток, поскольку он делает разработку Blueprint более сложной и трудоемкой.
Импорт и экспорт чертежей с помощью PowerShell
Если вы уже создали проект, вы можете импортировать или экспортировать определение полностью. Этот процесс также описан в документации Microsoft, где вы также можете найти команды.
Прежде всего, вам нужна ссылка на схему подписки, что можно сделать с помощью следующей команды.
Чтобы экспортировать Blueprint, вы можете использовать команду экспорта.
А импорт можно выполнить с помощью команды импорта.
Лазурные чертежи и терраформа
Наконец, я опишу ключевые особенности обеих технологий и преимущества.
Blueprint Service предоставляет следующие возможности:
- Услуга включает управление версиями, что упрощает обработку нескольких состояний чертежа.
- Интеграция службы чертежей в Microsoft Azure находится на высоком уровне и управляется через API, PowerShell и частично через веб-интерфейс.
- Чертеж можно использовать на уровне группы управления.
- Microsoft предлагает комплексную документацию по услуге, которая включает образцы и дополнительную информацию. Это разбросано по многим страницам, что делает излишне сложным получение обзора услуги и ознакомление с ней.
- Blueprints - это проприетарный сервис, который можно использовать только в облаке Azure.
Terraform, с другой стороны, имеет следующие особенности:
- Его можно использовать для нескольких облачных развертываний.
- У него большое сообщество, которое предлагает множество примеров и помощь в разработке.
- Terraform автоматически управляет зависимостями.
- Включены синтаксис и проверка развертывания, что значительно увеличивает скорость разработки.
- Документация хорошо оформлена и находится в неизменном виде.
Заключение
Я рекомендую использовать Blueprint Service только для специальных функций Azure на уровне группы управления, например предоставление фрейма для подписки, например политики и роли. Для сложной инфраструктуры я предпочитаю использовать Terraform, который предлагает большую гибкость.
Azure Blueprints может стать надежным сервисом. Microsoft необходимо разработать такие функции, как более простое описание зависимостей ресурсов и общих переменных. Сервис требует более эффективного процесса разработки, который проверяет синтаксис и зависимости, чтобы обеспечить более быстрое решение для загрузки изменений чертежей и конкуренции с Terraform.
