Bienvenue dans un nouvel épisode des pépites de connaissances Microsoft ici sur M365FM. Je suis votre autre Mirko Peters. Vous déployez des ressources Azure en cliquant dans le portail. Ça fonctionne bien jusqu'au jour où ça ne fonctionne plus. Ensuite, vous devez recommencer, mais vous ne vous souvenez pas exactement de vos choix. Vous devez transmettre la main à un coéquipier, il ne peut pas suivre vos états. Gestion de version, il n'y a rien à valider. C'est le problème que nous allons résoudre aujourd'hui. A la fin de cet épisode, vous comprendrez ce qu'est l'infrastructure en tant que code, pourquoi Bicep existe et comment il rend les déploiements Azure plus simples et plus fiables. Nous commencerons par le problème, puis la solution, et enfin un exemple pratique que vous pourrez suivre. Prenez votre café et plongeons dans le vif du sujet. Le problème du portail. Le piège du cliquer pour déployer que semble rapide.

Vous connectez, remplissez un formulaire, cliquez sur créer, et c'est fini. Mais que se passe-t-il quand vous devez recommencer avec les mêmes paramètres, régions et conventions de nommage ? Vous devez vous souvenir de chaque élément choisi, et c'est là que tout s'effondre. Le déploiement manuel signifie résultat incohérent, erreur humaine et absence de pistes d'audit. Voici un exemple concret. Quelqu'un de votre équipe crée une ressource avec des paramètres légèrement différents. Maintenant vous avez deux environnements qui ne correspondent pas. L'un fonctionne, l'autre non, et bon courage pour comprendre pourquoi. Ensuite il y a le problème de la documentation. L'infrastructure dans un document Word, ou pire, une vidéo YouTube enregistrée il y a 6 mois, alors que le portail était complètement différent. Les fonctionnalités bougent, les menus changent, de nouvelles options. J'ai discuté avec un chef de produit de l'équipe du portail Azure, et il a dit qu'il sorte de nouvelles fonctionnalités deux fois par jour.

Deux fois par jour. Votre document Word est obsolète avant même que vous ayez fini de l'écrire. Voici le constat. Cliquez partout, c'est bien pour apprendre. C'est inadapté pour la production. Alors, quelle est l'alternative ? Vous écrivez un fichier qui décrit ce que vous voulez, puis vous dites à Azure de le construire. Qu'est-ce que l'infrastructure en tant que code ? L'infrastructure en tant que code signifie gérer votre configuration cloud avec du code plutôt qu'en cliquant sur un portail web. Voici l'idée centrale. Vous écrivez un fichier qui décrit votre infrastructure. Ce fichier vit dans votre dépôt. Vous pouvez le versionner, le réviser dans une pull request, et le relancer demain pour obtenir le même résultat. Il y a un terme clé ici. Déclaratif. Cela signifie que vous décrivez ce que vous voulez, et non comment le construire. Vous ne dites pas à Azure de créer d'abord un groupe de ressources, puis d'ajouter un compte de stockage, puis de configurer le réseau.

Au lieu de cela, vous dites, je veux un groupe de ressources avec un compte de stockage et un réseau configuré ainsi. Et Azure détermine l'ordre. Le résultat est ce qu'on appelle l'idempotence. Lancez-le une fois, lancez-le 100 fois, et vous obtiendrez le même résultat. C'est là toute la puissance. Imaginez cela comme un plan architectural par opposition à une construction. Un plan est reproductible, partageable et révisable. Donnez-le à quelqu'un d'autre, et il construira exactement la même chose. Plusieurs outils permettent cela. Les modèles ARM, Bicep, Terraform, PUM. Ils mettent tous en œuvre le même concept de manière différente. C'est une distinction importante. L'infrastructure en tant que code est le concept. Bicep n'est qu'un outil parmi d'autres pour l'implémenter. Mais voici le point essentiel. Azure dispose depuis des années d'un langage IAC appelé modèle ARM. Et il y a une raison pour laquelle Microsoft en a créé un nouveau.

