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

Использование единого шаблона при развертывании инфраструктуры как кода (IaC) возможно, если у вас есть небольшой фрагмент инфраструктуры для любого данного приложения. Однако по мере того, как вы начнете все больше и больше использовать инфраструктуру как код для создания своих приложений в облаке Azure, вы поймете, что если у вас есть стандартные блоки для определенных ресурсов на уровне предприятия, ваша работа будет намного проще. Используя шаблоны ARM, мы можем сделать именно это — создать строительные блоки, которые можно повторно использовать во всех ваших проектах, и эти небольшие шаблоны будут использоваться для развертывания определенных областей нашей инфраструктуры. Из вашего основного файла шаблона мы можем указать, какие шаблоны нам нужно использовать для создания всего нашего приложения. У нас может быть файл шаблона Azure в отдельном файле, который называется связанным шаблоном, что и является целью этой статьи. Однако у нас также может быть другой шаблон внутри основного шаблона, и этот тип шаблона известен как вложенный шаблон.

Развертывание инфраструктуры как кода: использование простого сценария

У нас есть дизайн, который состоит из нескольких веб-приложений и изменений виртуальных сетей/подсетей как часть одного из наших новых приложений. Наша цель — использовать инфраструктуру как код для максимально быстрого и динамичного развертывания.

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

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

Раздел переменных

Первое изменение заключается в создании переменной или параметра для получения более одного значения. Мы будем использовать эти значения со связанными шаблонами, чтобы обеспечить все ресурсы единым и модульным фрагментом кода.

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

Использование развертываний

Помимо обычного развертывания ресурсов, где мы определяем , соответствующий создаваемому нами ресурсу, у нас есть Microsoft.Resources/deployments (элемент 1), который позволяет администратору облака указать другой шаблон и передать параметры.

В приведенном ниже коде мы можем определить (элемент 2) для выполнения нового шаблона. Эта функция полезна при управлении развертыванием в разных группах ресурсов.

Процесс использования другого шаблона описан в пункте 3. Мы используем файл network.json, хранящийся в моем общедоступном репозитории GitHub.

Последняя часть кода, выделенная ниже, — это раздел параметров. Это переменные, которые мы можем передать шаблону, который мы определяем в этом текущем развертывании.

Вам может быть интересно, какие отличия есть в этом файле network.json, который мы вызываем из основного шаблона, верно? Простой и понятный обычный файл JSON, как и все остальные, над которыми мы работали.

Секрет — это тип Microsoft.Resources/deployment, определенный в основном шаблоне. Это так просто. Просто для прозрачности мы очистили network.json, и весь код (только одна единственная подсеть) указан в этом разделе.

{ "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": { "среда ":{ "type": "string" }, "regionCode":{ "defaultValue": "CaC", "type": "string" }, "p_SecondOctet":{ "type": "string" } }, " переменные": { "v_virtualnetworkName":"[concat('VNET-',parameters('regionCode'),'-',parameters('environment'),'-CoreNetwork')]" }, "resources": [ { "apiVersion": "2018-04-01", "type": "Microsoft.Network/virtualNetworks/subnets", "name": "[concat(variables('v_virtualnetworkName'),'/','Subnet-', параметры('regionCode'),'-',параметры('среда'),'-VPN')]", "location": "[resourcegroup().location]", "properties": { "addressPrefix": " [concat('10.',parameters('p_SecondOctet'),'.5.0/28')]" } } ], "выходы": { } }

Использование объекта Copy и функции CopyIndex

В предыдущем разделе у нас была простая настройка — мы вызываем шаблон один раз и предоставляем параметры и развертывание.

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

На изображении ниже мы смотрим на файл , и это просто еще одна запись в разделе , ничего особенного.

Глядя на пункт 1, мы видим, что имя развертывания будет комбинацией строки и текущего индекса текущего цикла, запущенного объектом Copy. Значение будет целым числом, и значение всегда начинается с 0 (ноль).

Мы планируем иметь веб-приложения в той же группе ресурсов, где мы запускаем основной шаблон. Чтобы сэкономить время и избежать статического кода, мы используем функцию [resourcegroup().name], как показано в пункте 2.

Объект Copy выделен в пункте 3. Использование простое — укажите имя и количество повторений, которые мы хотим выполнить.

Наша цель — быть динамичной, поэтому вместо того, чтобы вводить конкретное количество будущих веб-приложений, мы собираемся использовать функцию length(variables('v_webappArray')), которая будет основываться на количестве значений, которые мы добавили в наш переменная.

Последняя часть информации — это передача имени веб-приложения, которое мы хотим на каждой итерации. В разделе мы используем функцию [variables('v_webAppArray')[copyIndex()]], которая будет передавать имя сервера на основе текущей итерации.

Например, при использовании переменной, которую мы определили в первом разделе этой статьи, длина массива будет равна двум, и это будет номер счетчика для объекта . Первая итерация отправит server01, а вторая итерация отправит server02 в связанный шаблон.

Может ли развертывание инфраструктуры как кода быть элегантным? О, да

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