Wie importiere ich ein benutzerdefiniertes PowerShell-Modul in die Remote-Sitzung?

Entwickle ich eine benutzerdefinierte PowerShell-Modul, das ich verwenden möchte, im Rahmen einer remote-Sitzung auf einem anderen computer. Den folgenden code (die offensichtlich nicht funktioniert) erklärt, was ich versuche zu erreichen:

import-module .\MyCustomModule.psm1
$session = new-pssession -computerName server01
invoke-command -session $session -scriptblock { 
  <# use function defined in MyCustomModule here #> 
}

Die erste Frage ist, ob es überhaupt möglich ist, um dieses Szenario zu erhalten? Ich meine, ich würde nur gerne meine custom Modul, physisch anwesend zu sein, auf meinem Rechner, nicht auf dem remote-server.

Habe ich gefunden dieser thread, aber ich schaffte es nicht ihn zu arbeiten - es nicht erlauben, Sitzung erstellen von remote-Maschine wieder auf die lokale. Wahrscheinlich Stand ich mit der Konfiguration Einschränkungen erwähnt irgendwo in den Kommentaren zu diesem thread... Außerdem, der Autor erwähnt die Auswirkungen auf die Leistung, die kritisch für meine Lösung...

Wenn das möglich ist, was dann?

Version von PowerShell ist derzeit nicht eine Einschränkung -, wenn die Lösung nur in PS 3.0 - damit kann ich Leben.

Kommentar zu dem Problem - Öffnen

Duplizieren mit stackoverflow.com/questions/2830827/... ? Kommentarautor: David Brabant

Ich glaube nicht, dass das unterstützt wird rechts neben dem Feld. Sie hatte einen hack, wie Sie es versuchten. Darf ich Fragen, warum Sie nicht installieren Sie einfach das Modul auf dem remote-computer? Das ist die intelligente Lösung. Kommentarautor: Frode F.

@DavidBrabant, gut, ja, es ist ganz in der Nähe. Allerdings habe ich nicht die Lösung, die dort arbeiten, und ich bin Referenzierung dieser thread explizit zu zeigen, dass ich versuchte, die Möglichkeit und Fragen nach alternativen 🙂 Kommentarautor: Yan Sklyarenko

@Graimer, war die Idee, die Verwendung jeglicher aus den zur Verfügung stehenden Maschinen durchführen deployment-Szenarien, ohne das etwas installiert werden muss auf einem remote-Rechner. Aber wenn das Szenario nicht unterstützt wird, müssen wir Leben mit diesem... Kommentarautor: Yan Sklyarenko

Warum nicht setzen Sie das Modul in einen öffentlichen Ort, starten Sie den Skriptblock mit Import-Modul \\fileserver\Ordner\modulefolder ? Stellen Sie sicher, dass es Digital signiert ist oder so etwas wie Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope-Prozess vor dem Import zu umgehen Warnungen? Kommentarautor: Frode F.

InformationsquelleAutor der Frage Yan Sklyarenko | 2013-01-21

35

Gab es einige tolle Kommentare auf die Frage, und ich habe einige Zeit damit verbracht untersucht verschiedene Möglichkeiten, dieses problem anzugehen.

Beginnen mit, was ich habe zunächst gefragt, ist nicht möglich. Ich meine, wenn man das Modul Weg, dann das Modul soll physisch auf einem Zielcomputer in der Lage sein, um Import-Module in die remote-Sitzung.

Abstrakten meine Frage, ich bin versucht, erstellen Sie eine wiederverwendbare PowerShell-basiertes framework für die Produkt-Bereitstellungen. Es geht um eine push-Weise-Bereitstellungen, was bedeutet, dass wir Menschen zu ermutigen, laufen einige Skripte auf einem lokalen Computer bereitstellen, auf einigen remote-server. Soweit ich in der Gegend erforscht, es gibt zwei Möglichkeiten, die freundlich sind, den common sense.

- Module Ansatz

Den Prozess zu Folgen:
- jede logisch anderen Teil der Funktionalität in die PowerShell-Modul (*.psm1)
- verteilen Sie das Modul an der entfernten Maschine und verlängern die PSModulePath variable, um die neuen Module Lage
- auf einem client-Rechner, erstellen Sie eine neue session auf dem remote-server, und verwenden Sie Invoke-Command -Session $s -ScriptBlock {...}
- in den script-block starten von Import-Module CustomModule - es wird nach CustomModule auf einem remote-Rechner, und offensichtlich finden es
Vorteile

Im folgenden sind die Gründe, die Liebe, die diese Vorgehensweise für:
- die Folge der traditionellen Moduls Rolle - ermöglichen die Erstellung von wiederverwendbaren Bibliotheken
- nach das große Buch Windows PowerShell in Action, "Module können verwendet werden, um domain-spezifische Anwendungen". Soweit ich das verstanden habe, kann erreicht werden, durch die Kombination der module nesting-und mixing-Skript /binary-Module verfügbar machen die intuitive Schnittstelle, die spezifisch für eine bestimmte Domäne. Im Grunde ist das die, die ich am meisten Wert für das Ziel der PowerShell-basierten deployment-framework
Nachteile

Ist Folgendes zu berücksichtigen:
- Sie müssen einen Weg finden, liefern die custom Module der remote-Maschine. Ich habe gespielt mit NuGet, und ich bin nicht sicher, es passt gut für die Aufgabe, aber es gibt auch andere Möglichkeiten, zum Beispiel MSI-installer oder plain xcopy aus dem freigegebenen Ordner. Neben der Lieferung Mechanismus unterstützen sollte, upgrade /downgrade und (vorzugsweise) Installationen mit mehreren Instanzen, aber das ist mehr im Zusammenhang mit meiner Aufgabe als das problem im Allgemeinen
Scripts Ansatz

