Partilhar via

Rede no ambiente de Aplicativos de Contêiner do Azure

  • Artigo

Os Aplicativos de Contêiner do Azure são executados no contexto de um ambiente, com sua própria rede virtual (VNet).

Por predefinição, o seu ambiente de Container Apps é criado com uma rede virtual que é gerada automaticamente para si. Para um controlo refinado da sua rede, pode fornecer uma VNet existente quando criar um ambiente. Depois de criar um ambiente com uma VNet gerada ou existente, o tipo de rede não pode ser alterado.

As VNets geradas assumem as seguintes características.

Eles são:

  • inacessíveis para você à medida que são criados no locatário da Microsoft
  • acessível ao público através da Internet
  • apenas capaz de alcançar pontos finais acessíveis à Internet

Além disso, eles suportam apenas um subconjunto limitado de recursos de rede, como restrições de IP de entrada e controles de entrada no nível do aplicativo de contêiner.

Use uma VNet existente se precisar de mais recursos de rede do Azure, como:

  • Integração com Application Gateway
  • Grupos de Segurança de Rede
  • Comunicação com recursos por trás de pontos de extremidade privados em sua rede virtual

Os recursos de VNet disponíveis dependem da seleção do seu ambiente.

Seleção de ambiente

Container Apps tem dois tipos de ambiente diferentes, que compartilham muitas das mesmas características de rede com algumas diferenças importantes.

Tipo de ambiente Description Tipos de planos suportados
Perfis de carga de trabalho Suporta rotas definidas pelo usuário (UDR) e saída através do NAT Gateway. O tamanho mínimo necessário da sub-rede é /27. Consumo, Dedicado
Apenas consumo Não suporta rotas definidas pelo usuário (UDR), saída através do gateway NAT, emparelhamento através de um gateway remoto ou outra saída personalizada. O tamanho mínimo necessário da sub-rede é /23. Consumo

Níveis de acessibilidade

Você pode configurar se seu aplicativo de contêiner permite a entrada pública ou a entrada somente de dentro de sua rede virtual no nível do ambiente.

Nível de acessibilidade Description
Externa Permite que seu aplicativo de contêiner aceite solicitações públicas. Os ambientes externos são implantados com um IP virtual em um endereço IP externo voltado para o público.
Interno Os ambientes internos não têm pontos de extremidade públicos e são implantados com um IP virtual (VIP) mapeado para um endereço IP interno. O ponto de extremidade interno é um ILB (balanceador de carga interno) do Azure e os endereços IP são emitidos a partir da lista de endereços IP privados da VNet personalizada.

Configuração de VNet personalizada

Ao criar uma rede virtual personalizada, lembre-se das seguintes situações:

  • Se você quiser que seu aplicativo de contêiner restrinja todo o acesso externo, crie um ambiente interno de Aplicativos de contêiner.

  • Se você usar sua própria rede virtual, precisará fornecer uma sub-rede dedicada exclusivamente ao ambiente do Aplicativo de Contêiner implantado. Esta sub-rede não está disponível para outros serviços.

  • Os endereços de rede são atribuídos a partir de um intervalo de sub-redes definido à medida que o ambiente é criado.

    • Você pode definir o intervalo de sub-rede usado pelo ambiente Container Apps.

    • Você pode restringir as solicitações de entrada para o ambiente exclusivamente para a VNet implantando o ambiente como interno.

Nota

Quando você fornece sua própria rede virtual, recursos gerenciados adicionais são criados. Estes recursos incorrem em custos às taxas associadas.

Ao começar a projetar a rede em torno de seu aplicativo de contêiner, consulte Planejar redes virtuais.

Diagram of how Azure Container Apps environments use an existing V NET, or you can provide your own.

Nota

Não é permitido mover VNets entre diferentes grupos de recursos ou assinaturas se a VNet estiver em uso por um ambiente de Aplicativos de Contêiner.

Comportamento do proxy de borda HTTP

Os Aplicativos de Contêiner do Azure usam o proxy Envoy como um proxy HTTP de borda. O Transport Layer Security (TLS) é encerrado na borda e as solicitações são roteadas com base em suas regras de divisão de tráfego e roteia o tráfego para o aplicativo correto.

Os aplicativos HTTP são dimensionados com base no número de solicitações e conexões HTTP. O Envoy encaminha o tráfego interno dentro de clusters.

