Azure Automation-Runbooktypen

Das Prozessautomatisierungsfeature von Azure Automation unterstützt verschiedene Runbooktypen, die in der folgenden Tabelle definiert sind. Weitere Informationen zur Prozessautomatisierungsumgebung finden Sie unter Ausführen von Runbooks in Azure Automation.

type	Beschreibung
PowerShell	Textrunbook, das auf einem Windows PowerShell-Skript basiert. Die derzeit unterstützten Versionen sind PowerShell 7.2 (GA) und PowerShell 5.1 (GA). Da PowerShell 7.1 nicht mehr von PowerShell im übergeordneten Produkt unterstützt wird, wird empfohlen, Runbooks in der langfristig unterstützten Version 7.2 von PowerShell zu erstellen
PowerShell-Workflow	Textrunbook, das auf einem Windows PowerShell-Workflowskript basiert.
Python	Textrunbook, das auf einem Python-Skript basiert. Die derzeit unterstützten Versionen sind Python 3.8 (GA) und Python 3.10 (Vorschau). Da Python 2.7 nicht mehr von Python im übergeordneten Produkt unterstützt wird, wird empfohlen, Runbooks in langfristig unterstützten Versionen zu erstellen.
Grafisch	Grafisches Runbook, das auf Windows PowerShell basiert und vollständig im grafischen Editor im Azure-Portal erstellt und bearbeitet wird.
PowerShell-Workflow, grafisch	Grafisches Runbook, das auf dem Windows PowerShell-Workflow basiert und vollständig im grafischen Editor im Azure-Portal erstellt und bearbeitet wird.

Hinweis

Azure Automation folgt dem Supportlebenszyklus von PowerShell- und Python-Sprachversionen entsprechend den Zeitachsen, die für PowerShell und Python in den übergeordneten Produkten veröffentlicht werden. Es wird empfohlen, Runbooks mit unterstützten Sprachversionen zu verwenden.

Wenn Sie festlegen, welchen Typ Sie für ein bestimmtes Runbook verwenden möchten, müssen Sie Folgendes berücksichtigen.

• Runbooks können nicht aus einem grafischen in einen textbasierten Typ oder umgekehrt konvertiert werden.
• Es gibt Einschränkungen bei der Verwendung von Runbooks verschiedener Typen als untergeordnete Runbooks. Weitere Informationen finden Sie unter Untergeordnete Runbooks in Azure Automation.

PowerShell-Runbooks

PowerShell-Runbooks basieren auf Windows PowerShell. Sie bearbeiten den Code des Runbooks direkt mit dem Text-Editor im Azure-Portal. Sie können auch einen beliebigen Offline-Texteditor verwenden und das Runbook in Azure Automation importieren .

Die PowerShell-Version wird durch die angegebene Runtimeversion bestimmt (d. h. Version 7.2, 7.1 (Vorschau) oder Version 5.1).

Derselbe Azure-Sandbox- und Hybrid-Runbook-Worker kann mehrere PowerShell-Runbooks für verschiedene Laufzeitversionen nebeneinander ausführen.

Hinweis

• Derzeit wird die PowerShell 7.2-Laufzeitversion für Cloud- und Hybridaufträge in allen öffentlichen Regionen mit Ausnahme von „Indien, Mitte“, „VAE, Mitte“, „Israel, Mitte“, „Italien, Norden“ und „Deutschland, Norden“ unterstützt.
• Wenn Sie bei der Ausführung des Runbooks die Runtimeversion 7.2 auswählen, werden PowerShell-Module verwendet, die auf die Runtimeversion 7.2 ausgerichtet sind, und wenn Sie die Runtimeversion 5.1 auswählen, werden PowerShell-Module verwendet, die auf die Runtimeversion 5.1 ausgerichtet sind. Dies gilt für PowerShell 7.1 (Vorschau)-Module und -Runbooks.

Stellen Sie sicher, dass Sie die richtige Runtimeversion für Module auswählen.