Den Prozess zu Folgen:
- jede logisch unterschiedliche Stück Funktionalität in eine separate PowerShell-Skript (*.ps1)
- auf einem client-Rechner, erstellen Sie eine neue session auf dem remote-server, und verwenden Sie Invoke-Command -Session $s -FilePath .\myscript.ps1 zum laden der Funktionen in einem Skript definiert wurden, um die remote-Sitzung
- verwenden Sie einen anderen Invoke-Command -Session $s -ScriptBlock {...} und finden Sie Ihre benutzerdefinierten Funktionen - Sie werden es in einer Sitzung
Vorteile

Die folgenden sind gute Punkte für diesen Ansatz:
- ist es einfach - Sie don ' T haben, um zu wissen, über Modul Besonderheiten. Nur schreiben Sie einfachen PowerShell-Skripts und das ist es
- Sie nicht liefern alles, um die remote-Maschine - das macht die Lösung einfacher und weniger fehleranfällig in der Wartung
Nachteile

Sicher, es ist nicht ideal:
- es gibt weniger Kontrolle über die Lösung: zum Beispiel, wenn Sie "importieren" eine Reihe von Funktionen an, die Sitzung, alle von Ihnen sind "importiert" und für den Benutzer sichtbar, so dass keine "Verkapselung", etc. Ich bin sicher, viele Lösungen können live mit dabei, also nicht entscheiden, basierend auf diesem Punkt nur
- die Funktionalität in jeder Datei muss geschlossen sein - jeder "dot-sourcing" oder das Modul, importieren von dort wird die Suche nach dem remote-Rechner, nicht die lokale
Schließlich sollte ich sagen, dass die remote-Maschine muss noch vorbereitet werden für das remoting. Dies ist, was ich meine:
- execution policy geändert werden sollte, zu etwas, da es standardmäßig eingeschränkt: Set-ExecutionPolicy Unrestricted
- PowerShell-remoting aktiviert werden soll: Enable-PSRemoting
- das Konto das Skript ausgeführt wird, sollte Hinzugefügt werden, um die lokalen Administratoren der remote-server
- wenn Sie planen, um Zugriff auf Dateifreigaben in der remote-Sitzung, stellen Sie sicher, Sie sind sich bewusst über multi-hop-Authentifizierung und nehmen Sie die richtigen Maßnahmen
- stellen Sie sicher, Ihre antivirus ist dein Freund und nicht senden Sie die PowerShell Hölle
InformationsquelleAutor der Antwort Yan Sklyarenko

Hier ist ein anderer Ansatz: Erstellen Sie das Modul in einer remote-Sitzung, ohne kopieren von Dateien.

Ich habe keinerlei Versuch unternommen, zu bewältigen Abhängigkeiten zwischen Modulen gibt, aber das scheint zu funktionieren ok für einfache in sich geschlossene Module. Es stützt sich auf das Modul angeboten in der lokalen Sitzung, da dies macht die Bestimmung der Exporte einfacher, aber mit ein wenig Arbeit, es würde auch funktionieren mit einer Modul-Datei.

function Import-ModuleRemotely([string] $moduleName,[System.Management.Automation.Runspaces.PSSession] $session)
{
    $localModule = get-module $moduleName;
    if (! $localModule) 
    { 
        write-warning "No local module by that name exists"; 
        return; 
    }
    function Exports([string] $paramName, $dictionary) 
    { 
        if ($dictionary.Keys.Count -gt 0)
        {
            $keys = $dictionary.Keys -join ",";
            return " -$paramName $keys"
        }
    }
    $fns = Exports "Function" $localModule.ExportedFunctions;
    $aliases = Exports "Alias" $localModule.ExportedAliases;
    $cmdlets = Exports "Cmdlet" $localModule.ExportedCmdlets;
    $vars = Exports "Variable" $localModule.ExportedVariables;
    $exports = "Export-ModuleMember $fns $aliases $cmdlets $vars;";

    $moduleString= @"
if (get-module $moduleName)
{
    remove-module $moduleName;
}
New-Module -name $moduleName {
$($localModule.Definition)
$exports;
}  | import-module
"@
    $script = [ScriptBlock]::Create($moduleString);
    invoke-command -session $session -scriptblock $script;
}

InformationsquelleAutor der Antwort Rob

Ich glaube nicht, dass das unterstützt wird rechts neben dem Feld, ohne irgendwelche "hacks". Der smart move wäre wahrscheinlich zu setzen Sie das Modul auf einen öffentlichen Ort wie einen fileserver und importieren es auf dem server, wenn Sie es brauchen. Ex:

$session = new-pssession -computerName server01
invoke-command -session $session -scriptblock {
    #Set executionpolicy to bypass warnings IN THIS SESSION ONLY
    Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process
    #Import module from public location
    Import-Module \\fileserver\folders\modulelocation...


    <# use function defined in MyCustomModule here #> 
}

InformationsquelleAutor der Antwort Frode F.

Was macht Skriptblock aus der benutzerdefinierten Funktion und senden Sie ab terget Server mit Invoke-command

Import-module YourModule
$s = [scriptblock]::Create($(get-item Function:\Your-ModuleFunction).Definition)

Invoke-Command -ScriptBlock $s -Computername s1,s2,sn

InformationsquelleAutor der Antwort Jiří Soyka Domin

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.

- Module Ansatz

Vorteile

Nachteile

Scripts Ansatz

Vorteile

Nachteile