Editions ENI Livres | Vidéos | e-Formations
Gestion des modules et des packages
Introduction
Il vous est sans doute déjà arrivé d’envier la "facilité" avec laquelle les linuxiens mettent à jour leurs applications, librairies et autres binaires. Et ce, depuis un simple dépôt hébergé. Une commande, et le tour est joué ! Soyez donc heureux d’apprendre que Microsoft a également mis à disposition sa propre solution de package management ! Appelée NuGet, elle a été créée en 2010 sous licence Apache 2.0. Elle met à disposition des packages au format NUPKG.
Au départ, NuGet a été intégré à Visual Studio 2012 pour gérer facilement les dépendances de librairies et les projets transverses. Il est utilisable à travers des lignes de commande ou des interfaces graphiques. Depuis, il n’a cessé de susciter l’intérêt. Si bien que le dépôt Chocolatey a fait son apparition. Basé sur cette technologie, il permet d’installer avec quelques lignes de commande des applications telles que 7zip, Adobe Reader, etc.
Et PowerShell dans tout cela ? Depuis sa création, son but premier est de simplifier et d’automatiser l’administration du système d’information. C’est donc dans ce cadre et celui du DevOps, que le module PackageManagement a été implémenté...
Module PackageManagement
Pour pouvoir installer un package depuis un dépôt, il est nécessaire de l’enregistrer en tant que source sur le système client. Pour connaître les sources déjà présentes, on utilise la commande Get-PackageSource :
PS > Get-PackageSource
Name ProviderName IsTrusted Location
---- ------------ --------- --------
PSGallery PowerShellGet False https://www.powershellga... Comme il a été dit, la galerie PowerShell est présente par défaut en tant que source pour PackageManagement. Toutefois, avant de commencer à l’utiliser, il faut connaître un dernier élément. Les sources ajoutées aux clients possèdent chacune un type de fournisseur particulier. Chaque type dispose de ses propres caractéristiques. Pour connaître les types de fournisseurs présents sur le système, on utilise la commande Get-PackageProvider :
PS > Get-PackageProvider
Name Version DynamicOptions
---- ------- --------------
msi 3.0.0.0 AdditionalArguments
msu 3.0.0.0
PowerShellGet 1.0.0.1 PackageManagementProvider, Typ...
Programs 3.0.0.0 IncludeWindowsInstaller, Inclu... Sont présentés ici les quatre fournisseurs présents par défaut. Il en existe d’autres que l’on peut télécharger et installer depuis Internet. Pour les découvrir, on utilise la commande Find-PackageProvider :
Find-packageProvider -Name * | Format-table Name,Version,Source
Name Version Source ...Module PowerShellGet
Le module PowerShellGet v1 et v2 se base sur le module PackageManagement. Le fonctionnement est quasiment identique. Quelques éléments différents tout de même.
Par défaut, PowerShellGet dispose d’une source enregistrée à l’installation de Windows 10 et de Windows Server 2016. Il s’agit de la galerie PowerShell. Elle sera utilisée dans toute cette section.
La section Création d’un dépôt expliquera comment organiser son propre fournisseur et comment l’enregistrer en tant que source pour le module PowerShellGet.
1. Mise à jour de PowerShellGet pour le support du TLS
Depuis avril 2020, Microsoft a désactivé le support du TLS 1.0 sur la PowerShell Gallery, et le module PowerShellGet v1 présent par défaut sur les systèmes ne supporte pas le TL1.2 requis pour utiliser correctement la PowerShell Gallery.
Avant tout, il est donc conseillé de mettre à jour la version de PowerShellGet en version 2.2.5 avec la commande suivante :
PS > Install-Module PowerShellGet -RequiredVersion 2.2.5
-SkipPublisherCheck -AllowClobber -Force Ensuite, il convient de vérifier si votre version du TLS 1.2 est activée. Par défaut, c’est le cas pour Windows 11.
Pour modifier dans le process en cours, vous pouvez toujours utiliser la commande suivante :
PS > [Net.ServicePointManager]::SecurityProtocol = `
[Net.SecurityProtocolType]::Tls12 Pour plus d’informations, il est possible de consulter le billet suivant : https://devblogs.microsoft.com/powershell/powershell-gallery-tls-support/
2. Recherche d’une ressource
Pour trouver la ressource qui convient le mieux au besoin, il existe cinq commandes. Une pour chaque type de ressource :
PS > Get-Command Find-* -Module PowerShellGet
CommandType Name Version Source
----------- ---- ------- ------
Function Find-Command 1.0.0.1 PowerShellGet ...Création d’un dépôt
La possibilité de déployer une application ou une ressource PowerShell en quelques commandes et de la mettre à jour à chaque nouvelle version est un vrai plus. Toutefois, si l’on vient à travailler dans un environnement avec un flux Internet assez restreint (pour diverses raisons : sécurité importante, faible bande passante, etc.), il peut rapidement devenir primordial d’avoir son propre fournisseur en interne.
Il existe alors deux possibilités :
-
un partage réseau
-
un site internet basé sur la technologie NuGet
La structure des packages Chocolatey est particulière et peut dérouter quelque peu. La création de packages à partir de zéro n’est donc pas abordée ici. Concernant PowerShellGet, la création est intégrée lors de la publication de la ressource.
1. Via un simple partage réseau
Les modules PackageManagement et PowerShellGet peuvent intégrer un simple partage réseau en tant que source. Les packages doivent être regroupés dans plusieurs dossiers différents en fonction de leur type respectif. Cela sous-entend que l’on doit dissocier les packages de Chocolatey et les packages de ressources PowerShell. Il n’est pas nécessaire de créer un partage par type de ressource, il suffit de pointer au bon endroit lors de l’ajout de la source sur le client.
Exemple de hiérarchie
\\myserver\LocalGet
└─MyChocolatey
└─<Packages Chocolatey>
└─MyPowerShell
└─<Packages Ressources PowerShell> Pour créer le partage sur le serveur :
PS > New-Item -Path `
C:\LocalGet\MyChocolatey,C:\LocalGet\MyPowerShell `
-ItemType Directory
Répertoire : C:\LocalGet
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 12/10/2017 15:52 MyChocolatey ...
