Considerações gerais de arquitetura para escolher um serviço de contêiner do Azure

  • Artigo

Este artigo orienta você pelo processo de escolha de um serviço de contêiner do Azure. Ele fornece uma visão geral das considerações de nível de recurso que são comuns e críticas para algumas cargas de trabalho. Ele pode ajudá-lo a tomar decisões para garantir que sua carga de trabalho atenda aos requisitos de confiabilidade, segurança, otimização de custos, excelência operacional e eficiência de desempenho.

Nota

Este artigo é a segunda parte de uma série que começa com Escolher um serviço de contêiner do Azure. É altamente recomendável que você leia esse artigo de visão geral primeiro para obter um contexto para essas considerações arquitetônicas.

Descrição geral

As considerações neste artigo estão divididas em quatro categorias:

Considerações arquitetônicas e de rede

  • Suporte de sistema operativo
  • Espaços de endereço de rede
  • Compreender o fluxo de tráfego
  • Planejando sub-redes
  • Número de IPs de entrada disponíveis
  • Rotas definidas pelo usuário e suporte a gateway NAT
  • Integração de rede privada
  • Cobertura do protocolo
  • Balanceamento de carga
  • Deteção de serviço
  • Domínios personalizados e TLS gerenciado
  • TLS mútuo
  • Conceitos de rede para serviços específicos do Azure

Considerações de segurança

  • Fornecendo segurança para o tráfego dentro do cluster usando diretivas de rede
  • Grupos de segurança de rede
  • Integração do Cofre de Chaves do Azure
  • Suporte de identidade gerenciado
  • Proteção contra ameaças e avaliações de vulnerabilidade com o Defender for Containers
  • Linhas de base de segurança
  • Azure Well-Architected Framework for Security

Considerações operacionais

  • Atualizações e correções de erros
  • Atualizações de imagem de contêiner
  • Escalabilidade da infraestrutura vertical
  • Escalabilidade da infraestrutura horizontal
  • Escalabilidade do aplicativo
  • Observabilidade
  • Estrutura bem arquitetada para excelência operacional

Considerações sobre confiabilidade

  • Contratos de nível de serviço
  • Redundância através de zonas de disponibilidade
  • Verificações de saúde e autorrecuperação
  • Implantações de aplicativos sem tempo de inatividade
  • Limites de recursos
  • Estrutura bem arquitetada para confiabilidade

Observe que este artigo se concentra em um subconjunto de serviços de contêiner do Azure que oferecem um conjunto de recursos maduro para aplicativos Web e APIs, rede, observabilidade, ferramentas de desenvolvedor e operações: Serviço Kubernetes do Azure (AKS), Aplicativos de Contêiner do Azure e Aplicativo Web para Contêineres. Para obter uma lista completa de todos os serviços de contêiner do Azure, consulte a página de categoria de produto de serviços de contêiner.

Nota

Neste guia, o termo carga de trabalho refere-se a uma coleção de recursos de aplicativo que dão suporte a uma meta de negócios ou à execução de um processo de negócios. Uma carga de trabalho usa vários componentes, como APIs e armazenamentos de dados, que trabalham juntos para fornecer funcionalidade específica de ponta a ponta.

Considerações arquitetônicas

Esta seção descreve decisões de arquitetura que são difíceis de reverter ou corrigir sem exigir tempo de inatividade ou reimplantação significativos. É especialmente necessário ter essa consideração em mente para componentes fundamentais, como rede e segurança.

Essas considerações não são específicas dos pilares do Well-Architected Framework. No entanto, eles merecem escrutínio e avaliação adicionais em relação aos requisitos de negócios quando você escolhe um serviço de contêiner do Azure.

Suporte de sistema operativo

A maioria dos aplicativos em contêineres é executada em contêineres Linux, que são suportados por todos os serviços de contêiner do Azure. Suas opções são mais limitadas para componentes de carga de trabalho que exigem contêineres do Windows.

Aplicativos de contêiner AKS Aplicação Web para Contentores
Suporte Linux ✅ ✅ ✅
Suporte do Windows ❌ ✅ ✅
Suporte a SO misto ❌ ✅ ❌*

*O suporte de SO misto para Aplicação Web para Contentores requer planos separados do Serviço de Aplicações do Azure para Windows e Linux.

Considerações sobre a rede

É importante entender o design de rede no início de seus processos de planejamento devido a restrições de segurança e conformidade e diretrizes impostas. Em geral, as principais diferenças entre os serviços do Azure abordados neste guia dependem da preferência:

  • Aplicativos de contêiner é uma oferta de PaaS que fornece muitos recursos de rede gerenciados pelo Azure, como descoberta de serviços e domínios gerenciados internos. As equipes de carga de trabalho que precisam de um pouco mais de configurabilidade podem usar perfis de carga de trabalho/dedicados antes de considerar alternativas para maximizar suas opções de rede.
  • AKS é o mais configurável dos três serviços e fornece o maior controle sobre o fluxo de rede. Por exemplo, ele fornece controladores de entrada personalizados e o controle do tráfego intra-cluster por meio de políticas de rede do Kubernetes. As equipes de carga de trabalho podem aproveitar vários complementos de rede gerenciados do Azure, bem como instalar e operar quaisquer complementos do ecossistema Kubernetes mais amplo.
  • O Aplicativo Web para Contêineres é um recurso do Serviço de Aplicativo. Assim, os conceitos de rede, especialmente a integração de rede privada, são muito específicos do Serviço de Aplicativo. Esse serviço será familiar para as equipes de carga de trabalho que já usam o Serviço de Aplicativo. As equipes que não têm experiência com o Serviço de Aplicativo e que desejam uma integração de rede virtual do Azure mais familiar são incentivadas a considerar os Aplicativos de Contêiner.

Tenha em mente que a rede é uma camada de infraestrutura fundamental. Muitas vezes, é difícil fazer alterações no projeto sem reimplantar a carga de trabalho, o que pode levar a tempo de inatividade. Portanto, se sua carga de trabalho tiver requisitos de rede específicos, revise esta seção cuidadosamente antes de restringir sua seleção de serviço de contêiner do Azure.

Espaços de endereço de rede

Ao integrar aplicativos em redes virtuais, você precisa fazer algum planejamento de endereços IP para garantir que endereços IP suficientes estejam disponíveis para instâncias de contêiner. Durante esse processo, planeje endereços adicionais para atualizações, implantações azuis/verdes e situações semelhantes em que instâncias extras são implantadas, o que consome endereços IP adicionais.

