Déploiement de ressources avec Bicep et Azure CLI

  • Article

Cet article explique comment utiliser Azure CLI avec les fichiers Bicep pour déployer vos ressources dans Azure. Si vous n’avez pas une bonne connaissance des concepts de déploiement et de gestion des solutions Azure, consultez Vue d’ensemble de Bicep.

Prérequis

Vous avez besoin d’un fichier Bicep à déployer. Le fichier doit être local.

Vous avez besoin d'Azure CLI et devez être connecté à Azure :

  • Installez les commandes Azure CLI sur votre ordinateur local. Pour déployer des fichiers Bicep, vous devez disposer d’Azure CLI version 2.20.0 ou ultérieure.
  • Connectez-vous à Azure à l’aide de la commande az login . Si vous disposez de plusieurs abonnements Azure, vous devrez peut-être également exécuter az account set.

Des exemples pour l’interface CLI sont écrits pour l’interpréteur de commandes bash. Pour exécuter cet exemple dans Windows PowerShell ou à une invite de commandes, vous devrez sans doute modifier certains éléments du script.

Si Azure CLI n’est pas installé, vous pouvez utiliser Azure Cloud Shell. Pour plus d’informations, consultez Déployer des fichiers Bicep à partir d’Azure Cloud Shell.

Autorisations requises

