Tipi di runbook di Automazione di Azure

La funzionalità Automazione processi di Automazione di Azure supporta diversi tipi di runbook, come definito nella tabella seguente. Per altre informazioni sull'ambiente di automazione dei processi, consultare Esecuzione di runbook in Automazione di Azure.

Tipo	Descrizione
PowerShell	Runbook testuale basato sullo scripting di Windows PowerShell. Le versioni attualmente supportate sono PowerShell 7.2 (GA) e PowerShell 5.1 (GA). Poiché PowerShell 7.1 non è più supportato dal prodotto padre PowerShell, è consigliabile creare runbook in una versione supportata a lungo termine di PowerShell 7.2
Flusso di lavoro PowerShell	Runbook testuale basato sullo scripting del flusso di lavoro di Windows PowerShell.
Python	Runbook testuale basato sullo scripting Python. Le versioni attualmente supportate sono Python 3.8 (GA) e Python 3.10 (anteprima). Poiché Python 2.7 non è più supportato dal prodotto padre Python, è consigliabile creare runbook in versioni supportate a lungo termine.
Grafico	Runbook grafico basato su Windows PowerShell e creato e modificato completamente nell'editor grafico nel portale di Azure.
Grafico del flusso di lavoro di PowerShell	Runbook grafico basato su flusso di lavoro Windows PowerShell e creato e modificato completamente nell'editor grafico nel portale di Azure.

Nota

Automazione di Azure seguirà il ciclo di vita del supporto delle versioni del linguaggio PowerShell e Python in base alle sequenze temporali pubblicate rispettivamente dai prodotti padre PowerShell e Python. È consigliabile usare runbook con versioni del linguaggio supportate.

Tenere conto delle considerazioni seguenti per determinare quale tipo usare per un runbook specifico.

• Non è possibile convertire i runbook dal tipo grafico al tipo testuale e viceversa.
• Esistono limitazioni di uso dei runbook di tipi diversi come runbook figlio. Per altre informazioni, vedere Runbook figlio in Automazione di Azure.

Runbook di PowerShell

I runbook di PowerShell sono basati su Windows PowerShell. È possibile modificare direttamente il codice del runbook usando l'editor di testo del portale di Azure. È anche possibile usare un editor di testo offline e importare il runbook in Automazione di Azure.

La versione di PowerShell è determinata dalla versione del runtime specificata, ovvero versione 7.2, 7.1, 5.1 (anteprima) o 5.1.

Lo stesso ruolo di lavoro ibrido per runbook e sandbox di Azure può eseguire più runbook di PowerShell destinati a versioni di runtime diverse affiancate.

Nota

• Attualmente, la versione di runtime di PowerShell 7.2 è supportata sia per i processi cloud che ibridi in tutte le aree pubbliche, ad eccezione di India centrale, Emirati Arabi Uniti centrali, Israele centrale, Italia settentrionale e Germania settentrionale.
• Al momento dell'esecuzione del runbook, se si seleziona la versione del runtime 7.2, vengono usati i moduli di PowerShell destinati alla versione del runtime 7.2 e se si seleziona la versione del runtime 5.1, vengono usati i moduli di PowerShell destinati alla versione del runtime 5.1. Questo vale per i moduli e i runbook di PowerShell 7.1 (anteprima).

Assicurarsi di selezionare la versione del runtime corretta per i moduli.

Ad esempio: se si esegue un runbook per uno scenario di automazione di SharePoint con versione del runtime 7.1 (anteprima), importare il modulo nella versione del runtime 7.1 (anteprima); se si esegue un runbook per uno scenario di automazione di SharePoint con versione runtime 5.1, importare il modulo nella versione del runtime 5.1. In questo caso, verranno visualizzate due voci per il modulo, una per la versione del runtime 7.1 (anteprima) e un'altra per la versione 5.1.

Nota

Attualmente sono supportati PowerShell 5.1, PowerShell 7.1 (anteprima) e PowerShell 7.2.

Vantaggi

