Execução de runbook no Automatização do Azure

A automação de processos no Automatização do Azure permite-lhe criar e gerir PowerShell, fluxos de trabalho PowerShell e livros gráficos de execução. Para mais detalhes, consulte Automatização do Azure runbooks.

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

Iniciar um runbook no Automatização do Azure cria uma tarefa, que é uma única instância de execução do runbook. Cada job acede aos recursos do Azure através de uma ligação à sua subscrição do Azure. O trabalho só pode aceder a recursos no seu datacenter se esses recursos estiverem acessíveis a partir da nuvem pública.

O Automatização do Azure atribui um trabalhador para executar cada job 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 quais trabalhadores atendem suas solicitações de trabalho.

Quando visualiza a lista de runbooks no portal Azure, é mostrado o estado de cada tarefa que foi iniciada para cada runbook. O Automatização do Azure armazena registos de trabalhos por um máximo de 30 dias.

O diagrama a seguir mostra o ciclo de vida de uma tarefa de runbook para livros de operações PowerShell, livros de operações Fluxo de Trabalho PowerShell e livros de operações gráficos.

Ambiente de execução do Runbook

Os runbooks em Automatização do Azure podem correr ou num sandbox do Azure ou num Hybrid Runbook Worker.

Quando os runbooks são concebidos para autenticar e executar contra recursos no Azure, correm num sandbox do Azure. O Automatização do Azure atribui um trabalhador para executar cada tarefa durante a execução de runbooks no ambiente sandbox. 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 sandbox estão sujeitos às limitações de recursos da sandbox. O ambiente sandbox do Azure não suporta operações interativas.

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. O Automatização do Azure armazena e gere runbooks e depois entrega-os a um ou mais computadores atribuídos.

Ativar a Azure Firewall em Armazenamento do Azure, Azure Key Vault ou SQL do Azure bloqueia o acesso a partir de Automatização do Azure runbooks para esses serviços. O acesso será bloqueado mesmo quando a exceção de firewall para permitir serviços Microsoft confiáveis estiver ativada, pois Automation não faz parte da lista de serviços de confiança. Com um firewall ativado, o acesso só pode ser feito usando um Runbook Worker híbrido e um endpoint 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 ambiente de teste

Se precisares de criar ficheiros temporários como parte da lógica do runbook, podes usar a pasta Temp (ou seja, $env:TEMP) no sandbox Azure para runbooks a correr em Azure. A única limitação é que não pode usar mais de 1 GB de espaço em disco, que é a cota para cada sandbox. 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, segundo as recomendações Azure VMs, não deve usar o disco temporário no Windows ou Linux para dados que precisam de ser preservados.

Recursos

Seus runbooks devem incluir lógica para lidar com recursos, por exemplo, VMs, a rede e recursos na rede. Os recursos estão ligados a uma subscrição do Azure, e os runbooks requerem credenciais apropriadas para aceder a qualquer recurso. Para obter um exemplo de manipulação de recursos em um runbook, consulte Manipular recursos.

Segurança

Automatização do Azure utiliza o Microsoft Defender para a Cloud para garantir a segurança dos seus recursos e detetar comprometimentos em sistemas Linux. A segurança é fornecida em todas as suas cargas de trabalho, quer os recursos estejam ou não no Azure. Ver Introdução à autenticação em Automatização do Azure.

O Defender para a Cloud impõe restrições aos utilizadores que podem executar quaisquer scripts, assinados ou não, numa 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 subscrição do Azure é um acordo com a Microsoft para utilizar um ou vários serviços baseados na cloud, pelo qual lhe é cobrado. Pode gerir várias subscrições a partir da mesma conta de Automação se a credencial que está a usar tiver acesso a várias subscrições.

Credenciais

Um runbook requer credenciais adequadas para aceder a qualquer recurso, seja para sistemas Azure ou de terceiros. Estas credenciais são armazenadas no Automatização do Azure, Key Vault, etc.

Azure Monitor

Automatização do Azure pode utilizar Azure Monitor para monitorizar as operações da sua máquina.

Permissões do Runbook

Um runbook precisa de permissões para autenticação no Azure, através de credenciais. Consulte a visão geral da autenticação do Automatização do Azure.

Módulos

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

• Orchestrator.AssetManagement.Cmdlets - contém vários cmdlets internos que só estão disponíveis quando executar runbooks no Azure Sandbox ou num Hybrid Runbook Worker do Windows. Estes cmdlets foram concebidos para serem usados em vez dos cmdlets do Azure PowerShell para interagir com os recursos da sua conta de Automação.
• Az.Automation - o módulo PowerShell recomendado para interagir com o Automatização do Azure que substitui o módulo AzureRM Automation. O módulo Az.Automation não está automaticamente incluído quando crias uma conta de Automação e tens de os 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 os seus runbooks e configurações DSC exigem. Para detalhes dos módulos disponíveis para os vossos runbooks e configurações DSC, veja Gerir módulos em Automatização do Azure.

Certificados

Automatização do Azure utiliza certificados para autenticação da Azure ou adiciona-os a recursos da Azure ou de terceiros. Os certificados são armazenados de forma segura para acesso por runbooks e configurações DSC.

Os seus runbooks podem usar certificados auto-assinados, que não são assinados por uma autoridade certificadora (CA). Veja Criar um certificado novo.

