Uso dei repository PowerShellGet privati
Il modulo PowerShellGet supporta repository diversi da PowerShell Gallery. Questi cmdlet consentono gli scenari seguenti:
- Supporto di un set attendibile e pre-convalidato di moduli PowerShell per l'uso nell'ambiente
- Test di una pipeline CI/CD che compila moduli o script PowerShell
- Distribuzione di moduli e script PowerShell in sistemi che non possono accedere a Internet
- Distribuzione di moduli e script PowerShell disponibili solo per l'organizzazione
Questo articolo descrive come configurare un repository PowerShell locale. L'articolo riguarda anche il modulo OfflinePowerShellGetDeploy disponibile in PowerShell Gallery. Questo modulo contiene i cmdlet per installare la versione più recente di PowerShellGet nel repository locale.
Tipi di repository locali
È possibile creare un repository PowerShell in due modi: Server NuGet o condivisione file. Ogni tipo presenta vantaggi e svantaggi.
Server NuGet
Vantaggi | Svantaggi |
---|---|
Simula la funzionalità powerShellGallery | L'app a più livelli richiede la pianificazione e il supporto delle operazioni |
NuGet si integra con Visual Studio e altri strumenti | È necessario gestire il modello di autenticazione e gli account NuGet |
NuGet supporta i metadati in pacchetti .Nupkg |
La pubblicazione richiede la gestione e la manutenzione delle chiavi API |
Fornisce ricerca, amministrazione dei pacchetti e così via. |
Condivisione file
Vantaggi | Svantaggi |
---|---|
Semplice da configurare, sottoporre a backup e gestire | Nessuna interfaccia utente oltre la condivisione file di base |
Modello di sicurezza semplice, autorizzazioni utente sulla condivisione | Sicurezza limitata e nessuna registrazione degli utenti e degli aggiornamenti che eseguono |
Nessun vincolo, ad esempio la sostituzione degli elementi esistenti |
PowerShellGet è compatibile con entrambi i tipi e supporta l'individuazione delle versioni e l'installazione delle dipendenze. Tuttavia, alcune funzionalità compatibili con PowerShell Gallery non sono disponibili per le condivisioni file o i server NuGet di base. Non esiste alcuna differenziazione di script, moduli, risorse DSC o funzionalità del ruolo.
Creazione di un repository NuGet.Server
L'articolo seguente elenca i passaggi per la configurazione di un server NuGet personalizzato.
Seguire i passaggi fino al momento dell'aggiunta di pacchetti. I passaggi per la pubblicazione di un pacchetto sono trattati più avanti in questo articolo.
Per un repository basato su condivisione file, assicurarsi che gli utenti dispongano delle autorizzazioni per accedere alla condivisione file.
Registrazione di un repository locale
Prima di poter usare un repository, è necessario registrarlo con il comando Register-PSRepository
. Negli esempi seguenti , InstallationPolicy è impostato su Trusted
, presupponendo che si consideri attendibile il proprio repository.
# 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
Notare la differenza nel modo in cui i due comandi gestiscono ScriptSourceLocation. Per repository basati su condivisione file, SourceLocation e ScriptSourceLocation devono corrispondere. Per un repository basato sul Web, devono essere diversi, quindi in questo esempio viene aggiunto un carattere "/" finale a SourceLocation.
Quando si usa un protocollo di condivisione file, ad esempio NFS o SMB, assicurarsi di seguire le indicazioni consigliate per proteggere il protocollo. Per altre informazioni sulla protezione di SMB in Windows, vedere [Miglioramenti alla sicurezza SMB][09].
Se si intende rendere predefinito il repository PowerShell appena creato, è necessario annullare la registrazione di tutti gli altri repository PowerShell. Ad esempio:
Unregister-PSRepository -Name PSGallery
Nota
Il nome di repository 'PSGallery' è riservato per l'uso da parte di PowerShell Gallery. È possibile annullare la registrazione di PSGallery, ma non è possibile riutilizzare il nome PSGallery per qualsiasi altro repository.
Se è necessario ripristinare PSGallery, eseguire il comando seguente:
Register-PSRepository -Default
Pubblicazione in un repository locale
Dopo aver registrato il repository PowerShell locale, sarà possibile eseguire pubblicazioni al suo interno. Esistono due scenari di pubblicazione principali: pubblicazione del proprio modulo e pubblicazione di un modulo da PSGallery.
Pubblicazione di un modulo creato dall'utente
Usare Publish-Module
e Publish-Script
per pubblicare un modulo nel repository PowerShell locale con la stessa procedura valida per PowerShell Gallery.
- Specificare la posizione per il codice
- Specificare una chiave API
- Specificare il nome del repository. Ad esempio, usare
-PSRepository LocalPSRepo
Nota
È necessario creare un account nel server NuGet, quindi eseguire l'accesso per generare e salvare la chiave API. Per una condivisione file, usare una stringa non vuota per il valore NuGetApiKey.
Esempi:
# Publish to a NuGet Server repository using my NuGetAPI key
$publishModuleSplat = @{
Path = 'c:\projects\MyModule'
Repository = 'LocalPsRepo'
NuGetApiKey = $nuGetApiKey
}
Publish-Module @publishModuleSplat
Importante
Per garantire la sicurezza, le chiavi API non devono essere hardcoded negli script. Usare un sistema di gestione delle chiavi sicuro. Quando si esegue manualmente un comando, le chiavi API non devono essere passate come testo normale per evitare la registrazione, il Read-Host
cmdlet può essere usato per passare in modo sicuro il valore della chiave API.
# 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
Pubblicazione di un modulo da PSGallery
Per pubblicare un modulo da PSGallery nel PSRepository locale, è possibile usare il Save-Package
cmdlet .
- Specificare il nome del pacchetto
- Specificare 'NuGet' come provider
- Specificare il percorso PSGallery come origine (
https://www.powershellgallery.com/api/v2
) - Specificare il percorso del repository locale
Esempio:
# 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
Se PSRepository locale è basato sul Web, è necessario un passaggio aggiuntivo che usa nuget.exe
per la pubblicazione. Vedere la documentazione per l'uso di nuget.exe.
Installazione di PowerShellGet in un sistema disconnesso
La distribuzione di PowerShellGet è difficile in ambienti che richiedono sistemi disconnessi da Internet. PowerShellGet include un processo bootstrap che installa la versione più recente al primo utilizzo. Il modulo OfflinePowerShellGetDeploy in PowerShell Gallery include cmdlet che supportano questo processo di bootstrap.
Per eseguire il bootstrap di una distribuzione offline, è necessario:
- Scaricare e installare OfflinePowerShellGetDeploy nel sistema connesso a Internet e nei sistemi disconnessi
- Scaricare PowerShellGet e le relative dipendenze nel sistema connesso a Internet usando i cmdlet
Save-PowerShellGetForOffline
- Copiare PowerShellGet e le relative dipendenze dal sistema connesso a Internet al sistema disconnesso
- Usare
Install-PowerShellGetOffline
nel sistema disconnesso per posizionare PowerShellGet e le relative dipendenze nelle cartelle appropriate
I comandi seguenti usano Save-PowerShellGetForOffline
per inserire tutti i componenti in una cartella f:\OfflinePowerShellGet
# 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'
A questo punto, è necessario rendere il contenuto di F:\OfflinePowerShellGet
disponibile per i sistemi disconnessi. Eseguire il cmdlet Install-PowerShellGetOffline
per installare PowerShellGet nel sistema disconnesso.
Nota
È importante non eseguire PowerShellGet nella sessione di PowerShell prima di eseguire questi comandi. Dopo il caricamento di PowerShellGet nella sessione, i componenti non possono essere aggiornati. Se si avvia PowerShellGet per errore, chiuderlo e riavviarlo.
Import-Module F:\OfflinePowerShellGetDeploy
Install-PowerShellGetOffline -LocalFolder 'F:\OfflinePowerShellGet'
Dopo aver eseguito questi comandi, sarà possibile pubblicare PowerShellGet nel repository locale.
# Publish to a NuGet Server repository using my NuGetAPI key
$publishModuleSplat = @{
Path = 'F:\OfflinePowershellGet'
Repository = 'LocalPsRepo'
NuGetApiKey = $nuGetApiKey
}
Publish-Module @publishModuleSplat
Importante
Per garantire la sicurezza, le chiavi API non devono essere hardcoded negli script. Usare un sistema di gestione delle chiavi sicuro. Quando si esegue manualmente un comando, le chiavi API non devono essere passate come testo normale per evitare la registrazione, il Read-Host
cmdlet può essere usato per passare in modo sicuro il valore della chiave API.
# 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
Usare soluzioni di creazione pacchetti per ospitare repository PowerShellGet
È anche possibile usare soluzioni di creazione pacchetti come Azure Artifacts per ospitare un repository PowerShellGet privato o pubblico. Per altre informazioni e istruzioni, vedere la documentazione di Azure Artifacts.