Types de runbooks Azure Automation

La fonctionnalité d’automatisation des processus Azure Automation prend en charge plusieurs types de runbooks, conformément à la définition du tableau suivant. Pour en savoir plus sur l’environnement d’automatisation des processus, consultez Exécution d’un runbook dans Azure Automation.

Type	Description
PowerShell	Runbook textuel basé sur les scripts Windows PowerShell. Les versions actuellement prises en charge sont : PowerShell 7.2 (GA) et PowerShell 5.1 (GA). Étant donné que PowerShell 7.1 n’est plus pris en charge par le produit parent PowerShell, nous vous recommandons de créer des runbooks dans la version prise en charge à long terme de PowerShell 7.2.
Workflow PowerShell	Runbook textuel basé sur les scripts Windows PowerShell Workflow.
Python	Runbook textuel basé sur les scripts Python. Les versions actuellement prises en charge sont : Python 3.8 (GA) et Python 3.10 (préversion). Étant donné que Python 2.7 n’est plus pris en charge par le produit parent Python, nous vous recommandons de créer des runbooks dans les versions prises en charge à long terme.
Graphique	Runbook graphique basé sur Windows PowerShell et créé et modifié entièrement dans l'éditeur graphique du portail Azure.
Graphique workflow PowerShell	Runbook graphique basé sur le workflow Windows PowerShell et créé et modifié entièrement dans l'éditeur graphique du portail Azure.

Remarque

Azure Automation suivra le cycle de vie de la prise en charge des versions de langage PowerShell et Python conformément aux chronologies publiées par les produits parents PowerShell et Python respectivement. Nous vous recommandons d’utiliser des runbooks avec des versions de langage prises en charge.

Prenez en compte les considérations suivantes pour déterminer le type à utiliser pour un runbook donné.

• Vous ne pouvez pas convertir de runbooks du type graphique au type texte ou vice versa.
• Il existe des limitations lorsque des runbooks de différents types sont utilisés comme runbooks enfants. Pour plus d’informations, consultez la page Runbooks enfants dans Azure Automation.

Runbooks PowerShell

Les Runbooks PowerShell sont basés sur Windows PowerShell. Vous modifiez directement le code du Runbook à l'aide de l'éditeur de texte du portail Azure. Vous pouvez également utiliser n'importe quel éditeur de texte hors ligne et importer le Runbook dans Azure Automation.

La version de PowerShell est déterminée par la Version du runtime spécifiée (c’est-à-dire la version 7.2, 7.1 (préversion) ou 5.1).

Les mêmes bacs à sable Azure et Runbooks Workers hybrides peuvent exécuter côte à côte plusieurs runbooks PowerShell ciblant différentes versions du runtime.

Remarque

• Actuellement, la version du runtime PowerShell 7.2 est prise en charge pour les travaux cloud et hybrides dans toutes les régions publiques, à l’exception d’Inde Centre, Émirats arabes unis Centre, Israël Central, Italie Nord, Allemagne Nord et des clouds gouvernementaux.
• Au moment de l’exécution du runbook, si vous sélectionnez 7.2 comme Version du runtime, les modules PowerShell ciblant la version de runtime 7.2 sont utilisés, et si vous sélectionnez 5.1 comme Version du runtime, les modules PowerShell ciblant la version de runtime 5.1 sont utilisés. Cela s’applique aux modules et runbooks PowerShell 7.1 (préversion).

Veillez à sélectionner la bonne version de runtime pour les modules.

Par exemple : si vous exécutez un runbook pour un scénario d’automatisation SharePoint dans la version de runtime 7.1 (préversion), importez le module dans la version de runtime 7.1 (préversion) ; si vous exécutez un runbook pour un scénario d’automatisation SharePoint dans la version de runtime 5.1, importez le module dans la version de runtime 5.1. Dans ce cas, vous voyez deux entrées pour le module, une pour la version de runtime 7.1 (préversion) et l’autre pour 5.1.

Remarque

Actuellement, PowerShell 5.1, PowerShell 7.1 (préversion) et PowerShell 7.2 sont pris en charge.

Avantages

• Implémentez toute la logique complexe avec le code PowerShell sans la complexité supplémentaire de PowerShell Workflow.
• Démarrez plus rapidement que les runbooks de workflow PowerShell dans la mesure où ils n’ont pas besoin d'être compilés avant l'exécution.
• Exécutez dans Azure et sur des Runbook Workers hybrides pour Windows et Linux.

