De implementatievolgorde regelen door afhankelijkheden op te geven

Voltooid

Stel dat u een set resources wilt implementeren in Azure, maar alleen als er al een andere resource is geïmplementeerd. Op dat moment moet u de sjabloon laten weten dat de ene resource afhankelijk is van een andere.

U moet rekening houden met de volgende aspecten:

• Iets moet bestaan voordat iets anders kan worden geïmplementeerd.

  Stel dat u een sleutelkluis in Azure Key Vault nodig hebt om geheimen op te halen die u in een virtuele machine (VM) wilt laden. Wanneer u de sleutelkluis implementeert, kunt u tegelijkertijd het geheim in dezelfde sjabloon implementeren. De sleutelkluis moet echter vóór het geheim worden geïmplementeerd. Daarom is het geheim afhankelijk van de sleutelkluis om te kunnen bestaan. De sleutelkluis en het geheim worden serieel geïmplementeerd, de ene na de andere, en vanwege de afhankelijkheid te beginnen met de sleutelkluis.

• Kan ik erop vertrouwen hoe de dingen in Azure Resource Manager functioneren?

  Uw eerste gedachte bij het controleren of er een andere resource aanwezig is, is wellicht dat u hiervoor bijvoorbeeld Azure PowerShell of de Azure CLI wilt gebruiken. Bij een meer geautomatiseerde oplossing wordt gebruikgemaakt van de ingebouwde idempotentie van Resource Manager. Als Resource Manager een resource ontdekt die is gedefinieerd in een sjabloon die al in de cloud aanwezig is, wordt de resource niet opnieuw geïmplementeerd. Als u weet hoe de controle door Resource Manager wordt uitgevoerd, is dit een geldige benadering.

  Notitie

  Wanneer bestaande resource-identiteiten overeenkomen met een definitie in een sjabloon, vergelijkt Azure Resource Manager de eigenschappen. Als de eigenschappen exact overeenkomen, wordt de resource met rust gelaten. Als ze niet overeenkomen, worden de wijzigingen door de engine aangebracht, waarbij de resource mogelijk opnieuw wordt geïmplementeerd.

• U kunt resources binnen een andere resource nesten.

  In uw Azure Resource Manager-sjablonen kunt u resources binnen een andere resource nesten. Door resources te nesten, definieert u een relatie tussen de geneste resources en de bovenliggende resource.

Hoe kan ik afhankelijkheden tussen Azure-resources definiëren?

Stel dat u ervoor wilt zorgen dat een resource (bijvoorbeeld een opslagaccount) is geïmplementeerd voorafgaand aan een resource waarvoor dit account vereist is. Hoe kunt u controleren of het afhankelijke opslagaccount bestaat?

U kunt beginnen met het controleren van de huidige status van uw implementatie door Azure PowerShell of Azure CLI-opdrachten uit te voeren om te controleren of het opslagaccount bestaat. U kunt ook zien of er een Resource Manager-constructie is waarmee u dezelfde controle kunt uitvoeren.

Er bestaat een dergelijke constructie in Resource Manager-sjablonen met de naam dependsOn. Met de deze constructie wordt er gewacht totdat de betreffende resource is geïmplementeerd.

Wat is de dependsOn-constructie?

Dit is een sleutel-waardepaar waarmee u de implementatievolgorde tussen resources kunt definiëren. Soms moet u er zeker van zijn dat er iets bestaat vóór iets anders. Zo moet mogelijk een database aanwezig zijn vóór een app, of moet een geheime resource aanwezig zijn vóór een sleutelkluis.

Plaats de dependsOn-constructie in een resource die afhankelijk is van andere resources die eerst moeten worden geïmplementeerd. Een resource kan afhankelijk zijn van meer dan één resource. Daarom verwacht de constructie een lijst met afhankelijke resources als waarde.

In het volgende voorbeeld ziet u hoe u een dergelijke afhankelijkheid in JSON kunt uitdrukken in de ARM-sjabloon:

"resources": [
  {
    "name": "<name of resource that needs to exist first>"
  },
  {
    "name": "someResource",
    "dependsOn": [
      "<name of resource that needs to exist first>"
    ]
  }
]

In dit voorbeeld gebruikt u de naam van de resource om op te geven van welke resource u afhankelijk bent. Veel resources kunnen echter dezelfde naam hebben. U kunt ervoor zorgen dat deze vergelijking doet wat u wilt, door in plaats daarvan de resourceId()-constructie te gebruiken om de unieke resource-id op te halen:

"dependsOn": [
  "resourceId('Microsoft.Network/loadBalancers', variables('nameOfLoadBalancer')))"
]

Met de bovenstaande JSON-code wordt een unieke id gemaakt door de naamruimte, het type en een variabelenaam te combineren. Op die manier zorgt u ervoor dat de juiste afhankelijke resource is opgegeven.

Wat zijn onderliggende resources?

Een onderliggende resource is een resource die alleen bestaat binnen de context van een andere resource. Een voorbeeld hiervan is een extensie van een virtuele machine, die niet kan bestaan zonder een virtuele machine.

Typische code voor een bovenliggende/onderliggende relatie in een sjabloon ziet er als volgt uit:

"resources": [
  {
    "name": "parent-resource",
    "resources": [{
      "name": "child-resource"
    }]
  }
]

Met deze bovenliggende/onderliggende afhankelijkheid wordt niet automatisch een afhankelijkheid gemaakt waarin het bovenliggende item vóór het onderliggende item wordt geïmplementeerd. U moet de afhankelijkheid expliciet maken.

Als u een dergelijke relatie uitdrukt, moet u dus een dependsOn constructie toevoegen, zoals het volgende:

"resources": [
  {
    "name": "parent-resource",
    "resources": [{
      "dependsOn": ["parent-resource"],
      "name": "child resource"
    }]
  }
]