Entenda a sequência de implantação nos Blueprints do Azure

  • Artigo

Importante

Em 11 de julho de 2026, o Blueprints (versão prévia) será preterido. Migre suas definições e atribuições de blueprint existentes para Especificações de Modelo e Pilhas de Implantação. Os artefatos de blueprint devem ser convertidos em modelos JSON do ARM ou arquivos Bicep usados para definir pilhas de implantação. Para saber como criar um artefato como um recurso do ARM, confira:

O Azure Blueprints usa uma ordem de sequenciamento para determinar a ordem de criação de recurso ao processar a atribuição de uma definição de blueprint. Este artigo o guiará pelos seguintes conceitos:

  • A ordem de sequenciamento padrão usada
  • Como personalizar o pedido
  • Como o pedido personalizado é processado

Existem variáveis nos exemplos JSON que você precisa substituir por seus próprios valores:

  • {YourMG}: substitua pelo nome do seu grupo de gerenciamento

Ordem de sequenciamento padrão

Se a definição de blueprint não contém qualquer diretiva para a ordem de implementação de artefatos ou se a diretiva é nula, a seguinte ordem é usada:

  • Designação de função de nível de assinatura artefatos classificados por nome de artefato
  • Designação de política do nível de assinatura artefatos classificados pelo nome do artefato
  • Artefatos de modelo do Azure Resource Manager (modelos do ARM) no nível de assinatura classificados por nome de artefato
  • Artefatos do grupo de recursos (incluindo artefatos derivados) classificados por nome de espaço reservado

Em cada artefato do grupo de recursos, a seguinte ordem de sequência é usada para artefatos a serem criados dentro desse grupo de recursos:

  • Filho de grupo de recursos atribuição de função artefatos classificados por nome de artefato
  • Filho de grupo de recursos atribuição de política artefatos classificados por nome de artefato
  • Artefatos de modelo do Azure Resource Manager (modelos do ARM) do grupo de recursos filho classificados por nome de artefato

Observação

O uso de artifacts() cria uma dependência implícita no artefato que está sendo referenciado.

Personalizando o pedido de sequenciamento

Pode ser necessário criar recursos em uma ordem específica ao compor grandes definições de blueprint. O padrão de uso mais comum desse cenário é quando uma definição de blueprint inclui vários modelos do ARM. O Azure Blueprints lida com esse padrão permitindo que a ordem de sequenciamento seja definida.

A ordenação é realizada definindo uma propriedade dependsOn no JSON. A definição de blueprint suporta essa propriedade para grupos de recursos e objetos de artefato. dependsOn é uma matriz de cadeia de caracteres de nomes de artefatos que o artefato específico precisa ser criado antes de ser criado.

Observação

Ao criar objetos de blueprint, cada recurso de artefato recebe o nome do nome de arquivo, se estiver usando o PowerShell, ou do ponto de extremidade de URL, se estiver usando a API REST. As referências de resourceGroup em artefatos devem corresponder àquelas definidas na definição de blueprint.

Exemplo - grupo de recursos ordenado

Esta definição de blueprint de exemplo possui um grupo de recursos que definiu uma ordem de sequenciamento customizada, declarando um valor para dependsOn, junto com um grupo de recursos padrão. Nesse caso, o artefato denominado assignPolicyTags será processado antes do grupo de recursos ordered-rg. standard-rg será processado de acordo com a ordem de sequenciamento padrão.

{
    "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"
}

Exemplo - artefato com ordem personalizada

Este exemplo é um artefato de política que depende de um modelo do ARM. Por ordenamento padrão, um artefato de política seria criado antes do modelo do ARM. Essa ordenação permite que o artefato de política aguarde o modelo do ARM ser criado.

{
    "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"
}

Exemplo - artefato do modelo de nível de assinatura dependendo de um grupo de recursos

Este exemplo é para um modelo do ARM implantado no nível de assinatura para depender de um grupo de recursos. Na ordenação padrão, os artefatos de nível de assinatura seriam criados antes de qualquer grupo de recursos e artefatos filho nesses grupos de recursos. O grupo de recursos é definido na definição de blueprint da seguinte maneira:

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

O artefato do modelo de nível de assinatura, que depende do grupo de recursos wait-for-me, é definido da seguinte maneira:

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

Processando a sequência customizada

Durante o processo de criação, uma classificação topológica é usada para criar o gráfico de dependência dos artefatos de blueprints. A verificação assegura que cada nível de dependência entre grupos de recursos e artefatos seja suportado.

Se uma dependência de artefato for declarada que não alteraria a ordem padrão, nenhuma alteração será feita. Um exemplo é um grupo de recursos que depende de uma política no nível da assinatura. Outro exemplo é uma atribuição de política filho 'standard-rg' do grupo de recursos que depende da atribuição de função filho 'standard-rg' do grupo de recursos. Em ambos os casos, o dependsOn não teria alterado a ordem de sequenciamento padrão e nenhuma alteração seria feita.

Próximas etapas