Tipos de runbook da Automação do Azure

O recurso de Automação de Processos de 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 processos, consulte Execução de runbook na Automação do Azure.

Tipo	Description
PowerShell	Runbook textual baseado em scripts do Windows PowerShell. As versões atualmente suportadas são: PowerShell 7.2 (GA) e PowerShell 5.1 (GA). Como o PowerShell 7.1 não é mais suportado pelo 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 textual baseado em scripts de fluxo de trabalho do Windows PowerShell.
Python	Runbook textual baseado em scripts Python. As versões atualmente suportadas são: Python 3.8 (GA) e Python 3.10 (preview). Como o Python 2.7 não é mais suportado pelo produto pai Python, recomendamos que você crie runbooks em versões suportadas de longo prazo.
Gráficos	Runbook gráfico baseado no Windows PowerShell e criado e editado completamente no editor gráfico no 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 completamente no editor gráfico no portal do Azure.

Nota

A Automação do Azure seguirá o ciclo de vida de suporte das versões de linguagem PowerShell e Python de acordo com os cronogramas publicados pelos produtos pai PowerShell e Python , respectivamente. Recomendamos que você use runbooks com versões de idioma suportadas.

Leve em consideração as seguintes considerações ao determinar qual tipo usar para um runbook específico.

• Não é possível converter runbooks de gráficos para textos, ou o contrário.
• Há limitações ao usar runbooks de diferentes tipos como runbooks infantis. Para obter mais informações, consulte Runbooks filho na Automação do Azure.

Runbooks do PowerShell

Os runbooks do PowerShell baseiam-se no Windows PowerShell. Você edita diretamente o código do runbook usando o editor de texto no portal do Azure. Você também pode usar qualquer editor de texto offline e importar o runbook para a Automação do Azure.

A versão do PowerShell é determinada pela versão de tempo de execução especificada (ou seja, a versão 7.2, 7.1 (visualização) ou 5.1).

A mesma sandbox do Azure e o Hybrid Runbook Worker podem executar vários runbooks do PowerShell destinados a diferentes versões de tempo de execução lado a lado.

Nota

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

Certifique-se de selecionar a versão de tempo de execução correta para os módulos.

Por exemplo: se você estiver executando um runbook para um cenário de automação do SharePoint no Runtime versão 7.1 (visualização), importe o módulo no Runtime versão 7.1 (visualização), importe o módulo no Runtime versão 7.1 (visualização), se estiver executando um runbook para um cenário de automação do SharePoint no Runtime versão 5.1, importe o módulo no Runtime versão 5.1. Nesse caso, você veria duas entradas para o módulo, uma para o Runtime Versão 7.1 (visualização) e outra para a 5.1.

Nota

Atualmente, o PowerShell 5.1, o PowerShell 7.1 (visualização) e o PowerShell 7.2 são suportados.

Vantagens

• Implemente toda a lógica complexa com o código do PowerShell sem as outras complexidades do Fluxo de Trabalho do PowerShell.
• Inicie mais rápido do que os runbooks do Fluxo de Trabalho do PowerShell, pois eles não precisam ser compilados antes da execução.
• Execute no Azure e no Hybrid Runbook Workers para Windows e Linux.

Limitações e problemas conhecidos

A seguir estão as limitações atuais e os problemas conhecidos com runbooks do PowerShell:

PowerShell 7.2

Limitações

Nota

Atualmente, a versão de tempo de execução do PowerShell 7.2 é suportada para trabalhos de nuvem e híbridos em todas as regiões públicas, exceto Índia Central, Emirados Árabes Unidos, Israel Central, Itália Norte e Alemanha Norte.

• Para a versão de tempo de execução do PowerShell 7.2, 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 suporta fluxos de trabalho. Para obter mais informações, consulte Fluxo de trabalho do PowerShell para obter mais detalhes.
• Atualmente, o PowerShell 7.x não suporta runbooks assinados.
• A integração de controle do código-fonte não oferece 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.
• Az módulo 8.3.0 é instalado por padrão. A lista completa de módulos de componentes da versão selecionada do módulo Az é mostrada assim que a versão 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. Certifique-se de que todas as dependências para o módulo selecionado também sejam importadas para a execução bem-sucedida do trabalho.
• O runbook do Azure não suporta Start-Job o -credential.
• O Azure não dá suporte a todos os parâmetros de entrada do PowerShell. Mais informações.

