Exécuter des runbooks Automation sur un Runbook Worker hybride

  • Article

Important

  • Runbook Worker hybride utilisateur basé sur un agent (Windows et Linux) Azure Automation sera mis hors service le 31 août 2024 et ne sera plus pris en charge après cette date. Avant le 31 août 2024, vous devez terminer la migration des Runbooks Workers hybrides utilisateur basés sur un agent vers des workers basés sur des extensions. De plus, à partir du 1er novembre 2023, il ne sera plus possible de créer de nouveaux travailleurs hybrides basés sur des agents. Plus d’informations
  • Le Compte d’identification Azure Automation prendra fin le 30 septembre 2023 et sera remplacé par les identités managées. Avant cette date, vous devez commencer à migrer vos runbooks pour utiliser les identités managées. Pour plus d’informations, consultez Migration d’un compte d’identification existant vers une identité managée pour commencer à migrer les runbooks d’un compte d’identification vers les identités managées avant le 30 septembre 2023.

Les runbooks qui s’exécutent sur un Runbook Worker hybride gèrent généralement les ressources sur l’ordinateur local ou par rapport aux ressources de l’environnement local dans lequel le Worker est déployé. Les runbooks dans Azure Automation gèrent généralement les ressources dans le cloud Azure. Même s’ils sont utilisés différemment, les runbooks qui s’exécutent dans Azure Automation et les runbooks qui s’exécutent sur un runbook Worker hybride ont une structure identique.

Quand vous créez un runbook pour l’exécuter sur un runbook Worker hybride, vous devez le modifier et le tester sur la machine qui héberge le Worker. La machine hôte dispose de tous les modules PowerShell, ainsi que de l’accès réseau nécessaire à la gestion des ressources locales. Une fois que vous avez testé le runbook sur la machine du runbook Worker hybride, vous pouvez le charger dans l’environnement Azure Automation, où il peut être exécuté sur le Worker.

Planifier les services Azure protégés par un pare-feu

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 si l'exception de pare-feu autorisant les services Microsoft approuvés est activée, car Automation ne figure pas dans la liste des services approuvés. 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.

Planifier le comportement d’un travail de runbook

Azure Automation gère les travaux exécutés sur des Runbooks Workers hybrides différemment des travaux exécutés dans des bacs à sable cloud. Si vous avez un runbook de longue durée, assurez-vous qu’il est résilient aux possibles redémarrages. Pour obtenir des informations détaillées sur le comportement des travaux, consultez Travaux Runbook Worker hybride.

Comptes de service

Worker hybride Windows

Les travaux des Runbooks Worker hybrides sont exécutés sous le compte local Système.

Remarque

  • Les runbooks PowerShell 5.1, PowerShell 7.1 (préversion), Python 2.7 et Python 3.8 sont pris en charge sur les Runbooks hybrides Windows hybrides basés sur les extensions et les agents. Pour les Workers basés sur un agent, vérifiez que la version du Worker hybride Windows est 7.3.12960 ou ultérieure.
  • Les runbooks PowerShell 7.2 et Python 3.10 (préversion) sont pris en charge uniquement sur les Workers hybrides Windows basés sur une extension. Vérifiez que la version de l’extension Worker hybride Windows est 1.1.11 ou ultérieure.

Remarque

Pour créer une variable d’environnement dans les systèmes Windows, procédez comme suit :

  1. Accédez à Panneau de configuration>Système>Paramètres système avancés.
  2. Dans Propriétés système, sélectionnez Variables d’environnement.
  3. Dans Variables système, sélectionnez Nouvelle.
  4. Indiquez le Nom de la variable et la Valeur de la variable, puis sélectionnez OK.
  5. Redémarrez la machine virtuelle ou déconnectez-vous de l’utilisateur actuel et connectez-vous pour implémenter les modifications apportées à la variable d’environnement.

PowerShell 7.2

Pour exécuter des runbooks PowerShell 7.2 sur un Worker hybride Windows, installez PowerShell sur le Worker hybride. Voir Installation de PowerShell sur Windows.

Une fois l’installation de PowerShell 7.2 terminée, créez une variable d’environnement avec pour Nom de variable powershell_7_2_path et pour Valeur de variable l’emplacement du PowerShell exécutable. Redémarrez le Runbook Worker hybride après la création de la variable d’environnement.

PowerShell 7.1

