Ausführung eines Runbooks in Azure Automation

Mit der Prozessautomatisierung in Azure Automation können Sie PowerShell, PowerShell-Workflow und grafische Runbooks erstellen und verwalten. Ausführliche Informationen finden Sie unter Azure Automation Runbooks.

Automation führt Ihre Runbooks auf der Grundlage der in ihnen definierten Logik aus. Wenn ein Runbook unterbrochen wird, startet es am Anfang neu. Dieses Verhalten erfordert, dass Sie Runbooks schreiben, die einen Neustart unterstützen, wenn vorübergehende Probleme auftreten.

Wenn Sie ein Runbook in Azure Automation starten, wird ein Auftrag erstellt, bei dem es sich um eine einzelne Ausführungsinstanz des Runbook handelt. Jeder Auftrag greift auf Azure Ressourcen zu, indem eine Verbindung mit Ihrem Azure-Abonnement hergestellt wird. Der Auftrag hat nur Zugriff auf Ressourcen in Ihrem Rechenzentrum, wenn aus der öffentlichen Cloud auf diese Ressourcen zugegriffen werden kann.

Azure Automation weist einen Worker zu, um jeden Auftrag während der Ausführung des Runbooks zu bearbeiten. Wenngleich Worker von vielen Automation-Konten gemeinsam genutzt werden, sind die Aufträge von verschiedenen Automation-Konten voneinander isoliert. Sie können nicht steuern, welcher Workerdienst Ihre Auftragsanforderung verarbeitet.

Wenn Sie die Liste der Runbooks im Azure-Portal anzeigen, wird der Status jedes Auftrags angezeigt, der für jedes Runbook gestartet wurde. Azure Automation speichert Auftragsprotokolle für maximal 30 Tage.

Im folgenden Diagramm wird der Lebenszyklus eines Runbookauftrags für PowerShell-Runbooks, PowerShell-Workflow-Runbooks und grafische Runbooks gezeigt.

Ausführungsumgebung für Runbooks

Runbooks in Azure Automation können entweder auf einer Azure Sandbox oder einem Hybrid Runbook Worker ausgeführt werden.

Wenn Runbooks entwickelt sind, um Ressourcen in Azure zu authentifizieren und auf sie zuzugreifen, werden sie in einer Azure Sandbox ausgeführt. Azure Automation weist einen Worker zu, um jeden Auftrag während der Ausführung des Runbooks in der Sandbox auszuführen. Wenngleich Worker von vielen Automation-Konten gemeinsam genutzt werden, sind die Aufträge von verschiedenen Automation-Konten voneinander isoliert. Aufträge, die die gleiche Sandbox verwenden, werden durch die Ressourceneinschränkungen der Sandbox gebunden. Die Azure Sandkastenumgebung unterstützt keine interaktiven Vorgänge.

Sie können auch einen Hybrid Runbook Worker verwenden, um Runbooks direkt auf dem Computer, der die Rolle hostet, und mit lokalen Ressourcen in der Umgebung auszuführen. Azure Automation Speichert und verwaltet Runbooks und liefert sie dann an einen oder mehrere zugewiesene Computer.

Das Aktivieren der Azure Firewall für Azure Storage, Azure Key Vault oder Azure SQL blockiert den Zugriff von Azure Automation Runbooks für diese Dienste. Der Zugriff wird auch dann blockiert, wenn die Firewall-Ausnahme aktiviert ist, um vertrauenswürdige Microsoft-Dienste zuzulassen, da die Automatisierung nicht Teil der Liste der vertrauenswürdigen Dienste ist. Bei aktivierter Firewall kann der Zugriff nur mithilfe eines Hybrid Runbook Workers und eines VNT-Dienstendpunkts erfolgen.

In der folgenden Tabelle sind einige Runbook-Ausführungsaufgaben mit der jeweils empfohlenen Ausführungsumgebung aufgelistet.

Temporäre Speicherung in einer Sandbox