• Implementare tutta la logica complessa con il codice di PowerShell senza le altre complessità del flusso di lavoro di PowerShell.
• Avvio più rapido rispetto ai runbook del flusso di lavoro PowerShell poiché non è necessaria la compilazione prima dell'esecuzione.
• Esecuzione in Azure e nei ruoli di lavoro ibridi per runbook sia per Windows che per Linux.

Limitazioni e problemi noti

Di seguito sono riportate le limitazioni correnti e i problemi noti relativi ai runbook di PowerShell:

PowerShell 7.2

Limitazioni

Nota

Attualmente, la versione di runtime di PowerShell 7.2 è supportata sia per i processi cloud che ibridi in tutte le aree pubbliche, ad eccezione di India centrale, Emirati Arabi Uniti centrali, Israele centrale, Italia settentrionale e Germania settentrionale.

• Per la versione del runtime di PowerShell 7.2, le attività del modulo non vengono estratte per i moduli importati. Usare l'estensione Automazione di Azure per VS Code per semplificare l'esperienza di creazione di runbook.
• PowerShell 7.x non supporta i flussi di lavoro. Per altre informazioni, vedere Flusso di lavoro di PowerShell.
• PowerShell 7.x attualmente non supporta i runbook firmati.
• L'integrazione del controllo del codice sorgente non supporta PowerShell 7.2. Inoltre, i runbook di PowerShell 7.2 nel controllo del codice sorgente vengono creati nell'account di Automazione come Runtime 5.1.
• Il modulo Az 8.3.0 è installato per impostazione predefinita. L'elenco completo dei moduli dei componenti della versione del modulo Az selezionata viene visualizzato dopo la configurazione della versione Az usando il portale di Azure o l'API.
• Il modulo PowerShell 7.2 importato verrebbe convalidato durante l'esecuzione del processo. Assicurarsi che tutte le dipendenze per il modulo selezionato vengano importate anche per la corretta esecuzione del processo.
• Il runbook di Azure non supporta Start-Job con -credential.
• Azure non supporta tutti i parametri di input di PowerShell. Altre informazioni.

Problemi noti

• I runbook che dipendono da percorsi di file interni, ad esempio C:\modules, potrebbero non riuscire a causa delle modifiche apportate all'infrastruttura back-end del servizio. Modificare il codice del runbook per assicurarsi che non ci siano dipendenze da percorsi di file interni e usare Get-ChildItem per ottenere le informazioni del modulo necessarie.

• Il cmdlet Get-AzStorageAccount potrebbe non riuscire con un errore: Il comando Get-AzStorageAccount è stato trovato nel modulo Az.Storage, ma non è stato possibile caricare il modulo.

• L'esecuzione di script figlio tramite .\child-runbook.ps1 non è supportata.
  Soluzione alternativa: usare Start-AutomationRunbook (cmdlet interno) o Start-AzAutomationRunbook (da modulo Az.Automation ) per avviare un altro runbook dal runbook padre.

• Quando si usa il modulo ExchangeOnlineManagement, versione 3.0.0 o successiva, è possibile riscontrare errori. Per risolvere il problema, assicurarsi di caricare in modo esplicito i moduli PowerShellGet e PackageManagement.

• Quando si usa il cmdlet New-AzAutomationVariable all'interno di Az.Automation Module per caricare una variabile di tipo oggetto, l'operazione non funziona come previsto.

  Soluzione alternativa: convertire l'oggetto in una stringa JSON usando il cmdlet ConvertTo-Json e quindi caricare la variabile con la stringa JSON come valore. Questa soluzione alternativa garantisce una corretta gestione della variabile all'interno dell'ambiente di Automazione di Azure come stringa JSON.

  Esempio: creare un oggetto PowerShell con informazioni archiviate nelle macchine virtuali di Azure

    # Retrieve Azure virtual machines with status information for the 'northeurope' region 
    $AzVM = Get-AzVM -Status | Where-Object {$_.Location -eq "northeurope"} 
  
    $VMstopatch = @($AzVM).Id 
    # Create an Azure Automation variable (This cmdlet will not fail, but the variable may not work as intended when used in the runbook.) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $VMstopatch 
  
    # Convert the object to a JSON string 
    $jsonString = $VMstopatch | ConvertTo-Json 
  
    # Create an Azure Automation variable with a JSON string value (works effectively within the automation runbook) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $jsonString 
  

