Execução de runbooks na Automatização do Azure

  • Artigo

A automatização de processos na Automatização do Azure permite-lhe criar e gerir o PowerShell, o Fluxo de Trabalho do PowerShell e runbooks gráficos. Para obter detalhes, consulte Runbooks de automação do Azure.

A automatização executa os runbooks com base na lógica definida neles. Se um runbook for interrompido, ele será reiniciado no início. Esse comportamento requer que você escreva runbooks que suportem a reinicialização se ocorrerem problemas transitórios.

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

A Automação do Azure atribui um trabalhador para executar cada trabalho durante a execução do runbook. Enquanto os trabalhadores são compartilhados por muitas contas de automação, os trabalhos de diferentes contas de automação são isolados uns dos outros. Você não pode controlar qual trabalhador atende suas solicitações de trabalho.

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 no máximo 30 dias.

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

Job Statuses - PowerShell Workflow

Nota

Para obter informações sobre a visualização ou eliminação de dados pessoais, veja Azure Data Subject Requests for the GDPR (Pedidos de Titulares de Dados do Azure relativos aos RGPD). Para obter mais informações sobre o GDPR, consulte a seção GDPR da Central de Confiabilidade da Microsoft e a seção GDPR do portal Service Trust.

Ambiente de execução Runbook

Os runbooks na Automação do Azure podem ser executados em uma área restrita do Azure ou em um Runbook Worker híbrido.

Quando os runbooks são projetados para autenticar e executar em relação a recursos no Azure, eles são executados em uma área restrita do Azure. A Automação do Azure atribui um trabalhador para executar cada trabalho durante a execução do runbook na área restrita. Enquanto os trabalhadores são compartilhados por muitas contas de automação, os trabalhos de diferentes contas de automação são isolados uns dos outros. Os trabalhos que usam a mesma área restrita são vinculados pelas limitações de recursos 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 de processo e não suporta fazer chamadas WMI para o provedor Win32 em seu runbook.  Esses cenários só são suportados executando o runbook em um Windows Hybrid Runbook Worker.

Você também pode usar um Runbook Worker híbrido para executar runbooks diretamente no computador que hospeda a função e em relação aos recursos locais no ambiente. A Automação do Azure armazena e gerencia runbooks e, em seguida, os entrega a um ou mais computadores atribuídos.

Habilitar o Firewall do Azure no Armazenamento do Azure, o Cofre da Chave do Azure ou o 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 serviços confiáveis da Microsoft estiver habilitada, já que 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 Runbook Worker híbrido e um ponto de extremidade de serviço de rede virtual.

Nota

  • Para executar em um Linux Hybrid Runbook Worker, seus scripts devem ser assinados e o trabalhador configurado de acordo. Como alternativa, a validação de assinatura deve ser desativada.
  • A execução do runbook não deve depender do fuso horário da área restrita.

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

Tarefa Recomendação Notas
Integrar com recursos do Azure Azure Sandbox Hospedada no Azure, a autenticação é mais simples. Se você estiver usando um Runbook Worker híbrido em uma VM do Azure, poderá usar a autenticação de runbook com identidades gerenciadas.
Obter o desempenho ideal para gerenciar recursos do Azure Azure Sandbox O script é executado no mesmo ambiente, que tem menos latência.
Minimizar os custos operacionais Azure Sandbox Não há sobrecarga de computação nem necessidade de uma VM.
Executar script de longa duração Função de Trabalho de Runbook Híbrida As caixas restritas do Azure têm limites de recursos.
Interaja com serviços locais Função de Trabalho de Runbook Híbrida Acesse diretamente a máquina host ou recursos em outros ambientes de nuvem ou no ambiente local.
Requer software e executáveis de terceiros Função de Trabalho de Runbook Híbrida Você gerencia o sistema operacional e pode instalar o software.
Monitorar um arquivo ou pasta com um runbook Função de Trabalho de Runbook Híbrida Use uma tarefa do Inspetor em um Runbook Worker híbrido.
Executar um script que consome muitos recursos Função de Trabalho de Runbook Híbrida As caixas restritas do Azure têm limites de recursos.
Use módulos com requisitos específicos Função de Trabalho de Runbook Híbrida Alguns exemplos são:
WinSCP - dependência do winscp.exe
Administração do IIS - dependência de habilitar ou gerenciar o IIS
Instalar um módulo com um instalador Função de Trabalho de Runbook Híbrida Os módulos para sandbox devem suportar cópia.
Use runbooks ou módulos que exigem a versão do .NET Framework diferente da 4.7.2 Função de Trabalho de Runbook Híbrida As sandboxes do Azure suportam o .NET Framework 4.7.2 e a atualização para uma versão diferente não é suportada.
Executar scripts que exigem elevação Função de Trabalho de Runbook Híbrida As caixas de areia não permitem elevação. Com um Runbook Worker híbrido, você pode desativar o UAC e usar Invoke-Command ao executar o comando que requer elevação.
Executar scripts que exigem acesso ao WMI (Instrumentação de Gerenciamento do Windows) Função de Trabalho de Runbook Híbrida Trabalhos executados em sandboxes na nuvem não podem acessar o provedor WMI.

