Partager via

Exécution d’un runbook dans Azure Automation

  • Article

Dans Azure Automation, l'automatisation des processus vous permet de créer et de gérer PowerShell, PowerShell Workflow et des runbooks graphiques. Pour plus d'informations, consultez Utilisation de runbooks Azure Automation.

Automation exécute vos runbooks selon la logique avec laquelle ils ont été définis. Si un runbook est interrompu, il redémarre au début. Ce comportement vous contraint d’écrire des runbooks qui prennent en charge le redémarrage si des problèmes temporaires se produisent.

Dans Azure Automation, le démarrage d'un runbook crée une tâche, qui correspond à une instance d’exécution unique du runbook. Chaque tâche accède à des ressources Azure en établissant une connexion à votre abonnement Azure. La tâche accède uniquement aux ressources de votre centre de données si ces ressources sont accessibles depuis le cloud public.

Azure Automation charge un Worker d’exécuter chaque tâche pendant l’exécution du runbook. Même si les workers sont partagés par de nombreux comptes Automation, les tâches des différents comptes Automation sont isolées les unes des autres. Vous ne pouvez pas contrôler le Worker qui traite les requêtes de votre tâche.

Quand vous affichez la liste des runbooks sur le portail Azure, elle indique l’état de chaque tâche qui a été démarrée pour chaque runbook. Azure Automation stocke les journaux de tâches pendant une durée maximale de 30 jours.

Le diagramme suivant illustre le cycle de vie d’une tâche de runbook pour les runbooks PowerShell, les runbooks de workflow PowerShell et les runbooks graphiques.

États des tâches - Workflow PowerShell

Remarque

Pour plus d’informations sur la visualisation ou la suppression de données personnelles, consultez Demandes de la personne concernée pour le RGPD – Général, Demandes de la personne concernée pour le RGPD – Azure ou Demandes de la personne concernée pour le RGPD – Windows, en fonction de votre domaine et de vos besoins spécifiques. Pour plus d’informations sur le Règlement général sur la protection des données (RGPD), consultez la section relative au RGPD du Centre de gestion de la confidentialité de Microsoft et la section relative au RGPD du Portail d’approbation de services.

Environnement d’exécution de runbook

Les runbooks d’Azure Automation peuvent s’exécuter dans un bac à sable Azure ou dans un runbook Worker hybride.

Les runbooks conçus pour s’authentifier et s’exécuter sur des ressources dans Azure s’exécutent dans un bac à sable Azure. Azure Automation affecte un worker pour exécuter chaque tâche pendant l’exécution du runbook dans le bac à sable. Même si les workers sont partagés par de nombreux comptes Automation, les tâches des différents comptes Automation sont isolées les unes des autres. Les travaux qui utilisent le même bac à sable sont liés par les limitations de ressources du bac à sable. L’environnement sandbox Azure ne prend pas en charge les opérations interactives. Il empêche l’accès à tous les serveurs COM hors processus et ne prend pas en charge les appels WMI vers le fournisseur Win32 dans votre runbook.  Ces scénarios sont pris en charge uniquement en exécutant le runbook sur un Runbook Worker hybride Windows.

Vous pouvez également utiliser un runbook Worker hybride pour exécuter des runbooks directement sur l’ordinateur qui héberge le rôle et avec les ressources disponibles dans l’environnement. Azure Automation stocke et gère les runbooks et les remet à un ou plusieurs ordinateurs assignés.

L’activation du Pare-feu Azure sur Stockage Microsoft Azure, Azure Key Vault ou Azure SQL bloque l’accès à partir des runbooks Azure Automation pour ces services. L'accès sera bloqué même lorsque l'exception du pare-feu pour autoriser les services Microsoft de confiance est activée, car Automation ne fait pas partie de la liste des services de confiance. Lorsqu'un pare-feu est activé, l'accès n'est possible qu'à l'aide d'un Runbook Worker hybride et d'un point de terminaison de service de réseau virtuel.

Remarque

  • Pour s’exécuter sur un runbook Worker hybride Linux, vos scripts doivent être signés et le Worker configuré en conséquence. Sinon, la validation de la signature doit être désactivée.
  • L’exécution du Runbook ne doit pas dépendre du fuseau horaire du bac à sable.

Le tableau suivant liste certaines tâches d’exécution de runbook avec l’environnement d’exécution recommandé indiqué pour chacune d’elles.