Aplicativos de contêiner AKS Aplicação Web para Contentores
Sub-redes dedicadas Plano de consumo: opcional
Plano dedicado: obrigatório		 Obrigatório Opcional
Requisitos de endereço IP Plano de consumo: Consulte Ambiente apenas de consumo.
Plano dedicado: consulte Ambiente de perfis de carga de trabalho.		 Consulte Redes virtuais do Azure para AKS. Consulte Requisitos de sub-rede do Serviço de Aplicativo.

Observe que os requisitos do AKS dependem do plug-in de rede escolhido. Alguns plug-ins de rede para AKS requerem reservas de IP mais amplas. Os detalhes estão fora do âmbito deste artigo. Para obter mais informações, consulte Conceitos de rede para AKS.

Compreender o fluxo de tráfego

Os tipos de fluxo de tráfego necessários para uma solução podem afetar o design da rede.

As seções a seguir fornecem informações sobre várias restrições de rede. Essas restrições afetam sua necessidade de implantar sub-redes adicionais, dependendo se você precisa:

  • Várias cargas de trabalho colocalizadas.
  • Entrada privada e/ou pública.
  • Um fluxo controlado de acesso de tráfego leste-oeste em um cluster (para Aplicativos de Contêiner e AKS) ou em uma rede virtual (para todos os serviços de contêiner do Azure).

Planeamento de sub-redes

Garantir que você tenha uma sub-rede grande o suficiente para incluir instâncias do seu aplicativo para sua carga de trabalho não é o único fator que dita o espaço ocupado pela rede onde esses aplicativos são implantados.

Aplicativos de contêiner AKS Aplicação Web para Contentores
Suporte para cargas de trabalho colocalizadas dentro de uma sub-rede* ❌* ✅ N/D*

*Isto descreve uma prática recomendada, não uma limitação técnica.

Para Aplicativos de Contêiner, a integração de sub-rede se aplica somente a um único ambiente de Aplicativos de Contêiner. Cada ambiente de Aplicativos de Contêiner é restrito a um único IP de entrada, público ou privado.

Cada ambiente de Aplicativos de Contêiner destina-se apenas a uma única carga de trabalho na qual os aplicativos dependentes são colocados. Portanto, você precisa introduzir dispositivos de rede do Azure adicionais para balanceamento de carga de entrada se precisar de entrada pública e privada. Os exemplos incluem o Azure Application Gateway e o Azure Front Door. Além disso, se você tiver várias cargas de trabalho que precisam ser segregadas, ambientes adicionais de Aplicativos de Contêiner serão necessários, portanto, uma sub-rede adicional deverá ser alocada para cada ambiente.

O AKS fornece controle granular de fluxo de rede leste-oeste dentro do cluster na forma de política de rede do Kubernetes. Esse controle de fluxo permite segmentar várias cargas de trabalho com diferentes limites de segurança de rede dentro do mesmo cluster.

Para o Web App for Containers, não há restrições sobre quantos aplicativos você pode integrar a uma única sub-rede, desde que a sub-rede seja grande o suficiente. Não há práticas recomendadas para controle de acesso entre aplicativos Web na mesma rede virtual. Cada aplicativo Web gerencia independentemente o controle de acesso para o tráfego leste-oeste ou norte-sul da rede virtual ou da Internet, respectivamente.

Nota

Não é possível redimensionar sub-redes que tenham recursos implantados nelas. Tenha cuidado extra ao planejar sua rede para evitar a necessidade de reimplantar componentes inteiros da carga de trabalho, o que pode levar a tempo de inatividade.

Número de IPs de entrada disponíveis

A tabela a seguir leva em consideração a seção de planejamento de sub-rede anterior para definir quantos IPs podem ser expostos para um número arbitrário de aplicativos hospedados em uma única implantação de um serviço de contêiner do Azure.

Aplicativos de contêiner AKS Aplicação Web para Contentores
Número de IPs de entrada Um Muitos Ambiente do Serviço de Aplicativo: Um
Sem ambiente de serviço de aplicativo: muitos

Container Apps permite um IP por ambiente, público ou privado. O AKS permite qualquer número de IPs, públicos ou privados. O Aplicativo Web para Contêineres, fora de um Ambiente do Serviço de Aplicativo, permite um IP público para todos os aplicativos dentro de um plano do Serviço de Aplicativo e vários IPs privados diferentes que usam pontos de extremidade privados do Azure.

É importante observar que os aplicativos Web integrados a um Ambiente do Serviço de Aplicativo só recebem tráfego por meio do IP de entrada único associado ao Ambiente do Serviço de Aplicativo, seja ele público ou privado.

Rotas definidas pelo usuário e suporte a gateway NAT

Se uma carga de trabalho exigir rotas definidas pelo usuário (UDRs) e recursos de gateway NAT para controle de rede granular, os Aplicativos de Contêiner exigirão o uso de perfis de carga de trabalho. A compatibilidade de gateway UDR e NAT não está disponível no plano somente de consumo para ACA.

O AKS e o Web App for Containers implementam esses dois recursos de rede por meio da funcionalidade de rede virtual padrão ou integração de rede virtual, respectivamente. Para elaborar, os pools de nós AKS e o Aplicativo Web para Contêineres em um Ambiente de Serviço de Aplicativo já são recursos diretos de rede virtual. O Aplicativo Web para Contêineres que não estão em um Ambiente do Serviço de Aplicativo oferece suporte a UDRs e gateway NAT por meio da integração de rede virtual. Com a integração de rede virtual, o recurso tecnicamente não reside diretamente na rede virtual, mas todo o seu acesso de saída flui através da rede virtual, e as regras associadas à rede afetam o tráfego conforme o esperado.

Aplicativos de contêiner AKS Aplicação Web para Contentores
Suporte UDR Plano apenas de consumo: ❌
Plano de perfil de carga de trabalho: ✅		 ✅ ✅
Suporte a gateway NAT Plano apenas de consumo: ❌
Plano de perfil de carga de trabalho: ✅		 ✅ ✅

Integração de rede privada

Para cargas de trabalho que exigem rede privada de Camada 4 estrita para entrada e saída, você deve considerar Aplicativos de Contêiner, AKS e a SKU do Ambiente do Serviço de Aplicativo de locatário único, onde as cargas de trabalho são implantadas em uma rede virtual autogerenciada, fornecendo os controles de rede privada granulares habituais.