Limitations et problèmes connus

Voici les limitations et problèmes connus actuels rencontrés avec les runbooks PowerShell :

PowerShell 7.2

Limitations

Remarque

Actuellement, la version du runtime PowerShell 7.2 est prise en charge pour les travaux cloud et hybrides dans toutes les régions publiques, à l’exception d’Inde Centre, Émirats arabes unis Centre, Israël Central, Italie Nord, Allemagne Nord et des clouds gouvernementaux.

• Dans la version de runtime PowerShell 7.2, les activités du module ne sont pas extraites pour les modules importés. Utilisez l’extension Azure Automation pour VS Code pour simplifier l’expérience de création de runbooks.
• PowerShell 7.x ne prend pas en charge les workflows. Pour plus d’informations et de détails, consultez PowerShell Workflow.
• PowerShell 7.x ne prend pas en charge les runbooks signés pour le moment.
• L’intégration du contrôle de code source ne prend pas en charge PowerShell 7.2. En outre, les runbooks PowerShell 7.2 dans le contrôle de code source sont créés dans le compte Automation en tant que runtime 5.1.
• Le module Az 8.3.0 est installé par défaut. La liste complète des modules de composant de la version sélectionnée du module Az s’affiche une fois que la version Az est configurée à nouveau à l’aide du portail Azure ou de l’API.
• Le module PowerShell 7.2 importé est validé pendant l’exécution du travail. Vérifiez que toutes les dépendances du module sélectionné sont également importées pour une exécution réussie du travail.
• Le runbook Azure ne prend pas en charge Start-Job avec -credential.
• Azure ne prend pas en charge tous les paramètres d’entrée PowerShell. Plus d’informations

Problèmes connus

• Les Runbooks qui dépendent des chemins d’accès de fichiers internes, tels que C:\modules, peuvent échouer en raison de modifications apportées à l’infrastructure back-end du service. Modifiez le code du runbook pour vous assurer qu’il n’existe aucune dépendance sur les chemins de fichiers internes et utilisez Get-ChildItem pour obtenir les informations de module requises.

• La cmdlet Get-AzStorageAccount peut échouer avec une erreur : La commande Get-AzStorageAccount a été trouvée dans le module Az.Storage, mais le module n’a pas pu être chargé.

• L’exécution de scripts enfants à l’aide de .\child-runbook.ps1 n’est pas prise en charge.
  Solution de contournement : utiliser Start-AutomationRunbook (cmdlet interne) ou Start-AzAutomationRunbook (à partir du module Az.Automation) pour démarrer un autre runbook à partir du runbook parent.

• Lorsque vous utilisez le module ExchangeOnlineManagement version 3.0.0 ou ultérieure, vous pouvez rencontrer des erreurs. Pour résoudre le problème, veillez à charger explicitement des modules PowerShellGet et PackageManagement.

• Lorsque vous utilisez la cmdlet New-AzAutomationVariable dans le module Az.Automation pour charger une variable de type objet, l’opération ne fonctionne pas comme prévu.

  Solution de contournement : convertissez l’objet en chaîne JSON à l’aide de la cmdlet ConvertTo-Json, puis chargez la variable avec la chaîne JSON comme valeur. Cette solution de contournement garantit une gestion appropriée de la variable dans l’environnement Azure Automation en tant que chaîne JSON.

  Exemple : créer un objet PowerShell qui a stocké des informations relatives à des machines virtuelles Azure

    # 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

Limitations

• Les runbooks ne peuvent pas utiliser un traitement en parallèle pour effectuer plusieurs actions en parallèle.
• Les runbooks ne peuvent pas utiliser de points de contrôle pour reprendre le runbook en cas d'erreur.
• Vous pouvez uniquement inclure PowerShell, les runbooks de flux de travail PowerShell et les runbooks graphiques comme runbooks enfants à l’aide de la cmdlet Start-AzAutomationRunbook, ce qui crée un travail.
• Les runbooks ne peuvent pas utiliser l’instruction PowerShell #Requires, car elle n’est pas prise en charge dans le bac à sable Azure ni sur les Runbooks Workers hybrides et peut entraîner l’échec de la tâche.
• Le runbook Azure ne prend pas en charge Start-Job avec -credential.
• Azure ne prend pas en charge tous les paramètres d’entrée PowerShell. Plus d’informations

