Condividi tramite

Esecuzione di runbook in Automazione di Azure

L'automazione dei processi in Automazione di Azure consente di creare e gestire PowerShell, flusso di lavoro PowerShell e runbook grafici. Per informazioni dettagliate, vedere Automazione di Azure runbook.

Automazione esegue i runbook in base alla logica definita al loro interno. Se un runbook viene interrotto, si riavvia dall'inizio. Questo comportamento richiede la scrittura di runbook che supportano il riavvio in caso di problemi temporanei.

L'avvio di un runbook in Automazione di Azure crea un processo, ovvero una singola istanza di esecuzione del runbook. Ogni processo accede alle risorse Azure effettuando una connessione alla sottoscrizione di Azure. Il processo può accedere solo alle risorse del data center dell'utente se tali risorse sono accessibili dal cloud pubblico.

Automazione di Azure assegna un ruolo di lavoro per eseguire ogni processo durante l'esecuzione del runbook. I computer di lavoro sono condivisi da molti account di automazione, mentre i processi di account di automazione diversi sono isolati l'uno dall'altro. Non è possibile controllare quali servizi del ruolo di lavoro vengono richiesti dal processo.

Quando si visualizza l'elenco dei runbook nel portale di Azure, viene visualizzato lo stato di ogni processo avviato per ogni runbook. Automazione di Azure archivia i log dei processi per un massimo di 30 giorni.

Il diagramma seguente mostra il ciclo di vita di un processo del runbook per i runbook di PowerShell, i runbook del flusso di lavoro di PowerShell e i runbook grafici.

Stati del processo - Flusso di lavoro PowerShell

Note

Per informazioni sulla visualizzazione o l'eliminazione dei dati personali, vedere General Data Subject Requests for the GDPR, Azure Data Subject Requests for the GDPR, or Windows Data Subject Requests for the GDPR, a seconda delle specifiche aree e esigenze. Per altre informazioni sul GDPR, vedere la sezione GDPR del Centro protezione Microsoft e la sezione GDPR del portale di attendibilità dei servizi.

Ambiente di esecuzione dei runbook

I runbooks in Automazione di Azure possono essere eseguiti in una sandbox di Azure o su un lavoratore ibrido dei runbooks.

Quando i runbook sono progettati per l'autenticazione e l'esecuzione su risorse in Azure, vengono eseguiti in una sandbox Azure. Automazione di Azure assegna una risorsa per eseguire ogni attività durante l'esecuzione del runbook nella sandbox. I computer di lavoro sono condivisi da molti account di automazione, mentre i processi di account di automazione diversi sono isolati l'uno dall'altro. I processi che usano la stessa sandbox sono vincolati dalle limitazioni di risorse della sandbox. L'ambiente sandbox Azure non supporta le operazioni interattive.

È anche possibile usare un ruolo di lavoro ibrido per runbook per eseguire i runbook direttamente nel computer che ospita il ruolo e nelle risorse locali dell'ambiente. Automazione di Azure archivia e gestisce i runbook e li distribuisce a uno o più computer assegnati.

L'abilitazione del Firewall di Azure in Archiviazione di Azure, Azure Key Vault o Azure SQL blocca l'accesso dai runbook Automazione di Azure per tali servizi. L'accesso verrà bloccato anche quando l'eccezione del firewall per consentire servizi Microsoft attendibili è abilitata, perché Automazione non fa parte dell'elenco di 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.

La tabella seguente elenca alcune attività di esecuzione del runbook insieme al relativo ambiente di esecuzione per ognuna di esse.

