Automatização da cloud baseada em eventos

Automatizar fluxos de trabalho e tarefas repetitivas na nuvem, usando tecnologias sem servidor, pode melhorar drasticamente a produtividade da equipe de DevOps de uma organização. Um modelo sem servidor é mais adequado para cenários de automação que se ajustam a uma abordagem orientada a eventos.

Arquitetura

Cenários

Este artigo ilustra dois cenários principais de automação na nuvem:

1. Marcação de centro de custo: essa implementação rastreia os centros de custo de cada recurso do Azure. O serviço de Política do Azure marca todos os novos recursos em um grupo com uma ID de centro de custo padrão. A Grade de Eventos do Azure monitora eventos de criação de recursos e chama uma função do Azure. A função interage com o Microsoft Entra ID e valida o ID do centro de custo para o novo recurso. Se diferente, ele atualiza a tag e envia um e-mail para o proprietário do recurso. As consultas REST para o Microsoft Entra ID são simuladas para simplificar. O Microsoft Entra ID também pode ser integrado usando o módulo Microsoft Graph PowerShell ou a Microsoft Authentication Library (MSAL) para Python.

2. Resposta de limitação: este exemplo monitora um banco de dados do Azure Cosmos DB para limitação. Os alertas do Azure Monitor são acionados quando as solicitações de acesso a dados para o Azure Cosmos DB excedem a capacidade em Unidades de Solicitação (ou RUs). Um grupo de ação do Azure Monitor é configurado para chamar a função de automação em resposta a esses alertas. A função dimensiona as RUs para um valor mais alto, aumentando a capacidade e, por sua vez, interrompendo os alertas.

A implementação de referência para o cenário um está disponível no GitHub.

As funções nesses cenários de automação de nuvem sem servidor geralmente são escritas em PowerShell e Python, duas das linguagens de script mais comuns usadas na automação de sistemas. Eles são implantados usando as Ferramentas Principais do Azure Functions na CLI do Azure. Como alternativa, use o cmdlet Az.Functions PowerShell para implantar e gerenciar o Azure Functions.

Fluxo de Trabalho

Os cenários de automação baseados em eventos são melhor implementados usando o Azure Functions. Eles seguem estes padrões comuns:

• Responda a eventos em recursos. Essas são respostas a eventos como um recurso ou grupo de recursos do Azure sendo criado, excluído, alterado e assim por diante. Esse padrão usa a Grade de Eventos para acionar a função para esses eventos. O cenário de marcação do centro de custo é um exemplo desse padrão. Outros cenários comuns incluem:

  • conceder às equipes de DevOps acesso a grupos de recursos recém-criados,
  • enviar notificação para o DevOps quando um recurso é excluído, e
  • respondendo a eventos de manutenção para recursos como VMs (Máquinas Virtuais) do Azure.

• Tarefas agendadas. Normalmente, são tarefas de manutenção executadas usando funções acionadas por temporizador. Exemplos deste padrão são:

  • parar um recurso à noite e começar de manhã,
  • ler conteúdo do Armazenamento de Blob em intervalos regulares e converter em um documento do Azure Cosmos DB,
  • verificando periodicamente se há recursos que não estão mais em uso e removendo-os, e
  • backups automatizados.

• Processar alertas do Azure. Esse padrão usa a facilidade de integrar alertas e grupos de ação do Azure Monitor com o Azure Functions. A função normalmente executa ações corretivas em resposta a métricas, análises de log e alertas originados nos aplicativos e na infraestrutura. O cenário de resposta de limitação é um exemplo desse padrão. Outros cenários comuns são:

  • truncar a tabela quando o Banco de dados SQL atinge o tamanho máximo,
  • reiniciar um serviço em uma VM quando ele é interrompido erroneamente e
  • enviar notificações se uma função estiver falhando.

• Orquestre com sistemas externos. Esse padrão permite a integração com sistemas externos, usando aplicativos lógicos para orquestrar o fluxo de trabalho. Os conectores de aplicativos lógicos podem ser facilmente integrados com vários serviços de terceiros, bem como com serviços da Microsoft, como o Microsoft 365. O Azure Functions pode ser usado para a automação real. O cenário de marcação do centro de custo demonstra esse padrão. Outros cenários comuns incluem:

  • monitorizar os processos informáticos, tais como pedidos de alteração ou aprovações, e
  • Enviar notificação por e-mail quando a tarefa de automação for concluída.

