Déploiement de ressources dans plusieurs étendues
Il peut arriver que vous deviez déployer des ressources à plusieurs niveaux de votre hiérarchie en une seule fois. Voici quelques situations de ce type :
- Vous devez déployer des ressources dans deux groupes de ressources différents. Par exemple, vous pouvez créer un groupe de sécurité réseau dans un groupe de ressources partagées tout en déployant une interface réseau pour une machine virtuelle dans un groupe de ressources pour votre application.
- Vous utilisez un modèle pour créer un groupe de ressources (soit une ressource étendue à l’abonnement), puis vous souhaitez déployer un compte de stockage et d’autres ressources Azure dans ce groupe de ressources dans le cadre d’un déploiement étendu au groupe de ressources.
- Vous déployez une hiérarchie de groupes d’administration et souhaitez également déployer des abonnements (soit des ressources étendues au locataire).
Avec Bicep, vous pouvez créer un déploiement qui fonctionne sur plusieurs étendues avec le mot-clé scope.
Notes
Les commandes de cette unité sont présentées pour illustrer les concepts. N’exécutez pas encore les commandes. Vous allez bientôt mettre en pratique ce que vous apprenez ici.
Spécification de l’étendue d’un module
Vous pouvez utiliser les modules Bicep pour déployer un ensemble de ressources dans une étendue différente du targetScope spécifié dans le fichier. Voici un exemple de fichier Bicep déployé pour lequel targetScope est égal à subscription, mais qui utilise un module pour déployer certaines ressources dans un groupe de ressources :
targetScope = 'subscription'
module networkModule 'modules/network.bicep' = {
scope: resourceGroup('ToyNetworking')
name: 'networkModule'
}
Comme vous pouvez le constater, la propriété scope emploie une fonction Bicep pour identifier l’étendue à cibler. Dans l’exemple précédent, la fonction resourceGroup() est utilisée, et le nom du groupe de ressources à cibler est spécifié. Vous pouvez également vous servir des fonctions subscription(), managementGroup() et tenant(). En utilisant le mot-clé targetScope sur les fichiers Bicep et le mot-clé scope sur les modules, il est possible de créer de nombreuses combinaisons différentes d’étendues pour les déploiements.
Notes
Il existe une exception : les fichiers Bicep pour lesquels targetScope est égal à resourceGroup ou à subscription ne peuvent pas inclure de module pour lequel scope est égal à managementGroup.
Conseil
Si vous utilisez un fichier Bicep étendu à l’abonnement pour créer un groupe de ressources, vous pouvez utiliser le nom symbolique de ce dernier comme scope du module. Vous verrez comment faire dans l’exercice suivant.
Déploiement dans plusieurs groupes de ressources
Une utilisation courante des étendues consiste à déployer des ressources dans plusieurs groupes de ressources. Bien que la propriété scope ne puisse pas être définie sur la plupart des ressources Azure, vous pouvez utiliser des modules pour indiquer à Bicep qu’un ensemble de ressources doit être déployé dans un autre groupe de ressources.
Supposons par exemple que vous vouliez créer un ensemble unique de fichiers Bicep qui déploie un réseau virtuel et les ressources associées dans un groupe de ressources partagées nommé ToyNetworking, puis déployer une interface réseau dans un autre groupe de ressources. Le fichier Bicep se présente ainsi :
module networkModule 'modules/network.bicep' = {
scope: resourceGroup('ToyNetworking')
name: 'networkModule'
}
resource networkInterface 'Microsoft.Network/networkInterfaces@2020-11-01' = {
name: 'production-nic'
location: resourceGroup().location
properties: {
ipConfigurations: [
{
name: 'toy-subnet-ip-configuration'
properties: {
subnet: {
id: networkModule.outputs.subnetResourceId
}
}
}
]
}
}
Comme vous pouvez le constater, les ressources à déployer dans le groupe de ressources ToyNetworking sont définies dans un module, et la sortie subnetResourceId est utilisée dans la définition des ressources de l’interface réseau.
Après avoir déployé ce fichier, vous pouvez cibler un autre groupe de ressources nommé ProjectTeddybear :
az deployment group create --resource-group ProjectTeddybear ...
New-AzResourceGroupDeployment -ResourceGroupName ProjectTeddybear ...
Bien que le déploiement vise le groupe de ressources ProjectTeddybear, les ressources du réseau virtuel sont déployées dans le groupe de ressources ToyNetworking. L’interface réseau est déployée dans le groupe de ressources ProjectTeddybear.
Vous pouvez même déployer un groupe de ressources dans un autre abonnement en incluant l’ID de l’abonnement dans l’étendue resourceGroup :
module networkModule 'modules/network.bicep' = {
scope: resourceGroup('f0750bbe-ea75-4ae5-b24d-a92ca601da2c', 'ToyNetworking')
name: 'networkModule'
}
De même, vous pouvez utiliser la fonction d’étendue subscription() pour déployer des ressources sur plusieurs abonnements dans l’étendue de l’abonnement, et la fonction d’étendue managementGroup() pour les déployer sur plusieurs groupes d’administration. Cependant, vous ne pouvez pas les déployer sur plusieurs locataires.
Spécification de l’étendue d’une seule ressource
Vous pouvez utiliser le mot-clé scope sur plusieurs types de ressources spécifiques, et pas seulement sur les modules. Les ressources d’extension l’utilisent pour préciser à quelle ressource elles s’appliquent. Il peut également servir à déployer des ressources étendues aux locataires à partir de n’importe quel modèle.
Par exemple, vous pouvez utiliser un fichier Bicep pour créer une hiérarchie de groupes d’administration, comme le montre l’exemple suivant :
targetScope = 'managementGroup'
resource parentManagementGroup 'Microsoft.Management/managementGroups@2020-05-01' = {
scope: tenant()
name: 'NonProduction'
properties: {
displayName: 'Non-production'
}
}
resource childManagementGroup 'Microsoft.Management/managementGroups@2020-05-01' = {
scope: tenant()
name: 'SecretRND'
properties: {
displayName: 'Secret R&D Projects'
details: {
parent: {
id: parentManagementGroup.id
}
}
}
}
Comme vous pouvez le constater, cet exemple utilise targetScope = 'managementGroup' dans le fichier modèle, mais déploie ensuite les groupes d’administration dans l’étendue tenant().
Notes
L’exemple précédent montre comment utiliser Bicep pour créer une hiérarchie de groupes d’administration. Le groupe d’administration NonProduction constitue un enfant du groupe d’administration racine, et le groupe d’administration SecretRND un enfant du groupe d’administration NonProduction.
Création d’un groupe d’administration et d’une hiérarchie d’abonnements
Vous savez maintenant déployer de nombreuses ressources différentes dans des étendues variées et utiliser les modules Bicep et le mot-clé scope pour déployer des combinaisons de ressources. Appliquons toutes ces nouvelles connaissances pour étendre la hiérarchie des groupes d’administration de l’exemple précédent. À présent, elle inclut également un alias d’abonnement (soit une ressource étendue au locataire) qui crée un abonnement Azure :
resource subscription 'Microsoft.Subscription/aliases@2020-09-01' = {
scope: tenant()
name: subscriptionAliasName
properties: {
// ...
}
}
Notes
Lorsque vous créez un alias d’abonnement, vous spécifiez également d’autres propriétés, notamment une étendue de facturation. Nous les avons omises pour plus de clarté.
Vous pouvez ensuite associer l’abonnement à un groupe d’administration, ce qui implique le déploiement d’un type de ressource appelé Microsoft.Management/managementGroups/subscriptions. En raison de la façon dont fonctionne cette ressource, vous devez la déclarer dans un module. Par exemple, voici un fichier nommé modules/mg-subscription-association.bicep :
targetScope = 'tenant'
@description('The name of the management group that should contain the subscription.')
param managementGroupName string
@description('The subscription ID to place into the management group.')
param subscriptionId string
resource managementGroup 'Microsoft.Management/managementGroups@2021-04-01' existing = {
name: managementGroupName
}
resource subscriptionAssociation 'Microsoft.Management/managementGroups/subscriptions@2021-04-01' = {
parent: managementGroup
name: subscriptionId
}
Notez que le groupe d’administration est référencé avec le mot clé existing.
Le fichier Bicep principal peut alors créer l’association en incluant le module. Voici le fichier Bicep complet :
targetScope = 'managementGroup'
@description('The name of the subscription alias to deploy.')
param subscriptionAliasName string
resource parentManagementGroup 'Microsoft.Management/managementGroups@2020-05-01' = {
scope: tenant()
name: 'NonProduction'
properties: {
displayName: 'Non-production'
}
}
resource childManagementGroup 'Microsoft.Management/managementGroups@2020-05-01' = {
scope: tenant()
name: 'SecretRND'
properties: {
displayName: 'Secret R&D Projects'
details: {
parent: {
id: parentManagementGroup.id
}
}
}
}
resource subscription 'Microsoft.Subscription/aliases@2020-09-01' = {
scope: tenant()
name: subscriptionAliasName
properties: {
// ...
}
}
module subscriptionAssociation 'modules/mg-subscription-association.bicep' = {
name: 'subscriptionAssociation'
scope: tenant()
params: {
managementGroupName: childManagementGroup.name
subscriptionId: subscription.properties.subscriptionId
}
}
Comme vous l’avez vu, vous pouvez combiner toutes les fonctionnalités des étendues et du langage Bicep pour créer des déploiements avancés de l’ensemble de votre infrastructure Azure.