PowerShell 5.1

Limitazioni

• I runbook non possono usare l'elaborazione parallela per eseguire più azioni in parallelo.
• I runbook non possono usare i checkpoint per riprendere il runbook in caso di errore.
• È possibile includere solo PowerShell, i runbook del flusso di lavoro di PowerShell e i runbook grafici come runbook figlio mediante il cmdlet Start-AzAutomationRunbook che crea un nuovo processo.
• I runbook non possono usare l'istruzione PowerShell #Requires, che non è supportata nella sandbox di Azure o nei ruoli di lavoro ibridi per runbook e potrebbe causare l'esito negativo del processo.
• Il runbook di Azure non supporta Start-Job con -credential.
• Azure non supporta tutti i parametri di input di PowerShell. Altre informazioni.

Problemi noti

• I runbook che dipendono da percorsi di file interni, ad esempio C:\modules, potrebbero non riuscire a causa delle modifiche apportate all'infrastruttura back-end del servizio. Modificare il codice del runbook per assicurarsi che non ci siano dipendenze da percorsi di file interni e usare Get-ChildItem per ottenere le informazioni del modulo necessarie.

  Script di esempio

  
  # Get information about module "Microsoft.Graph.Authentication"
  $ModuleName = "Microsoft.Graph.Authentication"
  
  $NewPath = "C:\usr\src\PSModules\$ModuleName"
  $OldPath = "C:\Modules\User\$ModuleName"
  
  if (Test-Path -Path $NewPath -PathType Container) {
      Get-ChildItem -Path $NewPath
  } elseif (Test-Path -Path $OldPath -PathType Container) {
      Get-ChildItem -Path $OldPath
  } else {
      Write-Output "Module $ModuleName not present."
  }
  # Getting the path to the Temp folder, if needed.
  $tmp = $env:TEMP
  
  

• Il cmdlet Get-AzStorageAccount potrebbe non riuscire con un errore: Il comando Get-AzStorageAccount è stato trovato nel modulo Az.Storage, ma non è stato possibile caricare il modulo.

• I runbook di PowerShell non sono in grado di recuperare un asset di tipo variabile non crittografato con valore Null.

• I runbook di PowerShell non sono in grado di recuperare un asset di tipo variabile con *~* nel nome.

• Un'operazione Get-Process in un ciclo in un runbook di PowerShell può arrestarsi in modo anomalo dopo circa 80 iterazioni.

• Un runbook di PowerShell può avere esito negativo se tenta di scrivere una quantità elevata di dati nel flusso di output in una sola volta. È possibile risolvere questo problema in genere facendo in modo che il runbook restituisca solo le informazioni necessarie per usare oggetti di grandi dimensioni. Ad esempio, invece di usare Get-Process senza limitazioni, è possibile fare in modo che il cmdlet restituisca solo i parametri obbligatori come in Get-Process | Select ProcessName, CPU.

• Quando si usa il modulo ExchangeOnlineManagement, versione 3.0.0 o successiva, è possibile riscontrare errori. Per risolvere il problema, assicurarsi di caricare in modo esplicito i moduliPowerShellGet e PackageManagement.

• Se si importa il modulo Az.Accounts con la versione 2.12.3 o successiva, assicurarsi di importare il modulo Newtonsoft.Json v10 in modo esplicito se i runbook di PowerShell 5.1 hanno una dipendenza da questa versione del modulo. La soluzione alternativa per questo problema consiste nell'usare i runbook di PowerShell 7.2.