Problèmes connus

• Les Runbooks qui dépendent des chemins d’accès de fichiers internes, tels que C:\modules, peuvent échouer en raison de modifications apportées à l’infrastructure back-end du service. Modifiez le code du runbook pour vous assurer qu’il n’existe aucune dépendance sur les chemins de fichiers internes et utilisez Get-ChildItem pour obtenir les informations de module requises.

  Exemple de script

  
  # 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
  
  

• La cmdlet Get-AzStorageAccount peut échouer avec une erreur : La commande Get-AzStorageAccount a été trouvée dans le module Az.Storage, mais le module n’a pas pu être chargé.

• Les runbooks PowerShell ne peuvent pas récupérer une ressource variable non chiffrée avec une valeur null.

• Les runbooks PowerShell ne peuvent pas récupérer une ressource variable dont le nom contient le symbole *~*.

• Une opération Get-Process dans une boucle d’un runbook PowerShell peut se bloquer après environ 80 itérations.

• Un runbook PowerShell peut échouer s’il essaie d'écrire une grande quantité de données à la fois dans le flux de sortie. Vous pouvez généralement contourner ce problème. Pour ce faire, le runbook doit sortir uniquement les informations nécessaires pour travailler avec des objets volumineux. Par exemple, au lieu d’utiliser Get-Process sans aucune limitation, vous pouvez faire en sorte que l’applet de commande génère uniquement les paramètres requis, comme dans Get-Process | Select ProcessName, CPU.

• Lorsque vous utilisez le module ExchangeOnlineManagement : version 3.0.0 ou ultérieure, vous pouvez rencontrer des erreurs. Pour résoudre le problème, veillez également à charger explicitement les modules PowerShellGet et PackageManagement.

• Si vous importez le module Az.Accounts avec la version 2.12.3 ou ultérieure, assurez-vous d’importer explicitement le module Newtonsoft.Json v10 si les runbooks PowerShell 5.1 ont une dépendance sur cette version du module. La solution de contournement pour ce problème consiste à utiliser des runbooks PowerShell 7.2.

• Lorsque vous utilisez la cmdlet New-AzAutomationVariable dans le module Az.Automation pour charger une variable de type objet, l’opération ne fonctionne pas comme prévu.

  Solution de contournement : convertissez l’objet en chaîne JSON à l’aide de la cmdlet ConvertTo-Json, puis chargez la variable avec la chaîne JSON comme valeur. Cette solution de contournement garantit une gestion appropriée de la variable dans l’environnement Azure Automation en tant que chaîne JSON.

  Exemple : créer un objet PowerShell qui a stocké des informations relatives à des machines virtuelles Azure

    # 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

Limitations

• PowerShell 7.1 n’est plus pris en charge par le produit parent PowerShell. Nous vous recommandons de créer de nouveaux runbooks dans PowerShell 7.2 pour une prise en charge à long terme et de mettre à jour les runbooks obsolètes.
• Les applets de commande PowerShell internes d’Azure Automation ne sont pas prises en charge sur un Runbook Worker hybride Linux. Vous devez importer le module automationassets au début de votre runbook PowerShell pour accéder aux fonctions de ressources partagées du compte Automation.
• Dans la version de runtime PowerShell 7, les activités du module ne sont pas extraites pour les modules importés.
• Le type de paramètre de runbook PSCredential n’est pas pris en charge dans la version de runtime PowerShell 7.
• PowerShell 7.x ne prend pas en charge les workflows. Pour plus d’informations et de détails, consultez PowerShell Workflow.
• PowerShell 7.x ne prend pas en charge les runbooks signés pour le moment.
• L’intégration du contrôle de code source ne prend pas en charge PowerShell 7.1 (préversion). En outre, les runbooks PowerShell 7.1 (préversion) dans le contrôle de code source sont créés dans le compte Automation en tant que runtime 5.1.
• La gestion des modules PowerShell 7.1 n’est pas prise en charge via les applets de commande Get-AzAutomationModule.
• Le runbook échoue sans trace de journal si la valeur d’entrée contient le caractère « ’ ».
• Le runbook Azure ne prend pas en charge Start-Job avec -credential.
• Azure ne prend pas en charge tous les paramètres d’entrée PowerShell. Plus d’informations

