Editar

Automatização da cloud baseada em eventos

Event Grid
Funções
Logic Apps
Monitor
Cosmos DB

Automatizar fluxos de trabalho e tarefas repetitivas na cloud, utilizando tecnologias sem servidor, pode melhorar significativamente a produtividade da equipa de DevOps de uma organização. Um modelo sem servidor é mais adequado para cenários de automatização que se adequam a uma abordagem orientada por eventos.

Arquitetura

Diagrama que demonstra dois cenários de automatização da cloud sem servidor.

Cenários

Este artigo ilustra dois principais cenários de automatização da cloud:

  1. Etiquetagem do centro de custos: esta implementação controla os centros de custos de cada recurso do Azure. O serviço Azure Policyidentifica todos os novos recursos num grupo com um ID do centro de custos predefinido. O Azure Event Grid monitoriza eventos de criação de recursos e, em seguida, chama uma função do Azure. A função interage com o Azure Active Directory e valida o ID do centro de custos do novo recurso. Se for diferente, atualiza a etiqueta e envia um e-mail para o proprietário do recurso. As consultas REST do Azure Active Directory são ridicularizadas por simplicidade. Azure AD também pode ser integrado com o módulo Azure AD PowerShell ou a biblioteca MSAL para Python.

  2. Resposta de limitação: este exemplo monitoriza uma base de dados do Azure Cosmos DB para limitação. Os alertas do Azure Monitor são acionados quando os pedidos de acesso a dados ao Azure Cosmos DB excedem a capacidade em Unidades de Pedido (ou RUs). Um grupo de ações do Azure Monitor está configurado para chamar a função de automatização em resposta a estes alertas. A função dimensiona as RUs para um valor mais elevado, aumentando a capacidade e, por sua vez, parando os alertas.

Nota

Estas soluções não são as únicas a realizar estas tarefas e são mostradas como ilustrativas de como as tecnologias sem servidor podem reagir aos sinais ambientais (eventos) e influenciar as alterações ao seu ambiente. Sempre que for prático, utilize soluções nativas de plataformas em soluções personalizadas. Por exemplo, o Azure Cosmos DB suporta nativamente o débito de dimensionamento automático como uma alternativa nativa ao cenário de resposta de Limitação.

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

As funções nestes cenários de automatização de cloud sem servidor são frequentemente escritas no PowerShell e python, duas das linguagens de scripting mais comuns utilizadas na automatização do sistema. São implementadas com Funções do Azure Ferramentas Principais na CLI do Azure. Em alternativa, utilize o cmdlet do PowerShell Az.Functions para implementar e gerir Funções do Azure.

Fluxo de trabalho

