Ajouter de la flexibilité à l’aide de paramètres et de variables

  • 10 minutes

Les modèles sont puissants du fait qu’ils sont réutilisables. Vous pouvez utiliser Bicep pour écrire des modèles qui déploient plusieurs environnements ou copies de vos ressources.

Votre entreprise de jouets lance régulièrement de nouveaux produits sur le marché et vous devez utiliser les modèles Bicep pour créer les ressources Azure requises pour chaque lancement de produit. Vous devez éviter d’utiliser des noms de ressources fixes. De nombreux types de ressources Azure nécessitent des noms uniques : incorporer des noms dans votre modèle signifie donc que vous ne pouvez pas le réutiliser pour le lancement de plusieurs produits. Vous devez également déployer les ressources dans différents emplacements en fonction de l’endroit où les jouets seront lancés, ce qui signifie que vous ne pouvez pas non plus incorporer les emplacements de ressources dans votre modèle.

Dans cette unité, vous allez découvrir les paramètres et les variables, qui sont deux fonctionnalités Bicep permettant de rendre vos modèles flexibles et réutilisables. Vous allez également découvrir les expressions.

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.

Paramètres et variables

Un paramètre vous permet d’importer des valeurs extérieures au fichier de modèle. Par exemple, si vous déployez manuellement le modèle à l’aide de l’interface Azure CLI ou d’Azure PowerShell, vous serez invitée à fournir des valeurs pour chaque paramètre. Vous pouvez également créer un fichier de paramètres, qui répertorie l’ensemble des paramètres et des valeurs que vous souhaitez utiliser pour le déploiement. Si le modèle est déployé à partir d’un processus automatisé comme un pipeline de déploiement, le pipeline peut fournir les valeurs de paramètre.

Une variable est définie et paramétrée dans le modèle. Les variables vous permettent de stocker des informations importantes à un même emplacement et d’y faire référence partout dans le modèle, sans devoir effectuer de copier-coller.

Il est généralement judicieux d’utiliser des paramètres pour les éléments qui varient entre chaque déploiement, comme :

  • Les noms des ressources qui doivent être uniques.
  • Les emplacements où déployer les ressources.
  • Les paramètres qui affectent la tarification des ressources, comme leurs références SKU, les niveaux tarifaires et le nombre d’instances.
  • Les informations d’identification et les informations nécessaires pour accéder à d’autres systèmes qui ne sont pas définis dans le modèle.

Les variables constituent généralement une option intéressante quand vous utilisez les mêmes valeurs pour chaque déploiement mais que vous souhaitez rendre une valeur réutilisable dans le modèle ou quand vous souhaitez utiliser des expressions pour créer une valeur complexe. Vous pouvez également utiliser des variables pour les ressources qui n’ont pas besoin de noms uniques.

Conseil

Il est important d’utiliser une attribution correcte des noms pour les paramètres et les variables, afin que vos modèles soient faciles à lire et à comprendre. Assurez-vous que vous utilisez des noms clairs, descriptifs et cohérents.

Ajouter un paramètre

Dans Bicep, vous pouvez définir un paramètre comme suit :

param appServiceAppName string

Examinons le fonctionnement de chaque partie de cette définition :

  • param indique à Bicep que vous définissez un paramètre.
  • appServiceAppName correspond au nom du paramètre. Si vous déployez le modèle manuellement, vous serez peut être invitée à entrer une valeur. Il est donc important que le nom soit clair et compréhensible. Le nom est également la manière dont vous faites référence à la valeur du paramètre dans le modèle, comme avec les noms symboliques des ressources.
  • string correspond au type du paramètre. Vous pouvez spécifier plusieurs types différents pour les paramètres Bicep, notamment string pour le texte, int pour les nombres et bool pour les valeurs booléennes true/false. Vous pouvez également transmettre des paramètres plus complexes à l’aide des types array et object.

Conseil

Essayez de ne pas trop généraliser les modèles en utilisant un nombre trop important de paramètres. Vous devez utiliser le nombre minimal de paramètres dont vous avez besoin pour votre scénario métier. Rappelez-vous que vous pouvez toujours modifier les modèles ultérieurement si vos exigences évoluent.

Fournir les valeurs par défaut

