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 nella 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 dai prodotti padreRispettivamente 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 runtime specificata (ovvero la versione 7.2, 7.1 (anteprima) o 5.1.

Lo stesso ambiente sandbox di Azure e il ruolo di lavoro ibrido per runbook possono 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 dei cloud India centrale, Emirati Arabi Uniti centrali, Israele centrale, Italia settentrionale, Germania settentrionale e gov.
• Al momento dell'esecuzione del runbook, se si seleziona Versione di runtime come versione 7.2, vengono usati i moduli di PowerShell destinati alla versione di runtime 7.2 e se si seleziona Versione di runtime come versione 5.1, vengono usati i moduli di PowerShell destinati alla versione di runtime 5.1. Questo vale per i moduli e i runbook di PowerShell 7.1 (anteprima).

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

Ad esempio: se si esegue un runbook per uno scenario di automazione di SharePoint in Runtime versione7.1 (anteprima), importare il modulo in Runtime versione7.1 (anteprima). Se si esegue un runbook per uno scenario di automazione di SharePoint nella versione 5.1 del runtime, importare il modulo in Runtimeversione5.1. In questo caso, verranno visualizzate due voci per il modulo, una per runtime versione7.1(anteprima) e l'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 dei cloud India centrale, Emirati Arabi Uniti centrali, Israele centrale, Italia settentrionale, Germania settentrionale e gov.

• Per la versione di runtime di PowerShell 7.2, le attività del modulo non vengono estratte per i moduli importati. Usare Automazione di Azure'estensione per Visual Studio 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 per altri dettagli.
• 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 componente della versione del modulo Az selezionata viene visualizzato dopo la configurazione della versione az usando portale di Azure o 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 l'esecuzione corretta del processo.
• Il runbook di Azure non supporta Start-Job .-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 C:\modules esempio potrebbero non riuscire a causa di modifiche nell'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.

• Get-AzStorageAccount Il cmdlet potrebbe non riuscire con un errore: il Get-AzStorageAccount comando è 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 (dal modulo Az.Automation ) per avviare un altro runbook dal runbook padre.

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

• Quando si usa il cmdlet all'interno di New-AzAutomationVariable 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 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 runbook powerShell, flussi di lavoro PowerShell e runbook grafici come runbook figlio usando il cmdlet Start-AzAutomationRunbook , che crea un nuovo processo.
• I runbook non possono usare l'istruzione powerShell #Requires , 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 .-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 C:\modules esempio potrebbero non riuscire a causa di modifiche nell'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
  
  

• Get-AzStorageAccount Il cmdlet potrebbe non riuscire con un errore: il Get-AzStorageAccount comando è 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 la versione del modulo ExchangeOnlineManagement : 3.0.0 o versione successiva, è possibile che si verifichino errori. Per risolvere il problema, assicurarsi di caricare in modo esplicito anche i moduli PowerShellGet 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 all'interno di New-AzAutomationVariable 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 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 del 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 di PowerShell per altri dettagli.
• PowerShell 7.x attualmente non supporta i runbook firmati.
• L'integrazione del controllo del codice sorgente non supporta Anche PowerShell 7.1 (anteprima), 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.
• Il runbook non riesce senza traccia del log se il valore di input contiene il carattere '.
• Il runbook di Azure non supporta Start-Job .-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 C:\modules esempio potrebbero non riuscire a causa di modifiche nell'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
  
  

• Get-AzStorageAccount Il cmdlet potrebbe non riuscire con un errore: il Get-AzStorageAccount comando è 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 Az.Automation modulo) 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 di seguito:

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

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

• Potrebbero verificarsi problemi di formattazione con i flussi di output degli errori per il 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 grigio anche quando è installata la versione di PowerShell 7.1 del modulo dipendente. Ad esempio, il modulo Az PowerShell. La versione di 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 la versione del modulo ExchangeOnlineManagement : 3.0.0 o versione 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 all'interno di New-AzAutomationVariable 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 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 versioni 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 e causare eccezioni come il 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 di runtime di Python 3.10 (anteprima) è supportata sia per i processi cloud che ibridi in tutte le aree pubbliche, ad eccezione di Australia centrale2, Corea meridionale, Svezia meridionale, Jio India centrale, Brasile meridionale, India centrale, India occidentale, emirati arabi uniti centrali e cloud gov.

Vantaggi

Nota

L'importazione di un pacchetto Python può richiedere alcuni minuti.

• 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 nei 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. Le 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 da 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 del cmdlet Start-AutomationRunbook nel flusso di lavoro di PowerShell/PowerShell per avviare un runbook Python 3.8 non funziona. È possibile usare il cmdlet Start-AzAutomationRunbook dal modulo Az.Automation o dal cmdlet Start-AzureRmAutomationRunbook dal modulo AzureRm.Automation per ovviare a questa limitazione. 
• Automazione di Azure non supporta sys.stderr.
• Il pacchetto automationassets Python 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 automationassets Python 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 cerca prima la variabile PYTHON_2_PATH di ambiente e verifica se punta a un file eseguibile valido. Ad esempio, se la cartella di installazione è C:\Python2, verificare se C:\Python2\python.exe è un percorso valido. Se non viene trovato, cerca la PATH variabile di ambiente per eseguire un controllo simile.

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

Quando si usa una sola versione di Python, è possibile aggiungere il percorso di installazione alla PATH variabile. 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 invalid interpreter executable pathdi eccezione . È 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 i runbook Python 3.8. Se il processo è ritardato, riavviare il runbook deve 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:

• Esportato in file nell'account di Automazione e quindi importato in un altro account di Automazione.
• Generano codice di PowerShell.
• Convertito in o da runbook grafici del flusso di lavoro 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.