Condividi tramite


Eseguire runbook di Automazione di Azure in un ruolo di lavoro ibrido per runbook

Importante

Il Ruolo di lavoro ibrido per runbook utente basato su agente di Automazione di Azure (Windows e Linux) è stato ritirato il 31 agosto 2024 e non è più supportato. Seguire le linee guida su come effettuare la migrazione da un ruoli di lavoro ibrido per i runbook basati su agente a ruoli di lavoro ibrido basati su estensione.

Nota

L'account RunAs di Automazione di Azure è stato ritirato il 30 settembre 2023 e viene sostituito con identità gestite. Seguire le linee guida su come avviare la migrazione dei runbook per usare le identità gestite. Per altre informazioni, vedere Eseguire la migrazione da un account RunAs esistente a Identità gestita.

I runbook eseguiti in un ruolo di lavoro ibrido per runbook in genere gestiscono risorse nel computer locale o in base a risorse nell'ambiente locale in cui il ruolo di lavoro è stato distribuito. I runbook usati in Automazione di Azure gestiscono in genere le risorse nel cloud di Azure. Anche se vengono usati in modo diverso, i runbook eseguiti in Automazione di Azure e quelli eseguiti in un ruolo di lavoro ibrido per runbook hanno la stessa struttura.

Quando si crea un runbook da eseguire in un ruolo di lavoro ibrido per runbook, è consigliabile modificarlo e testarlo all'interno del computer che ospita il ruolo di lavoro. Il computer host ha tutti i moduli di PowerShell e i diritti di accesso di rete necessari per gestire le risorse locali. Dopo aver testato il runbook nel computer con il ruolo di lavoro ibrido per runbook, è possibile caricarlo nell'ambiente di Automazione di Azure, dove può essere eseguito nel ruolo di lavoro.

Pianificare i servizi di Azure protetti da firewall

L'abilitazione del Firewall di Azure in Archiviazione di Azure, Azure Key Vault o Azure SQL blocca l'accesso dai runbook di Automazione di Azure per tali servizi. L'accesso verrà bloccato anche quando l'eccezione del firewall per consentire i servizi Microsoft attendibili è abilitata, perché Automazione non fa parte dell'elenco dei servizi attendibili. Con un firewall abilitato, l'accesso può essere ottenuto solo usando un ruolo di lavoro ibrido per runbook e un endpoint servizio di rete virtuale.

Pianificare il comportamento dei processi dei runbook

Automazione di Azure gestisce i processi nei ruoli di lavoro ibridi per runbook in modo differente rispetto ai processi eseguiti all'interno degli ambienti sandbox cloud. Se si ha un runbook a esecuzione prolungata, assicurarsi che sia resiliente a un eventuale riavvio. Per informazioni dettagliate sul comportamento dei processi, vedere Processi di ruoli di lavoro ibridi per runbook.

Account di servizio

Ruolo di lavoro ibrido di Windows

I processi per i ruoli di lavoro ibridi per runbook vengono eseguiti con l'account di sistema locale.

Nota

  • I runbook PowerShell 5.1, PowerShell 7.1(anteprima), Python 2.7 e Python 3.8 sono supportati sia nei ruoli di lavoro ibridi basati su estensione che su agenti. Per i ruoli di lavoro basati su agenti, verificare che la versione del Ruolo di lavoro ibrido di Windows sia 7.3.12960 o successiva.
  • I runbook di PowerShell 7.2 e Python 3.10 (anteprima) sono supportati solo nei Ruoli di lavoro ibridi di Windows basati su estensioni. Verificare che la versione dell'estensione del Ruolo di lavoro ibrido di Windows sia 1.1.11 o successiva.

Nota

Per creare una variabile di ambiente nei sistemi Windows, seguire questa procedura:

  1. Andare a Pannello di controllo>Sistema>Impostazioni di sistema avanzate.
  2. In Proprietà di sistema selezionare Variabili di ambiente.
  3. In Variabili di sistema selezionare Nuovo.
  4. Specificare Nome variabile e Valore variabile, quindi selezionare OK.
  5. Riavviare la macchina virtuale o disconnettersi dall'utente corrente e accedere per implementare le modifiche delle variabili di ambiente.

PowerShell 7.2