Aplicativos de contêiner AKS Aplicação Web para Contentores
Entrada privada em uma rede virtual ✅ ✅ Via ponto final privado
Saída privada de uma rede virtual ✅ ✅ Através da integração de rede virtual
Ponto final público totalmente suprimido ✅ ✅ Somente Ambiente do Serviço de Aplicativo
Rede privada com aplicativo Web para contêineres

O Aplicativo Web para Contêineres fornece recursos de rede adicionais que não são apresentados da mesma maneira pelos outros serviços do Azure descritos neste artigo. Para implementar requisitos rígidos de rede privada, as equipes de carga de trabalho precisam se familiarizar com esses conceitos de rede. Analise cuidadosamente estes recursos de rede:

Se você quiser uma solução PaaS e preferir conceitos de rede que são compartilhados entre várias soluções do Azure, considere Aplicativos de Contêiner.

Cobertura do protocolo

Uma consideração importante para a plataforma de hospedagem são os protocolos de rede que são suportados para solicitações de aplicativos de entrada (ingresso). O Web App for Containers é a opção mais rigorosa, suportando apenas HTTP e HTTPS. Aplicativos de contêiner também permite conexões TCP de entrada. O AKS é o mais flexível, suportando o uso irrestrito de TCP e UDP em portas auto-selecionadas.

Aplicativos de contêiner AKS Aplicativo Web para contêineres
Suporte a protocolos e portas HTTP (porta 80)*
HTTPS (porta 443)*
TCP (portas 1-65535, exceto 80 e 443)		 TCP (qualquer porta)
UDP (qualquer porta)		 HTTP (porta 80)
HTTPS (porta 443)
Suporte a WebSocket ✅ ✅ ✅
Suporte HTTP/2 ✅ ✅ ✅

*No ambiente Container Apps, HTTP/S pode ser exposto em qualquer porta para comunicação intra-cluster. Nesse cenário, os recursos HTTP internos do Container Apps, como CORS e afinidade de sessão, não se aplicam.

Tanto os Aplicativos de Contêiner quanto os Aplicativos Web para Contêineres suportam TLS 1.2 para sua entrada HTTPS interna.

Balanceamento de carga

Com Aplicativos de Contêiner e Aplicativo Web para Contêineres, o Azure abstrai totalmente os balanceadores de carga de Camada 4 e Camada 7.

Em contraste, o AKS usa um modelo de responsabilidade compartilhada no qual o Azure gerencia a infraestrutura subjacente do Azure que a equipe de carga de trabalho configura fazendo interface com a API do Kubernetes. Para o balanceamento de carga da Camada 7 no AKS, você pode escolher opções gerenciadas pelo Azure, por exemplo, o complemento de roteamento de aplicativo gerenciado pelo AKS ou o Application Gateway for Containers, ou implantar e autogerenciar um controlador de entrada de sua escolha.

Aplicativos de contêiner AKS Aplicação Web para Contentores
Balanceador de carga de camada 4 Gerenciado pelo Azure Responsabilidade partilhada Gerenciado pelo Azure
Balanceador de carga de camada 7 Gerenciado pelo Azure Compartilhado ou autogerenciado Gerenciado pelo Azure

Deteção de serviço

Em arquiteturas de nuvem, os tempos de execução podem ser removidos e recriados a qualquer momento para reequilibrar recursos, para que os endereços IP da instância sejam alterados regularmente. Essas arquiteturas usam FQDNs (nomes de domínio totalmente qualificados) para uma comunicação confiável e consistente.

Aplicativos de contêiner AKS Aplicação Web para Contentores
Descoberta de serviço FQDN gerenciado pelo Azure Kubernetes configurável FQDN gerenciado pelo Azure

Web Apps for Containers fornece FQDNs de entrada pública (comunicação norte-sul) prontos para uso. Nenhuma configuração de DNS adicional é necessária. No entanto, não há nenhum mecanismo integrado para facilitar ou restringir o tráfego entre outros aplicativos (comunicação leste-oeste).

Os Aplicativos de Contêiner também fornecem FQDNs de entrada pública. No entanto, o Container Apps vai além, permitindo que o FQDN do aplicativo seja exposto e restringindo o tráfego apenas dentro do ambiente. Essa funcionalidade facilita o gerenciamento da comunicação leste-oeste e habilita componentes como o Dapr.

As implantações do Kubernetes não são inicialmente detetáveis dentro ou fora do cluster. Você deve criar serviços do Kubernetes conforme definido pela API do Kubernetes, que expõe os aplicativos à rede de forma endereçável.

Importante

Apenas Container Apps e AKS fornecem descoberta de serviços por meio de esquemas DNS internos em seus respetivos ambientes. Essa funcionalidade pode simplificar as configurações de DNS em ambientes de desenvolvimento/teste e produção. Por exemplo, você pode criar esses ambientes com nomes de serviço arbitrários que precisam ser exclusivos apenas dentro do ambiente ou cluster, para que possam ser os mesmos em desenvolvimento/teste e produção. Com o Aplicativo Web para Contêineres, os nomes de serviço devem ser exclusivos em diferentes ambientes para evitar conflitos com o DNS do Azure.

Domínios personalizados e TLS gerenciado

Tanto o Container Apps quanto o Web App for Containers fornecem soluções prontas para uso para domínios personalizados e gerenciamento de certificados.

Aplicativos de contêiner AKS Aplicação Web para Contentores
Configurar domínios personalizados Fora da caixa BYO Fora da caixa
TLS gerenciado para FQDNs do Azure Fora da caixa N/A Fora da caixa
TLS gerenciado para domínios personalizados Em pré-visualização BYO Fora da caixa ou BYO

Os usuários do AKS são responsáveis por gerenciar DNS, configurações de cluster e certificados TLS para seus domínios personalizados. Embora o AKS não ofereça TLS gerenciado, os clientes podem aproveitar o software do ecossistema Kubernetes, por exemplo, o popular gerenciador de certificados para gerenciar certificados TLS.

TLS mútuo

Outra alternativa para restringir o tráfego de entrada é o TLS mútuo (mTLS). O TLS mútuo é um protocolo de segurança que garante que o cliente e o servidor em comunicação sejam autenticados. Para realizar a autenticação, ambas as partes trocam e verificam certificados antes que qualquer dado seja transmitido.

O Web App for Containers tem suporte mTLS integrado para conexões de clientes de entrada. No entanto, o aplicativo precisa validar o certificado acessando o cabeçalho HTTP encaminhado X-ARR-ClientCert pela plataforma do Serviço de Aplicativo.