Tâche Recommandation Notes
Intégration à des ressources Azure Bac à sable Azure Hébergé dans Azure, l’authentification est plus simple. Si vous utilisez un Runbook Worker hybride sur une machine virtuelle Azure, vous pouvez utiliser une authentification de runbook avec des identités managées.
Obtention de performances optimales pour gérer les ressources Azure Bac à sable Azure Le script est exécuté dans le même environnement, dont la latence est moindre.
Réduction des coûts d'exploitation Bac à sable Azure Il n'y a pas de surcharge de calcul et pas besoin de VM.
Exécution d’un script de longue durée Runbook Worker hybride Les bacs à sable Azure présentent des limites de ressources.
Interaction avec les services locaux Runbook Worker hybride Accédez directement à l’ordinateur hôte, ou aux ressources dans d’autres environnements cloud ou dans l’environnement local.
Imposer des logiciels et des fichiers exécutables tiers Runbook Worker hybride Vous gérez le système d’exploitation et pouvez installer des logiciels.
Surveillance d'un fichier ou d'un dossier avec un runbook Runbook Worker hybride Utilisez une tâche Watcher sur un runbook Worker hybride.
Exécution d’un script gourmand en ressources Runbook Worker hybride Les bacs à sable Azure présentent des limites de ressources.
Utilisation de modules ayant des exigences spécifiques Runbook Worker hybride En voici quelques exemples :
WinSCP - dépendance vis-à-vis de winscp.exe
Administration IIS - dépendance vis-à-vis de l'activation ou de la gestion de IIS
Installation d’un module avec un programme d’installation Runbook Worker hybride Les modules pour bac à sable doivent prendre en charge la copie.
Utilisation de runbooks ou de modules nécessitant une version de .NET Framework différente de la version 4.7.2 Runbook Worker hybride Les bacs à sable Azure prennent en charge .NET Framework 4.7.2 et la mise à niveau vers une version différente n'est pas prise en charge.
Exécution de scripts qui nécessitent une élévation Runbook Worker hybride Les bacs à sable ne permettent pas l’élévation. Avec un runbook Worker hybride, vous pouvez désactiver le Contrôle de compte d’utilisateur (UAC) et utiliser Invoke-Command au moment d’exécuter la commande qui nécessite une élévation.
Exécuter des scripts nécessitant un accès à WMI (Windows Management Instrumentation) Runbook Worker hybride Les tâches s’exécutant dans les bacs à sable du cloud ne peuvent pas accéder au fournisseur WMI.

Stockage temporaire dans un environnement de type « bac à sable » (« sandbox »)

Si vous devez créer des fichiers temporaires dans le cadre de votre logique runbook, vous pouvez utiliser le dossier Temp (autrement dit, $env:TEMP) dans l’environnement de type « bac à sable » (« sandbox ») d’Azure pour les runbooks s’exécutant dans Azure. La seule limitation est que vous ne pouvez pas utiliser plus de 1 Go d'espace disque, ce qui correspond au quota de chaque bac à sable. Lorsque vous travaillez avec des workflows PowerShell, ce scénario peut provoquer un problème, car les workflows PowerShell utilisent des points de contrôle et le script peut être retenté dans un bac à sable différent.

L’environnement de bac à sable hybride vous permet d’utiliser C:\temp en fonction de la disponibilité du stockage sur un Runbook Worker hybride. Toutefois, conformément aux suggestions de la machine virtuelle Azure, vous ne devez pas utiliser le disque temporaire sous Windows ou Linux pour les données qui doivent être conservées.

Ressources

Vos runbooks doivent inclure une logique pour gérer des ressources, par exemple, des machines virtuelles, le réseau et des ressources sur le réseau. Les ressources sont liées à un abonnement Azure et les runbooks requièrent des informations d’identification appropriées pour accéder à une ressource. Pour obtenir un exemple de gestion des ressources dans un runbook, consultez Gérer les ressources.

Sécurité

Azure Automation utilise Microsoft Defender pour le cloud pour assurer la sécurité de vos ressources et détecter les compromissions dans les systèmes Linux. La sécurité est fournie dans vos charges de travail, que les ressources se trouvent dans Azure ou non. Voir Présentation de l’authentification dans Azure Automation.

Defender pour le cloud applique des contraintes aux utilisateurs qui peuvent exécuter des scripts, signés ou non, sur une machine virtuelle. Si vous êtes un utilisateur disposant d'un accès root à une VM, vous devez configurer explicitement la machine avec une signature numérique ou la désactiver. Sinon, vous ne pouvez exécuter un script que pour appliquer des mises à jour du système d’exploitation après avoir créé un compte Automation et activé la fonctionnalité appropriée.

Abonnements

