Connaissez-vous Azure Bicep ?

Azure Bicep est une abstraction construite sur Azure ARM Templates et Azure Resource Manager qui offre une syntaxe de code plus propre avec un meilleur support pour la modularité et la réutilisation du code. Azure Bicep s’éloigne de la syntaxe JSON utilisée par ARM Templates et est beaucoup plus facile à lire et à écrire Infrastructure as Code (IaC) dans Azure !

C’est le dernier outil de Microsoft pour déployer des ressources Azure dans un processus DevOps, et même son open source !

Tout ce qui peut être fait avec Azure ARM Templates peut être fait avec Azure Bicep car il fournit une « abstraction transparente » sur ARM (Azure Resource Manager). Grâce à cette abstraction, tous les types, apiVersions et properties valables dans les modèles ARM sont également valables avec Azure Bicep.

Azure Bicep est une langue transplantée. Cela signifie que le code Azure Bicep a été converti en code ARM Template. Ensuite, le code ARM Template qui en résulte est utilisé pour déployer les ressources d’Azure. Cette transposition permet à Azure Bicep d’utiliser sa propre syntaxe et son propre compilateur pour créer des fichiers Azure Bicep qui se compilent en Azure Resource Manager (ARM) JSON comme une sorte de langage intermédiaire (IL).

Voici les principaux avantages de l’utilisation d’Azure Bicep qui sont intégrés comme objectifs principaux dans le projet Azure Bicep et qui sont à la base de la raison pour laquelle Microsoft construit Azure Bicep :

Créer un meilleur langage pour écrire l’Infrastructure as Code (IaC) pour décrire, valider et déployer les ressources Azure.
Le langage Azure Bicep est une abstraction transparente qui ne nécessite aucune mise à jour ou intégration à la plate-forme sous-jacente afin de prendre en charge un nouveau type de ressource Azure et/ou une apiVersion.
Le code Azure Bicep doit être facilement compréhensible et simple à apprendre pour les personnes qui sont à la fois nouvelles et expérimentées avec d’autres langages de programmation.
La réutilisation du code doit être une caractéristique principale permettant aux utilisateurs de modulariser et de réutiliser le code sans avoir à faire de « copier/coller ».
L’outil Azure Bicep doit offrir un niveau élevé de découverte et de validation. L’outil devrait également être développé en parallèle avec le compilateur, plutôt que d’être ajouté après coup.
Azure Bicep devrait permettre aux utilisateurs d’avoir une grande confiance dans la « validité syntaxique » du code avant qu’il ne soit déployé.

Azure Bicep est un outil DevOps conçu pour la création d’IaC utilisé pour déployer des ressources Azure depuis n’importe quel environnement. Cela signifie qu’Azure Bicep est compatible avec Windows, Linux et MacOS.

Le composant principal d’Azure Bicep est le Bicep CLI. C’est l’outil nécessaire pour compiler le code Bicep dans ARM JSON ; de plus, il est open source et multiplateforme.

Le script Powershell pour installer sur Windows:

$installPath = "$env:USERPROFILE\.bicep"
$installDir = New-Item -ItemType Directory -Path $installPath -Force
$installDir.Attributes += 'Hidden'
(New-Object Net.WebClient).DownloadFile("https://github.com/Azure/bicep/releases/latest/download/bicep-win-x64.exe", "$installPath\bicep.exe")
$currentPath = (Get-Item -path "HKCU:\Environment" ).GetValue('Path', '', 'DoNotExpandEnvironmentNames')
if (-not $currentPath.Contains("%USERPROFILE%\.bicep")) { setx PATH ($currentPath + ";%USERPROFILE%\.bicep") }
if (-not $env:path.Contains($installPath)) { $env:path += ";$installPath" }
# Verify you can now access the 'bicep' command.
bicep --help
# Done!

Le script Powershell pour installer sur Linux:

# Fetch the latest Bicep CLI binary
curl -Lo bicep https://github.com/Azure/bicep/releases/latest/download/bicep-linux-x64
# Mark it as executable
chmod +x ./bicep
# Add bicep to your PATH (requires admin)
sudo mv ./bicep /usr/local/bin/bicep
# Verify you can now access the 'bicep' command
bicep --help
# Done!

Le code Bicep est écrit dans les fichiers avec l’extension .bicep. Ces fichiers Bicep contiendront l’infrastructure sous forme de code qui sera ensuite compilé (ou transposé) dans Azure Resource Manager (ARM) JSON. Ensuite, une fois compilé, l’ARM JSON résultant sera déployé dans Microsoft Azure.

Chacun des fichiers .biceps est compilé dans un seul fichier ARM JSON. Si vous avez un seul fichier Azure Bicep nommé main.bicep, vous pouvez utiliser la commande CLI Azure Bicep suivante pour le compiler en ARM JSON :

bicep build main.bicep

