Automação de nuvem baseada em evento

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 controlada por eventos.

Arquitetura

Cenários

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

1. Marcação do centro de custos: essa implementação rastreia os centros de custo de cada recurso do Azure. O serviço Azure Policymarca 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 a ID do Microsoft Entra e valida a ID do centro de custo para o novo recurso. Se for diferente, ele atualiza a marcação e envia um email 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 Monitor do Azure são disparados 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ções 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, parando 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 gravadas no PowerShell e no Python, duas das linguagens de script mais comuns usadas na automação do sistema. Eles são implantados usando o Azure Functions Core Tools na CLI do Azure. Como alternativa, você usa o cmdlet do PowerShell do Az.Functions para implantar e gerenciar Azure Functions.

Workflow

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

• Responder a eventos sobre recursos. São respostas a eventos como um recurso do Azure ou um grupo de recursos sendo criado, excluído, alterado e assim por diante. Esse padrão usa a Grade de Eventos para disparar 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
  • responder 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 disparadas por temporizador. Exemplos desse padrão são:

  • parar um recurso à noite e começar pela manhã,
  • ler conteúdo do Armazenamento de Blobs em intervalos regulares e converter em um documento do Azure Cosmos DB,
  • verificar periodicamente os recursos que não estão mais em uso e removê-los e
  • backups automatizados.

• Processar alertas do Azure. Esse padrão usa a facilidade de integrar alertas e grupos de ações do Azure Monitor com o Azure Functions. A função normalmente executa ações corretivas em resposta a métricas, análise de logs 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 atingir 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.

• Orquestrar 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 dos Aplicativos Lógicos podem facilmente se integrar a vários serviços de terceiros, bem como 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:

  • monitoramento de processos de TI, como solicitações de alteração ou aprovações, e
  • enviar notificação por email quando a tarefa de automação for concluída.

• Expor como um web hook 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 web hook/API 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 ocorre em resposta aos eventos externos específicos do aplicativo, por exemplo, integração com aplicativos Power ou GitHub. Cenários comuns incluem:

  • acionando a automação para um serviço com falha e
  • integrando usuários aos recursos da organização.

• Criar interface do ChatOps. Esse padrão permite que os clientes criem uma interface operacional baseada em chat 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 do 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 ajudar DevOps a trabalhar melhor para obter mais informações.

• Automação híbrida. Esse padrão usa o Serviço de Aplicativo do Azure Conexões Híbridas para instalar um componente de software em seu computador local. Esse componente permite acesso seguro aos recursos nesse computador. Atualmente, a capacidade de gerenciar ambientes híbridos está disponível em sistemas baseados no Windows usando funções do PowerShell. Cenários comuns incluem:

  • gerenciar seus computadores locais e
  • gerenciar outros sistemas por trás do firewall (por exemplo, um SQL Server local) por meio de um servidor de salto.

Componentes

Essa arquitetura consiste nos seguintes componentes:

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

  Várias execuções de uma função idempotente criam os mesmos resultados. Para manter a idempotência, o dimensionamento de função no cenário de limitação deve ser simplista. Na automação do mundo real, escale ou reduza verticalmente de forma adequada. Leia a Otimizar o desempenho e a confiabilidade do Azure Functions para conhecer práticas recomendadas ao escrever suas funções.

• Aplicativos Lógicos do Azure. Os Aplicativos Lógicos podem ser usados para executar tarefas mais simples, facilmente implementadas usando os conectores internos. Essas tarefas podem variar desde notificações por email até integração com aplicativos de gerenciamento externo. Para saber como usar Aplicativos Lógicos com aplicativos de terceiros, leia a integração corporativa básica no Azure.

  Os Aplicativos Lógicos não fornecem um designer visual sem código ou de código baixo e podem ser usados sozinhos em alguns cenários de automação. Leia essa comparação entre Azure Functions e Aplicativos Lógicos para ver qual serviço pode se ajustar 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 propagados facilmente 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 assinatura de publicação, 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 grupos de ações do Azure Monitor. Esses grupos de ações são facilmente integrados com o 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 de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Resiliência

Funções do Azure

Manipular tempos limite de HTTP

Para evitar tempos limite de HTTP para uma tarefa de automação mais longa, enfileire esse evento em um Barramento de Serviço 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 do Azure Cosmos DB RU seja rápido.

Durable Functions, que mantêm o estado entre invocações, fornecem uma alternativa à abordagem acima. Durable Functions apenas dão suporte a idiomas específicos.

Falhas de log

Como prática recomendada, a função deve registrar 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 dá suporte nativo à 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 definindo a 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ções. Como cada instância consome CPU e memória, esse valor precisa ser ajustado para operações com uso intensivo de CPU. Diminua a maxConcurrentRequests se as chamadas de função parecerem muito lentas ou não forem capazes de ser concluídas. Consulte a seção Configurar comportamentos do host para lidar melhor com a simultaneidade para obter mais detalhes.

Idempotência

Verifique se a função de automação é idempotente. O Azure Monitor e a Grade de Eventos podem emitir alertas ou eventos que indicam que a progressão, como o evento inscrito, foi resolvida, acionada, está em andamento etc., que seu recurso está sendo provisionado, foi criado com êxito etc., ou até mesmo enviar alertas falsos devido a um erro de configuração. Verifique se sua função atua apenas nos alertas e eventos relevantes e ignora todas as outras, para que eventos falsos ou mal configurados não causem resultados indesejados. Para ter mais informações, consulte Como projetar o Azure Functions para obter uma entrada idêntica.

Grade de Eventos