Pour déployer un fichier Bicep ou un modèle ARM, vous devez disposer d’un accès en écriture aux ressources que vous déployez et un accès à toutes les opérations sur le type de ressource Microsoft.Resources/deployments. Par exemple, pour déployer une machine virtuelle, vous avez besoin des autorisations Microsoft.Compute/virtualMachines/write et Microsoft.Resources/deployments/*. L’opération de simulation présente les mêmes exigences d’autorisation.

Pour obtenir la liste des rôles et autorisations, consultez Rôles intégrés Azure.

Étendue du déploiement

Vous pouvez cibler votre déploiement au niveau d’un groupe de ressources, d’un abonnement, d’un groupe d’administration ou d’un locataire. Les commandes à utiliser diffèrent en fonction de l’étendue du déploiement.

Pour chaque étendue, l’utilisateur qui déploie le fichier Bicep doit disposer des autorisations nécessaires afin de créer des ressources.

Déployer un fichier Bicep local

Vous pouvez déployer un fichier Bicep à partir de votre ordinateur local ou d’un ordinateur stocké en externe. Cette section décrit le déploiement d’un fichier Bicep local.

Si vous effectuez un déploiement vers un groupe de ressources qui n’existe pas, vous devez commencer par créer ce dernier. Le nom du groupe de ressources ne peut contenir que des caractères alphanumériques, des points, des traits de soulignement, des traits d'union et des parenthèses. Il peut comprendre jusqu’à 90 caractères. Le nom ne peut pas se terminer par un point.

az group create --name ExampleGroup --location "Central US"

Pour déployer un fichier Bicep local, utilisez le commutateur --template-file dans la commande de déploiement. L’exemple suivant montre également comment définir une valeur de paramètre.

az deployment group create \
  --name ExampleDeployment \
  --resource-group ExampleGroup \
  --template-file <path-to-bicep> \
  --parameters storageAccountType=Standard_GRS

Le déploiement peut prendre plusieurs minutes. Au terme, vous voyez un message qui inclut le résultat :

"provisioningState": "Succeeded",

Déployer un fichier Bicep distant

Actuellement, Azure CLI ne prend pas en charge le déploiement de fichiers bicep distants. Vous pouvez utiliser L’interface CLI Bicep pour générer le fichier Bicep dans un modèle JSON, puis chargez le fichier JSON dans l’emplacement distant. Si vous souhaitez en savoir plus, veuillez consulter la rubrique Déployer des modèles ARM JSON distants.

Paramètres

Pour passer des valeurs de paramètre, vous pouvez utiliser des paramètres inline ou un fichier de paramètres. Le fichier de paramètres peut être un fichier de paramètres Bicep ou un fichier de paramètres JSON.

Paramètres inline

Pour passer des paramètres inline, indiquez les valeurs dans parameters. Par exemple, pour transmettre une chaîne et un tableau à un fichier Bicep dans un interpréteur de commandes Bash, utilisez :

az deployment group create \
  --resource-group testgroup \
  --template-file <path-to-bicep> \
  --parameters exampleString='inline string' exampleArray='["value1", "value2"]'

Si vous utilisez l’interface de ligne de commande Azure avec l’invite de commandes Windows (CMD) ou PowerShell, transmettez le tableau au format : exampleArray="['value1','value2']".

Vous pouvez également récupérer le contenu d’un fichier et fournir ce contenu en tant que paramètre inline. Préfacez le nom de fichier avec @.

az deployment group create \
  --resource-group testgroup \
  --template-file <path-to-bicep> \
  --parameters exampleString=@stringContent.txt exampleArray=@arrayContent.json

Obtenir une valeur de paramètre à partir d’un fichier est utile lorsque vous devez fournir des valeurs de configuration. Par exemple, vous pouvez fournir des valeurs cloud-init pour une machine virtuelle Linux.

Le format arrayContent.json est :

[
  "value1",
  "value2"
]

Pour passer un objet en entrée, par exemple pour définir des balises, utilisez JSON. Par exemple, votre fichier Bicep peut inclure un paramètre comme celui-ci :

"resourceTags": {
  "type": "object",
  "defaultValue": {
    "Cost Center": "IT Department"
  }
}

Dans ce cas, vous pouvez passer une chaîne JSON pour définir le paramètre comme indiqué dans le script bash suivant :

tags='{"Owner":"Contoso","Cost Center":"2345-324"}'
az deployment group create --name addstorage  --resource-group myResourceGroup \
--template-file $bicepFile \
--parameters resourceName=abcdef4556 resourceTags="$tags"

Utilisez des guillemets doubles autour du JSON que vous voulez passer à l’objet.

Si vous utilisez Azure CLI avec l’invite de commandes Windows (CMD) ou PowerShell, passez l’objet au format suivant :

$tags="{'Owner':'Contoso','Cost Center':'2345-324'}"
az deployment group create --name addstorage  --resource-group myResourceGroup \
--template-file $bicepFile \
--parameters resourceName=abcdef4556 resourceTags=$tags

Vous pouvez utiliser une variable pour contenir les valeurs de paramètre. Dans Bash, définissez la variable sur toutes les valeurs de paramètre et ajoutez-la à la commande de déploiement.

params="prefix=start suffix=end"

az deployment group create \
  --resource-group testgroup \
  --template-file <path-to-bicep> \
  --parameters $params

Toutefois, si vous utilisez Azure CLI avec l’invite de commandes (CMD) Windows ou PowerShell, définissez la variable sur une chaîne JSON. Échappez les guillemets : $params = '{ \"prefix\": {\"value\":\"start\"}, \"suffix\": {\"value\":\"end\"} }'.

L’évaluation des paramètres suit un ordre séquentiel, ce qui signifie que si une valeur est attribuée plusieurs fois, seule la dernière valeur attribuée est utilisée. Pour garantir la bonne affectation des paramètres, nous vous recommandons de fournir initialement votre fichier de paramètres, puis de remplacer de manière sélective des paramètres spécifiques à l’aide de la syntaxe KEY=VALUE. Important : si vous fournissez un fichier de paramètres bicepparam, vous ne pouvez utiliser cet argument qu’une seule fois.

Fichiers de paramètres Bicep

Plutôt que de transmettre des paramètres comme des valeurs inline dans votre script, vous pouvez utiliser un fichier de paramètres, un fichier de paramètres Bicep ou un fichier de paramètres JSON qui contient les valeurs de paramètre. Le fichier de paramètres doit être un fichier local. Les fichiers de paramètres externes ne sont pas pris en charge avec Azure CLI. Pour plus d’informations sur le fichier de paramètres, consultez Créer un fichier de paramètres Resource Manager.

Avec Azure CLI version 2.53.0 ou ultérieure et l’interface CLI Bicep version 0.22 ou ultérieure, vous pouvez déployer un fichier Bicep en utilisant un fichier de paramètres Bicep. Avec l’instruction using dans le fichier de paramètres Bicep, vous n’avez pas besoin de fournir le commutateur --template-file quand vous spécifiez un fichier de paramètres Bicep pour le commutateur --parameters. L’inclusion du commutateur --template-file entraîne l’erreur « Seul un modèle .bicep est autorisé avec un fichier .bicepparam ».

L’exemple suivant montre un fichier de paramètres nommé storage.bicepparam. Le fichier se trouve dans le même répertoire que celui dans lequel la commande est exécutée.

az deployment group create \
  --name ExampleDeployment \
  --resource-group ExampleGroup \
  --parameters storage.bicepparam

Fichiers de paramètres JSON

L’exemple suivant montre un fichier de paramètres nommé storage.parameters.json. Le fichier se trouve dans le même répertoire que celui dans lequel la commande est exécutée.

az deployment group create \
  --name ExampleDeployment \
  --resource-group ExampleGroup \
  --template-file storage.bicep \
  --parameters '@storage.parameters.json'

Pour plus d’informations sur le fichier de paramètres, consultez Créer un fichier de paramètres Resource Manager.

Vous pouvez utiliser des paramètres inclus et un fichier de paramètres d’emplacement pendant la même opération de déploiement. Pour plus d’informations, consultez Priorité des paramètres.

Prévisualiser les modifications

Avant de déployer votre fichier Bicep, vous pouvez obtenir un aperçu des changements que le fichier Bicep apportera à votre environnement. Utilisez l’opération de simulation pour vérifier que le fichier Bicep apporte les changements prévus. Cette opération vérifie aussi que le fichier Bicep est exempt d’erreurs.

Déployer des specs de modèle

Actuellement, Azure CLI ne prend pas en charge la création de spécifications de modèle en fournissant des fichiers Bicep. Toutefois, vous pouvez créer un fichier Bicep avec la ressource Microsoft.Resources/templateSpecs pour déployer un spec de modèle. L’exemple de création de spec de modèle montre comment créer un spec de modèle dans un fichier Bicep. Vous pouvez également générer votre fichier Bicep en JSON à l’aide de l’interface CLI Bicep, puis créer un spec de modèle avec le modèle JSON.

Nom du déploiement

Lorsque vous déployez un fichier Bicep, vous pouvez attribuer un nom au déploiement. Ce nom peut vous aider à récupérer le déploiement à partir de l’historique de déploiement. Si vous n’attribuez pas de nom au déploiement, le nom du fichier Bicep sera utilisé. Par exemple, si vous déployez un fichier Bicep nommé main.bicep sans spécifier de nom pour le déploiement, le déploiement sera nommé main.

Chaque fois que vous exécutez un déploiement, une entrée est ajoutée à l’historique de déploiement du groupe de ressources avec le nom du déploiement. Si vous exécutez un autre déploiement et que vous lui attribuez le même nom, l’entrée précédente est remplacée par le déploiement actuel. Si vous souhaitez conserver des entrées uniques dans l’historique de déploiement, attribuez un nom unique à chaque déploiement.

Pour créer un nom unique, vous pouvez assigner un numéro aléatoire.

deploymentName='ExampleDeployment'$RANDOM

Vous pouvez aussi ajouter une valeur de date.

deploymentName='ExampleDeployment'$(date +"%d-%b-%Y")

Si vous exécutez des déploiements simultanés dans le même groupe de ressources avec le même nom de déploiement, seul le dernier déploiement aboutit. Les déploiements de même nom qui n’arrivent pas à terme sont remplacés par le dernier déploiement. Par exemple, si vous exécutez un déploiement nommé newStorage qui déploie un compte de stockage nommé storage1 et que, dans le même temps, vous exécutez un autre déploiement nommé newStorage qui déploie un compte de stockage nommé storage2, vous ne déployez qu’un seul compte de stockage. Le compte de stockage qui en résulte est nommé storage2.

En revanche, si vous exécutez un déploiement nommé newStorage qui déploie un compte de stockage nommé storage1 et que, aussitôt terminé, vous exécutez un autre déploiement nommé newStorage qui déploie un compte de stockage nommé storage2, vous disposez de deux comptes de stockage : un nommé storage1 et l’autre nommé storage2. Cependant, l’historique de déploiement ne présente qu’une seule entrée.

Quand vous spécifiez un nom unique pour chaque déploiement, vous pouvez les exécuter simultanément sans conflit. Si vous exécutez un déploiement nommé newStorage1 qui déploie un compte de stockage nommé storage1 et que, dans le même temps, vous exécutez un autre déploiement nommé newStorage2 qui déploie un compte de stockage nommé storage2, vous disposez de deux comptes de stockage et l’historique de déploiement présente deux entrées.

Pour éviter les conflits lors de déploiements simultanés et faire en sorte que l’historique de déploiement présente des entrées uniques, attribuez un nom unique à chaque déploiement.

Étapes suivantes