Wenn Sie temporäre Dateien als Teil Der Runbook-Logik erstellen müssen, können Sie den Ordner "Temp" (d. h. $env:TEMP) im Azure Sandkasten für Runbooks verwenden, die in Azure ausgeführt werden. Die einzige Einschränkung besteht darin, dass Sie nicht mehr als 1 GB Speicherplatz nutzen können, weil dies das zulässige Kontingent pro Sandbox ist. Bei der Arbeit mit PowerShell-Workflows kann dieses Szenario zu einem Problem führen, weil für PowerShell-Workflows Prüfpunkte verwendet werden und unter Umständen versucht wird, das Skript in einer anderen Sandbox auszuführen.

Mit der Hybrid-Sandbox können Sie C:\temp basierend auf der Verfügbarkeit des Speichers auf einem Hybrid Runbook Worker verwenden. Pro Azure VM-Empfehlungen sollten Sie jedoch nicht die temporäre Festplatte auf Windows oder Linux für Daten verwenden, die beibehalten werden müssen.

Ressourcen

Ihre Runbooks müssen Logik für die Verarbeitung von Ressourcen enthalten, z. B. VMs, Netzwerk und Ressourcen im Netzwerk. Ressourcen sind an ein Azure-Abonnement gebunden, und Runbooks erfordern geeignete Anmeldeinformationen für den Zugriff auf jede Ressource. Ein Beispiel für die Verarbeitung von Ressourcen in einem Runbook finden Sie unter Behandeln von Ressourcen.

Sicherheit

Azure Automation verwendet die Microsoft Defender for Cloud, um Sicherheit für Ihre Ressourcen bereitzustellen und Kompromittierungen in Linux-Systemen zu erkennen. Sicherheit wird über Ihre Workloads hinweg bereitgestellt, unabhängig davon, ob sich Ressourcen in Azure befinden oder nicht. Siehe Introduction to authentication in Azure Automation.

Defender for Cloud legt Einschränkungen für Benutzer fest, die skripts, entweder signiert oder nicht signiert, auf einem virtuellen Computer ausführen können. Wenn Sie ein Benutzer mit Rootzugriff auf eine VM sind, müssen Sie für den Computer explizit eine digitale Signatur konfigurieren oder diesen ausschalten. Andernfalls können Sie ein Skript zum Anwendungen von Betriebssystemupdates erst ausführen, nachdem Sie ein Automation-Konto erstellt und das entsprechende Feature aktiviert haben.

Abonnements

Eine Azure subscription ist eine Vereinbarung mit Microsoft, einen oder mehrere cloudbasierte Dienste zu verwenden, für die Sie in Rechnung gestellt werden. Sie können mehrere Abonnements über dasselbe Automatisierungskonto verwalten, wenn die von Ihnen verwendeten Anmeldeinformationen Zugriff auf mehrere Abonnements haben.

Anmeldeinformationen

Für ein Runbook sind geeignete Credentials erforderlich, um auf jede Ressource zuzugreifen, unabhängig davon, ob für Azure oder Drittanbietersysteme. Diese Anmeldeinformationen werden in Azure Automation, Key Vault usw. gespeichert.

Azure Monitor

Azure Automation können Azure Monitor für die Überwachung des Maschinenbetriebs nutzen.

Runbookberechtigungen

Ein Runbook benötigt Berechtigungen für die Authentifizierung zum Azure über Anmeldeinformationen. Siehe Azure Automation Authentifizierungsübersicht.

Module

Azure Automation enthält die folgenden PowerShell-Module:

