Arbeiten mit privaten PowerShellGet-Repositorys

  • Artikel

Das PowerShellGet-Modul unterstützt andere Repositorys als den PowerShell-Katalog. Diese Cmdlets ermöglichen die folgenden Szenarien:

  • Unterstützung eines vertrauenswürdigen, bereits überprüften Satzes von PowerShell-Modulen für die Verwendung in Ihrer Umgebung
  • Testen einer CI/CD-Pipeline, die PowerShell-Module oder -Skripts erstellt
  • Bereitstellen von PowerShell-Skripts und -Modulen auf Systemen, die nicht auf das Internet zugreifen können
  • Bereitstellen von PowerShell-Skripts und -Modulen nur für Ihre Organisation

Dieser Artikel beschreibt, wie Sie ein lokales PowerShell-Repository einrichten. Der Artikel behandelt auch das im PowerShell-Katalog verfügbare OfflinePowerShellGetDeploy-Modul. Dieses Modul enthält Cmdlets zum Installieren der neuesten Version von PowerShellGet in Ihrem lokalen Repository.

Lokale Repositorytypen

Lokale PSRepositorys können auf zwei Arten erstellt werden: NuGet-Server oder Dateifreigabe. Jeder Typ hat Vor- und Nachteile:

NuGet-Server

Vorteile Nachteile
Nachahmen der PowerShellGallery-Funktionalität App mit mehreren Ebenen erfordert Planung des Betriebs und Support
NuGet integriert in Visual Studio, andere Tools Authentifizierungsmodell und NuGet-Kontenverwaltung erforderlich
NuGet unterstützt Metadaten in .Nupkg-Paketen Veröffentlichung erfordert Verwaltung und Wartung des API-Schlüssels
Ermöglicht Suche, Paketverwaltung usw.

Dateifreigabe

Vorteile Nachteile
Kann einfach eingerichtet, gesichert und verwaltet werden Keine Benutzeroberfläche außer einfacher Dateifreigabe
Einfaches Sicherheitsmodell – Benutzerberechtigungen für Freigabe Eingeschränkte Sicherheit und keine Aufzeichnung darüber, wer Updates ausführt
Keine Einschränkungen, wie z.B. das Ersetzen vorhandener Elemente

PowerShellGet funktioniert mit jedem Typ und unterstützt das Suchen von Versionen und die Installation von Abhängigkeiten. Einige Funktionen, die mit dem PowerShell-Katalog funktionieren, sind jedoch nicht für Basis-NuGet-Server oder Dateifreigaben verfügbar. Es gibt keine Unterscheidung zwischen Skripts, Modulen, DSC-Ressourcen oder Rollenfunktionen.

Erstellen eines NuGet.Server-Repositorys

Im folgenden Artikel sind die Schritte zum Einrichten Ihres eigenen NuGet-Servers aufgeführt.

Führen Sie die Schritte bis zum Punkt des Hinzufügens von Paketen aus. Die Schritte zum Veröffentlichen eines Pakets werden weiter unten in diesem Artikel behandelt.

Stellen Sie bei einem Repository auf Dateifreigabebasis sicher, dass Ihre Benutzer über Berechtigungen zum Zugriff auf die Dateifreigabe verfügen.

Registrieren eines lokalen Repositorys

Bevor ein Repository verwendet werden kann, muss es mithilfe des Register-PSRepository-Befehls registriert werden. In den folgenden Beispielen ist die InstallationPolicy auf Trustedfestgelegt, unter der Annahme, dass Sie Ihrem eigenen Repository vertrauen.

# Register a NuGet-based server
$registerPSRepositorySplat = @{
    Name = 'LocalPSRepo'
    SourceLocation = 'http://MyLocalNuget/Api/V2/'
    ScriptSourceLocation = 'http://MyLocalNuget/Api/V2'
    InstallationPolicy = 'Trusted'
}
Register-PSRepository @registerPSRepositorySplat

# Register a file share on my local machine
$registerPSRepositorySplat = @{
    Name = 'LocalPSRepo'
    SourceLocation = '\\localhost\PSRepoLocal\'
    ScriptSourceLocation = '\\localhost\PSRepoLocal\'
    InstallationPolicy = 'Trusted'
}
Register-PSRepository @registerPSRepositorySplat