Pour exécuter des runbooks PowerShell 7.1 sur un Worker hybride Windows, installez PowerShell sur le Worker hybride. Voir Installation de PowerShell sur Windows. Assurez-vous d’ajouter le fichier PowerShell à la variable d’environnement PATH et redémarrez le Runbook Worker hybride après l’installation.

Python 3.10

Pour exécuter des runbooks Python 3.10 sur un Worker hybride Windows, installez Python sur le Worker hybride. Voir Installation de Python sur Windows.

Une fois l’installation de Python 3.10 terminée, créez une variable d’environnement avec pour Nom de variable python_3_10_path et pour Valeur de variable l’emplacement du Python exécutable. Redémarrez le Runbook Worker hybride après la création de la variable d’environnement.

Python 3.8

Pour exécuter des runbooks Python 3.8 sur un Worker hybride Windows, installez Python sur le Worker hybride. Voir Installation de Python sur Windows. Créez une variable d’environnementPYTHON_3_PATH pour les runbooks Python 3.8 et veillez à ajouter l’emplacement du Python exécutable en tant que Valeur de variable. Redémarrez le Runbook Worker hybride après la création de la variable d’environnement.

Si le fichier exécutable Python se trouve à l’emplacement par défaut, C:\WPy64-3800\python-3.8.0.amd64\python.exe, vous n’avez pas besoin de créer la variable d’environnement.

Python 2.7

Pour exécuter des runbooks Python 2.7 sur un Worker hybride Windows, installez Python sur le Worker hybride. Voir Installation de Python sur Windows. Créez une variable d’environnementPYTHON_2_PATH pour les runbooks Python 2.7 et veillez à ajouter l’emplacement du fichier Python exécutable en tant que Valeur de variable. Redémarrez le Runbook Worker hybride après la création de la variable d’environnement.

Si le fichier exécutable Python se trouve à l’emplacement par défaut, C:\Python27\python.exe, vous n’avez pas besoin de créer la variable d’environnement.

Worker hybride Linux

Remarque

  • Les runbooks PowerShell 5.1, PowerShell 7.1 (préversion), Python 2.7, Python 3.8 sont pris en charge sur les Runbooks Workers hybrides Linux basés sur une extension et sur un agent. Pour les Workers basés sur un agent, assurez-vous que la version du Runbook Worker hybride Windows est 1.7.5.0 ou une version supérieure.
  • Les runbooks PowerShell 7.2 et Python 3.10 (préversion) sont pris en charge uniquement sur les Workers hybrides Linux basés sur une extension. Vérifiez que la version de l’extension du Worker hybride Linux est 1.1.11 ou ultérieure.

Remarque

Pour créer une variable d’environnement dans les systèmes Linux, procédez comme suit :

  1. Ouvrez /etc/environment.
  2. Créez une variable d’environnement en ajoutant VARIABLE_NAME="variable_value" dans une nouvelle ligne dans /etc/environment (« VARIABLE_NAME » est le nom de la nouvelle variable d’environnement et « variable_value » représente la valeur qui doit lui être attribuée).
  3. Redémarrez la machine virtuelle ou déconnectez-vous de l’utilisateur actuel puis connectez-vous après avoir enregistré les modifications apportées à /etc/environment pour implémenter les modifications des variables d’environnement.

PowerShell 7.2

Pour exécuter des runbooks PowerShell 7.2 sur un Worker hybride Linux, installez le fichier PowerShell sur le Worker hybride. Pour plus d’informations, consultez Installation de PowerShell sur Linux.

Une fois l’installation de PowerShell 7.2 terminée, créez une variable d’environnement avec pour Nom de variablepowershell_7_2_path et pour Valeur de variable l’emplacement du fichier PowerShell exécutable. Redémarrez le Runbook Worker hybride après la création d’une variable d’environnement.

Python 3.10

Pour exécuter des runbooks Python 3.10 sur un Worker hybride Linux, installez Python sur le Worker hybride. Pour plus d’informations, consultez Installation de Python 3.10 sur Linux.

Une fois l’installation de Python 3.10 terminée, créez une variable d’environnement avec pour Nom de variablepython_3_10_path et pour Valeur de variable l’emplacement du fichier Python exécutable. Redémarrez le Runbook Worker hybride après la création de la variable d’environnement.

Python 3.8

Pour exécuter des runbooks Python 3.8 sur un Worker hybride Linux, installez Python sur le Worker hybride. Assurez-vous d’ajouter le fichier Python exécutable à la variable d’environnement PATH et redémarrez le Runbook Worker hybride après l’installation.

Python 2.7

Pour exécuter des runbooks Python 2.7 sur un Worker hybride Linux, installez Python sur le Worker hybride. Assurez-vous d’ajouter le fichier Python exécutable à la variable d’environnement PATH et redémarrez le Runbook Worker hybride après l’installation.

Configurer des autorisations de runbook

Définissez les autorisations qui permettent à votre runbook de s’exécuter sur le Runbook Worker hybride des différentes manières suivantes :

  • Faire en sorte que le runbook fournisse sa propre authentification aux ressources locales.
  • Configurer l’authentification au moyen des identités managées pour les ressources Azure.
  • Spécifiez les informations d’identification de Worker hybride afin de fournir un contexte utilisateur pour tous les runbooks.

Utiliser l’authentification du runbook auprès des ressources locales

Si vous préparez un runbook qui fournit sa propre authentification aux ressources, utilisez les ressources Informations d’identification et Certificat dans votre runbook. Il existe plusieurs applets de commande vous permettant de spécifier des informations d’identification pour que le runbook puisse s’authentifier auprès de différentes ressources. L'exemple suivant présente une partie d'un Runbook qui redémarre un ordinateur. Il récupère des informations d’identification à partir d’une ressource d’informations d’identification, ainsi que le nom de l’ordinateur à partir d’une ressource de variable, puis il utilise ces valeurs avec l’applet de commande Restart-Computer.

$Cred = Get-AutomationPSCredential -Name "MyCredential"
$Computer = Get-AutomationVariable -Name "ComputerName"

Restart-Computer -ComputerName $Computer -Credential $Cred

Vous pouvez également utiliser une activité InlineScript. InlineScript vous permet d’exécuter des blocs de code sur un autre ordinateur avec des informations d’identification.

Authentification du runbook avec des identités managées

Les runbooks Workers hybrides sur les machines virtuelles Azure peuvent utiliser des identités managées pour s’authentifier auprès des ressources Azure. L’utilisation d’identités managées de ressources Azure au lieu de comptes d’identification offre des avantages, car vous n’avez pas besoin d’effectuer les tâches suivantes :

  • Exporter le certificat d’identification et l’importer dans le runbook Worker hybride
  • Renouveler le certificat utilisé par le compte d’identification
  • Gérer l’objet de connexion d’identification dans le code de votre runbook

Il existe deux façons d’utiliser les identités managées dans les scripts Runbook Worker hybrides.

  1. Utilisez l’identité managée affectée par le système pour le compte Automation :

    1. Configurez une identité managée affectée par le système pour le compte Automation.

    2. Accordez à cette identité les autorisations requises dans l’abonnement pour effectuer sa tâche.

    3. Mettez à jour le runbook pour utiliser l’applet de commande Connect-AzAccount avec le paramètre Identity pour l’authentification auprès des ressources Azure. Cette configuration réduit la nécessité d’utiliser un compte d’identification et d’effectuer la gestion de comptes associée.

      # 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

# Get all VM names from the subscription
Get-AzVM -DefaultProfile $AzureContext | Select Name

    Remarque

    Il n’est pas possible d’utiliser l’identité managée par l’utilisateur du compte Automation sur un Runbook Worker hybride, il doit s’agir de l’identité managée par le système du compte Automation.

  2. Pour une machine virtuelle Azure s’exécutant en tant que Runbook Worker hybride, utilisez l’identité managée de la machine virtuelle. Dans ce cas, vous pouvez utiliser l’identité managée affectée par l’utilisateur de la machine virtuelle OU l’identité managée affectée par le système de la machine virtuelle.

    Remarque

    Cela ne fonctionnera PAS dans un compte Automation qui a été configuré avec une identité managée de compte Automation. Dès que l’identité managée du compte Automation est activée, il n’est plus possible d’utiliser l’identité managée de la machine virtuelle, il est alors seulement possible d’utiliser l’identité managée affectée par le système du compte Automation, comme indiqué dans l’option 1 ci-dessus.

    Utilisez l’une des identités managées suivantes :

    1. Configurez une identité managée par le système pour la machine virtuelle.
    2. Accordez à cette identité les autorisations requises dans l’abonnement pour effectuer ses tâches.
    3. Mettez à jour le runbook pour utiliser l’applet de commande Connect-Az-Account avec le paramètre Identity pour l’authentification auprès des ressources Azure. Cette configuration réduit la nécessité d’utiliser un compte d’identification et d’effectuer la gestion de comptes associée.
        # 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

    # Get all VM names from the subscription
    Get-AzVM -DefaultProfile $AzureContext | Select Name