Se o fluxo de trabalho usar a Grade de Eventos, verifique se o cenário pode gerar um grande volume de eventos, o suficiente para entupir a grade. Consulte a entrega de mensagens da Grade de Eventos e tente novamente para entender 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 custos não implementa verificações adicionais para isso, pois ele só 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 uma manipulação 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 nessa assinatura. Evite essa situação limitando a frequência de 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 fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira Visão geral do pilar de segurança.

Controlar o acesso à função

Restrinja o acesso a uma função disparada por HTTP definindo o nível de autorização. Com a 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 no nível da função pode ofuscar o ponto de extremidade http, exigindo chaves de função na URL. Esse 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 do Azure por outros serviços do Azure e não serão expostas à Internet. A autorização de função às vezes é suficiente para funções acessadas como web hooks.

Adicione camadas de segurança sobre a autenticação de função, como,

• autenticação com certificados de cliente ou
• verificando se o chamador faz parte ou tem acesso ao diretório que hospeda a função habilitando 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ções do Azure Monitor usando 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 pagar somente se a API for executada. Para obter mais informações, leia Criar e expor suas funções com o OpenAPI.

Se o serviço de chamada der suporte a pontos de extremidade de serviço ou link privado, as seguintes opções mais caras poderão ser consideradas:

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

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

Controlar 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.

Há dois tipos de identidades gerenciadas:

• Identidades gerenciadas atribuídas pelo sistema: elas são criadas como parte do recurso do Azure e não podem ser compartilhadas entre vários recursos. Elas são excluídas quando o recurso é excluído. Use-os para cenários que envolvem um único recurso do Azure ou que precisam de identidades independentes. Ambos os cenários usam identidades atribuídas pelo sistema, pois atualizam apenas um único recurso. Identidades gerenciadas só são necessárias para atualizar outro recurso. Por exemplo, uma função pode ler as marcações de recurso sem uma identidade gerenciada. Consulte estas instruções para adicionar uma identidade atribuída pelo 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 em vários recursos e precisam ser excluídos explicitamente quando não forem mais necessários. Leia estas instruções sobre como adicionar a identidade atribuída pelo usuário à sua função. Use-os para cenários que:

  • Exigir acesso a vários recursos que podem 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 uma função usando o RBAC do Azure (controle de acesso baseado em função) do Azure para acessar os recursos. Por exemplo, para atualizar um recurso, a função Colaborador precisará ser atribuída à identidade da função.

Otimização de custo

A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

Use a Calculadora de Preços do Azure para estimar os custos. A seguir estão algumas considerações para reduzir o custo.

Aplicativos Lógicos do Azure

Os aplicativos lógicos têm um modelo de preço pago conforme o uso. Gatilhos, ações e execuções do conector são medidos cada vez que um aplicativo lógico é executado. Todas as ações com e sem êxito, incluindo gatilhos, 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 protegidos em uma rede virtual do Azure, poderá criá-los em um ISE (Ambiente de Serviço de Integração).

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

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

Os conectores internos são usados para se conectar ao Azure Functions e enviar notificação por email quando uma tarefa de automação for concluída. As funções são expostas como um web hook/API usando um gatilho HTTP. Os aplicativos lógicos são disparados somente quando ocorre uma solicitação HTTPS. Essa é uma maneira econômica quando comparada a um design em que as funções continuamente pesquisam e verificam determinados critérios. Cada solicitação de sondagem é medida como uma ação.

Para obter mais informações, consulte Preços de Aplicativos Lógicos.

Funções do Azure

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

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

• Plano Premium. Use o plano Premium do Azure Functions 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 execução de backups, indexação de banco de dados ou geração de relatórios.

• Plano do Serviço de Aplicativo. 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 de Serviço de Aplicativo. As funções criadas nesse 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 escalando os RUs para um valor mais alto. O plano de consumo é o apropriado para esse caso de uso porque essas tarefas são interativas e não são de longa execução.

Azure Cosmos DB

O Azure Cosmos DB é cobrado de acordo com a taxa de transferência provisionada e o armazenamento consumido por hora. A taxa de transferência provisionada é expressa em RU/s (Unidades de Solicitação por segundo), que podem ser usadas para operações típicas de banco de dados, como inserções, leituras. O armazenamento é cobrado para cada GB usado para seus dados armazenados e í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 Monitor do Azure dispara alertas. Em resposta a esses alertas, um grupo de ações do Azure Monitor é configurado para chamar a função de automação. A função dimensiona 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 de custo rápida de sua carga de trabalho, use a calculadora de capacidade do Azure Cosmos DB.

Para obter mais informações, confira a seção de custo em Microsoft Azure Well-Architected Framework.

Considerações de implantação

Para fluxos de trabalho de automação críticos que gerenciam o comportamento do aplicativo, a implantação de tempo de inatividade zero deve ser obtida usando um pipeline eficiente do DevOps. Para obter mais informações, leia a 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 recursos de automação e de 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ções. Leia Gerenciar aplicativo de funções para obter mais informações.

Ao implantar seu aplicativo, você precisará monitorá-lo. Use o Application Insights para permitir que os desenvolvedores monitorem o desempenho e detectem problemas.

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

Ações imperativas em 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 tenha sido o resultado pretendido, considere o impacto que isso pode ter em seu ambiente se os recursos modificados foram originalmente implantados declarativamente, como por modelos Bicep ou Terraform. A menos que essas alterações sejam replicadas novamente 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 combinação de alterações imperativas aos recursos do Azure que são implantados rotineiramente por meio de modelos.

Implantar este cenário

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

Próximas etapas

• Treinamento: 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 o Functions
• Design de arquitetura de funções sem servidor
• Arquiteturas de referência de funções sem servidor