• Exponha como um gancho da Web ou API. As tarefas de automação usando o Azure Functions podem ser integradas a aplicativos de terceiros ou até mesmo ferramentas de linha de comando, expondo a função como um gancho/API da Web usando um gatilho HTTP. Vários métodos de autenticação estão disponíveis no PowerShell e no Python para proteger o acesso externo à função. A automação acontece em resposta a eventos externos específicos do aplicativo, por exemplo, integração com aplicativos avançados ou GitHub. Cenários comuns incluem:

  • acionar a automação para um serviço com falha, e
  • integração de usuários aos recursos da organização.

• Crie a interface ChatOps. Esse padrão permite que os clientes criem uma interface operacional baseada em bate-papo e executem funções e comandos de desenvolvimento e operações em linha com a colaboração humana. Isso pode se integrar ao Azure Bot Framework e usar comandos do Microsoft Teams ou do Slack para implantação, monitoramento, perguntas comuns e assim por diante. Uma interface ChatOps cria um sistema em tempo real para gerenciar incidentes de produção, com cada etapa documentada automaticamente no chat. Leia Como o ChatOps pode ajudá-lo a melhorar o DevOps para obter mais informações.

• Automação híbrida. Esse padrão usa as Conexões Híbridas do Serviço de Aplicativo do Azure para instalar um componente de software em sua máquina local. Este componente permite o acesso seguro aos recursos nessa máquina. A capacidade de gerenciar ambientes híbridos está atualmente disponível em sistemas baseados no Windows usando funções do PowerShell. Cenários comuns incluem:

  • gerenciando suas máquinas locais, e
  • gerenciando outros sistemas por trás do firewall (por exemplo, um SQL Server local) por meio de um servidor saltitante.

Componentes

A arquitetura é composta pelos seguintes componentes:

• Funções do Azure. O Azure Functions fornece os recursos de computação sem servidor orientados a eventos nessa arquitetura. Uma função executa tarefas de automação, quando acionada por eventos ou alertas. Em dois cenários, uma função é invocada com uma solicitação HTTP. A complexidade do código deve ser minimizada, desenvolvendo a função que é stateless e idempotente.

  Várias execuções de uma função idempotente criam os mesmos resultados. Para manter a idempotência, o dimensionamento da função no cenário de limitação é mantido simplista. Na automação do mundo real, certifique-se de aumentar ou diminuir a escala adequadamente. Leia Otimizar o desempenho e a confiabilidade do Azure Functions para obter as práticas recomendadas ao escrever suas funções.

• Azure Logic Apps. Os aplicativos lógicos podem ser usados para executar tarefas mais simples, facilmente implementadas usando os conectores integrados. Essas tarefas podem variar de notificações por e-mail à integração com aplicativos de gerenciamento externos. Para saber como usar Aplicativos Lógicos com aplicativos de terceiros, leia Integração corporativa básica no Azure.

  Os Aplicativos Lógicos fornecem um designer visual sem código ou baixo código e podem ser usados sozinhos em alguns cenários de automação. Leia esta comparação entre o Azure Functions e os Aplicativos Lógicos para ver qual serviço pode se adequar ao seu cenário.

• Grade de eventos. A Grade de Eventos tem suporte interno para eventos de outros serviços do Azure, bem como eventos personalizados (também chamados de tópicos personalizados). Eventos operacionais, como a criação de recursos, podem ser facilmente propagados para a função de automação, usando o mecanismo interno da Grade de Eventos.

  A Grade de Eventos simplifica a automação baseada em eventos com um modelo de publicação-assinatura, permitindo automação confiável para eventos entregues por HTTPS.

• Azure Monitor. Os alertas do Azure Monitor podem monitorar condições críticas e tomar medidas corretivas usando os grupos de ação do Azure Monitor. Esses grupos de ação são facilmente integrados ao Azure Functions. Isso é útil para observar e corrigir quaisquer condições de erro em sua infraestrutura, como limitação de banco de dados.

• Ação de automação. Esse bloco amplo representa outros serviços com os quais sua função pode interagir, para fornecer a funcionalidade de automação. Por exemplo, Microsoft Entra ID para validação de marca como no primeiro cenário, ou um banco de dados para provisionar como no segundo cenário.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Resiliência

