Некоторые из моих друзей ненавидят использовать шаблоны рук. Это дает им головные боли, когда им нужно с этим справиться. Иногда они напуганы, или они просто не понимают, как иметь дело с файлами JSON. Я предполагаю, что это то же самое для любой другой формы монтажа облачного обеспечения на основе кода.
Зачем использовать шаблон рук:
- Он повторяется и управляется данными. После того, как у вас есть файл шаблона, вы можете повторно использовать его с другими данными (вы можете развернуть разработчик, UAT и производственную инфраструктуру с тем же шаблоном)
- Это тестируемо, вы можете запустить блок и интеграционное тестирование на шаблоны
- Это способ создать инфра как код, он создает единственный источник истины, и это идентификационно
Как использовать его в команде. Как создать и управлять шаблоном в команде. Arm Temple позволяет командам развернуть весь ваш проект из одного развертывания. Это также может помочь управлять жизненным циклом проекта.
Что такое шаблоны рук? Это файл JSON (своего рода) с 5 разделами;
- Параметры
- Переменные
- Ресурсы
- Функции
- выход
Параметры
В разделе «Параметры» указывается значение, которое будет использоваться для конкретного развертывания. Значение будет использоваться в разделе ресурсов в качестве входных данных.
Здесь есть лучшая практика. Ограничьте количество параметров. Для этого есть несколько мотивов. Первый — это жесткий предел; Вы не можете иметь более 256 параметров на шаблон. Но более важно, что шаблон представляет собой развертывание, создание ресурсов в группе ресурсов. Это должен быть единственный источник истины. Шаблон, как документация, рассказывает вам, что развернуто для конкретного проекта. Это должно быть понято всеми в команде. Во время жизненного цикла ресурсной группы. Проект может измениться, добавлять или удалять ресурсы или масштабировать других. Чтобы сохранить источник истинных точных изменений, должен быть внесен через шаблон. Если шаблон сложно читать или обновить, есть вероятность того, что люди попытаются обновить проект другими способами, и вы теряете ссылки между шаблоном и тем, что развернуто на Azure. С другой стороны, вы теряете контроль над своими ресурсами. Ограничение сложности шаблона является ключевым приоритетом для каждого проекта.
Первое, что нужно знать, если в шаблоне определено значение по умолчанию, параметр является необязательным во время развертывания.
"ManagedIdentity": {
"type": "string",
"defaultValue": "yes"
}
Если значение параметра часто не меняется в развертывании, это хороший вариант. Например, если для проекта размер виртуальной машины одинаковы для Dev, QAL, LAB и только изменения для Prod и UAT, параметр размера виртуальной машины должен выглядеть следующим образом:
"VmSize": {
"type": "string",
"defaultValue": "Standard_B2MS"
}
Имя параметра должно быть тщательно выбирать. Они должны быть явными, избегать использования одного слова, подобного размеру, и предпочитают что -то вроде Bakendervervmize. Имя параметра похоже на переменную. На любом языке программирования соглашение об именах используется для идентификации переменных. Я использую корпус Pascal для имени параметра. Это делает их более читаемыми (т.е. frontserversvmsize). Но будьте осторожны, когда параметры именования не используют каких-либо параметров PowerShell из New-AzresourceGroupDeployment.
Наряду с хорошим соглашением об именах, описания — отличный способ документировать параметр и как его можно установить. Каждый параметр должен иметь описание. Это позволяет сотрудничать команды, поскольку ограничивает путаницу.
"ManagedIdentity": {
"type": "string",
"defaultValue": "yes",
"metadata": {
"description": "Specify if the function needs a Managed System Identity or not"
}
},
Это просто простое текстовое предложение, описывающее, как параметр будет использоваться во время развертывания.
Можно создать шаблон только с одним типом данных, строка, но ARM предлагает немного больше. Существует несколько типов данных, строки, защиты, целочисленного, логического, объекта, массива и безопасного объекта.
Что касается защиты и SecureBject, используются для конфиденциальных данных, таких как пароль или ключ API или что -либо, что не следует видеть после развертывания. Значение этих двух типов данных не может быть прочитано в Azure.
Но если вы используете разумные значения в файлах параметров шаблона, вы можете извлечь разумную информацию из ваших репозитории или где хранится файл параметров.
Чтобы избежать этого, используйте KeyVault в файле параметров шаблона вместо хранения разумных данных.
"adminPassword": {
"reference": {
"keyVault": {
"id": "/subscriptions//resourceGroups//providers/Microsoft.KeyVault/vaults/"
},
"secretName": "vm-adm-Local"
}
}
Одна из лучших практик — ограничить количество параметров, если вам нужно развернуть несколько ресурсов. Я использую значения объектов для этой цели. Это помогает группировать ценности, связанные с одним ресурсом, и делает его более читабельным для всех.
Объекты JSON — это просто конструкция ключей/пары, где вы можете использовать другие данные дата, такие как строка, целое число, но также массивы и Конечно другие объекты JSON
Если я хочу развернуть Azure Postgres Server, у меня должно быть местоположение, версию, имя сервера, теги,… как параметры. Эти параметры могут быть сгруппированы только в один параметр.
В шаблоне
"PostGreSqlSetup": {
"type": "object",
"metadata": {
"description": "Azure PostGreSql Parameters in a Json object"
}
}
В файле параметров
"PostGreSqlSetup": {
"value": {
"location": "northeurope",
"DbServerName": "dbserver-psql01",
"version": "10",
"skuName": "B_Gen5_1",
"skuTier": "Basic",
"skuCapacity": 1,
"skuFamily": "Gen5",
"skuSizeMB": 12000,
"backupRetentionDays": 7,
"administratorLogin": "dbsuperuser",
"tags": {
"iac": "arm",
"env": "prod",
"displayname": "Prod database server"
}
}
}
В разделе ресурсов
"location": "[parameters('PostGreSqlSetup').location]",
Но есть недостаток, использующий объект в качестве параметра. Возможность управлять входами. Параметры могут включать базовый контроль, с этими элементами управления можно ограничить целое число между двумя границами (minvalue и maxvalue) или длиной строки или массива (minlength и maxlength). Наиболее используемый контроль разрешен. Он не позволяет пользователю развернуть нежелательные ресурсы (например, негабаритную виртуальную машину) или нереалистичную ценность (например, на жесткий диск 10 Petabytes), и помогает участникам и пользователям лучше понять, что необходимо для параметра. Но есть еще больше, это обеспечивает автозаполнение в PowerShell при использовании New-AZresourceGroupDeployment без файла параметров шаблона.
Последнее в параметрах, если значение параметра вообще не изменяется, нет необходимости использовать его в качестве параметра. Это должно быть размещено в разделе переменных. Это может быть случай местоположения ресурса, если есть ограничение, чтобы всегда использовать то же самое.
Переменные
Я использую раздел переменных для хранения статических параметров, а также для того, чтобы сделать любые вычисления, необходимые в разделе «Ресурсы». Это помогает удалить сложность в последнем разделе, и это облегчает чтение и обновление шаблона.
Например, место, часто я использую то же место, что и группа ресурсов. Нет необходимости использовать параметр для этого, и нет необходимости делать расчет для каждого ресурса.
"DefaultLocation": "[resourceGroup().location]",
Здесь я использую функцию шаблона (опять же, избегайте использования функций шаблона в ресурсе). Существует два типа функций, функции шаблонов и пользовательские функции (не покрытые здесь). Функции шаблонов используются для манипулирования данными. Они сгруппированы по типу, строке, массиву, числовым, сравнению, логическому, развертыванию и ресурсу. Вы можете найти полный список здесь
Для переменной по умолчанию я использовал функцию ResourceGroup (). Он возвращает объект JSON для использования в шаблоне.
{
"id": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}",
"name": "{resourceGroupName}",
"type":"Microsoft.Resources/resourceGroups",
"location": "{resourceGroupLocation}",
"managedBy": "{identifier-of-managing-resource}",
"tags": {
},
"properties": {
"provisioningState": "{status}"
}
}
Вы можете получить доступ к любым свойствам, используя точечную нотацию, как в PowerShell, когда вам нужно свойство из объекта. Если вам нужно имя группы ресурсов
resourceGroup().name
Две наиболее используемые функции шаблонов, используемые в любом шаблоне, — это…. Параметры и переменные. Да, эти ключевые слова Envy 2 Используются ключевые слова — это фактические функции, которые они просто возвращают значение параметра или переменной.
В разделе ресурсов они используются как это
[parameters('MyParameterName')]
[variables('MyVariableName')]
Можно сделать сложные вычисления в шаблоне, но я вижу, что наиболее используемыми функциями шаблона (после параметров и переменных) являются CONCAT, если, уникальные, ресурсоид и ресурсную группу.
Concat () возвращает результат объединения нескольких строк.
"applicationGatewayName": "[concat('appGateway' , variables('deploymentID'))]",
If () функция возвращает значение на основе теста.
"ManagedSystemIdentity": "[if(equals(parameters('ManagedIdentity'), 'yes'), 'SystemAssigned', 'None')]"
ResourceID () Возвращает уникальный идентификатор ресурса, который вам необходимо использовать в разделе «Ресурсы». Ресурс не должен находиться в группе ресурсов развертывания. В другой ресурсной группе или другой подписке.
"vnetID": "[resourceId(parameters('NetRg'), 'Microsoft.Network/virtualNetworks', parameters('VnetName'))]",
Я использую раздел переменных, чтобы поддерживать согласованность с именованием объектов. Возьмите виртуальную машину, вы можете ввести имя виртуальной машины, и вместе с ним создать имя виртуального интерфейса, публичного IP, имени VHD и любых других связанных компонентов. В этом случае я часто использую функцию TOLOWER ().
"OSDiskName": "[concat(toLower(parameters('virtualMachineName')),'-os-vhd')]",
"networkInterfaceName": "[concat(toLower(parameters('virtualMachineName')),'nic-01')]",
Для меня раздел переменных целей состоит в том, чтобы убрать сложность расчета из раздела ресурсов. Если в разделе ресурсов вам необходимо выполнить вычисление, чтобы установить значение свойств, он затрудняет чтение раздела, и если это значение используется более одного раза, оно увеличивает вероятность ошибки.
Раздел ресурсов — это место, где определяются ресурсы Azure, которые будут развернуты. Синтаксис может быть «простым». Вы должны предоставить имя ресурса, тип ресурса, версию API и некоторые другие параметры. Надеюсь, Microsoft предоставляет действительно хорошее Документация для всех ресурсов
Название ресурса — это уникальное имя в шаблоне, на которое вы можете ссылаться в другой части шаблона (например, пункт «Dypedson» может использовать его, например). Это может быть статичным или может быть создано динамически.
Тип рефери для провайдера, используемого в развертывании. Это всегда в форме пространства имен провайдера/типа ресурса. Как только вы узнаете об этом 2 элементах, легко построить шаблон. Иногда немного сложнее, потому что имя поставщика и тип ресурса не очевидны. Посмотрите на AKS, на портале Azure вы найдете сервис Kubernetes или AKS. Но имя поставщика — MicrosoftContainerService, а тип ресурса управляется.
Итак, Документация шаблона MS ARM будет вашим гидом.
Что касается параметра, вы можете добавить комментарий в каждом ресурсе. Рекомендуется использовать его. Это помогает понять первое намерение и может дать подсказки о том, что будет развернуть шаблон и как он был построен.
{
"name": "[variables('storageAccountName')]",
"comments": "This storage account used by the function App",
"type": "Microsoft.Storage/storageAccounts",
"apiVersion": "2018-07-01",
"location": "[parameters('location')]",
"kind": "StorageV2",
"sku": {
"name": "Standard_LRS",
"tier": "Standard"
},
"properties": {
"accessTier": "Hot"
}
}
Одна из целей шаблона также должна быть повторно используется. Разница между средами, такими как Prod, Qual, Dev не только о имени или размере, это также о количестве предметов для развертывания. Возьмите производственную среду, у VM может быть несколько жестких дисков, где разработчик использует только ОС. Там может быть иначе, как и количество виртуальных машин или сетей для развертывания.
Массив и копия являются идеальным ответом на ситуацию, когда должны быть развернуты 0 или более ресурсов или свойств.
Например, если необходимо создать несколько данных данных на основе параметра NBRDISK.
"copy": [
{
"name": "dataDisksDeploy",
"count": "[parameters('NbrDisk')]",
"input": {
"diskSizeGB": "[parameters('DataDiskSizeGB')]",
"lun": "[copyIndex('dataDisksDeploy')]",
"name": "[concat(variables('vmName'), '-vhd',copyIndex(), copyIndex('dataDisks'))]",
"createOption": "Empty"
}
}
]
Его также можно использовать с множеством объектов.
в файле параметров
"Netconfiguration": {
"value": [
{
"VnetName": "myapp-vnet",
"VnetNetwork": "10.124.0.0/25",
"VnetLocation": "westeurope",
"tags": {
"App": "Myapp",
"Environnement": "prod",
"Iac": "arm"
},
"Subnet": [
{
"SubnetName": "gatewaysubnet",
"SubnetPrefix": "10.124.0.0/29"
},
{
"SubnetName": "frontEndSubnet",
"SubnetPrefix": "10.124.0.16/28"
}
]
}
]
}
В разделе ресурсов
"copy": [
{
"name": "subnets",
"count": "[length(parameters('Netconfiguration')[copyIndex('Vnets')].Subnet)]",
"input": {
"name": "[parameters('Netconfiguration')[copyIndex('Vnets')].Subnet[copyIndex('subnets')].SubnetName]",
"properties": {
"addressPrefix": "[parameters('Netconfiguration')[copyIndex('Vnets')].Subnet[copyIndex('subnets')].SubnetPrefix]"
}
}
}
]
Добавление меньшего количества дисков или виртуальной машины — не единственное, что может измениться между средами. В зависимости от типа развертывания, вы можете иметь шлюз приложения, балансировщик нагрузки или любые другие компоненты, которые будут бесполезны в развертывании DEV.
Чтобы избежать использования 2 шаблонов для того же проекта, можно добавить условие в определении ресурса.
"name": "[variables('applicationGatewayName')]",
"type": "Microsoft.Network/applicationGateways",
"condition": "[equals(parameters('ENV'),'PROD')]",
"apiVersion": "2018-08-01",
"location": "[resourceGroup().location]",
Если ENV параметр равен PROD, шлюз приложения развернут, если нет ресурс не развернут.
Есть много других методов для использования с шаблонами ARM. Вы можете создать свою собственную функцию, чтобы сделать пользовательский расчет.
Вы также можете использовать шаблон связывания. Эта последняя техника позволяет модулизировать проект в несколько шаблонов, связанных в мастер -шаблоне. Каждая дочерние файлы должны быть в глобальном масштабе, так как их нужно прочитать менеджером шаблонов ARM, а не вашей локальной рабочей станцией. Они помещаются в хранилище Blob -Blob -Blob, и файл мастера -шаблона должен отправлять ключ SAS. Дочерний файл — это просто стандартный файл шаблона ARM с одним или несколькими ресурсами для развертывания. Вы также должны предоставить параметры для развертывания.
{
"type": "Microsoft.Resources/deployments",
"apiVersion": "2019-05-01",
"name": "provisionRessource",
"properties": {
"mode": "Incremental",
"templateLink": {
"uri":"[variables('RessourceDeployementUri')]",
"contentVersion":"[variables('RessourceTemplateVersion')]"
},
"parameters": {
"ResourceName":{"value": "[parameters('RessourceName')]"}
}
}
}
В этом последнем примере вы можете увидеть элемент ContentVersion. Это обязательный элемент на каждом шаблоне не только связанного. Это часть документации шаблона рук. Каждый раз, когда производится модификация, вы должны увеличить версию. Вы можете использовать ту же обозначения, что и модуль PowerShell, основная версия, второстепенная версия, номер сборки.
Еще одна вещь, полезная для шаблона, — это метаданные шаблона, где вы можете добавить информацию о комментариях и автора.
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.1.'",
"metadata": {
"comments": "Demo template for dev.to blog",
"author": "Olivier Miossec @omiossec_med"
},
Когда мы говорим об инфраструктуре как коде, это не только написание кода, но и внедрение той же культуры и тех же инструментов, которые разработчики используют в своей ежедневной работе. Это включает в себя использование управления управлением источниками, например GIT (у вас есть в Azure DevOps или в GitHub). Он также включает в себя стратегию для обновления и модификаций. Модификация должна всегда проверять перед тем, как попасть в главную ветвь и на этапе развертывания.
Конечно, существует тестовый командлет. Но есть другие способы провести тесты. Вы можете использовать Pester с PowerShell и прочитать разделы JSON для обнаружения ошибок и нежелательного поведения. Есть некоторые другие инструменты, такие как ArmtemprateValidation от Криса Гарднера или Архелпер от Барбары 4bes.
Шаблоны рук не должны быть сложными. Это не просто, но с некоторыми усилиями вы можете создать отличные проекты с ним. Ключом к успеху является сотрудничество и документация. Вам нужно думать о шаблонах ARM как инженера -программиста и меньше, чем инженеры OPS. Не бойтесь ресурсов, они хорошо документированы Microsoft и всегда тестируйте свой шаблон перед развертыванием. Это поможет прогрессировать и будет принимать всегда некоторые из самых очевидных ошибок.
Оригинал: «https://dev.to/omiossec/arm-templates-make-it-simple-and-stupid-338m»