Rede no ambiente de Aplicativos de Contêiner do Azure

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 controle refinado sobre sua rede, você pode fornecer uma VNet existente ao 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	Tipos de planos suportados	Description
Perfis de carga de trabalho	Consumo, Dedicado	Suporta rotas definidas pelo usuário (UDR), saída através do gateway NAT e criação de pontos de extremidade privados no ambiente do aplicativo de contêiner. O tamanho mínimo necessário da sub-rede é /27.
Apenas consumo	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.

Virtual IP

Dependendo da sua configuração de IP virtual, você pode controlar se o ambiente do aplicativo de contêiner permite a entrada pública ou a entrada somente de dentro da sua VNet no nível do ambiente. Essa configuração não pode ser alterada após a criação 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 acessível pela Internet.
Interna	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.

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 transport propriedade 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:

Tipo	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:

Ambiente de perfis de carga de trabalho

• /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.

Ambiente apenas de consumo

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

• Sua sub-rede não deve ser delegada a nenhum serviço.

• O tempo de execução dos Aplicativos de Contêiner reserva um mínimo de 60 IPs para infraestrutura em sua rede virtual. O valor reservado pode aumentar até 256 endereços à medida que os aplicativos em seu ambiente são dimensionados.

• À medida que seus aplicativos são dimensionados, um novo endereço IP é alocado para cada nova réplica.

• 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 reais com suporte disponíveis para um determinado tamanho de sub-rede.

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

Ambiente de perfis de carga de trabalho

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

Ambiente apenas de consumo

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

Se você criou seu ambiente de aplicativos de contêiner com um CIDR de serviço personalizado, verifique se a sub-rede do aplicativo de contêiner (ou qualquer sub-rede emparelhada) não entra em conflito com o intervalo CIDR de serviço personalizado.

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, a sub-rede não deverá 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.

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.net, login.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.io, production.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.

Acesso à rede pública (pré-visualização)

A configuração de acesso à rede pública determina se o ambiente de aplicativos de contêiner é acessível a partir da Internet pública. Se você pode alterar essa configuração depois de criar seu ambiente depende da configuração de IP virtual do ambiente. A tabela a seguir mostra valores válidos para acesso à rede pública, dependendo da configuração de IP virtual do seu ambiente.

Virtual IP	Acesso à rede pública suportado	Description
Externa	Enabled, Disabled	O ambiente de aplicativos de contêiner foi criado com um ponto de extremidade acessível pela Internet. A configuração de acesso à rede pública determina se o tráfego é aceito por meio do ponto de extremidade público ou apenas por meio de pontos de extremidade privados, e a configuração de acesso à rede pública pode ser alterada após a criação do ambiente.
Interna	Disabled	O ambiente de aplicativos de contêiner foi criado sem um ponto de extremidade acessível pela Internet. A configuração de acesso à rede pública não pode ser alterada para aceitar tráfego da Internet.

Para criar pontos de extremidade privados em seu ambiente do Aplicativo de Contêiner do Azure, o acesso à rede pública deve ser definido como Disabled.

As políticas de rede do Azure são suportadas com o sinalizador de acesso à rede pública.

Ponto de extremidade privado (visualização)

Nota

Este recurso é suportado para todas as regiões públicas. O governo e as regiões da China não são suportados.

O ponto de extremidade privado do Azure permite que os clientes localizados em sua rede privada se conectem com segurança ao seu ambiente de Aplicativos de Contêiner do Azure por meio do Azure Private Link. Uma conexão de link privado elimina a exposição à internet pública. Os pontos de extremidade privados usam um endereço IP privado em seu espaço de endereço de rede virtual do Azure.

Esse recurso é suportado para planos de consumo e dedicado em ambientes de perfil de carga de trabalho.

Tutoriais

• Para saber mais sobre como configurar pontos de extremidade privados em Aplicativos de Contêiner do Azure, consulte o tutorial Usar um ponto de extremidade privado com um ambiente de Aplicativos de Contêiner do Azure.
• A conectividade de link privado com o Azure Front Door é suportada para Aplicativos de Contêiner do Azure. Consulte para criar um link privado com o Azure Front Door para obter mais informações.

Considerações