Funções do Azure

Manipular tempos limite HTTP

Para evitar tempos limite HTTP para uma tarefa de automação mais longa, enfileire esse evento em um Service Bus e manipule a automação real em outra função. O cenário de automação de resposta de limitação ilustra esse padrão, mesmo que o provisionamento real de RU do Azure Cosmos DB seja rápido.

As funções duráveis, que mantêm o estado entre as invocações, fornecem uma alternativa à abordagem acima. As funções duráveis suportam apenas idiomas específicos.

Falhas de log

Como prática recomendada, a função deve registrar quaisquer falhas na execução de tarefas de automação. Isso permite a solução de problemas adequada das condições de erro. O Azure Functions suporta nativamente a integração com o Application Insights como o sistema de telemetria.

Simultaneidade

Verifique o requisito de simultaneidade para sua função de automação. A simultaneidade é limitada pela configuração da variável maxConcurrentRequests no arquivo host.json. Essa configuração limita o número de instâncias de função simultâneas em execução em seu aplicativo de função. Como cada instância consome CPU e memória, esse valor precisa ser ajustado para operações com uso intensivo de CPU. Abaixe a se as chamadas de função parecerem muito lentas maxConcurrentRequests ou não puderem ser concluídas. Consulte a seção Configurar comportamentos de host para lidar melhor com a simultaneidade para obter mais detalhes.

Idempotência

Certifique-se de que a sua função de automação é idempotente. O Monitor do Azure e a Grade de Eventos podem emitir alertas ou eventos que indicam que a progressão, como o evento inscrito, foi resolvido, disparado ou está em andamento e seu recurso está sendo provisionado, criado com êxito e assim por diante. ou até mesmo enviar alertas falsos devido a uma configuração incorreta. Certifique-se de que a sua função atua apenas nos alertas e eventos relevantes e ignora todos os outros, para que eventos falsos ou mal configurados não causem resultados indesejados. Para obter mais informações, consulte Projetando o Azure Functions para entrada idêntica.

Event Grid

Se o fluxo de trabalho usa a Grade de Eventos, verifique se o cenário pode gerar um grande volume de eventos, o suficiente para obstruir a grade. Consulte Entrega de mensagens da Grade de Eventos e tente entender novamente como ela lida com eventos quando a entrega não é reconhecida e modifique sua lógica de acordo. O fluxo de trabalho do centro de custo não implementa verificações adicionais para isso, pois ele apenas observa eventos de criação de recursos em um grupo de recursos. Os recursos de monitoramento criados em uma assinatura inteira, podem gerar um número maior de eventos, exigindo um tratamento mais resiliente.

Azure Monitor

Se um número suficientemente grande de alertas for gerado e a automação atualizar os recursos do Azure, os limites de limitação do Azure Resource Manager poderão ser atingidos. Isso pode afetar negativamente o restante da infraestrutura dessa assinatura. Evite essa situação limitando a frequência dos alertas gerados pelo Azure Monitor. Você também pode limitar os alertas gerados para um erro específico. Consulte a documentação sobre alertas do Azure Monitor para obter mais informações.

Segurança

A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Visão geral do pilar de segurança.

Controlar o acesso à função

Restrinja o acesso a uma função acionada por HTTP definindo o nível de autorização. Com autenticação anônima , a função é facilmente acessível com uma URL como http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>. A autenticação de nível de função pode ofuscar o ponto de extremidade http, exigindo teclas de função na URL. Este nível é definido no arquivo function.json:

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "Request",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "Response"
    }
  ]
}

Para o ambiente de produção, estratégias adicionais podem ser necessárias para proteger a função. Nesses cenários, as funções são executadas na plataforma Azure por outros serviços do Azure e não serão expostas à Internet. A autorização de funções às vezes é suficiente para funções acessadas como ganchos da web.

Considere adicionar camadas de segurança sobre a autenticação de funções, como, por exemplo,

• autenticação com certificados de cliente, ou
• certificando-se de que o chamador faz parte ou tem acesso ao diretório que hospeda a função, habilitando a Autenticação do Serviço de Aplicativo.

A autenticação no nível da função é a única opção disponível para grupos de ação do Azure Monitor usando o Azure Functions.

