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

  • Articolo

Importante

  • Il ruolo di lavoro per runbook ibrido utente basato su agente di Automazione di Azure (Windows e Linux) verrà ritirato il 31 agosto 2024 e non sarà supportato dopo tale data. Prima del 31 agosto 2024 sarà necessario completare la migrazione dei ruoli di lavoro ibridi per runbook ibridi utente basati su agenti. Inoltre, a partire dal 1° novembre 2023, la creazione di nuovi ruoli di lavoro ibridi basati su agente non sarebbe possibile. Altre informazioni.
  • L'account RunAs di Automazione di Azure verrà ritirato il 30 settembre 2023 e verrà sostituito con Identità gestite. Prima di tale data, sarà necessario avviare la migrazione dei runbook per usare le identità gestite. Per altre informazioni, vedere Migrazione da un account RunAs esistente all'identità gestita per avviare la migrazione dei runbook dall'account RunAs alle identità gestite prima del 30 settembre 2023.

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 da runbook 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 effettuato 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 diverso dai processi eseguiti in 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 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. Passare a Pannello di controllo> System>Advanced System Impostazioni.
  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 la disconnessione 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 Variabile come percorso del file eseguibile di 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 Python 3.10 in un ruolo di lavoro ibrido di Windows, installare Python nel ruolo di lavoro ibrido. Vedere Installazione di Python in Windows.

Al termine dell'installazione di Python 3.10, creare una variabile di ambiente con Nome variabile come valore python_3_10_path e 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 Python 3.8 in un ruolo di lavoro ibrido di Windows, installare Python nel ruolo di lavoro ibrido. Vedere Installazione di Python in Windows. Creare una variabiledi 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 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 Python 2.7 in un ruolo di lavoro ibrido di Windows, installare Python nel ruolo di lavoro ibrido. Vedere Installazione di Python in Windows. Creare una variabiledi ambiente PYTHON_2_PATH per i runbook Python 2.7 e assicurarsi di aggiungere il percorso del file Python eseguibile come valore variabile. Riavviare il ruolo di lavoro ibrido per runbook dopo la creazione 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, Python 3.8 sono supportati sia nei ruoli di lavoro ibridi basati su estensione che su agenti. 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/environment.
  2. Creare una nuova variabile di ambiente aggiungendo VARIABLE_NAME="variable_value" in una nuova riga in /etc/environment (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/environment 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 di 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 Variabile come percorso del file di PowerShell eseguibile. Riavviare il ruolo di lavoro ibrido per runbook dopo la creazione di una variabile di ambiente.

Python 3.10

Per eseguire runbook 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 Variabile come percorso del file Python eseguibile. Riavviare il ruolo di lavoro ibrido per runbook dopo la creazione corretta della variabile di ambiente.

Python 3.8

Per eseguire runbook 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 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 per l'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'account di Automazione in un ruolo di lavoro ibrido per runbook, deve essere 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 e 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 per usare il cmdlet Connessione-Az-Account con il parametro per l'autenticazione Identity alle risorse di Azure. Questa configurazione riduce la necessità di usare un account RunAs ed eseguire la gestione degli 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 una macchina virtuale VMware vSphere abilitata per Arc o 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 of how to select managed identities.

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

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

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 e 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-AzAccounte 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 del runbook con le credenziali del ruolo di lavoro ibrido

Invece di disporre del runbook di fornire 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 del ruolo di lavoro ibrido, è necessario definire un asset di credenziali che abbia 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 diverso, seguire questa 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. Selezionare 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\Azure Connessione edMachineAgent\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 su che consente di specificare il nome di un gruppo di ruoli di lavoro ibrido 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 ruolo di lavoro ibrido per runbook da un elenco a discesa.

Screenshot showing how to select the Hybrid Runbook Worker group.

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 basato su agente e Windows basato su agente.
  • I runbook Di PowerShell e Python firmati non sono supportati nei ruoli di lavoro ibridi Linux basati su estensione.

Creare un keyring e una coppia di chiavi di GPG

Nota

La combinazione di tasti Crea un gruppo di criteri di gruppo e la coppia di chiavi 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 usato nxautomation, generare la coppia di chiavi 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 modificare il proprietario in nxautomation usando 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 per includere il codice di esempio seguente nella sezione [worker-optional]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>.

È 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.loge i log del ruolo di lavoro del runbook di sistema sono disponibili in /var/opt/microsoft/omsagent/run/automationworker/worker.log.

Passaggi successivi