Partager via

Déployer des fichiers Bicep avec Azure PowerShell

  • Article

Cet article explique comment utiliser Azure PowerShell avec les fichiers Bicep pour déployer vos ressources dans Azure. Si vous n’êtes familiarisé avec le déploiement et la gestion de vos solutions Azure, consultez Présentation de Bicep.

Prérequis

Vous avez besoin d’un fichier Bicep pour déployer, et ce fichier doit être local. Vous avez aussi besoin d’Azure PowerShell et vous devez être connecté à Azure :

Si vous n’avez pas installé PowerShell, vous pouvez utiliser Azure Cloud Shell. Pour plus d’informations, consultez Déployer des fichiers Bicep avec 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. Selon l’étendue du déploiement, vous utilisez des commandes différentes, et l’utilisateur qui déploie le fichier Bicep doit disposer des autorisations requises pour créer des ressources dans chaque étendue.

Déployer un fichier Bicep local

Cette section décrit comment déployer un fichier Bicep local. Vous pouvez déployer un fichier Bicep depuis votre machine locale ou depuis une machine externe.

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 comporter jusqu’à 90 caractères et ne peut pas se terminer par un point.

New-AzResourceGroup -Name ExampleGroup -Location "Central US"

Pour déployer un fichier Bicep local, utilisez le commutateur -TemplateFile dans la commande de déploiement :

New-AzResourceGroupDeployment `
  -Name ExampleDeployment `
  -ResourceGroupName ExampleGroup `
  -TemplateFile <path-to-bicep>

Le déploiement peut prendre plusieurs minutes.

Déployer un fichier Bicep distant

Azure PowerShell ne prend actuellement pas en charge le déploiement de fichiers Bicep distants. Vous pouvez utiliser l’interface CLI Bicep pour créer le fichier Bicep sous la forme d’un modèle JSON, puis charger le fichier JSON à un emplacement distant. Pour plus d’informations, consultez Déployer un modèle distant.

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 les paramètres inline, indiquez les noms des paramètres au moyen de la commande New-AzResourceGroupDeployment. Par exemple, pour passer une chaîne et un tableau à un fichier Bicep, utilisez ceci :

$arrayParam = "value1", "value2"
New-AzResourceGroupDeployment -ResourceGroupName testgroup `
  -TemplateFile <path-to-bicep> `
  -exampleString "inline string" `
  -exampleArray $arrayParam

Vous pouvez utiliser le paramètre TemplateParameterObject pour passer une table de hachage qui contient les paramètres du modèle :

$params = @{
  exampleString = "inline string"
  exampleArray = "value1", "value2"
}

New-AzResourceGroupDeployment -ResourceGroupName testgroup `
  -TemplateFile <path-to-bicep> `
  -TemplateParameterObject $params

Vous pouvez aussi récupérer le contenu d’un fichier et fournir ce contenu en tant que paramètre inline :

$arrayParam = "value1", "value2"
New-AzResourceGroupDeployment -ResourceGroupName testgroup `
  -TemplateFile <path-to-bicep> `
  -exampleString $(Get-Content -Path c:\MyTemplates\stringcontent.txt -Raw) `
  -exampleArray $arrayParam

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.

Si vous devez passer un tableau d’objets, créez des tables de hachage dans Azure PowerShell, puis ajoutez-les à un tableau. Passez ce tableau en tant que paramètre lors du déploiement :

$hash1 = @{ Name = "firstSubnet"; AddressPrefix = "10.0.0.0/24"}
$hash2 = @{ Name = "secondSubnet"; AddressPrefix = "10.0.1.0/24"}
$subnetArray = $hash1, $hash2
New-AzResourceGroupDeployment -ResourceGroupName testgroup `
  -TemplateFile <path-to-bicep> `
  -exampleArray $subnetArray

Fichiers de paramètres Bicep

Au lieu de passer des paramètres comme valeurs inline dans votre script, vous pouvez utiliser un fichier de paramètres Bicep ou un fichier de paramètres JSON qui contient les valeurs des paramètres. Le fichier de paramètres Bicep doit être un fichier local, tandis que le fichier de modèle JSON peut se trouver quelque part en ligne. Pour plus d’informations sur les fichiers de paramètres, consultez Créer des fichiers de paramètres pour un déploiement Bicep.

Vous pouvez utiliser un fichier de paramètres Bicep pour déployer un fichier Bicep avec Azure PowerShell version 10.4.0 ou ultérieure, et avec l’interface CLI Bicep version 0.22.X ou ultérieure. Avec l’instruction using dans le fichier de paramètres Bicep, il n’est pas nécessaire de fournir le commutateur -TemplateFile lors de la spécification d’un fichier de paramètres Bicep pour le commutateur -TemplateParameterFile.

L’exemple suivant montre un fichier de paramètres nommé storage.bicepparam. Le fichier se trouve dans le même répertoire que celui où la commande s’exécute :

New-AzResourceGroupDeployment `
  -Name ExampleDeployment `
  -ResourceGroupName ExampleResourceGroup `
  -TemplateParameterFile storage.bicepparam

Fichier de paramètres JSON

Le fichier de paramètres JSON peut être local ou un fichier externe avec un URI accessible.

Pour transmettre un fichier de paramètres local, utilisez le commutateur TemplateParameterFile avec un fichier de paramètres JSON :

New-AzResourceGroupDeployment `
  -Name ExampleDeployment `
  -ResourceGroupName ExampleResourceGroup `
  -TemplateFile c:\BicepFiles\storage.bicep `
  -TemplateParameterFile c:\BicepFiles\storage.parameters.json

Pour transmettre un fichier de paramètres externe, utilisez le paramètre TemplateParameterUri :

New-AzResourceGroupDeployment `
  -Name ExampleDeployment `
  -ResourceGroupName ExampleResourceGroup `
  -TemplateFile c:\BicepFiles\storage.bicep `
  -TemplateParameterUri https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/quickstarts/microsoft.storage/storage-account-create/azuredeploy.parameters.json

Comme le paramètre TemplateParameterUri ne prend pas en charge les fichiers de paramètres JSON, il ne prend pas en charge les fichiers .bicepparam.

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

Azure PowerShell ne fournit actuellement pas de fichiers Bicep pour vous aider à créer des spécifications de modèle. Cependant, vous pouvez créer un fichier Bicep avec la ressource Microsoft.Resources/templateSpecs pour déployer une spécification de modèle. L’exemple de création de spécification de modèle montre comment créer une spécification de modèle dans un fichier Bicep. Vous pouvez également créer votre fichier Bicep en JSON en utilisant l’interface CLI Bicep, puis un modèle JSON pour créer une spécification de modèle.

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, c’est le nom du fichier Bicep qui est 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 est 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 affecter un nombre aléatoire :

$suffix = Get-Random -Maximum 1000
$deploymentName = "ExampleDeployment" + $suffix

Vous pouvez aussi ajouter une valeur de date :

$today=Get-Date -Format "MM-dd-yyyy"
$deploymentName="ExampleDeployment"+"$today"

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 vous exécutez en même temps 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.

Cependant, si vous exécutez un déploiement nommé newStorage qui déploie un compte de stockage nommé storage1 et que vous exécutez immédiatement après celui-ci un autre déploiement nommé newStorage qui déploie un compte de stockage nommé storage2, vous avez 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 vous exécutez en même temps un autre déploiement nommé newStorage2 qui déploie un compte de stockage nommé storage2, vous avez deux comptes de stockage et deux entrées dans l’historique des déploiements.

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

Pour découvrir comment définir des paramètres dans votre fichier, consultez Comprendre la structure et la syntaxe des fichiers Bicep.