Tipos de runbook da Automação do Azure

O recurso de Automação de Processo da Automação do Azure dá suporte a vários tipos de runbooks, conforme definido na tabela a seguir. Para saber mais sobre o ambiente de automação de processo, veja Execução de runbook na Automação do Azure.

Tipo	Descrição
PowerShell	Runbook de texto baseado no script do Windows PowerShell. As versões com suporte no momento são: PowerShell 7.2 (disponibilidade geral) e PowerShell 5.1 (disponibilidade geral). Como o PowerShell 7.1 não é mais compatível com o produto pai PowerShell, recomendamos que você crie runbooks na versão com suporte de longo prazo do PowerShell 7.2
Fluxo de Trabalho do PowerShell	Runbook de texto baseado no script do fluxo de trabalho do Windows PowerShell.
Python	Runbook de texto baseado no script do Python. As versões com suporte no momento são: Python 3.8 (disponibilidade geral) e Python 3.10 (versão prévia). Como o Python 2.7 não é mais compatível com o produto pai Python, recomendamos que você crie runbooks em versões com suporte de longo prazo.
Gráfico	Runbook gráfico baseado no Windows PowerShell e criado e editado totalmente no editor gráfico do portal do Azure.
Fluxo de Trabalho Gráfico do PowerShell	Runbook gráfico baseado no Fluxo de Trabalho do Windows PowerShell e criado e editado totalmente no editor gráfico do portal do Azure.

Observação

A Automação do Azure seguirá o ciclo de vida de suporte das versões de linguagem do PowerShell e do Python de acordo com as linhas do tempo publicadas pelos produtos pai PowerShell e Python, respectivamente. Recomendamos que você use runbooks com versões de linguagem com suporte.

Considere os fatores a seguir ao determinar qual tipo usar para um runbook específico.

• Não é possível converter runbooks do tipo gráfico para texto ou vice-versa.
• Existem limitações para o uso de runbooks de tipos diferentes, como runbooks filhos. Para obter mais informações, confira Runbooks filho na Automação do Azure.

Runbooks do PowerShell

Os runbooks do PowerShell se baseiam no Windows PowerShell. Você edita o código do runbook diretamente usando o editor de texto do portal do Azure. Também é possível usar qualquer editor de texto offline e importar o runbook na Automação do Azure.

A versão do PowerShell é determinada pela Versão do runtime especificada (ou seja, a v7.2, 7.1 (versão prévia) ou a 5.1).

A mesma área restrita do Azure e o Hybrid Runbook Worker podem executar vários runbooks do PowerShell direcionados a diferentes versões de runtime lado a lado.

Observação

• Atualmente, há suporte para a versão de runtime do PowerShell 7.2 para trabalhos de nuvem e híbridos em todas as regiões públicas, exceto Índia Central, EA Central, Israel Central, Norte da Itália, Norte da Alemanha e nuvens Gov.
• No momento da execução do runbook, se você selecionar a Versão do Runtime como 7.2, os módulos do PowerShell destinados à versão do runtime 7.2 serão usados e, se você selecionar a Versão do Runtime como 5.1, os módulos do PowerShell destinados à versão do runtime 5.1 serão usados. Isso se aplica a módulos e runbooks do PowerShell 7.1 (versão prévia).

Selecione a Versão do Runtime correta para os módulos.

Por exemplo: se você estiver executando um runbook em um cenário de automação do Sharepoint na Versão do runtime7.1 (versão prévia), importe o módulo na Versão do runtime7.1 (versão prévia). Se você estiver executando um runbook em um cenário de automação do Sharepoint na Versão do runtime5.1, importe o módulo na Versão do runtime5.1. Nesse caso, haverá duas entradas para o módulo, uma para a Versão do runtime7.1 (versão prévia) e outra para a 5.1.

Observação

Atualmente, há suporte a PowerShell 5.1, PowerShell 7.1 (versão prévia) e PowerShell 7.2.

Vantagens

