Compartilhar via

Implantar microsserviços nos Aplicativos de Contêiner do Azure

Aplicativos de Contêiner do Azure
Azure Cosmos DB
Barramento de Serviço do Azure

Esse cenário mostra uma carga de trabalho existente originalmente projetada para o Kubernetes, que é replatformada para ser executada nos Aplicativos de Contêiner do Azure. Os Aplicativos de Contêiner dão suporte a cargas de trabalho brownfield em que as equipes desejam simplificar a infraestrutura e a orquestração de contêineres.

A carga de trabalho de exemplo é um aplicativo de microsserviços em contêineres. Ele reutiliza a mesma carga de trabalho definida na arquitetura de Microsserviços no AKS (Serviço de Kubernetes do Azure). Essa arquitetura realoca a carga de trabalho no Container Apps como sua plataforma de aplicações.

Importante

Essa arquitetura se concentra em minimizar as alterações de código do aplicativo e abordar a transição do AKS para os Aplicativos de Contêiner como uma migração de plataforma. A meta é replicar a implementação existente e adiar otimizações de código ou infraestrutura que possam comprometer a migração.

Para uma carga de trabalho em ambiente greenfield, consulte Implantar microsserviços usando Aplicativos de Contêiner e Dapr.

Dica

Uma implementação de exemplo dá suporte a essa arquitetura e ilustra algumas das opções de design descritas neste artigo.

Arquitetura

Diagrama que mostra a arquitetura de runtime da solução.

Baixe um Arquivo Visio dessa arquitetura.

Os serviços que compartilham o mesmo ambiente se beneficiam das seguintes maneiras:

  • Entrada interna e descoberta de serviço
  • Um único espaço de trabalho do Log Analytics para registro em log de runtime
  • Um método de gerenciamento seguro para segredos e certificados

Fluxo de dados

  1. Serviço de ingestão: Recebe solicitações de cliente, faz buffers e as publica no Barramento de Serviço do Azure. É o único ponto de entrada na carga de trabalho.

  2. Serviço de fluxo de trabalho: Consome mensagens do Barramento de Serviço e as envia para os microsserviços subjacentes.

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

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

  5. Serviço de entrega: Gerencia entregas agendadas ou em trânsito. O serviço mantém seu próprio estado no Redis Gerenciado do Azure.

  6. Recuperação de segredos: Como é uma carga de trabalho existente, apenas alguns componentes acessam o Azure Key Vault para obter segredos de runtime. Os outros serviços recebem esses segredos do ambiente de Aplicativos de Contêiner.

  7. Logs e métricas: O ambiente e todos os aplicativos de contêiner emitem logs e métricas que o Azure Monitor coleta e visualiza.

  8. Imagens de contêiner: As imagens de contêiner são extraídas do Registro de Contêiner do Azure existente que foi usado anteriormente para o AKS e implantado no ambiente de Aplicativos de Contêiner.