• Orchestrator.AssetManagement.Cmdlets - enthält mehrere interne Cmdlets, die nur verfügbar sind, wenn Sie Runbooks in der Azure Sandkastenumgebung oder in einem Windows Hybrid Runbook Worker ausführen. Diese Cmdlets sind so konzipiert, dass sie anstelle von Azure PowerShell Cmdlets für die Interaktion mit Ihren Automatisierungskontoressourcen verwendet werden.
• Az.Automation – das empfohlene PowerShell-Modul für die Interaktion mit Azure Automation, das das AzureRM-Automatisierungsmodul ersetzt. Das Az.Automation-Modul ist nicht automatisch enthalten, wenn Sie ein Automatisierungskonto erstellen. Sie müssen es manuell importieren.
• AzureRM.Automation: Wird standardmäßig installiert, wenn Sie ein Automation-Konto erstellen

Außerdem werden installierbare Module unterstützt, die auf den Cmdlets basieren, die für Ihre Runbooks und DSC-Konfigurationen erforderlich sind. Ausführliche Informationen zu den Modulen, die für Ihre Runbooks- und DSC-Konfigurationen verfügbar sind, finden Sie unter Manage-Module in Azure Automation.

Zertifikate

Azure Automation verwendet Zertifikate für die Authentifizierung bei Azure oder um sie zu Azure- oder Drittanbieterressourcen hinzuzufügen. Die Zertifikate werden für den Zugriff durch Runbooks und DSC-Konfigurationen sicher gespeichert.

Ihre Runbooks können selbstsignierte Zertifikate verwenden, die nicht von einer Zertifizierungsstelle (CA) signiert sind. Weitere Informationen finden Sie unter Erstellen eines neuen Zertifikats.

Aufträge

Azure Automation unterstützt eine Umgebung zum Ausführen von Aufträgen aus demselben Automatisierungskonto. Für ein einzelnes Runbook können viele Aufträge gleichzeitig ausgeführt werden. Je mehr Aufträge Sie zur gleichen Zeit ausführen, desto häufiger können diese an dieselbe Sandbox weitergeleitet werden. Maximal 10 Aufträge können in einer Sandbox ausgeführt werden. Eine Sandbox wird entfernt, wenn keine Aufträge darin ausgeführt werden. Daher sollte sie nicht zum Speichern von Dateien verwendet werden.

Im selben Sandboxprozess ausgeführte Aufträge können sich gegenseitig beeinflussen. Ein Beispiel ist das Ausführen des Cmdlets Disconnect-AzAccount. Bei Ausführen dieses Cmdlets wird jeder Runbookauftrag im gemeinsam genutzten Sandboxprozess getrennt. Ein Beispiel für die Vorgehensweise bei diesem Szenario finden Sie unter Gleichzeitige Aufträge verhindern.

Auftragsstatuswerte

Die folgende Tabelle beschreibt die für einen Auftrag möglichen Status. Sie können eine Statuszusammenfassung für alle Runbookaufträge anzeigen oder Details zu einem bestimmten Runbookauftrag im Azure-Portal anzeigen. Sie können auch die Integration in Ihren Log Analytics-Workspace konfigurieren, um Runbook-Auftragsstatus und Auftragsstreams weiterzuleiten. Weitere Informationen zur Integration in Azure Monitor Logdaten lesen Sie unter Forward job status and job streams from Automation to Azure Monitor logs. Ein Beispiel für die Verwendung von Status in einem Runbook finden Sie unter Abrufen des Auftragsstatus.

Aktivitätsprotokollierung

Die Ausführung von Runbooks in Azure Automation schreibt Details in ein Aktivitätsprotokoll für das Automatisierungskonto. Ausführliche Informationen zur Verwendung des Protokolls finden Sie unter Abrufen von Details aus dem Aktivitätsprotokoll.

Ausnahmen

In diesem Abschnitt werden einige Möglichkeiten zur Behandlung von Ausnahmen oder zeitweiligen Problemen in Ihren Runbooks vorgestellt. Ein Beispiel hierfür ist eine WebSocket-Ausnahme. Durch die richtige Ausnahmebehandlung wird verhindert, dass vorübergehende Netzwerkausfälle zu Fehlern bei ihren Runbooks führen.

ErrorActionPreference