Un abonnement Azure est un accord avec Microsoft qui vous autorise à utiliser un ou plusieurs services cloud pour lesquels vous êtes facturé. Pour Azure Automation, chaque abonnement est lié à un compte Azure Automation et vous pouvez créer plusieurs abonnements dans le compte.

Informations d'identification

Un runbook nécessite des informations d’identification appropriées pour accéder à toutes les ressources, qu’il s’agisse d’Azure ou de systèmes tiers. Ces informations d’identification sont stockées dans Azure Automation, Key Vault, etc.

Azure Monitor

Azure Automation utilise Azure Monitor pour superviser ses opérations sur les machines. Les opérations nécessitent un espace de travail Log Analytics et un agent Log Analytics.

Agent Log Analytics pour Windows

L’agent Log Analytics pour Windows fonctionne avec Azure Monitor pour gérer les machines virtuelles et les ordinateurs physiques Windows. Les ordinateurs peuvent être exécutés dans Azure ou dans un environnement non-Azure, par exemple un centre de données local.

Remarque

L’agent Log Analytics pour Windows s’appelait auparavant Microsoft Monitoring Agent (MMA).

Agent Log Analytics pour Linux

L’agent Log Analytics pour Linux fonctionne de la même façon que l’agent pour Windows, mais il connecte les ordinateurs Linux à Azure Monitor. L’agent est installé avec certains comptes de service qui exécutent des commandes nécessitant des autorisations racine. Pour plus d’informations, consultez Comptes de service.

Le journal de l’agent de Log Analytics se trouve dans /var/opt/microsoft/omsagent/log/omsagent.log.

Autorisations de Runbook

Un runbook a besoin d’autorisations pour l’authentification auprès d’Azure, par le biais des informations d’identification. Consultez Vue d’ensemble de l’authentification Azure Automation.

Modules

Azure Automation comprend les modules PowerShell suivants :

  • Orchestrator.AssetManagement.Cmdlets : contient plusieurs cmdlets internes qui ne sont disponibles que si les runbooks sont exécutés dans l’environnement de bac à sable (sandbox) Azure ou sur un Runbook Worker hybride Windows. Ces cmdlets sont conçues pour être utilisées à la place des cmdlets Azure PowerShell pour interagir avec les ressources de votre compte Automation.
  • Az.Automation : module PowerShell recommandé pour interagir avec Azure Automation (qui remplace le module AzureRM.Automation). Il n’est pas inclus automatiquement lorsque vous créez un compte Automation : vous devez l’importer manuellement.
  • AzureRM.Automation : module installé par défaut lorsque vous créez un compte Automation.

Sont également pris en charge les modules installables, en fonction des cmdlets requises par les runbooks et les configurations DSC. Pour plus d’informations sur les modules disponibles pour vos runbooks et configurations DSC, consultez Gérer des modules dans Azure Automation.

Certificats

Azure Automation utilise des certificats pour l’authentification auprès Azure, ou les ajoute à Azure ou à des ressources tierces. Les certificats sont stockés de façon sécurisée pour l’accès par des runbooks et des configurations DSC.

Vos runbooks peuvent utiliser des certificats auto-signés, qui ne sont pas signés par une autorité de certification (CA). Voir Créer un certificat.

Tâches

Azure Automation prend en charge un environnement pour exécuter des tâches à partir du même compte Automation. Un même runbook peut avoir beaucoup de tâches qui s’exécutent simultanément. Plus vous exécutez de travaux simultanément, plus ils peuvent être répartis vers le même bac à sable. Un maximum de 10 travaux peuvent s’exécuter dans un bac à sable. Un bac à sable est supprimé lorsqu’aucun travail n’est en cours d’exécution ; par conséquent, il ne doit pas être utilisé pour enregistrer des fichiers.

Les tâches qui s’exécutent dans le même processus de bac à sable peuvent s’influencer mutuellement. C’est par exemple ce qui arrive quand l’applet de commande Disconnect-AzAccount est exécutée. Dans ce cas, cette applet de commande déconnecte chaque tâche du runbook dans le processus de bac à sable partagé. Pour obtenir un exemple d’utilisation de ce scénario, consultez Prévention des travaux simultanés.

Remarque

Les tâches PowerShell démarrées à partir d’un runbook qui s’exécute dans un bac à sable Azure peut ne pas s’exécuter en mode langage PowerShell complet.

États des tâches