• Quando si usa il cmdlet New-AzAutomationVariable all'interno di Az.Automation Module per caricare una variabile di tipo oggetto, l'operazione non funziona come previsto.

  Soluzione alternativa: convertire l'oggetto in una stringa JSON usando il cmdlet ConvertTo-Json e quindi caricare la variabile con la stringa JSON come valore. Questa soluzione alternativa garantisce una corretta gestione della variabile all'interno dell'ambiente di Automazione di Azure come stringa JSON.

  Esempio: creare un oggetto PowerShell con informazioni archiviate nelle macchine virtuali di Azure

    # Retrieve Azure virtual machines with status information for the 'northeurope' region 
    $AzVM = Get-AzVM -Status | Where-Object {$_.Location -eq "northeurope"} 
  
    $VMstopatch = @($AzVM).Id 
    # Create an Azure Automation variable (This cmdlet will not fail, but the variable may not work as intended when used in the runbook.) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $VMstopatch 
  
    # Convert the object to a JSON string 
    $jsonString = $VMstopatch | ConvertTo-Json 
  
    # Create an Azure Automation variable with a JSON string value (works effectively within the automation runbook) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $jsonString 
  

PowerShell 7.1

Limitazioni

• PowerShell 7.1 non è più supportato dal prodotto padre PowerShell. È consigliabile creare nuovi runbook in PowerShell 7.2 per un supporto a lungo termine e aggiornare i runbook obsoleti.
• I cmdlet di PowerShell interni di Automazione di Azure non sono supportati in un ruolo di lavoro ibrido per runbook Linux. È necessario importare il modulo automationassets all'inizio del runbook di PowerShell per accedere alle funzioni delle risorse condivise dell'account di Automazione (asset).
• Per la versione del runtime di PowerShell 7, le attività del modulo non vengono estratte per i moduli importati.
• Il tipo di parametro runbook PSCredential non è supportato nella versione di runtime di PowerShell 7.
• PowerShell 7.x non supporta i flussi di lavoro. Per altre informazioni, vedere Flusso di lavoro PowerShell per altri dettagli.
• PowerShell 7.x attualmente non supporta i runbook firmati.
• L'integrazione del controllo del codice sorgente non supporta PowerShell 7.1 (anteprima). Inoltre, i runbook di PowerShell 7.1 (anteprima) nel controllo del codice sorgente vengono creati nell'account di Automazione come Runtime 5.1.
• La gestione del modulo di PowerShell 7.1 non è supportata tramite i cmdlet Get-AzAutomationModule.
• Se il valore di input contiene il carattere ', il runbook ha esito negativo e non viene creata alcuna traccia del log.
• Il runbook di Azure non supporta Start-Job con -credential.
• Azure non supporta tutti i parametri di input di PowerShell. Altre informazioni.

Problemi noti

• I runbook che dipendono da percorsi di file interni, ad esempio C:\modules, potrebbero non riuscire a causa delle modifiche apportate all'infrastruttura back-end del servizio. Modificare il codice del runbook per assicurarsi che non ci siano dipendenze da percorsi di file interni e usare Get-ChildItem per ottenere le informazioni del modulo necessarie.

  Script di esempio

  
  # Get information about module "Microsoft.Graph.Authentication"
  $ModuleName = "Microsoft.Graph.Authentication"
  
  $NewPath = "C:\usr\src\PSModules\$ModuleName"
  $OldPath = "C:\Modules\User\$ModuleName"
  
  if (Test-Path -Path $NewPath -PathType Container) {
      Get-ChildItem -Path $NewPath
  } elseif (Test-Path -Path $OldPath -PathType Container) {
      Get-ChildItem -Path $OldPath
  } else {
      Write-Output "Module $ModuleName not present."
  }
  # Getting the path to the Temp folder, if needed.
  $tmp = $env:TEMP
  
  

• Il cmdlet Get-AzStorageAccount potrebbe non riuscire con un errore: Il comando Get-AzStorageAccount è stato trovato nel modulo Az.Storage, ma non è stato possibile caricare il modulo.

• L'esecuzione di script figlio con .\child-runbook.ps1 non è supportata in questa anteprima. Soluzione alternativa: usare Start-AutomationRunbook (cmdlet interno) o Start-AzAutomationRunbook (dal modulo Az.Automation) per avviare un altro runbook dal runbook padre.

• Le proprietà del runbook che definiscono le preferenze di registrazione non sono supportate nel runtime di PowerShell 7. Soluzione alternativa: impostare in modo esplicito la preferenza all'inizio del runbook come indicato sotto:

      $VerbosePreference = "Continue"
  
      $ProgressPreference = "Continue"
  