Per eseguire runbook di PowerShell 7.2 in un Ruolo di lavoro ibrido di Windows, installare PowerShell nel Ruolo di lavoro ibrido. Vedere Installazione di PowerShell in Windows.

Al termine dell'installazione di PowerShell 7.2, creare una variabile di ambiente con Nome variabile come valore powershell_7_2_path e Valore variabile come percorso del file eseguibile PowerShell. Riavviare il ruolo di lavoro ibrido per runbook dopo la creazione corretta della variabile di ambiente.

PowerShell 7.1

Per eseguire runbook di PowerShell 7.1 in un Ruolo di lavoro ibrido di Windows, installare PowerShell nel Ruolo di lavoro ibrido. Vedere Installazione di PowerShell in Windows. Assicurarsi di aggiungere il file di PowerShell alla variabile di ambiente PATH e riavviare il ruolo di lavoro ibrido per runbook dopo l'installazione.

Python 3.10

Per eseguire runbook di Python 3.10 in un Ruolo di lavoro ibrido di Windows, installare Python nel Ruolo di lavoro ibrido. Vedere Installazione di Python in macOS.

Al termine dell'installazione di Python 3.10, creare una variabile di ambiente con Nome variabile come valore python_3_10_path e Valore variabile come percorso del file eseguibile Python. Riavviare il ruolo di lavoro ibrido per runbook dopo la creazione corretta della variabile di ambiente.

Python 3.8

Per eseguire runbook di Python 3.8 in un Ruolo di lavoro ibrido di Windows, installare Python nel Ruolo di lavoro ibrido. Vedere Installazione di Python in macOS. Creare una variabile di ambiente PYTHON_3_PATH per i runbook Python 3.8 e assicurarsi di aggiungere il percorso del file eseguibile Python come Valore variabile. Riavviare il ruolo di lavoro ibrido per runbook dopo la creazione corretta della variabile di ambiente.

Se il file eseguibile Python si trova nel percorso predefinito C:\WPy64-3800\python-3.8.0.amd64\python.exe, non è necessario creare la variabile di ambiente.

Python 2.7

Per eseguire runbook di Python 2.7 in un Ruolo di lavoro ibrido di Windows, installare Python nel Ruolo di lavoro ibrido. Vedere Installazione di Python in macOS. Creare una variabile di ambiente PYTHON_2_PATH per i runbook Python 2.7 e assicurarsi di aggiungere il percorso del file eseguibile Python come Valore variabile. Riavviare il ruolo di lavoro ibrido per runbook dopo la creazione corretta della variabile di ambiente.

Se il file eseguibile Python si trova nel percorso predefinito C:\Python27\python.exe, non è necessario creare la variabile di ambiente.

Ruolo di lavoro ibrido Linux

Nota

  • I runbook PowerShell 5.1, PowerShell 7.1(anteprima), Python 2.7 e Python 3.8 sono supportati sia nei ruoli di lavoro ibridi Linuz basati sia estensione che su agente. Per i ruoli di lavoro basati su agente, verificare che la versione del ruolo di lavoro ibrido per runbook Linux sia 1.7.5.0 o successiva.
  • I runbook PowerShell 7.2 e Python 3.10 (anteprima) sono supportati solo nei ruoli di lavoro ibridi Linux basati su estensione. Verificare che la versione dell'estensione del ruolo di lavoro ibrido Linux sia 1.1.11 o successiva.

Nota

Per creare una variabile di ambiente nei sistemi Linux, seguire questa procedura:

  1. Aprire /etc/ambiente.
  2. Creare una nuova variabile di ambiente aggiungendo VARIABLE_NAME="variable_value" in una nuova riga in /etc/ambiente (VARIABLE_NAME è il nome della nuova variabile di ambiente e variable_value rappresenta il valore da assegnare).
  3. Riavviare la macchina virtuale o la disconnessione dall'utente corrente e accedere dopo aver salvato le modifiche in /etc/ambiente per implementare le modifiche delle variabili di ambiente.

PowerShell 7.2

Per eseguire runbook di PowerShell 7.2 in un ruolo di lavoro ibrido Linux, installare il file PowerShell nel ruolo di lavoro ibrido. Per altre informazioni, vedere Installazione di PowerShell in Linux.