Le tableau suivant décrit les différents états possibles d’une tâche. Vous pouvez afficher un résumé de l’état de toutes les tâches du runbook ou explorer les détails d’une tâche spécifique du runbook dans le portail Azure. Vous pouvez également configurer une intégration à votre espace de travail Log Analytics pour transférer l’état et les flux de travaux du runbook. Pour plus d’informations sur l’intégration avec les journaux d’activité Azure Monitor, consultez Transférer l’état d’un travail et des flux de travail d’Automation vers les journaux d’activité Azure Monitor. Pour obtenir un exemple d’utilisation des états dans un runbook, voir aussi Obtenir les états des tâches.

Statut Description
Activation Le travail en cours d’activation.
Terminée La tâche s'est terminée avec succès.
Échec Un runbook graphique ou un graphique de workflow PowerShell n’a pas pu être compilé. Un runbook PowerShell n’a pas pu démarrer ou la tâche a rencontré une exception. Consultez Types de runbooks Azure Automation.
Échec, en attente de ressources La tâche a échoué, car elle a atteint la limite de répartition de charge équilibrée trois fois et a démarré à partir du même point de contrôle ou à partir du début du Runbook à chaque fois.
Mis(e) en file d’attente La tâche attend que les ressources d’un Worker Automation deviennent disponibles pour pouvoir démarrer.
En cours de reprise Le système reprend la tâche suspendue.
En cours d’exécution La tâche est en cours d'exécution.
En cours d'exécution, en attente de ressources La tâche a été déchargée, car elle a atteint la limite de répartition de charge équilibrée. Elle va bientôt reprendre depuis son dernier point de contrôle.
Démarrage en cours La tâche a été attribuée à un travail et le système la démarre.
Arrêté La tâche a été arrêtée par l'utilisateur avant qu'elle n'ait été terminée.
Arrêt en cours Le système arrête la tâche.
Interrompu S’applique aux runbooks graphiques et aux runbooks de workflow PowerShell uniquement. La tâche a été suspendue par l'utilisateur, le système ou une commande du Runbook. Si un runbook n’a pas de point de contrôle défini, il démarre à partir du début. S’il a un point de contrôle défini, il peut recommencer et reprendre à partir de son dernier point de contrôle. Le système suspend uniquement le runbook quand une exception se produit. Par défaut, la variable ErrorActionPreference est définie sur Continue, ce qui indique que la tâche continue de s’exécuter en cas d’erreur. Si la variable de préférence est définie sur Stop, la tâche est suspendue en cas d’erreur.
Suspension S’applique aux runbooks graphiques et aux runbooks de workflow PowerShell uniquement. Le système tente de suspendre la tâche à la demande de l’utilisateur. Le Runbook doit atteindre son prochain point de contrôle avant de pouvoir être suspendu. S’il a déjà passé son dernier point de contrôle, il se termine avant d’être suspendu.
Nouvelle Le travail a été envoyé récemment, mais n’est pas encore activé.

Journalisation des activités

L’exécution de runbooks dans Azure Automation consigne les détails dans un journal d’activité pour le compte Automation. Pour plus d’informations sur l’utilisation du journal, consultez Récupérer les détails à partir du journal d’activité.

Exceptions

Cette section décrit des méthodes pour gérer les exceptions ou les problèmes intermittents qui se produisent dans vos runbooks. Par exemple, une exception WebSocket. Une gestion correcte des exceptions empêche des pannes de réseau temporaires de provoquer une défaillance de vos runbooks.

ErrorActionPreference

La variable ErrorActionPreference détermine la façon dont PowerShell répond à une erreur qui ne met pas fin à l’exécution. Les erreurs avec fin d’exécution provoquent systématiquement l'arrêt et ne sont pas affectées par ErrorActionPreference.

Lorsque le runbook utilise ErrorActionPreference, une erreur qui ne met normalement pas fin à l’exécution, comme PathNotFoundGet-ChildItem issue de la cmdlet qui empêche le runbook d’aboutir. L’exemple suivant illustre l’utilisation de ErrorActionPreference. La commande finale Write-Output ne s’exécute jamais, car le script s’arrête.

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

Try Catch

Try Catch Finally est utilisé dans les scripts PowerShell pour gérer les erreurs qui mettent fin à l’exécution. Le script peut utiliser ce mécanisme pour intercepter des exceptions spécifiques ou générales. L’instruction catch doit être utilisée pour suivre ou essayer de gérer les erreurs. L’exemple suivant tente de télécharger un fichier qui n’existe pas. Il intercepte l’exception System.Net.WebException et retourne la dernière valeur pour toute autre exception.

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

Throw

Throw peut être utilisée pour générer une erreur avec fin d’exécution. Ce mécanisme peut vous être utile au moment de définir votre propre logique dans un runbook. Si le script remplit un critère qui doit l’arrêter, il peut utiliser l’instruction throw pour s’arrêter. L’exemple suivant utilise cette instruction pour afficher un paramètre de fonction obligatoire.

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

