Je vous propose aujourd’hui de tester Azure Automation.
Ce service proposé sur le cloud de Microsoft Azure vous permet d’automatiser certaines tâches répétitives, manuelles, de longue durée et/ou susceptibles d’engendrer des erreurs humaines. Plus simplement, cela revient à scripter certains comportements de votre infrastructure cloud hébergée au sein d’Azure.
A noter qu’Azure Automation vous permet d’exécuter du code PowerShell (et même plus récemment Python) au sein de vous souscription Azure sans pour autant avoir besoin d’héberger votre code sur une machine dédiée. Le code est en effet géré et exécuté directement dans le service appelé Azure Automation. Dans ce contexte, on parle alors de runbook PowerShell ou workflow.
Il existe une librairie complète de scripts proposés par la communauté que vous pouvez retrouver en suivant ce lien. Mais l’objectif de cet article est de se familiariser avec Azure Automation – donc, je vous propose de faire tout depuis zéro avec un exemple basique : comment arrêter des machines virtuelles sur Azure automatiquement.
Pour les besoins de cet exemple, j’ai créé 2 machines virtuelles. Il s’agit de 2 machines virtuelles Linux DS1_v2 qui portent le nom de VM1 et VM2. Je les ai regroupées dans un resource group appelé TGI-Test. Je vous laisse adapter les détails du réseau si besoin – en fait nous n’avons même pas besoin de nous connecter à ces machines – c’est pourquoi je n’entre pas dans les détails. Tous ces éléments sont créés sur ma souscription MSDN Azure.
Nous allons maintenant créer notre nouveau compte Azure Automation. Cherchez dans Azure le service appelé Automation accounts et créez un nouvel objet.
Rien de particulier à ce niveau, j’ai personnellement choisi la configuration suivante :
Procédez à la création.
Cliquez sur notre nouvel objet AutomationAccount. Vous pourrez voir que vous disposez d’un certain nombre d’options. Pour commencer, nous allons nous intéresser à la partie Runbooks.
Créez un nouveau runbook en cliquant sur Add a runbook dans la partie supérieure.
Choisissez les options suivantes :
Si ce n’est pas automatique, cliquez ensuite sur votre nouveau runbook puis sur le bouton Edit pour passer en mode édition.
L’ossature de votre runbook est créé automatiquement et il ne vous reste alors plus qu’à compléter avec votre code.
Par défaut, un runbook peut avoir plusieurs statuts différents. Pour qu’il soit considéré comme « en production » celui-ci doit être « publié« .
Je vous proposer de tester le code suivant :
workflow MyFirstRunbook { # Association to the Azure subscribtion $Conn = Get-AutomationConnection -Name AzureRunAsConnection Add-AzureRMAccount -ServicePrincipal -Tenant $Conn.TenantID ` -ApplicationId $Conn.ApplicationID ` -CertificateThumbprint $Conn.CertificateThumbprint # Getting all the VM in the resource group concerned $listVM = Get-AzureRMVM -ResourcegroupName "TGI-Test" # Stopping all the virtual machines foreach ($VM in $ListVM) { Stop-AzureRMVM -ResourceGroupName "TGI-Test" -Name $VM.Name -Force } }
Rien de bien extravagant mais notez-le Get-AutomationConnection qui vous permet de vous connecter depuis votre runbook PowerShell à votre souscription Azure afin de pouvoir y réaliser des tâches. Selon vos besoins, cette portion pourra être nécessaire sur la plupart de vos scripts.
Ensuite, on récupère la liste des VM d’un même Resource group puis pour chaque machine virtuelle on arrête la VM avec la commande Stop-AzureRMVM. Cela aura pour effet de décommissionner les VM concernées. L’utilisation du paramètre -Force est nécessaire pour éviter que le code ne vous demande de confirmer votre choix (ce que le runbook ne pourrait pas confirmer tout seul en l’état).
Evidemment, avant d’aller plus loin – si ce n’est pas le cas, n’oubliez d’allumer vos machines de test ! 😉
Ensuite, pour tester votre script, il vous suffit de cliquer dans la partie supérieure sur Test pane puis sur le bouton Start pour lancer l’exécution. En exécutant votre runbook, il s’agit d’une exécution de test pour vérifier le bon fonctionnement du script. L’exécution va passer par plusieurs statuts différents : Queued, Running et si tout va bien Completed.
L’exécution peut prendre plus ou moins de temps…
Après quelques instants, nous pouvons voir que l’exécution du runbook semble s’être correctement déroulée. Pour s’en assurer, nous pouvons également vérifier que nos 2 machines virtuelles de test ont été correctement arrêtées.
On peut voir très clairement que nos 2 machines virtuelles ont été correctement stoppées et que la demande a bien été exécutée par notre « AutomationAccount » (et le runbook associé).
Evidemment, pour l’instant, notre script est plutôt très basique et ne gère aucun cas particulier (ma VM est déjà atteinte, mon script n’a pas pu éteindre ma VM, etc.). Dans un prochain article, nous verrons comment planifier l’exécution d’un runbook PowerShell afin d’exécuter un script à un moment précis (ou encore de répéter son exécution).
Aperçu de la nouvelle version à venir de Microsoft Outlook - Source Microsoft Microsoft prévoit…
Jacquie et Michel : le géant français du X racheté par des Américains Le célèbre…
Sora : Le Nouvel Outil Révolutionnaire de ChatGPT pour Créer des Vidéos avec l’IA OpenAI…
Nouveautés dans la recherche sur Google : Résultats non personnalisés Google introduit une nouvelle fonctionnalité…
Câble sous-marin - Image d'illustration Meta, la société mère de Facebook, Instagram et WhatsApp, envisage…
Google Maps : une révolution attendue dans le signalement d'incidents routiers Depuis plusieurs années, les…