• Implemente toda a lógica complexa com o código do PowerShell sem outras complexidades do Fluxo de Trabalho do PowerShell.
• Inicia mais rápido que os runbooks de Fluxo de Trabalho do PowerShell, já que não precisa ser compilado antes da execução.
• Pode ser executado no Azure e em Hybrid Runbook Workers para Windows e Linux.

Limitações e problemas conhecidos

Abaixo estão as limitações e os problemas conhecidos atualmente com runbooks do PowerShell:

PowerShell 7.2

Limitações

Observação

Atualmente, há suporte para a versão de runtime do PowerShell 7.2 para trabalhos de nuvem e híbridos em todas as regiões públicas, exceto Índia Central, EA Central, Israel Central, Norte da Itália, Norte da Alemanha e nuvens Gov.

• Na versão de runtime 7.2 do PowerShell, as atividades do módulo não são extraídas para os módulos importados. Use a extensão de Automação do Azure para código VS para simplificar a experiência de criação de runbook.
• O PowerShell 7.x não dá suporte a fluxos de trabalho. Para obter mais informações, consulte o fluxo de trabalho do PowerShell para obter mais detalhes.
• No momento, o PowerShell 7.x não dá suporte a runbooks assinados.
• A integração do controle do código-fonte não dá suporte ao PowerShell 7.2. Além disso, os runbooks do PowerShell 7.2 no controle do código-fonte são criados na conta de Automação como Runtime 5.1.
• O módulo Az 8.3.0 é instalado por padrão. A lista completa de módulos de componente da versão do módulo Az selecionada é mostrada quando a versão do Az é configurada novamente usando o portal ou a API do Azure.
• O módulo importado do PowerShell 7.2 seria validado durante a execução do trabalho. Verifique se todas as dependências do módulo selecionado também foram importadas para uma execução bem-sucedida do trabalho.
• O runbook do Azure não dá suporte a Start-Job com -credential.
• O Azure não dá suporte a todos os parâmetros de entrada do PowerShell. Saiba mais.

Problemas conhecidos

• Runbooks que assumem dependência em caminhos de arquivo internos, como C:\modules podem falhar devido a alterações na infraestrutura de back-end de serviço. Altere o código do runbook para garantir que não haja dependências em caminhos de arquivo internos e use Get-ChildItem para obter as informações necessárias do módulo.

• O cmdlet Get-AzStorageAccount pode falhar com um erro: O comando Get-AzStorageAccount foi encontrado no módulo Az.Storage, mas o módulo não pôde ser carregado.

• Não há suporte para a execução de scripts filho usando .\child-runbook.ps1.
  Solução alternativa: use Start-AutomationRunbook (cmdlet interno) ou Start-AzAutomationRunbook (do módulo Az.Automation) para iniciar outro runbook a partir do runbook pai.

• Ao usar o módulo ExchangeOnlineManagement versão 3.0.0 ou superior, você pode enfrentar erros. Para resolver o problema, certifique-se de carregar explicitamente os módulos PowerShellGet e PackageManagement.

• Quando você utiliza o cmdlet New-AzAutomationVariable no Módulo Az.Automation para carregar uma variável do tipo objeto, a operação não funciona como esperado.

  Solução alternativa: Converta o objeto em uma cadeia de caracteres JSON usando o cmdlet ConvertTo-Json e, em seguida, carregue a variável com a cadeia de caracteres JSON como seu valor. Essa solução alternativa garante o tratamento adequado da variável no ambiente da Automação do Azure como uma cadeia de caracteres JSON.

  Exemplo - Criar um objeto do PowerShell que tenha armazenado informações sobre VMs do 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

Limitações

• Os runbooks não usam processamento paralelo para executar várias ações paralelamente.
• Os runbooks não usam pontos de verificação para retomar o runbook em caso de erro.
• Só é possível incluir os runbooks do PowerShell, do Fluxo de Trabalho do PowerShell e os runbooks gráficos como runbooks filhos usando o cmdlet Start-AzAutomationRunbook, que cria um novo trabalho.
• Os runbooks não podem usar a instrução #Requires do PowerShell, pois ela não tem suporte na área restrita do Azure e nem no Hybrid Runbook Workers, e pode levar o trabalho a falhar.
• O runbook do Azure não dá suporte a Start-Job com -credential.
• O Azure não dá suporte a todos os parâmetros de entrada do PowerShell. Saiba mais.