As conexões downstream suportam HTTP1.1 e HTTP2 e o Envoy deteta e atualiza automaticamente as conexões se a conexão do cliente exigir uma atualização.

As conexões upstream são definidas definindo a transportpropriedade no objeto de entrada .

Configuração de ingresso

Na seção de ingresso, você pode definir as seguintes configurações:

  • Nível de acessibilidade: você pode definir seu aplicativo de contêiner como acessível externa ou internamente no ambiente. Uma variável CONTAINER_APP_ENV_DNS_SUFFIX de ambiente é usada para resolver automaticamente o sufixo FQDN (nome de domínio totalmente qualificado) para seu ambiente. Ao se comunicar entre aplicativos de contêiner dentro do mesmo ambiente, você também pode usar o nome do aplicativo. Para obter mais informações sobre como acessar seus aplicativos, consulte Ingress in Azure Container Apps.

  • Regras de divisão de tráfego: você pode definir regras de divisão de tráfego entre diferentes revisões do seu aplicativo. Para obter mais informações, consulte Divisão de tráfego.

Para obter mais informações sobre diferentes cenários de rede, consulte Ingress in Azure Container Apps.

Dependências do portal

Para cada aplicativo nos Aplicativos de Contêiner do Azure, há duas URLs.

O tempo de execução dos Aplicativos de Contêiner gera inicialmente um FQDN (nome de domínio totalmente qualificado) usado para acessar seu aplicativo. Consulte a URL do Aplicativo na janela Visão geral do seu aplicativo de contêiner no portal do Azure para obter o FQDN do seu aplicativo de contêiner.

Um segundo URL também é gerado para você. Esse local concede acesso ao serviço de streaming de log e ao console. Se necessário, talvez seja necessário adicionar https://azurecontainerapps.dev/ à lista de permissões do seu firewall ou proxy.

Portas e endereços IP

As portas a seguir são expostas para conexões de entrada.

Protocolo Porta(s)
HTTP/HTTPS 80, 443

Os endereços IP são divididos nos seguintes tipos:

Type Description
Endereço IP de entrada público Usado para tráfego de aplicativos em uma implantação externa e tráfego de gerenciamento em implantações internas e externas.
IP público de saída Usado como o IP "de" para conexões de saída que saem da rede virtual. Essas conexões não são roteadas por uma VPN. Os IPs de saída podem mudar ao longo do tempo. O uso de um gateway NAT ou outro proxy para tráfego de saída de um ambiente de Aplicativos de Contêiner só é suportado em um ambiente de perfis de carga de trabalho.
Endereço IP do balanceador de carga interno Esse endereço só existe em um ambiente interno.

Sub-rede

A integração de rede virtual depende de uma sub-rede dedicada. Como os endereços IP são alocados em uma sub-rede e quais tamanhos de sub-rede são suportados depende de qual plano você está usando nos Aplicativos de Contêiner do Azure.

Selecione cuidadosamente o tamanho da sub-rede. Os tamanhos das sub-redes não podem ser modificados depois de criar um ambiente de Aplicativos de Contêiner.

Diferentes tipos de ambiente têm diferentes requisitos de sub-rede:

  • /27 é o tamanho mínimo de sub-rede necessário para a integração de rede virtual.

  • Sua sub-rede deve ser delegada ao Microsoft.App/environments.

  • Ao usar um ambiente externo com entrada externa, o tráfego de entrada é direcionado através do IP público da infraestrutura em vez de através da sua sub-rede.

  • O Container Apps reserva automaticamente 12 endereços IP para integração com a sub-rede. O número de endereços IP necessários para a integração da infraestrutura não varia com base nas demandas de escala do ambiente. Endereços IP adicionais são alocados de acordo com as seguintes regras, dependendo do tipo de perfil de carga de trabalho que você está usando, mais endereços IP são alocados dependendo do perfil de carga de trabalho do seu ambiente:

    • Perfil de carga de trabalho dedicada: à medida que seu aplicativo de contêiner se expande, cada nó tem um endereço IP atribuído.

    • Perfil de carga de trabalho de consumo: cada endereço IP pode ser compartilhado entre várias réplicas. Ao planejar quantos endereços IP são necessários para seu aplicativo, planeje 1 endereço IP para cada 10 réplicas.

  • Quando você faz uma alteração em uma revisão no modo de revisão única, o espaço de endereçamento necessário é dobrado por um curto período de tempo para oferecer suporte a implantações sem tempo de inatividade. Isso afeta as réplicas ou nós reais e disponíveis com suporte para um determinado tamanho de sub-rede. A tabela a seguir mostra os endereços máximos disponíveis por bloco CIDR e o efeito na escala horizontal.

    Tamanho da sub-rede EndereçosIP disponíveis 1 Nós máximos (perfil de carga de trabalho dedicada)2 Máximo de réplicas (perfil de carga de trabalho de consumo)2
    /23 500 250 2500
    /24 244 122 1,220
    /25 116 58 580
    /26 52 26 260
    /27 20 10 100

    1 Os endereços IP disponíveis são o tamanho da sub-rede menos os 12 endereços IP necessários para a infraestrutura dos Aplicativos de Contêiner do Azure.
    2 Isso é contabilizar aplicativos no modo de revisão única.