Un serveur avec Arc ou une machine virtuelle VMware vSphere avec Arc s’exécutant en tant que Runbook Worker hybride dispose déjà d’une identité managée système intégrée qui peut être utilisée pour l’authentification.

  1. Vous pouvez accorder à cette identité managée l’accès aux ressources de votre abonnement dans le panneau Contrôle d’accès (IAM) de la ressource en ajoutant l’attribution de rôle appropriée.

    Screenshot of how to select managed identities.

  2. Ajoutez l’identité managée Azure Arc au rôle que vous avez choisi en fonction des besoins.

    Screenshot of how to add role assignment in the Access control blade.

Remarque

Cela ne fonctionnera PAS dans un compte Automation qui a été configuré avec une identité managée de compte Automation. Dès que l’identité managée du compte Automation est activée, il n’est plus possible d’utiliser l’identité managée Arc, il est alors seulement possible d’utiliser l’identité managée affectée par le système du compte Automation, comme indiqué dans l’option 1 ci-dessus.

Remarque

Par défaut, les contextes Azure sont enregistrés pour une utilisation entre des sessions PowerShell. Il est possible que lorsqu’un runbook précédent sur le Runbook Worker hybride ait été authentifié auprès d’Azure, ce contexte persiste sur le disque dans le profil System PowerShell, conformément aux contextes Azure et aux informations d’identification de connexion | Microsoft Docs. Par exemple, un runbook avec Get-AzVM peut retourner toutes les machines virtuelles de l’abonnement sans appel à Connect-AzAccount et l’utilisateur peut accéder aux ressources Azure sans avoir à s’authentifier dans ce runbook. Vous pouvez désactiver l’enregistrement automatique de contexte dans Azure PowerShell, comme indiqué ici.

Utiliser l’authentification de runbook avec des informations d’identification de Worker hybride

Plutôt que de laisser votre runbook fournir sa propre authentification auprès des ressources locales, vous pouvez spécifier des informations d’identification de Worker hybride pour un groupe de Workers de runbooks hybrides. Pour spécifier des informations d’identification de Worker hybride, vous devez définir une ressource d’informations d’identification qui a accès aux ressources locales. Ces ressources incluent des magasins de certificats et tous les runbooks s’exécutent sous ces informations d’identification sur un runbook Worker hybride dans le groupe.

  • Le nom d’utilisateur doit utiliser l’un des formats suivants :

    • domain\username
    • nom_utilisateur@domaine
    • nom d’utilisateur (pour les comptes locaux sur l’ordinateur local)

  • Pour utiliser le runbook PowerShell Export-RunAsCertificateToHybridWorker, vous devez installer les modules Az pour Azure Automation sur l’ordinateur local.

Utiliser une ressource d’informations d’identification pour un groupe de Workers de runbooks hybrides

Par défaut, les travaux hybrides s’exécutent sous le contexte du compte Système. Toutefois, pour exécuter des travaux hybrides sous une ressource d’informations d’identification différente, vous pouvez effectuer les étapes suivantes :

  1. Créez une ressource d’information d’identification ayant accès aux ressources locales.
  2. Ouvrez le compte Automation dans le portail Azure.
  3. Sélectionnez Groupes de Workers hybrides, puis sélectionnez le groupe.
  4. Cliquez sur Paramètres.
  5. Changez la valeur des Informations d’identification de Worker hybride de Par défaut en Personnalisées.
  6. Sélectionnez les informations d’identification et cliquez sur Enregistrer.
  7. Si les autorisations suivantes ne sont pas attribuées pour les utilisateurs personnalisés, les travaux risquent d’être suspendus.
Type de ressource Autorisations du dossier
Azure VM C:\Packages\Plugins\Microsoft.Azure.Automation.HybridWorker.HybridWorkerForWindows (lire et exécuter)
Serveur avec Arc C:\ProgramData\AzureConnectedMachineAgent\Tokens (lire)
C:\Packages\Plugins\Microsoft.Azure.Automation.HybridWorker.HybridWorkerForWindows (lire et exécuter)

Remarque

Worker hybride de Linux ne prend pas en charge les informations d’identification Worker hybride.

Démarrer un runbook sur un runbook Worker hybride

