Les équipes DevOps sont souvent en recherche d’optimisation pour améliorer les délais de mise en production, réduire les coûts informatiques en ayant une approche FinOps et générer plus de valeur en répondant de manière pertinente aux besoins métiers. Cela passe par un déploiement rapide du code avec un processus fiable et reproductible et c’est encore plus vrai pour la mise à l’échelle des applications. En ce qui concerne le cloud et l’infrastructure, ce processus est de plus en plus abouti avec l’infrastructure en tant que code (IaC), à condition d’avoir les bons outils comme Bicep ou Terraform.

L’Infrastructure as Code (IaC) est la gestion de l’ensemble de l’infrastructure (réseaux, machines virtuelles ou physiques, ressources réseaux…) via des scripts qui utilisent le même contrôle de version que celui utilisé par l’équipe Dev pour le code source. L’objectif de l’IaC est d’optimiser le déploiement de ressources informatiques quelle que soit, dans la mesure du possible, la nature de cette ressource.

IaC est donc le fait d’appliquer les bonnes pratiques DevOps à l’infrastructure de sorte qu’elle soit automatisée, cohérente et reproductible.

En appliquant les mêmes tests et le même contrôle des versions au code spécifique à l’IaC, celui-ci peut passer par le même pipeline CI/CD que l’application lors de son développement.

L’infrastructure cible peut être considérée soit comme immuable en changeant l’ancien serveur par un nouveau soit mutable en appliquant des modifications sur le serveur sans le remplacer.

Pour automatiser le déploiement de services et d’une infrastructure, en particulier dans le cloud Azure, il y a 2 approches possibles :

• Impérative ou procédural

Cela consiste à décrire de manière explicite des commandes exécutées de manière séquentielle afin d’obtenir un résultat escompté.

Par exemple, l’exécution d’un script powershell az illustre cette approche. Cela implique un risque de complexité et de devoir traiter la gestion des erreurs à chaque étape.

• Déclarative

D’autres outils permettent de spécifier un état de configuration désiré (DSC : Desired state configuration) afin de faciliter la gestion des infrastructures IT particulièrement dans le cloud.

Il existe de nombreux outils IaC sur le marché. Certains utilisent des agents qui s’exécutent en arrière-plan d’un serveur et qui gèrent la mise à jour de la configuration tandis que d’autres outils ne nécessitent pas l’installation d’un agent.

De plus certains outils ont une approche généraliste (multi-cloud, hybride) tels que Terraform tandis que d’autres sont spécifiques à une plateforme comme Bicep pour Azure.

Nous allons plus particulièrement nous intéresser, dans cet article, à ces deux outils open source.

Bicep

Bicep est un langage de spécialité (DSL) spécifique au domaine conçu pour les modèles de gestionnaire de ressources Azure (ARM).

Il est donc spécifique à Azure et non exploitable sur d’autres services cloud. Il permet aux développeurs de définir les ressources Azure de manière plus concise et intuitive en utilisant une syntaxe similaire à celle des programmes. Bicep a également une prise en charge intégrée pour les modèles ARM courants et les fonctions, ce qui facilite la création et la maintenance des modèles ARM.

Avantages de Bicep

Le langage Bicep est assez simple, concis et intuitif. La ressource exprimée en Bicep est beaucoup plus compacte et lisible que le modèle JSON. Il dispose également d’un support intégré pour les modèles et les fonctions courantes d’ARM. De fait, il reprend les caractéristiques présentes dans les templates Azure Resource Manager (ARM) à savoir les paramètres, les variables, les ressources, les sorties et les version d’API. Le CLI Bicep génère d’ailleurs lors de son exécution un template ARM standard.  C’est donc un méta langage visant à simplifier la conception et l’utilisation des templates ARM. Il en facilite la construction et la maintenance.

La compacité et la lisibilité ne sont pas les seuls avantages de Bicep car parmi les caractéristiques intéressantes du langage, il y a notamment le déploiement conditionnel et Itératif et des Modules.

Déploiement conditionnel

Vous devez déployer une fonctionnalité de serveur mais uniquement dans le cas d’un déploiement dans l’environnement de production.

Déploiement itératif

Vous avez créé un produit avec une politique et vous avez déployé Azure API Management et quelques API. Le déploiement itératif vous permettra d’affecter la politique à toutes les API.

Déploiement des modules

Le concept des modules permet de diviser les modèles en plus petits fichiers/composants indépendants de Bicep. Les modules remplacent le concept de modèles imbriqués et liés, mais d’une manière plus facile à gérer.

Terraform

Terraform, quant à lui, permet aux développeurs de définir, de gérer les ressources en parallèle et de déployer l’infrastructure sur plusieurs plateformes on premise ou cloud, y compris Azure, AWS et Google Cloud et cela au travers de l’utilisation de providers, lesquels encapsulent les API des différents CSP.  Il a une syntaxe déclarative, ce qui signifie que les développeurs spécifient l’état final souhaité de leur infrastructure et Terraform s’occupe des détails sous-jacents.

Avantages de Terraform