Restrições de intervalo de endereços de sub-rede

Os intervalos de endereços de sub-rede não podem se sobrepor aos seguintes intervalos reservados pelos Serviços Kubernetes do Azure:

  • 169.254.0.0/16
  • 172.30.0.0/16
  • 172.31.0.0/16
  • 192.0.2.0/24

Além disso, um ambiente de perfis de carga de trabalho reserva os seguintes endereços:

  • 100.100.0.0/17
  • 100.100.128.0/19
  • 100.100.160.0/19
  • 100.100.192.0/19

Configuração de sub-rede com CLI

À medida que um ambiente de Aplicativos de Contêiner é criado, você fornece IDs de recursos para uma única sub-rede.

Se você estiver usando a CLI, o parâmetro para definir a ID do recurso de sub-rede será infrastructure-subnet-resource-id. A sub-rede hospeda componentes de infraestrutura e contêineres de aplicativos de usuário.

Se você estiver usando a CLI do Azure com um ambiente Somente consumo e o intervalo platformReservedCidr estiver definido, ambas as sub-redes não deverão se sobrepor ao intervalo IP definido em platformReservedCidr.

Rotas

Rotas definidas pelo usuário (UDR)

As Rotas Definidas pelo Utilizador (UDR) e a entrada controlada através do NAT Gateway são suportadas no ambiente de perfis de carga de trabalho. No ambiente Apenas de consumo, estas funcionalidades não são suportadas.

Nota

Ao usar UDR com o Firewall do Azure em Aplicativos de Contêiner do Azure, você precisa adicionar determinados FQDN e tags de serviço à lista de permissões do firewall. Para saber mais, consulte Configurando o UDR com o Firewall do Azure.

  • Pode usar UDRs com ambientes de perfis de carga de trabalho para restringir o tráfego de saída da aplicação contentora através da Firewall do Azure ou de outras aplicações de rede.

  • A configuração de UDR é feita fora do âmbito do ambiente Container Apps.

Diagram of how UDR is implemented for Container Apps.

O Azure cria uma tabela de rotas padrão para suas redes virtuais após a criação. Ao implementar uma tabela de rotas definida pelo usuário, você pode controlar como o tráfego é roteado em sua rede virtual. Por exemplo, você pode criar um UDR que roteie todo o tráfego para o firewall.

Configurando o UDR com o Firewall do Azure

As rotas definidas pelo usuário só são suportadas em um ambiente de perfis de carga de trabalho. As seguintes regras de aplicativo e rede devem ser adicionadas à lista de permissões do seu firewall, dependendo dos recursos que você está usando.

Nota

Para obter um guia sobre como configurar UDR com Aplicativos de Contêiner para restringir o tráfego de saída com o Firewall do Azure, visite o como para Aplicativos de Contêiner e Firewall do Azure.

Regras de aplicação

As regras de aplicativo permitem ou negam tráfego com base na camada de aplicativo. As seguintes regras de aplicativo de firewall de saída são necessárias com base no cenário.

