Desired State Configuration : Introduction

Dans ce premier billet nous allons introduire un outil faisant partie de PowerShell v4 et Windows Management Framework Desired State Configuration.

Que fait cet outil et pourquoi je dois m’y intéresser?

Il y a quelque temps je devais intervenir chez un client pour installer une application web.  J’arrive donc avec mon MSI et mes scripts, je commence mon déploiement sur le premier serveur next next finish, tout va bien.  Je passe au deuxième, je lance le MSI d’installation et là…le drame. Une mystérieuse erreur Windows est survenue. Après de longues heures d’investigation j’ai fini par m’apercevoir que le Framework .NET 3.5 n’a pas été installé sur cette machine, ce qui faisait planter le MSI.  Un simple oubli qui nous avait coûté une bonne journée.

Dans une démarche DevOps, dont le but est d’accroître l’efficacité entre le développeur et l’administrateur, ce genre d’erreur peut s’avérer très coûteux et par conséquent pénalisant pour le projet.  Il est donc nécessaire de mettre en place un mécanisme garantissant la configuration identique sur toutes les machines d’un environnement, et ce de manière automatisé.  Il existe bel et bien un outil qui permet de le faire, il s’appelle Desired State Configuration.

Comment fonctionne Powershell DSC?

DSC repose sur trois éléments et deux modes de fonctionnement.  Les trois éléments sont:

• Un script PowerShell pour décrire une configuration.  Cette configuration fait référence à des ressources, qui ne sont d’autres que des modules PowerShell
• Un langage intermédiaire (MOF: Managed Object Format)
• Un composant d’exécution (LCM: Local Configuration Manager)

Deux modes de fonctionnement, push et pull.

Push: on se place sur un serveur on écrit le script DSC on le lance sur une liste de machines (les nœuds)

Pull: on se place sur un serveur, on écrit le script DSC on crée un service web, les nœuds font appel à ce service pour récupérer le script DSC ainsi que les ressources manquantes, chaque machine se charge ensuite d’exécuter la configuration.

Show me the code

Voici un exemple d’une simple configuration DSC qui permet de s’assurer que le module IIS est installé (j’utilise PowerShell ISE pour éditer le script):

1. Dans un premier temps on écrit le script DSC décrivant la configuration.  Cette configuration s’applique au nœud “localhost”.  Sur ce nœud on fait appel à la ressource WindowsFeature, qui active la feature “Web-Server”.   Le nom de la ressource, en l’occurrence IIS importe peu, j’aurai bien pu l’appeler “Bob”.   La déclaration de la ressource nécessite la spécification de ses propriétés, et notamment la propriété Ensure qu’on retrouvera dans un bon nombre d’autres ressources DSC.  Cette propriété peut prendre deux valeurs possibles (“Present”,”Absent”).  “Present” signifie dans cet exemple que la feature “Web-Server” doit être installé, “Absent” signifie le contraire.  On spécifie également le “Name” de la feature Windows qu’on souhaite installer, Web-Server pour IIS
2. Ensuite on fait appel à la configuration “mySimpleExample” au même titre qu’un appel d’une fonction classique PowerShell , à vrai dire la configuration DSC est une fonction PowerShell.  Cet appel va générer par la suite un fichier d’extension MOF (Managed Object Format).  Le MOF est un format standard cross-platform dont le but est de faire le lien entre le script DSC et un processus qui va s’occuper de l’exécution des opérations, ce processus s’appelle LCM (Local Configuration Manager).  Pour faire une analogie avec le .NET, on peut effectivement comparer le script DSC à un langage de programmation (C#, VB.NET…etc), le MOF est le MSIL et le LCM sera le .NET runtime

Voici le fichier MOF généré:

3. Enfin, La commande Start-DSCConfiguration déclenche l’appel vers le LCM avec comme input le fichier MOF généré dans l’étape précédente, et en voici l’output:

IIS est donc installé sur la machine.

Résumons:

Première étape, on rédige le script DSC en décrivant les nœuds, les ressources et les propriétés.  Deuxième étape, on fait appel à la configuration pour générer le .mof et finalement on appelle Start-DSCConfiguration pour déclencher le LCM.

Un point important, afin de tester ce script sur plusieurs nœuds, vous devez bien évidement spécifier les noms des différentes machines dans la directive Node

Exemple: Node (“localhost”,”madeuxièmemachine.mondomaine.com”)

Voici quelque points d’attention pour pouvoir exécuter le script DSC sur une ou plusieurs machines distantes.  Sur la machine distante, il faut donc effectuer les étapes suivantes:

1. Enable-PSRemoting
2. Set-SignedPolicy RemoteSigned
3. Le Service WinRM utilise les ports par défaut HTTP/5985 et HTTPS/5986, il faut donc soit s’assurer que les ports sont ouverts soit en modifiant la configuration WinRM, soit en ouvrant les ports
4. Activer les fonctionnalités WinRM, pour ce faire ouvrir une console Group Policy Edit

Run –> gpedit.msc –> Adminisitrative Templates –> Windows Components –> Windows Remote Management (WinRM)

5.    Activer le TrustedHost et spécifier le nom des machines pouvant lancer des sessions PS à distance.

Conclusion

Comme on vient de voir, DSC est un outil qui permet de réduire considérablement le temps de configuration des machines, il a également l’avantage de garantir une configuration unique et standard pout toutes les machines dans un environnement spécifique.  Il repose sur une architecture simple à la fois en mode Push et Pull et offre un langage de description intuitif.

Dans la deuxième partie de cette série, nous allons nous pencher sur le ressources DSC et leur fonctionnement, nous verrons également comment paramétrer un script DSC.

Happy scripting!