Armazenamento temporário em ambiente de teste

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 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 para cada área restrita. Ao trabalhar com fluxos de trabalho do PowerShell, esse cenário pode causar um problema porque os fluxos de trabalho do PowerShell usam pontos de verificação e o script pode ser repetido em uma área restrita diferente.

Com a sandbox 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 da VM do Azure, você não deve usar o disco temporário no Windows ou Linux para dados que precisam ser persistentes.

Recursos

Seus runbooks devem incluir lógica para lidar com recursos, por exemplo, VMs, a rede e recursos na rede. Os recursos estã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, consulte Manipular recursos.

Segurança

A Automação do Azure usa o Microsoft Defender for Cloud para fornecer segurança para seus recursos e detetar comprometimento em sistemas Linux. A segurança é fornecida em todas as suas cargas de trabalho, quer os recursos estejam no Azure ou não. Consulte Introdução à autenticação na Automação do Azure.

O Defender for Cloud impõe restrições aos usuários que podem executar quaisquer 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 atualizações do sistema operacional depois de criar uma conta de automação e habilitar o recurso apropriado.

Subscrições

Uma assinatura do Azure é um contrato com a Microsoft para usar um ou mais serviços baseados em nuvem, pelos quais você é cobrado. Para a 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 o Azure ou sistemas de terceiros. Essas credenciais são armazenadas na Automação do Azure, no Cofre da Chave, etc.

Azure Monitor

A Automação do Azure usa o Azure Monitor para monitorar suas operações de máquina. As operações exigem um espaço de trabalho 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 do Windows e computadores físicos. As máquinas podem ser executadas no Azure ou em um ambiente que não seja do Azure, como um datacenter local.

Nota

O agente do Log Analytics para Windows era conhecido anteriormente como Microsoft Monitoring Agent (MMA).

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 de root. Para obter mais informações, consulte Contas de serviço.

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

Permissões do Runbook

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

Módulos

A Automatizaçã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 Runbook Worker Híbrido do Windows. Estes cmdlets foram concebidos para serem utilizados em vez dos cmdlets do Azure PowerShell para interagir com os recursos da sua conta de Automatização.
  • Az.Automation - o módulo PowerShell recomendado 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 cria uma conta de Automatização e tem de o importar manualmente.
  • AzureRM.Automation - instalado por padrão quando você cria uma conta de automação.

Também são suportados 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 configurações DSC, consulte Gerenciar módulos na Automação do Azure.

Certificados

A Automação do Azure usa certificados para autenticação no Azure ou os adiciona a recursos do Azure ou de terceiros. Os certificados são armazenados de forma segura para acesso por runbooks e configurações DSC.

Seus runbooks podem usar certificados autoassinados, que não são assinados por uma autoridade de certificação (CA). Veja Criar um certificado novo.

Tarefas

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 para a mesma área restrita. Um máximo de 10 trabalhos pode ser executado em uma área restrita. Uma área restrita será removida quando nenhum trabalho estiver sendo executado nela; portanto, ele não deve ser usado para salvar arquivos.

Os trabalhos executados 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, consulte Impedir trabalhos simultâneos.

Nota

Os trabalhos do PowerShell iniciados a partir de um runbook executado em uma área restrita do Azure podem não ser executados no modo de idioma completo do PowerShell.

Status do trabalho

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

