Windows PowerShell-Workflow-Konzepte
Ein Typ von Runbook für Service Management Automation basiert auf Windows PowerShell-Workflows. Dieser Artikel stellt einen kurzen Überblick über die wichtigsten Merkmale von Workflows bereit, die bei Automation-Runbooks üblich sind. Vollständige Details zu Workflows finden Sie in Starten mit Windows PowerShell-Workflow.
Die Struktur der Runbooks für Service Management Automation und für Microsoft Azure Automation ist identisch, obwohl die beiden normalerweise mit unterschiedlichen Ressourcen arbeiten.
Windows PowerShell-Workflows
Bei einem Workflow handelt es sich um eine Sequenz von programmierten, zusammenhängenden Schritten, mit denen zeitaufwendige Aufgaben ausgeführt werden oder für die mehrere Schritte auf mehreren Geräten oder verwalteten Knoten koordiniert werden müssen. Die Vorteile eines Workflows gegenüber einem normalen Skript liegen darin, dass eine Aktion gleichzeitig für mehrere Geräte ausgeführt und bei Auftreten von Fehlern eine automatische Wiederherstellung durchgeführt werden kann. Ein Windows PowerShell-Workflow ist ein Windows PowerShell-Skript, das Windows Workflow Foundation nutzt. Während der Workflow mit Windows PowerShell-Syntax geschrieben und von Windows PowerShell gestartet wird, wird er von Windows Workflow Foundation verarbeitet.
Grundlegende Struktur
Ein Windows PowerShell-Workflow beginnt mit dem Schlüsselwort Workflow, gefolgt vom Hauptteil des Skripts in Klammern. Auf das Schlüsselwort Workflow folgt der Name des Workflows, wie in der folgenden Syntax gezeigt. Der Name des Workflows entspricht dem Namen des Automation-Runbook.
Workflow Test-Runbook
{
<Commands>
}
Um dem Workflow Parameter hinzuzufügen, verwenden Sie das Schlüsselwort Param, wie in der folgenden Syntax dargestellt. Das Verwaltungsportal wird den Benutzenden beim Starten des Runbooks auffordern, Werte für diese Parameter bereitzustellen. In diesem Beispiel wird das optionale Parameter-Attribut verwendet, das angibt, ob der Parameter obligatorisch ist.
Workflow Test-Runbook
{
Param
(
[Parameter(Mandatory=<$True | $False>]
[Type]$<ParameterName>,
[Parameter(Mandatory=<$True | $False>]
[Type]$<ParameterName>
)
<Commands>
}
Benennung
Der Name des Workflows sollte dem Verb-Nomen-Format entsprechen, das in Windows PowerShell Standard ist. Unter Zugelassene Verben für Windows PowerShell-Befehle finden Sie eine Liste der zugelassenen Verben. Der Name des Workflows muss mit dem Namen des Automation-Runbooks übereinstimmen. Wenn das Runbook importiert wird, muss der Dateiname mit dem Workflownamen übereinstimmen und auf .ps1 enden.
Begrenzungen
Eine vollständige Liste der Einschränkungen und Syntaxunterschiede zwischen Windows PowerShell Workflows und Windows PowerShell finden Sie unter Syntaktische Unterschiede zwischen Script-Workflows und Scripts.
Aktivitäten
Eine Aktivität ist eine bestimmte Aufgabe in einem Workflow. Ebenso wie ein Skript aus einem oder mehreren Befehlen zusammengesetzt ist, setzt sich ein Workflow aus einer oder mehreren Aktivitäten zusammen, die in einer bestimmten Reihenfolge ausgeführt werden. Windows PowerShell Workflow konvertiert viele der Windows PowerShell-Cmdlets automatisch in Aktivitäten, wenn ein Workflow ausgeführt wird. Wenn Sie eines dieser Cmdlets in Ihrem Runbook angeben, wird von Windows Workflow Foundation tatsächlich die entsprechende Aktivität ausgeführt. Bei Cmdlets ohne entsprechende Aktivität führt Windows PowerShell-Workflow das Cmdlet automatisch innerhalb einer InlineScript-Aktivität aus. Es gibt eine Reihe von Cmdlets, die ausgeschlossen sind und nicht in einem Workflow verwendet werden können, es sei denn, Sie schließen sie ausdrücklich in einen InlineScript-Block ein. Weitere Informationen zu diesen Konzepten finden Sie unter Verwendung von Aktivitäten in Script-Workflows.
Workflowaktivitäten teilen sich einen Satz allgemeiner Parameter, um ihren Betrieb zu konfigurieren. Ausführliche Informationen zu den allgemeinen Workflowparametern finden Sie unter about_WorkflowCommonParameters.
Integrationsmodule
Ein Integrationsmodul ist ein Paket, das ein Windows PowerShell-Modul enthält und in Automation importiert werden kann. Windows PowerShell-Module enthalten Cmdlets, die in Automation-Runbooks verwendet werden können. Produkte und Dienste wie Operations Manager und Azure verfügen über Module, die spezielle Cmdlets für ihren Betrieb enthalten.
Integrationsmodule, die in Automation importiert werden, sind automatisch für alle Runbooks verfügbar. Da die Automatisierung auf Windows PowerShell 4.0 basiert, unterstützt sie das automatische Laden von Modulen, was bedeutet, dass Cmdlets aus installierten Modulen verwendet werden können, ohne sie mit Import-Module in das Skript zu importieren.
Jedes Windows PowerShell-Modul kann in die Automatisierung importiert werden, solange sich alle seine Abhängigkeiten in einem einzigen Ordner befinden. Wenn das Modul von Registrierungseinstellungen oder Dateien abhängt, die sich nicht im Standardpfad befinden, kann es zwar importiert werden, aber es wird höchstwahrscheinlich nicht funktionieren, da die Automatisierung nicht in der Lage sein wird, die Abhängigkeiten zu finden. Module mit externen Abhängigkeiten können in einem Runbook verwendet werden, indem man sie auf einem anderen Host installiert und dann mit einem InlineScript-Skriptblock auf sie zugreift.
Mit Service Management Automation können Sie Module mit externen Abhängigkeiten verwenden, indem Sie sie auf jedem Worker-Server installieren. Die Cmdlets in diesen Modulen können zwar in Runbooks verwendet werden, werden aber von Automation nicht erkannt, um Funktionen wie den Assistenten zum Einfügen von Aktivitäten zu unterstützen. Um diese Funktion zu nutzen, können Sie mit dem Cmdlet New-SmaPortableModule ein portables Modul erstellen. Mit diesem Cmdlet wird ein Modul erstellt, das einen Stub für jedes seiner Cmdlets enthält und in Automation importiert werden kann. Wenn ein Runbook eines dieser Cmdlets verwendet, leitet der Stub den Aufruf an das eigentliche Cmdlet im externen Modul um. Dieses Modul muss auf jedem Worker-Server installiert sein, sonst schlägt der Aufruf fehl.
Parallelausführung
Ein Vorteil von Windows PowerShell-Workflows besteht darin, dass sie einen Satz an Befehlen parallel – und nicht wie in einem typischen Skript sequenziell – ausführen können. Dies ist vor allem bei Runbooks nützlich, da sie mehrere Aktionen ausführen können, deren Abschluss eine erhebliche Zeit in Anspruch nimmt. Ein Runbook könnte beispielsweise eine Reihe virtueller Computer festlegen. Anstatt die einzelnen Bereitstellungsvorgänge nacheinander auszuführen, könnten sie gleichzeitig durchgeführt werden, was die Gesamteffizienz erhöht. Erst wenn alle abgeschlossen sind, wird das Runbook fortgesetzt.
Sie können mit dem Schlüsselwort Parallel einen Skriptblock mit mehreren Befehlen erstellen, die gleichzeitig ausgeführt werden. Diese Methode wird in der nachstehend gezeigten Syntax verwendet. In diesem Fall starten "Activity1" und "Activity2" gleichzeitig. "Activity3" startet erst, wenn sowohl "Activity1" als auch "Activity2" abgeschlossen wurden.
Parallel
{
<Activity1>
<Activity2>
}
<Activity3>
Sie können das Konstrukt ForEach -Parallel verwenden, um Befehle für jedes Element in einer Auflistung gleichzeitig zu verarbeiten. Die Elemente in der Auflistung werden parallel ausgeführt, während die Befehle im Skriptblock sequenziell ausgeführt werden. Diese Methode wird in der nachstehend gezeigten Syntax verwendet. In diesem Fall startet Aktivität1 für alle Elemente der Sammlung zum gleichen Zeitpunkt. "Activity2" wird für alle Elemente gestartet, nachdem "Activity1" abgeschlossen wurde. Aktivität3 wird erst gestartet, wenn Aktivität1 und Aktivität2 für alle Elemente abgeschlossen sind.
ForEach -Parallel ($<item> in $<collection>)
{
<Activity1>
<Activity2>
}
<Activity3>
Das Schlüsselwort Sequenz wird verwendet, um Befehle innerhalb eines Parallel-Skriptblocks nacheinander auszuführen. Der Skriptblock Sequenz läuft parallel zu anderen Befehlen, aber die Befehle innerhalb des Blocks laufen nacheinander ab. Diese Methode wird in der nachstehend gezeigten Syntax verwendet. In diesem Fall starten Aktivität1, Aktivität2 und Aktivität3 zur gleichen Zeit. Aktivität4 wird erst gestartet, wenn Aktivität3 abgeschlossen ist. Aktivität5 wird gestartet, nachdem alle anderen Aktivitäten abgeschlossen sind
Parallel
{
<Activity1>
<Activity2>
Sequence
{
<Activity3>
<Activity4>
}
}
<Activity5>
Prüfpunkte
Ein Prüfpunkt ist eine Momentaufnahme des aktuellen Zustands des Workflows, der den aktuellen Wert für Variablen und sämtliche Ausgaben einschließt, die bis zu diesem Punkt generiert wurden. Der letzte in einem Runbook abgeschlossene Checkpoint wird in der Automation-Datenbank gespeichert, sodass der Workflow auch im Falle eines Ausfalls fortgesetzt werden kann. Die Checkpoint-Daten werden entfernt, sobald der Runbook-Auftrag abgeschlossen ist.
Sie können mithilfe der Aktivität Checkpoint-Workflow einen Prüfpunkt in einem Workflow setzen. Wenn Sie diese Aktivität in ein Runbook aufnehmen, wird sofort ein Checkpoint gesetzt. Wenn das Runbook aufgrund eines Fehlers unterbrochen wird, wird es bei der Wiederaufnahme des Auftrags an dem Punkt fortgesetzt, an dem der letzte Checkpoint festgelegt wurde.
Im folgenden Beispielcode tritt nach Aktivität2 ein Fehler auf, der dazu führt, dass das Runbook unterbrochen wird. Wenn der Auftrag wieder aufgenommen wird, startet er mit der Ausführung von Aktivität2, da diese unmittelbar nach dem letzten festgelegten Checkpoint stattfand.
<Activity1>
Checkpoint-Workflow
<Activity2>
<Error>
<Activity3>
Sie sollten in einem Runbook Checkpoints nach Aktivitäten festlegen, die fehleranfällig sein können und bei einer Fortsetzung des Runbook nicht wiederholt werden sollten. Ihr Runbook kann zum Beispiel einen virtuellen Computer erstellen. Sie können sowohl vor als auch nach den Befehlen zum Erstellen des virtuellen Computers einen Prüfpunkt setzen. Wenn die Erstellung fehlgeschlagen ist, werden die Befehle bei der Wiederaufnahme des Runbooks wiederholt. Wenn die Erstellung erfolgreich ist, das Runbook aber später fehlschlägt, wird das virtuelle Gerät bei der Wiederaufnahme des Runbook nicht erneut erstellt.
Weitere Informationen zu Prüfpunkten finden Sie unter Hinzufügen von Prüfpunkten zu einem Skriptworkflow.
Unterbrechen eines Runbook
Mit der Aktivität Suspend-Workflow können Sie erzwingen, dass ein Runbook sich selbst unterbricht. Mit dieser Aktivität wird ein Checkpoint festgelegt und der Workflow sofort unterbrochen. Das Unterbrechen eines Workflows ist nützlich für Runbooks, bei denen ein manueller Schritt erforderlich ist, bevor eine andere Reihe von Aktivitäten ausgeführt werden kann.
Weitere Informationen zum Unterbrechen eines Workflows finden Sie unter Workflow selbst unterbrechen.
InlineScript
Die InlineScript-Aktivität führt einen Block von Befehlen in einer separaten, nicht zum Workflow gehörenden Sitzung aus und gibt seine Ausgabe an den Workflow zurück. Wenngleich die Befehle in einem Workflow zur Verarbeitung an Windows Workflow Foundation gesendet werden, werden die Befehle in einem InlineScript-Block durch Windows PowerShell verarbeitet. Die Aktivität verwendet die gängigen Standardparameter des Workflows, darunter PSComputerName und PSCredential, mit denen Sie angeben können, dass der Codeblock auf einem anderen Computer oder mit anderen Anmeldeinformationen ausgeführt werden soll.
Der InlineScript-Block verwendet die nachstehende Syntax.
InlineScript
{
<Script Block>
} <Common Parameters>
Die gängigste Verwendung für InlineScript in einem Runbook ist die Ausführung eines Codeblocks auf einem anderen Computer. Dies ist erforderlich, wenn Cmdlets in Ihrem Runbook nicht in Automation installiert sind oder wenn die Aktion nur lokal auf dem Zielcomputer ausgeführt werden darf. Dies wird in der folgenden Abbildung veranschaulicht.
Um den Codeblock auf einem anderen Computer auszuführen, werden die Parameter PSComputer und PSCredential mit der Aktivität InlineScript verwendet. Um Werte für diese Parameter bereitzustellen, wird in einem Runbook normalerweise eine globale Ressource wie eine Anmeldeinformation oder eine Verbindung verwendet. Der folgende Beispielcode führt eine Reihe von Befehlen auf einem Computer aus, der durch eine Verbindung namens MyConnection repräsentiert wird.
$con = Get-AutomationConnection -Name 'MyConnection'
$securepassword = ConvertTo-SecureString -AsPlainText -String $con.Password -Force
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $con.Username, $securepassword
InlineScript
{
<Commands>
} -PSComputer $con.ComputerName -PSCredential $cred
Obwohl InlineScript-Aktivitäten in bestimmten Runbooks von entscheidender Bedeutung sein können, sollten sie aus den folgenden Gründen nur bei Bedarf eingesetzt werden:
Sie können Checkpoints nicht innerhalb eines InlineScript-Blocks verwenden. Tritt innerhalb des Blocks ein Fehler auf, muss er von Anfang an wieder aufgenommen werden.
InlineScript beeinträchtigt die Skalierbarkeit des Runbook, da es die Windows PowerShell-Sitzung über die gesamte Länge des InlineScript-Blocks aufrechterhält.
Aktivitäten wie Get-AutomationVariable und Get-AutomationPSCredential sind in einem InlineScript-Block nicht verfügbar.
Wenn Sie ein InlineScript verwenden müssen, sollten Sie dessen Geltungsbereich minimieren. Wenn Ihr Runbook beispielsweise eine Sammlung durchläuft und dabei auf jedes Element dieselbe Operation anwendet, sollte die Schleife außerhalb des InlineScript auftreten. Dies wird folgende Vorteile bieten:
Sie können den Workflow nach jedem Durchlauf prüfen. Wenn der Job angehalten oder unterbrochen und fortgesetzt wird, kann die Schleife fortgesetzt werden.
Sie können ForEach „Parallel verwenden, um Elemente der Sammlung gleichzeitig zu verarbeiten.
Beachten Sie die folgenden Empfehlungen, wenn Sie ein InlineScript in Ihrem Runbook verwenden:
Sie können jedoch mit dem Bereichsmodifikator $Using Werte an das Skript übergeben. Zum Beispiel würde eine Variable namens $abc, die außerhalb des InlineScripts festgelegt wurde, zu $using:abc innerhalb eines InlineScript.
Um die Ausgabe eines Inline-Script zurückzugeben, weisen Sie die Ausgabe einer Variablen zu und geben alle Daten, die zurückgegeben werden sollen, in den Ausgabestream aus. Das folgende Beispiel weist die Zeichenfolge hi einer Variablen namens $output zu.
$output = InlineScript { Write-Output "hi" }Vermeiden Sie es, Workflows im Geltungsbereich von InlineScript zu definieren. Auch wenn einige Workflows korrekt zu funktionieren scheinen, handelt es sich nicht um ein getestetes Szenario. Infolgedessen kann es zu verwirrenden Fehlermeldungen oder unerwartetem Verhalten kommen.
Weitere Informationen zur Verwendung von InlineScript finden Sie unter Ausführen von Windows PowerShell-Befehlen in einem Workflow und über_InlineScript.