Définir des ressources enfants

  • 5 minutes

Il est pertinent de déployer des ressources uniquement dans le contexte de leur parent. Ces ressources sont appelées ressources enfants. Il existe de nombreux types de ressource enfant dans Azure. Voici quelques exemples :

Nom Type de ressource
Sous-réseaux du réseau virtuel Microsoft.Network/virtualNetworks/subnets
Configuration App Service Microsoft.Web/sites/config
Bases de données SQL Microsoft.Sql/servers/databases
Extensions de machine virtuelle Microsoft.Compute/virtualMachines/extensions
Conteneurs d’objets blob de stockage Microsoft.Storage/storageAccounts/blobServices/containers
Conteneurs Azure Cosmos DB Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers

Prenons l’exemple d’un conteneur d’objets blob de stockage. Un conteneur d’objets blob doit être déployé dans un compte de stockage, et il n’est pas judicieux qu’un conteneur existe en dehors d’un compte de stockage.

Les types de ressources enfants ont des noms plus longs avec plusieurs parties. Un conteneur d’objets blob de stockage possède ce nom de type complet : Microsoft.Storage/storageAccounts/blobServices/containers. L’ID de ressource d’un conteneur d’objets blob inclut le nom du compte de stockage qui contient le conteneur et le nom du conteneur.

Notes

Certaines ressources enfants peuvent porter le même nom que d’autres types de ressources enfants de parents différents. Par exemple, containers est un type enfant à la fois des comptes de stockage et des bases de données Azure Cosmos DB. Les noms sont les mêmes, mais ils représentent des ressources différentes et leurs noms de type complets sont différents.

Comment les ressources enfants sont-elles définies ?

Avec Bicep, vous pouvez déclarer des ressources enfants de différentes façons. Chaque méthode présente ses propres avantages et est adaptée à certaines situations mais pas à d’autres. Penchons-nous sur chaque approche.

Conseil

Toutes les approches suivantes entraînent les mêmes activités de déploiement dans Azure. Vous pouvez choisir l’approche qui correspond le mieux à vos besoins sans craindre d’arrêt. Vous pouvez mettre à jour votre modèle et changer d’approche.

Ressources imbriquées

Une approche de la définition d’une ressource enfant consiste à imbriquer la ressource enfant à l’intérieur du parent. Voici un exemple de modèle Bicep qui déploie une machine virtuelle et une extension de machine virtuelle. Une extension de machine virtuelle est une ressource enfant qui fournit un comportement supplémentaire pour une machine virtuelle. Dans ce cas, l’extension exécute un script personnalisé sur la machine virtuelle après le déploiement.

resource vm 'Microsoft.Compute/virtualMachines@2024-07-01' = {
  name: vmName
  location: location
  properties: {
    // ...
  }

  resource installCustomScriptExtension 'extensions' = {
    name: 'InstallCustomScript'
    location: location
    properties: {
      // ...
    }
  }
}

Notez que la ressource imbriquée a un type de ressource plus simple que le type normal. Bien que le nom de type complet soit Microsoft.Compute/virtualMachines/extensions, la ressource imbriquée hérite automatiquement du type de ressource du parent. Vous devez donc spécifier uniquement le type de ressource enfant extensions.

Notez également qu’il n’existe aucune version d’API spécifiée pour la ressource imbriquée. Bicep suppose que vous souhaitez utiliser la même version d’API que la ressource parent, bien que vous puissiez remplacer la version de l’API si vous le souhaitez.

Vous pouvez faire référence à une ressource imbriquée à l’aide de l’opérateur ::. Par exemple, vous pouvez créer une sortie qui retourne l’ID de ressource complet de l’extension :

output childResourceId string = vm::installCustomScriptExtension.id

L’imbrication des ressources est un moyen simple de déclarer une ressource enfant. L’imbrication des ressources permet également de rendre la relation parent-enfant évidente pour toutes les personnes qui lisent le modèle. Toutefois, si vous avez beaucoup de ressources imbriquées ou plusieurs couches d’imbrication, les modèles peuvent devenir plus difficiles à lire. En outre, vous pouvez imbriquer des ressources uniquement jusqu’à cinq couches.

Propriété parent

Une deuxième approche consiste à déclarer la ressource enfant sans imbrication. Ensuite, utilisez la propriété parent pour indiquer à Bicep la relation parent-enfant :

resource vm 'Microsoft.Compute/virtualMachines@2024-07-01' = {
  name: vmName
  location: location
  properties: {
    // ...
  }
}

resource installCustomScriptExtension 'Microsoft.Compute/virtualMachines/extensions@2024-07-01' = {
  parent: vm
  name: 'InstallCustomScript'
  location: location
  properties: {
    // ...
  }
}

Notez que la ressource enfant utilise la propriété parent pour faire référence au nom symbolique de son parent.

Cette approche consistant à faire référence au parent est un autre moyen simple de déclarer une ressource enfant. Bicep comprend la relation entre les ressources parent et enfant, vous n’avez donc pas besoin de spécifier le nom complet de la ressource, ni de configurer une dépendance entre les ressources. Cette approche évite également d’avoir trop d’imbrications, ce qui peut compliquer la lecture. Toutefois, vous devez spécifier explicitement le type de ressource complet et la version d’API chaque fois que vous définissez une ressource enfant à l’aide de la propriété parent.

Pour faire référence à une ressource enfant déclarée avec la propriété parent, utilisez son nom symbolique comme vous le feriez avec une ressource parente normale :

