Contrôler l’ordre de déploiement en spécifiant des dépendances

Effectué

Supposons que vous souhaitez déployer un ensemble de ressources dans Azure, mais uniquement si une autre ressource est déjà déployée. À ce stade, vous devez communiquer dans le modèle qu’une ressource dépend d’une autre ressource.

Voici quelques aspects à prendre en compte :

• Quelque chose doit exister avant qu’autre chose puisse être déployé.

  Par exemple, vous avez besoin d’un coffre de clés dans Azure Key Vault pour extraire des secrets que vous devez charger sur une machine virtuelle. Durant le déploiement du coffre de clés, vous pouvez en même temps déployer son secret dans le même modèle. Toutefois, le coffre de clés doit être déployé avant son secret. Le secret dépend donc de l’existence du coffre de clés. Le coffre de clés et le secret sont déployés en série, l’un après l’autre, en commençant par le coffre de clés, en raison de la dépendance.

• Puis-je m’appuyer sur la façon dont les choses fonctionnent sur Azure Resource Manager ?

  Votre première idée au moment de vérifier l’existence d’une autre ressource peut consister à utiliser Azure PowerShell ou Azure CLI pour vérifier l’existence d’une ressource. Une solution plus automatisée utilise l’idempotence intégrée de Resource Manager. Si Resource Manager détecte une ressource définie dans un modèle qui existe déjà dans le cloud, il ne la redéploie pas. Pour que cette approche soit valide, vous devez comprendre comment Resource Manager effectue la vérification.

  Notes

  Quand des identités de ressources existantes correspondent à un élément défini dans un modèle, Azure Resource Manager compare les propriétés. Si les propriétés correspondent exactement, la ressource est laissée de côté. Si ce n’est pas le cas, le moteur effectue les changements appropriés, et redéploie éventuellement la ressource.

• Vous pouvez imbriquer des ressources dans une autre ressource.

  Dans vos modèles Azure Resource Manager, vous pouvez imbriquer des ressources dans une autre ressource. En imbriquant des ressources, vous définissez une relation entre les ressources imbriquées et la ressource parente.

Comment puis-je définir des dépendances entre ressources Azure ?

Imaginez que vous souhaitiez vérifier qu’une ressource, par exemple un compte de stockage, a été déployée avant une ressource qui en dépend. Comment pouvez-vous vérifier si le compte de stockage dépendant existe ?

Vous pouvez commencer par inspecter l’état actuel de votre déploiement en exécutant des commandes Azure PowerShell ou Azure CLI pour vérifier l’existence du compte de stockage. Vous pouvez également voir s’il existe une construction Resource Manager qui vous permet d’effectuer la même vérification.

Il existe une construction de ce type dans les modèles Resource Manager. Elle s’appelle dependsOn. L’utilisation de cette construction oblige les ressources à attendre la fin du déploiement de la ressource désignée.

Qu’est-ce que la construction dependsOn ?

Il s’agit d’une paire clé-valeur qui vous permet de définir l’ordre de déploiement entre les ressources. Parfois, vous devez vérifier qu’une chose existe avant une autre. Par exemple, vous pouvez avoir besoin qu’une base de données existe avant une application, ou qu’une ressource relative à un secret existe avant un coffre de clés.

Placez la construction dependsOn sur une ressource qui dépend d’autres ressources à déployer en premier. Une ressource peut dépendre de plusieurs ressources, c’est pourquoi la construction attend une liste de ressources dépendantes comme valeur.

Voici un exemple de la façon dont vous pouvez exprimer ce genre de dépendance au format JSON dans votre modèle ARM :

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

Dans cet exemple, vous utilisez le nom de la ressource pour spécifier la ressource dont vous dépendez. Toutefois, de nombreuses ressources peuvent avoir le même nom. Pour vérifier que cette comparaison effectue ce que vous souhaitez, vous pouvez utiliser à la place la construction resourceId() afin d’obtenir l’identificateur de ressource unique :

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

Le code JSON ci-dessus construit un ID unique en combinant l’espace de noms, le type et le nom d’une variable. Ainsi, vous avez la certitude que la ressource dépendante appropriée est spécifiée.

Que sont les ressources enfants ?

Une ressource enfant est une ressource qui existe uniquement dans le contexte d’une autre ressource. Par exemple, il peut s’agir d’une extension de machine virtuelle qui ne peut pas exister sans machine virtuelle.

Le code classique d’une relation parent-enfant dans un modèle ressemble à ceci :

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

Cette dépendance parent-enfant ne crée pas automatiquement une dépendance dans laquelle le parent est déployé avant son enfant. Vous devez rendre la dépendance explicite.

Ainsi, lorsque vous exprimez une telle relation, veillez à ajouter une construction dependsOn, comme suit :

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