Terraform simplifie donc le déploiement multicloud et peut exécuter des actions simultanément sur tous les fournisseurs de cloud. Résultat : les ingénieurs utilisent la même syntaxe sans être obligés de se familiariser avec de multiples technologies.

A chacun sa boîte à outils

Il est à noter que pour faciliter le développement du code IaC à savoir le Langage Bicep et le HarshiCorp Language (HCL) pour Terraform, des extensions sont disponibles au sein de VS Code. De plus, pour chacun des outils une interface en ligne de commande (CLI) est disponible.

Comme le précise Luc, Architecte Cloud

Par exemple Bicep est bien intégré avec Azure CLI et permet aux développeurs d’utiliser les commandes Powershell Az ou az bicep, ainsi az deployment permet le déploiement des ressources sur Azure ou az bicep la création ou la publication des fichiers Bicep. Le CLI Terraform permet également de valider et de formatter votre code IaC ainsi que de créer et d’exécuter un plan.

Lors du déploiement, l’authentification s’opère dès l’initialisation dans le cas de Bicep et pour chaque appel d’API pour Terraform. Les 2 outils offrent également une intégration au sein des outils DevOps tels que GitHub ou Azure DevOps : pour ce dernier, Bicep est nativement présent lors de la création d’un pipeline, pour Terraform il faut installer l’Azure Pipelines Terraform Task extension for Visual Studio.

Pour en savoir plus

Les principales différences entre Bicep et Terraform

Pour vous aider à choisir l’outil le plus adapté à votre problématique, partant du principe que votre cible d’infrastructure est Azure, Luc, Architecte Cloud vous donne les principales différences entre Bicep et Terraform.

Gestion de l’état

Bicep s’appuie sur le service d’infrastructure Azure et ne conserve pas un état en lien avec chaque déploiement incrémental dans le cloud. L’un des avantages c’est que cela permet d’opérer un prétraitement et ainsi de vérifier la disponibilité des ressources, la stratégie et autres règles de conformité mises en place au sein de la zone d’atterrissage Azure. C’est indéniablement un avantage au niveau qualité et optimisation des déploiements par rapport à Terraform car ce dernier stocke un état de l’infrastructure déployée ainsi que la configuration permettant de conserver les métadonnées et le mappage des ressources dans un fichier local ou distant dénommé terraform.tfstate. Le client Terraform utilise cet état pour déduire les modifications à mettre en œuvre avant de réaliser le traitement et donc contrairement à Bicep, il n’y a pas d’appel à Azure dans le cas d’un prétraitement. C’est pourquoi Bicep se montrera dans le cadre du cloud Azure plus pertinent lorsque des modifications hors IaC sont opérées et doivent être répercutées dans le code IaC. Bicep peut intégrer ces évolutions au travers de l’intégration d’un modèle ARM et de plus les modifications ne sont pas bloquantes lors des phases de déploiement. Pour Terraform ce même processus implique de mettre à jour la liste de contrôle hCL ainsi que l’état. Ces contraintes impliquent de limiter ces opérations avec Terraform et de préférer Bicep lorsque ce cas de figure est souvent répété.

Intégration Azure

Bicep présente l’avantage d’avoir la capacité de pouvoir interagir avec l’ARM et ainsi d’exploiter l’ensemble des fonctionnalités présentes sur le portail au travers des modèles (templates). Ces derniers sont exportables au format Json puis peuvent être décompilés avec Bicep. Vous pouvez alors opérer vos modifications du code des ressources et des propriétés avant de procéder à un nouveau déploiement manuellement ou en automatique. Cette interopérabilité forte est intégrée dans l’extension de VS Code ou en utilisant le CLI. Ainsi Bicep permet de s’appuyer sur les services natifs d’azure pour adopter les meilleures pratiques de déploiement illustrées au travers du Cloud Adoption Framework (CAF).

Pour Terraform, sont disponibles plusieurs outils pour gérer l’infrastructure Azure tels que TerraCognita, Azure Terrafy ou Terraformer.

Ainsi par exemple avec Azure Terrafy, pour générer les fichiers provider.tf, main.tf et terraform.tfstate, une simple commande aztfy resource <Identifiant Ressource Azure> permet la prise en charge d’une part d’infrastructure azure existante.

Enfin avec Terraform, c’est au travers l’utilisation du module Azure landing zones Terraform (disponible sur le registre Terraform d’HashiCorp) que les développeurs configurent la politique de l’entreprise concernant les règles de gestion pour les opérations et déploiements sur Azure.

Conclusion

Quel est donc finalement le bon choix à opérer ?

Vous l’aurez compris si vous avez une stratégie multicloud, on premise ou hybride, Terraform est la solution.

Cependant, si vous débutez votre démarche IaC et que votre cible de déploiement est uniquement Azure pour les siècles à venir alors prenez le temps d’appréhender Bicep, vous serez plus rapidement productif.

De même, si aujourd’hui, vous manipulez des modèles ARM en Json pour réaliser vos déploiements alors ce même conseil peut s’appliquer et vous pourrez valoriser et simplifier votre processus IaC.

Et que la force de l’IaC soit avec vous 😊