Attività Recommendation Note
Eseguire l'integrazione con le risorse di Azure Azure Sandbox Ospitata in Azure, l'autenticazione è più semplice. Se si utilizza un Hybrid Runbook Worker su una VM di Azure, è possibile utilizzare l'autenticazione del runbook con identità gestite.
Ottenere prestazioni ottimali per gestire le risorse Azure Azure Sandbox Lo script viene eseguito nello stesso ambiente, che ha una latenza inferiore.
Ridurre al minimo i costi operativi Azure Sandbox Non c'è alcun overhead di calcolo e non è necessaria una macchina virtuale.
Eseguire uno script con esecuzione prolungata ruolo di lavoro ibrido per runbook Azure sandbox hanno limiti risorse.
Interagire con i servizi locali ruolo di lavoro ibrido per runbook Accedere direttamente al computer host oppure alle risorse in altri ambienti cloud o nell'ambiente locale.
Richiedere software ed eseguibili di terze parti ruolo di lavoro ibrido per runbook L'utente gestisce il sistema operativo e può installare i software.
Monitorare un file o una cartella con un runbook ruolo di lavoro ibrido per runbook Usare un'attività watcher in un ruolo di lavoro ibrido per runbook.
Eseguire uno script con uso intensivo delle risorse ruolo di lavoro ibrido per runbook Azure sandbox hanno limiti risorse.
Usare moduli con requisiti specifici ruolo di lavoro ibrido per runbook Alcuni esempi sono:
WinSCP - dipendenza da winscp.exe
Amministrazione IIS - dipendenza dall'abilitazione o dalla gestione di IIS
Installare un modulo con un programma di installazione ruolo di lavoro ibrido per runbook I moduli per la sandbox devono supportare la copia.
Usare runbook o moduli che richiedono la versione di .NET Framework diversa dalla versione 4.7.2 ruolo di lavoro ibrido per runbook Azure sandbox supportano .NET Framework 4.7.2 e l'aggiornamento a una versione diversa non è supportato.
Eseguire script che richiedono l'elevazione dei privilegi ruolo di lavoro ibrido per runbook Le sandbox non consentono l'elevazione dei privilegi. Con un ruolo di lavoro ibrido per runbook è possibile disattivare il Controllo dell'account utente e usare Invoke-Command quando si esegue il comando che richiede l'elevazione dei privilegi.

Archiviazione temporanea in una sandbox

Se è necessario creare file temporanei come parte della logica del runbook, è possibile usare la cartella Temp (ovvero $env:TEMP) nella sandbox Azure per i runbook in esecuzione in Azure. L'unica limitazione è che non è possibile usare più di 1 GB di spazio su disco, ovvero la quota per ogni sandbox. Quando si usano flussi di lavoro di PowerShell, questo scenario può causare un problema perché tali flussi usano checkpoint e lo script potrebbe essere ritentato in una sandbox diversa.

Con la sandbox ibrida è possibile usare C:\temp in base alla disponibilità dell'archiviazione in un ruolo di lavoro ibrido per runbook. Tuttavia, secondo le raccomandazioni di Azure sulle macchine virtuali, non è consigliabile usare il disco temporaneo su Windows o Linux per i dati che devono essere salvati in modo permanente.

Risorse

I runbook devono includere la logica per gestire le risorse, ad esempio, le macchine virtuali, la rete e le risorse sulla rete. Le risorse sono associate a una sottoscrizione Azure e i runbook richiedono credenziali appropriate per accedere a qualsiasi risorsa. Per un esempio di gestione delle risorse in un runbook, vedere Gestire risorse.

Security

Automazione di Azure usa il Microsoft Defender per il cloud per garantire la sicurezza per le risorse e rilevare la compromissione nei sistemi Linux. La sicurezza viene fornita tra i carichi di lavoro, indipendentemente dal fatto che le risorse si trovino in Azure o meno. Vedere Introduzione all'autenticazione in Automazione di Azure.

Defender per il cloud pone vincoli agli utenti che possono eseguire script, firmati o non firmati, in una macchina virtuale. Se si ha accesso alla radice di una macchina virtuale, è necessario configurare in modo esplicito la macchina con una firma digitale oppure disattivarla. Altrimenti, è possibile eseguire solo uno script per applicare gli aggiornamenti del sistema operativo dopo aver creato un account di Automazione e aver abilitato la funzionalità appropriata.

Sottoscrizioni