Cette commande compilera le fichier principal .bicep en ARM JSON et enregistrera le modèle ARM résultant dans un fichier du même nom utilisant une extension de fichier .json. Ainsi, la compilation du fichier main.bicep se traduira par un modèle ARM existant dans un nouveau fichier nommé main.json dans le répertoire de sauvegarde comme le fichier main.bicep original. Gardez à l'esprit que le fichier .bicep existera toujours car il s'agit du code Azure Bicep que vous continuerez à modifier au fur et à mesure que vous développerez la solution Infrastructure as Code.

Vous pouvez également utiliser l’Azure Bicep pour compiler plusieurs fichiers .bicep en ARM Template JSON avec une seule commande, par exemple :

bicep build main.bicep second.bicep

Lorsque vous compilez le code Azure Bicep, il inclut automatiquement le code JSON de base du modèle ARM. Lorsque vous compilez un fichier Azure Bicep vide, le modèle ARM qui en résulte n’inclura que ce schéma JSON de base. Par conséquent, un fichier .bicep vide est un fichier accepté pour la compilation.

Un fichier .bicep vide sera compilé dans le JSON suivant :

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {},
  "functions": [],
  "variables": {},
  "resources": [],
  "outputs": {}
}

Azure Bicep est un langage transposé, vous devez donc d’abord le compiler dans le modèle ARM JSON, puis le modèle résultant peut être déployé sur Microsoft Azure. Le modèle ARM qui résulte de la compilation d’Azure Bicep est déployé sur Microsoft Azure de la même manière que tout autre modèle ARM. Cela peut être fait en utilisant les outils de ligne de commande Azure CLI ou Azure PowerShell.

# Transpile / Compile Azure Bicep code
bicep build main.bicep

# Create an Azure Resource Group to deploy to
az group create -n Bicep-RG -l northeurope

# Deploy ARM Template to Resource Group
az deployment group create -f main.json -g Bicep-RG

Le code Azure Bicep est écrit dans une syntaxe plus simple, plus facile à lire et à écrire que la syntaxe JSON utilisée avec les modèles ARM. La syntaxe de code créée pour Azure Bicep partage certains éléments que vous connaissez peut-être déjà dans les codes JSON et YAML.

L’élément principal du code Azure Bicep est le bloc de ressource qui déclare une ressource d’infrastructure à déployer. Voici un exemple simple de code Azure Bicep qui déploie un compte de stockage Azure :

resource mystorage 'Microsoft.Storage/storageAccounts@2019-06-01' = {
  name: 'bicepstorage2063'   // Globally unique storage account name
  location: 'northcentralus' // Azure Region
  kind: 'Storage'
  sku: {
    name: 'Standard_LRS'
  }
}

La déclaration des ressources Azure avec le code Bicep se fait selon le format suivant :

resource <symbolic-name> '<type>@<api-version>` = {
  // Properties
  name: 'bicepstorage2063'
  location: 'northcentralus'
  sku: {
    name: "Standard_LRS'
  }
}

Ce site vous donnera beaucoup plus de détail. Les différents éléments (tels que vus par les placeholders dans l’exemple ci-dessus) de la déclaration de ressources Azure en code Bicep sont les suivants :

mot-clé resource – Utilisation pour déclarer le bloc de code qui définit les ressources à déployer
Symbolic name – Il s’agit d’un identifiant (ou nom) dans le fichier Biceps qui peut être utilisé pour référencer cette ressource dans d’autres emplacements du fichier Biceps. Gardez à l’esprit que ce n’est pas le nom de la ressource qui est déployée ; ce nom sert uniquement à référencer cette ressource dans le code Bicep.
Type – Il s’agit du nom de type de la ressource pour la ressource qui est déclarée. Il est composé du nom du fournisseur de la ressource Azure (tel que Microsoft.Storage) et du type de ressource (tel que storageAccounts). La valeur complète du type de ressource Azure pour un compte de stockage Azure est Microsoft.Storage/storageAccounts.
API Version– Après le type de ressource Azure, séparé par un caractère @, il faut spécifier une apiVersion de fournisseur de ressource Azure. Cette exigence provient de l’Azure Resource Manager (ARM) et sera similaire à l’apiVersion spécifiée dans les modèles ARM. Par exemple, la version API spécifiée pour un compte de stockage Azure pourrait être 2019-06-01.
Properties – Les propriétés de la ressource sont contenues dans le champ = { … } dans la déclaration de la ressource. Il s’agit des propriétés spécifiques requises pour le type de ressource Azure spécifique déclaré. Toutes ces propriétés seront les mêmes que celles requises par un modèle ARM lors de la déclaration d’un même type de ressource Azure.

Bref, il y a de quoi s’amuser 🙂

Voici le Github https://github.com/Azure/bicep

Cédric GEORGEOT [MVP]

Je travaille actuellement en tant qu’Enterprise Architect pour le groupe CAPGEMINI. Acteur et expert communautaire reconnu depuis de nombreuses années, j’anime ce site autour des technologies Microsoft, des thématiques du Cloud, des infrastructures, … Je suis également à l’origine de nombreuses publications dans la presse IT.

Partagez si ça vous plait !