Démarrer un runbook dans Azure Automation décrit différentes méthodes de démarrage d’un runbook. Le démarrage d’un runbook sur un Runbook Worker hybride utilise une option Exécuter sur qui vous permet de spécifier le nom d’un groupe de Runbooks Workers hybrides. Quand un groupe est spécifié, l’un des Workers de ce groupe récupère et exécute le runbook. Si votre runbook ne spécifie pas cette option, Azure Automation exécute le runbook comme d’habitude.

Quand vous démarrez un runbook dans le portail Azure, une option Exécuter sur vous permet de sélectionner Azure ou Worker hybride. Sélectionnez Worker hybride pour choisir le groupe de Runbooks Workers hybrides dans une liste déroulante.

Screenshot showing how to select the Hybrid Runbook Worker group.

Quand vous démarrez un runbook à l’aide de PowerShell, utilisez le paramètre RunOn avec l’applet de commande Start-AzAutomationRunbook. L’exemple suivant utilise Windows PowerShell pour démarrer un runbook nommé Test-Runbook sur un groupe de runbooks Workers hybrides nommé MyHybridGroup.

Start-AzAutomationRunbook -AutomationAccountName "MyAutomationAccount" -Name "Test-Runbook" -RunOn "MyHybridGroup"

Utiliser des runbooks signés sur un runbook Worker hybride Windows

Vous pouvez configurer un runbook Worker hybride Windows pour exécuter uniquement des runbooks signés.

Important

Une fois que vous avez configuré un Runbook Worker hybride pour exécuter uniquement des runbooks signés, les runbooks non signés ne pourront pas s’exécuter sur le Worker.

Remarque

PowerShell 7.x ne prend pas en charge les runbooks signés pour les Runbooks Worker hybrides Windows et Linux.

Créer un certificat de signature

L’exemple suivant crée un certificat auto-signé qui peut être utilisé pour signer des runbooks. Ce code crée le certificat et l’exporte afin que le runbook Worker hybride puisse l’importer ultérieurement. L’empreinte est également retournée à des fins d’utilisation ultérieure pour référencer le certificat.

# Create a self-signed certificate that can be used for code signing
$SigningCert = New-SelfSignedCertificate -CertStoreLocation cert:\LocalMachine\my `
    -Subject "CN=contoso.com" `
    -KeyAlgorithm RSA `
    -KeyLength 2048 `
    -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" `
    -KeyExportPolicy Exportable `
    -KeyUsage DigitalSignature `
    -Type CodeSigningCert

# Export the certificate so that it can be imported to the hybrid workers
Export-Certificate -Cert $SigningCert -FilePath .\hybridworkersigningcertificate.cer

# Import the certificate into the trusted root store so the certificate chain can be validated
Import-Certificate -FilePath .\hybridworkersigningcertificate.cer -CertStoreLocation Cert:\LocalMachine\Root

# Retrieve the thumbprint for later use
$SigningCert.Thumbprint

Importer un certificat et configurer des Workers pour la validation de signature

Copiez le certificat que vous avez créé sur chacun des Runbooks Worker hybride d’un groupe. Exécutez le script suivant pour importer le certificat et configurer les Workers de façon à utiliser la validation de signature sur les runbooks.

# Install the certificate into a location that will be used for validation.
New-Item -Path Cert:\LocalMachine\AutomationHybridStore
Import-Certificate -FilePath .\hybridworkersigningcertificate.cer -CertStoreLocation Cert:\LocalMachine\AutomationHybridStore

# Import the certificate into the trusted root store so the certificate chain can be validated
Import-Certificate -FilePath .\hybridworkersigningcertificate.cer -CertStoreLocation Cert:\LocalMachine\Root

# Configure the hybrid worker to use signature validation on runbooks.
Set-HybridRunbookWorkerSignatureValidation -Enable $true -TrustedCertStoreLocation "Cert:\LocalMachine\AutomationHybridStore"

Signer vos runbooks avec le certificat

Si les runbooks Workers hybrides sont configurés pour utiliser uniquement des runbooks signés, vous devez signer les runbooks qui doivent être utilisés par les runbooks Workers hybrides. Utilisez l’exemple de code PowerShell suivant pour signer ces runbooks.

$SigningCert = ( Get-ChildItem -Path cert:\LocalMachine\My\<CertificateThumbprint>)
Set-AuthenticodeSignature .\TestRunbook.ps1 -Certificate $SigningCert

Quand un runbook a été signé, vous devez l’importer dans votre compte Automation et le publier avec le bloc de signature. Pour savoir comment importer des runbooks, consultez Importer un runbook.