Beispiel: Wenn Sie ein Runbook für ein SharePoint-Automatisierungsszenario in Laufzeitversion 7.1 (Vorschau) ausführen, dann importieren Sie das Modul in Laufzeitversion 7.1 (Vorschau). Wenn Sie ein Runbook für ein SharePoint-Automatisierungsszenario in Laufzeitversion 5.1 ausführen, dann importieren Sie das Modul in Laufzeitversion 5.1. In diesem Fall sehen Sie zwei Einträge für das Modul, einen für Runtimeversion 7.1 (Vorschauversion) und einen für 5.1.

Hinweis

Derzeit werden PowerShell 5.1, PowerShell 7.1 (Vorschau) und PowerShell 7.2 unterstützt.

Vorteile

• Implementierung der gesamten komplexen Logik mit PowerShell-Code ohne die zusätzliche Komplexität des PowerShell-Workflows.
• Schnellerer Start als PowerShell-Workflow-Runbooks, da vor der Ausführung keine Kompilierung erforderlich ist
• Werden in Azure und in Hybrid Runbook Workern sowohl für Windows als auch für Linux ausgeführt

Einschränkungen und bekannte Probleme

Im Folgenden sind die aktuellen Einschränkungen von sowie bekannten Probleme mit PowerShell-Runbooks aufgeführt:

PowerShell 7.2

Einschränkungen

Hinweis

Derzeit wird die PowerShell 7.2-Laufzeitversion für Cloud- und Hybridaufträge in allen öffentlichen Regionen mit Ausnahme von „Indien, Mitte“, „VAE, Mitte“, „Israel, Mitte“, „Italien, Norden“ und „Deutschland, Norden“ unterstützt.

• Für die PowerShell 7.2-Runtimeversion werden die Modulaktivitäten nicht für die importierten Module extrahiert. Verwenden Sie die Azure Automation-Erweiterung für VS-Code, um die Erstellung von Runbooks zu vereinfachen.
• PowerShell 7.x unterstützt keine Workflows. Weitere Informationen finden Sie im PowerShell-Workflow für weitere Details.
• PowerShell 7.x unterstützt derzeit keine signierten Runbooks.
• Die Integration der Quellcodeverwaltung unterstützt PowerShell 7.2 nicht. Außerdem werden PowerShell 7.2-Runbooks in der Quellcodeverwaltung im Automation-Konto als Runtime 5.1 erstellt.
• Az-Modul 8.3.0 ist standardmäßig installiert. Die vollständige Liste der Komponentenmodule der ausgewählten Az-Modulversion wird angezeigt, sobald die Az-Version erneut mithilfe des Azure-Portals oder der API konfiguriert ist.
• Das importierte PowerShell 7.2-Modul würde während der Auftragsausführung überprüft. Stellen Sie sicher, dass alle Abhängigkeiten für das ausgewählte Modul für eine erfolgreiche Auftragsausführung ebenfalls importiert werden.
• Das Azure-Runbook unterstützt Start-Job mit -credential nicht.
• Azure unterstützt nicht alle PowerShell-Eingabeparameter. Weitere Informationen

Bekannte Probleme

• Runbooks, die von internen Dateipfaden abhängig sind, z. B. C:\modules, können aufgrund von Änderungen in der Dienst-Back-End-Infrastruktur fehlschlagen. Ändern Sie den Runbook-Code, um sicherzustellen, dass keine Abhängigkeiten von internen Dateipfaden vorhanden sind, und verwenden Sie Get-ChildItem, um die erforderlichen Modulinformationen abzurufen.

• Das Get-AzStorageAccount-Cmdlet kann aufgrund eines Fehlers fehlschlagen: Der Get-AzStorageAccount-Befehl wurde im Modul Az.Storage gefunden, aber das Modul konnte nicht geladen werden.

• Das Ausführen von untergeordneten Skripts mithilfe von .\child-runbook.ps1 wird nicht unterstützt.
  Alternative Lösung: Verwenden Sie Start-AutomationRunbook (internes Cmdlet) oder Start-AzAutomationRunbook (aus dem Modul Az.Automation), um ein weiteres Runbook aus dem übergeordneten Runbook zu starten.

• Wenn Sie das ExchangeOnlineManagement Modul in der Version 3.0.0 oder höher verwenden, können Fehler auftreten. Um das Problem zu beheben, stellen Sie sicher, dass Sie die PowerShellGet- und PackageManagement-Module explizit hochladen.

• Wenn Sie das New-AzAutomationVariable-Cmdlet in Az.Automation-Modul verwenden, um eine Variable vom Typ Objekt hochzuladen, funktioniert der Vorgang nicht wie erwartet.

  Problemumgehung: Konvertieren Sie das Objekt mithilfe des Cmdlets ConvertTo-Json in eine JSON-Zeichenfolge, und laden Sie dann die Variable mit der JSON-Zeichenfolge als Wert hoch. Diese Problemumgehung stellt sicher, dass die Variable innerhalb der Azure Automation-Umgebung ordnungsgemäß als JSON-Zeichenfolge behandelt wird.

  Beispiel: Erstellen eines PowerShell-Objekts, auf dem Informationen zu Azure-VMs gespeichert sind

    # Retrieve Azure virtual machines with status information for the 'northeurope' region 
    $AzVM = Get-AzVM -Status | Where-Object {$_.Location -eq "northeurope"} 
  
    $VMstopatch = @($AzVM).Id 
    # Create an Azure Automation variable (This cmdlet will not fail, but the variable may not work as intended when used in the runbook.) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $VMstopatch 
  
    # Convert the object to a JSON string 
    $jsonString = $VMstopatch | ConvertTo-Json 
  
    # Create an Azure Automation variable with a JSON string value (works effectively within the automation runbook) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $jsonString 
  

PowerShell 5.1

Einschränkungen

• Können keine parallele Verarbeitung zum gleichzeitigen Ausführen mehrerer Aktionen nutzen
• Können keine Prüfpunkte zum Fortsetzen des Runbooks bei einem Fehler nutzen
• Sie können nur PowerShell-, PowerShell-Workflow- und grafische Runbooks mithilfe des Cmdlets Start-AzAutomationRunbook als untergeordnete Runbooks einfügen, wobei ein neuer Auftrag erstellt wird.
• Für Runbooks kann die PowerShell-Anweisung #Requires nicht verwendet werden. Sie wird in der Azure-Sandbox und für Hybrid Runbook Workers nicht unterstützt und führt möglicherweise dazu, dass für den Auftrag ein Fehler auftritt.
• Das Azure-Runbook unterstützt Start-Job mit -credential nicht.
• Azure unterstützt nicht alle PowerShell-Eingabeparameter. Weitere Informationen

Bekannte Probleme

• Runbooks, die von internen Dateipfaden abhängig sind, z. B. C:\modules, können aufgrund von Änderungen in der Dienst-Back-End-Infrastruktur fehlschlagen. Ändern Sie den Runbook-Code, um sicherzustellen, dass keine Abhängigkeiten von internen Dateipfaden vorhanden sind, und verwenden Sie Get-ChildItem, um die erforderlichen Modulinformationen abzurufen.

  Beispielskript

  
  # Get information about module "Microsoft.Graph.Authentication"
  $ModuleName = "Microsoft.Graph.Authentication"
  
  $NewPath = "C:\usr\src\PSModules\$ModuleName"
  $OldPath = "C:\Modules\User\$ModuleName"
  
  if (Test-Path -Path $NewPath -PathType Container) {
      Get-ChildItem -Path $NewPath
  } elseif (Test-Path -Path $OldPath -PathType Container) {
      Get-ChildItem -Path $OldPath
  } else {
      Write-Output "Module $ModuleName not present."
  }
  # Getting the path to the Temp folder, if needed.
  $tmp = $env:TEMP
  
  

• Das Get-AzStorageAccount-Cmdlet kann aufgrund eines Fehlers fehlschlagen: Der Get-AzStorageAccount-Befehl wurde im Modul Az.Storage gefunden, aber das Modul konnte nicht geladen werden.

• PowerShell-Runbooks können keine unverschlüsselten Variablenobjekte mit einem NULL-Wert abrufen.

• PowerShell-Runbooks können kein Variablenobjekt abrufen, dessen Name *~* enthält.

• Der Vorgang Get-Process in einer Schleife in einem PowerShell-Runbook kann nach etwa 80 Iterationen zum Absturz führen.

