Varonis debuts trailblazing features for securing Salesforce. Learn More

Introduction de l'automatisation du moindre privilège pour Microsoft 365, Google Drive et Box

En savoir plus

Azure Bicep : Premiers pas et guide pratique

Azure Bicep est le nouveau langage d’infrastructure as code de Microsoft pour le déploiement des ressources Azure. Découvrez ce que vous devez savoir sur ce nouveau langage et faites vos premiers pas.
Jeff Brown
11 minute de lecture
Publié 28 juin 2021
Dernière mise à jour 3 novembre 2021

Vous déployez des ressources sur Azure et essayez d’utiliser des modèles Azure Resource Manager (ARM) ? La syntaxe JSON vous laisse perplexe ? Microsoft a écouté vos critiques et lancé un nouveau projet d’infrastructure as code, appelé Azure Bicep.

Dans cet article, vous apprendrez tout sur Azure Bicep, ses avantages par rapport aux modèles ARM, et profiterez d’un tutoriel de démarrage.

Qu’est-ce qu’Azure Bicep ?

Azure Bicep est un nouveau langage déclaratif utilisé pour déployer des ressources Azure. Bicep est un langage spécialisé que Microsoft a délibérément conçu pour être utilisé dans des scénarios spécifiques. Vous ne pourrez pas utiliser Bicep pour déployer des ressources non Azure ou travailler dans d’autres fournisseurs cloud, tels que AWS d’Amazon ou GCP de Google. Bicep n’est pas non plus un langage de programmation standard destiné à l’écriture d’applications.

Vous souhaitez commencer à apprendre un nouveau langage de programmation ? Consultez l’article de Rob Sober, 11 langages de programmation populaires qui vous ouvrent des portes.

À travers Azure Bicep, l’objectif de Microsoft est de fournir une meilleure expérience de création grâce à une syntaxe simplifiée, une meilleure réutilisation du code et une structure de fichier plus souple. Azure Bicep prend mieux en charge la modularité et la possibilité de réutiliser du code.

Comparaison entre Azure Bicep et les modèles ARM Azure

Les modèles ARM sont des fichiers qui représentent des ressources Azure. Ils sont rédigés dans un format JSON spécifique et plus sophistiqué que le JSON standard. La syntaxe des modèles ARM contient des fonctions et des méthodes permettant de réaliser des opérations complexes.

L’une des critiques les plus courantes concernant le format ARM JSON est qu’il est difficile à écrire et à interpréter en raison de sa syntaxe complexe. Bicep résout ce problème en adoptant une approche plus directe de la syntaxe du langage. Lors de la création d’un modèle ARM, vous devez utiliser des expressions compliquées, et le résultat final peut être assez lourd.

Comparons la syntaxe et le code requis pour déployer un réseau virtuel Azure avec ARM JSON et Bicep. Voici un modèle ARM de base pour déployer ces ressources, qui nécessite 27 lignes :

exemple vnet json

Voici le déploiement de ressources équivalent avec un modèle Bicep, qui n’utilise que 19 lignes. Ne vous inquiétez pas si vous ne comprenez pas la syntaxe. Vous en apprendrez davantage sur la structure des fichiers Bicep en poursuivant ce tutoriel.

exemple vnet bicep

Avantages d’Azure Bicep

Microsoft a créé Azure Bicep pour répondre aux difficultés de prise en main des modèles ARM. De nombreux professionnels de l’informatique trouvent que la longueur et la syntaxe des modèles ARM s’avèrent peu pratiques par rapport à d’autres solutions.