Vous pouvez éventuellement fournir une valeur par défaut pour un paramètre. Lorsque vous spécifiez une valeur par défaut, le paramètre devient facultatif. La personne qui déploie le modèle peut spécifier une valeur si elle le souhaite, mais si ce n’est pas le cas, Bicep utilise la valeur par défaut.

Voici comment vous pouvez ajouter une valeur par défaut :

param appServiceAppName string = 'toy-product-launch-1'

Notes

Dans cet exemple, le nom de l’application Azure App Service a une valeur par défaut codée en dur. Ce n’est pas une bonne idée, car les applications App Service ont besoin de noms uniques. Vous allez bientôt résoudre ce problème.

Utiliser des valeurs de paramètre dans le modèle

Après avoir déclaré un paramètre, vous pouvez y faire référence dans le reste du modèle. Voyons comment vous pouvez utiliser votre nouveau paramètre dans la définition de ressource :

resource appServiceApp 'Microsoft.Web/sites@2023-12-01' = {
  name: appServiceAppName
  location: 'eastus'
  properties: {
    serverFarmId: appServicePlan.id
    httpsOnly: true
  }
}

Notez que le modèle utilise désormais la valeur de paramètre pour définir le nom de ressource de la ressource d’application, au lieu de coder une valeur en dur.

Conseil

L’extension Bicep pour Visual Studio Code vous montre des indicateurs visuels qui vous permettent de savoir quand vous ne suivez pas les pratiques recommandées. Par exemple, elle vous avertit si vous définissez un paramètre que vous n’utilisez pas. Le linter Bicep exécute continuellement ces vérifications pendant que vous travaillez.

Ajouter une variable

Vous pouvez définir une variable comme suit :

var appServicePlanName = 'toy-product-launch-plan'

Les variables sont définies de la même façon que les paramètres, mais il existe quelques différences :

  • Utilisez le mot clé var pour indiquer à Bicep que vous déclarez une variable.
  • Vous devez fournir une valeur pour une variable.
  • Les variables n’ont pas besoin de types. Bicep peut déterminer le type en fonction de la valeur que vous avez définie.

Expressions

Quand vous écrivez des modèles, vous ne voulez généralement pas coder des valeurs en dur, ni même les demander pour les spécifier dans un paramètre. Au lieu de cela, vous souhaitez découvrir des valeurs quand le modèle s’exécute. Par exemple, vous voulez probablement déployer toutes les ressources d’un modèle dans une seule région Azure : la région où vous avez créé le groupe de ressources. Vous pouvez aussi créer automatiquement un nom unique pour une ressource en fonction d’une stratégie de nommage particulière utilisée par votre entreprise.

Les expressions dans Bicep sont une fonctionnalité puissante qui permet de gérer toutes sortes de scénarios intéressants. Jetons un coup d’œil à quelques emplacements où vous pouvez utiliser des expressions dans un modèle Bicep.

Emplacements de ressource

Quand vous écrivez et déployez un modèle, vous préférez souvent ne pas devoir spécifier l’emplacement de chaque ressource individuellement. Au lieu de cela, vous pouvez avoir une simple règle d’entreprise indiquant que Par défaut, déployer toutes les ressources au même emplacement que celui où le groupe de ressources a été créé.

Dans Bicep, vous pouvez créer un paramètre appelé location, puis utiliser une expression pour définir sa valeur :

param location string = resourceGroup().location

Examinez la valeur par défaut de ce paramètre. Elle utilise une fonction appelée resourceGroup(), qui vous donne accès aux informations sur le groupe de ressources où le modèle doit être déployé. Dans cet exemple, le modèle utilise la propriété location. Il est courant d’utiliser cette approche pour déployer vos ressources dans la même région Azure que le groupe de ressources.

Si une personne déploie ce modèle, elle peut choisir de remplacer la valeur par défaut ici et d’utiliser un autre emplacement.

Notes

Certaines ressources dans Azure peuvent être déployées seulement à certains emplacements. Vous aurez peut-être besoin de paramètres distincts pour définir les emplacements de ces ressources.

Vous pouvez maintenant utiliser le paramètre d’emplacement de la ressource dans le modèle, comme ceci :

