Tipos de runbook de Automação do Azure

O recurso de Automação de Processos do Azure dá suporte a vários tipos de runbooks, conforme definido na tabela a seguir.

Tipo	Descrição
PowerShell (recomendado)	Runbook textual baseado em scripts do Windows PowerShell. As versões atualmente suportadas são PowerShell 7.4 e PowerShell 5.1. Como o PowerShell 7.1 e o PowerShell 7.2 não são mais suportados pelo produto pai PowerShell, recomendamos que você crie runbooks na versão com suporte de longo prazo do PowerShell 7.4.
Fluxo de Trabalho do PowerShell	Runbook textual baseado em script de fluxo de trabalho do Windows PowerShell.
Píton (recomendado)	Runbook textual baseado em scripts Python. A versão atualmente suportada é Python 3.10. Como Python 2.7 e Python 3.8 não são mais suportados pelo produto pai Python, recomendamos que você crie runbooks em Python 3.10.
Gráfico	Runbook gráfico baseado no Windows PowerShell e totalmente criado e editado 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.

Para saber mais sobre o ambiente de automação de processos, consulte Execução de runbook na Automação 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 utilize runbooks com versões suportadas de idiomas.

Tenha em mente as seguintes considerações ao decidir qual tipo utilizar para um runbook específico:

• Não é possível converter runbooks do tipo gráfico para o tipo texto, ou vice-versa.
• 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.

Roteiros do PowerShell

Os runbooks de 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.

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.4 é suportada para trabalhos em nuvem e híbridos em todas as regiões públicas, exceto as nuvens Brasil, Sudeste e Gov.
• No momento da execução do runbook, se você selecionar Versão do tempo de execução como 7.4, os módulos do PowerShell destinados à versão de tempo de execução 7.4 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.

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ão7.4, importe o módulo no Runtime Versão7.4; se você estiver executando um runbook para um cenário de automação do SharePoint no Runtime Versão5.1, importe o módulo no Runtime Versão5.1.

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.4

Limitações

Nota

Atualmente, a versão de tempo de execução do PowerShell 7.4 é suportada para trabalhos em nuvem e híbridos em todas as regiões públicas, exceto as nuvens Brasil, Sudeste e Gov.

• Para a versão de tempo de execução do PowerShell 7.4, 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 VS Code 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.4. Além disso, os runbooks do PowerShell 7.4 no controle do código-fonte são criados na conta de automação como Runtime 5.1.
• Az módulo 12.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.4 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 da tarefa.
• 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 ficheiros 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.

• A execução de scripts filho usando .\child-runbook.ps1 não é suportada.
  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

  azurepowershell
  
  # 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.2

Limitações

Nota

A versão do PowerShell 7.2 não é mais suportada pelo produto pai PowerShell.

• 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.
• 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 da tarefa.
• 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 ficheiros 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.

• A execução de scripts filho usando .\child-runbook.ps1 não é suportada.
  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

    azurepowershell
  
    # 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 checkpoints para retomar o runbook se houver um erro.
• Você pode incluir apenas livros de execução do PowerShell, livros de execução de fluxo de trabalho do PowerShell e livros de execução gráficos como livros de execução filho usando o cmdlet Start-AzAutomationRunbook, que cria um novo trabalho.
• Os Runbooks não podem usar a instrução #Requires do PowerShell, uma vez que 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 ficheiros 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.4 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 PSCredential do runbook não é suportado no ambiente 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 controlo 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 controlo de 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.
• O Runbook falha sem gerar um registo 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 ficheiros 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 secundários usando .\child-runbook.ps1 não é suportada nesta visualização. 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.

• 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 o módulo Az.Accounts para a versão 2.4.0 no runtime do PowerShell 7, pois pode haver um comportamento inesperado quando usada na Azure Automation.

• Pode encontrar problemas de formatação nos fluxos de saída de erros para o trabalho que está a correr no ambiente 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 em 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 de fluxo de trabalho do PowerShell

Os runbooks de fluxo de trabalho do PowerShell são runbooks de texto baseados no Windows PowerShell Workflow. 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 (pré-visualização) e o PowerShell 7.2 não suportam runbooks de fluxo de trabalho.

Vantagens

• Implemente toda a lógica complexa com o código de fluxo de trabalho do PowerShell.
• Utilize checkpoints para retomar a operação se houver um erro.
• Use processamento paralelo para executar várias ações em paralelo.
• Pode incluir outros runbooks gráficos e runbooks de Fluxo de Trabalho do PowerShell como runbooks subordinados 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 PowerShell Workflow, 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 de PowerShell como runbooks secundários usando o Start-AzAutomationRunbook cmdlet.
• Runbooks não podem ser executados em um Linux Hybrid Runbook Worker.

Runbooks de Python

Os runbooks Python são compilados em Python 3.10. 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. Python 2.7 e Python 3.8 não são mais suportados pelo produto pai e é recomendado criar runbooks na versão de tempo de execução do Python 3.10.

Atualmente, a versão de tempo de execução do Python 3.10 é suportada para trabalhos em nuvem e híbridos em todas as regiões públicas, exceto as nuvens Brasil, Sudeste e 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.
• 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.10 Hybrid em máquinas Windows, você pode optar por instalar qualquer versão 3.x que queira usar.
• Para trabalhos Python 3.10 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 disruptivas em assinaturas de métodos ou contratos entre versões do Python 3.

Limitações

As limitações dos runbooks Python são:

Python 3,10

• Para módulos Python 3.10, 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 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 são suportados apenas no portal do Azure e na API Rest.

Python 3,8

• Python 3.8 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.
• A integração de controle do código-fonte não é suportada.
• Para módulos Python 3.8, use ficheiros wheel destinados a 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 Python automationassets não está disponível no pypi.org, pelo que não pode ser importado numa 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 Python automationassets não está disponível no pypi.org, pelo que não pode ser importado numa 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 em Python 3.8 às vezes falham com uma mensagem de exceção invalid interpreter executable path. Você pode ver esta exceção se o trabalho estiver atrasado, começar com um atraso de mais de 10 minutos ou usar 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 do PowerShell Workflow utilizando 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 para ou a partir de runbooks gráficos do fluxo de trabalho do PowerShell durante a importação.

Vantagens

• Use o modelo de criação visual de inserção, ligação e configuração.
• Concentre-se em como os dados fluem ao longo do processo.
• Representar visualmente os processos de gestão.
• Inclua outros runbooks como sub-runbooks 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 sequer converter um runbook de texto num 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 o Tutorial: Criar um runbook gráfico.
• Para saber mais sobre runbooks Python, consulte Tutorial: Criar um runbook Python.