Se a função precisar ser chamada de um aplicativo ou serviço de terceiros, é recomendável fornecer acesso a ela com uma camada de Gerenciamento de API. Essa camada deve impor a autenticação. O Gerenciamento de API tem uma camada de consumo integrada ao Azure Functions, que permite que você pague somente se a API for executada. Para obter mais informações, leia Criar e expor suas funções com OpenAPI.

Se o serviço de chamada suportar pontos de extremidade de serviço ou link privado, as seguintes opções mais caras podem ser consideradas:

• Use um plano dedicado do Serviço de Aplicativo, onde você pode bloquear as funções em uma rede virtual para limitar o acesso a ela. Isso não é possível em um modelo sem servidor baseado em consumo.
• Use o plano Azure Functions Premium, que inclui uma rede virtual dedicada para ser usada por seus aplicativos de função.

Para comparar preços e recursos entre essas opções, leia Escala e hospedagem do Azure Functions.

Controle o que a função pode acessar

Identidades gerenciadas para recursos do Azure, um recurso do Microsoft Entra, simplifica como a função autentica e acessa outros recursos e serviços do Azure. O código não precisa gerenciar as credenciais de autenticação, pois é gerenciado pelo Microsoft Entra ID.

Existem dois tipos de identidades geridas:

• Identidades gerenciadas atribuídas ao sistema: elas são criadas como parte do recurso do Azure e não podem ser compartilhadas entre vários recursos. Eles são excluídos quando o recurso é excluído. Use-os para cenários que envolvam um único recurso do Azure ou que precisem de identidades independentes. Ambos os cenários usam identidades atribuídas ao sistema, uma vez que atualizam apenas um único recurso. As identidades gerenciadas só são necessárias para atualizar outro recurso. Por exemplo, uma função pode ler as tags de recurso sem uma identidade gerenciada. Consulte estas instruções para adicionar uma identidade atribuída ao sistema à sua função.

• Identidades gerenciadas atribuídas pelo usuário: elas são criadas como recursos autônomos do Azure. Eles podem ser compartilhados entre vários recursos e precisam ser explicitamente excluídos quando não forem mais necessários. Leia estas instruções sobre como adicionar identidade atribuída pelo usuário à sua função. Use-os para cenários que:

  • Exigir acesso a vários recursos que possam compartilhar uma única identidade, ou
  • Precisa de pré-autorização para proteger recursos durante o provisionamento, ou
  • Tenha recursos que são reciclados com frequência, enquanto as permissões precisam ser consistentes.

Depois que a identidade for atribuída à função do Azure, atribua-lhe uma função usando o controle de acesso baseado em função do Azure (Azure RBAC) para acessar os recursos. Por exemplo, para atualizar um recurso, a função de Colaborador precisará ser atribuída à identidade da função.

Otimização de custos

A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de otimização de custos.

Utilize a calculadora de preços do Azure para prever os custos. Seguem-se algumas considerações para reduzir os custos.

Azure Logic Apps

Os aplicativos lógicos têm um modelo de preços pré-pagos. As execuções de acionadores, ações e conectores são medidas sempre que uma aplicação lógica é executada. Todas as ações realizadas com e sem êxito, incluindo os acionadores, são consideradas execuções.

Os aplicativos lógicos também têm um modelo de preço fixo. Se você precisar executar aplicativos lógicos que se comunicam com recursos seguros em uma rede virtual do Azure, poderá criá-los em um ISE (Integration Service Environment).

Para obter detalhes, consulte Modelo de preços para Aplicativos Lógicos do Azure.

Nessa arquitetura, os aplicativos lógicos são usados no cenário de marcação do centro de custo para orquestrar o fluxo de trabalho.

Os conectores internos são usados para se conectar ao Azure Functions e enviar notificações por email quando uma tarefa de automação é concluída. As funções são expostas como um gancho/API da Web usando um gatilho HTTP. Os aplicativos lógicos são acionados somente quando ocorre uma solicitação HTTPS. Esta é uma forma rentável quando comparada com um desenho ou modelo em que as funções pesquisam e verificam continuamente determinados critérios. Cada pedido de sondagem é medido como uma ação.

Para obter mais informações, veja os preços do Logic Apps.

Funções do Azure

O Azure Functions está disponível com os três planos de preços a seguir.

• Plano de consumo. Este é o plano mais econômico e sem servidor disponível, onde você paga apenas pelo tempo em que sua função é executada. De acordo com este plano, as funções podem ser executadas por até 10 minutos de cada vez.