Erreurs

Vos runbooks doivent gérer les erreurs. Azure Automation prend en charge deux types d’erreurs PowerShell : celles qui mettent fin à l’exécution et celles qui ne mettent pas fin à l’exécution.

Quand elles se produisent, les erreurs qui mettent fin à l’exécution arrêtent l’exécution d’un runbook. Le runbook s’arrête et l’état de la tâche devient Échec.

Les erreurs qui ne mettent pas fin à l’exécution n’empêchent pas la poursuite d’un script. Par exemple, un runbook qui utilise l’applet de commande Get-ChildItem avec un chemin qui n’existe pas génère une erreur qui ne met pas fin à l’exécution. PowerShell détecte que le chemin n’existe pas, il génère une erreur et il passe au dossier suivant. Dans ce cas, l’erreur n’affecte pas l’état Échec à la tâche du runbook, laquelle peut même arriver à son terme. Pour forcer l’arrêt d’un runbook après une erreur sans fin d’exécution, utilisez ErrorAction Stop avec l’applet de commande.

Processus d’appel

Les runbooks qui s’exécutent dans les bacs à sable Azure ne prennent pas en charge les processus d’appel, comme les exécutables (fichiers .exe) ou les sous-processus. Cela s’explique par le fait qu’un bac à sable Azure est un processus partagé qui s’exécute dans un conteneur qui n’a peut-être pas accès à toutes les API sous-jacentes. Pour les scénarios qui exigent un logiciel tiers ou des appels à des sous-processus, exécutez le runbook sur un runbook Worker hybride.

Caractéristiques des appareils et des applications

Les tâches de runbook dans les bacs à sable Azure ne peuvent avoir accès aux caractéristiques des appareils ou des applications. Pour interroger les métriques de performances sur Windows, notamment celles, courantes, qui portent sur l’utilisation de la mémoire et du processeur, L’API la plus utilisée est WMI. Cependant, quelle que soit l’API utilisée, les tâches qui s’exécutent dans le cloud ne peuvent avoir accès à l’implémentation Microsoft de WBEM (Web-Based Enterprise Management). Cette plateforme est basée sur CIM (Common Information Model), qui fait office de standard sectoriel pour la définition des caractéristiques des appareils et des applications.

Webhooks

Les services externes, par exemple, Azure DevOps Services et GitHub, peuvent démarrer un runbook dans Azure Automation. Pour effectuer ce type de démarrage, le service utilise un webhook via une requête HTTP unique. L’utilisation d’un Webhook permet de démarrer runbooks sans implémenter une fonctionnalité Azure Automation complète.

Ressources partagées

Pour partager des ressources entre tous les runbooks dans le cloud, Azure utilise un concept appelé « répartition de charge équilibrée ». Grâce à la répartition de charge équilibrée, Azure décharge ou arrête toute tâche exécutée depuis plus de trois heures. Les tâches des runbooks PowerShell et des runbooks Python sont arrêtées et non redémarrées, et leur état devient Arrêté.

Pour les tâches Azure Automation de longue durée, il est recommandé d’utiliser un runbook Worker hybride. Les Runbook Workers hybrides ne sont pas limités par la répartition de charge équilibrée et n'imposent aucune limitation en termes de durée d'exécution des runbooks. Les autres limites du travail s’appliquent à la fois aux bacs à sable Azure et aux Runbooks Workers hybrides. Les Runbooks Workers hybrides ne sont pas concernés par la limite de trois heures de la répartition de charge équilibrée. Développez malgré tout des runbooks qui s’exécutent sur les Workers prenant en charge les redémarrages après des problèmes inattendus au niveau de l’infrastructure locale.

Une autre option consiste à optimiser un runbook en utilisant des runbooks enfants. Par exemple, il peut arriver que votre runbook exécute la même fonction en boucle sur plusieurs ressources, comme une opération de base de données sur diverses bases de données. Vous pouvez déplacer cette fonction dans un runbook enfant et faire en sorte que votre runbook l’appelle à l’aide de Start-AzAutomationRunbook. Les runbooks enfants s’exécutent en parallèle dans des processus distincts.

L’utilisation de runbooks enfants diminue le délai d’exécution total du runbook parent. Votre runbook peut utiliser la cmdlet Get-AzAutomationJob pour vérifier l’état de la tâche d’un runbook enfant s’il lui reste des opérations après que l’enfant a terminé.

Étapes suivantes