resource appServiceApp 'Microsoft.Web/sites@2023-12-01' = {
  name: appServiceAppName
  location: location
  properties: {
    serverFarmId: appServicePlan.id
    httpsOnly: true
  }
}

Noms de ressource

De nombreuses ressources Azure ont besoin de noms uniques. Dans votre scénario, deux ressources ont besoin de noms uniques : le compte de stockage et l’application App Service. Si ces valeurs doivent être définies en tant que paramètres, cela peut compliquer la tâche des personnes qui utilisent le modèle, car elles doivent trouver un nom que personne d’autre n’a utilisé.

Bicep possède une autre fonction appelée uniqueString() qui est utile quand vous créez des noms de ressources. Quand vous utilisez cette fonction, vous devez fournir une valeur initiale, qui doit être différente dans différents déploiements, mais cohérente dans tous les déploiements pour les mêmes ressources.

Si vous choisissez une bonne valeur de départ, vous pouvez obtenir le même nom chaque fois que vous déployez le même ensemble de ressources, mais vous obtenez un nom différent chaque fois que vous déployez un ensemble de ressources différent à l’aide du même modèle. Voyons comment vous pouvez utiliser la fonction uniqueString() :

param storageAccountName string = uniqueString(resourceGroup().id)

La valeur par défaut de ce paramètre utilise à nouveau la fonction resourceGroup(), comme vous l’avez fait en définissant l’emplacement de la ressource. Toutefois, vous obtenez cette fois l’ID d’un groupe de ressources. Voici à quoi ressemble un ID de groupe de ressources :

/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup

L’ID du groupe de ressources comprend l’ID d’abonnement Azure (aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e) et le nom du groupe de ressources (MyResourceGroup). L’ID du groupe de ressources est souvent un bon candidat pour une valeur seed pour les noms de ressources car :

  • Chaque fois que vous déployez les mêmes ressources, celles-ci sont placées dans le même groupe de ressources. La fonction uniqueString() retourne la même valeur à chaque fois.
  • Si vous déployez dans deux groupes de ressources différents dans l’abonnement Azure, la valeur de resourceGroup().id sera différente, car les noms des groupes de ressources seront différents. La fonction uniqueString() donne des valeurs différentes pour chaque ensemble de ressources.
  • Si vous effectuez le déploiement dans deux abonnements Azure différents, même si vous utilisez le même nom de groupe de ressources, la valeur resourceGroup().id sera différente car l’ID d’abonnement Azure sera différent. La fonction uniqueString() donne à nouveau des valeurs différentes pour chaque ensemble de ressources.

Conseil

Il est souvent judicieux d’utiliser des expressions de modèle pour créer des noms de ressources. De nombreux types de ressources Azure ont des règles relatives aux caractères autorisés et à la longueur des noms. Le fait d’incorporer la création des noms de ressources dans le modèle signifie que les personnes utilisant le modèle n’ont pas besoin de suivre ces règles elles-mêmes.

Chaînes combinées

Si vous utilisez simplement la fonction uniqueString() pour définir des noms de ressources, vous allez probablement obtenir des noms uniques, mais ils ne seront pas explicites. Un nom de ressource pertinent doit également être descriptif afin que la finalité de la ressource soit claire. Il est souvent recommandé de créer un nom en combinant un mot ou une chaîne explicite avec une valeur unique. De cette façon, vous obtenez des ressources dont le nom est explicite et unique.

Bicep dispose d’une fonctionnalité appelée interpolation de chaîne qui permet de combiner des chaînes. Voyons comment cela fonctionne :

param storageAccountName string = 'toylaunch${uniqueString(resourceGroup().id)}'

La valeur par défaut du paramètre storageAccountName se compose à présent de deux parties :

  • toylaunch est une chaîne codée en dur qui permet à toute personne examinant la ressource déployée dans Azure de comprendre la finalité de ce compte de stockage.
  • ${uniqueString(resourceGroup().id)} est un moyen d’indiquer à Bicep d’évaluer la sortie de la fonction uniqueString(resourceGroup().id), puis de la concaténer dans la chaîne.

Conseil

