Powershell DSC: Modification d’une ressource DSC existante

Dans cet article nous allons voir comment modifier une ressource DSC afin de l’adapter à nos besoins.

Pour rappel, une ressource DSC est un module qui permet de définir des configurations. Par exemple, la ressource xDisk permet d’initialiser et formater un volume et le rendre disponible avec une lettre donnée:

La ressource définit le numéro du disque à gérer (le disque 2 dans l’exemple), et la lettre avec laquelle on veut le rendre disponible (G).

Toute la gestion pour rendre le volume disponible, l’initialisation et le formatage (la partie impérative donc) est gérée sans qu’on ait à s’en soucier.

En fait si, on va s’en soucier. xDisk a été écrit pour Azure, et je voudrais le modifier car j’ai remarqué que le formatage du volume ne fonctionne pas sur mes serveurs.

Et j’ai aussi remarqué que la version 1.0 que j’ai essayée veut absolument redémarrer mon serveur cible….en boucle.

Alors allons modifier tout ça.

Toutes les ressources disponible dans le Resource Kit de Microsoft sont Open Source. Et Microsoft indique (à peu près une fois par page lue) ceci :

When making changes to these resources, we suggest the following practice:

  1. Update the following names by replacing MSFT with your company/community name and replacing the « x » with « c » (short for « Community ») or another prefix of your choice:
    • Module name (ex: xDisk becomes cDisk)
    • Resource folder (ex: MSFT_xDisk becomes Contoso_xDisk)
    • Resource Name (ex: MSFT_xDisk becomes Contoso_cDisk)
    • Resource Friendly Name (ex: xDisk becomes cDisk)
    • MOF class name (ex: MSFT_xDisk becomes Contoso_cDisk)
    • Filename for the <resource>.schema.mof (ex: MSFT_xDisk.schema.mof becomes Contoso_cDisk.schema.mof)
  2. Update module and metadata information in the module manifest
  3. Update any configuration that use these resources

We reserve resource and module names without prefixes (« x » or « c ») for future use (e.g. « MSFT_Disk » or « MSFT_ADUser »). If the next version of Windows Server ships with a « Disk » resource, we don’t want to break any configurations that use any community modifications. Please keep a prefix such as « c » on all community modifications.

Donc on doit renommer tous les fichiers dans l’arborescence de xDisk. Ainsi on sera conforme.

On renomme tous les fichiers et on remplace xDisk par cDisk, et MSFT par autre chose. Une fois que l’arborescence a été renommée on peut s’attaquer aux modules de metadonnées:

Le premier est cDisk.psd1:

Surtout bien remplacer le GUID qui identifie le module de façon unique.

Pour avoir un nouveau GUID utiliser la classe [guid] ainsi:

Ensuite dans le sous-répertoire DSCResources pour chaque ressource nous devons modifier le fichier MOF, par exemple le fichier BALLADELLI_cDisk.schema.mof. (comme je n’ai pas d’imagination et que Contoso est déjà pris, j’ai utilisé mon nom pour remplacer MSFT).

Et finalement on peut s’attaquer au module qui contient le code, dans mon cas: BALLADELLI_cDisk.psm1

Cette version de cDisk se focalise surtout sur la partie Set-TargetResource et ajoute le formatage à la suite de New-Partition directement avec un pipe (|).

On règle un petit souci car le code original ne pouvait fonctionner que si le volume était RAW. Et finalement enlève la demande de reboot car il y en a pas besoin.

Pour info dans Powershell DSC une demande de reboot s’écrit ainsi:

Un excellent moyen de tester le module est de le copier sur une machine cible de test, et de l’exécuter en local. Ainsi on s’évite toute la partie configuration à télécharger etc. ce qui peut prendre du temps si on doit résoudre des problèmes dans le code.

Une chose à savoir lorsqu’on crée ou on modifie une ressource DSC est que la fonction doit être idempotente. Ceci veut dire que si on exécute la fonction plusieurs fois, on doit toujours avoir le même résultat. Nous devons toujours nous assurer que c’est le cas, et le tester. Car si une ressource exécutée donne un résultat différent à chaque itération, nous allons avoir un vrai problème de conformité à terme.

Une fois le code bien testé, on doit le zipper et recréer un checksum.

On crée un zip qui s’appellera cDisk_1.2.zip (le 1.2 est la version qu’on a modifiée dans cDisk.psd1 dans le répertoire racine de la ressource).

On copie le zip dans $env:ProgramFiles\WindowsPowershell\DscService\Modules

et l’arborescence entière du répertoire cDisk dans $env:ProgramFiles\WindowsPowershell\Modules (comme pour l’installation d’un nouveau module, ainsi powershell ne produira pas d’erreurs lorsqu’on veut utiliser le nouveau module dans nos configurations).

Ensuite on regénére le checksum ainsi:

 

Finalement on est prêts à utiliser notre nouvelle ressource dans nos configurations:

Nous allons tout d’abord importer notre module:

Et nous allons l’utiliser:

Chose importante dans le cas de cette ressource cDisk (ou xDisk):

Nous devons arrêter le service ShellHWDetection, car dés qu’un nouveau matériel devient disponible il essaye (à tort ou à raison) de nous proposer un dialog box avec les tâches à effectuer, notamment pour effectuer un formatage du nouveau volume. Dans notre cas dés que la cmdlet New-Partition est exécutée, le service se réveille, or nous on ne veut pas de dialog box car on gère le formatage dans la commande successive. Du coup on l’arrête avec DSC, et on s’assure qu’il reste éteint.

Une fois que la configuration est exécutée on peut voir notre disque formaté, et disponible à la lettre voulue (G):

newvolumeAinsi que dans explorer:

newdrive

En conclusion je dirais qu’une best-practice est de se focaliser sur la fonction qui fait les modifications Set-TargetResource en local sur une machine de test. Et seulement ensuite d’intégrer le tout dans DSC pour utilisation avec des modules de configuration.

Autre best-practice est de ne pas sous-estimer le GUID et la version de la ressource. Si vous ne les changez pas, DSC ne copiera pas une nouvelle version du module car il pensera que c’est déjà fait. Pour vérifier le module que DSC a copié, vous pouvez vous rendre sur un serveur cible, dans le répertoire

C:\Program Files\WindowsPowerShell\Modules

Là vous pouvez vérifier que c’est bien la dernière version.

octocatToutes les sources sont dans ce repository Github