Introduction

L'ARM template est l’arme de choix dans l’arsenal d'Infrastructure as Code pour Azure.

De manière générale, il ne faut pas négliger le temps nécessaire pour la création des scripts, des fichiers de configuration pour l'Infrastructure as Code.

Pour autant, grâce à la répétabilité, vous gagnerez du temps pour la création des environnements (passage en prod à l’arrache ?), en documentation, en qualité et en confiance (chaque mise à jour ne générera pas un stress car le résultat est connu d’avance)

Comme on va le voir, il existe plusieurs façons de créer des ARM templates. Chacune a ses avantages et inconvénients.

Il sera donc parfois nécessaire de les combiner pour arriver à vos fins.

Automatisation dans le portail

Les gens me posent souvent la question : « Une fois que l’on a créé les ressources dans le portail, il n’est pas possible de faire un copié/collé pour créer un nouvel environnement ? »

Oui et non.

En effet, le portail a une fonction proche : « Exporter le modèle ». Cette fonctionnalité est présente au niveau d’un groupe de ressources ou au niveau de la plupart des ressources.

Dans le portail :

Exporter le modèle dans le portail Azure

Puis, le contenu généré :

ARM template généré dans le portail

Avantages :

  • Solution simple.

  • La qualité des ARM templates s’améliorent.

  • Le portail génère également le fichier de paramètres.

Inconvénients :

  • Comme on peut le voir sur la copie d’écran ci-dessus, toutes les ressources ne sont pas exportables.

  • Il n’est pas rare que des paramètres soient omis.

  • En réalité, les ARM templates ainsi produits sont de qualité assez médiocre :

    • Le nom des paramètres utilise le nom des ressources. Comme l’objectif est souvent de pouvoir créer plusieurs environnements, il est préférable de généraliser le nom des paramètres. Par exemple, pour un compte de stockage, le paramètre va être storageAccounts_nomducomptedestockage_name. Il est recommandé de le renommer storageAccountName par exemple pour le généraliser et conserver une convention de nommage en camelCase.

    • Il n’y a pas d’intelligence dans ces templates. Il peut être intéressant de prévoir des boucles ou d’autres logiques.

Création dans le portail

Lors de la création d’une ressource, il est possible, juste avant la création d’exporter un ARM template.

ARM template généré lors de la création

Avantages :

  • Solution simple.

  • ARM template plus propre que lors de l’export.

  • Le portail génère également le fichier de paramètres.

Inconvénients :

  • Les ARM templates ainsi générés peuvent plus complexe que nécessaire et inclure un paramétrage non nécessaire. Ainsi, lors de la création d’une base, l'ARM template généré intègre la création d’un serveur SQL alors qu’il s’agissait de la création d’une base uniquement. Sans parler de toute la configuration réseau ou de sécurité avancée…​

  • Les ARM templates ainsi générés sont parfois si complexe qu’ils ne sont pas valides (j’ai déjà eu le cas !).

Quickstart templates

Microsoft met à disposition des exemples pour la création de nombreuses ressources sur GitHub. On peut y retrouver des exemples de base (préfixés en 101) jusqu’à des architectures complexes (ferme RDS, infrastructure SAP, etc.).

Avantages :

  • Bon point de départ pour des cas de la vie réelle comme le chiffrement de disque de VM ou sa sauvegarde, des applications Web, etc.

  • Pas mal d’astuces à reprendre pour l’écriture d'ARM templates sur les conditions, les boucles, le jeu des nested templates, etc.

  • De nombreux template sur des composants non-Microsoft (Chef, SAP, Jenkins, Drupal, etc.).

Inconvénients :

  • Certains template ne sont pas mis à jour alors que le service évolue. Ainsi, certains templates utilisent des vieilles versions d’API. Je pense notamment aux App Services dont la gestion des piles technologies a évoluée et pour laquelle je n’ai pas trouvé d’exemple viable

  • Cela manque de cohérence :

    • Sur le nommage des paramètres. Un réseau virtuel peut s’appeler vnet ou virtualNetworkName, ce qui nécessite un travail pour mettre en cohérence.

    • La gestion de la localisation de la ressource: dans le cas général, comme ici, la localisation est traitée comme un paramètre qui a une valeur par défaut à celle du groupe de ressource, ici c’est une variable.

La référence

Microsoft publie la documentation des ressources disponibles, pour les différentes versions d’API.

Malheureusement, ces pages ne sont pas irréprochables. Ainsi, le nommage est proche de l’implémentation et l’on va avoir quelques bizarreries comme par exemple pour les App Services : pour avoir la référence, inutile de chercher « App Service ». Il faut aller sur « Web » car le provider est Microsoft.Web. Ne cherchez pas non plus « App Insights », etc. Vous voilà prévenu !

