A conteinerização é uma abordagem comum para a modernização de aplicativos. Você pode considerar usar o Serviço Kubernetes do Azure para cargas de trabalho avançadas ou usar as Instâncias de Contêiner do Azure para cargas de trabalho de contêiner simples, como um aplicativo Web simples. Este artigo se concentra na implementação de automação sem servidor no nível de infraestrutura para instâncias de contêiner quando o Application Gateway é usado como firewall.
Começaremos com um cenário comum. Para proteger instâncias de contêiner do Azure, você pode usar grupos de contêineres em Instâncias de Contêiner do Azure. Usando grupos de contêineres, você pode implantar instâncias de contêiner do Azure em uma rede virtual para que os contêineres possam acessar outros recursos privados ou outros serviços do Azure por meio de um ponto de extremidade privado do Azure. Para clientes que hospedam aplicativos Web, é uma prática comum usar um firewall de aplicativo Web, como o Gateway de Aplicativo do Azure, para antecipar o tráfego de entrada enquanto usa as Instâncias de Contêiner do Azure como um pool de back-end. Este artigo é um ótimo ponto de partida: expor um endereço IP estático para um grupo de contêineres.
Um desafio potencial com essa abordagem é usar um endereço IP privado não estático como um pool de back-end. O IP privado pode ser girado durante a manutenção, exigindo que o administrador da nuvem reconfigure manualmente o pool de back-end. Se novos contêineres forem adicionados para dimensionamento, o administrador também precisará fazer a reconfiguração para garantir que o tráfego seja roteado para o pool de back-end correto. E as sondas de vivacidade e de prontidão não são suportadas em grupos de contêineres, o que dificulta a identificação do tempo de inatividade da carga de trabalho.
Este artigo explora aprimoramentos para resolver esses problemas comuns por meio da adoção do Application Insights e do Azure Monitor para monitorar e usar o Azure Functions para executar a rotação automática de IPs privados. Essa abordagem melhora a redundância da carga de trabalho.
Potenciais casos de utilização
Esta arquitetura funciona melhor para:
- Implantação sem servidor.
- Operação mínima para uma carga de trabalho nativa da nuvem com automação.
- Uma carga de trabalho de contêiner simples que não requer orquestração avançada de contêineres.
- Uma carga de trabalho altamente redundante e voltada para o exterior com reconfiguração automatizada.
- Uma carga de trabalho de contêiner que requer acesso a recursos privados, como aqueles expostos por pontos de extremidade privados do Azure.
Arquitetura
Transfira um ficheiro do Visio desta arquitetura.
Fluxo de dados
Parte 1: Fluxo de tráfego típico de aplicativos Web
1 bis. O Application Gateway tem o recurso de firewall de aplicativos Web, que é ideal para frontar o tráfego voltado para o público antes que ele atinja a carga de trabalho de back-end. O Gateway de Aplicativo expõe o endereço IP público, portanto, a Proteção contra DDoS do Azure fornece outra camada de proteção.
1 ter. O pool de back-end do Gateway de Aplicativo é configurado com o endereço IP privado da instância de contêiner do Azure em um grupo de contêineres. As instâncias de contêiner do Azure em grupos de contêineres não vêm com FQDN (nomes de domínio totalmente qualificados), portanto, o endereço IP deve ser usado.
1 ter. Os contêineres nas Instâncias de Contêiner do Azure podem consumir recursos privados, como o Azure Cosmos DB, por meio de links privados.
Parte 2: Aprimoramentos com automação
2a. O Application Gateway inclui uma métrica de contagem de host íntegra que você pode usar como uma sonda de vivacidade para instâncias de contêiner do Azure, dado que os grupos de contêineres em Instâncias de Contêiner não oferecem suporte a testes de vivacidade ou prontidão.
2b. O Application Insights é usado em contêineres para coletar outras métricas, incluindo batimentos cardíacos, que podem ser enviadas ao Application Insights para monitoramento por meio de um thread personalizado.
2c. Você pode configurar alertas com base nos níveis de limite definidos nas etapas 2a e 2b. Por exemplo, suponha que seu sistema tenha três instâncias de contêiner em execução como um pool de back-end. Você pode configurar um alerta para disparar quando a contagem de hosts íntegros for inferior a 3. Em um grupo de ações de regras de alerta, você pode usar uma função do Azure como o tipo de ação para disparar a ação personalizada.
2 d. Na função do Azure, um SDK do Azure é usado para obter a configuração de instâncias de contêiner existentes e recriar as mesmas instâncias. Esta função é acionada pelo alerta definido na etapa 2c. Esta função pode levar muito tempo para ser executada, dependendo da complexidade da configuração. As funções do Azure podem atingir o tempo limite, para que possa utilizar as Funções Duráveis do Azure para lidar com processos de longa execução e obter atualizações de estado.
Componentes
Automatização
- Azure Durable Functions: Ao contrário do Azure Functions, o Durable Functions tem monitoração de estado e dá suporte a vários padrões de fluxo de trabalho com monitoração de estado. Neste exemplo, o padrão de monitor é usado.
- SDKs do Azure: os SDKs do Azure são coleções de bibliotecas que você pode usar para interagir com os serviços do Azure em sua linguagem de programação preferida. Os SDKs oferecem mais flexibilidade para integrar a lógica que executa a automação.
Monitorização
- Azure Monitor Metrics: este recurso do Azure Monitor coleta dados numéricos predefinidos dos serviços do Azure.
- Grupos de ações: um grupo de ações é uma coleção de preferências de notificação definidas pelo proprietário do recurso. Você pode definir canais de notificação e ações com base em alertas acionados.
Rede
- Proteção contra DDoS do Azure: a Proteção contra DDoS (Básica) do Azure é gratuita e habilitada em todos os IPs públicos. A Proteção de Rede DDoS do Azure fornece mais recursos, como a ingestão de logs para outros locais e a capacidade de envolver a equipe de Resposta Rápida de Proteção contra DDoS.
- Gateway de Aplicativo do Azure: o Firewall de Aplicativo Web do Azure fornece proteção para aplicativos voltados para o público contra explorações como injeção de SQL e ataques XSS.
- Azure Private Link: o Azure Private Link fornece acesso aos serviços PaaS do Azure por meio de um ponto de extremidade privado no backbone da Microsoft para aprimorar ainda mais a segurança de acesso à rede.
Aplicação
- Instâncias de Contêiner do Azure: as Instâncias de Contêiner do Azure executam imagens de contêiner sem a necessidade de configurar outra infraestrutura. Você deve considerar o Serviço Kubernetes do Azure (AKS) para orquestração avançada de contêineres.
- Azure Cosmos DB: O Azure Cosmos DB é um banco de dados NoSQL totalmente gerenciado que oferece suporte a várias plataformas, como SQL, Cassandra e MongoDB.
- Azure Key Vault: como prática recomendada de segurança, os desenvolvedores não armazenam cadeias de conexão como texto não criptografado no código-fonte do aplicativo. O Azure Key Vault serve como um local central para armazenar segredos com segurança aprimorada. Os aplicativos podem recuperar as chaves necessárias com segurança aprimorada.
Alternativas
O cenário anterior atualiza um pool de back-end para o Application Gateway. Como alternativa, você pode usar uma zona DNS privada do Azure como back-end de destino para o Application Gateway e usar as funções do Azure para atualizar um registro em vez de fazer alterações no Application Gateway. Essa alternativa reduziria o tempo de implantação. Por outro lado, as métricas do Application Gateway não seriam capazes de identificar a contagem de hosts porque ela seria abstraída pelo DNS. Portanto, essa automação precisaria ser acionada por meio de uma solução de monitoramento de aplicativos, como o Application Insights ou o Azure Monitor diretamente.
O Azure fornece várias opções para hospedar cargas de trabalho baseadas em contêiner, como o Serviço Kubernetes do Azure e o Serviço de Aplicativo do Azure.
O Serviço Kubernetes do Azure fornece recursos avançados de orquestração de contêiner e rede, como o recurso de Serviço, que não está disponível em Instâncias de Contêiner. Esta arquitetura de referência atende a esse requisito.
O Serviço de Aplicativo também pode hospedar cargas de trabalho de contêiner e o Ambiente do Serviço de Aplicativo permite que os desenvolvedores implantem o Serviço de Aplicativo na Rede Virtual do Azure. A estrutura de preços das Instâncias de Contêiner, em comparação com o Serviço de Aplicativo, a torna atraente para pequenas cargas de trabalho.
Considerações
Disponibilidade
Como os testes de animação e preparação não são suportados em grupos de contêineres, recomendamos que você use o Azure Monitor Metrics e o Azure Application Insights para monitoramento. A integridade e o tempo de atividade do contêiner não são abordagens determinísticas para determinar se um sistema está operando de ponta a ponta.
Operações
O Azure Durable Functions é usado para reconfigurar a infraestrutura se houver uma falha nas Instâncias de Contêiner ou se o IP privado de um grupo de contêineres for alterado. Conforme observado na documentação, o processo de provisionamento leva um pouco mais de tempo. Os usuários podem enfrentar um tempo de inatividade mínimo se os contêineres não estiverem prontos a tempo.
Esta arquitetura adiciona uma camada de resiliência. Mas ainda recomendamos que você configure o monitoramento no aplicativo e monitore o status do Azure para falhas na plataforma.
Escalabilidade
Os requisitos de CPU e memória são definidos quando os contêineres são criados, portanto, você não poderá executar o dimensionamento vertical diretamente. Você pode adicionar contêineres ao grupo de contêineres para dimensionar horizontalmente. Mas observe que cada contêiner no grupo de contêineres consumirá um IP privado, portanto, o limite seria o tamanho da sub-rede provisionada.
Outra consideração importante para o dimensionamento é o estado do aplicativo. O aplicativo precisa lidar com o estado, localmente ou usando serviços externos, como o Cache do Azure para Redis, para garantir que o dimensionamento sob demanda não crie perda de dados no aplicativo.
Segurança
A capacidade de implantar PaaS em uma rede virtual (injeção de VNet) não melhora a segurança se a configuração não estiver configurada corretamente. A injeção de VNet dá aos administradores mais controle de rede, fornecendo benefícios como grupos de segurança de rede mais rígidos e o uso de recursos não expostos publicamente.
O Private Link projeta um ponto de extremidade privado na rede virtual, o que permite que o aplicativo acesse o Azure PaaS diretamente por meio de um endereço IP privado. Ao mesmo tempo, os administradores podem controlar ainda mais quem pode acessar o PaaS do Azure relevante.
Se você armazenar imagens de contêiner no Registro de Contêiner do Azure, poderá habilitar o Microsoft Defender para registros de contêiner para executar verificações de vulnerabilidade de imagem de contêiner.
Implementar este cenário
O código-fonte de exemplo, com o Azure Functions executando automação, está disponível no GitHub.
Você precisará de uma entidade de serviço (ID do cliente e segredo). Ele será usado pelo Azure Functions para executar operações do Azure Resource Manager. Essa entidade de serviço requer pelo menos direitos de proprietário no grupo de recursos para que possa atualizar o Gateway de Aplicativo e criar instâncias de contêiner do Azure. O exemplo cria um aplicativo Python simples, conteinerizado e armazenado no Container Registry. Atualize o registo com a sua própria aplicação.
Preços
Use a calculadora de preços do Azure para estimar os custos dos recursos do Azure.
Veja este exemplo da implementação anterior.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Autor principal:
- Marcus Tee - Brasil | Estratégia Técnica & Roadmap
Próximos passos
- Arquitete aplicativos modernos no Azure
- Implementar segurança de rede no Azure
- Guia Detalhado da Computação sem Servidor do Azure
Recursos relacionados
Navegue pelas nossas arquiteturas:
Orientações relacionadas: