Implementar Microserviços em Aplicações de Contêiner do Azure

Este cenário mostra uma carga de trabalho existente originalmente concebida para Kubernetes, que foi replatformada para correr em Azure Container Apps. O Container Apps suporta cargas de trabalho brownfield onde as equipas querem simplificar a infraestrutura e a orquestração de contentores.

O exemplo de carga de trabalho é uma aplicação de microserviços containerizada. Reutiliza a mesma carga de trabalho definida na arquitetura de Microserviços no Azure Kubernetes Service (AKS). Esta arquitetura rehospeda a carga de trabalho nas Aplicações Container como plataforma de aplicação.

Arquitetura

Transfira um ficheiro do Visio desta arquitetura.

Os serviços que partilham o mesmo ambiente beneficiam das seguintes formas:

• Entrada interna e descoberta de serviços
• Um único espaço de trabalho do Log Analytics para registro em tempo de execução
• Um método de gestão segura para segredos e certificados

Fluxo de dados

1. Serviço de ingestão: Recebe pedidos de clientes, armazena-os em buffer e depois publica-os no Azure Service Bus. É o único ponto de entrada na carga de trabalho.

2. Serviço de fluxo de trabalho: Consome mensagens do Service Bus e despacha-as para microserviços subjacentes.

3. Serviço de pacotes: gerencia pacotes. O serviço mantém o seu próprio estado no Azure Cosmos DB.

4. Serviço de agendamento de drones: Programação drones e monitora drones em voo. O serviço mantém o seu próprio estado no Azure Cosmos DB.

5. Serviço de entrega: Gerir entregas programadas ou em trânsito. O serviço mantém o seu próprio estado no Azure Managed Redis.

6. Recuperação de segredos: Como é uma carga de trabalho existente, apenas alguns componentes acedem ao Azure Key Vault para obter segredos em tempo de execução. Os outros serviços recebem esses segredos do ambiente Container Apps.

7. Registos e métricas: O ambiente e todas as aplicações de contentores emitem logs e métricas que o Azure Monitor apresenta e depois recolhem e visualizam.

8. Imagens de contentores: As imagens dos contentores são retiradas do Azure Container Registry existente, que era anteriormente usado para o AKS, e implementadas no ambiente Container Apps.

Componentes

A carga de trabalho utiliza os seguintes serviços Azure em coordenação entre si:

• O Container Apps é uma plataforma serverless contentor que simplifica a orquestração e gestão de containers. Nessa arquitetura, o Container Apps serve como a principal plataforma de hospedagem para todos os microsserviços.

  As seguintes funcionalidades substituem muitas das capacidades da arquitetura AKS anterior:

  • Descoberta de serviço integrada
  • Endpoints geridos HTTP e HTTP/2
  • Balanceamento de carga integrado
  • Registos e monitorização
  • Dimensionamento automático baseado em tráfego HTTP ou eventos alimentados pelo KEDA (Event Driven Autoscaling) baseado em Kubernetes
  • Atualizações de aplicativos e controle de versão

• O Container Registry é um serviço gerido de registo para armazenar e gerir imagens privadas de contentores. Nesta arquitetura, é a fonte de todas as imagens de contentores que são implementadas no ambiente Container Apps. O registo é o mesmo usado na implementação do AKS.

• O Azure Cosmos DB é um serviço de base de dados distribuído globalmente, composto por múltiplos modelos. Nesta arquitetura, o serviço de agendamento de drones utiliza o Azure Cosmos DB como seu repositório de dados.

• O Azure DocumentDB é um serviço de base de dados totalmente gerido compatível com MongoDB para construir aplicações modernas. Nesta arquitetura, o serviço de pacotes utiliza o Azure DocumentDB como seu armazenamento de dados.

• Service Bus é um serviço de mensagens na cloud que oferece capacidades de comunicação assíncrona e integração híbrida. Nesta arquitetura, trata mensagens assíncronas entre o serviço de ingestão e o microserviço baseado em tarefas e fluxo de trabalho. O restante dos serviços na aplicação existente foi concebido para que outros serviços os possam invocar com pedidos HTTP.

• O Azure Managed Redis é um serviço de cache em memória. Nesta arquitetura, reduz a latência e melhora o débito dos dados de entrega frequentemente acedidos por drones.

• Key Vault é um serviço na cloud para armazenar e aceder de forma segura a segredos como chaves API, palavras-passe e certificados. Nesta arquitetura, o agendador de drones e os serviços de entrega utilizam identidades geridas atribuídas pelo utilizador para autenticar com o Key Vault e recuperar segredos necessários para os seus requisitos de execução.

• O Azure Monitor é uma solução abrangente de monitorização que recolhe e analisa dados de telemetria. Nessa arquitetura, ele coleta e armazena métricas e logs de todos os componentes do aplicativo por meio de um espaço de trabalho do Log Analytics. Utiliza-se estes dados para monitorizar a aplicação, configurar alertas e painéis, e realizar análises de causa raiz das falhas.

  • Application Insights é um serviço de gestão de desempenho de aplicações que oferece capacidades de monitorização extensíveis. Nesta arquitetura, cada serviço é instrumentado com o Application Insights SDK para monitorizar o desempenho da aplicação.

Alternativas

A arquitetura avançada de microserviços AKS descreve um cenário alternativo deste exemplo que utiliza Kubernetes.

Detalhes do cenário

Pode simplificar a implementação e gestão de contentores de microserviços utilizando Container Apps, um ambiente serverless para alojar aplicações containerizadas.

A Fabrikam, Inc., uma empresa fictícia, implementa uma carga de trabalho de entrega por drone onde os utilizadores pedem a um drone para recolher mercadorias para entrega. Quando um cliente agenda uma recolha, um sistema de back-end atribui um drone e notifica o utilizador com um tempo estimado de recolha.

O aplicativo de microsserviços foi implantado em um cluster AKS. Mas a equipa da Fabrikam não estava a tirar partido das funcionalidades avançadas ou específicas da plataforma do AKS. Eles migraram a aplicação para Aplicações Container, o que lhes permitiu realizar as seguintes ações:

• Utilize alterações mínimas no código ao mover a aplicação do AKS para as Aplicações Container. As alterações no código estavam relacionadas com bibliotecas de observabilidade que aumentavam logs e métricas com informação de nós do Kubernetes, que não são relevantes no ambiente novo.

• Implante a infraestrutura e a carga de trabalho com modelos Bicep: Nenhum manifesto YAML do Kubernetes era necessário para implantar seus contêineres de aplicativos.

• Expõe a aplicação através de entrada gerida. O suporte incorporado para entrada externa baseada em HTTPS para expor o serviço de ingestão eliminou a necessidade de configurar a sua própria entrada.

• Extrair imagens de contentores do Registo de Contentores. O Container Apps é compatível com qualquer imagem base Linux armazenada em qualquer repositório disponível.

• Use a funcionalidade de revisão para suportar as necessidades do ciclo de vida da aplicação. Podem executar múltiplas revisões de uma determinada aplicação container e dividir o tráfego entre elas para testes A/B ou cenários de implementação azul/verde.

• Use uma identidade gerida para autenticar com o Key Vault e o Container Registry.

Potenciais casos de utilização

Implante um aplicativo baseado em microsserviço brownfield em uma plataforma como serviço (PaaS) para simplificar o gerenciamento e evitar a complexidade da execução de um orquestrador de contêineres. A carga de trabalho brownfield poupou dinheiro ao usar esta arquitetura em vez da sua implementação no Kubernetes pelas seguintes razões:

• A escolha dos perfis de carga de trabalho
• Menos tempo gasto em tarefas operacionais do segundo dia para a equipa de operações
• A capacidade de evitar o excesso de provisionamento

Considere outros usos comuns das Aplicações Container:

• Executar cargas de trabalho containerizadas numa plataforma sem servidor (serverless) baseada no consumo.
• Aplicações autoescaláveis baseadas em tráfego HTTP ou HTTPS e disparadores orientados a eventos suportados pelo KEDA.
• Minimizar a sobrecarga de manutenção para aplicações contentorizadas.
• Implementar endpoints da API.
• Hospedar aplicações de processamento em segundo plano.
• Gerir o processamento orientado por eventos.

Optimizations

O objetivo da equipa de carga de trabalho é migrar a carga de trabalho existente para Aplicações Container com alterações mínimas no código. Mas deves fazer várias otimizações para melhorar a arquitetura e a implementação da carga de trabalho após a migração.

Melhorar a gestão de segredos