La fonction uniqueString() crée parfois des chaînes qui commencent par un chiffre. Certaines ressources Azure, comme les comptes de stockage, n’autorisent pas les noms qui commencent par un chiffre. Cela signifie qu’il est judicieux d’utiliser l’interpolation de chaîne pour créer des noms de ressource, comme dans l’exemple précédent.

Sélection des références SKU pour des ressources

Les autres membres de votre équipe sont impressionnés par le code Bicep que vous avez créé jusqu’à présent. Vous avez décidé d’utiliser votre modèle pour déployer les ressources afin de prendre en charge tout les lancements de votre nouveau jouet.

L’un de vos collègues vous a suggéré de créer des environnements hors production pour chaque lancement de produit afin d’aider l’équipe marketing à tester les sites avant qu’ils ne soient mis à disposition des clients. Toutefois, vous voulez vous assurer que vous ne consacrez pas trop d’argent à vos environnements hors production, vous décidez donc de certaines stratégies ensemble :

  • Dans les environnements de production, les comptes de stockage sont déployés au niveau de la référence SKU Standard_GRS (stockage géoredondant) pour une résilience élevée. Les plans App Service vont être déployés au niveau de la référence SKU P2v3 pour de hautes performances.
  • Dans les environnements hors production, les comptes de stockage sont déployés avec la référence SKU Standard_LRS (stockage localement redondant). Les plans App Service sont déployés avec la référence SKU F1 gratuite.

L’une des façons d’implémenter ces exigences métier consiste à utiliser des paramètres pour spécifier chaque référence. Toutefois, il peut être difficile de gérer la spécification de chaque référence SKU en tant que paramètre, en particulier quand vous avez des modèles plus volumineux. Une autre option consiste à incorporer les règles d’entreprise dans le modèle à l’aide d’une combinaison de paramètres, de variables et d’expressions.

Tout d’abord, vous pouvez spécifier un paramètre qui indique si le déploiement est destiné à un environnement de production ou hors production :

@allowed([
  'nonprod'
  'prod'
])
param environmentType string

Notez que ce code utilise une nouvelle syntaxe pour spécifier une liste de valeurs autorisées pour le paramètre environmentType. Bicep n’autorise personne à déployer le modèle tant que l’une de ces valeurs n’est pas fournie.

Ensuite, vous pouvez créer des variables qui déterminent les références SKU à utiliser pour le compte de stockage et le plan App Service en fonction de l’environnement :

var storageAccountSkuName = (environmentType == 'prod') ? 'Standard_GRS' : 'Standard_LRS'
var appServicePlanSkuName = (environmentType == 'prod') ? 'P2V3' : 'F1'

Notez également ici la nouvelle syntaxe. Nous allons la décomposer :

  • (environmentType == 'prod') évalue une valeur booléenne (true ou false), selon la valeur autorisée utilisée pour le paramètre environmentType.
  • ? est appelé un opérateur ternaire et évalue une instruction if/then. La valeur après l’opérateur ? est utilisée si l’expression est vraie. Si l’expression s’évalue à false, la valeur qui suit le signe deux-points (:) est utilisée.

Nous pouvons traduire ces règles en tant que :

  • Pour la variable storageAccountSkuName, si le paramètre environmentType a la valeur prod, il faut utiliser la référence SKU Standard_GRS. Dans le cas contraire, utiliser la référence SKU Standard_LRS.
  • Pour la variable appServicePlanSkuName, si le paramètre environmentType a la valeur prod, utilisez la référence SKU P2V3 et le niveau PremiumV3. Dans le cas contraire, utiliser la référence SKU F1.

Conseil

Quand vous créez des expressions à plusieurs parties comme celle-ci, il est préférable d’utiliser des variables plutôt que d’incorporer les expressions directement dans les propriétés de ressource. Cela facilite la lecture et la compréhension de vos modèles, car cela évite d’encombrer vos définitions de ressources avec la logique.

Lorsque vous utilisez des paramètres, des variables et des expressions dans votre modèle, vous pouvez réutiliser votre modèle et déployer rapidement un nouveau jeu de ressources. Par exemple, chaque fois que votre service marketing vous demande de déployer un nouveau site web pour le prochain lancement de jouets, vous fournissez de nouvelles valeurs de paramètre pour chaque environnement que vous déployez, et tout sera prêt !