• Evitare di importare il modulo Az.Accounts nella versione 2.4.0 per il runtime di PowerShell 7 perché può verificarsi un comportamento imprevisto usando questa versione in Automazione di Azure.

• È possibile che si verifichino problemi di formattazione con i flussi di output degli errori per un processo in esecuzione nel runtime di PowerShell 7.

• Quando si importa un modulo di PowerShell 7.1 dipendente da altri moduli, è possibile che il pulsante di importazione sia disattivato, anche quando viene installata la versione di PowerShell 7.1 del modulo dipendente. Ad esempio, per il modulo Az PowerShell, la versione del calcolo 4.20.0 ha una dipendenza da Az.Accounts > = 2.6.0. Questo problema si verifica quando un modulo dipendente equivalente in PowerShell 5.1 non soddisfa i requisiti della versione. Ad esempio, la versione 5.1 di Az.Accounts era < 2.6.0.

• Quando si avvia il runbook di PowerShell 7 usando il webhook, converte automaticamente il parametro di input del webhook in un codice JSON non valido.

• È consigliabile usare il modulo ExchangeOnlineManagement versione 3.0.0 o precedente perché la versione 3.0.0 o successiva può causare errori di processo.

• Se si importa il modulo Az.Accounts con la versione 2.12.3 o successiva, assicurarsi di importare il modulo Newtonsoft.Json v10 in modo esplicito se i runbook di PowerShell 7.1 hanno una dipendenza da questa versione del modulo. La soluzione alternativa per questo problema consiste nell'usare i runbook di PowerShell 7.2.

• Quando si usa il cmdlet New-AzAutomationVariable all'interno di Az.Automation Module per caricare una variabile di tipo oggetto, l'operazione non funziona come previsto.

  Soluzione alternativa: convertire l'oggetto in una stringa JSON usando il cmdlet ConvertTo-Json e quindi caricare la variabile con la stringa JSON come valore. Questa soluzione alternativa garantisce una corretta gestione della variabile all'interno dell'ambiente di Automazione di Azure come stringa JSON.

  Esempio: creare un oggetto PowerShell con informazioni archiviate nelle macchine virtuali di Azure

    # Retrieve Azure virtual machines with status information for the 'northeurope' region 
    $AzVM = Get-AzVM -Status | Where-Object {$_.Location -eq "northeurope"} 
  
    $VMstopatch = @($AzVM).Id 
    # Create an Azure Automation variable (This cmdlet will not fail, but the variable may not work as intended when used in the runbook.) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $VMstopatch 
  
    # Convert the object to a JSON string 
    $jsonString = $VMstopatch | ConvertTo-Json 
  
    # Create an Azure Automation variable with a JSON string value (works effectively within the automation runbook) 
    New-AzAutomationVariable -ResourceGroupName "mrg" -AutomationAccountName "mAutomationAccount2" -Name "complex1" -Encrypted $false -Value $jsonString 
  

Runbook del flusso di lavoro PowerShell

I runbook del flusso di lavoro PowerShell sono runbook di testo basati sul flusso di lavoro Windows PowerShell. È possibile modificare direttamente il codice del runbook usando l'editor di testo del portale di Azure. È anche possibile usare un editor di testo offline e importare il runbook in Automazione di Azure.

Nota

PowerShell 7.1 (anteprima) e PowerShell 7.2 non supportano i runbook del flusso di lavoro.

Vantaggi

• Implementazione di tutta la logica complessa con codice del flusso di lavoro PowerShell.
• Uso dei checkpoint per riprendere l'operazione in caso di errore.
• Uso dell'elaborazione parallela per eseguire più azioni in parallelo.
• Può includere altri runbook grafici e runbook di flusso di lavoro di PowerShell come runbook figli per creare flussi di lavoro di livello elevato.

Limiti