A carga de trabalho utiliza uma abordagem híbrida para gerir segredos. As identidades geridas aplicam-se apenas a serviços onde a mudança para identidades geridas não requer modificações no código. O agendador de drones e os serviços de entrega utilizam identidades geridas atribuídas pelo utilizador com o Key Vault para aceder a segredos armazenados. Os serviços restantes requerem alterações de código para adotarem identidades geridas, por isso esses serviços usam segredos fornecidos pelo ambiente Container Apps.

Uma abordagem melhor é atualizar todo o código para suportar identidades geridas, usando a aplicação ou identidade de trabalho em vez de segredos fornecidos pelo ambiente. Para mais informações sobre identidades de carga de trabalho, consulte Identidades geridas em Aplicações de Contentores.

Evite designs que exijam modo de revisão única

A aplicação de contentor de serviço de fluxo de trabalho funciona em modo de revisão singular. No modo de revisão única, a aplicação tem uma revisão suportada por zero ou mais réplicas. Uma réplica é composta pelo contentor de aplicação e quaisquer sidecars necessários. Este exemplo não usa sidecars, por isso cada réplica é um único contentor. O serviço de workflow não foi concebido para compatibilidade direta com esquemas de mensagens. Duas versões diferentes do serviço nunca deveriam funcionar em simultâneo.

Se o esquema de mensagens do Service Bus tiver de mudar, deve esvaziar o barramento antes de implementar a nova versão do serviço de fluxo de trabalho. Uma abordagem melhor é atualizar o código de serviço para compatibilidade futura e usar o modo multi-revisão para reduzir o tempo de inatividade associado ao esvaziamento das filas.

Considere o trabalho baseado no emprego

O serviço de fluxo de trabalho é executado como uma aplicação de contenedor de longa duração. Mas também pode executar como um trabalho em Aplicações de Contentor. Um trabalho é uma aplicação containerizada que começa a pedido, executa-se até à conclusão com base no trabalho disponível, depois desliga-se e liberta recursos. As tarefas podem ser mais económicas do que executar réplicas continuamente. Migrar o serviço para executar como um trabalho de Container Apps com base no trabalho disponível na fila pode ser uma opção prática. Depende do volume típico da fila e de quão finito, paralelizável e otimizado por recursos é escrito o serviço de workflow. Experimente e verifique para determinar a melhor abordagem.

Implementar controlo de entrada

A carga de trabalho utiliza a funcionalidade de entrada externa incorporada das Aplicações Container para expor o serviço de ingestão. A abordagem de controlo de entrada não permite posicionar completamente o seu ponto de entrada atrás de um firewall de aplicações web (WAF) nem incluí-lo nos planos de Proteção DDoS do Azure. Tens de colocar um WAF para todas as cargas de trabalho voltadas para a web. Para conseguir esta configuração no ambiente Container Apps, deve desativar a entrada pública incorporada e adicionar Application Gateway ou Azure Front Door.

Modernizar com Dapr

Pode modernizar ainda mais a carga de trabalho integrando com o Distributed Application Runtime (Dapr). Adiciona abstração entre código de carga de trabalho e armazenamentos de estados, sistemas de mensagens e mecanismos de descoberta de serviços. Para mais informações, consulte Implementar microserviços com Aplicações Container e Dapr. Se a tua carga de trabalho no Kubernetes já usa Dapr ou escaladores KEDA comuns, migrar para Aplicações Container é muitas vezes simples e pode manter essa capacidade.

Migrar para autenticação e autorização do utilizador

A carga de trabalho não delega autorização a uma porta de acesso. O serviço de ingestão trata da autorização dos seus clientes. Uma abordagem melhor é transferir esta responsabilidade para a funcionalidade de autenticação e autorização incorporada, frequentemente referida como Autenticação Fácil. Esta alteração aproveita as capacidades da plataforma e reduz o código personalizado no microserviço de ingestão.

Considerações

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

Fiabilidade

A fiabilidade ajuda a garantir que a sua aplicação cumpre os compromissos que assume para com os seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para Confiabilidade.

O Container Apps ajuda-o a implementar, gerir, manter e monitorizar as aplicações na carga de trabalho. Pode melhorar a fiabilidade seguindo as recomendações principais. Algumas recomendações são implementadas durante a migração a partir do Kubernetes.