Le problème des modèles ARM. Les modèles ARM sont le format IAC original d'Azure. Ce sont des fichiers JSON. Et ils ont beaucoup d'atouts. Une couverture complète de chaque ressource Azure. Et le même moteur de déploiement que celui utilisé en interne. Si vous pouvez le créer dans le portail, vous pouvez le définir dans un modèle ARM. Alors quel est le problème ? Le JSON est excellent pour les machines, mais terrible pour les humains. Laissez-moi vous montrer ce que je veux dire. Un compte de stockage dans un modèle ARM prend environ 20 lignes de code. Le même compte de stockage dans Bicep, environ 10 lignes. La version JSON est environ deux fois plus longue. Et ce n'est qu'une ressource simple. Imaginez un déploiement complet avec réseau, calcul, base de données et règles de sécurité. Le modèle ARM devient un véritable mur de texte. Les points de l'heure courant sont prévisibles. Virgule manquante, parenthèse mal appariée, imbrication verbeuse rendant difficile la distinction entre les ressources.

Vous passez plus de temps à vous battre avec la syntaxe JSON qu'à définir votre infrastructure. Et puis il y a les dépendances. Dans ARM, vous devez déclarer manuellement les « depends on ». Si la ressource A a besoin que la ressource B existe d'abord, vous devez l'écrire explicitement. En oubliez une et votre déploiement échoue. Bonne chance pour trouver celle que vous avez oubliée. Si vous avez déjà essayé d'écrire un fichier JSON de 200 lignes à la main, ce n'est pas amusant. Pas même un petit peu. La courbe d'apprentissage est abrupte. Les nouveaux membres de l'équipe ont du mal à comprendre les modèles ARM. La barrière à l'entrée est élevée. Mais que se passe-t-il en pratique ? Beaucoup d'équipes finissent avec une seule personne qui maîtrise les modèles ARM. Cette personne devient un point de défaillance unique. C'est la seule à pouvoir modifier le déploiement et la seule à pouvoir le déboguer en cas de problème.

Ce n'est pas viable. Microsoft a écouté les retours et a donc créé Bicep pour résoudre précisément ces problèmes. Qu'est-ce que Bicep ? Alors qu'est-ce que Bicep exactement ? C'est un langage conçu pour déployer des ressources Azure. A la base, c'est un transpiler. Vous écrivez en Bicep et cela compile vers du JSON ARM. Le moteur reste le même et la méthode d'écriture est bien plus bonne. Et le nom Bicep est en fait ARM éplé à l'envers, Bicep. Alors, une petite plaisanterie interne de la part de Microsoft. Mais une fois que vous le voyez en action, tout devient logique. Bicep s'appuie sur ARM au lieu de le remplacer. Vous obtenez la même puissance avec une syntaxe plus simple. Bicep ne remplace pas ARM, il se construit par-dessus. Tout ce que vous pouvez faire avec ARM, vous pouvez le faire avec Bicep. Chaque type de ressource, chaque version d'API, chaque option de configuration est disponible.

La seule différence réside dans la manière de l'écrire. La syntaxe est beaucoup plus claire. Pas de guillemets autour des noms de propriétés, pas de virgules entre les propriétés, pas d'accolade à suivre. C'est tout simplement plus simple. Comparer les deux versions côte à côte. La version JSON ARM d'un compte de stockage est pleine de bruit. Guillemets, virgules, crochets, imbrications. La version Bicep contient les mêmes informations, mais elle est lisible. Vous pouvez la regarder et comprendre immédiatement ce qu'elle fait, sans avoir à traverser des couches de syntaxe JSON. Une amélioration majeure est l'inférence automatique des dépendances. Dans ARM, vous devez déclarer manuellement les TK dépendants. Mais dans Bicep, si la ressource A référence la ressource B, le système détecte la dépendance automatiquement. Vous n'avez pas besoin de l'écrire. Cela fonctionne tout seul. Et rien que cela permet d'économiser des heures de débogage.

