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

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

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 recursos do Azure fazendo uma conexão com sua assinatura do Azure. O trabalho só poderá acessar recursos em seu datacenter se eles estiverem acessíveis na nuvem pública.

A Automação do Azure atribui um trabalhador 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 do Azure, ela mostra o status de cada trabalho que foi iniciado para cada runbook. A Automação do Azure armazena logs de trabalho por um máximo de 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 na Automação do Azure podem ser executados em uma área restrita 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. A Automação do Azure atribui uma função de trabalho para a execução de cada trabalho durante a execução do runbook na área restrita. 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 do Azure não oferece suporte a operações interativas. Ele impede o acesso a todos os servidores COM fora do processo e não dá suporte à realização de chamadas WMI para o provedor Win32 em seu runbook.  Esses cenários só têm suporte ao executar o runbook em um Hybrid Runbook Worker do Windows.

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. A Automação do Azure armazena e gerencia runbooks e, em seguida, entrega-os a um ou mais computadores atribuídos.

Habilitar o Firewall do Azure no Armazenamento do Microsoft Azure, no Azure Key Vault ou no SQL do Azure bloqueia o acesso dos runbooks da Automação do Azure para esses serviços. O acesso será bloqueado mesmo quando a exceção de firewall para permitir que serviços Microsoft confiáveis estiver habilitada, pois a Automação 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 de sua lógica de runbook, use a pasta Temp (ou seja, $env:TEMP) na área restrita do 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 nem no Linux para dados que precisam ser persistentes.

Recursos

Seus runbooks devem incluir lógica para lidar com recursos, por exemplo, VMs, a rede e os recursos na rede. Os recursos são vinculados a uma assinatura do 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

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

O Defender para Nuvem aplica restrições quanto aos usuários que podem executar scripts, assinados ou não, 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

Uma assinatura do Azure é um contrato com a Microsoft para usar um ou mais serviços baseados em nuvem, pelos quais você será cobrado. Na Automação do Azure, cada assinatura é vinculada a uma conta de Automação do Azure, e você pode criar várias assinaturas na conta.

Credenciais

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

Azure Monitor

A Automação do Azure usa o Azure Monitor para monitorar as operações de computador. As operações exigem um workspace do Log Analytics e um agente do Log Analytics.

Agente do Log Analytics para Windows

O agente do Log Analytics para Windows funciona com o Azure Monitor para gerenciar VMs e computadores físicos Windows. Os computadores podem ser executados no Azure ou em um ambiente não Azure, como um datacenter local.

Agente do Log Analytics para Linux

O agente do Log Analytics para Linux funciona de forma semelhante ao agente para Windows, mas conecta computadores Linux ao Azure Monitor. O agente é instalado com determinadas contas de serviço que executam comandos que exigem permissões raiz. Para saber mais, confira Contas de serviço.

O log do agente de Log Analytics está localizado em /var/opt/microsoft/omsagent/log/omsagent.log.

Permissões de runbook

Um runbook precisa de permissões para autenticação no Azure, por meio de credenciais. Confira a Visão geral da autenticação na Automação do Azure.

Módulos

A 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 área restrita do Azure ou em um Hybrid Runbook Worker do Windows. Esses cmdlets são criados para serem usados em vez de cmdlets do Azure PowerShell para interagir com seus recursos da conta de Automação.
• AZ.Automation – o módulo recomendado do PowerShell para interagir com a 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 você precisa importá-lo 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 dos módulos disponíveis para seus runbooks e suas configurações DSC, confira Gerenciar módulos na Automação do Azure.

Certificados

A Automação do Azure usa certificados para autenticação no Azure ou os adiciona ao Azure ou a recursos 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 CA (autoridade de certificação). Confira Criar um certificado.

Trabalhos

A 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. Os erros de finalização sempre são encerrados 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
}

Errors

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

Os runbooks executados em áreas restritas do Azure não oferecem suporte a processos de chamada, como executáveis (arquivos .exe) ou subprocessos. O motivo disso é que uma área restrita 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 as métricas de desempenho no Windows é a WMI, com algumas das métricas comuns incluindo uso de memória e de CPU. No entanto, não importa qual API é usada, pois os trabalhos em execução na nuvem não podem acessar a implementação Microsoft de WBEM (Web-Based Enterprise Management). Essa plataforma se baseia no modelo CIM (Common Information Model), fornecendo os padrões do setor para definir características de dispositivo e aplicativo.

Webhooks

Os serviços externos, como o Azure DevOps Services e o GitHub, podem iniciar um runbook na 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 completo da Automação do Azure.

Recursos compartilhados

Para compartilhar recursos entre todos os runbooks na nuvem, o Azure usa um conceito chamado compartilhamento justo. Usando o compartilhamento justo, 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, recomendamos 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 se familiarizar com os runbooks, confira Gerenciar runbooks na 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.