Les avantages d’Azure Bicep sont notamment les suivants :

  • Amélioration de la syntaxe : la syntaxe de Bicep est plus simple pour écrire des modèles. Si la syntaxe d’Hashicorp Terraform vous est familière, vous retiendrez rapidement Bicep car ils sont très similaires. Avec Bicep, vous pouvez pointer vers des paramètres et des variables sans utiliser de fonctions. Bicep intègre l’interpolation de chaînes au lieu de concaténer des chaînes de caractères. Vous pouvez également pointer vers les propriétés des ressources en utilisant leurs noms symboliques au lieu d’instructions de pointage complexes. Ces améliorations facilitent la création et la lecture des modèles Bicep par rapport à la syntaxe ARM JSON.
  • Modules : vous pouvez concevoir des déploiements de modèles complexes en créant des fichiers modules plus petits. Il vous suffit ensuite de pointer vers ces modules dans le modèle principal. Par exemple, vous pouvez avoir un module pour créer une machine virtuelle, puis pointer vers lui depuis le modèle principal.
  • Gestion des dépendances de ressources : dans la plupart des cas, Bicep détectera automatiquement les dépendances de ressources. Les modèles ARM nécessitent de créer soi-même ces dépendances lors de l’élaboration d’un modèle. Par exemple, une machine virtuelle nécessite une interface réseau, qui nécessite un réseau virtuel et un subnet. Bicep identifiera automatiquement ces dépendances de ressources et les déploiera dans l’ordre requis.
  • Installation d’Azure Bicep

Pour créer et déployer les fichiers Bicep, vous devez installer certains outils sur votre système local. Microsoft propose plusieurs options pour les installer sur Windows, Linux et macOS.

Interface de ligne de commande de Bicep

Azure Bicep dispose d’une interface de ligne de commande (CLI) pour compiler les fichiers Bicep dans des modèles ARM JSON. Vous pouvez également utiliser l’interface de ligne de commande de Bicep pour décompiler des modèles ARM JSON dans des fichiers Bicep si vous souhaitez convertir des modèles existants.

Microsoft réalise des installateurs pour Windows, Linux et macOS. Vous pouvez trouver le dernier installateur ici sur la page GitHub du projet. Si vous installez l’interface de ligne de commande de Bicep manuellement, vous devrez ajouter l’emplacement de l’installation à votre variable d’environnement PATH pour utiliser les commandes à partir d’une console.

Microsoft propose également plusieurs scripts pour télécharger, installer et configurer automatiquement votre variable PATH :

Interface de ligne de commande Azure

La CLI d’Azure est un ensemble de commandes utilisées pour créer et gérer des ressources Azure. La CLI d’Azure est disponible pour les systèmes d’exploitation Windows, macOS et Linux et constitue une alternative à l’utilisation d’Azure PowerShell. Apprenez-en davantage sur l’installation de la CLI d’Azure sur votre système.

À partir de la version 2.20.0 de la CLI d’Azure, Microsoft inclut automatiquement les binaires de l’interface de ligne de commande de Bicep. Grâce à cette configuration, vous n’avez pas besoin d’installer Bicep séparément si vous prévoyez de l’utiliser avec la CLI d’Azure.

La CLI d’Azure prend en charge le déploiement de fichiers Bicep en natif à l’aide de commandes de déploiement. Par exemple, au lieu de compiler un fichier Bicep dans un modèle ARM JSON pour un déploiement, vous pouvez déployer le fichier Bicep directement en utilisant la commande suivante :

  1. az deployment group create \
  2. --template-file azuredeploy.bicep \
  3. --resource-group myResourceGroup
az deployment group create \


--template-file azuredeploy.bicep \


--resource-group myResourceGroup

Vous pouvez également exécuter de nombreuses commandes Bicep à l’aide de la commande az bicep :

  1. az bicep
az bicep

Les commandes disponibles incluent la création d’un fichier Bicep à partir d’un modèle ARM ou la mise à niveau de l’interface de ligne de commande Bicep vers la nouvelle version. Voici les commandes actuellement disponibles dans la CLI d’Azure avec la version 0.3.539 de Bicep.

La CLI d’Azure installe une version distincte de la CLI de Bicep qui n’est pas en conflit avec vos autres installations sur le système. La CLI d’Azure n’ajoute pas non plus la CLI de Bicep à votre variable d’environnement PATH. Si vous avez l’intention d’utiliser Bicep en dehors de la CLI d’Azure, vous devrez l’installer en suivant les instructions de la section précédente.

Azure PowerShell

Comme la CLI d’Azure, Azure PowerShell est un ensemble de modules conçus pour le déploiement et la gestion des ressources Azure utilisant PowerShell. Azure PowerShell fonctionne avec PowerShell 5.1 pour systèmes Windows et PowerShell 7 ou version ultérieure pour toutes les plateformes.

