Appliquer les bonnes pratiques avec le module de la boîte à outils de test

  • 5 minutes

Lorsque nous développons des modèles Azure Resource Manager (modèles ARM), il existe des moyens permettant de faciliter la création de modèles valides et de fournir des recommandations pour améliorer leur qualité. Quelles sont ces recommandations et pourquoi peut-il être bénéfique pour votre modèle de s’y conformer ?

Les recommandations se situent à différents niveaux : sous toutes formes, depuis les paramètres et les variables jusqu’à des recommandations qui s’appliquent à vos ressources. Considérons ces recommandations d’un point de vue général et de voir ce que vous pouvez gagner à vous y conformer :

  • Maintenabilité. Au fil du développement d’un modèle, depuis sa création initiale à sa mise à jour, conserver vos modèles propres et en ordre devient difficile avec le temps. À mesure que votre modèle se développe, vos paramètres et vos variables en font de même. Il est important de comprendre comment chacune de ces constructions est utilisée et comment les utiliser de manière appropriée.

    Imaginez un scénario dans lequel un paramètre est mal nommé, et où vous avez un mal fou à comprendre son action. Vous pouvez aussi utiliser une valeur codée en dur là où vous ne devriez pas le faire, si bien que lorsque des modifications se produisent, vos services Azure deviennent inopérants. Tous ces problèmes contribuent à la charge mentale qui vous demande de comprendre, puis d’oublier ensuite ce sur quoi vous travaillez. Le fait de s’imposer de la discipline quant à la façon de nommer les choses et de les nettoyer peut aider à atténuer les effets de ces scénarios.

  • Exactitude. Vous pouvez essayer de nommer tous les éléments de la manière appropriée, mais un trop grand nombre de règles à suivre pourrait bien vous rendre la tâche impossible. De tels cas nécessitent un outil qui vous rappelle toutes ces règles et ces réglementations, et qui les applique.

  • Flexibilité. Assurez-vous que vos modèles sont suffisamment flexibles pour être utilisés dans n’importe quel environnement. Si vous ne paramétrisez pas correctement vos modèles, il est possible qu’ils ne soient pas réutilisables.

  • Extensibilité. Parfois, vous voulez ajouter vos propres recommandations. Votre entreprise ou votre équipe peut avoir ses propres règles à appliquer.

Notes

La vérification du code par rapport à ces types de recommandations est parfois appelée linting.

La boîte à outils de test de modèle ARM

L’utilisation d’un outil de test est une bonne idée, car il vous permet de vous concentrer sur la création, en sachant que l’outil va trouver les problèmes et améliorer vos modèles. Un tel outil existe, il s’agit de la boîte à outils de test de modèle ARM, parfois appelé ARM-TTK. Il apporte une réponse aux problèmes mentionnés plus tôt en effectuant une série de tests. Les tests peuvent être regroupés selon les catégories suivantes :

  • Validation de l’intention de l’utilisateur. Cette catégorie détermine si les variables et les paramètres déclarés sont utilisés, et il avertit si ce n’est pas le cas.
  • Le respect des pratiques de sécurité. Un autre aspect important est de vérifier que rien de sensible n’est retourné depuis le modèle, par exemple des secrets d’API.
  • Utilisation des constructions de langage appropriées. Vous devez utiliser certaines constructions ou fonctions d’assistance des langages afin de ne pas vous appuyer sur des valeurs codées en dur.

Notes

Ce sont des recommandations, mais pas des exigences. Cependant, nous vous encourageons vivement à les suivre.

Installation de l’outil

L’outil est un module PowerShell. Pour pouvoir l’exécuter, vous devez suivre ces étapes :

  1. Installez PowerShell. Cette tâche est effectuée différemment selon que vous êtes sur Linux, Mac ou Windows.
  2. Télécharger le module. Le module est hébergé dans un dépôt GitHub. Vous pouvez le télécharger à partir de cet emplacement ou l’extraire via une commande git clone.
  3. Importer le module. Cette étape se résume à une instruction d’une ligne que vous entrez dans une session PowerShell, ce qui rend les commandes ARM-TTK disponibles.

Vous verrez comment effectuer toutes ces actions dans l’unité suivante. Une fois que vous avez installé l’outil, vous êtes prêt à exécuter les tests sur votre modèle.

Exécution des tests

La réalisation des tests implique l’appel du module avec les paramètres appropriés. -TemplatePath est un paramètre obligatoire qui attend une chaîne pointant vers l’emplacement du fichier de modèle de déploiement. Le nom de fichier du modèle doit être azuredeploy.json ou maintemplate.json. Une série de tests classique peut donc ressembler à la commande suivante :

Test-AzTemplate -TemplatePath path/to/template

L’outil teste le fichier de modèle, et teste également tous les fichiers de modèle contenus dans le même répertoire et dans ses sous-dossiers.

Une sortie classique d’une série de tests peut se présenter comme suit :

[+] adminUsername Should Not Be A Literal (24 ms)
[+] apiVersions Should Be Recent (18 ms)
[+] artifacts parameter (16 ms)
[+] DeploymentTemplate Schema Is Correct (17 ms)
[+] IDs Should Be Derived From ResourceIDs (15 ms)
[-] Location Should Not Be Hardcoded (41 ms)
     azuredeploy.json must use the location parameter, not resourceGroup().location (except when used as a default value in the main template)

Les tests réussis sont codés en vert et sont préfixés d’un signe [+]. Les tests ayant échoué sont codés en rouge avec le préfixe [-].

Configurer votre série de tests avec des paramètres de test

Vous avez vu jusqu’à présent que l’inclusion du paramètre -TemplatePath est obligatoire lorsque vous exécutez l’outil. L’outil accepte également des paramètres facultatifs. Ces paramètres vous permettent d’exécuter des fichiers ou des tests spécifiques. L’utilisation de ces paramètres vous offre un contrôle plus granulaire dans la création et le débogage de vos modèles.

Le paramètre -File est utilisé pour exécuter un fichier spécifique. Le paramètre -Test vous permet de préciser un scénario de test à exécuter.

Vous pouvez utiliser les paramètres des différentes manières suivantes :

  • Exécuter des tests sur un seul fichier. Vous pouvez exécuter des tests pour un seul fichier sur lequel vous travaillez actuellement. La raison est qu’il est plus facile de se concentrer sur la création d’un fichier de modèle spécifique. Un avantage supplémentaire est que la sortie va contenir moins de bruit et vous montrer seulement ce qui vous intéresse. En utilisant le paramètre -File avec un chemin vers un fichier (incluant le nom du fichier), vous pouvez exécuter les tests seulement sur ce fichier.

    Important

    Le paramètre attend toujours que azuredeploy.json ou maintemplate.json se trouvent à l’emplacement spécifié.

  • Exécuter un seul type de test sur tous les fichiers. Parfois, vous voulez exécuter un seul type de test pour vérifier que vous respectez les critères seulement pour ce scénario. Vous pouvez accomplir cette tâche en utilisant le paramètre -Test. Le paramètre attend le nom complet du test entre guillemets, par exemple Resources Should Have Location (Les ressources doivent avoir un emplacement).