Al termine dell'installazione di PowerShell 7.2, creare una variabile di ambiente con Nome variabile come valore powershell_7_2_path e Valore variabile come percorso del file eseguibile PowerShell. Riavviare il ruolo di lavoro ibrido per runbook dopo la creazione corretta di una variabile di ambiente.

Python 3.10

Per eseguire runbook di Python 3.10 in un ruolo di lavoro ibrido Linux, installare Python nel ruolo di lavoro ibrido. Per altre informazioni, vedere Installazione di Python 3.10 in Linux.

Al termine dell'installazione di Python 3.10, creare una variabile di ambiente con Nome variabile come valore python_3_10_path e Valore variabile come percorso del file eseguibile Python. Riavviare il ruolo di lavoro ibrido per runbook dopo la creazione corretta della variabile di ambiente.

Python 3.8

Per eseguire runbook di Python 3.8 in un ruolo di lavoro ibrido Linux, installare Python nel ruolo di lavoro ibrido. Assicurarsi di aggiungere il file Python eseguibile alla variabile di ambiente PATH e riavviare il ruolo di lavoro ibrido per runbook dopo l'installazione.

Python 2.7

Per eseguire runbook di Python 2.7 in un ruolo di lavoro ibrido Linux, installare Python nel ruolo di lavoro ibrido. Assicurarsi di aggiungere il file Python eseguibile alla variabile di ambiente PATH e riavviare il ruolo di lavoro ibrido per runbook dopo l'installazione.

Configurare le autorizzazioni del runbook

Definire le autorizzazioni per l'esecuzione dei runbook nel ruolo di lavoro ibrido per runbook nei modi seguenti:

  • Fare in modo che il runbook fornisca i propri dati di autenticazione alle risorse locali.
  • Configurare l'autenticazione usando identità gestite per le risorse di Azure.
  • Specificare le credenziali del ruolo di lavoro ibrido per fornire un contesto utente per tutti i runbook.

Usare l'autenticazione dei runbook alle risorse locali

Se si intende predisporre un runbook che fornisca alle risorse i propri dati di autenticazione, usare asset di tipo credenziale e certificato all'interno del runbook. Sono disponibili diversi cmdlet che consentono di specificare credenziali in modo che il runbook possa eseguire l'autenticazione a risorse diverse. L'esempio seguente illustra una parte di un runbook che riavvia un computer. Recupera le credenziali da un asset credenziali e il nome del computer da un asset variabile e quindi usa questi valori con il cmdlet Restart-Computer.

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

Restart-Computer -ComputerName $Computer -Credential $Cred

È anche possibile usare un'attività InlineScript. InlineScript consente di eseguire blocchi di codice in un altro computer con credenziali.

Usare l'autenticazione dei runbook con identità gestite

I ruoli di lavoro ibridi per runbook all'interno di macchine virtuali di Azure possono usare identità gestite per l'autenticazione alle risorse di Azure. L'uso delle identità gestite anziché degli account RunAs per le risorse di Azure è vantaggioso perché non è necessario:

  • Esportare il certificato RunAs e quindi importarlo nel ruolo di lavoro ibrido per runbook.
  • Rinnovare il certificato usato dall'account RunAs.
  • Gestire l'oggetto connessione RunAs nel codice del runbook.