• As revisões ajudam a implantar atualizações de aplicativos sem tempo de inatividade. Pode usar revisões para gerir a implementação de atualizações de aplicações e dividir o tráfego entre as revisões para suportar implementações azuis/verdes e testes A/B.

• Com as funcionalidades de observabilidade das Aplicações Container, tens acesso aos componentes que correm dentro do ambiente. O Container Apps integra-se com o Application Insights e o Log Analytics. Utiliza estes dados para acompanhar operações e definir alertas com base em métricas e eventos como parte do seu sistema de observabilidade.

  A monitorização de desempenho ajuda-te a avaliar a aplicação sob carga. Métricas e registos fornecem dados para reconhecer tendências, investigar falhas e realizar análises da causa raiz.

• Use verificações de saúde e prontidão para gerir contentores que arrancam lentamente e evitar enviar tráfego antes de estarem prontos. A implementação do Kubernetes inclui estes endpoints. Continue a usá-los se fornecerem sinais eficazes.

• Quando um serviço termina inesperadamente, o Container Apps reinicia-o automaticamente. A descoberta de serviços é ativada para que o serviço de fluxo de trabalho possa descobrir os seus microserviços a jusante. Use políticas de resiliência para gerir os timeouts e introduza lógica de disjuntores sem necessidade de ajustar mais o código.

• Permitir regras de autoescalonamento para satisfazer a procura à medida que o tráfego e as cargas de trabalho aumentam.

• Utilize as funcionalidades dinâmicas de balanceamento de carga e escalabilidade das Aplicações Container para melhorar a disponibilidade. Superdimensione a sub-rede do seu ambiente para que tenha sempre endereços IP suficientes disponíveis para futuras réplicas ou trabalhos.

• Evite armazenar o estado diretamente no ambiente Container Apps, porque todo o estado se perde quando a réplica desliga. Externalize o estado para um armazenamento de estado dedicado para cada microserviço. Esta arquitetura distribui o estado por três lojas distintas: Azure Managed Redis, Azure Cosmos DB para NoSQL e Azure DocumentDB.

• Implemente todos os recursos, incluindo Aplicações Container, utilizando uma topologia multizona. Para mais informações, consulte Suporte a zonas de disponibilidade em Aplicações de Contentores.

  Defina o número mínimo de réplicas para aplicações não transitórias em pelo menos uma réplica para cada zona de disponibilidade. Durante as condições típicas de funcionamento, as réplicas são distribuídas e equilibradas de forma fiável entre as zonas de disponibilidade da região.

Segurança

A segurança fornece garantias contra ataques deliberados e o uso indevido de seus valiosos dados e sistemas. Para obter mais informações, consulte Lista de verificação de revisão de design parade segurança .

Segredos

• Seu aplicativo de contêiner pode armazenar e recuperar valores confidenciais como segredos. Depois de definir um segredo para a aplicação container, ele está disponível para uso pela aplicação e por quaisquer regras de escala associadas. Se você estiver executando no modo de várias revisões, todas as revisões compartilham os mesmos segredos. Como os segredos são considerados alterações no âmbito da aplicação, se alterar o valor de um segredo, não é criada uma nova revisão. Mas para que quaisquer revisões em execução carreguem o novo valor secreto, tens de as reiniciar. Nesse cenário, os valores das variáveis de aplicativo e ambiente são usados.

• Reescrever o código do serviço para usar a identidade gerida da aplicação para autenticar dependências em vez de segredos pré-partilhados. Todas as dependências têm SDKs que suportam autenticação de identidade gerida.

• Pode armazenar valores sensíveis de forma segura em variáveis de ambiente ao nível da aplicação. Quando as variáveis do ambiente mudam, a aplicação do contentor cria uma nova revisão.

Segurança da rede

• Para limitar o acesso externo, apenas o serviço de ingestão está configurado para entrada externa. Os serviços de back-end só podem ser acedidos através da rede virtual interna no ambiente Container Apps e estão configurados como modo interno. Só expõe serviços à internet quando necessário.

  Como esta arquitetura utiliza a funcionalidade de entrada externa incorporada, esta solução não permite posicionar completamente o seu ponto de entrada atrás de um WAF ou incluí-lo em planos de proteção DDoS. Coloque todas as cargas de trabalho voltadas para a web atrás de um firewall de aplicações web. Para mais informações sobre melhorias de entrada, veja Implementar controlo de entrada.

