Основи сервісу Microsoft Azure Blueprints

10 лютого
Олександр Монахов, Леонтій Оніщук, Віталій Гнусін і Анна Медведенко
Основи сервісу Microsoft Azure Blueprints
Наша DevOps-команда постаралася розібратись у тонкощах застосування сервісу Blueprints. У статті ми розповімо про результати нашого невеликого дослідження, структуру і параметри Blueprint, торкнемося теми артефактів і ресурсної групи в контексті використання сервісу. Матеріал може бути корисним, перш за все, DevOps-інженерам, які працюють з інфраструктурою Azure та потребують зручного інструменту створення і керування оточенням. Програмістам, зацікавленим у хмарних технологіях, прочитати статтю теж буде цікаво: Blueprints — сучасне рішення, що дозволяє оптимізувати процес розробки і підтримки програмного забезпечення.

1. ЩО ТАКЕ BLUEPRINTS?

Blueprints — сервіс Azure Cloud, що дозволяє в декларативному вигляді визначати повторюваний набір ресурсів Azure Cloud, який відповідає стандартам і вимогам організації.

Blueprints дозволяє розробникам швидко та зручно розгортати нове хмарне оточення Azure із дотриманням усіх вимог безпеки і комплаенсу.

img

Blueprints — структура і рівні застосування

2. ЩО МОЖНА ЗРОБИТИ ЗА ДОПОМОГОЮ BLUEPRINTS?

Перш за все, можна розгортати різні ресурси з темплейтів і використовувати артефакти:

  • Role Assignments;
  • Policy Assignments;
  • Azure Resource Manager templates (ARM templates);
  • Resource Groups.

На відміну від ARM-темплейтів, сервіс Blueprints призначений для конфігурації оточення. Така конфігурація зазвичай містить набір ресурсних груп, політик, ролей і, власне, ARM-темплейтів. Blueprint містить усі ці артефакти разом та підтримує версіонування, що відкриває можливість впровадження практик CI/CD.

Також, на відміну від ARM-темплейтів, при розгортанні ресурсів за допомогою Blueprint зберігається зв'язок між визначенням (що має бути розгорнуто) та призначенням (що було розгорнуто). Цей зв'язок дозволяє контролювати процес розгортання ресурсів.