• Os pontos de extremidade privados nos Aplicativos de Contêiner do Azure dão suporte apenas ao tráfego HTTP de entrada. Não há suporte para tráfego TCP.
• Para usar um ponto de extremidade privado com um domínio personalizado e um domínio do Apex como o tipo de registro Hostname, você deve configurar uma zona DNS privada com o mesmo nome do DNS público. No conjunto de registros, configure o endereço IP privado do ponto de extremidade privado em vez do endereço IP do ambiente do aplicativo contêiner. Ao configurar seu domínio personalizado com CNAME, a configuração não é alterada. Para obter mais informações, consulte Configurar domínio personalizado com certificado existente.
• A VNet do seu endpoint privado pode ser separada da VNet integrada com seu aplicativo de contêiner.
• Você pode adicionar um ponto de extremidade privado a ambientes de perfil de carga de trabalho novos e existentes.

Para se conectar aos seus aplicativos de contêiner por meio de um ponto de extremidade privado, você deve configurar uma zona DNS privada.

Serviço	subrecurso	Nome da zona DNS privada
Aplicativos de contêiner do Azure (Microsoft.App/ManagedEnvironments)	ambiente gerenciado	link privado. {regionName}.azurecontainerapps.io

Segurança ambiental

Nota

Para controlar o tráfego de entrada, você também pode usar pontos de extremidade privados com uma conexão privada com a Porta da Frente do Azure no lugar do Gateway de Aplicativo. Esta funcionalidade está em pré-visualização.

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 ponto a ponto no ambiente de Aplicativos de Contêiner do Azure

Os Aplicativos de Contêiner do Azure dão suporte à criptografia TLS ponto a ponto dentro do ambiente. Habilitar esse recurso criptografa todo o tráfego de rede dentro do ambiente com um certificado privado que é válido dentro do escopo do ambiente de Aplicativos de Contêiner do Azure. Esses certificados são gerenciados automaticamente pelos Aplicativos de Contêiner do Azure.

Nota

Por padrão, a criptografia ponto a ponto está desabilitada. Habilitar a criptografia ponto a ponto 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.

O exemplo a seguir mostra um ambiente com criptografia ponto a ponto habilitada.

1 O tráfego TLS de entrada é encerrado no proxy de entrada na borda do ambiente.

2 O tráfego de e para o proxy de entrada dentro do ambiente é criptografado por TLS com um certificado privado e descriptografado pelo recetor.

3 As chamadas feitas do aplicativo A para o FQDN do aplicativo B são enviadas primeiro para o proxy de entrada de borda e são criptografadas por TLS.

4 As chamadas efetuadas da aplicação A para a aplicação B utilizando o nome da aplicação B são enviadas diretamente para a aplicação B e são encriptadas por TLS.

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 à autorização para controle de acesso entre aplicativos usando a criptografia ponto a ponto interna.

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.

CLI do Azure

Você pode habilitar a criptografia ponto a ponto usando os seguintes comandos.

Ao criar:

az containerapp env create \
    --name <environment-name> \
    --resource-group <resource-group> \
    --location <location> \
    --enable-peer-to-peer-encryption

Para um aplicativo de contêiner existente:

az containerapp env update \
    --name <environment-name> \
    --resource-group <resource-group> \
    --enable-peer-to-peer-encryption

Modelo ARM

Você pode habilitar o mTLS no modelo ARM para ambientes de Aplicativos de Contêiner usando a seguinte configuração.

{
  ...
  "properties": {
       "peerTrafficConfiguration":{
            "encryption": {
                "enabled": "true|false"
            }
        }
  ...
}

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. Para obter mais informações, consulte Criar e configurar uma zona DNS privada do Azure.

  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:

• Um IP público estático padrão para saída se estiver usando um ambiente interno ou externo, mais um IP público estático padrão para entrada se estiver usando um ambiente externo. Se você precisar de mais IPs públicos para saída devido a problemas de SNAT, abra um tíquete de suporte para solicitar uma substituição.

• Um balanceador de carga padrão.

• O custo dos dados processados (em GBs) inclui entrada e saída para operações de gerenciamento.

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:

• Um IP público estático padrão para saída. Se você precisar de mais IPs para saída devido a problemas de SNAT (Source Network Address Translation), abra um tíquete de suporte para solicitar uma substituição.

• Dois balanceadores de carga padrão se estiverem usando um ambiente interno ou um balanceador de carga padrão se estiver usando um ambiente externo. Cada balanceador de carga tem menos de seis regras. O custo dos dados processados (em GBs) inclui entrada e saída para operações de gerenciamento.

Próximos passos

• Usar uma rede virtual personalizada