Inzicht in de implementatievolgorde in Azure Blueprints

Belangrijk

Op 11 juli 2026 worden Blauwdrukken (preview) afgeschaft. Migreer uw bestaande blauwdrukdefinities en -toewijzingen naar sjabloonspecificaties en implementatiestacks. Blauwdrukartefacten moeten worden geconverteerd naar ARM JSON-sjablonen of Bicep-bestanden die worden gebruikt om implementatiestacks te definiëren. Zie voor meer informatie over het ontwerpen van een artefact als een ARM-resource:

Azure Blueprints gebruikt een volgorde om de volgorde van het maken van resources te bepalen bij het verwerken van de toewijzing van een blauwdrukdefinitie. In dit artikel worden de volgende concepten uitgelegd:

  • De standaardvolgorde die wordt gebruikt
  • De bestelling aanpassen
  • Hoe de aangepaste bestelling wordt verwerkt

Er zijn variabelen in de JSON-voorbeelden die u moet vervangen door uw eigen waarden:

  • Vervang {YourMG} door de naam van uw beheergroep

Standaardvolgorde

Als de blauwdrukdefinitie geen instructie bevat voor de volgorde om artefacten te implementeren of als de -instructie null is, wordt de volgende volgorde gebruikt:

  • Roltoewijzingartefacten op abonnementsniveau gesorteerd op artefactnaam
  • Artefacten voor beleidstoewijzing op abonnementsniveau gesorteerd op artefactnaam
  • Azure Resource Manager-sjabloonartefacten (ARM-sjablonen) op abonnementsniveau gesorteerd op artefactnaam
  • Resourcegroepartefacten (inclusief onderliggende artefacten) gesorteerd op naam van tijdelijke aanduiding

Binnen elk resourcegroepartefact wordt de volgende volgorde gebruikt voor artefacten die binnen die resourcegroep moeten worden gemaakt:

  • Artefacten voor onderliggende roltoewijzing van resourcegroep gesorteerd op artefactnaam
  • Artefacten voor onderliggende beleidstoewijzing van resourcegroep gesorteerd op artefactnaam
  • Resourcegroep onderliggende Azure Resource Manager-sjabloonartefacten (ARM-sjablonen) gesorteerd op artefactnaam

Notitie

Met het gebruik van artifacts() wordt een impliciete afhankelijkheid gemaakt van het artefact waarnaar wordt verwezen.

De volgorde aanpassen

Bij het opstellen van grote blauwdrukdefinities kan het nodig zijn dat resources in een specifieke volgorde worden gemaakt. Het meest voorkomende gebruikspatroon van dit scenario is wanneer een blauwdrukdefinitie verschillende ARM-sjablonen bevat. Azure Blueprints verwerkt dit patroon door het definiëren van de volgorde toe te staan.

De volgorde wordt bereikt door een dependsOn eigenschap in de JSON te definiëren. De blauwdrukdefinitie voor resourcegroepen en artefactobjecten ondersteunen deze eigenschap. dependsOn is een tekenreeksmatrix met artefactnamen die het specifieke artefact moet maken voordat het wordt gemaakt.

Notitie

Bij het maken van blauwdrukobjecten krijgt elke artefactresource zijn naam uit de bestandsnaam, als u PowerShell gebruikt of het URL-eindpunt, als u REST API gebruikt. resourceGroup-verwijzingen in artefacten moeten overeenkomen met de verwijzingen die zijn gedefinieerd in de blauwdrukdefinitie.

Voorbeeld: geordende resourcegroep

Deze voorbeeldblauwdrukdefinitie bevat een resourcegroep die een aangepaste volgorde heeft gedefinieerd door een waarde te declareren voor dependsOn, samen met een standaardresourcegroep. In dit geval wordt het artefact met de naam assignPolicyTags verwerkt vóór de resourcegroep ordered-rg . standard-rg wordt verwerkt volgens de standaardvolgorde.

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

Voorbeeld: artefact met aangepaste volgorde

Dit voorbeeld is een beleidsartefact dat afhankelijk is van een ARM-sjabloon. Standaard wordt een beleidsartefact gemaakt vóór de ARM-sjabloon. Door deze volgorde kan het beleidsartefact wachten tot de ARM-sjabloon is gemaakt.

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

Voorbeeld: sjabloonartefact op abonnementsniveau, afhankelijk van een resourcegroep

In dit voorbeeld wordt een ARM-sjabloon die is geïmplementeerd op abonnementsniveau afhankelijk van een resourcegroep. In de standaardvolgorde worden de artefacten op abonnementsniveau gemaakt vóór resourcegroepen en onderliggende artefacten in deze resourcegroepen. De resourcegroep wordt als volgt in de blauwdrukdefinitie gedefinieerd:

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

Het sjabloonartefact op abonnementsniveau, afhankelijk van de wachtgroep , wordt als volgt gedefinieerd:

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

De aangepaste reeks verwerken

Tijdens het maken wordt een topologische sortering gebruikt om de afhankelijkheidsgrafiek van de blauwdrukartefacten te maken. De controle zorgt ervoor dat elk afhankelijkheidsniveau tussen resourcegroepen en artefacten wordt ondersteund.

Als een artefactafhankelijkheid wordt gedeclareerd die de standaardvolgorde niet wijzigt, wordt er geen wijziging aangebracht. Een voorbeeld is een resourcegroep die afhankelijk is van beleid op abonnementsniveau. Een ander voorbeeld is een onderliggende beleidstoewijzing 'standard-rg' van de resourcegroep die afhankelijk is van de onderliggende roltoewijzing standard-rg van de resourcegroep. In beide gevallen zou de dependsOn de standaardvolgorde niet hebben gewijzigd en zouden er geen wijzigingen worden aangebracht.

Volgende stappen