Desired State Configuration (DSC) : les ressources

Dans l’article précédent “Intro“, nous avons introduit DSC dans les grandes lignes. Après avoir survolé les notions de base de cette technologie, nous avons vu les pré-requis pour appliquer une configuration à un ensemble de nœuds distants.
Dans cet article nous allons nous intéresser aux Ressources DSC, du point de vue du fonctionnement et de l’extensibilité.

Les ressources DSC c’est quoi ?

Une ressource DSC se matérialise principalement par deux fichiers PowerShell. Le premier représente le module, le deuxième représente le schéma qui lui est affecté.
Le module :
On y trouve trois fonctions (on parle de function au sens PowerShell) :
Function Get-TargetResource
Function Set-TargetResource
Function Test-TargetResource
Rappelez-vous que DSC est une technologie idempotent, ce qui signifie qu’on peut lancer autant de fois que l’on souhaite un script DSC sans impact sur le résultat attendu. Par exemple, vous développez un script qui crée un site IIS, vous lancez une première fois, le site est créé.  Si vous lancez ce script une deuxième fois, vous aurez certainement une erreur indiquant que le site web existe déjà, il faut donc modifier le script pour vérifier au préalable que le site n’existe pas, s’il existe on ne fait rien, sinon on le crée.  DSC vous permet, du fait d’être idempotent, de vous affranchir complètement de cette logique vérificative et répétitive.
Cela est rendu possible par la manière dont s’enchaînent les appels vers les fonctions citées ci-dessus.  En effet, la première fonction appelée est Get-TargetRessource suivi non pas du Set-TargetRessource mais de Test-TargetRessource. Pourquoi ? Parce qu’on souhaite d’abord tester la configuration avant de l’appliquer, logique !

Exemple de ressources

Les ressources DSC se trouvent par défaut à l’endroit suivant :
C:\Windows\System32\WindowsPowerShell\v1.0\Modules\PSDesiredStateConfiguration\DSCResources
Intéressons-nous, à titre d’exemple, à la ressource MSFT_UserResource
Dans le répertoire dédié à cette ressource on retrouve les deux fichiers mentionnés ci-dessus, à savoir le module et son schéma associé.

Si on ouvre le fichier MSFT_UserResource installé par défaut dans la machine, cette ressource permet de créer un User. On y trouve en effet les trois fonctions (Get-TargetResource, Set-TargetResource et le Set-TargetResource).

La fonction Get-TargetResource effectue une vérification sur le user, assigne et retourne les valeurs des paramètres d’entrée utilisés dans les autres fonctions (Test et Set).

Les fonctions Test et Set utilisent à leur tour ces paramètres, dans les appels via le Local Configuration Manager, lors de l’exécution.  On retrouve par ailleurs dans les fonctions Test et Set les différents appels vers les cmdlet PowerShell pour tester l’existence et créer l’utilisateur.

Le deuxième fichier, compris dans le même répertoire, représente le schéma associé à la ressource.  Ce fichier contient principalement la spécification des paramètres de la ressource DSC ainsi que les contraintes (exemple: le paramètre Ensure ne prend que les valeurs “Present” ou “Absent”).

Extensibilité des ressources DSC

Hormis les ressources disponibles sur le serveurs, il est tout à fait possible d’étendre ces ressources pour répondre à des besoins plus spécifiques.
Microsoft publie quelque modules regroupant certaines ressources DSC via la technet gallery, en voici un exemple : http://gallery.technet.microsoft.com/scriptcenter/xDatabase-PowerShell-0db6cdaf
Ce module appelé xDatabase (x pour expérimental) regroupe deux ressources DSC, à savoir xDatabase et xDBPackage.  Pour utiliser ses ressources, il faut donc les télécharger et les décompresser vers le répertoire: C:\Windows\System32\WindowsPowerShell\v1.0\Modules
Dès lors, les ressources sont utilisables via un script DSC.
A noter qu’en fonction du mode de fonctionnement DSC choisi, la copie des fichiers de ressources DSC  peut être obligatoire ou pas.  En effet, en mode Push les fichiers de ressources DSC doivent être copiées sur chacun des nœuds.  En revanche, en mode Pull, les fichiers doivent être copiés uniquement sur le serveur principal, en effet les nœuds effectuent un Pull des ressources nécessaires au moment de l’exécution, via l’appel au web service, aucune copie locale n’est donc requise dans cas.
Une autre façon d’étendre les ressources DSC est d’en créer. Pour ce faire,  Je vous propose de créer une simple ressource DSC qui, à titre d’exemple, va assurer qu’une application pool IIS s’exécute avec une version spécifiée du Runtime .NET.
Nous allons donc créer deux fichiers, un représentant le module, le second sera le schéma associé.  Ces deux fichiers sont dans un répertoire qu’on appellera AppPoolNETVersion et qui sera copié vers le chemin suivant :
C:\Windows\System32\WindowsPowerShell\v1.0\Modules\PSDesiredStateConfiguration\DSCResources

AppPoolNetVersion.schema.mof :

AppPoolNETVersion.psm1



Globalement, on vérifie dans le Test-TargetResource si la version courante correspond à la valeur attendue, sinon LCM appelle le Set-TargetResource qui assigne le VersionNumber à la propriété managedRuntimeVersion de l’application pool $AppPoolName
Voici le script DSC :

IIS Avant :

On exécute le script :

IIS Après :

La propriété a été modifiée, Epic!

Conclusion

En résumé, dans cet article nous avons vu comment fonctionnent les ressources DSC et ce qui les rend indempotent.  Nous avons également vu comment étendre les ressources disponibles dans le serveur avec celles proposées par Microsoft, et comment on peut écrire nos propres ressources DSC.