Contrairement à la CLI d’Azure, les commandes de la CLI de Bicep ne sont pas automatiquement incluses dans Azure PowerShell. Pour utiliser l’interface de ligne de commande de Bicep, vous devez disposer de la version 5.6.0 ou ultérieure d’Azure PowerShell. Vous devrez avoir déjà installé la CLI de Bicep et l’avoir ajoutée à votre variable d’environnement PATH.

Guettez la sortie d’une future version du module Azure PowerShell prenant en charge les commandes CLI de Bicep.

Création de fichiers Azure Bicep

Pour commencer à écrire des modèles Bicep, Microsoft fournit une extension Visual Studio Code pour Bicep. L’extension prend en charge le langage et l’autocomplétion des ressources pour faciliter la création et la validation de fichiers Bicep.

Dans Visual Studio Code, sélectionnez l’icône Extensions dans la barre latérale gauche pour afficher la place de marché. Recherchez « bicep » et installez l’extension fournie par Microsoft.

Par exemple, lorsque vous définissez une machine virtuelle avec Visual Studio Code, l’extension Bicep fournit l’outil IntelliSense pour les propriétés des machines virtuelles. Vous pouvez rapidement trouver les propriétés des machines virtuelles à définir dans le modèle.

Pour démarrer votre premier modèle Bicep, créez un fichier nommé storageAccount.bicep. Les fichiers Azure Bicep ont une extension .bicep pour les distinguer des modèles ARM. Examinons la syntaxe Bicep pour commencer à créer ce compte de stockage.

Déclaration de ressource

La déclaration de ressource est un composant majeur d’un modèle Bicep. Il vous faut un moyen de définir la ressource Azure que vous souhaitez déployer. Voici un cadre de base pour déclarer une ressource :

  1. resource <symbolic name> ‘Microsoft.<resource type>@<api version>’ = {
  2. // Required properties
  3. name: ‘<resource name>’
  4. location: ‘<Azure region>’
  5. // Remaining resource-specific properties
  6. }
resource <symbolic name> ‘Microsoft.<resource type>@<api version>’ = {


// Required properties


name: ‘<resource name>’


location: ‘<Azure region>’


// Remaining resource-specific properties


}

Examinons ici plus en détail chaque composant de la déclaration de ressource :

  • Resource : utilisé pour déclarer une ressource Azure à des fins de déploiement.
  • Symbolic Name : l’identifiant ou le nom de référence à utiliser dans d’autres emplacements du modèle Bicep. Par exemple, imaginons que vous déployez un réseau virtuel et une machine virtuelle. Dans ce cas, vous devez pointer vers le réseau virtuel où déployer l’interface réseau de la machine virtuelle. Notez qu’il ne s’agit pas du nom de la ressource Azure déployée. Vous utilisez ce nom uniquement pour pointer vers la ressource ultérieurement dans le modèle.
  • Type : type de ressource que vous déployez. Le type est composé du fournisseur de la ressource, tel que Microsoft.Storage, suivi du type de ressource, tel que storageAccounts.
  • API Version : la version de l’API à utiliser lors du déploiement de la ressource. La version de l’API détermine quelles propriétés sont disponibles lors du déploiement de la ressource. La déclaration d’une version d’API est similaire à celle utilisée dans les modèles ARM.
  • Properties : chaque ressource a besoin d’un nom et d’un emplacement pour le déploiement. Le nom que vous spécifiez ici sera le nom de la ressource lors du déploiement dans Azure. La combinaison du type et de la version de l’API détermine les propriétés que vous pouvez utiliser.

Voici le début d’un modèle Bicep pour déployer un compte de stockage. Le nom symbolique est stgAcct, mais le nom de la ressource déployée est stgacctbicepdemo. Notez également la déclaration de type et de version d’API dans la première ligne. Vous définissez ensuite les autres propriétés du compte de stockage telles que l’emplacement, le type de compte de stockage, et le SKU.

  1. resource stgAcct 'Microsoft.Storage/storageAccounts@2021-02-01' = {
  2. name: 'stgacctbicepdemo'
  3. location: 'westus2'
  4. kind: 'StorageV2'
  5. sku: {
  6. name: 'Standard_LRS'
  7. tier: 'Standard'
  8. }
  9. }