Cenários FQDNs Description
Todos os cenários mcr.microsoft.com, *.data.mcr.microsoft.com Esses FQDNs para o Registro de Contêiner da Microsoft (MCR) são usados pelos Aplicativos de Contêiner do Azure e essas regras de aplicativo ou as regras de rede para MCR devem ser adicionadas à lista de permissões ao usar os Aplicativos de Contêiner do Azure com o Firewall do Azure.
Azure Container Registry (ACR) O seu-ACR-endereço, , *.blob.core.windows.netlogin.microsoft.com Esses FQDNs são necessários ao usar os Aplicativos de Contêiner do Azure com ACR e Firewall do Azure.
Azure Key Vault Seu-Azure-Key-Vault-address, login.microsoft.com Esses FQDNs são necessários, além da marca de serviço necessária para a regra de rede do Cofre de Chaves do Azure.
Identidade Gerida *.identity.azure.net, , , login.microsoftonline.com*.login.microsoftonline.com*.login.microsoft.com Esses FQDNs são necessários ao usar a identidade gerenciada com o Firewall do Azure em Aplicativos de Contêiner do Azure.
Registro do Docker Hub hub.docker.com, , registry-1.docker.ioproduction.cloudflare.docker.com Se você estiver usando o registro do Docker Hub e quiser acessá-lo através do firewall, precisará adicionar esses FQDNs ao firewall.
Regras de rede

As regras de rede permitem ou negam tráfego com base na camada de rede e transporte. As seguintes regras de rede de firewall de saída são necessárias com base no cenário.

Cenários Etiqueta de Serviço Description
Todos os cenários MicrosoftContainerRegistry, AzureFrontDoorFirstParty Essas Marcas de Serviço para o Registro de Contêiner da Microsoft (MCR) são usadas pelos Aplicativos de Contêiner do Azure e essas regras de rede ou as regras de aplicativo para MCR devem ser adicionadas à lista de permissões ao usar os Aplicativos de Contêiner do Azure com o Firewall do Azure.
Azure Container Registry (ACR) AzureContainerRegistry, AzureActiveDirectory Ao usar o ACR com os Aplicativos de Contêiner do Azure, você precisa configurar essas regras de aplicativo usadas pelo Registro de Contêiner do Azure.
Azure Key Vault AzureKeyVault, AzureActiveDirectory Essas tags de serviço são necessárias além do FQDN para a regra de aplicativo para o Cofre de Chaves do Azure.
Identidade Gerida AzureActiveDirectory Ao usar a Identidade Gerenciada com os Aplicativos de Contêiner do Azure, você precisará configurar essas regras de aplicativo usadas pela Identidade Gerenciada.

Nota

Para recursos do Azure que você está usando com o Firewall do Azure não listados neste artigo, consulte a documentação das tags de serviço.

Integração de gateway NAT

Você pode usar o NAT Gateway para simplificar a conectividade de saída para o tráfego de saída da Internet em sua rede virtual em um ambiente de perfis de carga de trabalho.

Quando você configura um gateway NAT em sua sub-rede, o gateway NAT fornece um endereço IP público estático para seu ambiente. Todo o tráfego de saída do seu aplicativo de contêiner é roteado através do endereço IP público estático do NAT Gateway.

Segurança ambiental

Diagram of how to fully lock down your network for Container Apps.

Você pode proteger totalmente seu ambiente de perfis de carga de trabalho de tráfego de rede de entrada e saída executando as seguintes ações:

  • Crie seu ambiente de aplicativo de contêiner interno em um ambiente de perfis de carga de trabalho. Para conhecer as etapas, consulte Gerenciar perfis de carga de trabalho com a CLI do Azure.

  • Integre seus aplicativos de contêiner com um gateway de aplicativo.

  • Configure o UDR para rotear todo o tráfego através do Firewall do Azure.

Criptografia de rede em nível de ambiente (visualização)

Os Aplicativos de Contêiner do Azure dão suporte à criptografia de rede no nível do ambiente usando mTLS (segurança de camada de transporte mútuo). Quando a criptografia de ponta a ponta é necessária, o mTLS criptografa os dados transmitidos entre aplicativos em um ambiente.

Os aplicativos em um ambiente de Aplicativos de Contêiner são autenticados automaticamente. No entanto, o tempo de execução de Aplicativos de Contêiner não oferece suporte a autorização para controle de acesso entre aplicativos que usam o mTLS interno.

Quando seus aplicativos estão se comunicando com um cliente fora do ambiente, a autenticação bidirecional com mTLS é suportada. Para saber mais, consulte Configurar certificados de cliente.

Nota