Componentes

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

  • Os Aplicativos de Contêiner são uma plataforma de contêiner sem servidor que simplifica a orquestração e o gerenciamento de contêineres. Nessa arquitetura, os Aplicativos de Contêiner servem como a principal plataforma de hospedagem para todos os microsserviços.

    Os recursos a seguir substituem muitos dos recursos da arquitetura anterior do AKS:

    • Descoberta de serviço interna
    • Pontos de extremidade HTTP e HTTP/2 gerenciados
    • Balanceamento de carga integrado
    • Log e monitoramento
    • Dimensionamento automático com base no tráfego HTTP ou eventos alimentados pelo KEDA (Dimensionamento Automático Controlado por Eventos) baseado em Kubernetes
    • Atualizações de aplicativo e controle de versão

  • O Registro de Contêiner é um serviço de registro gerenciado para armazenar e gerenciar imagens de contêiner privado. Nessa arquitetura, trata-se da fonte de todas as imagens de contêiner que são implantadas no ambiente dos Aplicativos de Contêiner. O registro é o mesmo usado na implementação do AKS.

  • O Azure Cosmos DB é um serviço de banco de dados de vários modelos distribuído globalmente. Nessa arquitetura, o serviço de agendador de drones usa o Azure Cosmos DB como seu armazenamento de dados.

  • O Azure DocumentDB é um serviço de banco de dados totalmente gerenciado compatível com o MongoDB para a criação de aplicativos modernos. Nessa arquitetura, o serviço de pacote usa o Azure DocumentDB como seu armazenamento de dados.

  • Service Bus é um serviço de mensagens na nuvem que fornece recursos de comunicação assíncrona e integração híbrida. Nessa arquitetura, ele lida com mensagens assíncronas entre o serviço de ingestão e o microsserviço de fluxo de trabalho baseado em tarefa. O restante dos serviços no aplicativo existente foi projetado para que outros serviços possam invocá-los com solicitações HTTP.

  • O Redis Gerenciado do Azure é um serviço de cache na memória. Nessa arquitetura, ela reduz a latência e melhora a taxa de transferência para dados de entrega de drones acessados com frequência.

  • O Key Vault é um serviço de nuvem para armazenar e acessar segredos com segurança, como chaves de API, senhas e certificados. Nessa arquitetura, o agendador de drones e os serviços de entrega usam identidades gerenciadas atribuídas pelo usuário para autenticar com o Key Vault e recuperar segredos necessários para seus requisitos de runtime.

  • O Azure Monitor é uma solução de monitoramento abrangente que coleta 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 workspace do Log Analytics. Você usa esses dados para monitorar o aplicativo, configurar alertas e dashboards e executar a análise de causa raiz de falhas.

    • O Application Insights é um serviço de gerenciamento de desempenho de aplicativos que fornece recursos extensíveis de monitoramento. Nessa arquitetura, cada serviço é instrumentado com o SDK do Application Insights para monitorar o desempenho do aplicativo.

Alternativas

A arquitetura avançada de microsserviços do AKS descreve um cenário alternativo deste exemplo que usa o Kubernetes.

Detalhes do cenário

Você pode simplificar a implantação e o gerenciamento de contêineres de microsserviço usando Aplicativos de Contêiner, um ambiente sem servidor para hospedar aplicativos em contêineres.

A Fabrikam, Inc., uma empresa fictícia, implementa uma carga de trabalho de entrega de drones onde os usuários solicitam um drone para pegar mercadorias para entrega. Quando um cliente agenda uma retirada, um sistema de back-end atribui um drone e notifica o usuário com uma hora de retirada estimada.

O aplicativo de microsserviços foi implantado em um cluster do AKS. Mas a equipe da Fabrikam não estava aproveitando os recursos avançados ou específicos da plataforma do AKS. Eles migraram o aplicativo para Container Apps, o que lhes permitiu realizar as seguintes ações:

  • Empregue alterações mínimas de código ao mover o aplicativo do AKS para os Aplicativos de Contêiner. As alterações de código estavam relacionadas a bibliotecas de observabilidade que enriqueceram logs e métricas com informações de nó do Kubernetes, as quais não são relevantes no novo ambiente.

  • Implantar a infraestrutura e a carga de trabalho com modelos do Bicep: nenhum manifesto YAML do Kubernetes foi necessário para implantar os contêineres de aplicativos.

  • Exponha o aplicativo por meio da entrada gerenciada. O suporte interno para entrada externa baseada em HTTPS para expor o serviço de ingestão removeu a necessidade de configurar sua própria entrada.

  • Baixar imagens de contêiner do Registro de Contêiner. Os Aplicativos de Contêiner são compatíveis com qualquer imagem base do Linux armazenada em qualquer repositório disponível.

  • Use o recurso de revisão para dar suporte às necessidades do ciclo de vida do aplicativo. Eles podem executar várias revisões de um aplicativo de contêiner específico e dividir o tráfego entre eles para testes A/B ou cenários de implantação azul/verde.

  • Use uma identidade gerenciada para autenticar com o Key Vault e o Registro de Contêiner.

Possíveis casos de uso

Implante um aplicativo baseado em microsserviço brownfield em uma plataforma como serviço (PaaS) para simplificar o gerenciamento e evitar a complexidade de executar um orquestrador de contêineres. A carga de trabalho brownfield economizou dinheiro usando essa arquitetura em vez da sua implantação em Kubernetes pelas seguintes razões:

  • A escolha dos perfis de carga de trabalho
  • Menos tempo gasto em tarefas operacionais do dia 2 para a equipe de operações
  • A capacidade de evitar o superdimensionamento

Observação

Nem todas as cargas de trabalho geram essa economia de custos.

Considere outros usos comuns de Aplicativos de Contêiner:

  • Execute cargas de trabalho em contêineres em uma plataforma baseada em consumo sem servidor.
  • Aplicativos de dimensionamento automático com base no tráfego HTTP ou HTTPS e gatilhos controlados por eventos compatíveis com KEDA.
  • Minimize a sobrecarga de manutenção para aplicativos em contêineres.
  • Implantar endpoints de API.
  • Hospedar aplicativos de processamento em segundo plano.
  • Lidar com o processamento dirigido por eventos.

Optimizations

A meta da equipe de carga de trabalho é migrar a carga de trabalho existente para Aplicativos de Contêiner com alterações mínimas de código. Mas você deve fazer várias otimizações para melhorar a arquitetura e a implementação da carga de trabalho após a migração.

Melhorar o gerenciamento de segredo

A carga de trabalho usa uma abordagem híbrida para gerenciar segredos. As identidades gerenciadas se aplicam somente aos serviços em que alternar para identidades gerenciadas não requer modificações de código. O agendador de drones e os serviços de entrega empregam identidades gerenciadas atribuídas pelo usuário com o Key Vault para acessar segredos armazenados. Os serviços restantes exigem alterações de código para adotar identidades gerenciadas, de modo que esses serviços usem segredos fornecidos pelo ambiente de Aplicativos de Contêiner.

Uma abordagem melhor é atualizar todo o código para dar suporte a identidades gerenciadas usando o aplicativo ou a identidade do trabalho em vez de segredos fornecidos pelo ambiente. Para obter mais informações sobre identidades de carga de trabalho, consulte Identidades gerenciadas em Aplicativos de Contêiner.

Evitar designs que exijam modo de revisão única

O aplicativo de contêiner do serviço de fluxo de trabalho é executado no modo de revisão única. No modo de revisão única, o aplicativo tem uma revisão apoiada por zero ou mais réplicas. Uma réplica é composta pelo contêiner do aplicativo e quaisquer sidecars necessários. Este exemplo não usa sidecars, portanto, cada réplica é um único contêiner. O serviço de fluxo de trabalho não foi projetado para compatibilidade futura com os esquemas de mensagem. Duas versões diferentes do serviço nunca devem ser executadas simultaneamente.

Se o esquema de mensagens do Barramento de Serviço precisar ser alterado, você deverá esvaziar o barramento antes de implantar 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 de múltiplas revisões para minimizar a indisponibilidade associada ao esvaziamento de filas.

Considere o trabalho baseado em tarefas

O serviço de fluxo de trabalho é implementado como um aplicativo de contêiner de execução longa. Mas também pode ser executado como uma tarefa em aplicativos de contêiner. Um job é um aplicativo em contêiner que é iniciado sob demanda, executa até ser concluído de acordo com o trabalho disponível, e depois é finalizado e libera recursos. Os trabalhos podem ser mais econômicos do que as réplicas em execução contínua. Migrar o serviço para ser executado como um trabalho de Container Apps, baseado no trabalho disponível na fila, pode ser uma opção prática. Depende do volume de fila típico e de quão finito, paralelizável e otimizado em termos de recursos o serviço de fluxo de trabalho é escrito. Experimente e verifique para determinar a melhor abordagem.

Implementar controle de entrada

A carga de trabalho usa o recurso embutido de entrada externa do Container Apps para expor o serviço de ingestão. A abordagem de controle de entrada não fornece a capacidade de posicionar completamente seu ponto de entrada atrás de um WAF (firewall de aplicativo Web) ou incluí-lo nos planos de Proteção contra DDoS do Azure. Você precisa proteger todas as cargas de trabalho voltadas para a web usando um WAF. Para obter essa configuração no ambiente de Aplicativos de Contêiner, desabilite a entrada pública incorporada e adicione o Gateway de Aplicativo ou o Azure Front Door.

Observação

Os gateways exigem verificações de integridade significativas, que mantêm o serviço de ingresso ativo e impedem que ele seja dimensionado para zero.

Modernize utilizando o Dapr

Você pode modernizar ainda mais a carga de trabalho integrando-se ao Dapr (Distributed Application Runtime). Ele adiciona abstração entre o código de carga de trabalho e repositórios de estado, sistemas de mensagens e mecanismos de descoberta de serviço. Para obter mais informações, consulte Implantar microsserviços com Aplicativos de Contêiner e Dapr. Se sua carga de trabalho no Kubernetes já usa Dapr ou dimensionadores KEDA comuns, a migração para Container Apps normalmente é simples e permite manter essa capacidade.

Migrar para autenticação e autorização do usuário

A carga de trabalho não delega a autorização para um gateway. O serviço de ingestão gerencia a autorização dos clientes. Uma abordagem melhor é descarregar essa responsabilidade para o recurso de autenticação e autorização interno, geralmente conhecido como Autenticação Fácil. Essa alteração aproveita os recursos da plataforma e reduz o código personalizado no microsserviço de ingestão.

Considerações

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

Confiabilidade

A confiabilidade ajuda a garantir que seu aplicativo possa cumprir os compromissos que você faz com seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design parade confiabilidade.

Os Aplicativos de Contêiner ajudam você a implantar, gerenciar, manter e monitorar os aplicativos na carga de trabalho. Você pode melhorar a confiabilidade seguindo as principais recomendações. Algumas recomendações são implementadas durante a migração do Kubernetes.

  • As revisões ajudam a implantar atualizações de aplicativos sem tempo de inatividade. Você pode usar revisões para gerenciar a implantação de atualizações de aplicativos e dividir o tráfego entre as revisões para dar suporte a implantações azul/verde e testes A/B.

  • Com os recursos de observabilidade dos Aplicativos de Contêiner, você tem informações sobre os componentes executados dentro do ambiente. Os Aplicativos de Contêiner se integram ao Application Insights e ao Log Analytics. Você usa esses dados para acompanhar as operações e definir alertas com base em métricas e eventos como parte do seu sistema de observabilidade.

    O monitoramento de desempenho ajuda você a avaliar o aplicativo sob carga. As métricas e os logs fornecem dados para reconhecer tendências, investigar falhas e executar a análise de causa raiz.

  • Use sondas de integridade e prontidão para lidar com contêineres de inicialização lenta e evitar enviar tráfego antes que estejam prontos. A implementação do Kubernetes inclui esses pontos de extremidade. Continue usando-os se eles fornecerem sinais eficazes.

  • Quando um serviço é encerrado inesperadamente, os Aplicativos de Contêiner o reiniciam automaticamente. A descoberta de serviço está habilitada para que o serviço de fluxo de trabalho possa descobrir seus microsserviços downstream. Use políticas de resiliência para lidar com tempos limite e introduzir lógica de disjuntor sem a necessidade de ajustar ainda mais o código.

  • Habilite as regras de dimensionamento automático para atender à demanda à medida que o tráfego e as cargas de trabalho aumentam.

  • Use os recursos dinâmicos de balanceamento de carga e dimensionamento de Aplicativos de Contêiner para melhorar a disponibilidade. Provisione em excesso a sub-rede do ambiente para que ela sempre tenha endereços IP disponíveis suficientes para futuras réplicas ou tarefas.

  • Evite armazenar informações de estado diretamente no ambiente do Container Apps, pois todas as informações de estado são perdidas quando a réplica é desligada. Externalize o estado para um repositório de estado dedicado para cada microsserviço. Essa arquitetura distribui o estado em três repositórios distintos: Redis Gerenciados do Azure, Azure Cosmos DB para NoSQL e Azure DocumentDB.

  • Implante todos os recursos, incluindo Aplicativos de Contêiner, usando uma topologia de várias zonas. Para obter mais informações, consulte o suporte à zona de disponibilidade em Aplicativos de Contêiner.

    Defina a contagem mínima de réplicas para aplicativos nãotransientes como pelo menos uma réplica para cada zona de disponibilidade. Durante as condições operacionais típicas, as réplicas são distribuídas de forma confiável e equilibradas entre zonas de disponibilidade na 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

  • O aplicativo de contêiner pode armazenar e recuperar valores confidenciais, como segredos. Depois de definir um segredo para o aplicativo de contêiner, ele estará disponível para uso pelo aplicativo e quaisquer regras de escala associadas. Se você estiver executando no modo de várias revisões, todas as revisões compartilharão os mesmos segredos. Como os segredos são considerados alterações no escopo do aplicativo, se você alterar o valor de um segredo, uma nova revisão não será criada. No entanto, para que as revisões em execução carreguem o novo valor secreto, você precisa reiniciá-las. Nesse cenário, são usados valores de variáveis de aplicativo e de ambiente.

  • Reescreva o código do serviço para utilizar a identidade gerenciada do próprio aplicativo a fim de autenticar as dependências em vez de usar segredos pré-compartilhados. Todas as dependências têm SDKs que dão suporte à autenticação de identidade gerenciada.

  • Você pode armazenar com segurança valores confidenciais em variáveis de ambiente no nível do aplicativo. Quando as variáveis de ambiente são alteradas, o aplicativo de contêiner cria uma nova revisão.

Segurança de rede

  • Para limitar o acesso externo, somente o serviço de ingestão é configurado para entrada externa. Os serviços de back-end só podem ser acessados por meio da rede virtual interna no ambiente de Aplicativos de Contêiner e são configurados como modo interno. Exponha apenas os serviços à Internet quando necessário.

    Como essa arquitetura usa o recurso interno de entrada externa, essa solução não fornece a capacidade de posicionar completamente seu ponto de entrada atrás de um WAF ou incluí-lo em planos de Proteção contra DDoS. Coloque na frente de todas as cargas de trabalho voltadas para a web um firewall de aplicação web. Para obter mais informações sobre melhorias de ingresso, consulte Implementar controle de ingressos.

  • Ao criar um ambiente, você pode fornecer uma rede virtual personalizada. Caso contrário, a Microsoft gera e gerencia automaticamente uma rede virtual. Você não pode manipular essa rede virtual gerenciada pela Microsoft, por exemplo, adicionando NSGs (grupos de segurança de rede) ou forçando o tráfego de túnel para um firewall de saída. O exemplo usa uma rede virtual gerada automaticamente, mas uma rede virtual personalizada melhora o controle de segurança. Uma rede personalizada permite aplicar NSGs e roteamento baseado em UDR (rota definida pelo usuário) por meio do Firewall do Azure.

Para obter mais informações sobre opções de topologia de rede, incluindo suporte de ponto de extremidade privado para entrada, consulte a arquitetura de rede em Aplicativos de Contêiner.