Esistono due modi per usare le identità gestite negli script del ruolo di lavoro ibrido per runbook.

  1. Usare l'identità gestita assegnata dal sistema per l'account di Automazione:

    1. Configurare un'identità gestita assegnata dal sistema con un account di Automazione.

    2. Concedere a questa identità le autorizzazioni necessarie all'interno della sottoscrizione per eseguire l'attività.

    3. Aggiornare il runbook in modo che usi il cmdlet Connect-AzAccount con il parametro Identity per eseguire l'autenticazione alle risorse di Azure. Questa configurazione riduce la necessità di usare un account RunAs e di eseguire la gestione dell'account associata.

      # 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
      

    Nota

    Non è possibile usare l'identità gestita dell'utente dell'account di automazione in un ruolo di lavoro ibrido per runbook, si deve usare l'identità gestita del sistema dell'account di automazione.

  2. Per una macchina virtuale di Azure in esecuzione come ruolo di lavoro ibrido per runbook, usare l'identità gestita della macchina virtuale. In questo caso, è possibile usare l'identità gestita assegnata dall'utente della macchina virtuale OPPURE l'identità gestita assegnata dal sistema della macchina virtuale.

    Nota

    NON funzionerà in un account di Automazione configurato con un'identità gestita dell'account di Automazione. Non appena l'identità gestita dell'account di Automazione è abilitata, non è più possibile usare l'identità gestita della macchina virtuale quindi è possibile usare solo l'identità gestita assegnata dal sistema dell'account di Automazione, come indicato nell'opzione 1 precedente.

    Usare una delle identità gestite seguenti:

    1. Configurare un'identità gestita dal sistema per la macchina virtuale.
    2. Concedere a questa identità le autorizzazioni necessarie all'interno della sottoscrizione per eseguire le attività.
    3. Aggiornare il runbook in modo che usi il cmdlet Connect-Az-Account con il parametro Identity per eseguire l'autenticazione alle risorse di Azure. Questa configurazione riduce la necessità di usare un account RunAs e di eseguire la gestione dell'account associata.
        # 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
    

A un server abilitato per Arc o a una macchina virtuale VMware vSphere abilitata per Arc in esecuzione come ruolo di lavoro ibrido per runbook è già stata assegnata un'identità gestita di sistema predefinita che può essere usata per l'autenticazione.

  1. È possibile concedere a questa identità gestita l'accesso alle risorse nella sottoscrizione nel pannello Controllo di accesso (IAM) per la risorsa aggiungendo l'assegnazione di ruolo appropriata.

    Screenshot sulla modalità di selezione delle identità gestite.

  2. Aggiungere l'identità gestita di Azure Arc al ruolo scelto in base alle esigenze.

    Screenshot di come aggiungere un'assegnazione di ruolo nel pannello Controllo di accesso.

Nota

NON funzionerà in un account di Automazione configurato con un'identità gestita dell'account di Automazione. Non appena l'identità gestita dell'account di Automazione è abilitata, non è più possibile usare l'identità gestita ARC quindi è possibile usare solo l'identità gestita assegnata dal sistema dell'account di Automazione, come indicato nell'opzione 1 precedente.

Nota

Per impostazione predefinita, i contesti di Azure vengono salvati per l'uso tra sessioni di PowerShell. È possibile che quando un runbook precedente nel ruolo di lavoro ibrido per runbook è stato autenticato con Azure, tale contesto viene mantenuto sul disco nel profilo di PowerShell di sistema, in base ai contesti di Azure e alle credenziali di accesso | Microsoft Docs. Ad esempio, un runbook con Get-AzVM può restituire tutte le macchine virtuali nella sottoscrizione senza alcuna chiamata a Connect-AzAccount e l'utente sarà in grado di accedere alle risorse di Azure senza dover eseguire l'autenticazione all'interno di tale runbook. È possibile disabilitare il salvataggio automatico del contesto in Azure PowerShell, come descritto qui.

Usare l'autenticazione dei runbook con le credenziali di ruolo di lavoro ibrido per runbook

Prerequisito

  • Il ruolo di lavoro ibrido deve essere distribuito e il computer deve essere in esecuzione prima di eseguire un runbook.

Credenziali del ruolo di lavoro ibrido Anziché avere il runbook fornisce la propria autenticazione alle risorse locali, è possibile specificare le credenziali del ruolo di lavoro ibrido per un gruppo di ruoli di lavoro ibrido per runbook. Per specificare le credenziali di un Ruolo di lavoro ibrido, è necessario definire un asset di credenziali con accesso alle risorse locali. Queste risorse includono gli archivi certificati e tutti i runbook eseguiti con queste credenziali in un ruolo di lavoro ibrido per runbook nel gruppo.

  • Il nome utente per le credenziali deve essere in uno dei formati seguenti:

    • dominio\nome utente
    • username@domain
    • nome utente (per gli account locali nel computer locale)
  • Per usare il runbook di PowerShell Export-RunAsCertificateToHybridWorker, è necessario installare i moduli Az per Automazione di Azure nel computer locale.

Usare un asset di credenziali per un gruppo di ruoli di lavoro ibridi per runbook