Problemas conhecidos

• Runbooks que assumem dependência em caminhos de arquivo internos, como C:\modules podem falhar devido a alterações na infraestrutura de back-end de serviço. Altere o código do runbook para garantir que não haja dependências em caminhos de arquivo internos e use Get-ChildItem para obter as informações necessárias do módulo.

  Exemplo de script

  
  # 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
  
  

• O cmdlet Get-AzStorageAccount pode falhar com um erro: O comando Get-AzStorageAccount foi encontrado no módulo Az.Storage, mas o módulo não pôde ser carregado.

• Os runbooks do PowerShell não conseguem recuperar um ativo variável não criptografado com um valor nulo.

• Os runbooks do PowerShell não conseguem recuperar um ativo variável com *~* no nome.

• Uma operação Get-Process em um loop dentro de um runbook do PowerShell pode falhar após cerca de 80 iterações.

• Um runbook do PowerShell pode falhar se tentar gravar uma grande quantidade de dados no fluxo de saída de uma só vez. Geralmente, você pode contornar esse problema fazendo com que o runbook emita apenas as informações necessárias para trabalhar com objetos grandes. Por exemplo, em vez de usar Get-Process sem limitações, faça com que o cmdlet gere apenas os parâmetros necessários como em Get-Process | Select ProcessName, CPU.

• Ao usar o módulo ExchangeOnlineManagement versão 3.0.0 ou superior, você pode enfrentar erros. Para resolver o problema, verifique se você também carrega explicitamente os módulos PowerShellGet e PackageManagement.

• Se você importar o módulo Az.Accounts com a versão 2.12.3 ou mais recente, certifique-se de importar o módulo v10 Newtonsoft.Json explicitamente se os runbooks do PowerShell 5.1 tiverem uma dependência nesta versão do módulo. A solução alternativa para esse problema é usar runbooks do PowerShell 7.2.

• Quando você utiliza o cmdlet New-AzAutomationVariable no Módulo Az.Automation para carregar uma variável do tipo objeto, a operação não funciona como esperado.

  Solução alternativa: Converta o objeto em uma cadeia de caracteres JSON usando o cmdlet ConvertTo-Json e, em seguida, carregue a variável com a cadeia de caracteres JSON como seu valor. Essa solução alternativa garante o tratamento adequado da variável no ambiente da Automação do Azure como uma cadeia de caracteres JSON.

  Exemplo - Criar um objeto do PowerShell que tenha armazenado informações sobre VMs do 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

Limitações

• O PowerShell 7.1 não é mais compatível com o produto pai PowerShell. Recomendamos que você crie novos runbooks no PowerShell 7.2 para um suporte de longo prazo e atualize os runbooks desatualizados.
• Não há suporte para os cmdlets internos do PowerShell de Automação do Azure no Hybrid Runbook Worker do Linux. Você precisa importar o módulo automationassets no início do runbook PowerShell para acessar as funções de recursos compartilhados (ativos) da conta de Automação.
• Na versão de runtime 7 do PowerShell, as atividades do módulo não são extraídas para os módulos importados.
• Não há suporte para o tipo de parâmetro de runbook PSCredential na versão de runtime do PowerShell 7.
• O PowerShell 7.x não dá suporte a fluxos de trabalho. Para obter mais informações, consulte o Fluxo de Trabalho do PowerShell para obter mais detalhes.
• No momento, o PowerShell 7.x não dá suporte a runbooks assinados.
• A integração de controle do código-fonte não dá suporte ao PowerShell 7.1 (versão prévia). Além disso, os runbooks do PowerShell 7.1 (versão prévia) no controle do código-fonte são criados na conta de Automação como Runtime 5.1.
• Não há suporte para o gerenciamento de módulo do PowerShell 7.1 por meio de cmdlets Get-AzAutomationModule.
• O runbook falha sem rastreamento de log se o valor de entrada contiver o caractere '.
• O runbook do Azure não dá suporte a Start-Job com -credential.
• O Azure não dá suporte a todos os parâmetros de entrada do PowerShell. Saiba mais.