resource stgAcct 'Microsoft.Storage/storageAccounts@2021-02-01' = {


name: 'stgacctbicepdemo'


location: 'westus2'


kind: 'StorageV2'


sku: {


name: 'Standard_LRS'


tier: 'Standard'


}


}
Paramètres et variables

Les paramètres et les variables rendent vos modèles Bicep plus dynamiques. Au lieu de coder en dur les valeurs des ressources, vous pouvez spécifier les valeurs au moment du déploiement. Lorsque vous déclarez des paramètres, vous devez transmettre une valeur au modèle Bicep lors de la création du déploiement.

Vous déclarez les paramètres à l’aide du mot clé param et vous déclarez les variables à l’aide du mot clé var. Voici quelques exemples de paramètres Bicep, appelés name et location, et une variable nommée stgAcctName. Notez que le paramètre location a une valeur par défaut westus2 ; donc, si vous ne spécifiez pas de valeur, le déploiement utilisera la région westus2 pour le déploiement.

  1. param name string
  2. param location string = 'westus2'
  3. var stgAcctName = concat(name, '2468')
param name string


param location string = 'westus2'


var stgAcctName = concat(name, '2468')

La variable stgAcctName effectue une concaténation de chaîne du paramètre name et de certains chiffres. Cette action a pour but de donner au compte de stockage un nom unique dans Azure. La déclaration de variable montre également comment vous pouvez utiliser les mêmes fonctions de modèle ARM dans les modèles Bicep.

Voici le modèle storageAccount.bicep mis à jour à l’aide de vos paramètres et variables déclarés. Notez que les valeurs des propriétés nom et emplacement du compte de stockage ont été remplacées par leurs noms de paramètre et de variable équivalents.

  1. param name string
  2. param location string = 'westus2'
  3. var stgAcctName = concat(name, '2468')
  4. resource stgAcct 'Microsoft.Storage/storageAccounts@2021-02-01' = {
  5. name: stgAcctName
  6. location: location
  7. kind: 'StorageV2'
  8. sku: {
  9. name: 'Standard_LRS'
  10. tier: 'Standard'
  11. }
  12. }
param name string


param location string = 'westus2'


var stgAcctName = concat(name, '2468')








resource stgAcct 'Microsoft.Storage/storageAccounts@2021-02-01' = {


name: stgAcctName


location: location


kind: 'StorageV2'


sku: {


name: 'Standard_LRS'


tier: 'Standard'


}


}

Les modèles Bicep utilisent les mêmes fichiers de paramètres écrits en JSON que les modèles ARM. Cela signifie que vous pouvez utiliser vos fichiers de paramètres ARM existants pour déployer des modèles Azure Bicep.

Interpolation de chaînes

L’une des fonctions les plus prisées des modèles ARM est concat(). Cette fonction combine plusieurs chaînes de caractères en une seule. Vous l’avez utilisée dans la section précédente pour concaténer le paramètre name et un nombre en vue de créer la valeur de variable stgAcctName.

Au lieu d’utiliser la concaténation, les modèles Bicep permettent d’utiliser l’interpolation de chaînes de caractères. Vous pouvez définir des chaînes en utilisant un nom de paramètre ou de variable, et Bicep évaluera la chaîne finale en utilisant les valeurs réelles.

Par exemple, au lieu d’utiliser la fonction concat() dans la déclaration de la variable, vous pouvez entourer le nom du paramètre à l’aide de ${ }, comme ceci :

  1. var stgAcctName = '${name}2468'
var stgAcctName = '${name}2468'

Attribution conditionnelle

Les attributions conditionnelles permettent de définir une valeur en fonction de différentes conditions. Par exemple, supposons que le modèle Bicep de votre compte de stockage comporte un paramètre booléen afin d’indiquer si vous souhaitez ou non utiliser des disques SSD plus coûteux pour le compte de stockage (par défaut, false) :

  1. param useSSD bool = false