Problèmes connus

• Les Runbooks qui dépendent des chemins d’accès de fichiers internes, tels que C:\modules, peuvent échouer en raison de modifications apportées à l’infrastructure back-end du service. Modifiez le code du runbook pour vous assurer qu’il n’existe aucune dépendance sur les chemins de fichiers internes et utilisez Get-ChildItem pour obtenir les informations de module requises.

  Exemple de script

  
  # 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
  
  

• La cmdlet Get-AzStorageAccount peut échouer avec une erreur : La commande Get-AzStorageAccount a été trouvée dans le module Az.Storage, mais le module n’a pas pu être chargé.

• L’exécution de scripts enfants à l’aide de .\child-runbook.ps1 n’est pas prise en charge dans cette préversion. Solution de contournement : utilisez Start-AutomationRunbook (cmdlet interne) ou Start-AzAutomationRunbook (à partir du module Az.Automation) pour démarrer un autre runbook à partir du runbook parent.

• Les propriétés de runbook définissant la préférence de journalisation ne sont pas prises en charge dans le runtime PowerShell 7. Solution de contournement : définissez explicitement la préférence au début du runbook, comme suit :

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

• Évitez d’importer le module Az.Accounts dans la version 2.4.0 du runtime PowerShell 7, car il peut avoir un comportement inattendu avec cette version dans Azure Automation.

• Vous pouvez rencontrer des problèmes de mise en forme avec des flux de sortie d’erreur pour les travaux qui s’exécutent dans le runtime PowerShell 7.

• Lorsque vous importez un module PowerShell 7.1 qui dépend d’autres modules, il se peut que le bouton d’importation soit grisé même si la version PowerShell 7.1 du module dépendant est installée. Par exemple, le module.Compute Az PowerShell 4.20.0 a une dépendance sur Az.Accounts >= 2.6.0. Ce problème se produit lorsqu’un module dépendant équivalent dans PowerShell 5.1 ne répond pas aux exigences de version. Par exemple, la version 5.1 de Az.Accounts était < 2.6.0.

• Lorsque vous démarrez un runbook PowerShell 7 à l’aide du webhook, il convertit automatiquement le paramètre d’entrée du webhook en JSON non valide.

• Nous vous recommandons d’utiliser la version 3.0.0 ou inférieure du module ExchangeOnlineManagement, car la version 3.0.0 ou ultérieure peut entraîner des échecs de travaux.

• Si vous importez le module Az.Accounts avec la version 2.12.3 ou ultérieure, veillez à importer explicitement le module Newtonsoft.Json v10 si les runbooks PowerShell 7.1 ont une dépendance sur cette version du module. La solution de contournement pour ce problème consiste à utiliser des runbooks PowerShell 7.2.

• Lorsque vous utilisez la cmdlet New-AzAutomationVariable dans le module Az.Automation pour charger une variable de type objet, l’opération ne fonctionne pas comme prévu.

  Solution de contournement : convertissez l’objet en chaîne JSON à l’aide de la cmdlet ConvertTo-Json, puis chargez la variable avec la chaîne JSON comme valeur. Cette solution de contournement garantit une gestion appropriée de la variable dans l’environnement Azure Automation en tant que chaîne JSON.

  Exemple : créer un objet PowerShell qui a stocké des informations relatives à des machines virtuelles Azure

    # 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 
  

Runbooks de workflow PowerShell

Les Runbooks de workflow PowerShell sont des Runbooks texte basés sur un workflow Windows PowerShell. Vous modifiez directement le code du Runbook à l'aide de l'éditeur de texte du portail Azure. Vous pouvez également utiliser n'importe quel éditeur de texte hors ligne et importer le Runbook dans Azure Automation.

Remarque

PowerShell 7.1 (préversion) et PowerShell 7.2 ne prennent pas en charge les runbooks de workflow.

Avantages

• Implémentez tout type de logique complexe avec le code de workflow PowerShell.
• Utilisez des points de contrôle pour reprendre l’opération en cas d'erreur.
• Utilisez un traitement en parallèle pour mener plusieurs actions en parallèle.
• Peut inclure d'autres runbooks graphiques et des runbooks de workflow PowerShell en tant que runbooks enfants afin de créer des workflows de haut niveau.

