Déployer des ressources de manière conditionnelle

Effectué

Vous pouvez utiliser des conditions dans votre code Bicep pour déployer des ressources uniquement lorsque des contraintes spécifiques sont en place.

Par exemple, dans votre société de jouets, vous devez déployer des ressources dans différents environnements. Lorsque vous les déployez dans un environnement de production, vous devez vous assurer que l’audit est activé pour vos serveurs logiques Azure SQL. Toutefois, lorsque vous déployez des ressources dans des environnements de développement, vous ne souhaitez pas activer l’audit. Vous souhaitez utiliser un seul modèle pour déployer des ressources dans tous vos environnements.

Dans cette unité, vous apprendrez à déployer des ressources de manière conditionnelle.

Utiliser des conditions de base

Lorsque vous déployez une ressource dans Bicep, vous pouvez indiquer le mot clé if suivi d’une condition. La condition doit se résoudre en une valeur booléenne (vrai ou faux). Si la valeur est true, la ressource est déployée. Si la valeur est false, la ressource n’est pas déployée.

Il est courant de créer des conditions basées sur les valeurs des paramètres que vous fournissez. Par exemple, le code suivant déploie un compte de stockage uniquement lorsque le paramètre deployStorageAccount est défini sur true :

param deployStorageAccount bool

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = if (deployStorageAccount) {
  name: 'teddybearstorage'
  location: resourceGroup().location
  kind: 'StorageV2'
  // ...
}

Notez que le mot clé if se trouve sur la même ligne que la définition de ressource.

Utiliser des expressions en tant que conditions

L’exemple précédent était assez basique. Le paramètre deployStorageAccount était de type bool, il est donc clair qu’il a une valeur true ou false.

Dans Bicep, les conditions peuvent également inclure des expressions. Dans l’exemple suivant, le code déploie une ressource d’audit SQL uniquement lorsque la valeur du paramètre environmentName est égale à Production :

@allowed([
  'Development'
  'Production'
])
param environmentName string

resource auditingSettings 'Microsoft.Sql/servers/auditingSettings@2023-08-01-preview' = if (environmentName == 'Production') {
  parent: server
  name: 'default'
  properties: {
  }
}

Il est généralement judicieux de créer une variable pour l’expression que vous utilisez comme condition. De cette façon, votre modèle est plus facile à comprendre et à lire. Voici un exemple :

@allowed([
  'Development'
  'Production'
])
param environmentName string

var auditingEnabled = environmentName == 'Production'

resource auditingSettings 'Microsoft.Sql/servers/auditingSettings@2023-08-01-preview' = if (auditingEnabled) {
  parent: server
  name: 'default'
  properties: {
  }
}

Dépendre de ressources déployées de manière conditionnelle

Lorsque vous déployez des ressources de manière conditionnelle, vous devez parfois avoir conscience de la façon dont Bicep évalue les dépendances entre elles.

Nous allons continuer à écrire du code Bicep pour déployer les paramètres d’audit SQL. Le fichier Bicep doit également déclarer une ressource de compte de stockage, comme illustré ici :

@allowed([
  'Development'
  'Production'
])
param environmentName string
param location string = resourceGroup().location
param auditStorageAccountName string = 'bearaudit${uniqueString(resourceGroup().id)}'

var auditingEnabled = environmentName == 'Production'
var storageAccountSkuName = 'Standard_LRS'

resource auditStorageAccount 'Microsoft.Storage/storageAccounts@2023-05-01' = if (auditingEnabled) {
  name: auditStorageAccountName
  location: location
  sku: {
    name: storageAccountSkuName
  }
  kind: 'StorageV2'
}

resource auditingSettings 'Microsoft.Sql/servers/auditingSettings@2023-08-01-preview' = if (auditingEnabled) {
  parent: server
  name: 'default'
  properties: {
  }
}

Notez que le compte de stockage a une condition lui aussi. Cela signifie qu’il ne sera pas déployé non plus pour les environnements de non-production. La ressource de paramètres d’audit SQL peut maintenant faire référence aux détails du compte de stockage :

resource auditingSettings 'Microsoft.Sql/servers/auditingSettings@2023-08-01-preview' = if (auditingEnabled) {
  parent: server
  name: 'default'
  properties: {
    state: 'Enabled'
    storageEndpoint: environmentName == 'Production' ? auditStorageAccount.properties.primaryEndpoints.blob : ''
    storageAccountAccessKey: environmentName == 'Production' ? listKeys(auditStorageAccount.id, auditStorageAccount.apiVersion).keys[0].value : ''
  }
}

Notez que ce code Bicep utilise l’opérateur point d’interrogation (?) dans les propriétés storageEndpoint et storageAccountAccessKey. Lorsque le code Bicep est déployé dans un environnement de production, les expressions sont évaluées sur les détails du compte de stockage. Lorsque le code est déployé dans un environnement de non-production, les expressions sont évaluées en une chaîne vide ('').

Vous vous demandez peut-être pourquoi ce code est nécessaire, car auditingSettings et auditStorageAccount ont la même condition, et vous n’aurez donc jamais besoin de déployer une ressource de paramètres d’audit SQL sans compte de stockage. Bien que cela soit vrai, Azure Resource Manager évalue les expressions de propriété avant les conditions sur les ressources. Cela signifie que si le code Bicep n’a pas cette expression, le déploiement échoue avec une erreur ResourceNotFound.

Remarque

Vous ne pouvez pas définir deux ressources portant le même nom dans le même fichier Bicep, puis déployer de manière conditionnelle une seule d’entre elles. Le déploiement échouera, car Resource Manager considère cela comme un conflit.

Si vous disposez de plusieurs ressources, toutes avec la même condition pour le déploiement, envisagez d’utiliser des modules Bicep. Vous pouvez créer un module qui déploie toutes les ressources, puis placer une condition sur la déclaration de module dans votre fichier Bicep principal.