Déploiement de modèles dans différentes étendues
Vous connaissez à présent les différentes étendues dans lesquelles vous pouvez déployer des ressources. Dans cette unité, vous allez apprendre à écrire des fichiers Bicep de déploiement dans ces étendues.
Spécification de l’étendue cible d’un dossier Bicep
Bicep a besoin de savoir dans quelle étendue le fichier est déployé. Cette information est importante, car Bicep doit s’assurer que les ressources déployées sont valides pour l’étendue choisie. Par exemple, l’extension Bicep pour Visual Studio Code vous avertit si vous essayez de définir une ressource dans une étendue non prise en charge.
Utilisez le mot-clé targetScope
pour indiquer à Bicep que les ressources du fichier sont destinées à une étendue spécifique. Voici un exemple de fichier Bicep qui déploie des ressources dans l’étendue du groupe d’administration :
targetScope = 'managementGroup'
resource policyDefinition 'Microsoft.Authorization/policyDefinitions@2024-05-01' = {
// ...
}
Comme vous pouvez le constater, nous indiquons à Bicep qu’il doit déployer les ressources dans l’étendue d’un groupe d’administration, sans pour autant spécifier lequel. C’est au moment de déployer le modèle que l’on spécifie précisément dans quel groupe d’administration les ressources doivent être déployées. Les cmdlets Azure CLI et Azure PowerShell fournissent des arguments permettant de spécifier ces informations.
Vous pouvez définir le targetScope
pour votre fichier sur resourceGroup
, subscription
, managementGroup
ou tenant
. Si vous ne spécifiez pas d’étendue cible, Bicep part du principe que l’étendue est resourceGroup
.
Créer des groupes de ressources
Maintenant que vous savez créer des déploiements dans différentes étendues, essayez d’appliquer ces connaissances à la création d’un groupe de ressources (soit une ressource étendue à l’abonnement) :
targetScope = 'subscription'
resource resourceGroup 'Microsoft.Resources/resourceGroups@2024-07-01' = {
name: 'example-resource-group'
location: 'westus'
}
Comme vous pouvez le constater dans cet exemple, targetScope
est égal à subscription
dans le fichier Bicep, ce qui signifie que Bicep considère toutes les ressources du fichier comme étendues par défaut à l’abonnement.
Remarque
Vous verrez comment utiliser Bicep pour créer des abonnements Azure et des groupes d’administration plus tard dans ce module.
Soumission d’un déploiement
Lorsque vous lancez un déploiement, vous devez indiquer à Azure dans quelle étendue l’effectuer. Vous utiliserez donc une commande Azure CLI différente pour chaque étendue de déploiement :
Pour effectuer un déploiement dans cette étendue : | Exécutez cette commande Azure CLI : |
---|---|
Resource group | az deployment group create |
Abonnement | az deployment sub create |
Groupe d’administration | az deployment mg create |
Locataire | az deployment tenant create |
Lorsque vous lancez un déploiement, vous devez indiquer à Azure dans quelle étendue l’effectuer. Vous utiliserez donc une cmdlet PowerShell différente pour chaque étendue de déploiement :
Pour effectuer un déploiement dans cette étendue : | Utilisez cette cmdlet PowerShell : |
---|---|
Resource group | New-AzResourceGroupDeployment |
Abonnement | New-AzSubscriptionDeployment |
Groupe d’administration | New-AzManagementGroupDeployment |
Locataire | New-AzTenantDeployment |
Azure stocke des métadonnées sur chaque déploiement. Pour les déploiements dans des étendues autres que le groupe de ressources, vous devez fournir certaines informations afin qu’Azure puisse stocker correctement les métadonnées :
Emplacement : les métadonnées de déploiement doivent être stockées dans un emplacement à spécifier. Vous n’avez pas besoin de spécifier d’emplacement pour les déploiements étendus à un groupe de ressources, car les métadonnées de déploiement utilisent le même emplacement que le groupe de ressources. Toutefois, lorsque vous créez un déploiement étendu à l’abonnement, au groupe d’administration ou au locataire, vous devez spécifier la région Azure dans laquelle les métadonnées de déploiement sont stockées. Les ressources de votre déploiement dans ces étendues ne sont pas toujours créées au même emplacement que celui que vous avez spécifié pour les métadonnées.
Nom : tous les déploiements effectués dans Azure possèdent un nom. Vous pouvez demander à Azure des informations sur un déploiement par le biais de son nom. Lorsque vous utilisez Azure CLI ou Azure PowerShell pour soumettre un déploiement, vous n’avez pas besoin de spécifier le nom. Mais si vous ne le spécifiez pas, le nom du fichier de modèle est utilisé comme nom de déploiement.
La combinaison de l’étendue, de l’emplacement et du nom du déploiement doit être unique. Par exemple, supposez que vous créez un déploiement d’abonnement nommé my-deployment
et que vous utilisez l’emplacement USA Est pour stocker ses métadonnées. Vous ne pouvez pas créer un autre déploiement sur le même abonnement également nommé my-deployment
, même s’il se trouve à un autre emplacement, comme Europe Ouest. Si vous créez un autre déploiement nommé my-deployment
dans USA Est, il remplace le déploiement existant.