Création de modules

Introduction

Le mot "module" fait généralement penser à "modulaire". On a l’image d’un élément de base, massif, à partir duquel gravitent d’autres éléments de plus petite taille qui viennent compléter ses fonctionnalités. Ces éléments peuvent être retirés, agrémentés, ajoutés, voire transférés.

Illustration de la modulalité sous PowerShell

Il en est ainsi des modules PowerShell, même si ces derniers sont plus que de simples ajouts. En effet, l’ensemble des commandes PowerShell, notamment les commandes de base, est contenu dans des modules. Les modules ont fait leur apparition avec PowerShell 2.0. Ils ont supplanté les snapins, apparus dans la première version de PowerShell. Les snapins sont encore utilisés, mais Microsoft conseille l’utilisation des modules, bien plus simples à mettre en place.

Les modules permettent d’organiser correctement le code conçu. Mais surtout, ils facilitent le partage du code avec des collègues, voire avec la communauté entière.

Module dynamique

La seconde possibilité pour créer un module est la commande New-Module. Elle crée un module dit dynamique. Il est chargé en mémoire et existe le temps de la session PowerShell. Cela signifie qu’il n’est pas écrit sur le disque, et donc invisible via la commande Get-Module (nous verrons plus loin qu’il existe un moyen de le faire apparaître). Les fonctions créées restent toutefois visibles par la commande Get-Command.

Arguments de la commande New-Module :

Module script

Les modules de type script sont les plus connus de par leur facilité et rapidité de création. Ils sont également simples à déployer, et plus faciles d’accès.

La création d’un module est relativement simple. Il peut d’ailleurs être stocké à différents endroits. Pour cela, il faut se référer au contenu de la variable d’environnement $Env:PSModulePath. Si le module créé n’est pas contenu dans un des répertoires de cette variable, alors il ne sera pas découvert automatiquement par PowerShell. Par ailleurs, il est tout à fait possible de modifier cette variable pour y ajouter ses propres chemins d’accès.

Si l’on décide de se passer de $Env:PSModulePath, il est toujours possible d’importer le module manuellement, en indiquant chemin d’accès complet à l’applet de commande Import-Module. Pour connaître le contenu de la variable $Env:PSModulePath :

PS > $Env:PSModulePath.Split(';') 
C:\Users\Nicol\Documents\WindowsPowerShell\Modules 
C:\Program Files\WindowsPowerShell\Modules 
C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules 

Une fois l’emplacement trouvé, il suffit de créer un dossier qui porte le nom du module, puis un fichier PSM1. Il doit porter le même nom que le dossier. Ce fichier va contenir le code PowerShell, voire faire appel à des scripts PS1.

Exemple de création du module

PS > New-Item -Path $Home\Documents\WindowsPowerShell\Modules ` 
            -Name MyModuleTools -Type directory 
 
PS > New-Item -Name MyModuleTools.psm1 -Type File ` 
-Path $Home\Documents\WindowsPowerShell\Modules\MyModuleTools 

Pour le moment, le module est vide. On va donc lui ajouter quelques fonctions utiles. Il est également intéressant d’y inclure une fonction qui fait appel à une seconde fonction, assez longue, utilisée régulièrement.

Manifeste de module

Le manifeste d’un module est un élément important si l’on souhaite partager son travail. Il s’agit d’un fichier au format PSD1. Il est formaté sous forme de hashtable et chaque champ détient les métadonnées concernant le module. Ces métadonnées regroupent un certain nombre d’éléments sur le module, tels que le nom de l’auteur, le numéro de version, les notes de versions, les différents fichiers à charger, ou encore les différents prérequis du module. Cette dernière section n’est d’ailleurs pas qu’informative. Elle a un impact important lors du chargement du module.

Si une version minimum de PowerShell est renseignée dans le manifeste, on ne peut pas utiliser le module dès lors que la version de PowerShell exécutée par le système est antérieure à celle indiquée.

Pour les manifestes, PowerShell dispose de deux cmdlets, New-ModuleManifest et Test-ModuleManifest. Les noms sont assez explicites : la première crée un manifeste, la seconde le teste.

Exportation des membres d’un module

Function Get-PSSerialNumber { 
    (Get-WMIObject -Class Win32_Bios).SerialNumber 
} 
 
Function Get-PSFolderSize { 
    Param( 
           [ValidateScript({Test-Path $_})] 
           [String]$Path 
    ) 
    (Get-ChildItem -Path $Path -Recurse -File | ` 
    Measure-Object -Property Length -Sum ).Sum /1MB 
} 
Set-Alias -Name gpsn -Value 'Get-PSSerialNumber' 
$ScriptAuthor = 'Nicolas Baudin' 
 
Export-ModuleMember -Function `  
    'Get-PSFolderSize','Get-PSSerialNumber' 
Export-ModuleMember -Variable 'ScriptAuthor' -Alias 'gpsn' 

Structure multifichier

Lors du maintien et de l’évolution d’un module, sa structure est un point important. S’il est très mal organisé, personne ne voudra travailler dessus, voir l’utiliser. Au contraire, si la structure est claire et définie, on aura plaisir à participer à son cycle de vie.

Il n’existe pas vraiment de structure conventionnelle. Le plus important est de documenter et de renseigner l’utilité de chaque dossier et de chaque fichier. Le travail d’un relecteur ou d’un contributeur sera ainsi facilité.

La structure présentée ici est un exemple. Elle n’est pas parfaite, mais a de gros avantages pour faciliter le maintien d’un module.

Structure hiérarchique

$Env:PSModulePath 
  └─<Version> 
    └─<Nom du module> 
      ├─Public 
         └─<Nom Script>.ps1 
      ├─Private 
         └─<Nom Script>.ps1 
      ├─<Manifeste du module>.psd1 
      ├─<Fichier principal>.psm1 
      └─<other...

Passer au Build avec Sampler

Dans la philosophie de développement d’un package, on retrouve généralement une phase de construction (build). Celle-ci prend le code brut, puis l’organise pour donner le package qui sera ensuite déployé. Dans cette phase de build, on retrouve souvent une compilation de code.

Dans notre cas, il s’agit d’un module. Le but est de pouvoir joindre la structure vue précédemment, et l’avantage d’un fichier PSM1 complet et performant. Pour cela, on part d’une structure multifichier, semblable à celle présentée dans la section précédente, pour le développement du module. Puis on utilise un outil de build afin d’arriver à un module construit sur un seul PSM1.

L’outil présenté ici est Sampler. Il s’agit d’un module communautaire développé par Gael Colas. Il en existe d’autres, notamment Stucco.

La motivation première de Gael pour concevoir ce module a été en priorité alimentée par les ressources DSC. En effet, Gael est l’un des piliers de la DSC Community et il souhaitait standardiser l’écriture des ressources DSC en basant leur développement sur une structure et des process de validation et de déploiement communs.

Sampler se base sur plusieurs modules pour construire un module de A à Z. En voici quelques-uns :

Le module Sampler est disponible sur la PowerShell Gallery. L’installation du module s’opère grâce au module PowerShellGet. Pour plus d’informations sur l’utilisation de ce dernier, référez-vous au chapitre Gestion des modules et des packages.

PS > Install-Module Sampler