Le code

Introduction

Le code, ou plutôt les codes sont utilisés depuis toujours en informatique pour la gestion des systèmes. On parle principalement d’automatisation des tâches. Faire et refaire de manière automatique, dérouler par le code un ensemble d’actions. Ce qui peut être fait manuellement est fait automatiquement. Le cloud n’échappe évidemment pas à cette pratique.

Ce qui est différent, c’est plutôt ce que couvre l’usage du code. On bascule peu à peu d’une administration par le code à un déploiement par le code que l’on retrouve sous le terme IaC (Infrastructure as Code ou infrastructure en tant que code). Certes, déployer par le code sur son centre de données local est possible. La mise en place d’une telle pratique demande beaucoup d’expertise et un temps de préparation conséquent.

Le cloud Azure est déjà prêt pour cet usage. Dans ce chapitre, cinq solutions différentes vont être abordées. Il en existe d’autres, mais comprendre comment fonctionnent celles qui sont présentées ici revient également à comprendre le fonctionnement des méthodes dérivées.

PowerShell, Az CLI, ARM, Terraform et Bicep sont expliqués et mis en pratique par quelques exercices. Le but n’est pas de savoir tout...

PowerShell

PowerShell est un langage qui est d’abord né avec Windows et qui est depuis porté sur de nombreux systèmes, de Windows à Linux (dans de nombreuses versions) en passant par Mac. Cette version multisystème d’exploitation est appelée PowerShell Core, en version 7 actuellement (plus exactement 7.5 à la date de l’écriture de ce livre). Ce langage est parfaitement adapté au cloud et a également l’avantage d’être directement accessible depuis le portail sans installation préalable. C’est un langage simple mais riche en commandes et paramètres. Il est construit sous la forme d’un couple verbe + nom.

Le verbe décide d’une action (Get, Set, Test…) et est complété par un nom (VM, Content…) qui ajoute une donnée de contexte (une VM, un compte de stockage, etc.). Par exemple, Get-VM demande des informations pour une machine virtuelle Hyper-V (le produit de virtualisation Microsoft).

Petite particularité liée à Azure : les noms sont préfixés par Az (pour Azure) afin d’éviter la confusion. Ainsi, la demande d’information pour une machine virtuelle Azure se fera au travers de la commande Get-AzVM. De cette manière, il est impossible de confondre les deux contextes. Petite remarque, il ne faut plus utiliser d’anciens modules mais bien uniquement le module AZ. Les anciens modules utilisent plutôt une commande de type Get-AzureRm. Ce sont des commandes dépréciées.

Le reste de la commande est constitué de tout un ensemble de paramètres. Certains sont obligatoires, d’autres sont facultatifs.

Comme expliqué ci-dessus, le portail propose PowerShell sans installation et peut aussi fonctionner depuis peu de temps sans compte de stockage. Toutefois, il peut être intéressant de conserver des données générées depuis le portail, Il y aura alors besoin d’un compte de stockage pour pouvoir fonctionner de cette manière. Dans les exercices suivants, après la création d’un compte de stockage (rattaché aux commandes du portail), quelques commandes sont présentées pour faciliter la montée en compétence sur le code.

Az CLI

Az CLI est assez différent de PowerShell. Dans le cloud Shell du portail Azure, on utilise préférablement la console Bash (Linux) pour l’Az CLI et la console Powershell pour Powershell. C’est un ensemble de commandes qui effectuent les mêmes actions que PowerShell mais avec une syntaxe différente. Par affinité, PowerShell est souvent le choix d’un utilisateur Windows, et Az CLI celui d’un utilisateur Linux. Les exercices suivants permettent de se familiariser avec le langage.

Sélection du type de console depuis le menu

ARM

Le modèle ARM (Azure Resource Manager) est celui dont on entendait le plus parler il y a encore quelques années. Il est très complet et permet de créer de ressources, de les mettre à jour mais également de les supprimer. C’est donc le code de gestion parfait.