Problemas conhecidos

• Runbooks que assumem dependência em caminhos de arquivo internos, como C:\modules podem falhar devido a alterações na infraestrutura de back-end de serviço. Altere o código do runbook para garantir que não haja dependências em caminhos de arquivo internos e use Get-ChildItem para obter as informações necessárias do módulo.

  Exemplo de script

  
  # 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
  
  

• O cmdlet Get-AzStorageAccount pode falhar com um erro: O comando Get-AzStorageAccount foi encontrado no módulo Az.Storage, mas o módulo não pôde ser carregado.

• Não há suporte para a execução de scripts filho usando .\child-runbook.ps1 nesta versão prévia. Solução alternativa: use Start-AutomationRunbook (cmdlet interno) ou Start-AzAutomationRunbook (do módulo Az.Automation) para iniciar outro runbook por meio do runbook pai.

• Não há suporte para propriedades de runbook que definem a preferência de registro em log no runtime 7 do PowerShell. Solução alternativa: defina explicitamente a preferência no início do runbook, como é mostrado a seguir:

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

• Evite importar o módulo Az.Accounts para a versão 2.4.0 no runtime 7 do PowerShell, pois pode haver um comportamento inesperado ao usar essa versão na Automação do Azure.

• Pode haver problemas de formatação com fluxos de saída de erro no trabalho em execução no runtime 7 do PowerShell.

• Quando você importa um módulo do PowerShell 7.1 que depende de outros módulos, pode ocorrer que o botão de importação esteja cinza mesmo quando a versão do PowerShell 7.1 do módulo dependente está instalada. Por exemplo, o módulo Az PowerShell. A versão de computação 4.20.0 tem uma dependência do Az.Accounts sendo >= 2.6.0. Esse problema ocorre quando um módulo dependente equivalente no PowerShell 5.1 não atende aos requisitos de versão. Por exemplo, a versão 5.1 do Az.Accounts era < 2.6.0.

• Quando você inicia o runbook do PowerShell 7 usando o webhook, ele converte automaticamente o parâmetro de entrada do webhook em um JSON inválido.

• Recomendamos que você use a versão do módulo ExchangeOnlineManagement: 3.0.0 ou inferior porque a versão: 3.0.0 ou superior pode levar a falhas no trabalho.

• Se você importar o módulo Az.Accounts com a versão 2.12.3 ou mais recente, certifique-se de importar o módulo Newtonsoft.Json v10 explicitamente se os runbooks do PowerShell 7.1 tiverem uma dependência nesta versão do módulo. A solução alternativa para esse problema é usar runbooks do PowerShell 7.2.

• Quando você utiliza o cmdlet New-AzAutomationVariable no Módulo Az.Automation para carregar uma variável do tipo objeto, a operação não funciona como esperado.

  Solução alternativa: Converta o objeto em uma cadeia de caracteres JSON usando o cmdlet ConvertTo-Json e, em seguida, carregue a variável com a cadeia de caracteres JSON como seu valor. Essa solução alternativa garante o tratamento adequado da variável no ambiente da Automação do Azure como uma cadeia de caracteres JSON.

  Exemplo - Criar um objeto do PowerShell que tenha armazenado informações sobre VMs do 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 
  

Runbooks do Fluxo de Trabalho do PowerShell

Os runbooks do Fluxo de Trabalho do PowerShell são runbooks de texto baseados no Fluxo de Trabalho do Windows PowerShell. Você edita o código do runbook diretamente usando o editor de texto do portal do Azure. Também é possível usar qualquer editor de texto offline e importar o runbook na Automação do Azure.

Observação

O PowerShell 7.1 (versão prévia) e o PowerShell 7.2 não dão suporte a runbooks do Workflow.

Vantagens

• Implemente toda a lógica complexa com o código do Fluxo de Trabalho do PowerShell.
• Utiliza os pontos de verificação para retomar a operação caso ocorra um erro.
• Utiliza o processamento paralelo para executar várias ações paralelamente.
• Pode incluir outros runbooks gráficos e runbooks de Fluxo de Trabalho do PowerShell como runbooks filhos para criar fluxos de trabalho de alto nível.

Limitações

• O fluxo de trabalho do PowerShell não tem suporte nas versões do PowerShell 7+. Portanto, os runbooks desatualizados não podem ser atualizados.
• Tratamento ineficiente da execução paralela em comparação com versões mais recentes do PowerShell 7+.
• O Fluxo de Trabalho do PowerShell funciona internamente usando vários processos. Portanto, os módulos disponíveis em um processo podem não estar disponíveis em outro e causar exceções como comando não encontrado.
• Os runbooks devem lidar com a complexidade adicional do Fluxo de Trabalho do PowerShell, como objetos desserializados.
• Os runbooks demoram mais para iniciar do que os runbooks do PowerShell, pois precisam ser compilados antes da execução.
• Você só pode incluir unbooks do PowerShell como runbooks filhos usando o cmdlet Start-AzAutomationRunbook.
• Os runbooks não podem ser executados em um Hybrid Runbook Worker do Linux.

Runbooks Python

Os runbooks do Python são compilados em Python 2.7 (GA), Python 3.8 (GA) e Python 3.10 (versão prévia). Você pode editar o código do runbook diretamente usando o editor de texto do portal do Azure. Também é possível usar um editor de texto offline e importar o runbook na Automação do Azure.

Atualmente, a versão do runtime do Python 3.10 (versão prévia) tem suporte para trabalhos de Nuvem e Híbrido em todas as regiões Públicas, exceto Austrália Central2, Sul da Coreia, Sul da Suécia, Jio Índia Central, Sudeste do Brasil, Índia Central, Oeste da Índia, EAU Central e Nuvens Gov.

Vantagens

Observação

A importação de um pacote do Python pode levar vários minutos.

• Ela usa bibliotecas robustas do Python.
• Podem ser executados no Azure ou em Hybrid Runbook Workers.
• Para o Python 2.7, há suporte para Hybrid Runbook Workers do Windows com o Python 2.7 instalado.
• Para trabalhos em nuvem do Python 3.8, há suporte para a versão 3.8 do Python. Scripts e pacotes de qualquer versão 3.x poderão funcionar se o código for compatível entre diferentes versões.
• Para trabalhos híbridos do Python 3.8 em computadores Windows, você pode optar por instalar qualquer versão 3.x que possa desejar usar.
• Para trabalhos híbridos do Python 3.8 em computadores Linux, dependemos da versão do 3 do Python instalada no computador para executar o DSC OMSConfig e o Hybrid Worker do Linux. Versões diferentes deverão funcionar se não houver alterações interruptivas em assinaturas de método ou contratos entre as versões do Python 3.

Limitações

A seguir estão as limitações dos runbooks do Python

Python 3.10 (versão prévia)

• Para módulos do Python 3.10 (versão prévia), atualmente há suporte apenas aos arquivos wheel direcionados ao sistema operacional Linux cp310. Saiba mais
• Não há suporte para a integração do controle do código-fonte.
• Pacotes personalizados para Python 3.10 (versão prévia) só são validados durante o runtime do trabalho. Espera-se que o trabalho falhe se o pacote não for compatível no runtime ou se as dependências necessárias dos pacotes não forem importadas para a conta de automação.
• Atualmente, os runbooks do Python 3.10 (versão prévia) só têm suporte no portal do Azure. Não há suporte à API Rest e ao PowerShell.

Python 3.8(GA)

• Você deve estar familiarizado com script do Python.
• Não há suporte para a integração do controle do código-fonte.
• Para módulos do Python 3.8, use arquivos wheel direcionados para cp38-amd64.
• Para utilizar bibliotecas de terceiros, você deve importar os pacotes para a conta de Automação.
• O uso do cmdlet Start-AutomationRunbook no PowerShell/Fluxo de trabalho do PowerShell para iniciar um runbook do Python 3.8 não funciona. Você pode usar o cmdlet Start-AzAutomationRunbook do módulo Az.Automation ou o cmdlet Start-AzureRmAutomationRunbook do módulo AzureRm.Automation para contornar essa limitação. 
• A Automação do Azure não dá suporte para sys.stderr.
• O pacote automationassets do Python não está disponível em pypi.org, portanto, ele não está disponível para importação em um computador Windows.