• Il flusso di lavoro di PowerShell non è supportato nelle versioni di PowerShell 7 e successive. Di conseguenza, i runbook obsoleti non possono essere aggiornati.
• Gestione inefficiente dell'esecuzione parallela rispetto alle versioni più recenti di PowerShell 7+.
• Il flusso di lavoro di PowerShell funziona internamente usando più processi. Di conseguenza, i moduli disponibili in un processo potrebbero non essere disponibili in un altro processo e causare eccezioni come comando non trovato.
• Gestione nei runbook della complessità aggiuntiva del flusso di lavoro PowerShell, ad esempio gli oggetti deserializzati.
• Tempi di avvio maggiori rispetto ai runbook di PowerShell perché è necessaria la compilazione prima dell'esecuzione.
• È possibile includere solo runbook di PowerShell come runbook figlio usando il cmdlet Start-AzAutomationRunbook.
• I runbook non possono essere eseguiti in un ruolo di lavoro ibrido per runbook Linux.

Runbook Python

I runbook Python vengono compilati in Python 2.7(GA), Python 3.8 (GA) e Python 3.10 (anteprima). È possibile modificare direttamente il codice del runbook usando l'editor di testo del portale di Azure. È anche possibile usare un editor di testo offline e importare il runbook in Automazione di Azure.

Attualmente, la versione del runtime di Python 3.10 (anteprima) è supportata sia per i processi cloud che ibridi in tutte le aree pubbliche, ad eccezione di Australia centrale 2, Corea meridionale, Svezia meridionale, JIO India centrale, Brasile sud-orientale, India centrale, India occidentale, Emirati Arabi Uniti centrali e cloud per enti pubblici.

Vantaggi

Nota

L'importazione di un pacchetto Python può richiedere qualche minuto.

• Usa le librerie Python affidabili.
• Può essere eseguito in Azure o in ruoli di lavoro ibridi per runbook.
• Per Python 2.7, i ruoli di lavoro ibridi per runbook windows sono supportati con Python 2.7 installato.
• Per i processi cloud Python 3.8, è supportata la versione di Python 3.8. Gli script e i pacchetti di qualsiasi versione 3.x potrebbero funzionare se il codice è compatibile tra versioni diverse.
• Per i processi ibridi Python 3.8 in computer Windows, è possibile scegliere di installare qualsiasi versione 3.x che si vuole usare.
• Per i processi ibridi Python 3.8 in computer Linux, si dipende dalla versione di Python 3 installata nel computer per eseguire DSC OMSConfig e il ruolo di lavoro ibrido Linux. Versioni diverse dovrebbero funzionare se non sono presenti modifiche di rilievo nelle firme dei metodi o nei contratti tra le versioni di Python 3.

Limiti

Di seguito sono riportate le limitazioni dei runbook Python

Python 3.10 (anteprima)

• Per i moduli Python 3.10 (anteprima), attualmente sono supportati solo i file wheel destinati al sistema operativo Linux cp310. Ulteriori informazioni
• L'integrazione del controllo del codice sorgente non è supportata.
• I pacchetti personalizzati per Python 3.10 (anteprima) vengono convalidati solo durante il runtime del processo. Il processo dovrebbe non riuscire se il pacchetto non è compatibile nel runtime o se le dipendenze necessarie dei pacchetti non vengono importate nell'account di automazione.
• Attualmente, i runbook Python 3.10 (anteprima) sono supportati solo dal portale di Azure. L'API REST e PowerShell non sono supportati.

Python 3.8 (GA)

• Conoscenza delle nozioni di scripting di Python.
• L'integrazione del controllo del codice sorgente non è supportata.
• Per i moduli Python 3.8, usare i file wheel destinati a cp38-amd64.
• Per poter usare librerie di terze parti, è necessario importare il pacchetto nell'account di Automazione.
• L'uso di cmdlet Start-AutomationRunbook in PowerShell/flusso di lavoro di PowerShell per avviare un runbook Python 3.8 non funziona. È possibile usare il cmdlet Start-AzAutomationRunbook dal modulo Az.Automation o Start-AzureRmAutomationRunbook dal modulo AzureRm.Automation per ovviare a questa limitazione. 
• Automazione di Azure non supporta sys.stderr.
• Il pacchetto Python automationassets non è disponibile in pypi.org, quindi non è disponibile per l'importazione in un computer Windows.