• Plano Premium. Considere usar o plano do Azure Functions Premium para cenários de automação com requisitos adicionais, como uma rede virtual dedicada, uma duração de execução mais longa e assim por diante. Essas funções podem ser executadas por até uma hora e devem ser escolhidas para tarefas de automação mais longas, como a execução de backups, indexação de banco de dados ou geração de relatórios.

• Plano do Serviço de Aplicações. Os cenários de automação híbrida que usam as Conexões Híbridas do Serviço de Aplicativo do Azure precisarão usar o plano do Serviço de Aplicativo. As funções criadas sob este plano podem ser executadas por duração ilimitada, semelhante a um aplicativo Web.

Nesses cenários de automação, o Azure Functions é usado para tarefas como atualizar marcas no Microsoft Entra ID ou alterar a configuração do Azure Cosmos DB dimensionando as RUs para um valor mais alto. O plano de consumo é o apropriado para este caso de uso porque essas tarefas são interativas e não de longa duração.

Azure Cosmos DB

O Azure Cosmos DB cobra a taxa de transferência provisionada e o armazenamento consumido por hora. A taxa de transferência provisionada é expressa em Unidades de Solicitação por segundo (RU/s), que podem ser usadas para operações típicas de banco de dados, como inserções e leituras. O armazenamento é cobrado por cada GB usado para os dados armazenados e o índice. Consulte Modelo de preços do Azure Cosmos DB para obter mais informações.

Nessa arquitetura, quando as solicitações de acesso a dados para o Azure Cosmos DB excedem a capacidade em Unidades de Solicitação (ou RUs), o Azure Monitor dispara alertas. Em resposta a esses alertas, um grupo de ação do Azure Monitor é configurado para chamar a função de automação. A função escala as RUs para um valor mais alto. Isso ajuda a manter o custo baixo porque você paga apenas pelos recursos de que suas cargas de trabalho precisam por hora.

Para obter uma estimativa rápida do custo da sua carga de trabalho, use a calculadora de capacidade do Azure Cosmos DB.

Para obter mais informações, consulte a seção Custo no Microsoft Azure Well-Architected Framework.

Considerações sobre implementação

Para fluxos de trabalho de automação críticos que gerenciam o comportamento de seu aplicativo, a implantação sem tempo de inatividade deve ser alcançada usando um pipeline de DevOps eficiente. Para obter mais informações, leia Implantação de back-end sem servidor.

Se a automação abranger vários aplicativos, mantenha os recursos exigidos pela automação em um grupo de recursos separado. Um único grupo de recursos pode ser compartilhado entre a automação e os recursos do aplicativo, se a automação abranger um único aplicativo.

Se o fluxo de trabalho envolver várias funções de automação, agrupe as funções que atendem a um cenário em um único aplicativo de função. Leia Gerenciar aplicativo de função para obter mais informações.

À medida que você implanta seu aplicativo, você precisará monitorá-lo. Considere o uso do Application Insights para permitir que os desenvolvedores monitorem o desempenho e detetem problemas.

Para obter mais informações, consulte a seção DevOps no Microsoft Azure Well-Architected Framework.

Ações imperativas nos recursos do Azure

Em ambos os cenários acima, o resultado final foi uma alteração no estado do recurso do Azure por meio da interação direta do Azure Resource Manager. Embora esse fosse o resultado pretendido, considere o impacto que isso poderia ter em seu ambiente se os recursos modificados fossem originalmente implantados declarativamente, como por modelos Bicep ou Terraform. A menos que essas alterações sejam replicadas de volta em seus modelos de origem, o próximo uso desses modelos pode desfazer as alterações feitas por essa automação. Considere o impacto da mistura de alterações imperativas nos recursos do Azure que são implantados rotineiramente por meio de modelos.

Implementar este cenário

Para implantar o cenário de centro de custo, consulte as etapas de implantação no GitHub.

Próximos passos

• Formação: Introdução ao Azure Functions
• Documentação: Introdução ao Azure Functions
• O que é a Grade de Eventos do Azure?

Recursos relacionados

• Passo a passo do código: Aplicativo sem servidor com funções
• Design de arquitetura de funções sem servidor
• Arquiteturas de referência de funções sem servidor