• Ein PowerShell-Runbook kann einen Fehler verursachen, wenn es versucht, eine große Datenmenge auf einmal in den Ausgabestream zu schreiben. Sie können dieses Problem in der Regel vermeiden, indem Sie nur die für die Arbeit mit großen Objekten benötigten Informationen in die Runbookausgabe einfügen. Anstatt Get-Process ohne Einschränkungen zu verwenden, können Sie z. B. nur die erforderlichen Parameter in die Cmdlet-Ausgabe einfügen wie bei Get-Process | Select ProcessName, CPU.

• Wenn Sie das ExchangeOnlineManagement-Modul in der Version 3.0.0 oder höher verwenden, können Fehler auftreten. Um das Problem zu beheben, stellen Sie sicher, dass Sie auch die PowerShellGet- und PackageManagement-Module explizit hochladen.

• Wenn Sie das Modul Az.Accounts mit Version 2.12.3 oder höher importieren, stellen Sie sicher, dass Sie das Newtonsoft.Json v10-Modul explizit importieren, wenn PowerShell 5.1-Runbooks von dieser Version des Moduls abhängig sind. Die Problemumgehung für dieses Problem besteht darin, PowerShell 7.2-Runbooks zu verwenden.

• Wenn Sie das New-AzAutomationVariable-Cmdlet in Az.Automation-Modul verwenden, um eine Variable vom Typ Objekt hochzuladen, funktioniert der Vorgang nicht wie erwartet.

  Problemumgehung: Konvertieren Sie das Objekt mithilfe des Cmdlets ConvertTo-Json in eine JSON-Zeichenfolge, und laden Sie dann die Variable mit der JSON-Zeichenfolge als Wert hoch. Diese Problemumgehung stellt sicher, dass die Variable innerhalb der Azure Automation-Umgebung ordnungsgemäß als JSON-Zeichenfolge behandelt wird.

  Beispiel: Erstellen eines PowerShell-Objekts, auf dem Informationen zu Azure-VMs gespeichert sind

    # Retrieve Azure virtual machines with status information for the 'northeurope' region 
    $AzVM = Get-AzVM -Status | Where-Object {$_.Location -eq "northeurope"} 
  
    $VMstopatch = @($AzVM).Id 
    # Create an Azure Automation variable (This cmdlet will not fail, but the variable may not work as intended when used in the runbook.) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $VMstopatch 
  
    # Convert the object to a JSON string 
    $jsonString = $VMstopatch | ConvertTo-Json 
  
    # Create an Azure Automation variable with a JSON string value (works effectively within the automation runbook) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $jsonString 
  

PowerShell 7.1

Einschränkungen

• PowerShell 7.1 wird von PowerShell im übergeordneten Produkt nicht mehr unterstützt. Es wird empfohlen, neue Runbooks für langfristigen Support in PowerShell 7.2 zu erstellen und die veralteten Runbooks zu aktualisieren.
• Die internen PowerShell-Cmdlets von Azure Automation werden auf einem Linux Hybrid Runbook Worker nicht unterstützt. Sie müssen das „automationassets“-Modul zu Beginn Ihres PowerShell-Runbooks importieren, um auf die Funktionen für freigegebene Ressourcen (Objekte) des Automation-Kontos zugreifen zu können.
• Für die PowerShell 7-Runtimeversion werden die Modulaktivitäten nicht für die importierten Module extrahiert.
• Der PSCredential-Runbookparametertyp wird in der PowerShell 7-Runtimeversion nicht unterstützt.
• PowerShell 7.x unterstützt keine Workflows. Weitere Informationen finden Sie unter PowerShell-Workflow für weitere Details.
• PowerShell 7.x unterstützt derzeit keine signierten Runbooks.
• Die Quellcodeverwaltungsintegration unterstützt PowerShell 7.1 (Vorschau) nicht. Außerdem werden PowerShell 7.1 (Vorschau)-Runbooks in der Quellcodeverwaltung im Automation-Konto als Runtime 5.1 erstellt.
• Die Verwaltung des PowerShell 7.1-Moduls über „Get-AzAutomationModule“-Cmdlets wird nicht unterstützt.
• Das Runbook schlägt ohne Protokollablaufverfolgung fehl, wenn der Eingabewert das Zeichen ‘ enthält.
• Das Azure-Runbook unterstützt Start-Job mit -credential nicht.
• Azure unterstützt nicht alle PowerShell-Eingabeparameter. Weitere Informationen

