Lorsque l’année dernière, la première version alpha du projet Bicep a été publiée, j’étais un peu sceptique. Un autre langage pour l’infrastructure ? Nous avons déjà des modèles ARM, il y a déjà Terraform et il y a aussi quelques projets sympathiques qui nous permettent de coder l’infrastructure avec les langages courants (C#, JavaScript, …). Alors pourquoi un autre langage DSL (langage spécifique au domaine) pour coder l’infrastructure Azure ? Eh bien, parfois, la création d’un ARM peut être assez laborieuse, surtout lorsqu’il s’agit de grands modèles. Il faut du temps pour trouver le bon endroit et ensuite modifier le bon morceau de code JSON du modèle. Comme les modèles ARM sont des fichiers JSON générés par une machine, il y a beaucoup de « bruit » qui rend difficile leur compréhension et leur modification. C’est là que Bicep apporte une innovation.
Le langage Bicep a été conçu pour avoir une parité totale avec le modèle ARM JSON. Cela signifie que tout ce que vous pouvez faire en Bicep, vous pouvez le faire avec le modèle ARM et vice versa. Le code Bicep est transposé en JSON (si vous êtes familier avec le développement JavaScript, c’est un peu similaire à la transposition de TypeScript en JavaScript).
Pour commencer le développement de Bicep, il est recommandé d’installer l’extension Bicep pour Visual Studio Code.
Ensuite, lorsque vous ouvrez un fichier avec l’extension .bicep, le code VS fournit non seulement la coloration syntaxique, mais aussi la puissante auto-complétion. Dans une présentation, l’équipe de développement de Bicep a mentionné qu’au lieu d’investir le temps et les ressources dans le langage lui-même, ils ont investi dans le développement de l’outil. Et vraiment l’extension Bicep fonctionne comme un charme.
Le langage Bicep est assez simple et il est très facile de commencer le développement. La ressource exprimée en Bicep est beaucoup plus compacte et lisible que le modèle JSON.
Prenons un exemple simple de la ressource Azure Storage Account ARM exprimée côte à côte comme Bicep et comme modèle JSON.
Comme vous pouvez le constater, le fichier Bicep ne compte que 20 lignes, tandis que le modèle JSON ARM en compte 39. Il est très clair de voir quelle est la ressource (le stockage dans notre cas) et où les paramètres et les variables sont utilisés. La compacité et la lisibilité ne sont pas les seuls avantages de Bicep. Parmi les caractéristiques du langage, il y en a quelques-unes que j’aimerais mentionner. Il s’agit du Déploiement conditionnel et Itératif et des Modules.
Pensez à une situation où vous devez déployer une fonctionnalité de serveur mais uniquement dans le cas d’un déploiement dans l’environnement de production. Dans l’exemple ci-dessous, cela est réalisé par le déploiement conditionnel. À l’étape (1), nous avons défini le paramètre environmentName. (Le décorateur avec les valeurs autorisées n’est pas nécessaire mais il met la contrainte sur le paramètre qui rend le modèle plus sûr). Ensuite, à l’étape (2), nous avons défini une variable bool auditingEnabled qui doit être définie à true uniquement si nous déployons en production. Enfin, à l’étape (3), nous déployons les paramètres d’audit du serveur uniquement en cas de déploiement en production.
Prenons une autre situation. Imaginons que nous ayons déployé Azure API Management et quelques API. Nous avons ensuite créé un produit avec une politique que nous souhaitons affecter à toutes les API. Cela peut être réalisé simplement par un déploiement itératif. Tout d’abord, (1) définissez le tableau des API. Après le déploiement incrémentiel, (2) boucle sur les API du tableau et déploie le produit pour chacune d’entre elles.
Parfois, nous avons besoin de décomposer des déploiements complexes en composants plus petits et plus réutilisables. Le concept des modules vous permet de diviser les modèles en plus petits fichiers/composants indépendants de Bicep. Chaque composant peut être utilisé dans une autre solution Bicep et peut également être déployé indépendamment. Les modules remplacent le concept de modèles imbriqués et liés, mais d’une manière plus facile à gérer.
Nous pouvons déployer le fichier Bicep avec Azure CLI ou Azure PowerShell. Les deux fournissent des outils multiplateformes, mais j’ai une légère préférence pour Azure CLI. Azure CLI à partir de la version 2.20.0 ou ultérieure installe automatiquement Bicep CLI au cas où nous déployons le fichier Bicep. Pour Azure PowerShell, le module Bicep doit être installé séparément. Disons que nous avons un Bicep avec la définition de toutes les ressources pour le déploiement de l’Azure Function App. Pour déployer le Bicep en utilisant Azure CLI, ouvrez la console et exécutez les commandes suivantes :
az group create --name regdemo --location northeurope
az deployment group create --resource-group regdemo --template-file .\functionapp.bicep --parameters .\functionapp.parameters.json
La première commande crée un groupe de ressources appelé regdemo dans la région northeurope. La seconde déploie l’Azure Function App dans ce groupe de ressources en utilisant le fichier Bicep functionapp.bicep. Notez que pour spécifier les paramètres, il est possible d’utiliser le même fichier de paramètres JSON que celui utilisé pour les modèles JSON classiques.
Pour intégrer le modèle Bicep aux pipelines Azure CI/CD, nous devons utiliser la tâche Azure CLI. La tâche exécutera en mode InlineScript les mêmes commandes Azure CLI que celles utilisées pour le déploiement Azure CLI dans l’exemple précédent.
Comme je l’ai mentionné au début de l’article, il y a une parité entre Bicep et les modèles JSON. L’outil Azure CLI Bicep vous permet de construire Bicep et de décompiler les fichiers JSON.
Pour construire/compiler Bicep en JSON en utilisant la commande Azure CLI :
az bicep build -–file main.bicep
Il crée le fichier main.json dans le même répertoire que votre fichier Bicep. Il peut être parfois fastidieux de conserver les deux fichiers dans votre projet, principalement si vous êtes en phase de conversion de votre solution de déploiement vers Bicep.
Pour décompiler JSON en Bicep, utilisez la commande Azure CLI suivante :
az bicep decompile --file main.json
Il génère le fichier main.bicep. Le résultat n’est pas parfait et vous devez corriger certains noms générés pour améliorer la lisibilité mais il vous donne une idée parfaite de ce que devrait être l’implémentation de Bicep.
Vous pouvez également essayer de décompiler vos modèles Bicep directement en ligne dans Bicep playground. Le site contient également une grande liste d’exemples de modèles Bicep qui pourraient vous inspirer pendant que vous travaillez sur votre solution Bicep.
À mon avis, Bicep est une excellente façon de faire de la gestion des ressources Azure. Il ajoute naturellement de la clarté, de la lisibilité et de la modularité à votre solution de déploiement. C’est un plaisir de travailler avec l’extension VS Code et le déploiement avec Azure CLI embrasse vraiment l’esprit de DevOps – vous pouvez déployer votre solution de n’importe où avec des commandes simples.
Si vous souhaitez apprendre à connaître Bicep, je vous recommande de suivre le cours gratuit de Microsoft Learn intitulé « Déployer et gérer des ressources dans Azure en utilisant Bicep« .