Beachten Sie, wie unterschiedlich die beiden Befehle ScriptSourceLocation behandeln. Für Repositorys auf Dateifreigabebasis müssen SourceLocation und ScriptSourceLocation übereinstimmen. Für ein webbasiertes Repository müssen sie unterschiedlich sein, also wird SourceLocation in diesem Beispiel ein nachstehender „/“ angefügt.

Wenn Sie ein Dateifreigabeprotokoll wie NFS oder SMB verwenden, befolgen Sie unbedingt die empfohlene Anleitung zum Schützen des Protokolls. Weitere Informationen zum Schützen von SMB unter Windows finden Sie unter [SMB-Sicherheitsverbesserungen][09].

Wenn das neu erstellte PSRepository das Standardrepository sein soll, müssen Sie die Registrierung aller anderen PSRepositorys aufheben. Beispiel:

Unregister-PSRepository -Name PSGallery

Hinweis

Das Repository mit dem Namen PSGallery ist für die Verwendung durch den PowerShell-Katalog reserviert. Sie können die Registrierung von PSGallery aufheben, aber den Namen PSGallery nicht für ein anderes Repository wiederverwenden.

Wenn Sie PSGallery wiederherstellen müssen, führen Sie den folgenden Befehl aus:

Register-PSRepository -Default

Veröffentlichung in einem lokalen Repository

Nachdem Sie das lokale PSRepository registriert haben, können Sie in Ihrem lokalen PSRepository veröffentlichen. Es gibt zwei Hauptveröffentlichungsszenarien: Veröffentlichen Ihres eigenen Moduls und Veröffentlichen eines Moduls aus der PSGallery.

Veröffentlichung eines von Ihnen erstellten Moduls

Veröffentlichen Sie Ihr Modul mit Publish-Module und Publish-Script genauso wie für den PowerShell-Katalog in Ihrem lokalen PSRepository.

  • Geben Sie den Speicherort für Ihren Code an
  • Geben Sie einen API-Schlüssel an
  • Geben Sie den Namen des Repositorys an. Zum Beispiel, -PSRepository LocalPSRepo

Hinweis

Sie müssen ein Konto auf dem NuGet-Server erstellen und sich dann anmelden, um den API-Schlüssel zu generieren und zu speichern. Verwenden Sie für eine Dateifreigabe eine beliebige nicht leere Zeichenfolge für den NuGetApiKey-Wert.

Beispiele:

# Publish to a NuGet Server repository using my NuGetAPI key
$publishModuleSplat = @{
    Path = 'c:\projects\MyModule'
    Repository = 'LocalPsRepo'
    NuGetApiKey = $nuGetApiKey
}
Publish-Module @publishModuleSplat

Wichtig

Um die Sicherheit zu gewährleisten, sollten API-Schlüssel in Skripts nicht hartcodiert werden. Verwenden Sie ein sicheres Schlüsselverwaltungssystem. Beim manuellen Ausführen eines Befehls sollten API-Schlüssel nicht als Nur-Text übergeben werden, um die Protokollierung zu vermeiden. Das Read-Host Cmdlet kann verwendet werden, um den Wert des API-Schlüssels sicher zu übergeben.

# Publish to a file share repo - the NuGet API key must be a non-blank string
$publishModuleSplat = @{
    Path = 'c:\projects\MyModule'
    Repository = 'LocalPsRepo'
    NuGetApiKey = 'AnyStringWillDo'
}
Publish-Module @publishModuleSplat

Veröffentlichung eines Moduls aus der PSGallery

