Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Aplicativos de Contêiner do Azure fornece descoberta e roteamento de serviços internos para que os aplicativos de contêiner possam se comunicar entre si sem gerenciar a infraestrutura. Quando você implanta vários aplicativos de contêiner no mesmo ambiente, a plataforma lida com a resolução de DNS, o balanceamento de carga e o roteamento de tráfego seguro automaticamente.
Se ingress estiver habilitado, cada aplicativo de contêiner obterá um nome de domínio. Você pode disponibilizar esse ponto de extremidade publicamente ou restringi-lo a outros aplicativos de contêiner no mesmo ambiente.
Os aplicativos de contêiner podem alcançar uns aos outros por meio de qualquer um desses métodos:
- FQDN (nome de domínio totalmente qualificado): o domínio gerado padrão
-
Nome do aplicativo: um endereço de formulário
http://<APP_NAME>curto para chamadas internas - Invocação de serviço Dapr: abordagem baseada em sidecar, com novas tentativas e observabilidade integradas.
- Domínio personalizado: seu próprio nome de domínio com um certificado gerenciado
Observação
Quando você chama outro aplicativo de contêiner no mesmo ambiente usando o FQDN ou o nome do aplicativo, o tráfego de rede nunca sai do ambiente.
Por que isso importa
Em uma arquitetura de microsserviços, os serviços precisam chamar uns aos outros de forma confiável. Os Aplicativos de Contêiner do Azure eliminam a carga operacional de configurar descoberta de serviços, gerenciar registros DNS e configurar proxies reversos.
O que a plataforma gerencia para você:
- Registro DNS automático: cada aplicativo de contêiner obtém um nome de host resolvível assim que é implantado.
- Roteamento gerenciado por proxy: todo o tráfego entre aplicativos flui por meio de uma camada de proxy envoy interna que lida com terminação TLS, divisão de tráfego e balanceamento de carga.
- Isolamento por ambiente: pontos de extremidade internos só podem ser acessados dentro do mesmo ambiente, criando um limite de segurança natural.
- Flexibilidade de protocolo: comunicação por HTTP/1.1, HTTP/2 (para gRPC) ou TCP bruto, dependendo das suas necessidades de carga de trabalho.
Esses recursos significam que você pode se concentrar na lógica do aplicativo em vez de encanamento de rede.
Local do aplicativo de contêiner (FQDN)
O nome de domínio totalmente qualificado de cada aplicativo de contêiner é composto pelo nome do aplicativo, um identificador de ambiente exclusivo e a região. Todos esses fragmentos de domínio se enquadram no azurecontainerapps.io domínio de nível superior.
FQDNs externos e internos
A configuração de visibilidade de entrada controla se o aplicativo pode ser acessado de fora do ambiente:
| Visibilidade | Padrão FQDN | Acessível de |
|---|---|---|
| Externo | <APP_NAME>.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io |
Em qualquer lugar (Internet pública) |
| Interna | <APP_NAME>.internal.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io |
Somente o mesmo ambiente |
Quando você define a entrada como interna, o FQDN inclui um .internal. segmento. Outros aplicativos de contêiner no mesmo ambiente ainda podem acessar o aplicativo usando esse endereço, mas as solicitações de fora do ambiente recebem uma 404 resposta do proxy do ambiente. O nome DNS é resolvido para o IP compartilhado do ambiente, mas o proxy rejeita a solicitação se o aplicativo for apenas interno.
Obter um nome de domínio totalmente qualificado
O comando az containerapp show retorna o nome de domínio totalmente qualificado do aplicativo de contêiner.
az containerapp show \
--resource-group <RESOURCE_GROUP_NAME> \
--name <CONTAINER_APP_NAME> \
--query properties.configuration.ingress.fqdn
Neste exemplo, substitua os espaço reservados entre <>pelos seus valores.
O valor retornado desse comando é semelhante a um nome de domínio como seguinte exemplo:
myapp.happyhill-70162bb9.canadacentral.azurecontainerapps.io
FQDNs de rótulos de revisão
Ao atribuir rótulos a revisões específicas, cada rótulo recebe seu próprio FQDN exclusivo, separado por três traços.
<APP_NAME>---<LABEL>.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io
Para aplicativos internos, o padrão inclui o .internal. segmento:
<APP_NAME>---<LABEL>.internal.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io
Os FQDNs de etiqueta permitem redirecionar tráfego diretamente para uma revisão específica. Essa prática é útil para testar novas versões, executar experimentos A/B ou fornecer pontos de extremidade estáveis para implantações de revisão específicas.
Chamar um aplicativo de contêiner pelo nome
A maneira mais simples de chamar outro aplicativo de contêiner de dentro do mesmo ambiente é pelo nome. Envie uma solicitação para http://<CONTAINER_APP_NAME>, e o DNS interno do ambiente resolve o nome automaticamente.
http://my-backend-api
Como funciona a resolução de DNS
Nos bastidores, Aplicativos de Contêiner do Azure usa uma configuração DNS personalizada que converte nomes de aplicativos de contêiner em endereços roteáveis. Quando seu aplicativo faz uma solicitação para o nome de outro aplicativo ou FQDN:
- O servidor DNS do ambiente resolve o nome do host para o endereço do serviço proxy Envoy.
- O proxy Envoy identifica o aplicativo de destino a partir do hostname original.
- O proxy roteia a solicitação para as revisões corretas com base na configuração de tráfego.
Essa arquitetura implica que os aplicativos em contêineres nunca se comunicam diretamente entre os pods. Todo o tráfego passa pela camada de proxy, que fornece terminação TLS, balanceamento de carga e divisão de tráfego.
Dica
Use o nome do aplicativo curto (http://<APP_NAME>) para chamadas entre aplicativos de contêiner no mesmo ambiente. É mais simples do que o FQDN completo e funciona da mesma maneira, pois o DNS resolve ambos os padrões por meio do mesmo proxy.
Protocolos de transporte
Os aplicativos de contêiner dão suporte a três modos de transporte para entrada, configurados por meio da transport propriedade:
| Transporte | Caso de uso | Detalhes |
|---|---|---|
| Automático (padrão) | APIs e serviços Web padrão | Negocia HTTP/1.1 e HTTP/2 automaticamente |
| HTTP/2 | serviços gRPC | Habilita HTTP/2 de ponta a ponta, necessário para gRPC |
| TCP | Protocolos não HTTP (bancos de dados, protocolos personalizados) | Conexões TCP brutas com mapeamento de porta |
Observação
A entrada TCP externa requer uma VNet personalizada. Se você tentar criar um aplicativo TCP externo sem uma VNet personalizada, receberá um ContainerAppTcpRequiresVnet erro. A entrada TCP interna funciona sem uma VNet personalizada.
Ao usar o transporte TCP, você também pode expor portas extras além da porta de entrada primária. Cada porta extra cria um ponto de extremidade TCP separado ao qual outros aplicativos no ambiente podem se conectar.
Divisão de tráfego e roteamento de revisão
Aplicativos de Contêiner do Azure dá suporte a três modos de revisão que afetam a forma como o tráfego é distribuído entre aplicativos de contêiner:
| Modo | Comportamento |
|---|---|
| Single | Todo o tráfego vai para a revisão ativa mais recente. |
| Vários | O tráfego é distribuído entre as revisões por porcentagem, de acordo com suas regras de tráfego. |
| Rótulos | Cada revisão rotulada obtém um FQDN exclusivo para acesso direto. |
No modo múltiplo, quando outro aplicativo de contêiner chama o FQDN do seu aplicativo, o proxy distribui automaticamente as solicitações entre as revisões conforme os pesos configurados. No modo rótulos, os chamadores podem direcionar uma revisão específica usando seu FQDN de rótulo.
Para obter mais informações, consulte Revisões no Aplicativos de Contêiner do Azure.
Invocação do serviço do Dapr
Dapr (Distributed Application Runtime) fornece uma abordagem baseada em sidecar para comunicação entre aplicativos. Ao habilitar o Dapr, seus aplicativos de contêiner ganham invocação de serviço interna com TLS mútuo, repetições automáticas e rastreamento distribuído por meio do Aplicativo Azure Insights.
Como funciona a invocação de Dapr
Cada aplicativo de contêiner habilitado para Dapr executa um processo sidecar junto com o aplicativo. Para chamar outro aplicativo habilitado para Dapr, faça uma solicitação HTTP local para o sidecar da Dapr, que manipula a descoberta e o roteamento do serviço:
http://localhost:3500/v1.0/invoke/<DAPR_APP_ID>/method/<METHOD_NAME>
Por exemplo, para chamar o método catalog em um aplicativo com ID de aplicativo Dapr order-processor:
http://localhost:3500/v1.0/invoke/order-processor/method/catalog
O sidecar resolve o aplicativo alvo por meio de um domínio DNS dedicado e roteia a solicitação por meio da camada de proxy Envoy. Essa é a mesma infraestrutura que manipula o roteamento baseado em FQDN.
Observação
O Dapr usa seu próprio caminho de resolução DNS (o .dapr domínio) separado da resolução FQDN padrão. Os dois caminhos são roteados pela infraestrutura de proxy do ambiente.
ID do aplicativo Dapr
A ID do aplicativo Dapr é a identidade que outros aplicativos usam para invocar seu serviço. Se você não definir uma ID de Aplicativo explícita, o runtime do Dapr usará como padrão o nome do aplicativo de contêiner. A API do ARM mostra appId: null quando você não configura uma ID personalizada, mas o runtime aplica o nome do aplicativo automaticamente. Defina uma ID de Aplicativo personalizada em sua configuração de Dapr se precisar de um identificador diferente.
As IDs do aplicativo Dapr devem ser exclusivas em um ambiente. Se você tentar implantar um aplicativo de contêiner com um ID de aplicativo Dapr já em uso por outro aplicativo, o recurso do contêiner será criado, mas sua revisão não será provisionada (provisioningState: Failed). A mensagem de erro identifica a ID do Aplicativo conflitante e o aplicativo que a possui.
Aplicativos somente Dapr (sem ingresso HTTP)
Você pode habilitar o Dapr em um aplicativo de contêiner sem configurar a entrada HTTP. Nesse caso, o aplicativo não é acessível por meio de um FQDN ou nome de aplicativo, mas outros aplicativos habilitados para Dapr ainda podem invocá-lo por meio da invocação do serviço Dapr. Esse padrão é útil para trabalhadores em segundo plano ou processadores de eventos que só precisam receber chamadas de outros serviços na malha.
Dica
Ao criar um aplicativo sem entrada com o CLI do Azure, omita os sinalizadores --ingress e --target-port. Incluindo --target-port sem --ingress retorna um erro de uso.
Configuração do sidecar Dapr
O sidecar Dapr é configurado por meio das propriedades do aplicativo de contêiner. As configurações de chave incluem:
| Configurações | Descrição |
|---|---|
appId |
O ID do aplicativo Dapr (por padrão, é o nome do aplicativo de contêiner) |
appPort |
A porta na qual seu aplicativo escuta (ou, em caso de falha, a porta de destino do ingress). |
appProtocol |
Protocolo para comunicação de dapr para aplicativo (por exemplo, http, grpc) |
logLevel |
Nível de detalhamento do log do sidecar Dapr. |
enableApiLogging |
Se as chamadas à API dapr devem ser registradas em log |
httpMaxRequestSize |
Tamanho máximo do corpo da solicitação em MB para o servidor HTTP da Dapr |
httpReadBufferSize |
Tamanho máximo do buffer de leitura HTTP em KB |
Para obter mais informações sobre como configurar o Dapr com Aplicativos de Contêiner do Azure, consulte Dapr integration with Aplicativos de Contêiner do Azure.
Segurança para comunicação entre aplicativos
Aplicativos de Contêiner do Azure inclui vários recursos de segurança que afetam a forma como os aplicativos de contêiner se comunicam:
-
TLS por padrão: todo o tráfego entre aplicativos de contêiner é roteado por meio do proxy Envoy, que manipula a terminação TLS. Defina
allowInsecurecomofalse(o padrão) para impor redirecionamentos HTTPS. -
Modo de certificado do cliente (mTLS): configure o TLS mútuo definindo o modo de certificado do cliente como
require,acceptouignore. - Restrições de IP: defina regras de permissão ou negação para restringir quais endereços IP podem acessar seu aplicativo.
- Políticas CORS: Configurar regras de compartilhamento de recursos entre origens para clientes baseados em navegador ao chamarem seus aplicativos de contêiner.
Observação
Ao usar a invocação de serviço Dapr, os sidecars protegem automaticamente a comunicação entre serviços com TLS mútuo. Você não precisa configurar o mTLS separadamente para chamadas Dapr-para-Dapr.
Para obter mais informações, consulte Ingress no Aplicativos de Contêiner do Azure.
Domínios personalizados
Você pode mapear seus próprios nomes de domínio para um aplicativo de contêiner configurando domínios personalizados nas configurações de entrada. Cada domínio personalizado pode referenciar um certificado TLS gerenciado ou carregado.
Domínios personalizados são registrados junto com o FQDN padrão, portanto, seu aplicativo responde a ambos os endereços. Quando outros aplicativos de contêiner no ambiente precisam acessar seu aplicativo, eles podem usar o FQDN padrão, o nome do aplicativo ou seu domínio personalizado.
Para obter mais informações, consulte domínios personalizados no Aplicativos de Contêiner do Azure.
Solução de exemplo
Um exemplo que mostra como chamar entre contêineres usando o FQDN e o Dapr está disponível em Azure Amostras.
Conceitos relacionados
Entender a comunicação entre aplicativos no Aplicativos de Contêiner do Azure se conecta a vários tópicos relacionados:
- Ambientes nos Aplicativos de Contêiner do Azure: limite compartilhado onde os aplicativos de contêiner descobrem e se comunicam entre si.
- Entrada no Aplicativos de Contêiner do Azure: como configurar endpoints externos e internos, TLS e regras de roteamento
- Integração do Dapr com Aplicativos de Contêiner do Azure: cobertura mais profunda dos componentes do Dapr, pub/sub e gerenciamento de estado junto com a invocação de serviço.
- Rede no Aplicativos de Contêiner do Azure: integração VNet, pontos de extremidade privados e segurança de rede para seu ambiente
- Revisionamentos no Aplicativos de Contêiner do Azure: como os modos de revisão e a divisão de tráfego afetam o roteamento entre aplicativos