Gérer les runbooks dans Azure Automation
Vous pouvez ajouter un runbook à Azure Automation en en créant un ou en en important un existant à partir d’un fichier ou de la galerie de runbooks. Cet article fournit des informations sur la gestion d’un runbook ainsi que des modèles recommandés et les bonnes pratiques en matière de conception de runbook. Vous trouverez toutes les informations sur l’accès aux runbooks et modules communautaires dans Galeries de runbooks et de modules pour Azure Automation.
Créer un runbook
Créez un runbook dans Azure Automation à l’aide du portail Azure ou de PowerShell. Une fois le runbook créé, vous pouvez le modifier à l'aide des informations contenues dans :
- Modifier un runbook textuel dans Azure Automation
- Découvrez les concepts clés du flux de travail PowerShell pour les runbooks Automation
- Gérer des packages Python 2 dans Azure Automation
- Manager les packages Python 3 (préversion) dans Azure Automation
Créer un runbook dans le portail Azure
- Connectez-vous au portail Azure.
- Recherchez et sélectionnez Comptes Automation.
- Sur la page Comptes Automation, accédez à la liste et sélectionnez votre compte Automation.
- À partir du compte Automation, sélectionnez Runbooks sous Automatisation de processus pour ouvrir la liste des runbooks.
- Cliquez sur Créer un runbook.
- Nommez le runbook.
- Dans la liste déroulante Type de runbook, sélectionnez son type. Le nom du runbook doit commencer par une lettre et peut contenir des lettres, des chiffres, des traits de soulignement et des tirets
- Sélectionnez la Version du runtime
- Entrez la Description applicable
- Cliquez sur Créer pour créer le runbook.
Créer un Runbook avec PowerShell
Utilisez l’applet de commande New-AzAutomationRunbook pour créer un runbook vide. Utilisez le paramètre Type pour spécifier l’un des types de runbook définis pour New-AzAutomationRunbook.
L’exemple suivant montre comment créer un runbook vide.
$params = @{
AutomationAccountName = 'MyAutomationAccount'
Name = 'NewRunbook'
ResourceGroupName = 'MyResourceGroup'
Type = 'PowerShell'
}
New-AzAutomationRunbook @params
Importer un runbook
Vous pouvez importer un script ou un workflow PowerShell (.ps1), un runbook graphique (.graphrunbook) ou un script Python 2 ou Python 3 (.py) pour créer votre propre runbook. Vous devez spécifier le type de runbook qui sera créé lors de l'importation et ce, en tenant compte des considérations suivantes.
Vous pouvez importer un fichier .ps1 qui ne contient pas de workflow dans un runbook PowerShell ou un runbook PowerShell Workflow. Si vous l’importez dans un runbook PowerShell Workflow, il est converti en workflow. Dans ce cas, les commentaires sont inclus dans le runbook pour décrire les modifications apportées.
Vous ne pouvez importer un fichier .ps1 contenant un workflow PowerShell que dans un runbook PowerShell Workflow. Si le fichier contient plusieurs workflows PowerShell, l’importation échoue. Vous devez enregistrer chaque workflow dans son propre fichier, puis les importer séparément.
N'importez pas de fichier .ps1 contenant un workflow PowerShell dans un runbook PowerShell car le moteur de script PowerShell ne peut pas le reconnaître.
Importez un fichier .graphrunbook que dans un nouveau runbook graphique.
Importer un runbook à partir du portail Azure
Vous pouvez utiliser la procédure suivante pour importer un fichier de script dans Azure Automation.
Remarque
Vous pouvez uniquement importer un fichier .ps1 dans un runbook PowerShell Workflow à l’aide du portail.
- Sur le portail Azure, recherchez et sélectionnez Comptes Automation.
- Sur la page Comptes Automation, accédez à la liste et sélectionnez votre compte Automation.
- À partir du compte Automation, sélectionnez Runbooks sous Automatisation de processus pour ouvrir la liste des runbooks.
- Cliquez sur Importer un runbook. Vous pouvez sélectionner l'une des options suivantes :
- Rechercher un fichier : sélectionne un fichier sur votre machine locale.
- Rechercher dans la galerie : vous pouvez rechercher et sélectionner un runbook existant à partir de la galerie.
- Sélectionnez le fichier .
- Si le champ Nom est activé, vous avez la possibilité de modifier le nom du runbook. Celui-ci doit commencer par une lettre et peut contenir des lettres, des chiffres, des traits de soulignement et des tirets.
- Le Type de runbook est rempli automatiquement, mais vous pouvez le changer après avoir pris en compte les restrictions applicables.
- La Version du runtime est remplie automatiquement, mais vous pouvez sélectionner la version dans la liste déroulante.
- Cliquez sur Importer. Le nouveau runbook apparaît dans la liste des runbooks du compte Automation.
- Vous devez publier le runbook avant de pouvoir l’exécuter.
Remarque
Après avoir importé un runbook graphique, vous pouvez en convertir le type. Toutefois, vous ne pouvez pas convertir un runbook graphique en runbook textuel.
Importer un Runbook avec PowerShell
Utilisez l’applet de commande Import-AzAutomationRunbook pour importer un fichier de script en tant que brouillon de runbook. Si le runbook existe déjà, l’importation échoue, sauf si vous utilisez le paramètre Force avec l’applet de commande.
L’exemple suivant montre comment importer un fichier de script dans un runbook.
$params = @{
AutomationAccountName = 'MyAutomationAccount'
Name = 'Sample_TestRunbook'
ResourceGroupName = 'MyResourceGroup'
Type = 'PowerShell'
Path = 'C:\Runbooks\Sample_TestRunbook.ps1'
}
Import-AzAutomationRunbook @params
Gérer les ressources
Si votre runbook crée une ressource, le script doit vérifier qu’elle n’existe pas déjà avant d’essayer de la créer. Voici un exemple simple.
$vmName = 'WindowsVM1'
$rgName = 'MyResourceGroup'
$myCred = Get-AutomationPSCredential 'MyCredential'
$vmExists = Get-AzResource -Name $vmName -ResourceGroupName $rgName
if (-not $vmExists) {
Write-Output "VM $vmName does not exist, creating"
New-AzVM -Name $vmName -ResourceGroupName $rgName -Credential $myCred
} else {
Write-Output "VM $vmName already exists, skipping"
}
Récupérer les détails du journal d’activité
Vous pouvez récupérer les détails d’un runbook, comme le nom de la personne ou le compte qui a démarré le runbook, à partir du journal d’activité du compte Automation. L’exemple PowerShell suivant indique le dernier utilisateur à avoir exécuté le runbook spécifié.
$rgName = 'MyResourceGroup'
$accountName = 'MyAutomationAccount'
$runbookName = 'MyRunbook'
$startTime = (Get-Date).AddDays(-1)
$params = @{
ResourceGroupName = $rgName
StartTime = $startTime
}
$JobActivityLogs = (Get-AzLog @params).Where( { $_.Authorization.Action -eq 'Microsoft.Automation/automationAccounts/jobs/write' })
$JobInfo = @{}
foreach ($log in $JobActivityLogs) {
# Get job resource
$JobResource = Get-AzResource -ResourceId $log.ResourceId
if ($null -eq $JobInfo[$log.SubmissionTimestamp] -and $JobResource.Properties.Runbook.Name -eq $runbookName) {
# Get runbook
$jobParams = @{
ResourceGroupName = $rgName
AutomationAccountName = $accountName
Id = $JobResource.Properties.JobId
}
$Runbook = Get-AzAutomationJob @jobParams | Where-Object RunbookName -EQ $runbookName
# Add job information to hashtable
$JobInfo.Add($log.SubmissionTimestamp, @($Runbook.RunbookName, $Log.Caller, $JobResource.Properties.jobId))
}
}
$JobInfo.GetEnumerator() | Sort-Object Key -Descending | Select-Object -First 1
Suivre la progression
Il est recommandé de créer des runbooks de nature modulaire, avec une logique pouvant être réutilisée et redémarrée facilement. Le suivi de la progression d’un runbook garantit que la logique du runbook s’exécute correctement en cas de problème.
Vous pouvez suivre la progression d’un runbook en utilisant une source externe, notamment un compte de stockage, une base de données ou des fichiers partagés. Créez une logique dans votre runbook qui vérifie dans un premier temps l’état de la dernière action effectuée. Ensuite, selon les résultats de la vérification, la logique peut ignorer ou poursuivre certaines tâches du runbook.
Prévention des travaux simultanés
Certains runbooks peuvent se comporter bizarrement quand ils exécutent plusieurs tâches en même temps. Dans ce cas, il est important qu’un runbook implémente une logique qui puisse déterminer si une tâche est déjà en cours d’exécution. Voici un exemple simple.
# Ensures you do not inherit an AzContext in your runbook
Disable-AzContextAutosave -Scope Process
# Connect to Azure with system-assigned managed identity
$AzureContext = (Connect-AzAccount -Identity).context
# set and store context
$AzureContext = Set-AzContext -SubscriptionName $AzureContext.Subscription -DefaultProfile $AzureContext
# Check for already running or new runbooks
$runbookName = "runbookName"
$resourceGroupName = "resourceGroupName"
$automationAccountName = "automationAccountName"
$jobs = Get-AzAutomationJob -ResourceGroupName $resourceGroupName -AutomationAccountName $automationAccountName -RunbookName $runbookName -DefaultProfile $AzureContext
# Ranking all the active jobs
$activeJobs = $jobs | where {$_.status -eq 'Running' -or $_.status -eq 'Queued' -or $_.status -eq 'New' -or $_.status -eq 'Activating' -or $_.status -eq 'Resuming'} | Sort-Object -Property CreationTime
$jobRanking = @()
$rank = 0
ForEach($activeJob in $activeJobs)
{
$rank = $rank + 1
$activeJob | Add-Member -MemberType NoteProperty -Name jobRanking -Value $rank -Force
$jobRanking += $activeJob
}
$AutomationJobId = $PSPrivateMetadata.JobId.Guid
$currentJob = $activeJobs | where {$_.JobId -eq $AutomationJobId}
$currentJobRank = $currentJob.jobRanking
# Only allow the Job with Rank = 1 to start processing.
If($currentJobRank -ne "1")
{
Write-Output "$(Get-Date -Format yyyy-MM-dd-hh-mm-ss.ffff) Concurrency check failed as Current Job Ranking is not 1 but $($currentJobRank) therefore exiting..."
Exit
} Else
{
Write-Output "$(Get-Date -Format yyyy-MM-dd-hh-mm-ss.ffff) Concurrency check passed. Start processing.."
}
Si vous souhaitez que le runbook s’exécute avec l’identité managée affectée par le système, laissez le code tel quel. Si vous préférez utiliser une identité managée affectée par l’utilisateur, procédez comme suit :
- À la ligne 5, supprimez
$AzureContext = (Connect-AzAccount -Identity).context, - Remplacez-la par
$AzureContext = (Connect-AzAccount -Identity -AccountId <ClientId>).contextet - Entrez l'ID client.
Remarque
Pour les tâches hybrides PowerShell 7.2, apportez les modifications à la ligne 28. Remplacez $PSPrivateMetadata.JobId.Guid par $env:PSPrivateMetaData.
Gérer les erreurs temporaires dans un script dépendant de l’heure
Vos runbooks doivent être robustes et capables de gérer les erreurs temporaires, notamment les erreurs temporaires qui peuvent entraîner leur redémarrage ou une défaillance. Si un runbook rencontre une défaillance, Azure Automation effectue un nouvel essai.
Si votre runbook s’exécute normalement dans les limites d’une contrainte de temps, faites en sorte que le script implémente la logique pour vérifier la durée d’exécution. Cette vérification contrôle la bonne exécution de certaines opérations comme le démarrage, l’arrêt ou le scale-out, uniquement à des moment précis.
Remarque
L’heure locale du processus de bac à sable Azure est définie sur le temps universel coordonné (UTC). Les calculs de date et d’heure dans vos runbooks doivent prendre cet élément en considération.
Logique de nouvelle tentative dans le runbook pour éviter les échecs temporaires
Les Runbooks appellent souvent des systèmes distants tels qu'Azure via ARM, Azure Resource Graph, des services SQL et d'autres services Web. Lorsque le système appelé par les runbooks est occupé, temporairement indisponible ou implémente une limitation sous charge, les appels sont vulnérables aux erreurs d'exécution. Pour renforcer la résilience des runbooks, vous devez implémenter une logique de nouvelle tentative lors des appels afin que les runbooks puissent gérer un problème passager sans échouer.
Pour plus d’informations, consultez Modèle de nouvelle tentative et Directives générales REST et nouvelle tentative.
Exemple 1 : si votre runbook n'effectue qu'un ou deux appels
$searchServiceURL = "https://$searchServiceName.search.windows.net"
$resource = Get-AzureRmResource -ResourceType "Microsoft.Search/searchServices" -ResourceGroupName $searchResourceGroupName -ResourceName $searchServiceName -ApiVersion 2015-08-19
$searchAPIKey = (Invoke-AzureRmResourceAction -Action listAdminKeys -ResourceId $resource.ResourceId -ApiVersion 2015-08-19 -Force).PrimaryKey
Lorsque vous appelez Invoke-AzureRmResourceAction, vous pouvez observer des pannes passagères. Dans un tel scénario, nous vous recommandons d’implémenter le modèle de base suivant autour de l’appel à l’applet de commande.
$searchServiceURL = "https://$searchServiceName.search.windows.net"
$resource = Get-AzureRmResource -ResourceType "Microsoft.Search/searchServices" -ResourceGroupName $searchResourceGroupName -ResourceName $searchServiceName -ApiVersion 2015-08-19
# Adding in a retry
$Stoploop = $false
$Retrycount = 0
do {
try {
$searchAPIKey = (Invoke-AzureRmResourceAction -Action listAdminKeys -ResourceId $resource.ResourceId -ApiVersion 2015-08-19 -Force).PrimaryKey
write-verbose "Invoke-AzureRmResourceAction on $resource.ResourceId completed"
$Stoploop = $true
}
catch {
if ($Retrycount -gt 3)
{
Write-verbose "Could not Invoke-AzureRmResourceAction on $resource.ResourceId after 3 retrys."
$Stoploop = $true
}
else
{
Write-verbose "Could not Invoke-AzureRmResourceAction on $resource.ResourceId retrying in 30 seconds..."
Start-Sleep -Seconds 30
$Retrycount = $Retrycount + 1
}
}
}
While ($Stoploop -eq $false)
Remarque
Vous pouvez tenter de réessayer l'appel jusqu'à trois fois, en dormant 30 secondes à chaque fois.
Exemple 2 : si le runbook effectue des appels à distance fréquents
Si le runbook effectue des appels à distance fréquents, il peut rencontrer des problèmes d'exécution temporaires. Créez une fonction qui implémente la logique de nouvelle tentative pour chaque appel effectué et transmettez l'appel à effectuer sous forme de bloc de script à exécuter.
Function ResilientRemoteCall {
param(
$scriptblock
)
$Stoploop = $false
$Retrycount = 0
do {
try {
Invoke-Command -scriptblock $scriptblock
write-verbose "Invoked $scriptblock completed"
$Stoploop = $true
}
catch {
if ($Retrycount -gt 3)
{
Write-verbose "Invoked $scriptblock failed 3 times and we will not try again."
$Stoploop = $true
}
else
{
Write-verbose "Invoked $scriptblock failed retrying in 30 seconds..."
Start-Sleep -Seconds 30
$Retrycount = $Retrycount + 1
}
}
}
While ($Stoploop -eq $false)
}
Vous pouvez ensuite transmettre chaque appel à distance dans la fonction comme
ResilientRemoteCall { Get-AzVm }
ou
ResilientRemoteCall { $searchAPIKey = (Invoke-AzureRmResourceAction -Action listAdminKeys -ResourceId $resource.ResourceId -ApiVersion 2015-08-19 -Force).PrimaryKey}
Utilisation de plusieurs abonnements
Votre runbook doit pouvoir utiliser des abonnements. Par exemple, pour gérer plusieurs abonnements, le runbook utilise la cmdlet Disable-AzContextAutosave. Cette cmdlet permet de s'assurer que le contexte d’authentification n’est pas récupéré à partir d’un autre runbook s'exécutant dans le même bac à sable.
# Ensures you do not inherit an AzContext in your runbook
Disable-AzContextAutosave -Scope Process
# Connect to Azure with system-assigned managed identity
$AzureContext = (Connect-AzAccount -Identity).context
# set and store context
$AzureContext = Set-AzContext -SubscriptionName $AzureContext.Subscription `
-DefaultProfile $AzureContext
$childRunbookName = 'childRunbookDemo'
$resourceGroupName = "resourceGroupName"
$automationAccountName = "automationAccountName"
$startParams = @{
ResourceGroupName = $resourceGroupName
AutomationAccountName = $automationAccountName
Name = $childRunbookName
DefaultProfile = $AzureContext
}
Start-AzAutomationRunbook @startParams
Si vous souhaitez que le runbook s’exécute avec l’identité managée affectée par le système, laissez le code tel quel. Si vous préférez utiliser une identité managée affectée par l’utilisateur, procédez comme suit :
- À la ligne 5, supprimez
$AzureContext = (Connect-AzAccount -Identity).context, - Remplacez-la par
$AzureContext = (Connect-AzAccount -Identity -AccountId <ClientId>).contextet - Entrez l'ID client.
Utilisation d’un script personnalisé
Remarque
Normalement, vous ne pouvez pas exécuter des scripts personnalisés et des runbooks sur l’hôte sur lequel est installé un agent Log Analytics.
Pour utiliser un script personnalisé :
- Créer un compte Automation.
- Déployez un rôle Runbook Worker hybride.
- Si vous utilisez un ordinateur Linux, vous devez disposer de privilèges élevés. Connectez-vous pour désactiver les vérifications de signature.
Tester un runbook
Lorsque vous testez un runbook, la version Brouillon est exécutée et toutes les actions qu’il effectue sont finalisées. Aucun historique des travaux n'est créé, mais les flux Résultat et Avertissement et Erreur s'affichent dans le volet Sortie de test. Les messages destinés au flux de commentaires ne sont affichés dans le volet des résultats que si la variable VerbosePreference est définie sur Continue.
Bien que la version Brouillon soit lancée, le runbook s'exécute normalement et effectue toutes les actions sur les ressources de l'environnement. Pour cette raison, vous devez tester les runbooks uniquement sur des ressources hors production.
Remarque
Toutes les actions d’exécution de runbook sont enregistrées dans le Journal d’activité du compte Automation avec le nom de l’opération Créer un travail Azure Automation. Toutefois, l’exécution du runbook dans un volet de test où la version brouillon du runbook est exécutée est journalisée dans les journaux d’activité avec le nom de l’opération Écrire un brouillon de runbook Azure Automation. Sélectionnez l’onglet Opération et JSON pour voir l’étendue se terminant par .. /runbooks/(nom du runbook)/brouillon/testjob.
La procédure de test de chaque type de runbook est identique. Il n’y a aucune différence de test entre l’éditeur de texte et l’éditeur graphique du portail Azure.
- Ouvrez la version Brouillon du runbook dans l’éditeur de texte ou l’éditeur graphique.
- Cliquez sur Tester pour ouvrir la page Test.
- Si le runbook a des paramètres, ils figurent dans le volet gauche dans lequel vous pouvez fournir des valeurs à utiliser pour le test.
- Si vous souhaitez exécuter le test sur un runbook Worker hybride, définissez les Paramètres d’exécution sur Worker hybride et sélectionnez le nom du groupe cible. Dans le cas contraire, conservez la valeur par défaut Azure pour exécuter le test dans le cloud.
- Cliquez sur Démarrer pour commencer le test.
- Vous pouvez utiliser les boutons situés sous le volet Sortie pour arrêter ou suspendre un workflow PowerShell ou un runbook graphique en cours de test. Lorsque vous interrompez le runbook, il termine l’activité en cours avant de s’interrompre. Lorsque le runbook est suspendu, vous pouvez l’arrêter ou le redémarrer.
- Inspectez la sortie du runbook dans le volet Sortie.
Publier un runbook
Lorsque vous créez ou importez un runbook, vous devez le publier avant de pouvoir l'exécuter. Dans Azure Automation, chaque runbook a une version brouillon et une version publiée. Seule la version publiée est disponible à l'exécution, et seul le brouillon peut être modifié. La version publiée n'est pas affectée par les modifications apportées à la version Bouillon. Quand la version brouillon doit être rendue disponible, vous la publiez, ce qui remplace la version publiée actuelle par la version brouillon.
Publier un runbook dans le portail Azure
- Sur le portail Azure, recherchez et sélectionnez Comptes Automation.
- Sur la page Comptes Automation, accédez à la liste et sélectionnez votre compte Automation.
- Ouvrez le runbook dans votre compte Automation.
- Cliquez sur Modifier.
- Cliquez sur Publier, puis sélectionnez Oui en réponse au message de vérification.
Publier un runbook à l’aide de PowerShell
Utilisez l’applet de commande Publish-AzAutomationRunbook pour publier votre runbook.
$accountName = "MyAutomationAccount"
$runbookName = "Sample_TestRunbook"
$rgName = "MyResourceGroup"
$publishParams = @{
AutomationAccountName = $accountName
ResourceGroupName = $rgName
Name = $runbookName
}
Publish-AzAutomationRunbook @publishParams
Planifier un runbook dans le portail Azure
Une fois votre runbook publié, vous pouvez le planifier en vue de l'utiliser :
- Sur le portail Azure, recherchez et sélectionnez Comptes Automation.
- Sur la page Comptes Automation, accédez à la liste et sélectionnez votre compte Automation.
- Sélectionnez le runbook dans votre liste de runbooks.
- Sélectionnez Planifications sous Ressources.
- Sélectionnez Ajouter une planification.
- Dans le volet Planifier un runbook, sélectionnez Associer une planification à votre runbook.
- Choisissez Créer une planification dans le volet Planification.
- Entrez un nom, une description et d’autres paramètres dans le volet Nouvelle planification.
- Une fois la planification créée, mettez-la en surbrillance et cliquez sur OK. Elle doit maintenant être associée à votre runbook.
- Accédez à votre boîte aux lettres et recherchez-y un e-mail qui vous informe de l'état du runbook.
Restaurer le runbook supprimé
Vous pouvez récupérer un runbook supprimé via des scripts PowerShell. Pour récupérer un runbook, assurez-vous que les conditions suivantes sont remplies :
- Les runbooks à restaurer ont été supprimés au cours des 29 derniers jours.
- Le compte Automation pour ce runbook existe.
- L’autorisation du rôle Contributeur Automation est accordée à l’identité managée attribuée par le système du compte Automation.
Script PowerShell
- Exécutez le script PowerShell en tant que tâche dans votre compte Automation pour restaurer les runbooks supprimés.
- Téléchargez le script PowerShell depuis GitHub. Vous pouvez également importer le script PowerShell nommé Runbook Restore Automation à partir de Runbook Gallery. Fournissez le nom du runbook qui doit être restauré et exécutez-le en tant que tâche dans Azure Automation pour restaurer les runbooks supprimés.
- Téléchargez le script depuis GitHub ou importez le script PowerShell nommé List Deleted Automation Runbook depuis Runbook Gallery, pour identifier les noms des runbooks qui ont été supprimés au cours des 29 derniers jours.
Obtenir les états des tâches
Afficher les états sur le portail Azure
Les détails de la gestion des tâches dans Azure Automation apparaissent dans la section Tâches. Lorsque vous êtes prêt à afficher vos tâches runbook, utilisez le portail Azure et accédez à votre compte Automation. À droite, vous pouvez voir un résumé de toutes les tâches runbook dans la section Statistiques des tâches.
Le résumé affiche un nombre et une représentation graphique de l’état de chaque tâche exécutée.
Lorsque vous cliquez sur la vignette, la page Tâches s’affiche avec un récapitulatif de toutes les tâches exécutées. Cette page indique l’état, le nom du runbook, l’heure de début et l’heure de fin de chaque tâche.
Vous pouvez filtrer la liste des tâches en sélectionnant Filtrer les tâches. Filtrez en fonction d’un runbook spécifique, d’un état de tâche ou d’un choix dans la liste déroulante, puis indiquez un intervalle de temps pour la recherche.
Vous pouvez aussi afficher un résumé détaillé des tâches d’un runbook en sélectionnant le runbook dans la page Runbooks de votre compte Automation, puis en sélectionnant Tâches. Cette action affiche la page Tâches. De là, vous pouvez cliquer sur un enregistrement de tâche pour en afficher les détails et la sortie.
Récupérer des états de tâches avec PowerShell
Utilisez l’applet de commande Get-AzureAutomationJob pour récupérer les tâches créées pour un runbook ainsi que les détails d’une tâche particulière. Si vous démarrez un runbook à l’aide de Start-AzAutomationRunbook, la tâche obtenue est retournée. Utilisez AzAutomationJobOutput pour récupérer la sortie de la tâche.
Les exemples suivants obtiennent la dernière tâche d’un exemple de runbook et affichent son état, les valeurs définies pour les paramètres du runbook et la sortie de la tâche.
$getJobParams = @{
AutomationAccountName = 'MyAutomationAccount'
ResourceGroupName = 'MyResourceGroup'
Runbookname = 'Test-Runbook'
}
$job = (Get-AzAutomationJob @getJobParams | Sort-Object LastModifiedDate -Desc)[0]
$job | Select-Object JobId, Status, JobParameters
$getOutputParams = @{
AutomationAccountName = 'MyAutomationAccount'
ResourceGroupName = 'MyResourceGroup'
Id = $job.JobId
Stream = 'Output'
}
Get-AzAutomationJobOutput @getOutputParams
L’exemple suivant récupère la sortie d’une tâche spécifique et retourne chaque enregistrement. Si une exception se produit pour l’un des enregistrements, le script écrit l’exception à la place de la valeur. Ce comportement est utile, car les exceptions peuvent fournir des informations supplémentaires qui ne sont pas nécessairement journalisées au moment de la sortie.
$params = @{
AutomationAccountName = 'MyAutomationAccount'
ResourceGroupName = 'MyResourceGroup'
Stream = 'Any'
}
$output = Get-AzAutomationJobOutput @params
foreach ($item in $output) {
$jobOutParams = @{
AutomationAccountName = 'MyAutomationAccount'
ResourceGroupName = 'MyResourceGroup'
Id = $item.StreamRecordId
}
$fullRecord = Get-AzAutomationJobOutputRecord @jobOutParams
if ($fullRecord.Type -eq 'Error') {
$fullRecord.Value.Exception
} else {
$fullRecord.Value
}
}
Étapes suivantes
- Pour obtenir des exemples de requêtes, consultez Exemples de requêtes pour les journaux de travaux et les flots de travaux
- Pour en savoir plus sur la gestion des runbooks, voir Exécution d'un Runbook dans Azure Automation.
- Pour préparer un runbook PowerShell, consultez Modifier des runbooks textuels dans Azure Automation.
- Pour résoudre les problèmes liés à l’exécution de runbooks, voir Résoudre les erreurs avec les runbooks.