L’utilisation de machines virtuelles dans AZURE est soumis à un mode de facturation bien particulier, qui peut rapidement faire grimper la facture si on ne prend un minimum de précautions.
Aussi, après avoir pris soin de bien dimensionner vos machines virtuelles en fonction de besoins réels (taille des instances adaptée à l’usage), vous aurez tout intérêt à éteindre convenablement vos machines lorsqu’elles sont inutilisées, ce qui est souvent le cas lorsque l’on utilise le Cloud AZURE comme plateforme de démonstration.
Facile à dire, mais nous allons voir qu’il ne suffit pas d’éteindre une machine pour que le compteur de facturation s’arrête, il faut en effet que celle-ci soit désallouée, c’est-à-dire éteinte au travers de la fonction « ShutDown » du tenant AZURE.
Cette tâche peut rapidement s’avérer rébarbative, et je vous propose de voir de quelle façon il est possible de l’automatiser à l’aide du service AZURE Automation et d’un peu de PowerShell.
SMA – Le service AZURE Management Automation.
Le service AZURE automation (abrégé SMA) permet d’orchester différents types d’opérations au sein de votre tenant AZURE. Si vous avez déjà eu l’occasion de travailler sur votre Intranet avec System Center Orchestrator, il s’agit du même concept : les codes sous jacents sont les mêmes et l’on retrouve beaucoup de similitudes entre ces deux composants. Du reste, l’utilisation de SMA au travers de la nouvelle interface de gestion AZURE présente clairement la notion de Runbook en mode graphique, comme Orchestrator….
Le RunBook représente un ensemble de tâches ordonnancé pouvant être simple ou complexe selon la problématique à traiter. Dans notre cas, il s’agira d’énumérer les machines virtuelles en cours d’execution puis de les éteindre, c’est donc un RunBook plutôt simple que nous allons mettre en œuvre.
Pour implémenter SMA dans votre tenant, la prémière opération va être de créer un comte d’automation. Rendez vous sur votre portail AZURE et choisissez l’option « Automation Accounts » :
Selectionnez l’option « Add », donnez un nom à votre compte, affectez le à un service de Cloud, à une de vos souscriptions et à votre région:
Après avoir créé votre compte d’automation, il va être nécessaire d’y ajouter des « Assets », ce concept identique à celui de la plateforme Orchestrator est particulièrement important.
Il s’agit d’objets associés à votre compte d’automation déstinés à être « consommés » (utilisés) dans vos RunBook. Ils sont définis par un Administrateur du tenant AZURE mais sont consommables par des opérateurs, ainsi, nous pourrons facilement générer des Assets de type « Compte d’utilisateur », planification ou « Variable » utilisables par des opérateurs sans pour autant leur communiquer d’informations sur ces éléments (mots de passe notamment…).
Pour notre premier RunBook, il va nous falloir les Assets suivants:
- Un compte d’utilisateur (utilisé pour éteindre les VMs)
- Une planification (la récurrence d’exécution du RunBook)
Les Assets sont accessibles via le compte d’automation. Dans ce billet de blog, nous ne nous intéresserons qu’aux Assets nécessaires à notre RunBook (planification et comptes d’utilisateurs) bien que les « Modules » soient également nécessaires (ces derniers sont définis à la création du compte d’automation, il s’agit de modules PowerShell executables dans les RunBooks – hors sujet).
Asset « Compte utilisateur » (Credential)
Avant de référencer un Asset de type « Credential », il est nécessaire de créer un compte correspondant dans l’annuaire Acitve Directory de votre tenant AZURE :
Pour ce besoin, j’ai créé le compte « SMA-01 » auquel j’ai attribué le rôle « Global Administrator » par souci de simplicité. Il est probable que des permissions moindres auraient suffi pour éteindre des VMs, mais cela sort du sujet de ce billet de blog.
Si vous avez envie que votre RunBook fonctionne longtemps, pensez à faire en sorte que le mot de passe du compte d’automation n’expire pas, sinon ce sera 90 jours par défaut.
Ref : https://msdn.microsoft.com/fr-fr/library/azure/jj943764.aspx )
Le portail AZURE ne vous permettra pas de définir ce paramètre, il faudra faire un peu de code depuis une instance PowerShell liée à votre tenant :
Ref : https://msdn.microsoft.com/fr-fr/library/azure/dn194136.aspx
Asset « Planification » (Schedule)
J’ai créé une planification très simple, chaque jour à 23h00, qui sera parfait pour éteindre les VMs restées allumées
Script PowerShell du RunBook
N’oublions pas le script PowerShell du RunBook. A ce sujet, il est important de souligner que SMA n’utilise que du Powershell de type « WorkFlow », dont l’exécution diffère du PowerShell traditionnel et dont la syntaxe, bien que proche, diffère également. Vous trouverez des informations sur les WorkFlows PowerShell sur le site https://technet.microsoft.com/en-us/library/jj134242.aspx
Notre script traite donc:
- La définition de l’Asset « utilisateur » qui exécutera l’action
- La définition du tenant AZURE (souscription)
- L’énumeration des VMs du tenant qui sont en état « Ready »
- La définition d’une liste de VMs ne devant pas être éteinte de façon à les exclure de la liste précédente
- L’extinction des VMs concernées.
Facile en quelque sorte. Notez que le bloc de commandes est inclus dans un WorkFlow, ainsi que la syntaxe un peu particulière qui en découle (utilisation d’un bloc « FilterScript » dans la redirection Where-object). Le code ici: Stop-VMs
Planification du RunBook
Il nous reste à planifier le RunBook, c’est-à-dire associer le RunBook à la planification que nous avons définie, et il sera exécuté chaque jour à 23h00 :
Conclusion
SMA est un service très utile sitôt que l’on a besoin d’automatiser certaines tâches dans le cloud AZURE, ce qui devrait être un cas de figure général.
Cette première approche nous a permis d’exploiter un RunBook de type PowerShell assez simple à mettre en œuvre, mais qui peut grandement contribuer à préserver votre crédit AZURE.
Pour terminer, je dois ajouter qu’il s’agit d’un service gratuit tant que vous ne dépassez pas les 500 Minutes de traitement (30000 secondes si vous préférez), optimisez vos scripts et observez leur durée de traitement avant de les publier.
Bonne automation !