Habilitar o mTLS para seus aplicativos pode aumentar a latência de resposta e reduzir a taxa de transferência máxima em cenários de alta carga.

Você pode habilitar o mTLS usando os seguintes comandos.

Ao criar:

az containerapp env create \
    --name <environment-name> \
    --resource-group <resource-group> \
    --location <location> \
    --enable-mtls

Para um aplicativo de contêiner existente:

az containerapp env update \
    --name <environment-name> \
    --resource-group <resource-group> \
    --enable-mtls

DNS

  • DNS personalizado: se sua rede virtual usar um servidor DNS personalizado em vez do servidor DNS padrão fornecido pelo Azure, configure seu servidor DNS para encaminhar consultas DNS não resolvidas para 168.63.129.16. Os resolvedores recursivos do Azure usam esse endereço IP para resolver solicitações. Ao configurar seu NSG ou firewall, não bloqueie o 168.63.129.16 endereço, caso contrário, seu ambiente de Aplicativos de Contêiner não funcionará corretamente.

  • Ingresso de escopo de rede virtual: se você planeja usar a entrada de escopo de rede virtual em um ambiente interno, configure seus domínios de uma das seguintes maneiras:

    1. Domínios não personalizados: se você não planeja usar um domínio personalizado, crie uma zona DNS privada que resolva o domínio padrão do ambiente Aplicativos de Contêiner para o endereço IP estático do ambiente de Aplicativos de Contêiner. Você pode usar o DNS Privado do Azure ou seu próprio servidor DNS. Se você usar o DNS Privado do Azure, crie uma Zona DNS privada nomeada como domínio padrão do ambiente do Aplicativo de Contêiner (<UNIQUE_IDENTIFIER>.<REGION_NAME>.azurecontainerapps.io), com um A registro. O A registro contém o nome *<DNS Suffix> e o endereço IP estático do ambiente Container Apps.

    2. Domínios personalizados: se você planeja usar domínios personalizados e estiver usando um ambiente externo de Aplicativos de Contêiner, use um domínio resolúvel publicamente para adicionar um domínio e um certificado personalizados ao aplicativo de contêiner. Se estiver a utilizar um ambiente Container Apps interno, não haverá nenhuma validação para a associação DNS, uma vez que o cluster apenas poderá ser acedido a partir da rede virtual. Adicionalmente, crie uma zona DNS Privado que resolva o domínio apex para o endereço IP estático do ambiente Container Apps. Você pode usar o DNS Privado do Azure ou seu próprio servidor DNS. Se você usar o DNS Privado do Azure, crie uma Zona DNS Privada nomeada como o domínio do ápice, com um A registro que aponte para o endereço IP estático do ambiente de Aplicativos de Contêiner.

O endereço IP estático do ambiente de Aplicativos de Contêiner está disponível no portal do Azure no sufixo DNS personalizado da página do aplicativo de contêiner ou usando o comando CLI az containerapp env list do Azure.

Recursos geridos

Quando você implanta um ambiente interno ou externo em sua própria rede, um novo grupo de recursos é criado na assinatura do Azure onde seu ambiente está hospedado. Este grupo de recursos contém componentes de infraestrutura geridos pela plataforma Azure Container Apps. Não modifique os serviços neste grupo ou o próprio grupo de recursos.

Ambiente de perfis de carga de trabalho

O nome do grupo de recursos criado na assinatura do Azure onde seu ambiente está hospedado é prefixado com por padrão, e o nome do grupo de recursos pode ser personalizado à ME_ medida que você cria seu ambiente de aplicativo de contêiner.

Para ambientes externos, o grupo de recursos contém um endereço IP público usado especificamente para conectividade de entrada com seu ambiente externo e um balanceador de carga. Para ambientes internos, o grupo de recursos contém apenas um Balanceador de Carga.

Além da cobrança padrão dos Aplicativos de Contêiner do Azure, você é cobrado por:

Ambiente apenas de consumo

O nome do grupo de recursos criado na assinatura do Azure onde seu ambiente está hospedado é prefixado com MC_ por padrão, e o nome do grupo de recursos não pode ser personalizado quando você cria um aplicativo de contêiner. O grupo de recursos contém endereços IP públicos usados especificamente para conectividade de saída do seu ambiente e um balanceador de carga.

Além da cobrança padrão dos Aplicativos de Contêiner do Azure, você é cobrado por:

Próximos passos