O Container Apps também tem suporte integrado para mTLS. Ele encaminha o certificado do cliente para o aplicativo no cabeçalho HTTP X-Forwarded-Client-Cert. Você também pode habilitar facilmente o mTLS automático para comunicação interna entre aplicativos em um único ambiente.

O TLS mútuo no AKS pode ser implementado através da malha de serviço baseada em Istio como um complemento gerenciado, que inclui recursos de mTLS para conexões de clientes de entrada e comunicação intra-cluster entre serviços. As equipes de carga de trabalho também podem optar por instalar e gerenciar outra oferta de malha de serviço do ecossistema Kubernetes. Essas opções tornam a implementação do mTLS no Kubernetes a mais flexível.

Conceitos de rede específicos do serviço

As secções anteriores descrevem algumas das considerações mais comuns a ter em conta. Para obter mais detalhes e saber mais sobre os recursos de rede específicos dos serviços de contêiner individuais do Azure, consulte estes artigos:

As seções anteriores se concentram no design de rede. Continue para a próxima seção para saber mais sobre segurança de rede e proteção do tráfego de rede.

Considerações de segurança

A falha em lidar com os riscos de segurança pode levar a acesso não autorizado, violações de dados ou vazamentos de informações confidenciais. Os contêineres oferecem um ambiente encapsulado para seu aplicativo. Os sistemas de hospedagem e sobreposições de rede subjacentes, no entanto, exigem guarda-corpos adicionais. Sua escolha do serviço de contêiner do Azure precisa dar suporte aos seus requisitos específicos para proteger cada aplicativo individualmente e fornecer medidas de segurança adequadas para evitar acesso não autorizado e mitigar o risco de ataques.

Visão geral da comparação de segurança

A maioria dos serviços do Azure, incluindo Aplicativos de Contêiner, AKS e Aplicativo Web para Contêineres, integra-se às principais ofertas de segurança, incluindo o Cofre de Chaves e identidades gerenciadas.

Dos serviços neste guia, o AKS oferece a maior configurabilidade e extensibilidade em parte por sobressair componentes subjacentes, que muitas vezes podem ser protegidos através de opções de configuração. Por exemplo, os clientes podem desativar contas locais para o servidor de API do Kubernetes ou ativar atualizações automáticas para nós subjacentes por meio de opções de configuração.

Para obter uma comparação detalhada, analise cuidadosamente as considerações a seguir para garantir que seus requisitos de segurança de carga de trabalho possam ser atendidos.

Segurança do plano de controle do Kubernetes

O AKS oferece a maior flexibilidade das três opções consideradas neste artigo, fornecendo acesso total à API do Kubernetes para que você possa personalizar a orquestração de contêineres. Esse acesso à API do Kubernetes, no entanto, também representa uma superfície de ataque significativa, e você precisa protegê-la.

Importante

Observe que esta seção não é relevante para o Aplicativo Web para Contêineres, que usa a API do Azure Resource Manager como seu plano de controle.

Segurança baseada em identidade

Os clientes são responsáveis por proteger o acesso baseado em identidade à API. Pronto para usar, o Kubernetes fornece seu próprio sistema de gerenciamento de autenticação e autorização, que também precisa ser protegido com controles de acesso.

Para aproveitar um único plano de vidro para gerenciamento de identidade e acesso no Azure, é uma prática recomendada desabilitar contas locais específicas do Kubernetes e, em vez disso, implementar a integração do Microsoft Entra gerenciada pelo AKS junto com o RBAC do Azure para Kubernetes. Se você implementar essa prática recomendada, os administradores não precisarão executar o gerenciamento de identidade e acesso em várias plataformas.

Aplicativos de contêiner AKS
Controles de acesso à API do Kubernetes Sem acesso Acesso total

Os clientes que usam aplicativos de contêiner não têm acesso à API do Kubernetes. A Microsoft fornece segurança para esta API.

Segurança baseada na rede

Se você quiser restringir o acesso à rede para o plano de controle do Kubernetes, você precisa usar o AKS, que fornece duas opções. A primeira opção é usar clusters AKS privados, que usam o Azure Private Link entre a rede privada do servidor de API e a rede privada do cluster AKS. A segunda opção é a integração de VNet do API Server (visualização), onde o servidor de API é integrado em uma sub-rede delegada. Consulte a documentação para saber mais.

Há consequências na implementação do acesso restrito à rede à API do Kubernetes. Mais notavelmente, a gestão só pode ser realizada a partir da rede privada. Normalmente, isso significa que você precisa implantar agentes autohospedados para DevOps do Azure ou Ações do GitHub. Para saber mais sobre outras limitações, consulte a documentação específica do produto.

Aplicativos de contêiner AKS
Segurança de rede da API do Kubernetes Não configurável em PaaS Configurável: IP público ou IP privado

Essas considerações não se aplicam aos Aplicativos de Contêiner. Por se tratar de PaaS, a Microsoft abstrai a infraestrutura subjacente.

Segurança da rede do plano de dados

Os seguintes recursos de rede podem ser usados para controlar o acesso a, de e dentro de uma carga de trabalho.

Usando diretivas de rede para fornecer segurança para o tráfego intra-cluster

Algumas posturas de segurança exigem segregação de tráfego de rede em um ambiente, por exemplo, quando você usa ambientes multilocatários para hospedar aplicativos de várias ou várias camadas. Nesses cenários, você deve escolher AKS e implementar políticas de rede, uma tecnologia nativa da nuvem que permite a configuração granular da rede de Camada 4 em clusters Kubernetes.

Aplicativos de contêiner AKS Aplicação Web para Contentores
Políticas de rede Plano de consumo: ❌
Plano dedicado: ❌		 ✅ ❌

Dos três serviços do Azure descritos neste artigo, o AKS é o único que oferece suporte ao isolamento adicional da carga de trabalho dentro do cluster. Não há suporte para políticas de rede em Aplicativos de Contêiner ou Aplicativo Web para Contêineres.

Grupos de segurança de rede

Em todos os cenários, você pode regular a comunicação de rede dentro da rede virtual mais ampla usando grupos de segurança de rede, o que permite usar regras de tráfego de Camada 4 que regulam a entrada e saída no nível da rede virtual.

Aplicativos de contêiner AKS Aplicação Web para Contentores
Grupos de segurança de rede Plano de consumo: ✅
Plano dedicado: ✅		 ✅ ✅ Aplicativos integrados à rede virtual: somente saída