Os cenários de automatização baseados em eventos são melhor implementados com Funções do Azure. Seguem estes padrões comuns:

  • Responder a eventos em recursos. Estas são respostas a eventos como um recurso do Azure ou um grupo de recursos a ser criado, eliminado, alterado, etc. Este padrão utiliza o Event Grid para acionar a função para tais eventos. O cenário de identificação do centro de custos é um exemplo deste padrão. Outros cenários comuns incluem:

    • conceder às equipas do DevOps acesso a grupos de recursos criados recentemente,
    • enviar notificação para o DevOps quando um recurso é eliminado e
    • responder a eventos de manutenção para recursos como o Azure Máquinas Virtuais (VMs).

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

    • parar um recurso à noite e começar de manhã,
    • ler o conteúdo do Armazenamento de Blobs em intervalos regulares e converter num documento do Azure Cosmos DB,
    • analisar periodicamente os recursos que já não estão a ser utilizados e removê-los e
    • cópias de segurança automatizadas.

  • Processar alertas do Azure. Este padrão utiliza a facilidade de integrar alertas e grupos de ações do Azure Monitor com Funções do Azure. Normalmente, a função executa ações de remediação em resposta a métricas, análise de registos e alertas com origem nas aplicações e na infraestrutura. O cenário de resposta de limitação é um exemplo deste padrão. Outros cenários comuns são:

    • truncar a tabela quando Base de Dados SQL atingir o tamanho máximo,
    • reiniciar um serviço numa VM quando é interrompido erroneamente e
    • enviar notificações se uma função estiver a falhar.

  • Orquestrar com sistemas externos. Este padrão permite a integração com sistemas externos, utilizando o Logic Apps para orquestrar o fluxo de trabalho. Os conectores do Logic Apps podem ser facilmente integrados em vários serviços de terceiros, bem como Microsoft serviços, como Microsoft 365. Funções do Azure pode ser utilizada para a automatização real. O cenário de identificação do centro de custos demonstra este padrão. Outros cenários comuns incluem:

    • monitorizar processos de TI, como pedidos de alteração ou aprovações, e
    • enviar notificação por e-mail quando a tarefa de automatização estiver concluída.

  • Expor como um web hook ou API. As tarefas de automatização que utilizam Funções do Azure podem ser integradas em aplicações de terceiros ou até em ferramentas de linha de comandos, expondo a função como um web hook/API com um acionador HTTP. Estão disponíveis vários métodos de autenticação no PowerShell e no Python para proteger o acesso externo à função. A automatização ocorre em resposta aos eventos externos específicos da aplicação, por exemplo, a integração com aplicações de energia ou o GitHub. Os cenários comuns incluem:

    • acionar a automatização para um serviço com falhas e
    • integração de utilizadores nos recursos da organização.

  • Criar interface chatOps. Este padrão permite que os clientes criem uma interface operacional baseada em chat e executem funções de desenvolvimento e operações e comandos em linha com a colaboração humana. Isto pode ser integrado no Azure Bot Framework e utilizar Microsoft comandos do Teams ou do Slack para implementação, monitorização, perguntas comuns, etc. Uma interface chatOps cria um sistema em tempo real para gerir incidentes de produção, com cada passo documentado automaticamente no chat. Leia Como o ChatOps pode ajudá-lo a melhorar o DevOps para obter mais informações.

  • Automatização híbrida. Este padrão utiliza o Serviço de Aplicações do Azure Ligações Híbridas para instalar um componente de software no seu computador local. Este componente permite o acesso seguro aos recursos nesse computador. A capacidade de gerir ambientes híbridos está atualmente disponível em sistemas baseados no Windows com funções do PowerShell. Os cenários comuns incluem:

    • gerir as suas máquinas no local e
    • gerir outros sistemas atrás da firewall (por exemplo, um SQL Server no local) através de um servidor jump.

Componentes

A arquitetura é composta pelos seguintes componentes:

  • Funções do Azure. Funções do Azure fornecer as capacidades de computação baseadas em eventos e sem servidor nesta arquitetura. Uma função executa tarefas de automatização quando acionada por eventos ou alertas. Em dois cenários, uma função é invocada com um pedido HTTP. A complexidade do código deve ser minimizada ao desenvolver a função sem estado 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 automatização do mundo real, certifique-se de que aumenta ou reduz verticalmente adequadamente. Leia Otimizar o desempenho e a fiabilidade das Funções do Azure para melhores práticas ao escrever as suas funções.

  • Azure Logic Apps. O Logic Apps pode ser utilizado para realizar tarefas mais simples, facilmente implementadas com os conectores incorporados. Estas tarefas podem ir desde notificações por e-mail até à integração com aplicações de gestão externa. Para saber como utilizar o Logic Apps com aplicações de terceiros, leia a integração empresarial básica no Azure.

    O Logic Apps não fornece um código ou um estruturador visual de código baixo e pode ser utilizado sozinho em alguns cenários de automatização. Leia esta comparação entre Funções do Azure e o Logic Apps para ver qual o serviço que se adequa ao seu cenário.

  • Event Grid. O Event Grid tem suporte incorporado para eventos de outros serviços do Azure, bem como eventos personalizados (também denominados tópicos personalizados). Os eventos operacionais, como a criação de recursos, podem ser facilmente propagados para a função de automatização, utilizando o mecanismo incorporado do Event Grid.

    O Event Grid simplifica a automatização baseada em eventos com um modelo de publicação-subscrição, permitindo uma automatização fiável para eventos fornecidos através de HTTPS.

  • Azure Monitor. Os alertas do Azure Monitor podem monitorizar as condições críticas e tomar medidas corretivas com os grupos de ações do Azure Monitor. Estes grupos de ações são facilmente integrados com Funções do Azure. Isto é útil para observar e corrigir quaisquer condições de erro na sua infraestrutura, como a limitação da base de dados.

  • Ação de automatização. Este bloco amplo representa outros serviços com os quais a sua função pode interagir, para fornecer a funcionalidade de automatização. Por exemplo, o Azure Active Directory para validação de etiquetas como no primeiro cenário ou uma base de dados a aprovisionar como no segundo cenário.