Die Variable ErrorActionPreference gibt an, wie PowerShell auf einen Fehler ohne Abbruch reagiert. Terminatorische Fehler führen immer zu einem Abbruch und werden nicht von ErrorActionPreference beeinflusst.

Bei Verwendung von ErrorActionPreference für das Runbook verhindert ein Fehler, der normalerweise nicht zu einem Abbruch führt (z. B. PathNotFound im Cmdlet Get-ChildItem), dass die Ausführung des Runbooks abgeschlossen wird. Im folgenden Beispiel wird die Verwendung von ErrorActionPreference veranschaulicht. Der abschließende Befehl Write-Output wird nie ausgeführt, da das Skript beendet wird.

$ErrorActionPreference = 'Stop'
Get-ChildItem -path nofile.txt
Write-Output "This message will not show"

Fangen Sie endlich ab

Try Catch Finally wird in PowerShell-Skripts verwendet, um Fehler mit Abbruch zu behandeln. Das Skript kann diesen Mechanismus nutzen, um spezifische oder allgemeine Ausnahmen abzufangen. Die catch-Anweisung sollte zum Nachverfolgen oder Behandeln von Fehlern verwendet werden. Im folgenden Beispiel wird versucht, eine Datei herunterzuladen, die es nicht gibt. Die Ausnahme System.Net.WebException wird abgefangen, und bei anderen Ausnahmen wird der letzte Wert zurückgegeben.

try
{
   $wc = new-object System.Net.WebClient
   $wc.DownloadFile("http://www.contoso.com/MyDoc.doc")
}
catch [System.Net.WebException]
{
    "Unable to download MyDoc.doc from http://www.contoso.com."
}
catch
{
    "An error occurred that could not be resolved."
}

Throw

Mit Throw können Sie einen Fehler mit Abbruch generieren. Dies kann nützlich sein, wenn Sie in einem Runbook eigene Logik definieren. Wenn das Skript ein Kriterium für die Beendigung erfüllt, kann es zum Beenden die throw-Anweisung verwenden. Das folgende Beispiel verwendet diese Anweisung, um einen erforderlichen Funktionsparameter zu zeigen.

function Get-ContosoFiles
{
  param ($path = $(throw "The Path parameter is required."))
  Get-ChildItem -Path $path\*.txt -recurse
}

Errors

In Ihren Runbooks müssen Fehler behandelt werden. Azure Automation unterstützt zwei Arten von PowerShell-Fehlern: beendende und nicht-beendende Fehler.

Bei Fehlern mit Abbruch wird die Runbookausführung beendet, sobald sie auftreten. Das Runbook wird mit dem Auftragsstatus „Fehler“ angehalten.

Fehler ohne Abbruch ermöglichen einem Skript, auch nach ihrem Auftreten fortzufahren. Ein Beispiel für einen Fehler ohne Abbruch ist ein Fehler, der auftritt, wenn ein Runbook das Cmdlet Get-ChildItem mit einem nicht vorhandenen Pfad verwendet. PowerShell erkennt, dass der Pfad nicht vorhanden ist, löst einen Fehler aus und fährt mit dem nächsten Ordner fort. Vom Fehler wird der Status des Runbookauftrags in diesem Fall nicht auf „Fehler“ festgelegt, sodass der Auftrag unter Umständen sogar abgeschlossen wird. Um ein Runbook zu veranlassen, bei einem Fehler ohne Abbruch anzuhalten, können Sie ErrorAction Stop für das Cmdlet verwenden.

Aufrufen von Prozessen

Runbooks, die in Azure Sandkasten ausgeführt werden, unterstützen keine Aufrufprozesse wie ausführbare Dateien (.exeDateien) oder Unterverarbeitungen. Der Grund dafür ist, dass ein Azure Sandkasten ein freigegebener Prozess ist, der in einem Container ausgeführt wird, der möglicherweise nicht auf alle zugrunde liegenden APIs zugreifen kann. Für Szenarien, die Software von Drittanbietern oder Aufrufe von Unterprozessen erfordern, sollten Sie das Runbook in einem Hybrid Runbook Worker ausführen.

