Общие сведения о последовательности развертывания в Azure Blueprints

Это важно

11 июля 2026 г. Blueprints (Preview) будут признаны устаревшими. Перенесите существующие определения схем и назначений в Спецификации Шаблонов и Стеки Развертывания. Артефакты Blueprint необходимо конвертировать в JSON-шаблоны ARM или файлы Bicep, которые используются для определения стеков развертывания. Чтобы узнать, как создать артефакт как ресурс ARM, см. в:

Azure Blueprints использует порядок последовательности для определения порядка создания ресурсов при обработке назначения определения схемы. В этой статье описываются следующие понятия:

  • Порядок последовательности по умолчанию, используемый
  • Настройка заказа
  • Как обрабатывается настраиваемый заказ

В примерах JSON есть переменные, которые необходимо заменить собственными значениями:

  • {YourMG} — замените это значение именем своей группы управления.

Порядок последовательности по умолчанию

Если определение схемы не содержит директивы для порядка развертывания артефактов или директивы имеет значение NULL, используется следующий порядок:

  • Артефакты назначения ролей уровня подписки, отсортированные по имени артефакта
  • Артефакты назначения политики уровня подписки, отсортированные по имени артефакта
  • Артефакты уровня подписки Azure Resource Manager template (шаблоны ARM) отсортированы по имени артефакта
  • Артефакты группы ресурсов (включая дочерние артефакты), отсортированные по имени заполнителя

В каждом артефакте группы ресурсов для создания артефактов в этой группе ресурсов используется следующий порядок последовательности:

  • Артефакты, связанные с назначением дочерних ролей в группе ресурсов, отсортированные по имени артефакта
  • Артефакты назначения политики дочерней группы ресурсов, отсортированные по имени артефакта
  • Артефакты дочерней группы ресурсов Azure Resource Manager (шаблоны ARM), отсортированные по имени артефакта

Замечание

Использование артефактов() создает неявную зависимость от упоминаемого артефакта.

Настройка порядка последовательности

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

Упорядочивание достигается путем определения свойств dependsOn для JSON. Определение схемы для групп ресурсов и объектов артефактов поддерживают это свойство. dependsOn — это строковый массив имен артефактов, который необходимо создать перед созданием определенного артефакта.

Замечание

При создании объектов плана каждый артефактный ресурс получает своё имя из имени файла, если используется PowerShell, или из конечной точки URL-адреса, если используется REST API. Ссылки resourceGroup в артефактах должны соответствовать тем, которые определены в определении схемы.

Пример— упорядоченная группа ресурсов

В этом примере определение схемы содержит группу ресурсов, определяющую пользовательский порядок последовательности, объявляя значение для dependsOn, а также стандартную группу ресурсов. В этом случае артефакт с именем assignPolicyTags будет обработан до группы ресурсов ordered-rg. Standard-rg будет обрабатываться в порядке последовательности по умолчанию.

{
    "properties": {
        "description": "Example blueprint with custom sequencing order",
        "resourceGroups": {
            "ordered-rg": {
                "dependsOn": [
                    "assignPolicyTags"
                ],
                "metadata": {
                    "description": "Resource Group that waits for 'assignPolicyTags' creation"
                }
            },
            "standard-rg": {
                "metadata": {
                    "description": "Resource Group that follows the standard sequence ordering"
                }
            }
        },
        "targetScope": "subscription"
    },
    "type": "Microsoft.Blueprint/blueprints"
}

Пример — артефакт с пользовательским порядком

В этом примере представлен артефакт политики, который зависит от шаблона ARM. Артефакт политики по умолчанию будет создан раньше, чем шаблон ARM. Это упорядочение позволяет артефакту политики ожидать создания шаблона ARM.

{
    "properties": {
        "displayName": "Assigns an identifying tag",
        "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/2a0e14a6-b0a6-4fab-991a-187a4f81c498",
        "resourceGroup": "standard-rg",
        "dependsOn": [
            "customTemplate"
        ]
    },
    "kind": "policyAssignment",
    "type": "Microsoft.Blueprint/artifacts"
}

Пример— артефакт шаблона уровня подписки в зависимости от группы ресурсов

Этот пример предназначен для шаблона ARM, развернутого на уровне подписки и зависящего от группы ресурсов. По умолчанию артефакты уровня подписки создаются перед любыми группами ресурсов и дочерними артефактами в этих группах ресурсов. Группа ресурсов определена в определении схемы следующим образом:

"resourceGroups": {
    "wait-for-me": {
        "metadata": {
            "description": "Resource Group that is deployed prior to the subscription level template artifact"
        }
    }
}

Артефакт шаблона уровня подписки в зависимости от группы ресурсов wait-for-me определяется следующим образом:

{
    "properties": {
        "template": {
            ...
        },
        "parameters": {
            ...
        },
        "dependsOn": ["wait-for-me"],
        "displayName": "SubLevelTemplate",
        "description": ""
    },
    "kind": "template",
    "type": "Microsoft.Blueprint/blueprints/artifacts"
}

Обработка настраиваемой последовательности

Во время процесса создания топологическая сортировка используется для создания графа зависимостей артефактов схем. Проверка гарантирует, что поддерживается каждый уровень зависимостей между группами ресурсов и артефактами.

Если объявляется зависимость артефакта, которая не изменит порядок по умолчанию, тогда изменения не требуются. Примером является группа ресурсов, которая зависит от политики уровня подписки. Другим примером является назначение дочерней политики группы ресурсов "standard-rg", которая зависит от назначения дочерней роли группы ресурсов "standard-rg". В обоих случаях dependsOn не изменится порядок последовательности по умолчанию, и никаких изменений не будет сделано.

Дальнейшие действия