Limites

• Le workflow PowerShell n’est pas pris en charge dans les versions de PowerShell ultérieures à la version 7. Par conséquent, les runbooks obsolètes ne peuvent pas être mis à niveau.
• Gestion inefficace de l’exécution parallèle par rapport aux versions plus récentes de PowerShell ultérieures à la version 7.
• Le workflow PowerShell fonctionne en interne à l’aide de plusieurs processus. Par conséquent, les modules disponibles dans un processus peuvent ne pas être disponibles dans un autre, et provoquer des exceptions telles que Commande introuvable.
• Les runbooks doivent pouvoir gérer la complexité supplémentaire liée au workflow PowerShell, notamment les objets désérialisés.
• Les runbooks prennent plus de temps à démarrer que les runbooks PowerShell, car il doivent être compilés avant l'exécution.
• Vous pouvez inclure uniquement des runbooks PowerShell en tant que runbooks enfants à l’aide de l’applet de commande Start-AzAutomationRunbook.
• Les runbooks ne peuvent pas être exécutés sur un Runbook Worker hybride.

Runbooks Python

Les runbooks Python sont compilés sous Python 2.7 (GA), Python 3.8 (GA) et Python 3.10 (préversion). Vous pouvez modifierz directement le code du runbook à l'aide de l'éditeur de texte du portail Azure. Vous pouvez également utiliser un éditeur de texte hors ligne et importer le runbook dans Azure Automation.

Actuellement, la version du runtime Python 3.10 (préversion) est prise en charge pour les travaux cloud et hybrides dans toutes les régions publiques, à l’exception de l’Australie Centre 2, de la Corée Sud, de la Suède Sud, de Jio Inde Centre, du Brésil Sud-Est, de l’Inde Centre, de l’Inde Ouest, des Émirats arabes unis Centre et des clouds Gov.

Avantages

Remarque

L’importation d’un package Python peut prendre plusieurs minutes.

• Utilise les bibliothèques Python robustes.
• Ils peuvent s’exécuter dans Azure ou sur des runbooks Worker hybrides.
• Pour Python 2.7, les runbooks Workers hybrides Windows sont pris en charge si Python 2.7 est installé.
• Pour les tâches cloud Python 3.8, la version Python 3.8 est prise en charge. Les scripts et les packages de toute version 3.x peuvent fonctionner si le code est compatible entre les différentes versions.
• Pour les tâches hybrides Python 3.8 sur des ordinateurs Windows, vous pouvez choisir d’installer une version 3.x quelconque que vous souhaitez utiliser.
• Pour les travaux hybrides Python 3.8 sur des machines Linux, nous dépendons de la version Python 3 installée sur la machine pour exécuter DSC OMSConfig et le worker hybride Linux. D’autres versions devraient fonctionner si aucun changement cassant n’est introduit dans les signatures de méthode ou les contrats entre les versions de Python 3.

Limites

Voici les limitations des runbooks Python

Python 3.10 (préversion)

• Pour les modules Python 3.10 (préversion), actuellement, seuls les fichiers wheel ciblant le système d’exploitation Linux cp310 sont pris en charge. En savoir plus
• L’intégration du contrôle de code source n’est pas prise en charge.
• Les packages personnalisés pour Python 3.10 (préversion) sont validés uniquement pendant l’exécution du travail. Le travail devrait échouer si le package n’est pas compatible dans le runtime ou si les dépendances requises des packages ne sont pas importées dans le compte Automation.
• Actuellement, les runbooks Python 3.10 (préversion) ne sont pris en charge qu’à partir du Portail Azure. L’API REST et PowerShell ne sont pas pris en charge.

Python 3.8 (GA)

• Vous devez être familiarisé avec les scripts Python.
• L’intégration du contrôle de code source n’est pas prise en charge.
• Pour les modules Python 3.8, utilisez des fichiers wheel ciblant cp38-amd64.
• Pour utiliser des bibliothèques tierces, vous devez importer les packages dans le compte Automation.
• L’utilisation de la cmdlet Start-AutomationRunbook dans PowerShell/PowerShell Workflow pour démarrer un runbook Python 3.8 ne fonctionne pas. Vous pouvez utiliser la cmdlet Start-AzAutomationRunbook issue du module Az.Automation ou la cmdlet Start-AzureRmAutomationRunbook issue du module AzureRm.Automation pour contourner cette limitation. 
• Azure Automation ne prend pas en charge sys.stderr.
• Le package automationassets Python n’étant pas disponible sur pypi.org, il n’est pas disponible pour importation sur une machine Windows.