Restrições de IP para entrada

Normalmente, as restrições de tráfego de rede são aplicadas através das regras da Camada 4 descritas acima. No entanto, em cenários de PaaS de aplicativos sem integração de rede virtual, pode ser útil restringir o tráfego na camada de aplicativo.

Os Aplicativos de Contêiner e o Aplicativo Web para Contêineres fornecem restrições de IP de origem internas para o tráfego de entrada em aplicativos individuais.

Aplicativos de contêiner AKS Aplicação Web para Contentores
Restrições de IP de entrada na camada de aplicativo Fora da caixa Auto-gerido ou através de add-on gerido Fora da caixa
Consumo de recursos - Consome recursos de cluster -

Para cargas de trabalho AKS, a implementação depende do controlador de entrada escolhido. Tanto o complemento de roteamento de aplicativo autogerenciado quanto o complemento de roteamento de aplicativo gerenciado do Azure consomem recursos de cluster.

Segurança ao nível das aplicações

Você precisa proteger as cargas de trabalho não apenas no nível de rede e infraestrutura, mas também no nível de carga de trabalho e aplicativo. As soluções de contêiner do Azure integram-se às ofertas de segurança do Azure para ajudar a padronizar a implementação e os controles de segurança para seus aplicativos.

Integração com o Key Vault

É uma prática recomendada armazenar e gerenciar segredos, chaves e certificados em uma solução de gerenciamento de chaves como o Key Vault, que fornece segurança aprimorada para esses componentes. Em vez de armazenar e configurar segredos no código ou em um serviço de computação do Azure, todos os aplicativos devem se integrar ao Cofre da Chave.

A integração do Key Vault permite que os desenvolvedores de aplicativos se concentrem no código do aplicativo. Todos os três serviços de contêiner do Azure descritos neste artigo podem sincronizar automaticamente segredos do serviço Cofre de Chaves e fornecê-los ao aplicativo, normalmente como variáveis de ambiente ou arquivos montados.

Aplicativos de contêiner AKS Aplicação Web para Contentores
Integração com o Key Vault ✅ ✅ ✅

Para obter mais informações, consulte:

Suporte de identidade gerenciado

Os aplicativos com identidades gerenciadas atribuídas podem acessar recursos do Azure sem senhas. Todos os serviços de contêiner mencionados neste guia suportam identidades gerenciadas.

Aplicativos de contêiner AKS Aplicação Web para Contentores
Suporte de identidade gerenciado ✅ ✅ ✅

Para obter mais informações, consulte:

Proteção contra ameaças e avaliações de vulnerabilidade com o Defender for Containers

A proteção contra ameaças contra vulnerabilidades também é importante. É uma prática recomendada usar o Defender for Containers. As avaliações de vulnerabilidade têm suporte nos registros de contêiner do Azure, portanto, podem ser usadas por qualquer serviço de contêiner do Azure, não apenas pelas descritas neste artigo. A proteção de tempo de execução do Defender for Containers, no entanto, está disponível apenas para AKS.

Como o AKS expõe a API nativa do Kubernetes, a segurança do cluster também pode ser avaliada com ferramentas de segurança específicas do Kubernetes do ecossistema do Kubernetes.

Aplicativos de contêiner AKS Aplicação Web para Contentores
Proteção contra ameaças em tempo de execução ❌ ✅ ❌

Para obter mais informações, consulte Matriz de suporte de contêineres no Defender for Cloud.

Observe que as avaliações de vulnerabilidade de imagem de contêiner não são verificações em tempo real. O registro de contêiner do Azure é verificado em intervalos regulares.

Linhas de base de segurança

Em geral, a maioria dos serviços de contêiner do Azure integra as ofertas de segurança do Azure. No geral, tenha em mente que um conjunto de recursos de segurança é apenas uma pequena parte da implementação da segurança na nuvem. Para obter mais informações sobre como implementar a segurança para serviços de contêiner, consulte as seguintes linhas de base de segurança específicas do serviço:

As linhas de base de segurança abrangem outras integrações do Azure, incluindo criptografia de hardware e log, que estão fora do escopo deste artigo.

Estrutura bem arquitetada para segurança

Este artigo se concentra nas principais diferenças entre os recursos de serviços de contêiner descritos aqui.

Para obter orientações de segurança mais completas sobre o AKS, consulte Revisão do Well-Architected Framework - AKS.

Considerações operacionais

Para executar com sucesso uma carga de trabalho na produção, as equipes precisam implementar práticas de excelência operacional, incluindo registro centralizado, monitoramento, escalabilidade, atualizações e patches regulares e gerenciamento de imagens.

Atualizações e correções de erros

É importante que o sistema operacional subjacente de um aplicativo seja atualizado e corrigido regularmente. Tenha em mente, no entanto, que a cada atualização há um risco de falha. Esta seção e a próxima descrevem as principais considerações para os três serviços de contêiner no que diz respeito à responsabilidade compartilhada entre o cliente e a plataforma.

Como um serviço Kubernetes gerenciado, o AKS fornecerá as imagens atualizadas para o sistema operacional do nó e os componentes do plano de controle. Mas as equipes de carga de trabalho são responsáveis por aplicar atualizações aos seus clusters. Você pode acionar atualizações manualmente ou aproveitar o recurso de canais de atualização automática de cluster para garantir que seus clusters estejam atualizados. Consulte o guia de operações do AKS day-2 para saber mais sobre como corrigir e atualizar clusters AKS.

Container Apps e Web App for Containers são soluções PaaS. O Azure é responsável por gerenciar atualizações e patches, para que os clientes possam evitar a complexidade do gerenciamento de atualizações do AKS.

Aplicativos de contêiner AKS Aplicação Web para Contentores
Atualizações do plano de controle Plataforma Cliente Plataforma
Atualizações e patches do host Plataforma Cliente Plataforma
Atualizações e patches de imagens de contêiner Cliente Cliente Cliente

Atualizações de imagem de contêiner

Independentemente da solução de contêiner do Azure, os clientes são sempre responsáveis por suas próprias imagens de contêiner. Se houver patches de segurança para imagens de base de contêiner, é sua responsabilidade reconstruir suas imagens. Para receber alertas sobre essas vulnerabilidades, use o Defender for Containers para contêineres hospedados no Registro de contêineres.

Escalabilidade

O dimensionamento é usado para ajustar a capacidade de recursos para atender às demandas, adicionando mais capacidade para garantir o desempenho e removendo a capacidade não utilizada para economizar dinheiro. Ao escolher uma solução de contêiner, você precisa considerar restrições de infraestrutura e estratégias de dimensionamento.

