Le Cloud a ses différences, ses particularités et ses spécificités. La différence la plus flagrante pour l’administrateur étant l’absence totale de matériel, de hardware. La baie de stockage est virtuelle, l’équilibreur de charge, les équipements réseau ou les grosses machines de calcul le sont aussi.
Azure Bicep, vraiment simple ?
C’est un changement majeur. Plutôt que des actions manuelles pour l’installation de nouveaux environnements, tout se fera « à la souris » au travers d’un portail Web pour les installations et les déploiements, … ou d’une console pour réaliser ces mêmes actions au travers du code. Pratique déclinée sous le terme IaC, Infrastructure en tant que Code.
Tout ce qui se fait depuis le portail, le code permet de le faire plus rapidement, mais surtout, de façon plus homogène. C’est à mon sens le plus grand de ses avantages. Le déploiement est orchestré, contrôlé, ce qui a été déployé une première fois le sera une seconde fois puis une troisième fois avec le même niveau de conformité.
Pour le Cloud Microsoft Azure, l’utilisation des commandes Powershell ou AZ CLI est une première étape, suffisante pour traiter le déploiement de quelques composants. Une commande et quelques paramètres sont suffisants pour déployer une nouvelle ressource.
Ici, un exemple éditeur pour créer une machine virtuelle.
New-AzVm `
-ResourceGroupName « myResourceGroup » `
-Name « myVM » `
-Location « East US » `
-VirtualNetworkName « myVnet » `
-SubnetName « mySubnet » `
-SecurityGroupName « myNetworkSecurityGroup » `
-PublicIpAddressName « myPublicIpAddress » `
-OpenPorts 80,3389
Pour des déploiements plus conséquents, on se tourne généralement vers des modèles plus évolués comme ARM (Azure ressource manager) ou Terraform qui offre l’avantage d’être utilisable pour de très nombreux fournisseurs en plus d’Azure. Ces langages sont déclaratifs et idempotents (ils ne redéploient pas ce qui l’est déjà). Ils sont très structurés, s’appuient sur des schémas et des règles d’utilisation très précises.
Au milieu de l’année 2020 est apparu un petit nouveau nommé Azure Bicep (dépendant de la Microsoft-managed open source communities, gratuit et Open Source), avec la promesse d’un code performant, mais épuré, qui offrirait un maximum de simplicité à l’utilisateur.
Car oui, même si les langages déclaratifs vont au plus simple, il reste souvent quelques freins à leur utilisation.
– Simple mais pas suffisamment pour se lancer, pour démarrer ses déploiements avec le code.
– Un utilisateur occasionnel doit passer un peu de temps pour se « remettre en action » après une période sans code.
Bicep veut supprimer ces contraintes en proposant un code encore plus simple.
Mais qu’est-ce qu’un code encore plus simple ? Quoi de vraiment différent qui pourrait vous convaincre de franchir le pas et d’investir un peu de temps dans son apprentissage. Ce n’est pas la première fois que l’on entend dire que ce sera plus simple, sans toujours être satisfait du résultat.
La première réponse se trouve du côté du convertisseur en ligne https://bicepdemo.z22.web.core.windows.net/, qui offre la possibilité de convertir son modèle ARM en modèle Bicep avec un taux de réussite assez convaincant. Il propose aussi quelques modèles existants et puisqu’en matière de code, tout commence par « Hello World », qu’en est-il de la différence entre Bicep et ARM ?
Téléchargez cette ressource
Sécuriser votre système d’impression
Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.
Dans le menu Sample Template, on choisit donc le modèle 000/01-hello-world.
A gauche, le code Bicep, à droite, la version ARM.
Hello World, Bicep vs ARM
C’est un exemple un peu extrême, mais qui doit retenir l’attention.
Les écarts ne sont pas toujours de cet ordre, mais en moyenne, le code Bicep est 20 à 40% plus compact et c’est une évidence, il parait beaucoup (beaucoup, beaucoup !) plus facile à lire.
Si code compact n’est pas forcément la garantie d’un code simple, il faut aller plus dans le détail pour comprendre ce qui rend plus confortable l’utilisation. Avec quelques exemples qui ne demandent aucune connaissance préalable pour apprécier les différences entre les deux types de code.
Dans l’exemple plus complet qui suit (201/SQL dans les templates de démonstration), déclaration d’une variable ou d’un paramètre, vue ici dans une double fenêtre de l’éditeur Visual Studio.
A gauche, la version Bicep, à droite, le code ARM.
Variables et paramètres
Les éléments « décoratifs » sont retirés, lecture et compréhension sont facilitées. La déclaration d’un paramètre est un bon exemple, avec cette méthode sur une seule ligne sous la forme Param + Nom + Type + Valeur :
param transparentDataEncryption string = ‘Enabled’
C’est une façon plus naturelle d’écrire, les caractères []{} sont remplacés par le signe égal et sont beaucoup moins utilisés dans les déclarations. Difficile de faire plus lisible.
Ce qui est simple à déclarer se retrouve simple à utiliser au cœur du code. On remarque 2 choses dans le code qui suit.
– Pour un même déploiement, Bicep contient 49 lignes, ARM 72.
– Bicep ne vous demande pas si transparentDataEncryption est un paramètre ou une variable, il se débrouille seul.
Les exemples sont nombreux et le but de cet article n’est pas de décortiquer les lignes de code mais plutôt d’exposer clairement ce qui fait les principales différences.
La liste des différences n’est pas exhaustive, il y a aurait encore beaucoup à dire sur la simplicité de la syntaxe.
Par la suite, on retrouve dans une utilisation avancées :
- Les modules, c’est-à-dire la possibilité d’appeler des morceaux de code hors du code principale.
- La concaténation de valeurs.
- La possibilité d’importer des scripts ARM déjà existants (commande decompile) …
Après quelques semaines d’utilisation et même si je pratique régulièrement plusieurs types de code, ce que je retiens de cette nouveauté :
– Pas de frustration dans l’utilisation de Bicep. Il manque encore quelques fonctionnalités disponibles sous d’autres langages, mais tout ou presque est là.
– C’est un code facile à partager, facile à transmettre sur des équipes hétérogènes. Les familiers du code peuvent échanger avec les débutants sans difficulté.
– La documentation éditeur est à jour, les pages d’aide et d’exemples sont disponibles avec un onglet ARM et un onglet Bicep.
– Les mises à jour de versions sont fréquentes, le meilleur est à venir !
Alors expert du code, codeur intermédiaire ou débutant, il faut ABSOLUMENT prendre un peu de temps pour réaliser un premier déploiement Azure Bicep. Et surtout, ne pas avoir peur de se lancer !
En synthèse, il faut retenir ces 3 points :
- Bicep est un langage simple et naturel qui favorise la lisibilité. Il est parfaitement adapté aux débutants et aux équipes désireuses de se lancer dans l’aventure du code.
- L’existant sous ARM peut être facilement être porté sous Bicep depuis le site Bicepdemo utilisé plus haut dans ce sujet ou depuis la commande decompile.
- Bicep est parfaitement documenté et est régulièrement mis à jour. Il est supporté par Microsoft en production.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Azul permet aux entreprises de simplifier leurs environnements Java
- AI Speech double toutes vos vidéos !
- Finance : l’IA générative plébiscitée pour les décisions stratégiques
- Cybersécurité : les comportements à risque des collaborateurs
- Prédictions 2025 : voici comment l’intelligence artificielle va redéfinir la sécurité de 3 façons