Tarefas

O Automatização do Azure suporta um ambiente para executar trabalhos a partir da mesma conta de Automação. Um único runbook pode ter muitas tarefas em execução simultaneamente. Quanto mais tarefas forem executadas ao mesmo tempo, mais frequentemente poderão ser atribuídas ao mesmo sandbox. Um máximo de 10 trabalhos pode ser executado numa sandbox. Uma sandbox será removida quando nenhum trabalho estiver a ser executado nela; portanto, não deve ser usada para salvar arquivos.

Os trabalhos executados no mesmo processo de área restrita podem interferir entre si. Um exemplo é a execução do cmdlet Disconnect-AzAccount . A execução deste cmdlet desconecta cada tarefa de runbook no processo sandbox partilhado. Para obter um exemplo de como trabalhar com esse cenário, consulte Impedir trabalhos simultâneos.

Status de Trabalhos

A tabela seguinte descreve os diferentes estados possíveis das tarefas. Pode visualizar um resumo de estado de todas as tarefas de runbook ou analisar detalhes de uma tarefa específica do runbook no portal do Azure. Também pode configurar a integração com o seu espaço de trabalho Log Analytics para encaminhar o estado dos trabalhos do runbook e os respetivos fluxos de dados. Para mais informações sobre integração com Azure Monitor logs, consulte Encaminhe o estado do trabalho e os fluxos de trabalho da Automação para Azure Monitor logs. Consulte também Obter estados de tarefas para obter um exemplo de trabalho com estados num runbook.

Registo de atividades

A execução de runbooks no Azure Automatização regista 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.

PreferênciaDeAçãoDeErro

A variável ErrorActionPreference determina como o PowerShell responde a um erro não terminativo. Erros de terminação terminam sempre e não são afetados por ErrorActionPreference.

Quando o guia de execução usa ErrorActionPreference, um erro que normalmente não é terminativo, como PathNotFound do cmdlet Get-ChildItem, impede a conclusão do guia de execução. 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 Captura 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çar

Throw pode ser usado para gerar um erro de terminação. Este mecanismo pode ser útil ao definir a sua própria lógica num 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

Os seus runbooks devem lidar com erros. O Automatização do Azure suporta dois tipos de erros do PowerShell, terminais e não terminais.

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

Os erros não terminais permitem que um script continue mesmo após a sua ocorrência. Um exemplo de erro não terminativo é 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 não terminal, pode-se usar ErrorAction Stop no cmdlet.

Processos de invocação

Runbooks que correm em sandboxes da Azure não suportam processos chamados, como executáveis (ficheiros .exe) ou subprocessos. A razão para isto é que um sandbox do Azure é um processo partilhado executado num contentor que pode não conseguir aceder a 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 Runbook em sandboxes da Azure não conseguem aceder a nenhuma característica de dispositivo ou aplicação. A API mais comum usada para consultar métricas de desempenho no Windows é o WMI, sendo algumas das métricas comuns o uso de memória e CPU.

Ganchos da Web

Serviços externos, por exemplo, Azure DevOps Services e GitHub, podem iniciar um runbook no Automatização do Azure. Para fazer esse tipo de inicialização, o serviço usa um webhook por meio de uma única solicitação HTTP. A utilização de um webhook permite iniciar runbooks sem a implementação de uma funcionalidade completa do Automatização do Azure.

Recursos partilhados

Para partilhar recursos entre todos os runbooks na cloud, o Azure utiliza um conceito chamado fair share. Com o uso de fair share, o Azure descarrega temporariamente ou para qualquer trabalho que está a ser executado há mais de três horas. Os trabalhos para PowerShell runbooks e Python runbooks são parados e não reiniciados, e o estado da tarefa passa a ser Parado.

Para tarefas de longa duração no Automatização do Azure, recomenda-se usar um Hybrid Runbook Worker. Os Executores de Runbook Híbridos não são limitados por uma parte justa e não têm uma limitação no tempo de execução de um runbook. O outro trabalho limites aplicam-se tanto a sandboxes Azure como a Trabalhadores de Runbook Híbridos. Embora os Trabalhadores de Runbook Híbridos não estejam limitados pelo limite de fair share de três horas, deve desenvolver runbooks que sejam executados nos trabalhadores que suportam reinicializações após falhas inesperadas na infraestrutura local.

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

O uso de runbooks secundários reduz o tempo total necessário para a conclusão do runbook principal. O seu runbook pode usar o cmdlet Get-AzAutomationJob para verificar o estado do trabalho de um runbook filho, se o runbook filho ainda tiver mais operações após sua conclusão.

Próximos passos

• Para começar a usar um runbook do PowerShell, consulte Tutorial: Criar um runbook do PowerShell.
• Para trabalhar com runbooks, veja Gerir runbooks em Automatização do Azure.
• Para obter detalhes sobre o PowerShell, consulte Documentos do PowerShell.
• Para obter uma referência de cmdlet do PowerShell, consulte Az.Automation.
• Para resolver problemas relacionados com recursos partilhados durante a execução Automatização do Azure runbook, veja Troubleshoot Automatização do Azure shared resource issues.
• Para resolver problemas durante a execução do runbook do Automatização do Azure, veja Resolver problemas do runbook.