Gérer la configuration des machines virtuelles avec Azure Automation et PowerShell DSC
Gérer la configuration des machines virtuelles avec Azure Automation et PowerShell
DSC
La gestion de multiples machines virtuelles impose de
trouver des solutions pour gérer de façon centralisées les
configurations : installer des serveurs applicatifs, ouvrir des ports de
pare-feu, paramétrer le fuseau horaire etc.
Azure Automation
Afin d’automatiser autant des tâches métier (envoi d’email
par exemple) ou techniques (démarrage / extinction de VM), Microsoft fourni sur
Azure le service nommé « Automation » qui permet d’exécuter des
scripts PowerShell selon des planifications.
Dans Azure vous pouvez créer un ou plusieurs comptes d’automatisation.
Ces comptes sont gratuits jusqu’à X minutes d’exécution puis une tarification à
la minute est appliquée.
Les comptes vont permettre également de stocker des
informations importantes pour vos scripts que vous ne voulez pas mettre en
clair : identifiants (par exemple pour envoyer des emails via office 365)
et variables.
PowerShell Desired State
Configuration (DSC)
Windows Server supporte, depuis la version 2012 et Powershell 4.0, la technologie
« PowerShell DSC » : un serveur référence des configurations (le
format est PowerShell), les clients s’y connecte, choisis sa configuration, son
nœuds dans la configuration et l’applique à intervalle régulier.
Configuration
Un fichier de configuration à cette forme :
En enchainant les paramétrages on va être en mesure
d’automatiser un grand nombre de manipulations sur les VM.
Nœuds de configuration
La configuration va nécessiter en entrée des informations
pour générer les nœuds de configuration. Ces nœuds sont descriptibles en
PowerShell :
Ici une VM pourra donc récupérer la configuration
« Ctoutvert_DSC.secureholiday_iis » ou
« Ctoutvert_DSC.secureholiday_sql ».
Conditions
Les VM « secureholiday_iis » et
« secureholiday_sql » n’auront évidemment pas le même contenu. Il
faudra donc dans la déclaration de configuration mettre des conditions pour
avoir des paramétrages adaptés.
Pour ce faire on va rajouter des informations à notre
déclaration des nœuds :
Dans la configuration on va
ajouter des conditions :
Plutôt que utiliser des
« Roles » on peut également utiliser des booléens pour combiner les
configuration : « IsWebServer » et « IsSQLServer ».
Dans notre utilisation du cloud Azure nous préférons affecter des rôles unique
à chacun de nos serveurs pour faciliter la mise à l’échelle, optimiser nos
coûts et rendre notre architecture plus claire (Single Responsibility Principle
appliqué aux serveurs).
Types de paramétrages
Les « TypeParametrage » et « AutreTypeParametrage »
ne sont que des exemples pour remplir mon code. Microsoft fourni des
paramétrages, voici une liste des paramétrage que l’on utilise :
xDSCDomainjoin
Permet de joindre la VM à un domaine Active Directory :
“XX.com” est le domaine active directory
$adminCredentials contient des informations
d’authentification d’un administrateur du domaine, on les récupère via la
méthode « Get-AutomationPSCredential » de Azure Automation permettant
de récupérer des informations d’authentification stockées de manière
sécurisées.
xTimeZone
Permet de changer le fuseau horaire de l’horloge d’une VM.
On passe donc le nom du fuseau horaire (ici celui de Paris).
cChocoInstaller
Permet d’installer l’utilitaire de gestionnaire de package de Windows « Chocolatey ». Pour avoir accès à ce type de paramétrage, il faut installer le module « cChoco » dans le compte d’automatisation.cChocoPackageInstaller
Permet d’installer un package chocolatey (chocolatey.org).
On installe donc le package
“googlechrome” qui sera mis à jour automatiquement. Grâce à la valeur
« DependsOn » on déclare que ce paramétrage ne sera lancé que lorsque
la tache installChoco du type cChocoInstaller sera passée.
WindowsFeature
Ce paramétrage permet d’installer des fonctionnalités de
windows (Wizard “Add Roles And Functionnality”)
On demande l’installation de la fonctionnalité « Web
Server » (IIS) de Windows Server ainsi que toutes les fonctionnalités
enfants tel que ASP.Net, ASP classique ou le suivi des requêtes en cours.
On peut également vérifier qu’une fonction n’est pas
installée en passant le « Ensure » à « Absent », ce qui est
pratique pour supprimer des fonctionnalités installées par défaut sur Windows.
User / GroupSet
Ces deux paramétrages permettent de créer des utilisateurs
et de les affecter à des groupes.
Pour centraliser nos
configurations de IIS on utilise un Azure File Share. Afin de permettre à II de
s’y connecter, il faut créer un utilisateur local qui aura les mêmes
informations d’authentification que le partage de fichier Azure. Cet
utilisateur doit également être dans le groupe local « IIS_IUSRS »
pour avoir tous les accès nécessaires sur la machine locale.
Script
Les paramétrage scripts permettent de lancer des scripts
PowerShell personnalisé. Cela permet de créer ses propre paramétrage quand ce
dont on a besoin n’est pas fourni par Microsoft ou autre.
Ce script permet d’installer
le Soap SDk de Microsoft (utilise par l’asp Classique pour faire des appels
Soap) dont on a stocké le msi sur un partage de fichiers. La déclaration est en
3 partie :
-
TestScript :
retourne $true si la configuration est ok (ici je vais chercher dans les
logiciels installés)
-
SetScript :
exécuté pour mettre en place le paramétrage
-
GetScript :
utilisé pour du renvoyer l’état actuel
On utilise AzCopy pour copier
le msi depuis le partage.
Le paramétrage de type
« Package » permet également de faire ça, mais les msi n’ont pas de
tag ProductVersion et ProductName. De plus ces msi ne sont plus disponible sur
les sites de Microsoft.
xFirewall
xFirewall
Permet de créer des règles de firewall. Windows en ouvre
certaines lors de l’installation de logiciels (IIS, SQL Server) mais d’autres
sont à ouvrir à la main.
Ici on ouvre 3 ports pour
l’accès en passif à notre serveur FTP.
Automatisation / Publication
Une fois le fichier de configuration et la déclaration des
nœuds, il faut envoyer ces informations à Azure Automation, connecter Azure
Automation aux VM et connecter les VM à leur nœud de configuration.
Publication sur Azure automation
Cette publication peut se faire depuis l’interface portail,
mais il vaut mieux le faire en PowerShell étant donné qu’on peut être emmené
(surtout au début) à y effectuer de nombreuses modifications.
La publication se passe en 2 phases : l’envoi du
fichier de configuration (« configuration Ctoutvert_dsc {} ») et sa
compilation selon la déclaration des nœuds.
Connection d’Azure Automation aux VM
La connexion de la VM au compte d’automatisation se fait via
l’installation d’une extension de machine virtuelle Azure.
Dans le compte d'automatisation Azure :
- Menu gauche : "DSC Nodes"
- "Add Azure VM"
- Cliquez sur la VM
- "Connect"
Cela va prendre quelques minutes et votre VM apparaitra dans la partie "DSC Nodes".
Assignation des configurations
- Dans le menu "DSC Nodes" cliquez sur la VM
- "Assign node configuration"
- Sélectionnez la configuration
Commentaires
Enregistrer un commentaire