Craft et PowerShell : de la nécessité d’appliquer les pratiques de Software Engineering à l’infrastructure

Les plateformes Cloud sont de plus en plus complexes et de plus en plus sensibles à des erreurs de paramétrages. Leur pilotage demande aussi une grande quantité de scripts, et qui dit script dit maintenance et évolutions.

Les modèles d’organisation s’orientent maintenant vers des équipes qui concentrent la gestion et l’évolution, et dont la taille n’est plus linéairement corrélée à la taille de l’infrastructure. Ces équipes ont donc besoin d’outils permettant de réduire les risques lors des évolutions et les maintenances, et doivent pouvoir automatiser en toute confiance le plus d’actions possible. Elles se retrouvent donc avec la même problématique que les équipes de développement logiciel classique : une petite équipe avec une grande base de code.

Le premier maillon dans cette liste d’outils est le langage de script qu’elles utilisent.

Vous pouvez retrouver l’ensemble des pratiques présentées dans cet article sur cette vidéo de la DevCon #17 (à partir d’1h37) :

PowerShell, le couteau suisse de l’Ops

Lors de sa sortie, PowerShell était un outil exclusivement réservé au monde Windows, car basé sur le .NET Framework. Les dernières versions se sont affranchies de cette limite en se basant sur .NET Core au début, puis maintenant sur .NET 6 et 7.

PowerShell est donc maintenant disponible sur toutes les plateformes que l’on peut administrer : Windows, Linux, MacOs et même sur des conteneurs.

Comme il est toujours basé sur un langage structuré, il apporte des paradigmes de développement au monde de l’Ops. En particulier :

• Types structurés
• Gestion des erreurs
• Debug

Ces propriétés permettent à PowerShell d’être une excellente plateforme pour écrire des « scripts » d’envergure, car ils vont permettre un haut niveau de maintenance et d’évolution…. A condition que l’on respecte quelques bonnes pratiques.

Bonne pratique #1 : utiliser les types structurés

Les types structurés permettent de stocker la donnée au format natif, et éviter les erreurs d’interpolations classiques du genre entier ou date en chaine de caractères.

Tous les types de bases connus en .NET sont disponibles. Ceux dont on se sert le plus couramment sont : les chaines, les entiers, les booléens et les dates.

Les structures de données permettent nativement de stocker des listes et des tables de hachage. Par exemple, il est assez courant de convertir un fichier JSON en table de hachage pour parcourir son contenu.

Bonne pratique #2 : une bonne gestion des erreurs

Comme n’importe quel langage, la gestion des erreurs est essentielle, surtout lorsque les scripts vont tourner sur des comptes de services ou des agents en tâche de fond. Il faut donc être sûr que lorsqu’une erreur se produit, elle est tout de suite capturée et traitée.

PowerShell vous laisse décider de ce qu’il faut faire en cas d’erreur.

Sur les cmdlets, il y a la possibilité de choisir le comportement via le paramètre « -ErrorAction », dont :

• Afficher l’erreur et continuer (mode par défaut) ;
• Continuer et cacher l’erreur ;
• Émettre une exception.

Il peut être fastidieux de procéder ainsi pour chaque commande. Il est donc possible de le faire une fois pour toutes via cette variable :

$ErrorActionPreference = "Stop"

Consulter la documentation Microsoft sur le sujet.

De cette façon, le script va automatiquement s’arrêter si l’exception n’est pas traitée. La gestion des exceptions est d’ailleurs assez simple à gérer :

Il est même possible, comme dans n’importe quel langage évolué, de spécifier l’exception que l’on veut attraper.

Consulter la documentation Microsoft pour en savoir plus.

Bonne pratique #3 : Éviter les surprises avec le « Strict Mode »

Par défaut, PowerShell aime bien renvoyer la valeur « $null » si la variable ou la propriété que l’on cherche n’existe pas. Cela peut être très pratique lorsque l’on navigue dans un fichier « JSON », mais on est à la merci de beaucoup d’erreurs, dont les erreurs de noms de variables. Pour éviter cela, on peut indiquer à PowerShell comment se comporter : c’est le « Strict Mode »

Pour éviter les mauvaises surprises, il est recommandé de toujours de démarrer les scripts par figer le strict mode au niveau le plus élevé. Pour les scripts déjà existants, il faut être plus prudent, et y aller au cas par cas.

Accéder à la documentation Microsoft sur le Strict Mode.

Bonne pratique #4 : Tests

Un bon langage est un langage qui permet de faire des tests ! Pester est une bibliothèque open source qui permet de réaliser des suites de tests complètes. Elle inclut entre autres :

• La possibilité d’avoir des générateurs de cas de tests ;
• Une isolation pour tester les modules ;
• Un jeu d’assertion pour une meilleure lisibilité des tests ;
• Des commandes pour réaliser des Mocks.

Voilà à quoi ressemble un ensemble de tests sous Pester :

Bonne pratique #5 : Environnements contrôlés

L’autre problématique avec l’infra, c’est le contrôle de l’environnement d’exécution local et distant. Généralement, au-dessus du langage de script, toute une suite d’outils en ligne de commande est nécessaire pour piloter l’infrastructure. Chaque outil vient avec ses limitations, et ses versions. Contrôler que tout le monde travaille avec le même environnement est crucial pour la reproductibilité de l’exécution des scripts.

Pour cela, la conteneurisation des environnements de développement et d’exécution est essentielle pour maintenir ce contrôle.

Visual Studio Code possède un système de plugin qui permet cette isolation .

En savoir plus sur le Craft

Vous souhaitez en savoir plus sur le Craftsmanship ? Retrouvez tous les articles de notre série du Mois du Craft :

• Le Craft est-il toujours d’actualité ?
• Comment choisir l’architecture logicielle idéale grâce aux Architectural Drivers ?
• Comment crafter une infrastructure avec Terraform ?
• Les bonnes pratiques de tests unitaires PySpark
• Télémétrie : la garantie d’un code qui fonctionne
• Boostez la performance de vos applications avec Asyncio : un guide pratique pour les développeurs Python