Execução de runbook na Automação do Azure

A automação de processos em Automação do Azure permite que você crie e gerencie o PowerShell, o Fluxo de Trabalho do PowerShell e os runbooks gráficos. Para obter detalhes, consulte Automação do Azure runbooks.

A automação executa seus runbooks com base na lógica definida dentro deles. Se um runbook for interrompido, ele será reiniciado. Esse comportamento exige que você grave runbooks que dão suporte à reinicialização caso ocorram problemas transitórios.

Iniciar um runbook na Automação do Azure cria um trabalho, que é uma instância de execução única do runbook. Cada trabalho acessa Azure recursos fazendo uma conexão com sua assinatura Azure. O trabalho só poderá acessar recursos em seu datacenter se eles estiverem acessíveis na nuvem pública.

Automação do Azure designa um agente para executar cada trabalho durante a execução do runbook. Enquanto as funções de trabalho são compartilhadas por muitas contas de Automação, os trabalhos de diferentes contas de Automação ficam isolados uns dos outros. Você não pode controlar de quais serviços seu trabalho necessita.

Quando você exibe a lista de runbooks no portal Azure, ele mostra o status de cada trabalho iniciado para cada runbook. Automação do Azure armazena logs de trabalho por no máximo 30 dias.

O diagrama a seguir mostra o ciclo de vida de um trabalho de runbook para runbooks do PowerShell, runbooks de Fluxo de Trabalhos do PowerShell e runbooks gráficos.

Ambiente de execução de runbook

Os runbooks no Automação do Azure podem ser executados em um sandbox do Azure ou em um Hybrid Runbook Worker.

Quando os runbooks são projetados para serem autenticados e executados em recursos no Azure, eles são executados em uma área restrita do Azure. Automação do Azure atribui um trabalhador para executar cada trabalho durante a execução do runbook na sandbox. Enquanto as funções de trabalho são compartilhadas por muitas contas de Automação, os trabalhos de diferentes contas de Automação ficam isolados uns dos outros. Os trabalhos que usam a mesma área restrita são restringidos pelas limitações de recurso da área restrita. O ambiente de área restrita Azure não dá suporte a operações interativas.

Você também pode usar um Hybrid Runbook Worker para executar runbooks diretamente no computador que hospeda a função e em recursos locais no ambiente. Automação do Azure armazena e gerencia runbooks e os entrega a um ou mais computadores designados.

Habilitar o Firewall do Azure em Armazenamento do Azure, Azure Key Vault ou SQL do Azure bloqueia o acesso de Automação do Azure runbooks para esses serviços. O acesso será bloqueado mesmo quando a exceção de firewall para permitir serviços confiáveis da Microsoft estiver habilitada, pois o Automation não faz parte da lista de serviços confiáveis. Com um firewall habilitado, o acesso só pode ser feito usando um Hybrid Runbook Worker e um ponto de extremidade de serviço de rede virtual.

A tabela a seguir lista algumas tarefas de execução de runbook com o ambiente de execução recomendado listado para cada uma.

Armazenamento temporário em uma área restrita

Se você precisar criar arquivos temporários como parte da lógica do runbook, poderá usar a pasta Temp (ou seja, $env:TEMP) na área restrita Azure para runbooks em execução no Azure. A única limitação é que você não pode usar mais de 1 GB de espaço em disco, que é a cota de cada área restrita. Ao trabalhar com fluxos de trabalho do PowerShell, esse cenário pode causar um problema, pois os fluxos de trabalho do PowerShell usam pontos de verificação e o script pode ser repetido em uma área restrita diferente.

Com a área restrita híbrida, você pode usar C:\temp com base na disponibilidade de armazenamento em um Hybrid Runbook Worker. No entanto, de acordo com as recomendações de VM do Azure, você não deve usar o disco temporário no Windows ou Linux para dados que precisam ser mantidos.

Recursos

Seus runbooks devem incluir lógica para lidar com recursos, por exemplo, VMs, a rede e os recursos na rede. Os recursos estão vinculados a uma assinatura Azure e os runbooks exigem credenciais apropriadas para acessar qualquer recurso. Para obter um exemplo de manipulação de recursos em um runbook, confira Manipular recursos.

Segurança

Automação do Azure usa o Microsoft Defender para Nuvem para fornecer segurança para seus recursos e detectar comprometimento em sistemas Linux. A segurança é fornecida em suas cargas de trabalho, independentemente de os recursos estarem em Azure ou não. Consulte Introdução à autenticação no Automação do Azure.

Defender para Nuvem impõe restrições a usuários que podem executar scripts assinados ou não assinados em uma VM. Se você for um usuário com acesso raiz a uma VM, deverá configurar explicitamente a máquina com uma assinatura digital ou desativá-la. Caso contrário, você só poderá executar um script para aplicar as atualizações do sistema operacional após criar uma conta de Automação do Azure e habilitar o recurso apropriado.

Assinaturas