Python 2.7

• Python 2.7 n’est plus pris en charge par le produit parent Python. Nous vous recommandons de créer de nouveaux runbooks dans les versions prises en charge et de mettre à jour les runbooks obsolètes.
• Vous devez être familiarisé avec les scripts Python.
• Pour les modules Python 2.7.12, utilisez les fichiers wheel cp27-amd6.
• Pour utiliser des bibliothèques tierces, vous devez importer les packages dans le compte Automation.
• Azure Automation ne prend pas en charge sys.stderr.
• Le package automationassets Python n’étant pas disponible sur pypi.org, il n’est pas disponible pour importation sur une machine Windows.

Plusieurs versions de Python

Cela s’applique aux Workers hybrides Windows. Pour un Runbook Worker Windows, lors de l’exécution d’un Runbook Python 2, il recherche d’abord la variable d’environnement PYTHON_2_PATH et vérifie si elle pointe vers un fichier exécutable valide. Par exemple, si le dossier d’installation est C:\Python2, il vérifie si C:\Python2\python.exe correspond à un chemin d’accès valide. Si ce n’est pas le cas, il recherche la variable d’environnement PATH pour effectuer une vérification similaire.

Pour Python 3, il recherche d'abord la variable d’environnement PYTHON_3_PATH, puis revient à la variable d’environnement PATH.

Lorsque vous utilisez une seule version de Python, vous pouvez ajouter le chemin d’installation à la variable PATH. Si vous souhaitez utiliser les deux versions sur le Runbook Worker, définissez PYTHON_2_PATH et PYTHON_3_PATH sur l’emplacement du module correspondant à ces versions.

Problèmes connus

Pour les tâches cloud, les travaux Python 3.8 échouent parfois avec un message d’exception invalid interpreter executable path. Vous pouvez voir cette exception si le travail est retardé, démarre en plus de 10 minutes ou utilise Start-AutomationRunbook pour démarrer les runbooks Python 3.8. Si le travail est retardé, le redémarrage du runbook doit être suffisant.

Runbooks graphiques

Vous pouvez créer et modifier des runbooks graphiques de workflow PowerShell avec l’éditeur graphique du portail Azure. Vous ne pouvez cependant ni créer ni modifier ce type de runbook avec un autre outil. Principales fonctionnalités des runbooks graphiques :

• Ils sont exportés vers des fichiers de votre compte Automation, puis importés dans un autre compte Automation.
• Générer du code PowerShell.
• Ils sont convertis vers ou depuis les runbooks PowerShell Workflow graphiques pendant l’importation.

Avantages

• Utilisation d’un modèle de création visuel insert-link-configure.
• Concentration sur la circulation des flux de données dans tout le processus.
• Représentez visuellement les processus de gestion.
• Inclusion d’autres runbooks en tant que runbooks enfants pour créer des workflows de niveau élevé.
• Programmation modulaire favorisée.

Limites

• Impossible de créer ou de modifier en dehors du portail Azure.
• Peut nécessiter une activité de code contenant du code PowerShell pour exécuter une logique complexe.
• Impossible d’effectuer une conversion vers l’un des formats de texte ou de convertir un runbook de texte au format graphique.
• Impossible d'afficher ou de modifier directement du code PowerShell créé par le workflow graphique. Vous pouvez afficher le code créé dans toute activité de code.
• Impossible d’exécuter des runbooks sur un Runbook Worker hybride. Consultez Automatiser les ressources de votre centre de données ou de votre cloud à l’aide d’un Runbook Worker hybride.
• Les runbooks graphiques ne peuvent pas être signés numériquement.

Étapes suivantes

• Pour en savoir plus sur les runbooks PowerShell, consultez Tutoriel : créer un runbook PowerShell.
• Pour en savoir plus sur les runbooks PowerShell Workflow, consultez Tutoriel : créer un runbook PowerShell Workflow.
• Pour en savoir plus sur les runbooks graphiques, consultez Tutoriel : créer un runbook graphique.
• Pour en savoir plus sur les runbooks Python, consultez Tutoriel : créer un runbook Python.