Per impostazione predefinita, i processi ibridi vengono eseguiti nel contesto dell'account di sistema. Tuttavia, per eseguire processi ibridi in un asset di credenziali differente, attenersi alla seguente procedura:

  1. Creare un asset credenziali con accesso alle risorse locali.
  2. Nel portale di Azure, aprire l'account di Automazione.
  3. Selezionare Gruppi di ruoli di lavoro ibridi e quindi selezionare il gruppo specifico.
  4. Seleziona Impostazioni.
  5. Modificare il valore di Credenziali del ruolo di lavoro ibrido da Predefinito a Personalizzato.
  6. Selezionare le credenziali e fare clic su Salva.
  7. Se le autorizzazioni seguenti non vengono assegnate agli utenti personalizzati, i processi potrebbero essere sospesi.
Tipo di risorsa Autorizzazioni per le cartelle
Macchina virtuale di Azure C:\Packages\Plugins\Microsoft.Azure.Automation.HybridWorker.HybridWorkerForWindows (lettura ed esecuzione)
Server abilitato per Arc C:\ProgramData\AzureConnectedMachineAgent\Tokens (lettura)
C:\Packages\Plugins\Microsoft.Azure.Automation.HybridWorker.HybridWorkerForWindows (lettura ed esecuzione)

Nota

Il ruolo di lavoro ibrido di Linux non supporta le credenziali del ruolo di lavoro ibrido.

Avviare un runbook in un ruolo di lavoro ibrido per runbook

Avviare un runbook in Automazione di Azure descrive metodi diversi per l'avvio di un runbook. L'avvio di un runbook in un ruolo di lavoro ibrido per runbook usa un'opzione Esegui in che consente di specificare il nome di un gruppo di ruoli di lavoro ibridi per runbook. Quando si specifica un gruppo, uno dei ruoli di lavoro di questo recupera ed esegue il runbook. Se il runbook non specifica questa opzione, Automazione di Azure lo esegue come di consueto.

Quando si avvia un runbook nel portale di Azure, viene visualizzata l'opzione Esegui in, per la quale è possibile selezionare Azure o Ruolo di lavoro ibrido. Selezionare Ruolo di lavoro ibrido per scegliere il gruppo di ruoli di lavoro ibridi per runbook da un elenco a discesa.

Screenshot che mostra come selezionare il gruppo ruolo di lavoro ibrido per runbook.

Quando si avvia un runbook con PowerShell, usare il parametro RunOn con il cmdlet Start-AzAutomationRunbook. L'esempio seguente usa Windows PowerShell per avviare un runbook denominato Test-Runbook in un gruppo di ruoli di lavoro ibridi per runbook denominato MyHybridGroup.

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

Usare runbook firmati in un ruolo di lavoro ibrido per runbook di Windows

È possibile configurare un ruolo di lavoro ibrido per runbook di Windows per eseguire solo runbook firmato.

Importante

Dopo aver configurato un ruolo di lavoro ibrido per runbook per l'esecuzione solo di runbook firmati, l'esecuzione di runbook non firmati nel ruolo di lavoro non riesce.

Nota

PowerShell 7.x non supporta i runbook firmati per il ruolo di lavoro ibrido per runbook di Windows e Linux.

Creare il certificato di firma

L'esempio seguente crea un certificato autofirmato che può essere usato per la firma dei runbook. Questo codice crea il certificato e lo esporta in modo che il ruolo di lavoro ibrido per runbook possa importarlo in seguito. Viene restituita anche l'identificazione personale perché possa essere usata in seguito quando si fa riferimento al certificato.

# 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

Importare il certificato e configurare i ruoli di lavoro per la convalida della firma

Copiare il certificato creato in ogni ruolo di lavoro ibrido per runbook in un gruppo. Eseguire lo script seguente per importare il certificato e configurare i ruolo di lavoro per l'uso della convalida della firma per i runbook.

# 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"

Firmare i runbook usando il certificato

Con i ruoli di lavoro ibridi per runbook configurati per l'uso solo di runbook firmati, è necessario firmare i runbook da usare con il ruolo di lavoro ibrido per runbook. Usare l'esempio di PowerShell seguente per firmare i runbook.

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