Remarque

Utilisez uniquement des caractères de texte brut dans votre code de runbook, y compris les commentaires. L’utilisation de caractères avec des signes diacritiques, comme á ou ñ, génère une erreur. Lorsqu’Azure Automation télécharge votre code, les caractères sont remplacés par un point d’interrogation et la signature échoue avec un message « Échec de validation du hachage de la signature ».

Utiliser des runbooks signés sur un runbook Worker hybride Linux

Pour pouvoir utiliser des runbooks signés, un runbook Worker hybride Linux doit avoir l’exécutable GPG exécutable sur la machine locale.

Important

Une fois que vous avez configuré un Runbook Worker hybride pour exécuter uniquement des runbooks signés, les runbooks non signés ne pourront pas s’exécuter sur le Worker.

Pour terminer cette configuration, procédez comme suit :

  • Créer un porte-clés et une paire de clés GPG
  • Rendre le porte-clés disponible pour le runbook Worker hybride
  • Vérifier que la validation de signature est activée
  • Signer un runbook

Remarque

  • PowerShell 7.x ne prend pas en charge les runbooks signés pour les runbooks Worker hybride Windows et Linux basés sur un agent.
  • Les runbooks PowerShell et Python signés ne sont pas pris en charge dans les workers hybrides Linux basés sur une extension.

Créer un porte-clés et une paire de clés GPG

Remarque

La création d’un porte-clés et d’une paire de clés GPG s’applique uniquement aux workers hybrides basés sur un agent.

Pour créer un porte-clés et une paire de clés GPG, utilisez le compte nxautomation du Runbook Worker hybride.

  1. Utilisez l’application sudo pour vous connecter en tant que compte nxautomation.

    sudo su - nxautomation

  2. Une fois que vous utilisez nxautomation, générez la paire de clés GPG comme racine. GPG vous guide tout au long des étapes. Vous devez fournir un nom, une adresse e-mail, un délai d’expiration et une phrase secrète. Ensuite, patientez jusqu’à ce que l’entropie soit suffisante sur la machine pour que la clé soit générée.

    sudo gpg --generate-key

  3. Étant donné que le répertoire GPG a été généré avec sudo, vous devez remplacer son propriétaire par nxautomation à l’aide de la commande suivante comme racine.

    sudo chown -R nxautomation ~/.gnupg

Rendre le porte-clés disponible pour le runbook Worker hybride

Une fois le porte-clés créé, vous devez le rendre disponible au runbook Worker hybride. Modifiez le fichier de paramètres home/nxautomation/state/worker.conf pour inclure l’exemple de code suivant sous la section de fichier [worker-optional].

gpg_public_keyring_path = /home/nxautomation/run/.gnupg/pubring.kbx

Vérifier que la validation de signature est activée

Si la validation de signature a été désactivée sur la machine, vous devez l’activer en exécutant la commande suivante comme racine. Remplacez <LogAnalyticsworkspaceId> par l’ID de votre espace de travail.

sudo python /opt/microsoft/omsconfig/modules/nxOMSAutomationWorker/DSCResources/MSFT_nxOMSAutomationWorkerResource/automationworker/scripts/require_runbook_signature.py --true <LogAnalyticsworkspaceId>

Signer un runbook

Une fois que vous avez configuré la validation de signature, utilisez la commande GPG suivante pour signer le runbook.

gpg --clear-sign <runbook name>

Le runbook signé est appelé <nom du runbook>.asc.

Vous pouvez maintenant charger le runbook signé sur Azure Automation et l’exécuter comme un runbook normal.

Logging

Pour aider à résoudre les problèmes liés à votre runbooks s’exécutant sur un Runbook Worker hybride, les journaux sont stockés localement dans l’emplacement suivant :

  • Sur Windows dans le chemin d’accès C:\ProgramData\Microsoft\System Center\Orchestrator\<version>\SMA\Sandboxes pour une journalisation détaillée du processus de runtime du travail. Les événements d’état de travail de runbook de haut niveau sont écrits dans le journal des événements Application and Services Logs\Microsoft-Automation\Operations.

  • Sur Linux, les journaux du Worker hybride de l’utilisateur se trouvent dans le chemin d’accès /home/nxautomation/run/worker.log, et les journaux du Runbook Worker système dans le chemin d’accès /var/opt/microsoft/omsagent/run/automationworker/worker.log.

Étapes suivantes