Python 2.7

• Python 2.7 non è più supportato dal prodotto padre Python. È consigliabile creare nuovi runbook nelle versioni supportate e aggiornare i runbook obsoleti.
• Conoscenza delle nozioni di scripting di Python.
• Per i moduli Python 2.7.12, usare i file wheel cp27-amd6.
• Per poter usare librerie di terze parti, è necessario importare il pacchetto nell'account di Automazione.
• Automazione di Azure non supporta sys.stderr.
• Il pacchetto Python automationassets non è disponibile in pypi.org, quindi non è disponibile per l'importazione in un computer Windows.

Più versioni di Python

È applicabile per i ruoli di lavoro ibridi di Windows. Per un ruolo di lavoro runbook di Windows, quando si esegue un runbook Python 2, questo cerca prima la variabile di ambiente PYTHON_2_PATH e verifica se punta a un file eseguibile valido. Ad esempio, se la cartella di installazione è C:\Python2, verifica se C:\Python2\python.exe è un percorso valido. Se non viene trovato, cerca la variabile di ambiente PATH per eseguire un controllo simile.

Per Python 3, cerca prima la variabile di PYTHON_3_PATH env e quindi esegue il fallback alla variabile di ambiente PATH.

Quando si usa una sola versione di Python, è possibile aggiungere il percorso di installazione alla variabile PATH. Se si vogliono usare entrambe le versioni nel ruolo di lavoro runbook, impostare PYTHON_2_PATH e PYTHON_3_PATH sul percorso del modulo per tali versioni.

Problemi noti

Per i processi cloud, i processi Python 3.8 talvolta hanno esito negativo con un messaggio di eccezione invalid interpreter executable path. È possibile che venga visualizzata questa eccezione se il processo viene ritardato, a partire da più di 10 minuti o se si usa Start-AutomationRunbook per avviare runbook Python 3.8. Se il processo è ritardato, il riavvio del runbook dovrebbe essere sufficiente.

Runbook grafici

È possibile creare e modificare runbook grafici e runbook del flusso di lavoro PowerShell grafico usando l'editor grafico nel portale di Azure. Tuttavia, non è possibile creare o modificare questo tipo di runbook con un altro strumento. Funzionalità principali dei runbook grafici:

• Sono esportati in file nell'account di Automazione e quindi importati in un altro account di Automazione.
• Generano codice di PowerShell.
• Sono convertiti in runbook grafici del flusso di lavoro di PowerShell durante l'importazione.

Vantaggi

• Uso di un modello di creazione con inserimento, collegamento e configurazione visivi.
• Possibilità di analizzare il flusso dei dati attraverso il processo.
• Rappresentazione grafica dei processi di gestione.
• Inclusione di altri runbook come runbook figlio per creare flussi di lavoro di livello elevato.
• Agevolazione della programmazione modulare.

Limiti

• Non è possibile creare o modificare all'esterno del portale di Azure.
• Potrebbe richiedere un'attività di codice contenente il codice di PowerShell per eseguire una logica complessa.
• Non è possibile eseguire la conversione in uno dei formati di testo, né convertire un runbook di testo in formato grafico.
• Non è possibile visualizzare o modificare direttamente il codice di PowerShell creato dal flusso di lavoro grafico. È possibile visualizzare il codice creato in qualsiasi attività di codice.
• Non è possibile eseguire runbook in un ruolo di lavoro ibrido per runbook Linux. Consultare Automatizzare le risorse nel centro dati o nel cloud usando i ruoli di lavoro ibridi per runbook.
• I runbook grafici non possono essere firmati digitalmente.

Passaggi successivi

• Per informazioni sui runbook di PowerShell, vedere Esercitazione: Creare un runbook di PowerShell.
• Per informazioni sui runbook del flusso di lavoro PowerShell, vedere Esercitazione: Creare un runbook del flusso di lavoro PowerShell.
• Per informazioni sui runbook grafici, vedere Esercitazione: Creare un runbook grafico.
• Per informazioni sui runbook Python, vedere Esercitazione: Creare un runbook Python.