Les modules sont un autre élément majeur. Vous pouvez diviser votre infrastructure en morceaux plus petits et réutilisables et les partager entre vos projets. Une équipe crée un module réseau et une autre équipe l'utilise. Inutile de réinventer la roue à chaque fois. Les paramètres et les variables vous permettent de définir vos entrées une fois et de les réutiliser partout. Fini la recherche et le remplacement de valeurs codées en dur. Et l'interpolation de chaîne signifie que vous pouvez écrire le préfixe de stockage au lieu d'utiliser des fonctions de concaténation complexes. L'outillage est une autre raison pour laquelle Bicep est si agréable à utiliser. L'extension VS Code vous offre IntelliSense, la coloration syntaxique et la vérification des erreurs en temps réel. Honnêtement, c'est l'une des meilleures extensions de langage dans VS Code. Commencez à taper et il suggère la suite.

Faites une erreur et vous le signale immédiatement. Fini l'attente de l'échec d'un déploiement avant de réaliser qu'il manquait une virgule. Alors à quoi cela ressemble-t-il en pratique ? Regardons comment Bicep diffère d'ARM. Bicep face à ARM, qu'est-ce qui change vraiment ? Parlons de ce qui change réellement lorsque vous écrivez du Bicep au lieu du JSON ARM. La taille du fichier est une différence évidente. Les fichiers Bicep font environ la moitié de la taille des modèles ARM équivalents. Ce n'est pas une exagération. Vous supprimez toutes les guillemets, virgule, crochet et le code répétitif et il ne reste que la définition de l'infrastructure. Moitié moins de code, même résultat. La lisibilité s'en trouve naturellement l'heure. Moins de lignes, une structure plus propre et une compréhension plus facile au premier coup d'œil. Lorsque vous ouvrez un fichier Bicep, vous pouvez le parcourir et comprendre ce qui est déployé.

Avec le JSON ARM, vous devez passer par des couches d'imbrication avant de trouver la configuration réelle de la ressource. Les dépendances font gagner énormément de temps. En ARM, vous déclarez manuellement les dépendances. Si vous en oubliez un, votre déploiement échoue. En Bicep, si la ressource A fait référence à la ressource B, le système gère cela automatiquement. Il ajoute la dépendance lors de la compilation au JSON ARM. Vous n'y pensez pas, ça fonctionne tout simplement ? Cela permet à soi seul d'économiser des heures de débogage. Les modules sont d'une différence majeure. ARM possédait des modèles imbriqués, mais ils étaient pénibles à utiliser. Fichiers séparés, liens complexes, difficiles à versionner. Bicep propose des modules qui sont plus propres, versionnables et réutilisables. Vous définissez un module une fois, le publiez dans un registre et y faites référence n'importe où.

Même module, même configuration à chaque fois. Le processus de déploiement lui-même est identique. Bicep compile en JSON ARM puis Azure Resource Manager le déploie. Même moteur, même pipeline. Vous n'avez pas besoin de changer votre processus de déploiement, vous changez juste la façon d'écrire les modèles. Whatif est une fonctionnalité qu'ARM possède techniquement, mais Bicep la rend beaucoup plus accessible. Vous pouvez prévisualiser les changements avant le déploiement et voir exactement ce qui sera créé, modifié ou supprimé. Pas de surprise, pas de suppression accidentelle. Vous exécutez Whatif dégueu, vérifiez le résultat. Et si tout semble correct, vous déployez. La courbe d'apprentissage est un domaine où Bicep se distingue. Le JSON ARM suppose que vous savez ce que vous faites. Il est conçu pour les machines, pas pour les humains. Bicep est conçu pour les débutants. Syntaxe intuitive, outil qui vous guide.