Bekannte Probleme

• Runbooks, die von internen Dateipfaden abhängig sind, z. B. C:\modules, können aufgrund von Änderungen in der Dienst-Back-End-Infrastruktur fehlschlagen. Ändern Sie den Runbook-Code, um sicherzustellen, dass keine Abhängigkeiten von internen Dateipfaden vorhanden sind, und verwenden Sie Get-ChildItem, um die erforderlichen Modulinformationen abzurufen.

  Beispielskript

  
  # Get information about module "Microsoft.Graph.Authentication"
  $ModuleName = "Microsoft.Graph.Authentication"
  
  $NewPath = "C:\usr\src\PSModules\$ModuleName"
  $OldPath = "C:\Modules\User\$ModuleName"
  
  if (Test-Path -Path $NewPath -PathType Container) {
      Get-ChildItem -Path $NewPath
  } elseif (Test-Path -Path $OldPath -PathType Container) {
      Get-ChildItem -Path $OldPath
  } else {
      Write-Output "Module $ModuleName not present."
  }
  # Getting the path to the Temp folder, if needed.
  $tmp = $env:TEMP
  
  

• Das Get-AzStorageAccount-Cmdlet kann aufgrund eines Fehlers fehlschlagen: Der Get-AzStorageAccount-Befehl wurde im Modul Az.Storage gefunden, aber das Modul konnte nicht geladen werden.

• Das Ausführen von untergeordneten Skripts mithilfe von .\child-runbook.ps1 wird in dieser Vorschauversion nicht unterstützt. Problemumgehung: Verwenden Sie Start-AutomationRunbook (internes Cmdlet) oder Start-AzAutomationRunbook (aus dem Az.Automation-Modul), um ein weiteres Runbook aus dem übergeordneten Runbook zu starten.

• Runbookeigenschaften, die die Protokollierungsvoreinstellung definieren, werden in der PowerShell 7-Runtime nicht unterstützt. Problemumgehung: Legen Sie die Einstellung explizit am Anfang des Runbook wie folgt fest:

      $VerbosePreference = "Continue"
  
      $ProgressPreference = "Continue"
  

• Vermeiden Sie den Import des Moduls Az.Accounts in Version 2.4.0 für die PowerShell 7-Runtime, da es zu unerwartetem Verhalten bei Verwendung dieser Version in Azure Automation führen kann.

• Möglicherweise treten Formatierungsprobleme mit Fehlerausgabestreams für den Auftrag auf, der in der PowerShell 7-Runtime ausgeführt wird.

• Wenn Sie ein PowerShell 7.1-Modul importieren, das von anderen Modulen abhängig ist, können Sie feststellen, dass die Importschaltfläche auch dann grau ist, wenn PowerShell 7.1 Version des abhängigen Moduls installiert ist. Beispielsweise weist das Modul „Az PowerShell-Modul.Compute“ in der Version 4.20.0 eine Abhängigkeit vom Modul „Az.Accounts“ auf, nämlich dass > = Version 2.6.0 ist. Dieses Problem tritt auf, wenn ein entsprechendes abhängiges Modul in PowerShell 5.1 die Versionsanforderungen nicht erfüllt. Die Version 5.1 des Moduls „Az.Accounts“ war beispielsweise < Version 2.6.0.

• Wenn Sie das PowerShell 7-Runbook mithilfe des Webhooks starten, wird der Webhookeingabeparameter automatisch in einen ungültigen JSON-Code konvertiert.

• Es wird empfohlen, die ExchangeOnlineManagement-Modulversion 3.0.0 oder niedriger zu verwenden, da Version 3.0.0 oder höher zu Auftragsfehlern führen kann.