Geräte- und Anwendungsmerkmale

Runbookaufträge in Azure-Sandboxen können nicht auf Geräte- oder Anwendungsmerkmale zugreifen. Die am häufigsten verwendete API zum Abfragen von Leistungsmetriken für Windows ist WMI, wobei einige der allgemeinen Metriken Arbeitsspeicher und CPU-Auslastung sind.

webhooks

Externe Dienste, z. B. Azure DevOps Dienste und GitHub, können ein Runbook in Azure Automation starten. Für diese Art des Starts verwendet der Dienst einen Webhook über eine einzige HTTP-Anforderung. Die Verwendung eines Webhooks ermöglicht das Starten von Runbooks ohne Implementierung eines vollständigen Azure Automation Features.

Gemeinsame Ressourcen

Um Ressourcen für alle Runbooks in der Cloud freizugeben, verwendet Azure ein Konzept namens fairer Freigabe. Unter Verwendung des Fair-Share-Verfahrens entlädt oder stoppt Azure vorübergehend jeden Auftrag, der länger als drei Stunden ausgeführt wurde. Aufträge für PowerShell-Runbooks und Python Runbooks werden beendet und nicht neu gestartet, und der Auftragsstatus wird beendet.

Für lang andauernde Azure-Automation-Aufgaben wird empfohlen, einen Hybrid Runbook Worker zu verwenden. Hybrid Runbook Worker unterliegen nicht der gleichmäßigen Verteilung und keiner Einschränkung hinsichtlich der Ausführungszeit eines Runbooks. Die anderen Beschränkungen gelten sowohl für Azure-Sandboxen als auch für Hybrid-Runbook-Worker. Für Hybrid Runbook Worker gilt zwar nicht die dreistündige Begrenzung für die gleichmäßige Verteilung, aber Sie sollten Runbooks für die Ausführung auf den Workern entwickeln, die einen Neustart nach unerwarteten lokalen Infrastrukturproblemen unterstützen.

Eine weitere Möglichkeit ist das Optimieren eines Runbooks durch Verwendung untergeordneter Runbooks. Beispielsweise kann Ihr Runbook die gleiche Funktion auf mehreren Ressourcen durchlaufen, z. B. bei einem Datenbankvorgang in mehreren Datenbanken. Sie können diese Funktion in ein untergeordnetes Runbook verschieben und veranlassen, dass Ihr Runbook es mit Start-AzAutomationRunbook aufruft. Untergeordnete Runbooks werden in separaten Prozessen parallel ausgeführt.

Das Verwenden untergeordneter Runbooks führt dazu, dass die Gesamtdauer der Verarbeitung für das übergeordnete Runbook verringert wird. Ihr Runbook kann mit dem Cmdlet Get-AzAutomationJob den Auftragsstatus für ein untergeordnetes Runbook überprüfen, wenn nach Abschluss des untergeordneten Runbooks noch Vorgänge erfolgen müssen.

Nächste Schritte

• Informationen zu den ersten Schritten mit PowerShell-Runbooks finden Sie unter Tutorial: Erstellen eines PowerShell-Runbooks.
• Informationen zum Arbeiten mit Runbooks finden Sie unter Manage runbooks in Azure Automation.
• Details zu PowerShell finden Sie in der PowerShell-Dokumentation.
• Eine Referenz zu den PowerShell-Cmdlets finden Sie unter Az.Automation.
• Informationen zur Problembehandlung im Zusammenhang mit geteilten Ressourcen während der Ausführung von Azure Automation Runbooks finden Sie unter Problembehandlung bei Azure Automation-Problemen mit geteilten Ressourcen.
• Informationen zur Problembehandlung bei der Ausführung von Azure Automation-Runbooks finden Sie unter Troubleshoot Runbook-Probleme.