Vous pouvez l'apprendre en après-midi et être productif d'ici la fin de la semaine. Microsoft a fait de Bicep l'expérience de création recommandée. Toutes les nouvelles fonctionnalités et améliorations ciblent Bicep en priori. Les modèles ARM fonctionnent toujours et ne vont pas disparaître, mais vous ne devriez probablement plus en écrire nous. Si vous commencez un nouveau projet aujourd'hui, Bicep est la solution à privilégier. Trois lignes de Bicep pour déployer un groupe de ressources. Juste trois lignes. Le JSON ARM équivalent fait environ 15 lignes. Même résultat, même déploiement. Mais l'un est lisible et l'autre est un fouillis. Maintenant vous vous demandez peut-être qu'en est-il de Terraform ? Dois-je apprendre Bicep ou Terraform ? Bicep contre Terraform, lequel devriez-vous utiliser ? Bienvenue à nouveau sur Microsoft Knowledge Nugget. Je suis Mirko Peters et aujourd'hui nous abordons une question récurrente.

Bicep ou Terraform ? Analysons cela. Terraform fonctionne sur plusieurs clouds. Vous pouvez l'utiliser pour Azure, AWS, GCP ou même les trois à la fois. Bicep en revanche est conçu pour Azure et rien d'autre. La différence fondamentale influence tout le reste. Si vous travaillez sur plusieurs clouds, Terraform est la solution idéale. Vous apprenez un langage, un outil, un flux de travail et cela fonctionne partout. Mais si vous êtes principalement sur Azure, Bicep offre de vrais avantages. Voici le premier. Aucun fichier d'état à gérer. Terraform conserve un fichier d'état qui suit ses déploiements. Et ce fichier est critique. S'il est corrompu ou désynchronisé, vous avez un sérieux problème. Vous devez le stocker de manière sécurisée, le sauvegarder et gérer ses accès. Bicep communique directement avec Azure Resource Manager, vérifie l'existant et calcule les différences. Pas de fichier d'état signifie pas de problème de synchro ni de risque de corruption.

Second avantage, le support dès le premier jour. Quand Microsoft publie une nouvelle fonctionnalité Azure, Bicep la supporte immédiatement, le jour même. Terraform doit attendre une mise à jour du fournisseur, ce qui est parfois rapide, parfois prend des semaines. Si vous devez utiliser une nouvelle fonctionnalité tout de suite, Bicep est la seule option. Troisièmement, il est conçu par l'équipe Azure. L'outillage, IntelliSense, les messages d'erreur, tout est conçu selon le fonctionnement réel d'Azure. Lorsque vous écrivez en Bicep, vous utilisez un langage qui comprend nativement les ressources Azure. Il connaît les propriétés requises, les valeurs valides et les dépendances existantes. Cette intégration poussée est difficile à reproduire avec un outil tiers. Vous pouvez aussi utiliser les deux. De nombreuses organisations utilisent Bicep pour la plateforme et les landing zones, et Terraform pour le multicloud.

Ils ne sont pas mutuellement exclusifs. Vous pouvez choisir l'outil adapté à chaque tâche ? La réponse honnête est celle-ci. Pour apprendre spécifiquement Azure, Bicep comporte moins d'éléments mobiles. C'est un chemin plus simple quand on débute. Pas besoin d'apprendre les fichiers d'état, les fournisseurs ou la configuration back-end. Vous installez Azure CLI, ouvrez VS Code et commencez à écrire. Assez de théorie. Parlons de ce dont vous avez réellement besoin pour commencer. Démarrage. Ce dont vous avez vraiment besoin. Il vous faut deux choses pour commencer. Azure CLI et l'extension Bicep pour VS Code. C'est tout. Aucune CLI Bicep séparée installée, aucun outil supplémentaire à configurer. Azure CLI inclut Bicep nativement. L'installation d'Azure CLI est assez simple. Allez sur Microsoft Docs. Trouvez la page d'installation pour votre système d'exploitation. Si vous êtes sur Mac, il y a une seule commande.

Brow install Azure CLI. Sur Windows, il y a un installateur MSI. Téléchargez-le, exécutez-le, c'est fini. Cela fonctionne aussi sur Linux via votre gestionnaire de paquets. Une fois installé, exécutez AZ version pour confirmer que tout fonctionne. Vous devriez voir la version d'Azure CLI et la version de Bicep listées. Maintenant, ouvrez VS Code, allez dans le panneau des extensions à gauche et recherchez Bicep. Installez celle de Microsoft, pas une tierce partie, l'officiel. Vous avez vraiment besoin de cette extension. Elle offre un télisans pour suggérer des propriétés de ressources, surligne la syntaxe pour repérer les erreurs et vérifier les fautes en temps réel. Vous verrez des lignes ondulées rouges sous les erreurs avant même de déployer. Honnêtement, c'est l'une des meilleures extensions VS Code et une raison majeure pour laquelle Bicep est si agréable. Créez maintenant un nouveau fichier et nommez-le main.bicep.

