Bicep : l’IaC Azure moderne

Bicep est un langage propre à un domaine (DSL) développé par Microsoft. Il constitue une alternative concise et fortement typée aux modèles JSON ARM. Bicep est compilé en JSON ARM standard : il utilise donc le même moteur de déploiement ARM et prend en charge tous les types de ressources Azure dès leur disponibilité. Bicep supprime une grande partie du code répétitif nécessaire avec le JSON brut et offre une meilleure sécurité de typage ainsi qu'une meilleure prise en charge d'IntelliSense.

Le même compte de stockage qui nécessite environ 25 lignes de JSON dans un modèle ARM n'en nécessite qu'environ 8 en Bicep. Bicep élimine '$schema', contentVersion, le conteneur du tableau resources et la syntaxe d'expression verbeuse. Les noms et les types des propriétés restent identiques, car Bicep est une couche d'abstraction directe au-dessus du JSON ARM : il n'y a absolument aucune différence à l'exécution.

Les paramètres Bicep utilisent la syntaxe concise param name type = defaultValue. Vous pouvez appliquer des décorateurs (préfixés par @) directement au-dessus d'un paramètre afin d'ajouter des contraintes telles que @minLength(), @maxLength(), @allowed() et @description(). Le décorateur @secure() marque un paramètre comme sensible, ce qui équivaut à secureString dans le JSON ARM.

Les variables Bicep sont déclarées avec le mot-clé var et peuvent contenir n'importe quelle expression, notamment l'interpolation de chaînes à l'aide de la syntaxe '${value}'. L'interpolation de chaînes est l'une des améliorations les plus lisibles par rapport au JSON ARM : plus besoin d'appels à la fonction concat(). Bicep prend également en charge les expressions conditionnelles utilisant l'opérateur ternaire condition ? trueValue : falseValue.

Dans Bicep, chaque ressource reçoit un nom symbolique, c'est-à-dire un identifiant utilisé pour la référencer dans le modèle. Le nom symbolique n'est pas identique au nom Azure de la ressource. Utilisez les noms symboliques pour accéder aux propriétés des ressources et établir des dépendances implicites en référençant une ressource à l'intérieur d'une autre, ce qui évite d'avoir à utiliser un tableau dependsOn explicite.

Les sorties Bicep se déclarent avec le mot-clé output, suivi du nom, du type et de la valeur de la sortie. Vous pouvez référencer les propriétés d’une ressource déployée à l’aide de son nom symbolique et de la notation par points, ce qui est bien plus lisible que la fonction reference() d’ARM. Les sorties sont essentielles pour transmettre des valeurs entre les appels de modules Bicep.

Les modules Bicep sont l’équivalent des modèles liés dans ARM JSON et vous permettent de diviser votre infrastructure en composants réutilisables. Un module est simplement un autre fichier .bicep. Vous le référencez à l’aide du mot-clé module, lui transmettez des paramètres et utilisez ses sorties. Les modules peuvent également être publiés dans un Azure Container Registry et utilisés depuis celui-ci afin d’être réutilisés par toute l’équipe.

Si vous disposez déjà de modèles ARM JSON existants, le CLI Bicep peut les décompiler en Bicep à l’aide de bicep decompile. Le résultat peut nécessiter un nettoyage manuel, mais il constitue un excellent point de départ. Microsoft propose également un environnement de test en ligne à l’adresse aka.ms/bicepdemo, où vous pouvez coller du code ARM JSON et voir l’équivalent Bicep en temps réel.

Azure CLI prend directement en charge les fichiers Bicep : vous n’avez pas besoin de les compiler manuellement en ARM JSON avant le déploiement. Transmettez le chemin du fichier .bicep à az deployment group create avec l’option --template-file, et le CLI le compile de manière transparente. Les mêmes sous-commandes validate et what-if fonctionnent avec les fichiers Bicep exactement comme avec ARM JSON.

Bicep prend en charge les boucles de ressources avec la syntaxe for ... in afin de créer plusieurs instances d’une ressource à partir d’un paramètre tableau, ce qui évite les duplications dues au copier-coller. Le mot-clé if permet le déploiement conditionnel de ressources : une ressource n’est incluse que lorsqu’une condition donnée est vraie. Ces deux fonctionnalités sont compilées respectivement en constructions ARM copy et condition.

L’extension Bicep pour Visual Studio Code fournit IntelliSense avancé, la vérification des types et la mise en évidence des erreurs directement dans le code pendant la saisie. Le CLI Bicep inclut un analyseur de code qui recherche les écarts par rapport aux bonnes pratiques, tels que les paramètres inutilisés, les descriptions manquantes et les versions d’API incorrectes. Exécutez az bicep lint --file main.bicep dans votre pipeline d’intégration continue afin de détecter les problèmes avant le déploiement.

Vérifiez votre compréhension des concepts Microsoft Azure Fundamentals (AZ-900) présentés dans cette leçon.

Dans cette leçon, vous avez appris que Bicep est une abstraction concise et fortement typée d’ARM JSON qui se compile en modèles ARM standard, que les modules et les boucles permettent de créer du code d’infrastructure réutilisable et DRY, et que l’Azure CLI déploie directement les fichiers Bicep en prenant en charge le même processus validate/what-if/deploy. Nous allons maintenant découvrir Terraform sur Azure.