Кожен Blueprint може (але не зобов'язаний) містити ARM-темплейт.

3. BLUEPRINT AS CODE

3.1 Попередні вимоги

Для зручності роботи з Blueprints у Azure DevOps на рівні організації можна встановити розширення Azure Blueprints від Neil Peterson.

Робота з Blueprints складається з таких етапів:

  • Підготовка Blueprint, його артефактів (див. нижче), а також файлу з параметрами призначень (assign.json).
  • Створення (publish) версії Blueprint у Azure Blueprints service.
  • Призначення (assignment) версії Blueprint — у підсумку створюється оточення, відповідне до артефактів Blueprint і параметрів із файлу ASSIGN.JSON, або ж існуюче оточення оновлюється та приводиться у відповідність із ними.

3.2 Структура артефактів Blueprint

Артефакти Blueprint описуються файлами JSON — кожен артефакт міститься в окремому файлі.

У загальному випадку папка з Blueprints і артефактами виглядає так:

image

Файл blueprint.json — основний, його призначення — визначення самого Blueprint. При деплї Blueprint він викликається першим, а всі артефакти є його дочірніми ресурсами.

Файл assign.json є обов'язковим при операції призначення Blueprint, він містить значення змінних, які використовуються у Blueprint у процесі Assignment (наприклад, імена та SKU компонент, що створюються, регіон, у якому будуть створені описані компоненти, тощо). Зазвичай значення змінних або параметрів у цьому файлі необхідно змінити. Для цього використовується трансформація файлу.

3.3 Трансформація файлу

Функція FileTransform може змінювати вміст XML або JSON-файлів.

Приклад:

Файл assign.json використовується у процесі призначення Blueprint. Нам необхідно змінити значення location, blueprintId, gOrganizationName і g_AzureRegion:

{
    "identity": {
      "type": "SystemAssigned"
    },
    "location": "testLocation",
    "properties": {
      "blueprintId": "testBlueprintId",
      "resourceGroups": {},
      "parameters": {
        "g_Organization_Name": {
          "value": "testOrgName"
        },
        "g_AzureRegion": {
          "value": "testLocation"
        }
      }
    }
} 

У YAML-пайплайні вказуємо бажані значення змінних, дотримуючись структури змінюваного файлу:

variables:
  location: 'westeurope'
  properties.blueprintId: "/subscriptions/$(SubscriptionId)/providers/Microsoft.Blueprint/blueprints/AM-BP-feature-init"
  properties.parameters.g_AzureRegion.value: $(location)
  properties.parameters.g_Organization_Name.value: "Integration"

І виконуємо трансформацію файлу:

- task: FileTransform@1
  inputs:
    folderPath: '$(Agent.BuildDirectory)\blueprints'
    fileType: 'json'
    targetFiles: 'assign.json'

Можемо подивитися вміст трансформованого файлу:

- script: type "$(Agent.BuildDirectory)\blueprints\assign.json"

3.4 Типи артефактів

Blueprint складається з артефактів, причому підтримуються наступні типи останніх:

  • Ресурсні групи — застосовуються на рівні підписок.
  • ARM-темплейти — застосовуються на рівні підписок і ресурсних груп.
  • Призначення політик — застосовуються на рівні підписок і ресурсних груп.
  • Призначення ролей — застосовуються на рівні підписок і ресурсних груп.

Розглянемо приклад файлу blueprint.json:

{
    "properties": {
        "description": "This will be displayed in the essentials, so make it good",
        "targetScope": "subscription",
        "parameters": { 
            "principalIds": {
                "type": "string",
                "metadata": {
                    "displayName": "Display Name for Blueprint parameter",
                    "description": "This is a blueprint parameter that any artifact can reference. We'll display these descriptions for you in the info bubble",
                    "strongType": "PrincipalId"
                }
            },
            "genericBlueprintParameter": {
                "type": "string"
            }
        },
        "resourceGroups": {
            "SingleRG": {
                "description": "An optional description for your RG artifact. FYI location and name properties can be left out and we will assume they are assignment-time parameters",
                "location": "eastus"
            }
        }
    },
    "type": "Microsoft.Blueprint/blueprints" 
}

Ми бачимо два опціональні параметри parameters: principalIds і genericBlueprintParameter.

Ці параметри можуть бути використані у будь-яких дочірніх артефактах. У цьому випадку ми визначаємо параметр ResourceGroup у файлі blueprint.json, а не в окремому файлі.

3.5 Параметри

Практично все у Blueprint може бути параметризовано. Параметри визначаються у файлі blueprint.json і можуть застосовуватись у будь-яких артефактах.

Параметр може бути визначений у простому вигляді:

"parameters": { 
    "genericBlueprintParameter": {
        "type": "string"
    }
}

Типи параметрів можна знайти у цьому розділі документації.

Звернення до параметрів може відбуватися так само, як це робиться у властивостях ARM-темплейтів (defaultValue, allowedValue тощо). Також ми можемо викликати параметри, визначені раніше:

"properties": {
    "genericBlueprintParameter": "[parameters('principalIds')]",
}

Також отримати значення параметра можемо через конструкцію виду:

${{ parameters.genericBlueprintParameter }}

3.6 Властивості Resource Group

Ми визначили властивості Resource Group у головному файлі blueprint.json із такими параметрами:

  • Місцезнаходження: "location": "eastus".
  • Ім'я розміщення для ResourceGroup: SingleRG.

Ресурсна група ще не створена, це відбудеться після призначення (assignment).

За бажанням ми можемо вказати ім'я ресурсної групи, додавши "name": "myRgName" як дочірній параметр об'єкта SingleRG (докладніше тут).

3.7 Артефакти

Всі артефакти повинні мати такі параметри:

  1. Kind, згідно з яким, артефакт може бути:

    a. template,

    b. roleAssignment,

    c. policyAssignment.

  2. Type, який для артефактів завжди буде: Microsoft.Blueprint/blueprints/artifacts.
  3. Properties — основний розділ, в якому описуються всі властивості артефакту.
    Наприклад:

    a. dependsOn опціонально може вказувати на залежність від інших артефактів. Більше інформації тут.

    b. resourceGroup опціонально може вказувати на назву ресурсної групи, де будуть розміщуватись ресурси. Якщо цей параметр не визначений, для розміщення ресурсів використовуватиметься ресурсна група, зазначена у файлі blueprint.json.

Повна специфікація для кожного типу артефактів описана тут: Policy Assignment, Role Assignment, Template.

3.8 Робота з Blueprints у пайплайнах

Для роботи з Blueprints можна використовувати:

  • powershell командлети (модуль Az.Blueprint, докладніше тут);
  • таски, розроблені Neil Peterson (докладніше тут, їх ми й використовуємо у цій статті).

3.8.1 Створення Blueprint

steps:
- task: nepeters.azure-blueprints.CreateBlueprint.CreateBlueprint@1
  displayName: 'Create Azure Blueprint'
  inputs:
    azureSubscription: 'nepeters-subscription'
    BlueprintName: 'blueprints-demo'
    BlueprintPath: ./create
    IncludeSubFolders: true
    PublishBlueprint: true
    ChangeNote: 'Added new artifacts.'

Результати можна переглянути на Azure порталі -> Blueprints -> Blueprint definitions.

3.8.2 Призначення Blueprint

steps:
- task: nepeters.azure-blueprints.AssignBlueprint.AssignBlueprint@1
  displayName: 'Assign Azure Blueprint'
  inputs:
    azureSubscription: 'nepeters-internal'
    AssignmentName: 'prod-test-one'
    BlueprintName: 'prod-test-one'
    ParametersFile: 'assign/assign-blueprint.json'
    AlternateSubscription: true
    SubscriptionID: '00000000-0000-0000-0000-000000000000'
    Wait: true
    StopOnFailure: true

Результати можна переглянути на Azure порталі -> Blueprints -> Assigned blueprints. Ця секція особливо корисна для отримання детальних логів при помилках призначення Blueprint.

Як бачите, робота з Blueprints не набагато складніша за роботу з ARM-темплейтами, але дає набагато більший функціонал та дозволяє контролювати оточення. Важливий момент — можливість ієрархічного застосування блюпринтів. Використовуючи сервіс Azure, ви можете не просто автоматично розгорнути оточення, а керувати ним із дотриманням всіх вимог безпеки і комплаенсу.

  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    18 листопада
  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    1 липня
  • Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    25 червня
  • Україна, Одеса
    25 червня