Considerações

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

Resiliência

Funções do Azure

Processar tempos limite de HTTP

Para evitar tempos limite de HTTP para uma tarefa de automatização mais longa, coloque este evento em fila num Service Bus e processe a automatização real noutra função. O cenário de automatização de resposta de limitação ilustra este padrão, embora o aprovisionamento real de RU do Azure Cosmos DB seja rápido.

Diagrama que mostra a fiabilidade numa função de automatização.

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

Falhas de registo

Como melhor prática, a função deve registar quaisquer falhas na execução de tarefas de automatização. Isto permite a resolução de problemas adequada das condições de erro. Funções do Azure suporta nativamente a integração com o Application Insights como o sistema de telemetria.

Simultaneidade

Verifique o requisito de simultaneidade da função de automatização. A simultaneidade é limitada ao definir a variável maxConcurrentRequests no ficheiro host.json. Esta definição limita o número de instâncias de funções simultâneas em execução na sua aplicação de funções. Uma vez que cada instância consome CPU e memória, este valor tem de ser ajustado para operações intensivas de CPU. Reduza se as maxConcurrentRequests chamadas de função parecerem demasiado lentas ou não conseguirem ser concluídas. Veja a secção Configurar comportamentos do anfitrião para lidar melhor com a simultaneidade para obter mais detalhes.

Idempotência

Certifique-se de que a função de automatização é idempotente. Tanto o Azure Monitor como o Event Grid podem emitir alertas ou eventos que indiquem que a progressão, como o evento subscrito, está resolvida, acionada, em curso, etc., o recurso está a ser aprovisionado, criado com êxito, etc., ou até mesmo enviar alertas falsos devido a uma configuração incorreta. Certifique-se de que a função age apenas nos alertas e eventos relevantes e ignora todos os outros, para que os eventos falsos ou configurados incorretamente não causem resultados indesejados. Para obter mais informações, veja Estruturar Funções do Azure para entradas idênticas.

Event Grid

Se o fluxo de trabalho utilizar o Event Grid, verifique se o seu cenário pode gerar um grande volume de eventos, o suficiente para entupir a grelha. Veja Entrega e repetição de mensagens do Event Grid para compreender como lida com eventos quando a entrega não é reconhecida e modifique a sua lógica em conformidade. O fluxo de trabalho do centro de custos não implementa verificações adicionais para tal, uma vez que apenas observa eventos de criação de recursos num grupo de recursos. Os recursos de monitorização criados numa subscrição inteira podem gerar um maior número de eventos, o que requer um processamento mais resiliente.

Azure Monitor

Se for gerado um número suficientemente grande de alertas e a automatização atualizar os recursos do Azure, poderão ser atingidos os limites de limitação da Resource Manager do Azure. Isto pode afetar negativamente o resto da infraestrutura nessa subscrição. Evite esta situação ao limitar a frequência de alertas gerados pelo Azure Monitor. Também pode limitar os alertas gerados para um erro específico. Veja a documentação sobre alertas do Azure Monitor para obter mais informações.

Segurança

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

Controlar o acesso à função

Restrinja o acesso a uma função acionada por HTTP ao definir o nível de autorização. Com a autenticação anónima , a função é facilmente acessível com um URL, como http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>. A autenticação ao nível da função pode obstinar o ponto final http, ao exigir chaves de função no URL. Este nível é definido no ficheiro 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, poderão ser necessárias estratégias adicionais para proteger a função. Nestes 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. Por vezes, a autorização da função é suficiente para funções acedidas como web hooks.

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

