Déploiement automatisé d’une configuration SQL hautement disponible dans Azure : Première étape d’une démarche "Devops"
J’ai récemment déployé une infrastructure SQL Server 2012 hautement disponible (« Always On ») sur les services d’infrastructure Azure (IaaS). Plutôt que d’y consacrer les nombreuses heures de configuration manuelle requises, j’ai préféré utiliser les Windows Azure PowerShell Cmdlets.
Cette démarche a été grandement facilitée par la récente publication de scripts d’installation et de configuration de ferme SharePoint dans le référentielWindows Azure PowerShell Samples GitHub et par les récentes mises à jour concernant ce type de configuration sur lesquelles j’ai déjà eu l’occasion de communiquer.
Quelques modifications du code Powershell mis à disposition suffisent en effet pour atteindre l’objectif que je m’étais fixé :
• Suppression des quelques lignes spécifiques à SharePoint dans le fichier PowerShell «autoconfigure.ps1»
• Modification de l’image de l’OS de référence pour SQL 2012 (je ciblais Windows Server 2012, alors que la version initiale déployait les machines virtuelles SQL Server 2012 sur Windows Server 2008 R2).
Extrait du fichier Modification du fichier autoconfigure.ps1 :
functionSetSQLConfiguration
{
param($configPath,$serviceName,$storageAccount,$subscription,$adminAccount,$password,$domain,$dnsDomain)
#$sql2k12img = (GetLatestImage "SQL Server 2012 SP1 Enterprise On Win2K8R2")
$sql2k12img= (GetLatestImage"SQL Server 2012 SP1 Enterprise On Win2012")
….
functionGetLatestImage
{
param($imageFamily)
$images=Get-AzureVMImage|where { $_.ImageFamily -eq$imageFamily } |Sort-Object-Descending-PropertyPublishedDate
return$images[0].ImageName
}
• Ecriture d’un script de désinstallation (fort pratique lorsqu’il s’agit de supprimer un Cloud Service, 5 VMs, 13 Disques et fichiers de stockage associés, 1 VNET)…
Import-AzurePublishSettingsFile'C:\DEMOS\21 - CLOUD\AZURE\Azure Keys\azure.publishsettings'
Get-AzureSubscription-Current
Get-AzureDeployment–ServiceName"SQLHigh"|Remove-AzureDeployment
Remove-AzureService-ServiceName"SQLHigh"
$disks=Get-AzureDisk|Where {$_.DiskName -Match"SQLHigh-*"}
$disks|ForEach-Object {
Write-Host"deleting"$_.DiskName -foregroundcolorcyan
Remove-AzureDisk-DiskName$_.DiskName -DeleteVHD
}
Le code est lancé directement depuis la console Windows PowerShell ISE en tant qu’administrateur.
Avant de lancer le script, il faut prendre soin au préalable de :
• Configurer Powershell pour importer les CmdLets Azure avec la commande :
« Import-Module C:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\Azure\Azure.psd1 »
• Importer les informations permettant d’authentifier les accès sur la souscription Azure (notamment la référence au certificat présent sur la machine cliente et déclaré dans le portail Azure).
https://manage.windowsazure.com/publishsettings/index?client=vs&schemaversion=2.0
« Import-AzurePublishSettingsFile "C:\DEMOS\21 - CLOUD\AZURE\Azure Keys\azure.publishsettings" »
• S’assurer que sa souscription dispose de suffisamment de quota pour créer les VMs : « Get-AzureSubscription –ExtendedDetails »
• Déléguer les accès depuis la machine cliente pour permettre l’automatisation de la configuration des serveurs distants (« multi-hop WinRM ») :
Activation de l’option CredSSP : « enable-wsmancredssp -role client -delegatecomputer "*.cloudapp.net" »
Activation de délégation d’identité dans l’éditeur de stratégie de sécurité du PC, dans le menu « Computer Configuration -> Administrative Templates -> System -> Credentials Delegation »
Activation de l’option « Allow Delegating Fresh Credentials with NTLM-only server authentication »
Ajout de « AWSMAN/*.cloudapp.net » dans la section « Add Servers »
• Spécifier la taille des instances pour chaque type de VM dans les fichiers XML présents dans le répertoire \config.
Une fois le script exécuté, les cinq machines virtuelles VMs sont instanciées et visibles dans le portail Azure.
Les « Availability Groups » sont également automatiquement configurés sur les serveurs SQL 2012.
Au-delà du gain de temps que m’ont apporté ces scripts Windows Azure PowerShell Samples GitHub, j’ai particulièrement apprécié la façon dont ils ont été implémentés. En effet, le script « master-deployment-script.ps1” crée les instances des machines Active Directory et SQL Server en se fondant sur un modèle de configuration XML spécifié dans le script. Plutôt que de proposer un script avec un degré de variabilité de la topologie obtenu par une declaration présente directement dans le script powershell, l’approche retenue dans l’implémentation de ces scripts est d’offrir un niveau d’abstraction supplémentaire en associant aux scripts PowerShell génériques des fichiers XML externes décrivant le modèle de topologie ciblée.
Ainsi, la méthode “AutoConfigure” permet de personnaliser l’environnement en spécifiant le nom du modèle (TemplateName : exemple « SQLHighlyAvailable », la localisation du Data center cible pour la création des VMs et du Virtual Network, le nom du Cloud Service,…) :
AutoConfigure-TemplateName"SQLHighlyAvailable"-Location"West Europe"-ServiceName"SQLHigh"-ScriptFolder$scriptFolder-SubscriptionName"stephgouInTheCloud" -StorageAccountName"stephgouvmstorage"-adminAccount"stephgou"–adminPassword"######"-domain"STEPHGOU"-dnsDomain"stephgou.demo.com"
Cette approche de « provisioning d’infrastructure fondé sur un modèle » s’inscrit, à un degré plus basique, dans une démarche que l’on pourrait comparer à celle que propose le PaaS Azure avec les fichiers « Azure Service Definition Schema (.csdef) » et « Windows Azure Service Configuration Schema (.cscfg) » ou les « Services templates » de System Center 2012.
L’idée ne date pas d’hier (Mars 2004) : Dynamic Systems Initiative et les System Definition Model (SDM). Le principe est d’intégrer les spécifications d'exploitation dans celles de l'application de sorte que l'automatisation du déploiement de l'application et de sa supervision puissent fait partie des livrables. Puisque ces spécifications sont généralement déclarées pour chaque application déployée, leur définition fait partie de la conception de l'application elle-même.
Afin d'éviter que le code d’une application soit étroitement couplé à un profil d'infrastructure spécifique, des "blueprints" sont associés aux applications précisant les « règles », descriptives ou prescriptives, ainsi que les paramètres d'entrée qui permettent aux services cloud de connaître les actions à effectuer au nom de l'application. Ces stratégies sont délivrées aux services cloud via des API bien définies et directement corrélées aux profils de services d'infrastructure que propose Azure afin de configurer un ensemble d'instances et les différentes ressources connexes. Un autre exemple d’outillage associé à ce type de démarche est Chef Opscode, utilisé pour automatiser le déploiement d'une infrastructure Azure et pouvant être déclenché pour appliquer des « recettes » (recipes) qui se rapportent à des événements spécifiques dans la gestion du cycle de vie de l'application.
De plus en plus, les infrastructures vont dépendre du code, au même titre que les applications qu’elles hébergent. Le Cloud ne fait qu’amplifier cette tendance. L’utilisation de modèles de « provisioning » d’une application et de son infrastructure sous-jacente permet ainsi de briser le fameux « Wall of Confusion » qui sépare les équipes de développement des équipes d’administration des systèmes et réseaux.
En permettant une intégration plus étroite entre les deux disciplines, cette pratique contribue à rendre plus efficace la collaboration entre les équipes de développement et les responsables opérationnels d'une organisation, et s’inscrit donc totalement dans une démarche DevOps.