Escalabilidade da infraestrutura vertical

O dimensionamento vertical refere-se à capacidade de aumentar ou diminuir a infraestrutura existente, ou seja, calcular a CPU e a memória. Cargas de trabalho diferentes exigem quantidades diferentes de recursos de computação. Ao escolher uma solução de contêiner do Azure, você precisa estar ciente das ofertas de SKU de hardware disponíveis para um serviço específico do Azure. Variam e podem impor restrições adicionais.

Para o AKS, revise os tamanhos das máquinas virtuais na documentação do Azure e as restrições do AKS por região.

Estes artigos fornecem detalhes sobre as ofertas de SKU para os outros dois serviços:

Escalabilidade da infraestrutura horizontal

O dimensionamento horizontal refere-se à capacidade de aumentar ou diminuir a capacidade por meio de novas infraestruturas, como nós de VM. Durante o aumento ou diminuição do dimensionamento, a camada de consumo de Aplicativos de Contêiner abstrai as máquinas virtuais subjacentes. Para os serviços de contêiner restantes do Azure, você gerencia a estratégia de dimensionamento horizontal usando a API padrão do Azure Resource Manager.

Observe que o dimensionamento inclui o rebalanceamento de instâncias, portanto, também cria um risco de tempo de inatividade. O risco é menor do que o risco correspondente com escala vertical. No entanto, as equipes de carga de trabalho são sempre responsáveis por garantir que seus aplicativos possam lidar com falhas e por implementar inicializações graciosas e desligamentos de seus aplicativos para evitar tempo de inatividade.

Aplicativos de contêiner AKS Aplicação Web para Contentores
Dimensionamento de infraestrutura para dentro e para fora Plano de consumo: N/A
Plano dedicado: configurável		 Configurável Configurável
Provisionamento de hardware flexível Plano de consumo: N/A
Plano dedicado: abstraído com perfis de carga de trabalho		 Qualquer VM SKU Abstraído. Consulte Plano do Serviço de Aplicativo.

Importante

As opções de provisionamento de hardware disponíveis por meio do plano Container Apps Dedicated (perfis de carga de trabalho) e Web App for Containers (planos do Serviço de Aplicativo) não são tão flexíveis quanto o AKS. Você precisa se familiarizar com os SKUs disponíveis em cada serviço para garantir que suas necessidades sejam atendidas.

Escalabilidade do aplicativo

A medida típica para acionar o dimensionamento de infraestrutura e aplicativos é o consumo de recursos: CPU e memória. Algumas soluções de contêiner podem dimensionar a contagem de instâncias de contêiner em métricas com contexto específico do aplicativo, como solicitações HTTP. Por exemplo, o AKS e o Container Apps podem dimensionar instâncias de contêiner com base em filas de mensagens via KEDA e muitas outras métricas por meio de seus escaladores. Esses recursos oferecem flexibilidade ao escolher a estratégia de escalabilidade para seu aplicativo. O Web App for Containers depende das opções de escalabilidade fornecidas pelo Azure. (Veja a tabela a seguir.) O Web App for Containers não suporta configurações de dimensionamento personalizadas como o KEDA.

Aplicativos de contêiner AKS Aplicação Web para Contentores
Dimensionamento do contêiner HTTP, TCP ou baseado em métricas (CPU, memória, orientado a eventos). Baseado em métricas (CPU, memória ou personalizadas). Manual, baseado em métricas ou automático (visualização).
Escalabilidade orientada a eventos Sim. Nativo da nuvem. Sim. Nativo da nuvem. Configuração adicional necessária. Sim. Específico do recurso do Azure.

Observabilidade

Instrumentação da carga de trabalho

Reunir métricas para aplicativos complexos ou de várias camadas pode ser um desafio. Para obter métricas, você pode integrar cargas de trabalho em contêineres com o Azure Monitor de duas maneiras:

  • Instrumentação automática. Não são necessárias alterações de código.
  • Instrumentação manual. Alterações mínimas de código necessárias para integrar e configurar o SDK e/ou cliente.
Aplicativos de contêiner AKS Aplicação Web para Contentores
Instrumentação automática via plataforma ❌ ❌ Suporte parcial*
Instrumentação automática via agente ❌ Suporte parcial* N/A
Instrumentação manual Via SDK ou OpenTelemetry Via SDK ou OpenTelemetry Via SDK ou OpenTelemetry

*O AKS e o Web App for Containers suportam instrumentação automática para determinadas configurações de cargas de trabalho Linux e Windows, dependendo do idioma do aplicativo. Para mais informações, consulte estes artigos:

A instrumentação dentro do código do aplicativo é de responsabilidade dos desenvolvedores de aplicativos, portanto, é independente de qualquer solução de contêiner do Azure. Sua carga de trabalho pode usar soluções como:

Registos

Todos os serviços de contêiner do Azure fornecem funcionalidade de log de aplicativo e plataforma. Os logs de aplicativos são logs de console gerados pela sua carga de trabalho. Os logs da plataforma capturam eventos que ocorrem no nível da plataforma, fora do escopo do seu aplicativo, como dimensionamento e implantações.

As principais diferenças entre a funcionalidade de registro em log para serviços de contêiner dizem respeito ao registro em log da plataforma: o que é registrado e como os logs são organizados internamente. O Azure Monitor é o principal serviço de registo no Azure que se integra com estes serviços. O Monitor usa logs de recursos para separar logs que vêm de fontes diferentes em categorias. Uma maneira de determinar quais logs estão disponíveis em cada serviço do Azure é examinar as categorias de log de recursos disponíveis para cada um dos serviços.

Aplicativos de contêiner AKS Aplicação Web para Contentores
Suporte para streaming de logs (streaming em tempo real) ✅ ✅ ✅
Suporte para o Azure Monitor ✅ ✅ ✅
Logs de recursos do Azure Monitor Consola e sistema Servidor de API do Kubernetes, Auditoria, Agendador, Autoscaler de Cluster e muito mais ConsoleLogs, HTTPLogs, EnvironmentPlatformLogs, e muito mais

Para obter uma descrição detalhada de cada um dos logs de recursos na tabela, selecione os links na tabela.