Identidades de carga de trabalho

  • Os Aplicativos de Contêiner dão suporte a identidades gerenciadas do Microsoft Entra que permitem que seu aplicativo se autentique em outros recursos protegidos pela ID do Microsoft Entra, como o Key Vault, sem gerenciar credenciais em seu aplicativo de contêiner. Um aplicativo de contêiner pode usar identidades atribuídas pelo sistema, identidades atribuídas pelo usuário ou ambas. Para serviços que não dão suporte à autenticação da ID do Microsoft Entra, armazene segredos no Key Vault e use uma identidade gerenciada para acessar os segredos.

  • Use uma identidade gerenciada dedicada atribuída pelo usuário para acesso ao Registro de Contêiner. Os Aplicativos de Contêiner dão suporte ao uso de uma identidade gerenciada diferente para a operação de carga de trabalho do que para o acesso ao registro de contêiner. Essa abordagem fornece controle de acesso granular. Se sua carga de trabalho tiver vários ambientes de Aplicativos de Contêiner, não compartilhe a identidade entre instâncias.

  • Use identidades gerenciadas atribuídas pelo sistema para identidades de carga de trabalho para vincular o ciclo de vida da identidade ao ciclo de vida do componente de carga de trabalho.

Mais recomendações de segurança

  • A implementação do Kubernetes dessa carga de trabalho fornece proteção usando os recursos do Microsoft Defender para Contêineres. Nessa arquitetura, o Defender para Contêineres avalia apenas a vulnerabilidade dos contêineres em seu Registro de Contêiner. O Defender para Contêineres não fornece proteção em tempo de execução para Aplicativos de Contêiner. Avalie a complementação com soluções de segurança que não sejam da Microsoft se a proteção de runtime for um requisito.

  • Não execute a carga de trabalho em um ambiente de Aplicativos de Contêiner compartilhado. Segmente-o de outras cargas de trabalho ou componentes que não precisam de acesso a esses microsserviços. Criar ambientes separados de Aplicativos em Contêiner. Aplicativos e trabalhos executados em um ambiente de Aplicativos de Contêiner podem descobrir e alcançar qualquer serviço executado no ambiente com entrada interna habilitada.

Otimização de custos

A Otimização de Custos concentra-se em maneiras 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 design parade Otimização de Custos.

  • Examine uma estimativa de preço de exemplo para a carga de trabalho. Use a calculadora de preços do Azure. As configurações variam, portanto, ajuste-a para corresponder ao seu cenário.

  • Nesse cenário, o Azure Cosmos DB, o Redis Gerenciado do Azure e o Barramento de Serviço na versão Premium são os principais fatores de custo.

  • Para contêineres que normalmente consomem baixa quantidade de CPU e memória, avalie primeiro o perfil de carga de trabalho de consumo. Estimar o custo do perfil de consumo com base em seu uso para ajudar a coletar dados de custo de linha de base e avaliar outros perfis. Por exemplo, você pode usar um perfil de carga de trabalho dedicado para componentes que têm uso altamente previsível e estável e podem compartilhar nós dedicados. Para otimização de custo, mantenha um múltiplo de três nós para cada perfil dedicado para garantir hosts de computação suficientes e a distribuição adequada de réplicas entre zonas de disponibilidade.

  • Elimine os custos de computação durante períodos de inatividade, garantindo que os componentes possam ser dimensionados para zero para que você só pague quando necessário. Essa abordagem reduz as despesas para aplicativos que têm uso variável ou pouco frequente. As verificações de integridade normalmente impedem a escala completa para zero. Na arquitetura, você pode reimplementar o serviço de automação de fluxo de trabalho como uma tarefa para aproveitar o escalonamento até zero durante períodos ociosos. Essa abordagem se combina bem com tarefas que podem usar um plano de consumo.

  • Para evitar encargos de rede entre regiões, implante todos os componentes, como repositórios de estado e o registro de contêiner, na mesma região.