Um Azure subscription é um contrato com Microsoft para usar um ou mais serviços baseados em nuvem, pelos quais você é cobrado. Você pode gerenciar várias assinaturas da mesma conta de Automação se a credencial que você está usando tiver acesso a várias assinaturas.

Credenciais

Um *runbook* requer credenciais apropriadas para acessar qualquer recurso, seja para sistemas Azure ou de terceiros. Essas credenciais são armazenadas em Automação do Azure, Key Vault etc.

Azure Monitor

Automação do Azure pode usar Azure Monitor para monitorar suas operações de computador.

Permissões de runbook

Um runbook precisa de permissões para autenticação na Azure, por meio de credenciais. Consulte visão geral de autenticação do Automação do Azure.

Módulos

Automação do Azure inclui os seguintes módulos do PowerShell:

• Orchestrator.AssetManagement.Cmdlets – contém vários cmdlets internos que só estão disponíveis quando você executa runbooks no ambiente de sandbox do Azure ou em um Windows Hybrid Runbook Worker. Esses cmdlets foram projetados para serem usados em vez dos cmdlets do Azure PowerShell para interagir com os recursos da Conta de Automação.
• Az.Automation – o módulo recomendado do PowerShell para interagir com Automação do Azure que substitui o módulo de Automação do AzureRM. O módulo Az.Automation não é incluído automaticamente quando você cria uma conta de Automação e precisa importá-los manualmente.
• AzureRM.Automation – instalado por padrão quando você cria uma conta de Automação.

Também há suporte para módulos instaláveis, com base nos cmdlets que seus runbooks e configurações DSC exigem. Para obter detalhes sobre os módulos disponíveis para seus runbooks e configurações de DSC, consulte Gerenciar módulos no Automação do Azure.

Certificados

Automação do Azure usa certificados para autenticação no Azure ou para adicioná-los a recursos do Azure ou de terceiros. Os certificados são armazenados com segurança para acesso por runbooks e configurações DSC.

Seus runbooks podem usar certificados autoassinados, que não são assinados por uma autoridade certificadora (CA). Confira Criar um certificado.

Trabalhos

Automação do Azure dá suporte a um ambiente para executar trabalhos da mesma conta de Automação. Um único runbook pode ter muitos trabalhos em execução ao mesmo tempo. Quanto mais trabalhos você executar ao mesmo tempo, mais frequentemente eles poderão ser enviados à mesma área restrita. No máximo 10 trabalhos podem ser executados em uma área restrita. Uma área restrita será removida quando nenhum trabalho estiver sendo executado nela; portanto, ela não deve ser usado para salvar arquivos.

Os trabalhos em execução no mesmo processo de área restrita podem afetar uns aos outros. Um exemplo é a execução do cmdlet Disconnect-AzAccount. A execução desse cmdlet desconecta cada trabalho de runbook no processo de área restrita compartilhada. Para obter um exemplo de como trabalhar com esse cenário, confira Evitar trabalhos simultâneos.

Status de trabalho

A tabela a seguir descreve os diferentes status possíveis para um trabalho. Você pode exibir um resumo do status para todos os trabalhos de runbook ou analisar detalhes de um trabalho de runbook específico no portal do Azure. Você também pode configurar a integração com o seu espaço de trabalho do Log Analytics a fim de encaminhar fluxos de trabalho e status do trabalho do runbook. Para obter mais informações sobre a integração com logs do Azure Monitor, confira Encaminhar status do trabalho e fluxos de trabalho da Automação para logs do Azure Monitor. Confira também Obter status do trabalho para ver um exemplo de como trabalhar com status em um runbook.

Log de atividades

A execução de runbooks na Automação do Azure grava detalhes em um log de atividades da conta de Automação. Para obter detalhes sobre como usar o log, confira Recuperar detalhes do log de atividades.

Exceções

Esta seção descreve algumas maneiras de lidar com exceções ou problemas intermitentes em seus runbooks. Um exemplo é uma exceção WebSocket. A manipulação correta de exceções impede que falhas de rede transitórias causem falha nos runbooks.

ErrorActionPreference

A variável ErrorActionPreference determina como o PowerShell responde a um erro de não encerramento. Erros de encerramento sempre encerram o processo e não são afetados por ErrorActionPreference.

Quando o runbook usa ErrorActionPreference, um erro que normalmente é de não encerramento, como PathNotFound do cmdlet Get-ChildItem, interrompe a conclusão do runbook. O exemplo a seguir mostra o uso de ErrorActionPreference. O comando final Write-Output nunca é executado, pois o script é interrompido.

$ErrorActionPreference = 'Stop'
Get-ChildItem -path nofile.txt
Write-Output "This message will not show"

Try Catch Finally

Try Catch Finally é usado em scripts do PowerShell para lidar com erros de encerramento. O script pode usar esse mecanismo para capturar exceções específicas ou gerais. A instrução catch deve ser usada para rastrear ou tentar lidar com erros. O exemplo a seguir tenta baixar um arquivo que não existe. Ele captura a exceção System.Net.WebException e retorna o último valor para qualquer outra exceção.