A autenticação ao nível da função é a única opção disponível para grupos de ações do Azure Monitor com Funções do Azure.

Se a função precisar de ser chamada a partir de uma aplicação ou serviço de terceiros, recomenda-se que forneça acesso à mesma com uma camada de Gestão de API. Esta camada deve impor a autenticação. Gestão de API tem um escalão de consumo integrado com Funções do Azure, o que lhe permite pagar apenas se a API for executada. Para obter mais informações, leia Criar e expor as suas funções com OpenAPI.

Se o serviço de chamadas suportar pontos finais de serviço ou ligação privada, poderão ser consideradas as seguintes opções mais dispendiosas:

  • Utilize um plano de Serviço de Aplicações dedicado, onde pode bloquear as funções numa rede virtual para limitar o acesso às mesmas. Isto não é possível num modelo sem servidor baseado no consumo.
  • Utilize o plano Funções do Azure Premium, que inclui uma rede virtual dedicada a ser utilizada pelas suas aplicações de funções.

Para comparar preços e funcionalidades entre estas opções, leia Funções do Azure dimensionamento e alojamento.

Controlar o que a função pode aceder

Identidades geridas para recursos do Azure, uma funcionalidade do Azure Active Directory, simplifica a forma como a função autentica e acede a outros recursos e serviços do Azure. O código não precisa de gerir as credenciais de autenticação, uma vez que é gerido por Azure AD.

Existem dois tipos de identidades geridas:

  • Identidades geridas atribuídas pelo sistema: estas são criadas como parte do recurso do Azure e não podem ser partilhadas entre vários recursos. Estes são eliminados quando o recurso é eliminado. Utilize estes cenários para cenários que envolvam um único recurso do Azure ou que necessitem de identidades independentes. Ambos os cenários utilizam identidades atribuídas pelo sistema, uma vez que atualizam apenas um único recurso. As identidades geridas só são necessárias para atualizar outro recurso. Por exemplo, uma função pode ler as etiquetas de recursos sem uma identidade gerida. Veja estas instruções para adicionar uma identidade atribuída pelo sistema à sua função.

  • Identidades geridas atribuídas pelo utilizador: são criadas como recursos autónomos do Azure. Estes podem ser partilhados em vários recursos e têm de ser explicitamente eliminados quando já não forem necessários. Leia estas instruções sobre como adicionar a identidade atribuída pelo utilizador à sua função. Utilize-os para cenários que:

    • Exigir acesso a vários recursos que podem partilhar uma única identidade ou
    • Precisa de pré-autorização para proteger recursos durante o aprovisionamento ou
    • Ter recursos que são reciclados frequentemente, enquanto as permissões têm de ser consistentes.

Assim que a identidade for atribuída à função do Azure, atribua-lhe uma função com o controlo de acesso baseado em funções do Azure (RBAC do Azure) para aceder aos recursos. Por exemplo, para atualizar um recurso, a função Contribuidor terá de ser atribuída à identidade da função.

Otimização de custos

A otimização de custos consiste em analisar formas de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, veja Descriçã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

As aplicações lógicas têm um modelo de preços pay as you go. Os acionadores, as ações e as execuções de conectores são limitados sempre que uma aplicação lógica é executada. Todas as ações bem-sucedidas e sem êxito, incluindo acionadores, são consideradas execuções.

As aplicações lógicas também têm um modelo de preço fixo. Se precisar de executar aplicações lógicas que comunicam com recursos protegidos numa rede virtual do Azure, pode criá-las num Ambiente de Serviço de Integração (ISE).

Para obter detalhes, veja Modelo de preços do Azure Logic Apps.

Nesta arquitetura, as aplicações lógicas são utilizadas no cenário de identificação do centro de custos para orquestrar o fluxo de trabalho.

Os conectores incorporados são utilizados para ligar a Funções do Azure e enviar notificações por e-mail quando uma tarefa de automatização é concluída. As funções são expostas como um web hook/API com um acionador HTTP. As aplicações lógicas são acionadas apenas quando ocorre um pedido HTTPS. Esta é uma forma económica quando comparada com um design em que as funções consultam continuamente e verificam determinados critérios. Cada pedido de consulta é medido como uma ação.

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