Problemas conhecidos

• Runbooks que dependem de caminhos de arquivos 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.

• Get-AzStorageAccount cmdlet pode falhar com um erro: O Get-AzStorageAccount comando 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.

• Quando você usa a versão do módulo ExchangeOnlineManagement : 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 New-AzAutomationVariable cmdlet dentro do Az.Automation Module para carregar uma variável do tipo objeto, a operação não funciona conforme o 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. Esta solução alternativa garante o tratamento adequado da variável no ambiente de Automação do Azure como uma cadeia de caracteres JSON.

  Exemplo - Criar um objeto do PowerShell que tenha armazenado informações em torno de 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 podem usar o processamento paralelo para executar várias ações em paralelo.
• Runbooks não podem usar pontos de verificação para retomar runbook se houver um erro.
• Você pode incluir apenas o PowerShell, runbooks de fluxo de trabalho do PowerShell e runbooks gráficos como runbooks filho usando o cmdlet Start-AzAutomationRunbook , que cria um novo trabalho.
• Os runbooks não podem usar a instrução #Requires do PowerShell, ela não é suportada na área restrita do Azure ou nos Runbook Workers híbridos e pode fazer com que o trabalho falhe.
• O runbook do Azure não suporta Start-Job o -credential.
• O Azure não dá suporte a todos os parâmetros de entrada do PowerShell. Mais informações.

Problemas conhecidos

• Runbooks que dependem de caminhos de arquivos 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
  
  

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

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

• Os runbooks do PowerShell não conseguem obter um recurso de variável com *~* no nome.

• Uma operação Get-Process em um loop em 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. Normalmente, pode contornar este problema ao fazer com que o runbook produza apenas as informações necessárias para trabalhar com objetos grandes. Por exemplo, em vez de usar Get-Process sem limitações, você pode ter a saída do cmdlet apenas os parâmetros necessários, como em Get-Process | Select ProcessName, CPU.

• Quando você usa a versão do módulo ExchangeOnlineManagement : 3.0.0 ou superior, você pode enfrentar erros. Para resolver o problema, certifique-se de carregar explicitamente os módulos PowerShellGet e PackageManagement também.

• 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 5.1 dependerem dessa versão do módulo. A solução alternativa para esse problema é usar runbooks do PowerShell 7.2.

• Quando você utiliza o New-AzAutomationVariable cmdlet dentro do Az.Automation Module para carregar uma variável do tipo objeto, a operação não funciona conforme o 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. Esta solução alternativa garante o tratamento adequado da variável no ambiente de Automação do Azure como uma cadeia de caracteres JSON.

  Exemplo - Criar um objeto do PowerShell que tenha armazenado informações em torno de 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 suportado pelo produto pai PowerShell. Recomendamos que você crie novos runbooks no PowerShell 7.2 para um suporte de longo prazo e atualize os runbooks desatualizados.
• Os cmdlets internos do PowerShell da Automatização do Azure não são suportados numa Função de Trabalho de Runbook Híbrida do Linux. Tem de importar o módulo automationassets no início do runbook do PowerShell para aceder às funções de recursos partilhados da conta de Automatização.
• Para a versão de runtime do PowerShell 7, as atividades do módulo não são extraídas para os módulos importados.
• O tipo de parâmetro de runbook PSCredential não é suportado na versão de tempo de execução do PowerShell 7.
• O PowerShell 7.x não suporta fluxos de trabalho. Para obter mais informações, consulte Fluxo de trabalho do PowerShell para obter mais detalhes.
• Atualmente, o PowerShell 7.x não suporta runbooks assinados.
• A integração de controle do código-fonte não oferece suporte ao PowerShell 7.1 (visualização) Além disso, os runbooks do PowerShell 7.1 (visualização) no controle do código-fonte são criados na conta de automação como Runtime 5.1.
• A gestão de módulos do PowerShell 7.1 não é suportada através de cmdlets Get-AzAutomationModule.
• Runbook falhará sem rastreamento de log se o valor de entrada contiver o caractere '.
• O runbook do Azure não suporta Start-Job o -credential.
• O Azure não dá suporte a todos os parâmetros de entrada do PowerShell. Mais informações.