Status Descrição
Ativação O trabalho está sendo ativado.
Concluída A tarefa foi concluída com êxito.
Com Falha Falha na compilação de um runbook gráfico ou do fluxo de trabalho do PowerShell. Falha ao iniciar um runbook do PowerShell ou o trabalho tinha uma exceção. Consulte Tipos de runbook da Automação do Azure.
Falhou, aguardando recursos O trabalho falhou porque atingiu o limite de partilha justa três vezes e começou a partir do mesmo ponto de verificação ou do início do runbook de cada vez.
Em fila O trabalho está aguardando que os recursos em um trabalhador de automação fiquem disponíveis para que ele possa ser iniciado.
A retomar O sistema está retomando o trabalho depois que ele foi suspenso.
Em Execução A tarefa está a ser executada.
Em execução, aguardando recursos O trabalho foi descarregado porque atingiu o limite de partilha justa. Será retomado em breve a partir do seu último posto de controlo.
A iniciar O trabalho foi atribuído a um trabalhador e o sistema está a iniciá-lo.
Parado A tarefa foi parada pelo utilizador antes de ser concluída.
A parar O sistema está a parar o trabalho.
Suspenso Aplica-se apenas a runbooks gráficos e de fluxo de trabalho do PowerShell. A tarefa foi suspensa pelo utilizador, pelo sistema ou por um comando no runbook. Se um runbook não tiver um ponto de verificação, ele começa do início. Se tiver um ponto de verificação, ele pode começar novamente e retomar a partir de seu último ponto de verificação. O sistema só suspende o runbook quando ocorre uma exceção. Por padrão, a ErrorActionPreference variável é definida como Continuar, indicando que o trabalho continua sendo executado em um erro. Se a variável de preferência estiver definida como Parar, o trabalho será suspenso em caso de erro.
A suspender Aplica-se apenas a runbooks gráficos e de fluxo de trabalho do PowerShell. O sistema está tentando suspender o trabalho a pedido do usuário. O runbook tem de atingir o próximo ponto de verificação antes de poder ser suspenso. Se ele já tiver passado pelo último ponto de verificação, ele será concluído antes de poder ser suspenso.

Registo de atividades

A execução de runbooks na Automatização do Azure escreve detalhes num registo de atividades para a conta de Automatização. Para obter detalhes sobre como usar o log, consulte 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. O tratamento correto de exceções evita que falhas de rede transitórias causem falhas nos runbooks.

ErrorActionPreference

A variável ErrorActionPreference determina como o PowerShell responde a um erro de não terminação. Os erros de encerramento sempre terminam e não são afetados pelo ErrorActionPreference.

Quando o runbook usa ErrorActionPreference, um erro normalmente não terminativo, como PathNotFound do cmdlet Get-ChildItem , impede que o runbook seja concluído. O exemplo a seguir mostra o uso de ErrorActionPreference. O comando Write-Output final nunca é executado, pois o script para.

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

Tente pegar finalmente

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 exceções gerais. A catch instrução 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 System.Net.WebException exceção 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."
}

Lançamento

Throw pode ser usado para gerar um erro de terminação. Esse mecanismo pode ser útil ao definir sua própria lógica em um runbook. Se o script atender a um critério que deve pará-lo, ele pode usar a throw instrução para parar. 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, terminando e não terminando.

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

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

Processos de chamada

Os runbooks executados em sandboxes do Azure não dão suporte a processos de chamada, como executáveis (arquivos .exe ) ou subprocessos. A razão para isso é 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 do dispositivo e da aplicação

Os trabalhos de runbook nas caixas de proteção do Azure não podem acessar nenhuma característica de dispositivo ou aplicativo. A API mais comum usada para consultar métricas de desempenho no Windows é o WMI, com algumas das métricas comuns sendo o uso de memória e CPU. No entanto, não importa qual API é usada, pois os trabalhos em execução na nuvem não podem acessar a implementação da Microsoft do WBEM (Web-Based Enterprise Management). Esta plataforma baseia-se no Common Information Model (CIM), fornecendo os padrões da indústria para definir as características dos dispositivos e aplicações.

Webhooks

Serviços externos, por exemplo, Serviços de DevOps do Azure e 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 runbooks sejam iniciados sem a implementação de um recurso completo de Automação do Azure.

Recursos partilhados

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

Para tarefas de Automação do Azure de longa execução, é recomendável usar um Runbook Worker Híbrido. Os Trabalhadores de Runbook Híbrido não são limitados por uma parte justa e não têm uma limitação sobre quanto tempo um runbook pode executar. Os outros limites de trabalho aplicam-se às caixas de proteção do Azure e aos Trabalhadores de Runbook Híbridos. Embora os Trabalhadores de Runbook Híbridos não estejam limitados pelo limite de compartilhamento justo de três horas, você deve desenvolver runbooks para serem executados nos trabalhadores que suportam reinicializações de problemas inesperados de infraestrutura local.

Outra opção é otimizar um runbook usando runbooks infantis. Por exemplo, seu runbook pode percorrer a mesma função em vários recursos, por exemplo, com uma operação de banco de dados em vários bancos de dados. Você pode mover essa função para um runbook filho e fazer com que seu runbook o chame usando Start-AzAutomationRunbook. Os runbooks filhos são executados em paralelo em processos separados.

O uso de runbooks filho diminui a quantidade total de tempo para o runbook pai ser concluído. Seu runbook pode usar o cmdlet Get-AzAutomationJob para verificar o status do trabalho de um runbook filho se ele ainda tiver mais operações após a conclusão do filho.

Próximos passos