try
{
   $wc = new-object System.Net.WebClient
   $wc.DownloadFile("http://www.contoso.com/MyDoc.doc")
}
catch [System.Net.WebException]
{
    "Unable to download MyDoc.doc from http://www.contoso.com."
}
catch
{
    "An error occurred that could not be resolved."
}

Throw

Throw pode ser usado para gerar um erro de encerramento. Esse mecanismo pode ser útil ao definir sua lógica em um runbook. Se o script atender a um critério que deve encerrá-lo, ele poderá usar a instrução throw para o encerramento. O exemplo a seguir usa essa instrução para mostrar um parâmetro de função necessário.

function Get-ContosoFiles
{
  param ($path = $(throw "The Path parameter is required."))
  Get-ChildItem -Path $path\*.txt -recurse
}

Erros

Seus runbooks devem lidar com erros. A automação do Azure dá suporte a dois tipos de erros do PowerShell, de encerramento e de não encerramento.

Os erros de encerramento param a execução do runbook quando ocorrem. O runbook é finalizado com um status de trabalho de Falha.

Os erros de não encerramento permitem que o script continue mesmo depois de ocorrerem. Um exemplo de erro de não encerramento é aquele que ocorre quando um runbook usa o cmdlet Get-ChildItem com um caminho que não existe. O PowerShell vê que o caminho não existe, gera um erro e continua até a próxima pasta. O erro nesse caso não define o status de trabalho do runbook como Falha, e o trabalho pode até ser concluído. Para forçar um runbook a parar se houver um erro sem finalização, você pode usar ErrorAction Stop no cmdlet.

Chamar processos

Runbooks executados em sandboxes do Azure não dão suporte a chamar processos, como executáveis (arquivos .exe) ou subprocessos. O motivo disso é que um sandbox do Azure é um processo compartilhado executado em um contêiner que pode não ser capaz de acessar todas as APIs subjacentes. Para cenários que exigem software de terceiros ou chamadas para subprocessos, você deve executar um runbook em um Hybrid Runbook Worker.

Características de dispositivo e aplicativo

Os trabalhos de runbook em áreas restritas do Azure não podem acessar nenhuma característica de dispositivo ou aplicativo. A API mais comum usada para consultar métricas de desempenho em Windows é a WMI, com algumas das métricas comuns sendo a memória e o uso da CPU.

Ganchos da Web

Os serviços externos, por exemplo, Azure DevOps Services e GitHub, podem iniciar um runbook no Automação do Azure. Para fazer esse tipo de inicialização, o serviço usa um webhook por meio de uma única solicitação HTTP. O uso de um webhook permite que os runbooks sejam iniciados sem a implementação de um recurso de Automação do Azure completo.

Recursos compartilhados

Para compartilhar recursos entre todos os runbooks na nuvem, Azure usa um conceito chamado compartilhamento justo. Usando o compartilhamento justo de recursos, o Azure descarrega ou interrompe temporariamente qualquer trabalho que tenha sido executado por mais de três horas. Os trabalhos de runbooks do PowerShell e runbooks Python são interrompidos e não são reiniciados, e o status do trabalho é mostrado como Parado.

Para tarefas de Automação do Azure de longa execução, é recomendável usar um Hybrid Runbook Worker. Os Hybrid Runbook Workers não são limitados por fração justa e não limitam o tempo de execução de um runbook. Os outros limites do trabalho se aplicam a áreas restritas do Azure e ao Hybrid Runbook Workers. Embora Hybrid Runbook Workers não sejam restringidos pelo limite de compartilhamento justo de três horas, você deve desenvolver runbooks para execução em trabalhos com suporte para reinicializações após problemas de infraestrutura local inesperados.

Outra opção é otimizar o runbook usando runbooks filhos. Por exemplo, seu runbook pode executar um loop por meio da mesma função em vários recursos, como em uma operação de banco de dados em vários bancos. Você pode mover essa função para um runbook filho e fazer com que seu runbook a chame usando Start-AzAutomationRunbook. Cada um desses runbooks filhos é executado paralelamente em processos separados.

Esse comportamento reduz a quantidade total de tempo para o runbook pai ser concluído. O runbook pode usar o cmdlet Get-AzAutomationJob para verificar o status do trabalho de um runbook filho, caso ainda tenha mais operações após a conclusão do runbook filho.

Próximas etapas

• Para começar a usar um runbook do PowerShell, confira Tutorial: Criar um runbook do PowerShell.
• Para trabalhar com runbooks, consulte Manage runbooks no Automação do Azure.
• Para obter detalhes do PowerShell, confira Documentos do PowerShell.
• Para obter uma referência de cmdlet do PowerShell, confira Az.Automation.
• Para solucionar problemas relacionados a recursos compartilhados durante a execução de runbook do Automação do Azure, consulte Solucionar problemas de recursos compartilhados do Automação do Azure.
• Para solucionar problemas durante a execução do runbook do Automação do Azure, consulte Solucionar problemas de runbook.