Funções do Azure

Funções do Azure estão disponíveis com os três planos de preços seguintes.

  • Plano de consumo. Este é o plano mais económico e sem servidor disponível, onde paga apenas o tempo de execução da função. Neste plano, as funções podem ser executadas até 10 minutos de cada vez.

  • Plano Premium. Considere utilizar Funções do Azure plano Premium para cenários de automatização com requisitos adicionais, como uma rede virtual dedicada, uma duração de execução mais longa, etc. Estas funções podem ser executadas até uma hora e devem ser escolhidas para tarefas de automatização mais longas, como executar cópias de segurança, indexação de bases de dados ou gerar relatórios.

  • Serviço de Aplicações plano. Os cenários de automatização híbrida que utilizam o Serviço de Aplicações do Azure Ligações Híbridas terão de utilizar o plano de Serviço de Aplicações. As funções criadas ao abrigo deste plano podem ser executadas durante uma duração ilimitada, semelhante a uma aplicação Web.

Nestes cenários de automatização, Funções do Azure são utilizadas para tarefas como atualizar etiquetas no Azure Active Directory ou alterar a configuração do Azure Cosmos DB ao aumentar verticalmente as RUs para um valor mais elevado. O plano consumo é o adequado para este caso de utilização porque essas tarefas são interativas e não de execução prolongada.

Azure Cosmos DB

O Azure Cosmos DB cobra o débito aprovisionado e o armazenamento consumido por hora. O débito aprovisionado é expresso em Unidades de Pedido por segundo (RU/s), que podem ser utilizadas para operações de base de dados típicas, como inserções, leituras. O armazenamento é faturado por cada GB utilizado para os seus dados armazenados e índice. Veja Modelo de preços do Azure Cosmos DB para obter mais informações.

Nesta arquitetura, quando os pedidos de acesso a dados ao Azure Cosmos DB excedem a capacidade em Unidades de Pedido (ou RUs), o Azure Monitor aciona alertas. Em resposta a esses alertas, é configurado um grupo de ações do Azure Monitor para chamar a função de automatização. A função dimensiona as RUs para um valor mais alto. Isto ajuda a reduzir os custos, uma vez que paga apenas os recursos de que as cargas de trabalho precisam por hora.

Para obter uma estimativa rápida dos custos da carga de trabalho, utilize a calculadora de capacidade do Azure Cosmos DB.

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

Considerações sobre implementação

Para fluxos de trabalho de automatização críticos que gerem o comportamento da sua aplicação, a implementação sem tempo de inatividade tem de ser alcançada com um pipeline de DevOps eficiente. Para obter mais informações, leia implementação de back-end sem servidor.

Se a automatização abranger várias aplicações, mantenha os recursos exigidos pela automatização num grupo de recursos separado. Um único grupo de recursos pode ser partilhado entre a automatização e os recursos da aplicação, se a automatização abranger uma única aplicação.

Se o fluxo de trabalho envolver várias funções de automatização, agrupe as funções que servem um cenário numa única aplicação de funções. Leia Gerir aplicação de funções para obter mais informações.

À medida que implementa a sua aplicação, terá de monitorizá-la. Considere utilizar o Application Insights para permitir que os programadores monitorizem o desempenho e detetem problemas.

Para obter mais informações, veja a secçã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 dos recursos do Azure através da interação direta do Azure Resource Manager. Apesar de este ser o resultado pretendido, considere o impacto que tal poderá ter no seu ambiente se os recursos modificados tiverem sido originalmente implementados de forma declarativa, tal como por modelos do Bicep ou do Terraform. A menos que essas alterações sejam replicadas novamente nos seus modelos de origem, a utilização seguinte desses modelos poderá anular as alterações efetuadas por esta automatização. Considere o impacto da mistura de alterações imperativas aos recursos do Azure que são implementados rotineiramente através de modelos.

Implementar este cenário

Para implementar o cenário do centro de custos, veja os passos de implementação no GitHub.

Passos seguintes