param useSSD bool = false

Dans la déclaration de la ressource, vous pouvez utiliser un opérateur ternaire pour déterminer le SKU. Un opérateur ternaire revient à utiliser une instruction de type If…Then…Else. Si useSSD est défini sur true (vrai), alors le compte de stockage utilise le SKU Premium_LRS ; sinon, le compte de stockage utilise le SKU Standard_LRS.

  1. param name string
  2. param location string = 'westus2'
  3. param useSSD bool = false
  4. var stgAcctName = '${name}2468'
  5. resource stgAcct 'Microsoft.Storage/storageAccounts@2021-02-01' = {
  6. name: stgAcctName
  7. location: location
  8. kind: 'StorageV2'
  9. sku: {
  10. // if true, use Premium SSD, else use Standard HDD
  11. name: useSSD ? 'Premium_LRS' : 'Standard_LRS'
  12. }
  13. }
param name string


param location string = 'westus2'


param useSSD bool = false








var stgAcctName = '${name}2468'








resource stgAcct 'Microsoft.Storage/storageAccounts@2021-02-01' = {


name: stgAcctName


location: location


kind: 'StorageV2'


sku: {


// if true, use Premium SSD, else use Standard HDD


name: useSSD ? 'Premium_LRS' : 'Standard_LRS'


}


}

 

Déploiement des modèles Bicep

Maintenant que vous avez créé un modèle Bicep, il est temps de déployer le compte de stockage sur Azure ! Il y a deux façons de déployer les modèles Bicep. Vous pouvez réaliser le déploiement en utilisant le modèle Bicep, ou convertir ce dernier en modèle ARM JSON et procéder au déploiement.

Utilisation du fichier modèle Bicep

Azure Resource Manager fonctionne toujours à l’aide des modèles écrits en JSON. Lorsque vous soumettez un modèle Bicep à Azure, les outils de Bicep convertissent le modèle au format JSON. Ce processus est appelé transpilation, c’est-à-dire la conversion d’un langage de programmation en un autre langage.

En tant que créateur du modèle, vous n’avez pas à vous soucier de cette conversion. Vous continuez à définir les ressources Azure dans le modèle Bicep, et Bicep effectue la conversion pour vous.

Pour déployer le modèle Bicep à l’aide d’Azure PowerShell, utilisez la commande New-AzResourceGroupDeployment en spécifiant le groupe de ressources pour déployer les ressources. L’exemple ci-dessous utilise un groupe de ressources nommé bicep-rg.

Vous souhaitez gérer Azure Active Directory et d’autres services Office 365 ? Découvrez comment vous connecter à Office 365 PowerShell : modules Azure AD.

Comme les paramètres location et useSSD ont des valeurs par défaut, il vous suffit de spécifier le paramètre name. Étant donné que New-AzResourceGroupDeployment possède déjà un paramètre -Name, vous utilisez -nameFromTemplate pour spécifier le paramètre pour le modèle Bicep.

  1. New-AzResourceGroupDeployment `
  2. -ResourceGroupName bicep-rg `
  3. -TemplateFile storageAccount.bicep `
  4. -nameFromTemplate 'stgacctbicepdemo'
New-AzResourceGroupDeployment `


-ResourceGroupName bicep-rg `


-TemplateFile storageAccount.bicep `


-nameFromTemplate 'stgacctbicepdemo'

Pour effectuer un déploiement à l’aide de la CLI d’Azure, utilisez la commande az deployment group create en spécifiant le nom du groupe de ressources et le fichier modèle. Utilisez –parameter afin de spécifier le nom du compte de stockage pour le modèle.

  1. az deployment group create \
  2. --resource-group bicep-rg \
  3. --template-file storageAccount.bicep \
  4. --parameters name='stgacctbicepazcli'
az deployment group create \


--resource-group bicep-rg \


--template-file storageAccount.bicep \


--parameters name='stgacctbicepazcli'

Conversion des modèles Bicep et ARM

Pour convertir manuellement un modèle Bicep en modèle ARM, utilisez la commande bicep build en précisant le chemin d’accès au fichier modèle Bicep.