output childResourceId string = installCustomScriptExtension.id

Construire le nom de la ressource

Dans certains cas, il est impossible d’utiliser des ressources imbriquées ou le mot clé parent. C’est le cas par exemple quand vous déclarez des ressources enfants dans une boucle for ou quand vous devez utiliser des expressions complexes pour sélectionner dynamiquement une ressource parent pour un enfant. Dans ces situations, vous pouvez déployer une ressource enfant en créant manuellement le nom de la ressource enfant afin qu’il comprenne le nom de la ressource parent, comme illustré ici :

resource vm 'Microsoft.Compute/virtualMachines@2024-07-01' = {
  name: vmName
  location: location
  properties: {
    // ...
  }
}

resource installCustomScriptExtension 'Microsoft.Compute/virtualMachines/extensions@2024-07-01' = {
  name: '${vm.name}/InstallCustomScript'
  location: location
  properties: {
    // ...
  }
}

Notez que cet exemple utilise l’interpolation de chaîne pour ajouter la propriété name de ressource de machine virtuelle au nom de la ressource enfant. Bicep comprend qu’il y a une dépendance entre vos ressources enfant et parent. Vous pouvez déclarer le nom de la ressource enfant à l’aide de la variable vmName à la place. Si vous faites cela, toutefois, votre déploiement peut échouer, car Bicep ne comprend pas que la ressource parente doit être déployée avant la ressource enfant :

Pour résoudre cette situation, vous pouvez indiquer manuellement à Bicep la dépendance en utilisant le mot-clé dependsOn, comme indiqué ici :

resource vm 'Microsoft.Compute/virtualMachines@2024-07-01' = {
  name: vmName
  location: location
  properties: {
    // ...
  }
}

resource installCustomScriptExtension 'Microsoft.Compute/virtualMachines/extensions@2024-07-01' = {
  name: '${vmName}/InstallCustomScript'
  dependsOn: [
    vm
  ]
  //...
}

Conseil

Il est généralement préférable d’éviter de construire des noms de ressources, car vous perdez un grand nombre des avantages offerts par Bicep quand il comprend les relations entre vos ressources. Utilisez cette option uniquement quand vous ne pouvez pas utiliser l’une des autres options pour déclarer des ressources enfants.

ID de ressource enfant

Vous commencez à créer un ID de ressource enfant en incluant l’ID de ressource de son parent, puis en ajoutant le type et le nom de la ressource enfant. Prenons l’exemple d’un compte Azure Cosmos DB appelé toyrnd. Le fournisseur de ressources Azure Cosmos DB expose un type appelé databaseAccounts, qui est la ressource parent que vous déployez :

/subscriptions/A123b4567c-1234-1a2b-2b1a-1234abc12345/resourceGroups/ToyDevelopment/providers/Microsoft.DocumentDB/databaseAccounts/toyrnd

Voici une représentation visuelle du même ID de ressource :

ID de ressource d’un compte Azure Cosmos DB, fractionné avec la paire clé-valeur sur une ligne distincte.

Si nous ajoutons une base de données à ce compte, nous pouvons utiliser le type de ressource enfant sqlDatabases. Ajoutons une base de données appelée FlightTests à notre compte Azure Cosmos DB et examinons l’ID de ressource enfant :

/subscriptions/A123b4567c-1234-1a2b-2b1a-1234abc12345/resourceGroups/ToyDevelopment/providers/Microsoft.DocumentDB/databaseAccounts/toyrnd/sqlDatabases/FlightTests

Voici une représentation visuelle :

ID de ressource enfant d’une base de données Azure Cosmos DB, fractionné avec la paire clé-valeur sur une ligne distincte.

Vous pouvez avoir plusieurs niveaux de ressources enfants. Voici un exemple d’ID de ressource montrant un compte de stockage avec deux niveaux d’enfants :

/subscriptions/A123b4567c-1234-1a2b-2b1a-1234abc12345/resourceGroups/ToyDevelopment/providers/Microsoft.Storage/storageAccounts/secrettoys/blobServices/default/containers/glitterspecs

Voici une représentation visuelle du même ID de ressource :

ID de ressource enfant pour un compte de stockage avec un conteneur d’objets blob, fractionné avec la paire clé-valeur sur une ligne distincte.

Cet ID de ressource comprend plusieurs composants :

  • Tout ce qui précède secrettoys est l’ID de ressource parent.

  • blobServices indique que la ressource se trouve dans un type de ressource enfant appelé blobServices.

    Notes

    Vous n’avez pas à créer les ressources blobServices vous-même. Le fournisseur de ressources Microsoft.Storage crée automatiquement cette ressource quand vous créez un compte de stockage. Ce type de ressource est parfois appelé ressource implicite. Ce type est relativement rare, mais vous le trouverez dans Azure.

  • default est le nom de la ressource enfant blobServices.

    Notes

    Parfois, une seule instance d’une ressource enfant est autorisée. Ce type d’instance est appelé singleton et il est souvent nommé default.

  • containers indique que la ressource se trouve dans un type de ressource enfant appelé containers.

  • glitterspecs est le nom du conteneur d’objets blob.

Quand vous utilisez des ressources enfants, les ID de ressource peuvent être longs et sembler compliqués. Toutefois, si vous décomposez un ID de ressource en ses composants, il est plus facile de comprendre comment la ressource est structurée. Un ID de ressource peut également vous fournir des indications importantes sur le comportement de la ressource.