Un Azure subscription è un contratto con Microsoft per l'uso di uno o più servizi basati sul cloud per cui vengono addebitati i costi. È possibile gestire più sottoscrizioni dallo stesso account di Automazione se le credenziali in uso hanno accesso a più sottoscrizioni.

Credenziali

Un runbook richiede le credenziali appropriate per accedere a qualsiasi risorsa, sia per Azure che per sistemi di terze parti. Queste credenziali vengono archiviate in Automazione di Azure, Key Vault e così via.

Monitoraggio di Azure

Automazione di Azure può usare Monitoraggio di Azure per il monitoraggio delle operazioni del computer.

Autorizzazioni per i runbook

Un runbook necessita delle autorizzazioni per l'autenticazione per Azure, tramite le credenziali. Consulta la panoramica sull'autenticazione di Automazione di Azure.

Moduli

Automazione di Azure include i moduli di PowerShell seguenti:

  • Orchestrator.AssetManagement.Cmdlets: contiene diversi cmdlet interni disponibili solo quando si eseguono runbook nell'ambiente sandbox Azure o su un Runbook Worker ibrido di Windows. Questi cmdlet sono progettati per essere usati invece di Azure PowerShell cmdlet per interagire con le risorse dell'account di Automazione.
  • Az.Automation: modulo PowerShell consigliato per l'interazione con Automazione di Azure che sostituisce il modulo automazione AzureRM. Il modulo Az.Automation non viene incluso automaticamente quando si crea un account di Automazione ed è necessario importarli manualmente.
  • AzureRM.Automation: installato per impostazione predefinita quando si crea un account di Automazione.

Sono supportati anche moduli installabili, basati sui cmdlet richiesti dai runbook e dalle configurazioni DSC. Per informazioni dettagliate sui moduli disponibili per i runbook e le configurazioni DSC, vedere Gestisci moduli in Automazione di Azure.

Certificati

Automazione di Azure usa certificates per l'autenticazione per Azure o aggiungerli a risorse di Azure o di terze parti. I certificati vengono archiviati in modo sicuro per consentirne l'accesso ai runbook e alle configurazioni DSC.

I runbook possono utilizzare certificati autofirmati, che non sono firmati da un'autorità di certificazione (CA). Vedere Creare un nuovo certificato.

Processi

Automazione di Azure supporta un ambiente per l'esecuzione di processi dallo stesso account di Automazione. In un singolo runbook possono venire eseguiti molti processi contemporaneamente. Quanti più processi vengono eseguiti contemporaneamente, tanto più spesso questi possono essere inviati allo stesso ambiente sandbox. Un massimo di 10 processi può essere eseguito in una sandbox. Una sandbox verrà rimossa quando non vengono eseguiti processi; di conseguenza, non deve essere usata per salvare i file.

I processi in esecuzione nello stesso processo sandbox possono influire l'uno sull'altro. Un esempio è dato dal cmdlet Disconnect-AzAccount. L'esecuzione di questo cmdlet disconnette ogni processo runbook nel processo sandbox condiviso. Per un esempio di utilizzo di questo scenario, vedere Evitare i processi simultanei.

Note

I processi di PowerShell avviati da un runbook eseguito in una sandbox Azure potrebbero non essere eseguiti nella modalità del linguaggio PowerShell.

Stati dei processi

La tabella seguente descrive gli stati possibili per un processo. È possibile visualizzare un riepilogo dello stato per tutti i processi del runbook o esaminare i dettagli di un processo del runbook specifico nel portale di Azure. Puoi anche configurare l'integrazione con l'area di lavoro Log Analytics per trasmettere lo stato dell'attività del runbook e i flussi di lavoro. Per altre informazioni sull'integrazione con i log di Monitoraggio di Azure, vedere Forward job status and job streams from Automation to Monitoraggio di Azure logs. Per un esempio di utilizzo degli stati in un runbook, vedere anche Ottenere gli stati del processo.