• Wenn Sie das Modul Az.Accounts mit Version 2.12.3 oder höher importieren, stellen Sie sicher, dass Sie das Newtonsoft.Json v10-Modul explizit importieren, wenn PowerShell 7.1-Runbooks von dieser Version des Moduls abhängig sind. Die Problemumgehung für dieses Problem besteht darin, PowerShell 7.2-Runbooks zu verwenden.

• Wenn Sie das New-AzAutomationVariable-Cmdlet in Az.Automation-Modul verwenden, um eine Variable vom Typ Objekt hochzuladen, funktioniert der Vorgang nicht wie erwartet.

  Problemumgehung: Konvertieren Sie das Objekt mithilfe des Cmdlets ConvertTo-Json in eine JSON-Zeichenfolge, und laden Sie dann die Variable mit der JSON-Zeichenfolge als Wert hoch. Diese Problemumgehung stellt sicher, dass die Variable innerhalb der Azure Automation-Umgebung ordnungsgemäß als JSON-Zeichenfolge behandelt wird.

  Beispiel: Erstellen eines PowerShell-Objekts, auf dem Informationen zu Azure-VMs gespeichert sind

    # Retrieve Azure virtual machines with status information for the 'northeurope' region 
    $AzVM = Get-AzVM -Status | Where-Object {$_.Location -eq "northeurope"} 
  
    $VMstopatch = @($AzVM).Id 
    # Create an Azure Automation variable (This cmdlet will not fail, but the variable may not work as intended when used in the runbook.) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $VMstopatch 
  
    # Convert the object to a JSON string 
    $jsonString = $VMstopatch | ConvertTo-Json 
  
    # Create an Azure Automation variable with a JSON string value (works effectively within the automation runbook) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $jsonString 
  

PowerShell-Workflow-Runbooks

PowerShell-Workflow-Runbooks sind Textrunbooks, die auf einem Windows PowerShell-Workflowbasieren. Sie bearbeiten den Code des Runbooks direkt mit dem Text-Editor im Azure-Portal. Sie können auch einen beliebigen Offline-Texteditor verwenden und das Runbook in Azure Automation importieren .

Hinweis

PowerShell 7.1 (Vorschau) und PowerShell 7.2 unterstützen keine Workflow-Runbooks.

Vorteile

• Implementierung der gesamten komplexen Logik mit PowerShell-Workflowcode.
• Verwendung von Prüfpunkten zum Fortsetzen des Vorgangs bei einem Fehler
• Verwendung der Parallelverarbeitung, um mehrere Aktionen gleichzeitig auszuführen
• Können andere grafische und PowerShell-Workflow-Runbooks als untergeordnete Runbooks enthalten, um übergeordnete Workflows zu erstellen

Begrenzungen

• PowerShell-Workflow wird in PowerShell 7 und höheren Versionen nicht unterstützt. Daher können die veralteten Runbooks nicht upgegradet werden.
• Ineffiziente Behandlung der parallelen Ausführung im Vergleich zu neueren Versionen von PowerShell 7 und höher
• PowerShell-Workflow funktioniert intern mit mehreren Prozessen. Daher sind Module, die in einem Prozess verfügbar sind, möglicherweise nicht in einem anderen verfügbar und verursachen Ausnahmen wie Befehl nicht gefunden.
• Müssen die zusätzliche Komplexität des PowerShell-Workflows (z. B. deserialisierte Objekte) verarbeiten
• Benötigen beim Starten länger als PowerShell-Runbooks, da sie vor der Ausführung kompiliert werden müssen
• Ausschließlich PowerShell-Runbooks können mit dem Cmdlet Start-AzAutomationRunbook als untergeordnete Runbooks eingeschlossen werden.
• Keine Möglichkeit zum Ausführen von Runbooks auf einem Hybrid Runbook Worker und Linux

Python-Runbooks

Python-Runbooks lassen sich unter Python 2.7 (GA), Python 3.8 (GA) und Python 3.10 (Vorschau) kompilieren. Sie können den Code des Runbooks direkt mit dem Text-Editor im Azure-Portal bearbeiten. Sie können auch einen beliebigen Offline-Text-Editor verwenden und das Runbook in Azure Automation importieren.