• Quando cria um ambiente, pode fornecer uma rede virtual personalizada. Caso contrário, a Microsoft gera e gere automaticamente uma rede virtual. Não é possível manipular essa rede virtual gerenciada pela Microsoft, por exemplo, adicionando NSGs (grupos de segurança de rede) ou forçando o tráfego de encapsulamento a um firewall de saída. O exemplo utiliza uma rede virtual gerada automaticamente, mas uma rede virtual personalizada melhora o controlo de segurança. Uma rede personalizada permite aplicar NSGs e roteamento baseado em rotas definidas pelo utilizador (UDR) através do Azure Firewall.

Para mais informações sobre opções de topologia de rede, incluindo suporte a endpoints privados para entradas, consulte Arquitetura de rede em Aplicações de Contentores.

Identidades de carga de trabalho

• O Container Apps suporta identidades geridas Microsoft Entra que permitem que a sua aplicação se autentique a outros recursos protegidos pelo Microsoft Entra ID, como o Key Vault, sem gerir credenciais na sua aplicação container. Uma aplicação de contentores pode usar identidades atribuídas pelo sistema, identidades atribuídas pelo utilizador, ou ambas. Para serviços que não suportam autenticação Microsoft Entra ID, armazene segredos no Key Vault e use uma identidade gerida para aceder aos segredos.

• Use uma identidade gerida dedicada e atribuída pelo utilizador para o acesso ao Registo de Contentores. O Container Apps suporta o uso de uma identidade gerida diferente para a operação da carga de trabalho do que para o acesso ao registo de contentores. Esta abordagem proporciona controlo de acesso granular. Se a tua carga de trabalho tiver múltiplos ambientes de Aplicações Container, não partilhes a identidade entre instâncias.

• Utilize identidades geridas atribuídas pelo sistema para as identidades da carga de trabalho, de modo a ligar o ciclo de vida da identidade ao ciclo de vida do componente da carga de trabalho.

Mais recomendações de segurança

• A implementação do Kubernetes desta carga de trabalho oferece proteção ao utilizar funcionalidades do Microsoft Defender para Containers. Nesta arquitetura, o Defender for Containers avalia apenas a vulnerabilidade dos contentores no seu Registo de Contentores. O Defender for Containers não oferece proteção em tempo de execução para Aplicações de Container. Avalie a possibilidade de complementar com soluções de segurança não Microsoft se a proteção em tempo de execução for um requisito.

• Não execute a carga de trabalho num ambiente de Aplicações de Contentores partilhado. Segmente-o de outras cargas de trabalho ou componentes que não precisem de acesso a estes microserviços. Crie ambientes separados para Aplicações em Contentores. Aplicações e trabalhos que correm num ambiente de Aplicações Container podem descobrir e aceder a qualquer serviço que corra no ambiente com entrada interna ativada.

Otimização de Custos

A Otimização de Custos concentra-se em formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de projeto para Otimização de custos.

• Veja um exemplo de estimativa de preço para a carga de trabalho. Usa o calculador de preços do Azure. As configurações variam, por isso ajusta para o teu cenário.

• Neste cenário, Azure Cosmos DB, Azure Managed Reddis e Service Bus Premium são os principais fatores de custo.

• Para contentores que normalmente consomem pouca CPU e memória, avalie primeiro o perfil de carga de trabalho de consumo. Estima o custo do perfil de consumo com base no teu consumo para ajudar a recolher dados de custo de referência e avaliar outros perfis. Por exemplo, pode usar um perfil de carga de trabalho dedicado para componentes que têm um uso altamente previsível e estável e que podem partilhar nós dedicados. Para otimização de custos, mantenha um múltiplo de três nós de computação para cada perfil dedicado, de modo a garantir suficientes hosts de computação, bem como a distribuição de réplicas pelas zonas de disponibilidade.

• Elimine os custos de computação durante períodos de inatividade, garantindo que os componentes possam escalar até zero para que só pague quando necessário. Esta abordagem reduz as despesas das aplicações com uso variável ou pouco frequente. Os exames de integridade tipicamente impedem o escalonamento completo até zero. Na arquitetura, pode reimplementar o serviço de workflow como uma tarefa para tirar partido do scale-to-zero durante os períodos de inatividade. Esta abordagem combina bem com cargas de trabalho que podem beneficiar de um plano de consumo.