Mais avec l’arrivée de Bicep et de Terraform, la complexité du modèle ARM a petit à petit poussé les administrateurs vers ces deux langages. Il faut toutefois connaître ARM, langage historique du cloud Azure.

Avec ARM, on ne parle pas de code de programmation mais plutôt de déclaration par le code. Il faut décrire un état souhaité qu’ARM va ensuite mettre ou remettre en cohérence. Le langage supporte les paramètres, les variables et les fonctions. Construire un fichier JSON ARM de zéro est une opération qui peut rebuter dans un premier temps, et ce n’est pas le sujet lorsque l’on débute avec Azure. L’approche va être différente dans le livre, afin de permettre même aux débutants de déployer une première ressource sans difficulté. Et surtout, de pouvoir continuer à le faire en toute autonomie.

Pour cela, la première opération est de créer une ressource depuis le portail, puis d’utiliser le code généré pour créer la ressource suivante. C’est ce qui est proposé dans l’exercice. Il faut savoir que lorsqu’une ressource est créée sur Azure, le dernier écran de création propose systématiquement un code de déploiement au format ARM. Chaque création propose sur ce dernier écran une option Télécharger un modèle pour automation.

Bicep

Bicep est arrivé depuis quelques années maintenant et sa facilité de mise en œuvre est un gros avantage pour qui débute ou pour qui ne déploie pas régulièrement avec le code. C’est un modèle ARM mais avec une syntaxe plus légère, plus compacte et beaucoup plus compréhensible. Plutôt que de présenter ce modèle, une façon simple et agréable de comprendre les différences entre Bicep et ARM est de consulter le site https://azure.github.io/bicep/. Bicep masque un peu de la complexité de l’ARM.

Depuis l’accueil, en haut à droite du menu se trouve un bouton Sample Template. C’est une sélection de modèles ARM que le site se propose de modifier et il va les convertir en un code Bicep équivalent dans la partie gauche de l’écran.

Le code Bicep ne peut être utilisé sous cette forme. Il doit être compilé...

Terraform

Terraform est de plus en plus utilisé. Il a deux avantages par rapport aux solutions précédentes. Le premier est la présence d’un fichier d’état appelé tfstate. Le tfstate garde une trace de l’état actuel de l’infrastructure déployée. Cela permet à Terraform de savoir ce qui est déjà créé et ce qui doit être modifié. Lors de modifications de la configuration, Terraform utilise le fichier tfstate pour comprendre quelles ressources doivent être ajoutées, mises à jour ou supprimées. Avant d’appliquer des modifications, Terraform peut comparer l’état souhaité (défini dans les fichiers de configuration) avec l’état actuel (dans le tfstate), permettant ainsi de créer un plan d’action clair.

À chaque exécution, Terraform lit le fichier tfstate pour déterminer l’état actuel, le compare à la configuration et applique les modifications nécessaires.

Second avantage, Terraform est multifournisseurs, c’est-à-dire que la logique de son code permet de déployer Azure, mais aussi tout un tas de fournisseurs (provider) différents avec une syntaxe proche.

Exemple de providers pour Terraform

Voilà pourquoi c’est le code le plus utilisé pour les déploiements. En plus de ces deux points différenciants, il est aussi assez simple d’utilisation, même si certains scénarios de déploiements complexes peuvent aussi être traités par Terrafom. C’est aussi un langage déclaratif. Il faut décrire ce que l’on souhaite pour qu’Azure puisse le déployer et le maintenir.

Voilà pourquoi il ne faut pas démarrer sans avoir construit sa documentation de déploiement. Un code déclaratif, c’est une préparation importante.

Avant de passer aux exercices, si le fichier d’état Tfstate a beaucoup d’avantages, il impose une nouvelle méthode de travail. Il n’est plus possible de travailler directement depuis le portail, sauf si toutes les modifications manuelles (celles faites depuis le portail donc) sont systématiquement portées dans le code. Sans cette précaution, le fichier d’état...