Stato Descrizione
In fase di attivazione Il processo viene attivato.
Completi Il processo è stato completato.
Operazione non riuscita La compilazione di un runbook grafico o di un runbook del flusso di lavoro di PowerShell non è riuscita. Non è stato possibile avviare il runbook di PowerShell oppure il processo conteneva un'eccezione. Per vedere i tipi di runbook di Automazione di Azure.
Non riuscito, in attesa di risorse Il processo non è riuscito perché ha raggiunto il limite di condivisione equa tre volte iniziando ogni volta dallo stesso checkpoint o dall'inizio del runbook.
Queued Il processo è in attesa che le risorse diventino disponibili in un ruolo di lavoro di Automazione per poter essere avviato.
Resuming Il sistema sta riprendendo il processo dopo che è stato sospeso.
In esecuzione Il processo è in esecuzione.
In esecuzione, in attesa di risorse Il processo è stato scaricato perché ha raggiunto il limite di condivisione equa. Riprenderà a breve dall'ultimo checkpoint.
Avvio in corso Il processo è stato assegnato a un computer di lavoro e il sistema lo sta avviando.
Arrestato Il processo è stato arrestato dall'utente prima del completamento.
Stopping Il sistema sta arrestando il processo.
Sospeso Si applica solo ai runbook grafici e ai runbook del flusso di lavoro di PowerShell. Il processo è stato sospeso dall'utente, dal sistema o da un comando del runbook. Se un runbook non ha un checkpoint, viene avviato dall'inizio. Se ha un checkpoint, può essere nuovamente avviato e riprendere dall'ultimo checkpoint. Il runbook viene sospeso dal sistema solo quando si verifica un'eccezione. Per impostazione predefinita, la variabile ErrorActionPreference è impostata su Continua, a indicare che il processo continua a essere eseguito in caso di errore. Se la variabile di preferenza è impostata su Interrompi, il processo viene sospeso in caso di errore.
Suspending Si applica solo ai runbook grafici e ai runbook del flusso di lavoro di PowerShell. Il sistema sta provando a sospendere il processo su richiesta dell'utente. Il runbook deve raggiungere il checkpoint successivo prima di poter essere sospeso. Se ha già superato l'ultimo checkpoint, viene completato prima di poter essere sospeso.
Nuovo Il lavoro è stato inviato di recente, ma non è ancora stato attivato.

Note

In caso di errore dell'infrastruttura, il processo viene ritentato internamente per un massimo di 3 volte.

Registrazione dell'attività

L'esecuzione di runbook in Automazione di Azure scrive i dettagli in un log delle attività per l'account di Automation. Per informazioni dettagliate sull'uso del log, vedere Recuperare i dettagli dal log attività.

Eccezioni

Questa sezione descrive alcuni modi per gestire le eccezioni o i problemi intermittenti nei runbook. Un esempio è l'eccezione WebSocket. La corretta gestione delle eccezioni impedisce che gli errori di rete temporanei causino un errore del runbook.

ErrorActionPreference

La variabile ErrorActionPreference determina il modo in cui PowerShell risponde a un errore non fatale. Gli errori di terminazione terminano sempre e non sono interessati da ErrorActionPreference.

Quando il runbook usa ErrorActionPreference, un errore che normalmente non è fatale, ad esempio PathNotFound del cmdlet Get-ChildItem impedisce il completamento del runbook. L'esempio seguente mostra l'uso di ErrorActionPreference. Il comando Write-Output finale non viene mai eseguito, perché lo script si interrompe.

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

Try Catch Finally

Try Catch Finally viene usato negli script di PowerShell per gestire gli errori fatali. Lo script può usare questo meccanismo per intercettare eccezioni specifiche o eccezioni generali. L'istruzione catch deve essere usata per tenere traccia o tentare di gestire gli errori. L'esempio seguente tenta di scaricare un file che non esiste. Rileva l'eccezione System.Net.WebException e restituisce l'ultimo valore per un'altra eccezione.

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 può essere usato per generare un errore fatale. Questo meccanismo può essere utile quando si definisce la logica personalizzata in un runbook. Se lo script soddisfa un criterio che dovrebbe arrestarlo, può usare l'istruzione throw per eseguire l'interruzione. L'esempio seguente usa questa istruzione per mostrare un parametro di funzione obbligatorio.

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