Cette extension Bicep indique à VS Code de s'activer. Sans elle, vous écrivez simplement du texte bruit. Avec elle, vous bénéficiez de toute l'expérience des outils. Voici un exemple rapide. Un déploiement de groupe de ressources en trois lignes de code. D'abord, vous définissez la portée sur l'abonnement, puis vous définissez la ressource, un groupe de ressources avec un nom et un emplacement. C'est tout, trois lignes. Comparez cela à l'équivalent ARM JSON, qui compte environ 15 lignes de crochet et de guillemets. Pour le déployer, utilisez l'Azure CLI. Comme vous déployez au niveau de l'abonnement, la commande est az-deployment-sub-create. Vous indiquez un emplacement pour les métadonnées de déploiement et pointez vers votre fichier Bicep. C'est la méthode en ligne de commande, mais il existe aussi une expérience guidée. Dans VS Code, faites un clic droit sur le fichier Bicep et sélectionnez Deploy Bicep File.

Cela vous guide tout au long du processus. Il demande à un nom de déploiement de sélectionner votre abonnement, de créer ou sélectionner un groupe de ressources, et s'il y a un fichier de paramètres, vous dites non et il déploie. Le résultat apparaît dans votre portail Azure. C'est comme cliquer dans le portail, mais vous avez maintenant un fichier réutilisable. Vous pouvez le valider dans votre dépôt, le partager avec votre équipe et le réexécuter demain. Et voici la partie magique. Relancez le même déploiement et observez ce qu'il se passe. La puissance de l'identpotence. Voici ce qu'il faut savoir sur l'exécution des déploies. Vous voulez pouvoir les lancer encore et encore sans rien casser ? C'est exactement ce que vous apporte l'identpotence. La première fois que vous exécutez le fichier Bicep, il crée le groupe de ressources, mais la deuxième fois, rien ne se passe. Pas d'erreur, pas de doublon, rien du tout.

Bicep vérifie ce qui existe déjà dans Azure, le compare à ce que vous avez demandé et conclut qu'il n'y a rien à modifier. Il n'a pas tenté de créer un nouveau groupe de ressources et n'a pas à renvoyer d'erreurs indiquant qu'il existait déjà. Il a simplement confirmé que l'état actuel correspond à l'état souhaité. Imaginez cela comme faire un JIT statut sur un dépôt propre. Il n'y a rien à faire. Tout est déjà exactement comme il se doit. C'est là toute la puissance de l'infrastructure en tant que code. Vous pouvez lancer votre déploiement indéfiniment et obtenir le même résultat à chaque fois. Pas de surprise, pas de dérive. Vous savez exactement ce qui est déployé car le fichier le précise. Le fichier devient votre source unique de vérité. Vous n'avez plus à vous demander si vous avez oublié un paramètre, à gérer le problème du « ça marche sur la machine » ou à fouiller le portail Azure pour vérifier si quelqu'un a modifié quelque chose.

Le fichier vous indique ce qui est présent. Si vous voulez changer quelque chose, vous modifiez le fichier et redéployez. Si vous voulez vérifier, vous relancez le déploiement et il confirme que tout correspond. C'est ainsi que vous renforcez la confiance dans votre infrastructure. Le fichier est la source de vérité. Pas votre mémoire, pas un document Word, pas une vidéo YouTube d'il y a 6 mois, mais le fichier, mais le fichier. Alors où Bicep s'intègre-t-il dans la vue d'ensemble d'Azure ? La vue d'ensemble, là où s'intègre Bicep. Bicep réside au sein de l'écosystème Azure Resource Manager. Ce n'est pas un outil séparé. Beaucoup de gens le pensent, mais c'est en fait juste une meilleure façon d'écrire des modèles ARM. Sous le capot, c'est toujours de l'ARM, le même moteur de déploiement, la même API, tout est identique. La seule différence réside dans la manière dont vous l'écrivez. Et comme Bicep compile vers de l'ARM, tout ce qui fonctionne avec ARM fonctionne avec Bicep.

