Editions ENI Livres | Vidéos | e-Formations
Snap-ins, modules et PowerShell Gallery
Introduction
Là où PowerShell et la célèbre firme à la pomme se rejoignents c’est autour du fameux slogan « Il y a une application pour ça ». En effet, dans l’écosystème PowerShell on pourrait faire le parallèle en disant « Il y a une commande pour ça ». Ceci est d’autant plus vrai que depuis que Microsoft a créé la PowerShell Gallery (dont nous parlerons à la fin de ce chapitre), on pourrait la comparer à un magasin d’applications. Sauf qu’au lieu d’y trouver des applications, on y trouve de nombreuses commandes additionnelles packagées dans des modules. Vous l’aurez compris, ces commandes additionnelles vont permettre d’étendre à l’infini les fonctionnalités de base offertes par PowerShell.
Par ailleurs, PowerShell a suscité l’engouement de la part de nombreux éditeurs tiers tels que VMware, Amazon, Google, Citrix, HP, Hitachi, EMC, IBM, F5 Networks, etc. Tous proposent des snap-ins ou des modules pour gérer leurs logiciels ou leurs matériels. Ceci n’est pas près de s’arrêter et c’est tant mieux car on en redemande.
Les snap-ins
La notion de « snap-in » ne concerne que Windows PowerShell. On pourrait dire que le snap-in est l’ancêtre du module. C’est la raison pour laquelle Microsoft les a complètement retirés de PowerShell Core au profit des modules.
Avec Windows PowerShell 1.0, l’ajout de fonctionnalités et de commandelettes additionnelles se réalisait uniquement par le biais des snap-ins. Pour des raisons de compatibilité, les snap-ins sont toujours supportés dans Windows PowerShell mais, à partir de PowerShell 2.0, ils ont cédé leur place aux modules, bien plus pratiques et simples à utiliser.
En effet, pour installer un snap-in, il faut posséder des privilèges administrateur, les snap-ins étant presque toujours livrés sous forme de fichiers MSI car ils doivent enregistrer leurs DLL dans la base de registres. A contrario, pour installer un module, un simple copier/coller suffit et on peut le faire avec de simples privilèges utilisateurs. Enfin, pour couronner le tout, pour développer des snap-ins, il faut obligatoirement le faire avec un langage .NET compilé (tel que C# ou VB.NET) tandis que les modules peuvent l’être en PowerShell, ce qui met leur développement à la portée du plus grand nombre.
1. Lister les snap-ins installés
Pour connaître la liste des snap-ins présents sur votre machine et importés dans la session courante, tapez la commande Get-PSSnapin. Par défaut, sous Windows PowerShell, il n’y en a qu’un seul : le snap-in Microsoft.PowerShell.Core.
PS > Get-PSSnapin
Name : Microsoft.PowerShell.Core
PSVersion : 5.1.14393.1944
Description : This Windows PowerShell snap-in contains cmdlets used
to manage components of Windows PowerShell.
Get-PSSnapin possède également le commutateur -Registred. Celui-ci, lorsque spécifié, permet de lister les snap-ins installés sur notre système mais qui n’ont pas été importés dans la session courante. Le résultat de la commande ne contient pas les snap-ins nécessaires au fonctionnement de PowerShell....
Les modules
Comme nous vous le disions précédemment, les modules sont apparus avec la version 2.0 de PowerShell. Un module est un conteneur qui regroupe des commandes, mais aussi des scripts, des variables, des alias et des fonctions. Par rapport à un snap-in, l’avantage d’un module, c’est qu’il est facilement transportable (une simple copie de fichiers suffit) et donc très facilement partageable afin d’en faire profiter d’autres utilisateurs. Il est également assez simple d’en créer soi-même, mais cela est en dehors du périmètre de ce livre… L’idée de l’équipe PowerShell chez Microsoft est de bâtir une grande communauté d’utilisateurs, et de faire en sorte que celle-ci puisse aisément s’échanger ou partager des modules à l’image de la communauté CPAN (Comprehensive Perl Archive Network) que connaissent bien les utilisateurs du langage PERL.
C’est de cette volonté qu’est né en 2015 le site www.powershellgallery.com. La « PowerShell Gallery » se veut être le dépôt central des modules PowerShell émanant de Microsoft comme de la communauté internationale des utilisateurs PowerShell. Ce site de dépôt est l’initiative de Microsoft. Il vous faudra la version 5 minimum de PowerShell afin de pouvoir bénéficier des commandes permettant d’interagir avec les modules présents dans ce dépôt.
1. Installer un module
Avec Windows Server, chaque rôle installé donne généralement droit à un module qui s’installe automatiquement. Cependant, vous pouvez également recevoir un module d’une tierce personne. Dans ce cas, il suffit de le copier dans l’un des emplacements prévus pour recevoir les modules et le tour est joué. Un module se présente sous la forme d’un dossier contenant plusieurs fichiers. Pour qu’un module soit valide, il doit contenir au minimum un fichier portant l’extension .psd1 ainsi qu’un fichier portant l’extension...
PowerShell Gallery
1. Qu’est-ce que c’est ?
La PowerShell Gallery est un dépôt open source de scripts et de modules (dont de nombreuses ressources DSC). Elle est hébergée et gérée par Microsoft et tout un chacun est invité à contribuer en venant y déposer ses créations mais aussi à les consommer. Vous l’aurez compris, l’idée de la galerie PowerShell est de favoriser le partage afin d’éviter de réinventer la roue.
Microsoft est bien évidemment un contributeur important de la PowerShell Gallery, mais il n’est pas le seul. Les auteurs que nous sommes contribuent également, mais de manière modeste, à l’enrichissement de ce dépôt.
À l’heure où nous écrivons ces lignes, il y a dans la galerie plus de 2750 éléments uniques publiés (scripts et modules), pour un ensemble de plus de 15000 éléments si on comptabilise toutes les versions. Il faut savoir que les modules représentent à eux seuls plus de 85% des éléments présents dans la bibliothèque. Ces derniers, contrairement aux scripts, ont l’avantage d’être rigoureusement versionnés et possèdent de nombreuses métadonnées. La galerie PowerShell est donc avant tout un dépôt de modules.
2. Quid de la sécurité ?
Comme il s’agit d’un dépôt public, cette question nous vient immédiatement à l’esprit. C’est tout à fait légitime. Et c’est tant mieux de se poser la question, car le contraire pourrait avoir de graves conséquences !
Il faut savoir que lorsque quelqu’un publie un module dans la galerie, Microsoft utilise un robot qui effectue les actions suivantes :
1. Installation du module,
2. Scan antiviral en vue de détecter des éventuels malwares,
3. Application du module « PowerShell Script Analyzer ».
Le module PowerShell Script Analyzer (présent lui aussi dans la galerie) est un excellent module qui permet de tester la qualité du code d’un module ou d’un script PowerShell. Il sert à vérifier - à travers un certain nombre de règles prédéfinies - que les bonnes pratiques soient...