Dopo che un runbook è stato firmato, deve essere importato nell'account di Automazione e pubblicato con il blocco della firma. Per informazioni su come importare runbook, vedere Importare un runbook.

Nota

Usare solo caratteri di testo non crittografato nel codice del runbook, inclusi i commenti. L'uso di caratteri con segni diacritici, ad esempio á o ñ, genererà un errore. Quando Automazione di Azure scarica il codice, i caratteri verranno sostituiti da un punto interrogativo e la firma avrà esito negativo con un messaggio di "errore di convalida dell'hash della firma".

Usare runbook firmati in un ruolo di lavoro ibrido per runbook di Linux

Per poter usare runbook firmati, un ruolo di lavoro ibrido per Runbook di Linux deve avere l'eseguibile GPG nel computer locale.

Importante

Dopo aver configurato un ruolo di lavoro ibrido per runbook per l'esecuzione solo di runbook firmati, l'esecuzione di runbook non firmati nel ruolo di lavoro non riesce.

Per completare questa configurazione, seguire questa procedura:

  • Creare un keyring e una coppia di chiavi di GPG
  • Rendere disponibile il keyring per il ruolo di lavoro ibrido per runbook
  • Verificare che la convalida della firma sia abilitata
  • Firmare un runbook

Nota

  • PowerShell 7.x non supporta runbook firmati per il Ruolo di lavoro ibrido per runbook ibrido Windows basato su agente e Linux basato su agente.
  • I runbook di PowerShell e Python cui si ha eseguito l'accesso non sono supportati nei ruoli di lavoro ibridi Linux basati su estensione.

Creare un keyring e una coppia di chiavi di GPG

Nota

Crea un keyring GPG e keypair sono applicabili solo per i ruoli di lavoro ibridi basati su agenti.

Per creare il keyring e la coppia di chiavi di GPG, usare l'account nxautomation del ruolo di lavoro ibrido per runbook.

  1. Usare l'applicazione sudo per accedere con l'account nxautomation.

    sudo su - nxautomation
    
  2. Dopo aver iniziato a usare nxautomation, generare la coppia di chiavi di GPG come radice. GPG consente di usare una procedura dettagliata. È necessario specificare il nome, l'indirizzo di posta elettronica, l'ora di scadenza e la passphrase. Attendere quindi che nel computer sia presente entropia sufficiente per la generazione della chiave.

    sudo gpg --generate-key
    
  3. Poiché la directory GPG è stata generata con sudo, è necessario cambiare il proprietario in nxautomation tramite il comando seguente come radice.

    sudo chown -R nxautomation ~/.gnupg
    

Rendere disponibile il keyring per il ruolo di lavoro ibrido per runbook

Dopo aver creato il keyring, renderlo disponibile per il ruolo di lavoro ibrido per runbook. Modificare il file di impostazioni home/nxautomation/state/worker.conf in modo da includere il codice di esempio seguente nella sezione [worker-optional] del file.

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

Verificare che la convalida della firma sia abilitata

Se la convalida della firma è stata disabilitata nel computer, è necessario attivarla eseguendo il comando seguente come radice. Sostituire <LogAnalyticsworkspaceId> con l'ID della propria area di lavoro.

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

Firmare un runbook

Dopo aver configurato la convalida della firma, usare il comando GPG seguente per firmare il runbook.

gpg --clear-sign <runbook name>

Il runbook firmato è denominato <runbook name.asc>.asc.

È ora possibile caricare il runbook firmato in Automazione di Azure ed eseguito come un runbook normale.

Registrazione

Per risolvere i problemi relativi ai runbook in esecuzione in un ruolo di lavoro ibrido per runbook, i log vengono archiviati localmente nel percorso seguente:

  • In Windows in C:\ProgramData\Microsoft\System Center\Orchestrator\<version>\SMA\Sandboxes per la registrazione dettagliata del processo di runtime. Gli eventi di stato del processo runbook di alto livello vengono scritti nel registro eventi Registri applicazioni e servizi\Microsoft-Automation\Operations.

  • In Linux i log dei ruoli di lavoro ibridi dell'utente sono disponibili in /home/nxautomation/run/worker.log e i log del ruolo di lavoro del runbook di sistema sono disponibili in /var/opt/microsoft/omsagent/run/automationworker/worker.log.

Passaggi successivi