Azure Policy impose la conformité sur vos déploiements. Herba a ses contrôles qui peut déployer, quoi. Cost Management suit les dépenses liées à vos ressources. Azure DevOps et GitHub Actions déploient vos fichiers Bicep via des pipelines. Tout cela fonctionne parfaitement, car Bicep génère du JSON ARM standard. Vous ne perdez rien en changeant de méthode ? Vous faites vous gagner en clarté. Microsoft a bâti tout un écosystème autour de Bicep. Azure Verified Modules, ou AVM, est une bibliothèque organisée de modules Bicep et Terraform qui suivent les meilleures pratiques. Vous n'avez pas besoin de tout écrire à partir de zéro. Vous pouvez utiliser des modules préconçus pour des modèles courants, comme les réseaux virtuels, les comptes de stockage et les services d'application.

Le Cloud Adoption Framework inclut des implémentations de références Bicep pour des architectures d'entreprises standardisées. Si vous construisez une zone d'atterrissage, il existe un modèle Bicep pour cela. Les piles de déploiement offrent une gestion du cycle de vie pour des groupes de ressources. Vous pouvez déployer une pile, et si vous supprimez une ressource de votre fichier Bicep, la pile peut la nettoyer pour vous. Vous la protégez contre une suppression accidentelle ? C'est vous qui décidez. L'écosystème ne cesse de croître avec davantage de modules, de meilleurs outils et une intégration plus poussée avec l'IA et GitHub Copilot. Vous pouvez décrire ce que vous voulez en langage clair, et Copilot génère le code Bicep pour vous. Microsoft continue d'investir dans Bicep comme expérience principale de création pour Azure. Ainsi, les nouvelles fonctionnalités ciblent Bicep en préau.

Les modèles ARM fonctionnent toujours, mais l'innovation se produit dans Bicep. Voici donc ce qu'il faut retenir. Si vous travaillez dans Azure, Bicep est l'étape naturelle après les clics dans le portail. Vous n'avez pas besoin d'apprendre Terraform ou de maîtriser le JSON ARM. Vous installez deux choses, écrivez quelques lignes de code, et vous déployez une infrastructure répétable, versionnée et fiable. Laissez-moi vous donner quelque chose de concret que vous pouvez faire aujourd'hui. Maintenant, vous savez ce qu'est l'infrastructure en tant que code, pourquoi Bicep existe et comment il simplifie les déploiements Azure. Voici le point principal. Bicep n'est pas un système de déploiement différent. C'est une meilleure façon d'écrire les mêmes modèles ARM que vous écrivez de toute façon en utilisant le même moteur et Azure Resource Manager en arrière-plan, mais dans un langage que les humains peuvent réellement lire et écrire.

Voici un défi pour vous. Créer un fichier main.bicep, déployer un groupe de ressources et exécuter le déploiement deux fois. Regardez-le fonctionner les deux fois. La première fois, il crée la ressource, et la deuxième fois, il confirme que rien n'a changé. C'est le déclic, le moment où vous réalisez que vous ne reviendrez jamais au clic dans le portail. C'est la fondation. A partir de là, vous pouvez ajouter des comptes de stockage, des réseaux virtuels et des services d'application en utilisant le même modèle. Écrivez un fichier, déployez-le, exécutez-le à nouveau. Ce fichier devient votre source de vérité, et tout le reste en découle. Si vous avez trouvé cela utile, partagez-le avec quelqu'un qui clique encore dans le portail. On vous remerciera. Abonnez-vous sur votre plateforme de podcast préférée, et dans le prochain épisode, nous approfondirons Bicep en déployant de vraies ressources avec de vraies propriétés.

Sous-titrage Société Radio-Canada