Compartilhar via

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

  • Artigo

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.

Status de trabalho - Fluxo de trabalho do PowerShell

Observação

Para obter informações sobre como exibir ou excluir dados pessoais, consulte Solicitações do titular dos dados geral para GDPR, Solicitações do titular de dados do Azure para o GDPRou solicitações do titular de dados do Windows para o GDPR, dependendo de sua área e necessidades específicas. Para obter mais informações sobre o GDPR, confira a seção GDPR da Central de Confiabilidade da Microsoft e a seção GDPR do Portal de Confiança do Serviço.

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.

Observação

  • Para serem executados em um Hybrid Runbook Worker Linux, seus scripts devem ser assinados e a função de trabalho configurada 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 Observações
Integração com serviços do Azure Área restrita do Azure Com hospedagem no Azure, a autenticação é mais simples. Se você estiver usando um Hybrid Runbook Worker em uma VM do Azure, poderá usar a autenticação de runbook com identidades gerenciadas.
Obter o desempenho ideal para gerenciar recursos do Azure Área restrita do Azure O script é executado no mesmo ambiente, que tem menos latência.
Redução de custos operacionais Área restrita do Azure Não há sobrecarga de computação nem a necessidade de uma VM.
Executar script de execução longa Hybrid Runbook Worker As áreas restritas do Azure têm limites de recursos.
Interagir com serviços locais Hybrid Runbook Worker Acesse diretamente o computador host ou os recursos em outros ambientes de nuvem ou no ambiente local.
Exigir software de terceiros e executáveis Hybrid Runbook Worker Você gerencia o sistema operacional e pode instalar o software.
Monitoramento de um arquivo ou uma pasta com um runbook Hybrid Runbook Worker Use uma Tarefa do Observador em um Hybrid Runbook Worker.
Executar um script com uso intensivo de recursos Hybrid Runbook Worker As áreas restritas do Azure têm limites de recursos.
Usar módulos com requisitos específicos Hybrid Runbook Worker O
WinSCP - dependência em administração de IIS
winscp.exe - dependência em habilitar ou gerenciar IIS, são alguns exemplos
Instalar um módulo com um instalador Hybrid Runbook Worker Os módulos para área restrita devem dar suporte à cópia.
Usar runbooks ou módulos que exigem o .NET Framework diferente da versão 4.7.2 Hybrid Runbook Worker As áreas restritas do Azure dão suporte a .NET Framework 4.7.2, e não há suporte para a atualização para uma versão diferente.
Executar scripts que exigem elevação Hybrid Runbook Worker As áreas restritas não permitem elevação. Com um Hybrid Runbook Worker, você pode desativar o UAC e usar Invoke-Command ao executar o comando que requer elevação.
Executar scripts que exigem acesso à WMI (Instrumentação de Gerenciamento do Windows) Hybrid Runbook Worker Trabalhos em execução em áreas restritas na nuvem não podem acessar o provedor WMI.

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.

Observação

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

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.

Observação

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

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.

Status Descrição
Ativando O trabalho está sendo ativado.
Concluído(a) Operação concluída com sucesso.
Com falha Falha na compilação de um runbook gráfico ou do Fluxo de Trabalho do PowerShell. Um runbook do PowerShell não pôde ser iniciado, ou o trabalho teve uma exceção. Confira Tipos de runbook da Automação do Azure.
Erro, aguardando recursos O trabalho falhou porque atingiu o limite de fração justa três vezes e iniciou do mesmo ponto de verificação ou desde o início do runbook em cada uma das vezes.
Em espera O trabalho está aguardando que os recursos em um trabalho de Automação fiquem disponíveis para que possam ser iniciados.
Retomando O sistema está retomando o trabalho depois que ele ter sido suspenso.
Em execução O trabalho está em execução.
Executando, aguardando recursos O trabalho foi descarregado porque atingiu o limite de compartilhamento justo. Ele continuará em breve a partir de seu último ponto de verificação.
Iniciando O trabalho foi atribuído a um trabalhador e o sistema está iniciando-o.
Parado O trabalho foi interrompido pelo usuário antes de ser concluído.
Parando O sistema está parando o trabalho.
Suspenso Aplica-se somente a runbooks gráficos ou de Fluxo de Trabalho do PowerShell. O trabalho foi suspenso pelo usuário, pelo sistema ou por um comando no runbook. Se um runbook não tiver um ponto de verificação, ele começará do início. Se ele tiver um ponto de verificação, poderá iniciar novamente e retomar no último ponto de verificação. O sistema só suspende o runbook quando ocorre uma exceção. Por padrão, a variável ErrorActionPreference é definida como Continuar, indicando que o trabalho continua em execução em caso de erro. Se a variável de preferência for definida como Parar, o trabalho será suspenso com um erro.
Suspensão Aplica-se somente a runbooks gráficos ou de Fluxo de Trabalho do PowerShell. O sistema está tentando suspender o trabalho por solicitação do usuário. O runbook precisa atingir seu próximo ponto de verificação antes de poder ser suspenso. Se já tiver passado seu último ponto de verificação, ele será concluído antes que possa ser suspenso.
Novo O trabalho foi enviado recentemente, mas ainda não foi ativado.

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