Um ein Modul aus der PSGallery in Ihrem lokalen PSRepository zu veröffentlichen, können Sie das Save-Package Cmdlet verwenden.

  • Geben Sie den Namen des Pakets an
  • Geben Sie „NuGet“ als Anbieter an
  • Geben Sie den PSGallery-Speicherort als Quelle an (https://www.powershellgallery.com/api/v2)
  • Geben Sie den Pfad zu Ihrem lokalen Repository an

Beispiel:

# Publish from the PSGallery to your local Repository
$savePackageSplat = @{
    Name = 'PackageName'
    ProviderName = 'NuGet'
    Source = 'https://www.powershellgallery.com/api/v2'
    Path = '\\localhost\PSRepoLocal\'
}
Save-Package @savePackageSplat

Wenn Ihr lokales PSRepository webbasiert ist, ist ein zusätzlicher Schritt erforderlich, der zum Veröffentlichen verwendet nuget.exe wird. Weitere Informationen finden Sie in der Dokumentation zur Verwendung von nuget.exe.

Installieren von PowerShellGet auf einem nicht verbundenen System

Das Bereitstellen von PowerShellGet ist schwierig in Umgebungen, die erfordern, dass Systeme nicht mit dem Internet verbunden sind. Der Bootstrapprozess von PowerShellGet installiert bei der ersten Verwendung die aktuelle Version. Das OfflinePowerShellGetDeploy-Modul im PowerShell-Katalog bietet Cmdlets, die diesen Bootstrapprozess unterstützen.

Um eine Offlinebereitstellung zu starten, müssen Sie Folgendes tun:

  • OfflinePowerShellGetDeploy herunterladen und auf Ihrem mit dem Internet verbundenen System und Ihren nicht verbundenen Systemen installieren
  • PowerShellGet und seine Abhängigkeiten mithilfe des Save-PowerShellGetForOffline-Cmdlets auf das mit dem Internet verbundene System herunterladen
  • PowerShellGet und seine Abhängigkeiten von dem mit dem Internet verbundenen System auf das nicht verbundene System kopieren
  • Durch Verwendung von Install-PowerShellGetOffline auf dem nicht verbundenen System PowerShellGet und seine Abhängigkeiten in den richtigen Ordnern ablegen

Die folgenden Befehle legen mit Save-PowerShellGetForOffline alle Komponenten im Ordner f:\OfflinePowerShellGet ab.

# Requires -RunAsAdministrator
#Download the OfflinePowerShellGetDeploy to a location that can be accessed
# by both the connected and disconnected systems.
Save-Module -Name OfflinePowerShellGetDeploy -Path 'F:\' -Repository PSGallery
Import-Module F:\OfflinePowerShellGetDeploy

# Put PowerShellGet somewhere locally
Save-PowerShellGetForOffline -LocalFolder 'F:\OfflinePowerShellGet'

An diesem Punkt müssen Sie den Inhalt von F:\OfflinePowerShellGet Ihren nicht verbundenen Systemen verfügbar machen. Führen Sie das Install-PowerShellGetOffline-Cmdlet aus, um PowerShellGet auf dem nicht verbundenen System zu installieren.

Hinweis

Es ist wichtig, dass Sie PowerShellGet nicht in der PowerShell-Sitzung ausführen, bevor Sie diese Befehle ausführen. Sobald PowerShellGet in die Sitzung geladen wurde, können die Komponenten nicht mehr aktualisiert werden. Wenn Sie PowerShellGet versehentlich starten, beenden Sie PowerShell, und starten Sie es neu.

Import-Module F:\OfflinePowerShellGetDeploy
Install-PowerShellGetOffline -LocalFolder 'F:\OfflinePowerShellGet'

Nach dem Ausführen dieser Befehle können Sie PowerShellGet in Ihrem lokalen Repository veröffentlichen.

# Publish to a NuGet Server repository using my NuGetAPI key
$publishModuleSplat = @{
    Path = 'F:\OfflinePowershellGet'
    Repository = 'LocalPsRepo'
    NuGetApiKey = $nuGetApiKey
}
Publish-Module @publishModuleSplat

Wichtig

Um die Sicherheit zu gewährleisten, sollten API-Schlüssel in Skripts nicht hartcodiert werden. Verwenden Sie ein sicheres Schlüsselverwaltungssystem. Wenn Sie einen Befehl manuell ausführen, sollten API-Schlüssel nicht als Nur-Text übergeben werden, um die Protokollierung zu vermeiden. Das Read-Host Cmdlet kann verwendet werden, um den Wert des API-Schlüssels sicher zu übergeben.

# Publish to a file share repo - the NuGet API key must be a non-blank string
$publishModuleSplat = @{
    Path = 'F:\OfflinePowerShellGet'
    Repository = 'LocalPsRepo'
    NuGetApiKey = 'AnyStringWillDo'
}
Publish-Module @publishModuleSplat

Verwenden von Paketierungslösungen zum Hosten von PowerShellGet-Repositorys

Sie können auch Paketierungslösungen wie Azure Artifacts verwenden, um ein privates oder öffentliches PowerShellGet-Repository zu hosten. Weitere Informationen und Anweisungen finden Sie in der Azure Artifacts-Dokumentation.