Errors

Il runbook deve gestire gli errori. Automazione di Azure supporta due tipi di errori di PowerShell, terminazione e non terminazione.

Quando si verificano, gli errori fatali interrompono l'esecuzione del runbook. Il runbook si interrompe e lo stato del processo è Non riuscito.

Gli errori non fatali consentono allo script di continuare anche dopo che questi si sono verificati. Un esempio di errore non fatale è quello che si verifica quando il runbook usa il cmdlet Get-ChildItem con un percorso che non esiste. PowerShell rileva che il percorso non esiste, genera un errore e passa alla cartella successiva. In questo caso, l'errore non imposta lo stato del processo del runbook su Non riuscito e il processo potrebbe anche essere completato. Per forzare l'arresto di un runbook in caso di errore non fatale, è possibile usare ErrorAction Stop nel cmdlet.

Processi di chiamata

I runbook eseguiti in Azure sandbox non supportano processi chiamanti, ad esempio file eseguibili (.exe) o sottoprocessi. Il motivo è che un Azure sandbox è un processo condiviso eseguito in un contenitore che potrebbe non essere in grado di accedere a tutte le API sottostanti. Per gli scenari che richiedono software di terze parti o chiamate ai sottoprocessi, è consigliabile eseguire un runbook in un ruolo di lavoro ibrido per runbook.

Caratteristiche dell'applicazione e del dispositivo

I processi del runbook in Azure sandbox non possono accedere ad alcuna caratteristica del dispositivo o dell'applicazione. L'API più comune usata per eseguire query sulle metriche delle prestazioni in Windows è WMI, con alcune delle metriche più comuni che usano la memoria e l'utilizzo della CPU.

Webhook

I servizi esterni, ad esempio, Azure DevOps Services e GitHub, possono lanciare un runbook nell'ambito di Automazione di Azure. Per eseguire questo tipo di avvio, il servizio usa un webhook tramite una sola richiesta HTTP. L'uso di un webhook consente l'avvio dei runbook senza l'implementazione di una funzionalità di Automazione di Azure completa.

Risorse condivise

Per condividere le risorse tra tutti i runbook nel cloud, Azure usa un concetto denominato condivisione equa. Usando la condivisione equa, Azure scarica temporaneamente o arresta qualsiasi processo eseguito per più di tre ore. I processi per i runbook PowerShell e i runbook Python vengono arrestati e non riavviati, e lo stato del processo diventa Arrestato.

Per le attività di Automazione di Azure a esecuzione prolungata, è consigliabile usare un Hybrid Runbook Worker. I ruoli di lavoro ibridi per runbook non sono limitati da condivisione equa e non hanno una limitazione rispetto alla possibile durata dell'esecuzione di un runbook. L'altro processo limiti si applica sia alle sandbox Azure che agli Hybrid Runbook Worker. Anche se i ruoli di lavoro ibridi per runbook non sono soggetti al limite di tre ore della condivisione equa, i runbook devono essere sviluppati per essere eseguiti nei ruoli di lavoro che supportano il riavvio causato da problemi imprevisti dell'infrastruttura locale.

Un'altra opzione consiste nell'ottimizzare il runbook usando un runbook figlio. Ad esempio, il runbook potrebbe eseguire il ciclo della stessa funzione su diverse risorse, ad esempio, con un'operazione di database su diversi database. È possibile spostare questa funzione in un runbook figlio e fare in modo che il runbook lo chiami usando Start-AzAutomationRunbook. I runbook figlio vengono eseguiti in parallelo in processi separati.

L'uso di runbook figlio riduce la quantità totale di tempo per il completamento del runbook padre. Il runbook può usare il cmdlet Get-AzAutomationJob per verificare lo stato del processo di un runbook figlio se dispone di altre operazioni dopo il completamento del runbook figlio.

Passaggi successivi

  • Last updated on