Python 2,7

• O Python 2.7 não é mais compatível com o produto pai Python. Recomendamos que você crie novos runbooks nas versões com suporte e atualize os runbooks desatualizados.
• Você deve estar familiarizado com script do Python.
• Para módulos do Python 2.7.12, use arquivos wheel cp27-amd6.
• Para utilizar bibliotecas de terceiros, você deve importar os pacotes para a conta de Automação.
• A Automação do Azure não dá suporte para sys.stderr.
• O pacote automationassets do Python não está disponível em pypi.org, portanto, ele não está disponível para importação em um computador Windows.

Várias versões do Python

Ele é aplicável a trabalhos híbridos do Windows. Para o Runbook Worker do Windows, ao executar um runbook do Python 2, ele primeiro procura a variável de ambiente PYTHON_2_PATH e valida se ela aponta para um arquivo executável válido. Por exemplo, se a pasta de instalação for C:\Python2, ele verifica se C:\Python2\python.exe é um caminho válido. Se não for encontrado, ele procurará a variável de ambiente PATH para fazer uma verificação semelhante.

Para o Python 3, ele procura a variável de ambiente PYTHON_3_PATH e, depois, volta para a variável de ambiente PATH.

Ao usar apenas uma versão do Python, você pode adicionar o caminho de instalação à variável PATH. Se você quiser usar as duas versões no Runbook Worker, defina PYTHON_2_PATH e PYTHON_3_PATH para a localização do módulo para essas versões.

Problemas conhecidos

Para trabalhos de nuvem, às vezes, os trabalhos do Python 3.8 falham com uma mensagem de exceção invalid interpreter executable path. Você poderá ver essa exceção se o trabalho estiver atrasado, iniciando mais de 10 minutos ou usando Start-AutomationRunbook para iniciar runbooks do Python 3.8. Se o trabalho estiver atrasado, reiniciar o runbook deverá ser suficiente.

Runbooks gráficos

Você pode criar e editar runbooks gráficos e runbooks gráficos de Fluxo de Trabalho do PowerShell usando o editor gráfico no portal do Azure. No entanto, não é possível criar ou editar este tipo de runbook com outra ferramenta. Principais recursos dos runbooks gráficos:

• Exportados para arquivos na conta de Automação e, em seguida, importados para outra conta de Automação.
• Gerar código do PowerShell.
• Convertidos de ou para runbooks gráficos de Fluxo de Trabalho do PowerShell durante a importação.

Vantagens

• Uso do modelo visual de criação para configurar link de inserção.
• Foco em como os dados fluem no processo.
• Represente visualmente os processos de gerenciamento.
• Inclui outros runbooks como runbooks filhos para criar fluxos de trabalho de alto nível.
• Incentiva a programação modular.

Limitações

• Não é possível criar ou editar fora do portal do Azure.
• Pode exigir uma atividade de código que contenha código do PowerShell para executar lógica complexa.
• Não é possível converter para dos formatos de texto, nem converter um runbook de texto para formato gráfico.
• Não é possível exibir ou editar diretamente o código do PowerShell que o fluxo de trabalho gráfico cria. É possível exibir o código criado em todas as atividades do código.
• Não é possível executar runbooks em um Hybrid Runbook Worker do Linux. Veja Automação de recursos em seu datacenter ou nuvem usando o Hybrid Runbook Worker.
• Os runbooks gráficos não podem ser assinados digitalmente.

Próximas etapas

• Para começar a usar os runbooks do PowerShell, confira Tutorial: Criar um runbook do PowerShell.
• Para saber mais sobre runbooks de Fluxo de Trabalho do PowerShell, confira Tutorial: Criar um runbook de Fluxo de Trabalho do PowerShell.
• Para saber mais sobre runbooks gráficos, confira Tutorial: Criar um runbook gráfico.
• Para saber mais sobre runbooks do Python, consulte Tutorial: Criar um runbook do Python.