Derzeit wird die Laufzeitversion von Python 3.10 (Vorschau) sowohl für Cloud- als auch für Hybridaufträge in allen öffentlichen Regionen mit Ausnahme von Australien Zentral2, Südkorea Süd, Schweden Süd, Jio Indien Zentral, Brasilien Südost, Indien Zentral, Indien West, VAE Zentral und Government-Clouds unterstützt.

Vorteile

Hinweis

Das Importieren eines Python-Pakets kann einige Minuten dauern.

• Verwendet die stabilen Python-Bibliotheken.
• Können in Azure oder auf Hybrid Runbook Workern ausgeführt werden.
• Bei Python 2.7 werden Windows Hybrid Runbook Workers unterstützt, wenn Python 2.7 installiert ist.
• Für Python 3.8-Cloudaufträge wird die Python-Version 3.8 unterstützt. Skripts und Pakete aus einer beliebigen 3.x-Version funktionieren möglicherweise, wenn der Code mit mehreren Versionen kompatibel ist.
• Für Python 3.8-Hybridaufträge auf Windows-Computern können Sie jede beliebige 3.x-Version installieren, die Sie eventuell verwenden möchten.
• Für Python 3.8-Hybridaufträge auf Linux-Computern ist die auf dem Computer installierte Version von Python 3 zum Ausführen von DSC OMSConfig und dem Linux Hybrid Worker erforderlich. Andere Versionen sollten funktionieren, wenn zwischen den Versionen von Python 3 keine Breaking Changes bei Methodensignaturen oder Verträgen erfolgt sind.

Begrenzungen

Im Folgenden finden Sie die Einschränkungen von Python-Runbooks

Python 3.10 (Vorschau)

• Für Python 3.10 (Vorschau)-Module werden derzeit nur die Wheel-Dateien für das cp310 Linux-Betriebssystem unterstützt. Weitere Informationen
• Die Integration der Quellcodeverwaltung wird nicht unterstützt.
• Benutzerdefinierte Pakete für Python 3.10 (Vorschau) werden nur während der Auftragsruntime überprüft. Es wird erwartet, dass der Auftrag fehlschlägt, wenn das Paket in der Runtime nicht kompatibel ist oder wenn erforderliche Abhängigkeiten von Paketen nicht in das Automation-Konto importiert wurden.
• Derzeit werden Python 3.10 (Vorschau)-Runbooks nur im Azure-Portal unterstützt. REST-API und PowerShell werden nicht unterstützt.

Python 3.8 (GA)

• Erfordern Kenntnisse mit Python-Skripts
• Die Integration der Quellcodeverwaltung wird nicht unterstützt.
• Verwenden Sie für Python 3.8-Module Wheel-Dateien für cp38-amd64.
• Erfordern für die Verwendung von Bibliotheken von Drittanbietern das Importieren der Pakete in das Automation-Konto
• Das Verwenden des Cmdlets Start-AutomationRunbook in PowerShell oder einem PowerShell-Workflow zum Starten eines Python 3.8-Runbooks funktioniert nicht. Sie können das Cmdlet Start-AzAutomationRunbook aus dem Modul Az.Automation oder das Cmdlet Start-AzureRmAutomationRunbook aus dem Modul AzureRm.Automation verwenden, um diese Einschränkung zu umgehen. 
• Azure Automation unterstützt sys.stderr nicht.
• Da das Python-Paket automationassets auf pypi.org nicht verfügbar ist, kann es nicht auf einen Windows-Computer importiert werden.

Python 2.7

• Python 2.7 wird von Python im übergeordneten Produkt nicht mehr unterstützt. Es wird empfohlen, neue Runbooks in den unterstützten Versionen zu erstellen und die veralteten Runbooks zu aktualisieren.
• Erfordern Kenntnisse mit Python-Skripts
• Verwenden Sie für Python 2.7.12-Module Wheel-Dateien für cp27-amd6.
• Erfordern für die Verwendung von Bibliotheken von Drittanbietern das Importieren der Pakete in das Automation-Konto
• Azure Automation unterstützt sys.stderr nicht.
• Da das Python-Paket automationassets auf pypi.org nicht verfügbar ist, kann es nicht auf einen Windows-Computer importiert werden.

