Maîtrisez votre Cloud : gérez vos services avec Azure Automation!

Le Cloud Microsoft Azure offre la possibilité d’allouer rapidement de nouvelles ressources qui se rajoutent au système d’information. En complément, les services Cloud permettent d’exécuter des opérations de gestion sur la souscription Azure elle-même. Dans cet article, nous allons voir ce que les tâches planifiées peuvent apporter, et comment les mettre en place via Azure Automation.
Faire des économies grâce au Cloud
Le Cloud Azure fonctionne dans un modèle « Pay-as-you-Go », ce qui signifie que ce sont les ressources consommées qui sont facturées. De ce fait, pour réduire les coûts de la plateforme, il suffit d’éteindre les machines virtuelles allouées lorsqu’elles ne sont pas utilisées. Cette particularité du Cloud n’est pas tant valable pour les ressources hébergées à demeure, il s’agit donc de nouvelles habitudes qu’il est bon de prendre rapidement pour optimiser sa consommation. C’est notamment en ce sens que l’hébergement sur le Cloud a un coût moins élevé que celui à demeure : il n’y a pas des coûts fixes liés à l’achat de matériel, à leur installation ou à leur maintenance.
Mais plutôt que d’allumer et d’éteindre manuellement les machines chaque jour, il est plus intéressant de profiter d’une philosophie apportée par le Cloud : automatiser tout ce processus ! En plus de faire gagner du temps et d’éviter les erreurs que peuvent apporter les opérations répétitives manuelles, cette façon de procéder est tout de même plus pertinente, plus adaptée en cette ère digitale que nous traversons ! 🙂
C’est dans cette optique que Microsoft propose Azure Automation, service hautement disponible qui permet d’exécuter des processus de façon manuelle ou automatique. Le langage utilisé pour développer les scripts est le PowerShell, bien connu dans l’environnement Microsoft.
Création des runbooks dans Azure Automation
Dans cet article, je vais détailler comment mettre en place une automatisation qui va démarrer ou arrêter les machines virtuelles en fonction d’un calendrier stocké sur une table SQL.
Pour ce calendrier, nous pouvons utiliser la structure de table suivante :
- AzureVMNamePattern : modèle de nom des machines virtuelles, sous le format PowerShell,
- StartDate : date de début de fonctionnement pour les machines virtuelles concernées,
- EndDate : date de fin de fonctionnement pour les machines virtuelles concernées.
Dans mon exemple, la machine virtuelle « bts-dev » et celles commençant par « devlyi- » doivent être opérationnelles le 31/08/2015 entre 8h et 20h.
Pour mettre en place l’automatisation, une des possibilités est de le découper en plusieurs processus ou runbook, par exemple :
- StartVM : processus de démarrage des VMs,
- StopVM : processus d’arrêt des VMs,
- CalendarCheck : récupère les machines virtuelles qui doivent être démarrées à la date d’exécution, et lance les runbooks StartVM et StopVM en fonction du résultat.
Dans la description de CalendarCheck, on perçoit une fonctionnalité proposée par Azure Automation : il est possible d’exécuter un runbook à partir d’un autre, en lui passant les bons paramètres. La création des runbooks peut s’effectuer directement à partir du nouveau portail Azure, à l’adresse suivante : https://portal.azure.com
Pour commencer, après connexion à la souscription Azure, il faut créer un compte Azure Automation s’il est inexistant. Pour le faire, cliquer sur Parcourir tout > Compte Automation > Ajouter et renseigner les différentes informations pour la création du compte d’automatisation. Une fois ce compte créé, cliquer dessus pour entrer dans les détails puis sur le bouton « Runbooks » pour faire apparaître la liste des runbooks existants. Cliquer sur « Ajouter un runbook » et remplissez les champs Nom et Description pour chacun des runbooks à créer. Les runbooks sont de type « Flux de travail PowerShell ».
Les runbooks créés sont à présent visibles dans la liste et il est possible d’en sélectionner un et de le modifier en cliquant sur le bouton correspondant. Un volet permet d’entrer le code PowerShell qui correspond au workflow exécuté par ce runbook. Vous pouvez intégrer le code suivant pour les runbooks StartVM et StopVM et cliquer sur le bouton « Enregistrer » pour valider la modification.
- Runbook StartVM :
workflow StartVM { Param ( [parameter(Mandatory=$true)] [String] $AzureCredentialName, [parameter(Mandatory=$true)] [String] $SubscriptionId, [parameter(Mandatory=$true)] [Array] $VMList ) InlineScript { $cred = Get-AutomationPSCredential –Name $using:AzureCredentialName Add-AzureAccount –Credential $cred Select-AzureSubscription -SubscriptionID $using:SubscriptionId Get-AzureVM | Where { ($using:VMList -contains $_.Name) -and ($_.Status -eq "StoppedDeallocated") } | Start-AzureVM } }
- Runbook StopVM :
workflow StopVM { Param ( [parameter(Mandatory=$true)] [String] $AzureCredentialName, [parameter(Mandatory=$true)] [String] $SubscriptionId, [parameter(Mandatory=$true)] [Array] $VMList ) InlineScript { $cred = Get-AutomationPSCredential –Name $using:AzureCredentialName Add-AzureAccount –Credential $cred Select-AzureSubscription -SubscriptionID $using:SubscriptionId Get-AzureVM | Where { ($using:VMList -contains $_.Name) -and ($_.Status -eq "ReadyRole") } | Stop-AzureVM -Force } }
Lors de l’exécution de ces runbooks, les paramètres AzureCredentialName, SubscriptionId et VMList seront requis. Le comportement des runbooks peut donc être modifié en fonction des paramètres soumis, ce qui est très utile lorsque l’on lance un runbook à partir d’un autre.
Petit point d’attention sur l’exécution d’opérations de gestion sur la souscription Azure : comme pour utiliser Azure PowerShell sur un poste local, il est nécessaire de rajouter un compte dans les droits d’administration de la souscription. La procédure est détaillée à la page suivante, en note de la section « Utilisation de la méthode Azure AD ».
Ensuite, pour utiliser ce compte d’administration dans un runbook, il faut rajouter un compte de type Credential dans le compte Automation. Sur le portail Azure, sélectionner le compte Automation et cliquer sur le bouton « Ressources ». Dans le nouveau volet, choisir « Informations d’identification » et cliquer sur le bouton « Ajouter » pour entrer les informations nécessaires. Attribuer un nom à cette nouvelle information d’identification, et saisir le nom d’utilisateur et le mot de passe.
Vous pouvez à présent retourner dans les détails des runbooks précédents et exécuter un test. Renseigner le nom du Credential créé à l’étape précédente, l’ID de la souscription Azure et la liste de VM à démarrer, au format PowerShell JSON.
Le volet de test permet de suivre directement l’exécution du runbook et les informations retournées. Il constitue une véritable aide lors de la phase de développement.
Si le test aboutit correctement, nous pouvons procéder à l’étape de publication le runbook et l’exécuter directement. Azure Automation enregistre les exécutions des runbooks publiés et il est possible de consulter les traces, elles comportent notamment les paramètres d’entrée, les messages de sortie et les exceptions qui peuvent survenir.
A présent, nous pouvons créer le dernier runbook CalendarCheck avec le code suivant :
workflow CalendarCheck { Param ( [parameter(Mandatory=$true)] [String] $DBAddress, [parameter(Mandatory=$true)] [String] $DBName, [parameter(Mandatory=$true)] [String] $CalendarDbCredential, [parameter(Mandatory=$true)] [String] $AzureCredentialName, [parameter(Mandatory=$true)] [String] $SubscriptionId, [parameter(Mandatory=$true)] [String] $AutomationAccountName ) $cred = Get-AutomationPSCredential -Name $CalendarDbCredential $azureCredential = Get-AutomationPSCredential –Name $AzureCredentialName Add-AzureAccount –Credential $azureCredential Select-AzureSubscription -SubscriptionID $SubscriptionId $result = InlineScript { $result = $null $DBUser = ($Using:cred).GetNetworkCredential().UserName $DBPassword = ($Using:cred).GetNetworkCredential().Password $SqlQuery = "select AzureVmNamePattern from Calendar where getdate() between StartDate and EndDate" #Connexion a la base SQL $SqlConnection = New-Object System.Data.SqlClient.SqlConnection $SqlConnection.ConnectionString = "Server = $Using:DBAddress; Database = $Using:DBName; User ID = $DBUser ; Password = $DBPassword ; Integrated Security = False" #requete $SqlCmd = New-Object System.Data.SqlClient.SqlCommand $SqlCmd.CommandText = $SqlQuery $SqlCmd.Connection = $SqlConnection $SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter $SqlAdapter.SelectCommand = $SqlCmd $DataSet = New-Object System.Data.DataSet #on vérifie l'exécution de la requete SQL $recupData = $SqlAdapter.Fill($DataSet) if ($recupData -ne $null) { $result = $DataSet.Tables.AzureVMNamePattern } #fermeture de la connexion SQL $SqlConnection.Close() $result } #liste des vms à démarrer $VMsToStart = @() #liste des vms à éteindre $VMsToStop = @() foreach($vm in (Get-AzureVM)){ $isPresent = $false foreach($namePattern in $result){ if( (-not $isPresent) -and ($vm.Name -like $namePattern) ){ $isPresent = $true if($vm.Status -eq "StoppedDeallocated"){ $VMsToStart += $vm.Name } } } if(-not $isPresent -and $vm.Status -eq "ReadyRole"){ $VMsToStop += $vm.Name } } echo "VMs à allumer" $VMsToStart echo "VMs à éteindre" $VMsToStop #lancement du runbook StartVM if($VMsToStart.count -gt 0){ $params = @{"AzureCredentialName"=$AzureCredentialName;"SubscriptionId"=$SubscriptionId;"VMList"=$VMsToStart} Start-AzureAutomationRunbook -Name "StartVM" -Parameters $params -AutomationAccountName $AutomationAccountName } #lancement du runbook StopVM if($VMsToStop.count -gt 0){ $params = @{"AzureCredentialName"=$AzureCredentialName;"SubscriptionId"=$SubscriptionId;"VMList"=$VMsToStop} Start-AzureAutomationRunbook -Name "StopVM" -Parameters $params -AutomationAccountName $AutomationAccountName } }
Ce dernier runbook effectue une requête sur la table SQL pour ensuite la liste des machines virtuelles qui doivent être allumées et celles qui doivent être éteintes. La sélection « select AzureVmNamePattern from Calendar where getdate() between StartDate and EndDate » permet d’obtenir les modèles de nom de machines qui doivent être allumées à la date d’exécution. Encore une fois, nous utiliserons un paramètre de type Credential pour stocker le nom d’utilisateur et le mot de passe pour l’accès à la base de données.
A partir du résultat (stocké dans la variable $result), le script détermine la liste des machines virtuelles à démarrer et celles à éteindre.
Vous pouvez alors exécuter ce runbook avec les paramètres suivants :
- DbAddress : adresse du serveur de base de données SQL Azure,
- DbName : nom de la base de données,
- CalendarDbCredential : nom des informations d’identification lié au compte d’utilisateur SQL,
- SubscriptionId : ID de la souscription Azure,
- AutomationAccount : nom du compte Automation qui héberge les runbooks développés.
Par exemple, au cours de mon exécution, le script détecte que les machines « bts-dev » et celles dont le nom commence par « devlyi » ne sont pas démarrées. Ces machines sont ajoutées à la liste VMsToStart et le runbook StartVM est alors appelé avec ces paramètres, via la commande « Start-AzureAutomationRunbook ».
Bien entendu, cet article se focalise sur l’avantage de l’automatisation, qu’il est donc nécessaire de mettre en place. Il faut tout d’abord créer une planification pour le runbook CalendarCheck.
Veillez à utiliser des paramètres adaptés à votre besoin, notamment la fréquence pour laquelle on exécute la vérification.
Enfin, les paramètres d’appel doivent être renseignés pour cette tâche planifiée.
C’est terminé! Le runbook va automatiquement démarrer et arrêter les machines virtuelles en fonction des entrées du Calendrier.
L’effort de mise en place n’est pas énorme comparé aux économies à faire, surtout si vous prévoyez de profiter des avantages du Cloud!
Bien entendu, les scripts fournissent une base de ce qu’il est possible de faire, il existe des optimisations et des adaptations en fonction du cas à traiter. A vous de jouer! 🙂
Dommage de ne pas avoir décrit la partie relative à l’ajout de l’utilisateur et des droits à associer pour executer les RunBook.
En effet, j’ai perdu la matinée à trouver une solution qui consiste à ajouter un utilisateur dans AzureAD en tant que Co-Administrateur de la subscription pour que ca fonctionne…
Je doute que ce soit la solution la plus optimisée niveau droit de sécurité mais bon…
Tous les tutoriaux que j’ai trouvé se reportait à Classic Portal (et on ne peut plus gérer automation dans Classic Portal dans mon compte).