Voici un exemple de conversion du modèle Bicep storageAccount.bicep en modèle ARM.

  1. bicep build storageAccount.bicep
bicep build storageAccount.bicep

Vous pouvez déployer le modèle Bicep converti en modèle ARM au moyen de la commande Azure PowerShell New-AzResourceGroupDeployment ou de la commande CLI d’Azure az deployment.

Si vous possédez déjà un modèle ARM JSON, vous pouvez le convertir en modèle Bicep à l’aide de la commande bicep decompile comme suit :

  1. bicep decompile storageAccount.json
bicep decompile storageAccount.json

Le processus de décompilation un processus « au plus juste ». Microsoft ne garantit pas une correspondance de mappage directe entre ARM JSON et Bicep. Vous devrez vérifier le modèle Bicep et corriger les avertissements et les erreurs. Si vous rencontrez un problème de décompilation, vous pouvez signaler toute difficulté ou inexactitude sur la page Bicep GitHub Issues.

FAQ sur Azure Bicep

Qu’est-ce qu’Azure Bicep ?

Azure Bicep est un nouveau langage spécialisé, créé par Microsoft pour le déploiement de ressources Azure. Azure Bicep est une technologie de déploiement qui vient en complément des modèles Azure Resource Manager (ARM).

Qu’est-ce qu’ARM ?

Azure Resource Manager (ARM) est le service de déploiement et de gestion d’Azure chargé de la création, de la mise à jour et de la suppression des ressources. Les modèles ARM sont des fichiers JSON avec une ou plusieurs ressources Azure définies en tant que code pour des déploiements cohérents.

Étapes suivantes

Nous espérons vous avoir convaincu qu’Azure Bicep convient mieux que les modèles ARM pour écrire l’infrastructure as code d’Azure. Microsoft améliore rapidement les outils Bicep afin d’en faire le meilleur choix pour les déploiements Azure.

Si vous souhaitez en apprendre davantage sur Azure Bicep, consultez les modules Microsoft Learn pour vous lancer. Pour une comparaison rapide des modèles Bicep et ARM, consultez le site Bicep Playground. Il vous permet de programmer dans l’un ou l’autre langage de modèle et voir immédiatement le code correspondant. Vous pouvez également consulter des exemples de modèles pour apprendre à écrire des modèles Bicep.

 

What you should do now

Below are three ways we can help you begin your journey to reducing data risk at your company:

  1. Schedule a demo session with us, where we can show you around, answer your questions, and help you see if Varonis is right for you.
  2. Download our free report and learn the risks associated with SaaS data exposure.
  3. Share this blog post with someone you know who'd enjoy reading it. Share it with them via email, LinkedIn, Reddit, or Facebook.
Testez Varonis gratuitement.
Un résumé détaillé des risques liés à la sécurité de vos données.
Stratégie claire vers une remédiation automatisée.
Déploiement rapide.
Keep reading
guide-de-l’acheteur-de-dspm
Guide de l’acheteur de DSPM
Comprenez les différents types de solutions DSPM, évitez les pièges les plus courants et posez les bonnes questions pour vous assurer que vous achetez une solution de sécurité des données qui répond à vos besoins spécifiques.
derrière-la-refonte-de-la-marque-varonis
Derrière la refonte de la marque Varonis
Découvrez la stratégie derrière la refonte de Varonis qui impliquait une transition complète vers un archétype de héros et l'introduction de Protector 22814.
tendances-en-matière-de-cybersécurité-pour 2024 :-ce-que-vous-devez-savoir
Tendances en matière de cybersécurité pour 2024 : ce que vous devez savoir
Apprenez-en davantage sur la gestion de la posture en matière de sécurité des données, les risques liés à la sécurité de l’IA, les changements en termes de conformité et bien plus encore pour préparer votre stratégie en matière de cybersécurité pour 2024.
trois façons-dont-varonis-vous-aide-à-lutter-contre-les-menaces-internes
Trois façons dont Varonis vous aide à lutter contre les menaces internes
Les entreprises ont du mal à lutter contre les menaces internes. Pour lutter contre elles, Varonis s’appuie sur la « triade de la sécurité des données » (sensibilité, accès et activité).