Aqui está um breve resumo dos recursos de registro em log dos serviços de contêiner:

  • O Container Apps abstrai todos os seus logs internos do Kubernetes em duas categorias. Um deles, chamado Logs de console , contém os logs do contêiner de carga de trabalho. Uma segunda categoria de Sistema contém todos os logs relacionados à plataforma.
  • O AKS fornece todos os logs relacionados ao Kubernetes e controle granular sobre o que pode ser registrado. Ele também mantém total compatibilidade com ferramentas de cliente Kubernetes para streaming de logs, como kubectl.
  • O Web App for Containers fornece muitas categorias de logs de recursos porque sua plataforma (Serviço de Aplicativo) não é exclusiva para cargas de trabalho de contêiner. Para operações específicas de contêiner que gerenciam sua plataforma Docker interna, ele fornece a categoria de log AppServicePlatformLogs. Outra categoria importante é AppServiceEnvironmentPlatformLogs, que registra eventos como dimensionamento e alterações de configuração.

Estrutura bem arquitetada para excelência operacional

Este artigo se concentra nas principais diferenças entre os recursos de serviços de contêiner descritos aqui. Consulte estes artigos para rever as orientações completas de Excelência Operacional para os seguintes serviços:

Fiabilidade

A fiabilidade refere-se à capacidade de um sistema reagir a falhas e permanecer totalmente funcional. No nível do software de aplicativo, as cargas de trabalho devem implementar práticas recomendadas, como cache, novas tentativas, padrões de disjuntor e verificações de integridade. No nível de infraestrutura, o Azure é responsável por lidar com falhas físicas, como falhas de hardware e quedas de energia, em datacenters. Falhas ainda podem acontecer. As equipes de carga de trabalho devem selecionar a camada de serviço apropriada do Azure e aplicar as configurações de instância mínima necessárias para implementar failovers automáticos entre zonas de disponibilidade.

Para escolher a camada de serviço apropriada, você precisa entender como funcionam os contratos de nível de serviço (SLAs) e as zonas de disponibilidade.

Contratos de nível de serviço

A confiabilidade é geralmente medida por métricas orientadas aos negócios, como SLAs, ou métricas de recuperação, como RTOs (Recovery Time Objetives, objetivos de tempo de recuperação).

O Azure tem muitos SLAs para serviços específicos. Não existe um nível de serviço de 100%, porque sempre podem ocorrer falhas em software e hardware, e na natureza, por exemplo, tempestades e terremotos. Um SLA não é uma garantia, mas sim um acordo de disponibilidade de serviço apoiado financeiramente.

Para obter os SLAs e detalhes mais recentes, baixe o documento SLA mais recente do Microsoft Online Services no site de licenciamento da Microsoft.

Níveis gratuitos vs. pagos

Geralmente, as camadas gratuitas de serviços do Azure não oferecem um SLA, o que as torna opções econômicas para ambientes que não são de produção. Para ambientes de produção, no entanto, é uma prática recomendada escolher uma camada paga que tenha um SLA.

Fatores adicionais para AKS

O AKS tem diferentes SLAs para diferentes componentes e configurações:

  • Plano de controlo. O servidor de API do Kubernetes tem um SLA separado.
  • Plano de dados. Os pools de nós usam os SLAs SKU de VM subjacentes.
  • Zonas de disponibilidade. Há SLAs diferentes para os dois planos, dependendo se o cluster AKS tem zonas de disponibilidade habilitadas e execução de várias instâncias em zonas de disponibilidade.

Observe que, quando você usa vários serviços do Azure, os SLAs compostos podem diferir e ser inferiores aos SLAs de serviço individuais.

Redundância com zonas de disponibilidade

As zonas de disponibilidade são datacenters distintos que têm energia elétrica independente, resfriamento e assim por diante, dentro de uma única região. A redundância resultante aumenta a tolerância a falhas sem exigir a implementação de arquiteturas de várias regiões.

O Azure tem zonas de disponibilidade em cada país/região em que o Azure opera uma região de datacenter. Para permitir que várias instâncias de contêineres cruzem zonas de disponibilidade, selecione SKUs, camadas de serviço e regiões que forneçam suporte à zona de disponibilidade.

Caraterística Aplicativos de contêiner AKS Aplicação Web para Contentores
Suporte à zona de disponibilidade Total Total Total

Por exemplo, um aplicativo ou infraestrutura configurado para executar uma única instância fica indisponível se ocorrer um problema na zona de disponibilidade onde o hardware está hospedado. Para usar totalmente o suporte à zona de disponibilidade, você deve implantar cargas de trabalho com uma configuração mínima de três instâncias do contêiner, distribuídas entre zonas.

Verificações de saúde e autorrecuperação

Os pontos finais de verificação de integridade são cruciais para uma carga de trabalho confiável. Mas construir esses pontos finais é apenas metade da solução. A outra metade é controlar o que a plataforma de hospedagem faz, e como, quando há falhas.

Para distinguir melhor entre os tipos de sondas de integridade, dê uma olhada nos tipos internos de testes do Kubernetes:

  • Arranque. Verifica se o aplicativo foi iniciado com êxito.
  • Prontidão. Verifica se o aplicativo está pronto para lidar com solicitações de entrada.
  • Vivacidade. Verifica se o aplicativo ainda está em execução e responsivo.

Outra consideração importante é a frequência com que essas verificações de integridade são solicitadas do aplicativo (granularidade interna). Se você tiver um longo intervalo entre essas solicitações, poderá continuar a atender o tráfego até que a instância seja considerada não íntegra.

A maioria dos aplicativos suporta verificações de integridade através do protocolo HTTP(S). No entanto, alguns podem precisar de outros protocolos, como TCP ou gRPC, para executar essas verificações. Tenha isso em mente ao projetar seu sistema de verificação de saúde.

Aplicativos de contêiner AKS Aplicativo Web para contêineres
Sondas de arranque ✅ ✅ Suporte parcial
Sondas de prontidão ✅ ✅ ❌
Sondas de vivacidade ✅ ✅ ✅
Granularidade do intervalo Segundos Segundos 1 minuto
Suporte a protocolos HTTP(S)
TCP		 HTTP(S)
TCP
gRPC		 HTTP(S)

As verificações de integridade são mais fáceis de implementar no Web App for Containers. Existem algumas considerações importantes:

  • Suas sondas de inicialização são incorporadas e não podem ser alteradas. Ele envia uma solicitação HTTP para a porta inicial do seu contêiner. Qualquer resposta da sua candidatura é considerada um início bem-sucedido.
  • Ele não suporta sondas de prontidão. Se o teste de inicialização for bem-sucedido, a instância de contêiner será adicionada ao pool de instâncias íntegras.
  • Envia o exame de saúde com intervalos de um minuto. Não é possível alterar o intervalo.
  • O limite mínimo que você pode definir para que uma instância não íntegra seja removida do mecanismo de balanceamento de carga interno é de dois minutos. A instância não íntegra recebe tráfego por pelo menos dois minutos depois de falhar em uma verificação de integridade. O valor padrão para essa configuração é 10 minutos.

Container Apps e AKS, por outro lado, são muito mais flexíveis e oferecem opções semelhantes. Em termos de diferenças específicas, o AKS fornece as seguintes opções para realizar verificações de integridade, que não estão disponíveis em Aplicativos de contêiner:

Autorrecuperação

Para identificar uma instância de contêiner incorreta e parar de enviar tráfego para ela é um começo. O próximo passo é implementar a recuperação automática. A recuperação automática é o processo de reiniciar o aplicativo na tentativa de se recuperar de um estado não íntegro. Veja como os três serviços de contêiner se comparam:

  • No Web App for Containers, não há opção para reiniciar uma instância de contêiner imediatamente após uma verificação de integridade falhar. Se a instância continuar falhando por uma hora, ela será substituída por uma nova instância. Há outro recurso, chamado de recuperação automática, que monitora e reinicia instâncias. Não está diretamente relacionado com os exames de saúde. Ele usa várias métricas do aplicativo, como limites de memória, duração da solicitação HTTP e códigos de status.
  • Aplicativos de contêiner e AKS tentam reiniciar automaticamente uma instância de contêiner se a sonda de vivacidade atingir o limite de falha definido.

Implantações de aplicativos sem tempo de inatividade

A capacidade de implantar e substituir aplicativos sem causar tempo de inatividade para os usuários é crucial para uma carga de trabalho confiável. Todos os três serviços de contêiner descritos neste artigo oferecem suporte a implantações sem tempo de inatividade, mas de maneiras diferentes.

Aplicativos de contêiner AKS Aplicação Web para Contentores
Estratégia de tempo de inatividade zero Atualização contínua Atualização contínua, além de todas as outras estratégias do Kubernetes Slots de implantação

Observe que as arquiteturas de aplicativos também devem oferecer suporte à implantação sem tempo de inatividade. Consulte Azure Well-Architected Framework para obter orientação.

Limites de recursos

Outro componente importante de um ambiente compartilhado confiável é seu controle sobre o uso de recursos (como CPU ou memória) de seus contêineres. Você precisa evitar cenários em que um único aplicativo ocupa todos os recursos e deixa outros aplicativos em mau estado.

Aplicativos de contêiner AKS Aplicação Web para Contentores
Limites de recursos (CPU ou memória) Por aplicativo/contêiner Por aplicativo/contêiner
Por namespace		 Por plano do Serviço de Aplicativo
  • Aplicativo Web para contêineres: você pode hospedar vários aplicativos (contêineres) em um único plano do Serviço de Aplicativo. Por exemplo, você pode alocar um plano com dois núcleos de CPU e 4 GiB de RAM no qual você pode executar vários aplicativos Web em contêineres. No entanto, não é possível restringir um dos aplicativos a uma certa quantidade de CPU ou memória. Todos eles competem pelos mesmos recursos do plano do Serviço de Aplicativo. Se você quiser isolar os recursos do aplicativo, precisará criar planos adicionais do Serviço de Aplicativo.
  • Aplicativos de contêiner: você pode definir limites de CPU e memória por aplicativo em seu ambiente. Você está restrito, no entanto, a um conjunto de combinações permitidas de CPU e memória. Por exemplo, você não pode configurar uma vCPU e 1 GiB de memória, mas você pode configurar uma vCPU e 2 GiB de memória. Um ambiente Container Apps é análogo a um namespace Kubernetes.
  • AKS: Você pode escolher qualquer combinação de vCPU e memória, desde que seus nós tenham o hardware para suportá-lo. Você também pode limitar recursos no nível de namespace se quiser segmentar seu cluster dessa maneira.

Estrutura bem arquitetada para confiabilidade

Este artigo se concentra nas principais diferenças entre os recursos de serviços de contêiner no Azure. Se você quiser revisar as diretrizes completas de confiabilidade para um serviço específico, consulte estes artigos:

Conclusão

Soluções bem arquitetadas estabelecem as bases para cargas de trabalho bem-sucedidas. Embora as arquiteturas possam ser ajustadas à medida que a carga de trabalho cresce e as equipes progridem em suas jornadas na nuvem, algumas decisões, especialmente em torno da rede, são difíceis de reverter sem tempo de inatividade ou reimplantação significativos.

Em geral, quando você compara os serviços de contêiner do Azure, surge um tema: o AKS apresenta a infraestrutura mais subjacente, oferecendo assim a maior configurabilidade e extensibilidade. A quantidade de sobrecarga operacional e complexidade é altamente variável para cargas de trabalho AKS. Algumas equipes podem reduzir significativamente a sobrecarga operacional usando extensões e complementos gerenciados pela Microsoft, bem como recursos de atualização automática. Outros clientes podem preferir o controle total do cluster para aproveitar a extensibilidade total do Kubernetes e do ecossistema CNCF. Por exemplo, embora a Microsoft ofereça o Flux como uma extensão gerenciada do GitOps, muitas equipes optam por configurar e operar o ArgoCD por conta própria.

As equipes de carga de trabalho que, por exemplo, não exigem aplicativos CNCF, têm menos experiência em operações ou preferem se concentrar em recursos de aplicativos podem preferir uma oferta de PaaS. Recomendamos que eles considerem primeiro os Aplicativos de Contêiner.

Embora Container Apps e Web App for Containers sejam ofertas de PaaS que fornecem níveis semelhantes de infraestrutura gerenciada pela Microsoft, uma diferença importante é que o Container Apps está mais próximo do Kubernetes e fornece recursos adicionais nativos da nuvem para descoberta de serviços, dimensionamento automático orientado a eventos, integração Dapr e muito mais. No entanto, as equipes que não precisam desses recursos e estão familiarizadas com os modelos de rede e implantação do Serviço de Aplicativo podem preferir o Aplicativo Web para Contêineres.

As generalizações podem ajudá-lo a restringir a lista de serviços de contêiner do Azure a serem considerados. Mas lembre-se de que você também precisa verificar sua escolha examinando os requisitos individuais em detalhes e combinando-os com conjuntos de recursos específicos do serviço.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

Outros contribuidores:

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos