La fonctionnalité d’automatisation des processus Azure Automation prend en charge plusieurs types de runbooks, conformément à la définition du tableau suivant.
| Type |
Descriptif |
PowerShell
(recommandé) |
Runbook textuel basé sur les scripts Windows PowerShell. Les versions actuellement prises en charge sont PowerShell 7.6, PowerShell 7.4 et PowerShell 5.1. Puisque PowerShell 7.1 et PowerShell 7.2 ne sont plus pris en charge par le produit parent PowerShell, créez des livres d’exécution à partir de versions supportées à long terme telles que PowerShell 7.6 ou PowerShell 7.4. |
|
Flux de travail PowerShell |
Runbook textuel basé sur les scripts Windows PowerShell Workflow. |
Python
(recommandé) |
Runbook textuel basé sur les scripts Python. La version actuellement prise en charge est Python 3.10. Étant donné que Python 2.7 et Python 3.8 ne sont plus pris en charge par python produit parent, nous vous recommandons de créer des runbooks dans Python 3.10. |
|
Graphique |
Runbook graphique basé sur Windows PowerShell et créé et modifié entièrement dans l'éditeur graphique du portail Azure. |
|
Flux de travail graphique PowerShell |
Runbook graphique basé sur le workflow Windows PowerShell et créé et modifié entièrement directement dans l'éditeur graphique du portail Azure. |
Pour en savoir plus sur l’environnement d’automatisation des processus, consultez Exécution d’un runbook dans Azure Automation.
Remarque
Azure Automation suivra le cycle de vie de support 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 linguistiques prises en charge.
Prenez en compte les considérations suivantes lors de la détermination du type à utiliser pour un runbook particulier :
- Vous ne pouvez pas convertir des runbooks d'un type graphique à un type texte ou inversement.
- 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.
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. Les versions d’exécution de PowerShell 7.6 et PowerShell 7.4 sont prises en charge aussi bien pour les emplois cloud que hybrides dans toutes les régions.
Remarque
- Au moment de l’exécution du runbook, si vous sélectionnez Runtime Version7.4, les modules PowerShell ciblant la version du runtime 7.4 sont utilisés et si vous sélectionnez La version du runtime en tant que version 5.1, les modules PowerShell ciblant la version du runtime 5.1 sont utilisés.
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 runtime version7.4, importez le module dans runtime version7.4 ; si vous exécutez un runbook pour un scénario d’automatisation SharePoint dans runtime version5.1, importez le module dans runtime version5.1.
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 :
Limitations PowerShell 7.6 est disponible en expérience d’environnement d’exécution.
Pour la version PowerShell 7.6, les activités du module ne sont pas extraites pour les modules importés.
PowerShell 7.x ne prend pas en charge les workflows. Pour plus d’informations, consultez le flux de travail PowerShell.
PowerShell 7.x ne prend pas en charge les runbooks signés pour le moment.
L’intégration du contrôle de version ne prend pas en charge PowerShell 7.6. De plus, les runbooks PowerShell 7.6 dans le contrôle de version sont créés dans le compte Automation sous le nom d’exécution 5.1.
Le module 15.1.0 d’Arizona 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.
Les modules PowerShell 7.6 importés sont validés lors de 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.
Azure Automation livres de règles ne prennent pas en charge Start-Job avec la Credenciale -.
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éez un objet PowerShell qui stocke des informations sur les machines virtuelles Azure
azurepowershell
# 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
Limitations
Remarque
La version d’exécution PowerShell 7.4 prend en charge à la fois les emplois cloud et hybrides dans toutes les régions.
- PowerShell 7.4 est disponible uniquement dans l’expérience de l’environnement d'exécution.
- Pour la version du runtime PowerShell 7.4, les activités de 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.4. En outre, les runbooks PowerShell 7.4 dans le contrôle de code source sont créés dans le compte Automation en tant que Runtime 5.1.
- Le module Az 12.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.4 importé serait 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
azurepowershell
# 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
Limitations
Remarque
La version de PowerShell 7.2 n’est plus prise en charge par le produit parent PowerShell.
- Dans la version de runtime PowerShell 7.2, les activités du module ne sont pas extraites pour les modules importés.
- 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
azurepowershell
# 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
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 en configurant le runbook pour qu'il ne sorte que les informations nécessaires au traitement 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
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.4 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 Az.Accounts module vers la version 2.4.0 pour le runtime PowerShell 7, car il peut y avoir un comportement inattendu à l’aide de 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 Az PowerShell.Compute version 4.20.0 dépend de Az.Accounts version >= 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 3.10. Vous pouvez modifier directement le code du runbook dans le portail Azure à l'aide de l'éditeur de texte. Vous pouvez également utiliser un éditeur de texte hors ligne et importer le runbook dans Azure Automation. Python 2.7 et Python 3.8 ne sont plus pris en charge par le produit parent et il est recommandé de créer des runbooks dans la version du runtime Python 3.10.
La version d’exécution Python 3.10 est prise en charge aussi bien pour les emplois cloud que hybrides dans toutes les régions.
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.
- Les scripts et les packages de toute version 3.x peuvent fonctionner si le code est compatible entre les différentes versions.
- Pour les travaux Python 3.10 hybrides sur les machines Windows, vous pouvez choisir d’installer n’importe quelle version 3.x que vous souhaiterez peut-être utiliser.
- Pour les travaux Hybrides Python 3.10 sur les machines Linux, nous dépendons de la version python 3 installée sur la machine pour exécuter DSC OMSConfig et Linux Hybrid Worker. 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
Les limitations des runbooks Python sont les suivantes :
- Pour les modules Python 3.10, seuls les fichiers wheel ciblant le système d'exploitation Linux pour 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 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 ne sont pris en charge qu’à partir du portail Azure et de l’API Rest.
- Python 3.8 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.
- 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 n’est plus pris en charge par le produit parent Python. Nous vous recommandons de créer de nouveaux runbooks dans les versions actuellement prises en charge et de mettre à jour ceux qui sont 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.
Remarque
L’utilisation d’un webhook pour démarrer un runbook Python n’est pas prise en charge.
Plusieurs versions de Python
Cela s’applique aux travailleurs hybrides de 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 Linux. 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