Mehrere Python-Versionen

Dies gilt für Windows Hybrid Worker. Ein Windows Runbook Worker sucht beim Ausführen eines Python 2-Runbooks zuerst nach der Umgebungsvariable PYTHON_2_PATH und überprüft, ob sie auf eine gültige ausführbare Datei verweist. Wenn der Installationsordner beispielsweise C:\Python2 lautet, wird überprüft, ob C:\Python2\python.exe ein gültiger Pfad ist. Wenn er nicht gefunden wird, sucht der Worker nach der Umgebungsvariable PATH, um eine ähnliche Überprüfung durchzuführen.

Für Python 3 sucht er zuerst nach der Umgebungsvariable PYTHON_3_PATH und greift dann auf die Umgebungsvariable PATH zurück.

Wenn Sie nur eine Version von Python verwenden, können Sie der Variable den Installationspfad PATH hinzufügen. Wenn Sie beide Versionen auf dem Runbook Worker verwenden möchten, legen Sie für PYTHON_2_PATH und PYTHON_3_PATH den Speicherort des Moduls für diese Versionen fest.

Bekannte Probleme

Bei Cloudaufträgen schlagen Python 3.8-Aufträge manchmal mit der Ausnahmemeldung invalid interpreter executable path fehl. Diese Ausnahme wird möglicherweise angezeigt, wenn der Auftrag verzögert ist, wenn der Start länger als 10 Minuten dauert oder wenn Start-AutomationRunbook verwendet wird, um Python 3.8-Runbooks zu starten. Wenn der Auftrag verzögert wurde, sollte ein Neustart des Runbooks ausreichen.

Grafische Runbooks

Sie können grafische Runbooks und grafische PowerShell-Workflow-Runbooks im grafischen Editor im Azure-Portal erstellen und bearbeiten. Es ist jedoch nicht möglich, diesen Runbooktyp mit einem anderen Tool zu erstellen oder zu bearbeiten. Hauptfunktionen von grafischen Runbooks:

• Werden in Dateien in Ihrem Automation-Konto exportiert und dann in ein anderes Automation-Konto importiert
• Generieren PowerShell-Code
• Werden während des Imports in grafische PowerShell-Workflow-Runbooks konvertiert und umgekehrt

Vorteile

• Verwenden ein visuelles Erstellungsmodell zum Einfügen/Verknüpfen/Konfigurieren
• Schwerpunkt auf Datenfluss im Prozess
• Visuelle Darstellung von Verwaltungsprozessen.
• Schließen weitere Runbooks als untergeordnete Runbooks ein, um übergeordnete Workflows zu erstellen
• Fördern modulare Programmierung

Begrenzungen

• Können nicht außerhalb des Azure-Portals erstellt oder bearbeitet werden
• Erfordern möglicherweise Aktivität mit PowerShell-Code, um komplexe Logik auszuführen
• Können nicht in eines der Textformate konvertiert werden (Textrunbooks können darüber hinaus nicht in das grafische Format überführt werden)
• Bieten keine Möglichkeit zum Anzeigen oder direkten Bearbeiten des vom grafischen Workflow erstellten PowerShell-Codes. Sie können den erstellten Code in allen Codeaktivitäten anzeigen.
• Keine Möglichkeit zum Ausführen von Runbooks auf einem Hybrid Runbook Worker unter Linux. Weitere Informationen finden Sie unter Automatisieren von Ressourcen im Rechenzentrum oder in der Cloud mit Hybrid Runbook Worker.
• Grafische Runbooks können nicht digital signiert werden.

Nächste Schritte

• Informationen zu PowerShell-Runbooks finden Sie unter Tutorial: Erstellen eines PowerShell-Runbooks.
• Weitere Informationen zu PowerShell-Workflow-Runbooks finden Sie unter Tutorial: Erstellen eines PowerShell-Workflow-Runbook.
• Informationen zu den grafischen Runbooks finden Sie unter Tutorial: Erstellen eines grafischen Runbooks.
• Weitere Informationen zu Python-Runbooks finden Sie im Tutorial: Erstellen eines Python-Runbook.