Mais le principal reproche est que les valeurs sont rarement documentées. Par exemple, le paramètre type de la configuration git d’un DataFactory n’a pas de valeur décrite

Avantages :

  • Liste en théorie tous les paramètres disponibles

Inconvénients :

  • Il n’est pas rare qu’il manque des paramètres

  • Les valeurs des enums sont souvent manquantes

  • Le parcours du site n’est pas toujours aisé du fait d’une recherche médiocre

Exploration des ressources

Microsoft met à disposition une interface Web qui permet de parcourir les ressources de sa souscription en ARM : https://resources.azure.com.

Azure Resource Explorer

Cet outil est très utile pour justement récupérer les valeurs que la référence n’aura pu nous donner.

Cela étant, comme il n’affiche pas un ARM template, il y a un travail certain pour convertir l’information dans un ARM template. A utiliser en dernier recours donc !

Cet outil permet de parcourir les différentes souscriptions rattachées à différents tenants Azure AD.

Avantages :

  • Permet d’afficher les valeurs. Cela est intéressant quand on joue dans le portail pour voir les effets en ARM.

Inconvénients :

  • Ne fournit pas un ARM template à proprement parler.

  • Il est nécessaire de faire le tri en les paramètres que l’on peut fixer et ceux qui sont des attributs systèmes, accessibles en lecture seule par exemple.

  • Toutes les ressources ne sont pas affichages par ce biais.

  • Tous les paramètres ne sont pas affichés, notamment les secrets.

Déploiement

Chaque déploiement dans un groupe de ressources est tracé. C’est un bon moyen parfois pour avoir des détails sur les erreurs. Mais il est possible de récupérer l'ARM template utilisé lors de l’export.

Dans le portail, il suffit d’aller dans le menu « Déploiement » :

Menu déploiement dans le portail Azure

Il est alors possible d’accéder aux paramètres d’entrée, au template utilisé :

Template d’un déploiement
Le template affiché ici est différent de l’export proposé à la création.

Avantages :

  • Récupération d'ARM template fonctionnel (dès lors que le déploiement est en succès).

  • Très bonne méthode pour faire du reverse engineering si les templates ont été perdu.

Inconvénients :

  • Comme pour les autres méthodes à partir du portail Azure, la qualité du template n’est pas toujours excellente.

PowerShell

C’est une critique que l’on peut faire aux cmdlets PowerShell d’Azure : je trouve qu’on est souvent trop proche de l’implémentation ARM. Essayez de créer une VM en PowerShell ! En Az cli, cela peut se faire en une ligne, pas en PowerShell.

Pour autant, ici cela peut être un avantage.

Je me suis servi de cette technique pour automatiser la création d’alerte. Il est facile de créer ou modifier une alerte ou un groupe d’actions dans le portail mais il n’existe pas les moyens de l’exporter.

Les alertes sont aussi absentes d'Azure Resource Explorer.

J’ai donc travaillé avec la cmdlet Get-AzMetricAlertRuleV2 qui m’a permis d’aller dans le détail des paramètres

Exemple pour avoir l’identifiant du groupe d’action :

$alertes = Get-AzMetricAlertRuleV2
$alerte = $alertes[0]
$alerte.Actions[0].ActionGroupId

Avantages :

Inconvénients :

  • Comme pour l'explorateur de ressources, cette méthode ne permet pas d’obtenir un ARM template directement exploitable.

  • Cette méthode ne va pas fonctionner sur toutes les ressources car cela dépend à quel point la cmdlet est proche de l’implémentation ARM

Bonus : ARMTemplateGenerator

Afin de pallier les défauts rencontrés dans la création d'ARM templates, j’ai créé un outil permettant la création d'ARM templates « propre » : https://github.com/r3dlin3/ARMTemplateGenerator.

Cet outil permet de :

  • Assurer une cohérence dans le nommage des paramètres

  • Générer un template en fonction de son besoin : ainsi, lors de la création d’une base, le template généré contiendra la création d’un serveur que si cela est nécessaire.

N’hésitez pas à contribuer pour ajouter des ressources ou des nouveaux paramètres, mettre à jour les API, etc.

Avantages :

  • Cohérence dans le nommage des paramètres

  • Template adapté à son besoin

Inconvénients :

  • Peu de ressources disponibles

Conclusion

L’écriture d'ARM templates n’est pas toujours compliqué heureusement.

Parfois, cependant, pour arriver à ses fins, il peut être nécessairement d’ouvrir le truc au pied de biche, mais cela vaut souvent le coup. Chacune des techniques citées plus haut vous permettra d’arriver à vos fins, si tant est que soit possible. On se souvient par exemple qu’à l’époque, il n’était pas possible de créer un container sur un compte de stockage. Aujourd’hui, c’est possible de le faire en ARM template.