• Para evitar cobranças de rede entre regiões, implemente todos os componentes, como os estados de armazenamento e o registo de contentores, na mesma região.

Excelência Operacional

A Excelência Operacional abrange os processos operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Lista de verificação de revisão de projeto para o Operational Excellence.

• Use a integração com GitHub Actions ou Azure Pipelines para configurar pipelines automatizados de integração contínua e implementação contínua (CI/CD).

• Use o modo de múltiplas revisões com divisão de tráfego para testar alterações no código da carga de trabalho e nas regras de escala.

• Integre com Application Insights e Log Analytics para fornecer informações sobre a sua carga de trabalho. Use o mesmo espaço de trabalho de Log Analytics que os restantes componentes da sua carga de trabalho para manter todos os insights da carga de trabalho juntos.

• Use infraestrutura como código (IaC), como Bicep ou Terraform, para gerir todas as implementações de infraestrutura. As implementações incluem o ambiente de Container Apps, o registo de contentores e os repositórios de estado de microserviços. Separe os pipelines de implementação de microserviços dos pipelines de infraestrutura porque muitas vezes não partilham um ciclo de vida semelhante. O seu pipeline declarativo para a infraestrutura da Azure deve desplegar todos os recursos exceto os recursos da aplicação de contentores.

• Use uma abordagem imperativa para criar, atualizar e remover aplicações de contentores do ambiente. É especialmente importante se estiver a ajustar dinamicamente a lógica de redirecionamento de tráfego entre as revisões. Use uma ação do GitHub ou uma tarefa Azure Pipelines nos seus fluxos de trabalho de implementação. Esta abordagem imperativa pode basear-se nas definições de aplicações YAML . Para minimizar falhas nas verificações de saúde, certifique-se sempre de que o seu pipeline preenche o registo do contentor com a nova imagem do contentor antes de implementar a aplicação do contentor.

  Uma mudança importante em relação à implementação do Kubernetes é a transição da gestão de ficheiros de manifestos Kubernetes, como a definição Deployment de objetos Kubernetes. O Kubernetes fornece uma abordagem atómica de sucesso conjunto ou falha em conjunto para a implementação de microserviços, com este objeto manifesto. Nas Aplicações Container, cada microserviço é implementado de forma independente. Os seus pipelines de implementação passam a ser responsáveis por orquestrar qualquer estratégia de sequenciação e rollback necessária para garantir uma implementação segura.

Eficiência de desempenho

A Eficiência de Desempenho refere-se à capacidade da sua carga de trabalho de escalar para atender às demandas dos usuários de forma eficiente. Para obter mais informações, consulte Lista de verificação de revisão de design para Eficiência de desempenho.

• A carga de trabalho é distribuída entre vários aplicativos de microsserviço.

• Cada microserviço é independente e não partilha estado com outros microserviços, o que permite uma escalabilidade independente.

• Use tarefas de Container Apps para execuções finitas de processos para implementar runtimes transitórios e reduzir o consumo de recursos para serviços inativos. Avalie as implicações de desempenho de iniciar e parar trabalhos em comparação com manter componentes ativos e prontos para uso.

• O autoescalonamento está ativado. Prefira escalabilidade baseada em eventos em vez de métrica, sempre que possível. Por exemplo, o serviço de workflow, se concebido para o suportar, poderia escalar com base na profundidade da fila do Service Bus. O autoescalador padrão baseia-se em pedidos HTTP. Durante uma migração de plataforma, é importante começar com a mesma abordagem de escalabilidade e, posteriormente, avaliar ajustes de escalabilidade.

• Os pedidos são dinamicamente balanceados para réplicas disponíveis de uma revisão.

• Métricas, incluindo utilização da CPU, memória, informação de largura de banda e armazenamento, estão disponíveis através do Azure Monitor.

Implementar este cenário

Siga os passos do README.md no repositório de cenários de exemplo Container Apps.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Contribuidores:

• Julien Strebler | Arquiteto de Soluções Cloud
• Steve Caravajal | Arquiteto de Soluções Cloud
• Simon Kurtz | Arquiteto de Soluções Cloud

Próximos passos

• Documentação de Container Apps

Recursos relacionados

• Estilo de arquitetura de microsserviços
• Conceber uma arquitetura de microsserviços
• Construa um pipeline CI/CD para aplicações AKS usando Azure Pipelines
• Arquitetura avançada de microsserviços AKS