Problemas conhecidos

• Runbooks que dependem de caminhos de arquivos 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
  
  

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

• A execução de scripts filho usando .\child-runbook.ps1 não é suportada nesta visualização. Solução alternativa: use Start-AutomationRunbook (cmdlet interno) ou Start-AzAutomationRunbook (do Az.Automation módulo) para iniciar outro runbook a partir do runbook pai.

• As propriedades do runbook que definem a preferência de registo não são suportadas no runtime do PowerShell 7. Solução alternativa: defina explicitamente a preferência no início do runbook da seguinte forma -

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

• Evite importar Az.Accounts o módulo para a versão 2.4.0 para o tempo de execução do PowerShell 7, pois pode haver um comportamento inesperado usando essa versão na Automação do Azure.

• Você pode encontrar problemas de formatação com fluxos de saída de erro para o trabalho em execução no tempo de execução do PowerShell 7.

• Quando você importa um módulo do PowerShell 7.1 que depende de outros módulos, você pode achar que o botão de importação é cinza mesmo quando a versão do PowerShell 7.1 do módulo dependente está instalada. Por exemplo, o módulo Az PowerShell. Compute versão 4.20.0, tem uma dependência de Az.Accounts sendo >= 2.6.0. Este problema ocorre quando um módulo dependente equivalente no PowerShell 5.1 não cumpre os 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 de 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 dependerem dessa versão do módulo. A solução alternativa para esse problema é usar runbooks do PowerShell 7.2.

• Quando você utiliza o New-AzAutomationVariable cmdlet dentro do Az.Automation Module para carregar uma variável do tipo objeto, a operação não funciona conforme o 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. Esta solução alternativa garante o tratamento adequado da variável no ambiente de Automação do Azure como uma cadeia de caracteres JSON.

  Exemplo - Criar um objeto do PowerShell que tenha armazenado informações em torno de 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 diretamente o código do runbook usando o editor de texto no portal do Azure. Você também pode usar qualquer editor de texto offline e importar o runbook para a Automação do Azure.

Nota

O PowerShell 7.1 (visualização) e o PowerShell 7.2 não oferecem suporte a runbooks de fluxo de trabalho.

Vantagens

• Implemente toda a lógica complexa com o código de fluxo de trabalho do PowerShell.
• Use pontos de verificação para retomar a operação se houver um erro.
• Use o processamento paralelo para executar várias ações em paralelo.
• Pode incluir outros runbooks gráficos e runbooks do 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 é suportado 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 as versões mais recentes do PowerShell 7+.
• O fluxo de trabalho do PowerShell funciona internamente usando vários processos. Assim, 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 levam mais tempo para serem iniciados do que os runbooks do PowerShell, pois eles devem ser compilados antes da execução.
• Você só pode incluir runbooks do PowerShell como runbooks filho usando o Start-AzAutomationRunbook cmdlet.
• Runbooks não podem ser executados em um Linux Hybrid Runbook Worker.

Runbooks Python

Os runbooks Python compilam em Python 2.7(GA), Python 3.8 (GA) e Python 3.10 (preview). Você pode editar diretamente o código do runbook usando o editor de texto no portal do Azure. Você também pode usar um editor de texto offline e importar o runbook para a Automação do Azure.

Atualmente, a versão de tempo de execução do Python 3.10 (visualização) é suportada para trabalhos em nuvem e híbridos em todas as regiões públicas, exceto Austrália Central2, Coreia do Sul, Sul da Suécia, Jio India Central, Sudeste do Brasil, Índia Central, Índia Ocidental, Central dos Emirados Árabes Unidos e nuvens Gov.

Vantagens

Nota

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

• Usa as robustas bibliotecas Python.
• Pode ser executado no Azure ou em Runbook Workers híbridos.
• Para Python 2.7, Windows Hybrid Runbook Workers são suportados com python 2.7 instalado.
• Para Python 3.8 Cloud Jobs, a versão Python 3.8 é suportada. Scripts e pacotes de qualquer versão 3.x podem funcionar se o código for compatível entre diferentes versões.
• Para trabalhos Python 3.8 Hybrid em máquinas Windows, você pode optar por instalar qualquer versão 3.x que queira usar.
• Para trabalhos Python 3.8 Hybrid em máquinas Linux, dependemos da versão Python 3 instalada na máquina para executar o DSC OMSConfig e o Linux Hybrid Worker. Versões diferentes devem funcionar se não houver alterações de quebra em assinaturas de método ou contratos entre versões do Python 3.

Limitações

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

Python 3.10 (visualização)

• Para módulos Python 3.10 (visualização), atualmente, apenas os arquivos de roda direcionados ao sistema operacional Linux cp310 são suportados. Mais informações
• A integração de controle do código-fonte não é suportada.
• Os pacotes personalizados para Python 3.10 (visualização) só são validados durante o tempo de execução do trabalho. Espera-se que o trabalho falhe se o pacote não for compatível no tempo de execução 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 (visualização) são suportados apenas no portal do Azure. A API REST e o PowerShell não são suportados.

Python 3.8 (GA)

• Você deve estar familiarizado com scripts Python.
• A integração de controle do código-fonte não é suportada.
• Para módulos Python 3.8, use arquivos wheel direcionados para cp38-amd64.
• Para usar bibliotecas de terceiros, você deve importar os pacotes para a conta de automação.
• Usar o cmdlet Start-AutomationRunbook no fluxo de trabalho do PowerShell/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 suporta sys.stderr.
• O pacote de ativos de automação Python não está disponível no pypi.org, portanto, não está disponível para importação em uma máquina Windows.

Python 2,7

• Python 2.7 não é mais suportado pelo produto pai Python. Recomendamos que você crie novos runbooks nas versões suportadas e atualize os runbooks desatualizados.
• Você deve estar familiarizado com scripts Python.
• Para módulos Python 2.7.12, use arquivos de roda cp27-amd6.
• Para usar bibliotecas de terceiros, você deve importar os pacotes para a conta de automação.
• A Automação do Azure não suporta sys.stderr.
• O pacote de ativos de automação Python não está disponível no pypi.org, portanto, não está disponível para importação em uma máquina Windows.

Várias versões do Python

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

Para Python 3, ele procura a PYTHON_3_PATH variável env primeiro e, em seguida, retorna à PATH variável de ambiente.

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

Problemas conhecidos

Para trabalhos na nuvem, os trabalhos do Python 3.8 às vezes falham com uma mensagem invalid interpreter executable pathde exceção . Você pode 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 deve ser suficiente.

Runbooks gráficos

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

• Exportado para ficheiros na sua conta de Automação e, em seguida, importado para outra conta de Automação.
• Gere o código do PowerShell.
• Convertido de ou para runbooks gráficos do Fluxo de Trabalho do PowerShell durante a importação.

Vantagens

• Use o modelo de criação visual insert-link-configure.
• Concentre-se em como os dados fluem ao longo do processo.
• Representar visualmente os processos de gestão.
• Inclua outros runbooks como runbooks filhos para criar fluxos de trabalho de alto nível.
• Incentivar 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 contendo código do PowerShell para executar lógica complexa.
• Não é possível converter para um dos formatos de texto, nem você pode converter um runbook de texto para o formato gráfico.
• Não é possível exibir ou editar diretamente o código do PowerShell criado pelo fluxo de trabalho gráfico. Você pode exibir o código criado em qualquer atividade de código.
• Não é possível executar runbooks em um Linux Hybrid Runbook Worker. Consulte Automatizar recursos em seu datacenter ou nuvem usando o Hybrid Runbook Worker.
• Os runbooks gráficos não podem ser assinados digitalmente.

Próximos passos

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