Etant devenu depuis quelques temps utilisateur d’Azure pour mes machines de développement SharePoint 2013 (cf. mon précédent article sur le sujet), l’étape suivante consiste à limiter la consommation inutile de celles-ci. En effet, maintenant que la consommation des machines n’est plus décomptée quand elle est dé-provisionnée, les économies peuvent être substantielles.

Petit exemple avec une instance A5 :

• Tarif horaire : 0,298€
• Soit pour un mois : 31*24*0,298 = 221,72€
• En retirant les WE (disons 8j pour simplifier), et en tablant sur une utilisation d’une dizaine d’heure par jour (9h – 19h par ex.), cela nous ramène à 23*10*0,298 = 68,54€, soit environ 31% du prix d’un mois plein !

Dans le même ordre d’idée, pour une instance A4 (XL) :

• Tarif horaire : 0,537€
• Mois plein : 399,54€
• En utilisant la même formule (usage “réel”) : 123,51€

Evidemment, vous pourriez trouver moins cher en cherchant chez des hébergeurs à tarifs compétitifs, mais ici le gros avantage c’est que vous ne payez que ce dont vous avez besoin ! Vous ne faites en effet peut-être pas de développement tous les jours ! (et sans doute pas pendant vos vacances, quoi que ).

Personnellement, j’ai un usage mixte entre des machines virtuelles en local et une machine principale dans Azure pour les plus gros développements. De plus, pour les détenteurs d’un compte MSDN, vous pouvez bénéficier jusqu’à 115€ de crédits Azure par mois, ce qui permet de couvrir les frais de cette machine virtuelle.

Voilà pour le chapitre tarification et le pourquoi de l’article : économisez ! (mon côté fourmi). L’idée est donc d’automatiser l’arrêt des machines quand nous n’en avons pas besoin, voire le démarrage automatique pour qu’au petit matin, quand vos mains se posent sur votre clavier usés par les lignes de C# que vous avez écrites, votre machine est disponible et prête à l’emploi. Il faut en effet toujours compter quelques minutes pour le provisioning de la machine, puisque nous sommes ici dans un cas de désallocation et non de simple arrêt (ce dernier vous faisant toujours décompter des crédits).

J’appelle donc notre meilleur allié dans ces cas-là : PowerShell.

1. Installer les prérequis

Vous devrez  tout d’abord télécharger et installer le pack “Windows Azure PowerShell”, disponible à l’adresse suivante : http://www.windowsazure.com/fr-fr/downloads/#cmd-line-tools

2. Initialiser votre environnement

Tout d’abord, récupérez vos paramètres de publication Azure (le fichier xxx-credentials.publishsettings) en vous rendant sur https://windows.azure.com/download/publishprofile.aspx. Nous aurons besoin de ce fichier pour pouvoir se connecter à notre environnement Azure. Afin de scripter plus facilement, j’ai renommé le fichier de paramètres en [nom de l’instance]-credentials.publishsettings (vous verrez peu après pourquoi).

Autorisez ensuite l’exécution de script (http://technet.microsoft.com/fr-fr/library/ee176961.aspx), car par défaut PowerShell est en mode restrictif. Pour cela, lancez une commande Azure et tapez :

Set-ExecutionPolicy RemoteSigned

Vous n’aurez à le faire qu’une seule fois sur votre machine.

3 . Préparez vos scripts PowerShell :

Créez 2 fichiers “StartVM.ps1” et “StopVM.ps1”.

Copiez le contenu suivant dans StartVM.ps1 :

param([String] $serviceName, [String] $instanceName)

$curLocation = get-location
$configPath = $curLocation.Path + "\"

$credFile = $configPath + $instanceName + "-credentials.publishsettings"
$rdpFile = $configPath + $instanceName + ".rdp"

Write-Host "Execution de la VM $instanceName du service $serviceName"

Import-Module 'C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\Azure\Azure.psd1'
Import-AzurePublishSettingsFile $credFile 

$instanceInfo = Get-AzureVM -ServiceName $serviceName -Name $instanceName 

Write-Host "VM " $instanceInfo.InstanceName " is " $instanceInfo.PowerState

if ($instanceInfo.PowerState -ne "Started") 
{
    Write-Host "Démarrage de la VM $instanceName du service $serviceName"
    Start-AzureVM -ServiceName $serviceName -Name $instanceName 
}


Write-Host "Récupération du fichier de connexion RDP"

Get-AzureRemoteDesktopFile -ServiceName $serviceName -Name $instanceName -LocalPath $rdpFile

Et celui-ci dans StopVM.ps1 :

param([String] $serviceName, [String] $instanceName)

$curLocation = get-location
$configPath = $curLocation.Path + "\"

$credFile = $configPath + $instanceName + "-credentials.publishsettings"

Import-Module 'C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\Azure\Azure.psd1'
Import-AzurePublishSettingsFile $credFile 

Write-Host "Extinction de la VM $instanceName du service $serviceName"

Stop-AzureVM -ServiceName $serviceName -Name $instanceName -Force

En résumé :

• On va passer en argument le nom du service Azure et le nom de l’instance concernée ($serviceName et $instanceName).
• On va chercher notre fichier de publication dans le répertoire courant portant le nom de l’instance suffixée par “-credentials.publishsettings” que l’on passe après le chargement du module Azure pour charger les paramètres.
• Dans le cas du démarrage, on vérifie l’état de la machine, si elle n’est pas démarrée, on s’en occupe. Et cerise sur le gâteau, on récupère aussi le fichier RDP qui va bien pour se connecter sur l’instance.
• Dans le cas de l’extinction, rien de spécial, sauf que l’on passe le paramètre “-Force” pour effectuer la désallocation de la machine, sinon elle sera simplement arrêtée (http://msdn.microsoft.com/en-us/library/jj152831.aspx). La principale différence réside dans le fait que l’IP interne de la machine pourra être réinitialisée dans le cas de la désallocation, puisqu’il n’y a plus aucune ressources associées à ce moment là.

4. Exécution !

Maintenant que l’on a le nécessaire, ya plus qu’à !

Pour cela, j’utilise 2 fichiers “.cmd”, l’un pour démarrer, l’autre pour arrêter la machine, l’idée ici étant de lancer PowerShell avec les bons paramètres. Exemple pour “StartVM-DEV.cmd” :

Powershell.exe -File ".\StartVM.ps1" -serviceName MonServiceCloud -instanceName MonInstanceDeVM
pause

Vous pourrez évidemment virer la pause une fois que vous serez certain du bon fonctionnement de vos scripts.

Petit rappel en passant : le nom du service = nom de l’alias DNS (pour faire simple, c’est donc nomduservice.cloudapp.net) nom de l’instance = nom de la machine tel qu’elle apparait dans l’administration des machines virtuelles.

5. Aller plus loin

Comme je vous le disais en préambule, on peut pousser le raisonnement un peu plus loin. Pour cela, il suffit de créer des tâches planifiées sur une de vos machines ou un serveur disponible et qui appellera vos scripts à certaines heures données, et donc a minima de forcer l’extinction en soirée, mais aussi de démarrer la machine de bon matin en semaine.

En espérant vous avoir donné envie de sauter le pas, à vous de jouer !