Tipos de runbook da Automação do Azure

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

Tipo	Descrição
PowerShell (recomendado)	Runbook de texto baseado no script do Windows PowerShell. As versões atualmente compatíveis são o PowerShell 7.4 e o PowerShell 5.1. Como o PowerShell 7.1 e o PowerShell 7.2 não são mais compatíveis com o produto pai PowerShell, recomendamos que você crie runbooks na versão de longo prazo com suporte do PowerShell 7.4.
Fluxo de Trabalho do PowerShell	Runbook de texto baseado no script do fluxo de trabalho do Windows PowerShell.
Python (recomendado)	Runbook de texto baseado no script do Python. A versão atualmente compatível é o Python 3.10. Como o Python 2.7 e o Python 3.8 não são mais compatíveis com o produto pai Python, recomendamos que você crie runbooks no Python 3.10.
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.

Para saber sobre o ambiente de automação de processos, veja Execução de Runbook na Automação do Azure.

Observação

a automação do Azure seguirá o ciclo de vida de suporte das versões de linguagem do PowerShell e Python de acordo com as linhas do tempo publicadas pelos produtos principais, PowerShell e Python, respectivamente. Recomendamos que você use manuais de operação (runbooks) com versões de idiomas compatíveis.

Considere o seguinte ao determinar qual tipo de runbook usar:

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

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

Selecione a Versão do Runtime 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 outras complexidades do Fluxo de Trabalho do PowerShell.
• Iniciam mais rápido do que os runbooks de Fluxo de Trabalho do PowerShell, pois não precisam ser compilados antes de serem executados.
• 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.4

Limitações

Observação

Atualmente, há suporte para a versão de runtime do PowerShell 7.4 para trabalhos de nuvem e híbridos em todas as regiões públicas, exceto no Sudeste do Brasil e nas nuvens Gov.

• O PowerShell 7.4 só está disponível na experiência de ambiente de runtime.
• Para a versão de runtime 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 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.4. Além disso, os runbooks do PowerShell 7.4 no controle do código-fonte são criados na conta da Automação como Runtime 5.1.
• O módulo Az 12.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.4 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

  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

Observação

A versão 7.2 do PowerShell não tem mais suporte do projeto principal PowerShell.

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

    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

• Runbooks não conseguem usar processamento paralelo para executar várias ações ao mesmo tempo.
• 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.4 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ódulos no PowerShell 7.1 através dos 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 da seguinte maneira:

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

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

• Pode haver problemas de formatação com fluxos de saída de erro no trabalho que está sendo executado no ambiente de execução do PowerShell 7.

• 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.Compute versão 4.20.0 tem como dependência que o Az.Accounts seja >= 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 3.10. 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. O Python 2.7 e o Python 3.8 não são mais compatíveis com o produto pai e é recomendável criar runbooks na versão de runtime do Python 3.10.

Atualmente, a versão de runtime do Python 3.10 tem suporte para trabalhos de nuvem e híbridos em todas as regiões públicas, exceto no Sudeste do Brasil 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.
• 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.10 em computadores Windows, você pode optar por instalar qualquer versão 3.x que deseje usar.
• Para trabalhos híbridos do Python 3.10 em computadores Linux, dependemos da versão do Python 3 instalada no computador para executar o DSC OMSConfig e o Hybrid Worker do Linux. Versões distintas deverão funcionar desde que não ocorram mudanças disruptivas nas assinaturas de métodos ou nos contratos entre as versões do Python 3.

Limitações

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

Python 3.10

• No caso dos módulos Python 3.10, só há suporte no momento para os arquivos de wheel voltados 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 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 só têm suporte no portal do Azure e na API Rest.

Python 3.8

• O Python 3.8 não é mais compatível com o Python do produto pai. Recomendamos que você crie novos runbooks nas versões com suporte e atualize os runbooks desatualizados.
• 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.

Observação

Não há suporte para o uso de um webhook para iniciar um runbook do Python.

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 um 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 PowerShell Workflow, confira Tutorial: Criar um runbook de PowerShell Workflow.
• 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.