Excelência Operacional

A Excelência Operacional abrange os processos de operações que implantam um aplicativo e o mantêm em execução em produção. Para obter mais informações, consulte Lista de verificação de revisão de design parade Excelência Operacional.

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

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

  • Integre-se ao Application Insights e ao Log Analytics para fornecer insights sobre sua carga de trabalho. Use o mesmo espaço de trabalho do Log Analytics dos componentes da sua carga de trabalho para manter a coesão de todos os insights.

  • Utilize a IaC (Infraestrutura como Código), como o Bicep ou o Terraform, para gerenciar todas as implantações de infraestrutura. As implantações incluem o ambiente de Apps de Contêiner, o registro de contêineres e o armazenamento de estado dos microsserviços. Separe os pipelines de implantação de microsserviços dos pipelines de infraestrutura, pois geralmente não compartilham um ciclo de vida semelhante. Seu pipeline declarativo para a infraestrutura do Azure deve implantar todos os recursos, com exceção dos recursos da aplicação de contêiner.

  • Use uma abordagem imperativa para criar, atualizar e remover aplicativos de contêiner do ambiente. É especialmente importante se você estiver ajustando dinamicamente a lógica de mudança de tráfego entre revisões. Use uma ação do GitHub ou uma tarefa do Azure Pipelines em seus fluxos de trabalho de implantação. Essa abordagem imperativa pode ser baseada em definições de aplicativo YAML . Para minimizar falhas de verificação de integridade, certifique-se sempre de que o pipeline preencha o registro de contêiner com a nova imagem de contêiner antes de implantar o aplicativo de contêiner.

    Uma alteração importante da implementação do Kubernetes é a mudança do gerenciamento de arquivos de manifesto do Kubernetes, como a definição Deployment de objetos do Kubernetes. O Kubernetes fornece uma abordagem de "sucede em conjunto" ou "falha em conjunto" para a implantação de microsserviços, por meio desse objeto de manifesto. Em Aplicativos de Contêiner, cada microsserviço é implantado de forma independente. Os seus pipelines de implantação tornam-se responsáveis por orquestrar qualquer estratégia de sequenciamento e reversão necessária para garantir uma implantação segura.

Eficiência de desempenho

A Eficiência de Desempenho refere-se à capacidade da carga de trabalho de dimensionar para atender às demandas do usuário com eficiência. Para obter mais informações, consulte Lista de verificação de design parade Eficiência de Desempenho.

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

  • Cada microsserviço é independente e não compartilha nenhum estado com outros microsserviços, o que permite dimensionamento independente.

  • Use tarefas em Aplicativos de Contêiner para execuções de processos finitos a fim de implementar ambientes de execução transitórios e reduzir o consumo de recursos para serviços ociosos. Avalie as implicações de desempenho de girar trabalhos para cima e para baixo em vez de manter os componentes aquecidos e prontos.

  • O dimensionamento automático está habilitado. Prefira o dimensionamento baseado em evento em vez de dimensionamento baseado em métricas sempre que possível. Por exemplo, o serviço de fluxo de trabalho, se projetado para dar suporte a ele, pode ser dimensionado com base na profundidade da fila do Barramento de Serviço. O dimensionador automático padrão é baseado em solicitações HTTP. Durante uma reformulação, é importante começar com a mesma abordagem de dimensionamento e avaliar as otimizações de dimensionamento posteriormente.

  • As solicitações são balanceadas dinamicamente para as réplicas disponíveis de uma revisão.

  • As métricas, incluindo utilização de CPU, memória, informações de largura de banda e armazenamento, estão disponíveis por meio do Azure Monitor.

Implantar este cenário

Siga as etapas no README.md do repositório do cenário de exemplo de Aplicativos de Contêineres.

Colaboradores

A Microsoft atualiza este artigo. Os colaboradores a seguir escreveram este artigo.

Colaboradores

Próximas etapas