Comunicar entre aplicações container em Azure Container Apps

O Azure Container Apps oferece descoberta e encaminhamento de serviços integrados para que as suas aplicações container possam comunicar entre si sem gerir a infraestrutura. Quando implementa várias aplicações de contentores no mesmo ambiente, a plataforma gere automaticamente a resolução DNS, o balanceamento de carga e o encaminhamento seguro do tráfego.

Se o ingress estiver ativado, cada aplicação container recebe um nome de domínio. Pode tornar esse endpoint disponível publicamente ou restringi-lo a outras aplicações container no mesmo ambiente.

As aplicações container podem contactar-se entre si através de qualquer um destes métodos:

• Nome de domínio totalmente qualificado (FQDN): o domínio padrão
• Nome da aplicação: um endereço curto http://<APP_NAME> para chamadas internas
• Invocação de serviço Dapr: uma abordagem baseada em sidecar com tentativas e observabilidade incorporadas
• Domínio personalizado: o seu próprio nome de domínio com um certificado gerido

Por que é importante

Numa arquitetura de microserviços, os serviços precisam de comunicar entre si de forma fiável. O Azure Container Apps elimina o encargo operacional de configurar a descoberta de serviços, gerir registos DNS e configurar proxies reversos.

Eis o que a plataforma faz por si:

• Registo automático de DNS: Cada aplicação de contentores recebe um nome de host resolvível assim que é implementada.
• Encaminhamento gerido por proxy: Todo o tráfego inter-app passa através de uma camada proxy Envoy incorporada que trata da terminação TLS, divisão de tráfego e balanceamento de carga.
• Isolamento no âmbito do ambiente: Os endpoints internos apenas são acessíveis a partir do mesmo ambiente, criando uma fronteira natural de segurança.
• Flexibilidade do protocolo: Comunicação via HTTP/1.1, HTTP/2 (para gRPC) ou TCP bruto, dependendo das suas necessidades de carga de trabalho.

Estas capacidades permitem-lhe focar-se na lógica da aplicação em vez da canalização de rede.

Localização da aplicação de contentores (FQDN)

O domínio totalmente qualificado de cada app container é composto pelo nome da app, um identificador de ambiente único e a região. Estes fragmentos de domínio enquadram-se todos no azurecontainerapps.io domínio de nível superior.

FQDNs externos e internos

A definição de visibilidade de entrada controla se a sua aplicação é acessível a partir de fora do ambiente:

Quando defines o ingress como interno, o FQDN inclui um .internal. segmento. Outras aplicações container no mesmo ambiente ainda podem aceder à aplicação usando este endereço, mas pedidos de fora do ambiente recebem uma 404 resposta do proxy do ambiente. O nome DNS corresponde ao endereço IP partilhado do ambiente, mas o proxy rejeita o pedido porque a aplicação é de uso apenas interno.

Obter nome de domínio totalmente qualificado

O az containerapp show comando retorna o nome de domínio totalmente qualificado de um aplicativo de contêiner.

az containerapp show \
  --resource-group <RESOURCE_GROUP_NAME> \
  --name <CONTAINER_APP_NAME> \
  --query properties.configuration.ingress.fqdn

(Get-AzContainerApp -Name <CONTAINER_APP_NAME> -ResourceGroupName <RESOURCE_GROUP_NAME>).Configuration.IngressFqdn

Neste exemplo, substitua os espaços reservados cercados por <> com os seus valores.

O valor retornado desse comando é semelhante a um nome de domínio como o exemplo a seguir:

myapp.happyhill-70162bb9.canadacentral.azurecontainerapps.io

Etiquetas de revisão FQDNs

Quando atribui etiquetas a revisões específicas, cada uma recebe um FQDN único, usando três hífens como separador:

<APP_NAME>---<LABEL>.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io

Para aplicações internas, o padrão inclui o segmento .internal. :

<APP_NAME>---<LABEL>.internal.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io

Os FQDNs de etiqueta permitem que você envie tráfego diretamente para uma revisão específica. Esta prática é útil para testar novas versões, executar experiências A/B ou fornecer endpoints estáveis para implementações específicas de revisões.

Chamar um aplicativo de contêiner pelo nome

A forma mais direta de chamar outra aplicação container a partir do mesmo ambiente é pelo seu nome. Envie um pedido para http://<CONTAINER_APP_NAME>, e o DNS incorporado do ambiente resolve automaticamente o nome.

http://my-backend-api

Como funciona a resolução DNS

Nos bastidores, o Azure Container Apps utiliza uma configuração DNS personalizada que traduz nomes de aplicações container em endereços roteáveis. Quando a sua aplicação faz um pedido ao nome ou FQDN de outra aplicação:

1. O servidor DNS do ambiente resolve o nome do host para o endereço do serviço de proxy Envoy.
2. O proxy Envoy identifica a aplicação-alvo a partir do nome de host original.
3. O proxy encaminha o pedido para a(s) revisão(ões) correta(s) com base na configuração do seu tráfego.

Esta arquitetura significa que as aplicações container nunca comunicam diretamente com os pods umas das outras. Todo o tráfego passa pela camada proxy, que fornece terminação TLS, balanceamento de carga e divisão de tráfego.

Protocolos de transporte

As aplicações container suportam três modos de transporte para entrada, configurados através da transport propriedade:

Quando usas transporte TCP, também podes expor portas extra para além da porta de entrada principal. Cada porta extra cria um endpoint TCP separado ao qual outras aplicações no ambiente podem ligar-se.

Divisão de tráfego e encaminhamento de revisão

O Azure Container Apps suporta três modos de revisão que afetam a forma como o tráfego é distribuído entre as aplicações container:

Em modo múltiplo, quando outra aplicação container chama o FQDN da sua aplicação, o proxy distribui automaticamente os pedidos entre revisões de acordo com os seus pesos configurados. No modo de rótulos, os chamadores podem direcionar uma revisão específica usando o rótulo FQDN.

Para mais informações, consulte Revisões em Azure Container Apps.

Invocação do serviço Dapr

Dapr (Distributed Application Runtime) oferece uma abordagem de sidecar para a comunicação entre aplicações. Ao ativar o Dapr, as suas aplicações container ganham invocação de serviço integrada com TLS mútuo, tentativas automáticas e rastreamento distribuído através do Aplicação Azure Insights.

Como funciona a invocação Dapr

Cada aplicação de contentores habilitada com Dapr executa um processo sidecar ao lado da sua aplicação. Para chamar outra aplicação habilitada com Dapr, faça um pedido HTTP local ao sidecar Dapr, que gestiona a descoberta de serviços e o encaminhamento.

http://localhost:3500/v1.0/invoke/<DAPR_APP_ID>/method/<METHOD_NAME>

Por exemplo, chamar o catalog método numa aplicação com um ID de aplicação Dapr de order-processor:

http://localhost:3500/v1.0/invoke/order-processor/method/catalog

O sidecar resolve a aplicação alvo através de um domínio DNS dedicado e encaminha o pedido pela camada proxy Envoy. Esta é a mesma infraestrutura que gere o encaminhamento baseado em FQDN.

ID da aplicação Dapr

O ID da aplicação Dapr é a identidade que outras aplicações usam para invocar o seu serviço. Se não definires um ID Aplicação explícito, o runtime do Dapr assume por defeito o nome da tua aplicação em contentor. A API ARM mostra appId: null quando não configuras um ID personalizado, mas o tempo de execução aplica automaticamente o nome da app. Defina um ID de aplicação personalizado na sua configuração Dapr se precisar de um identificador diferente.

Os IDs de aplicações Dapr devem ser únicos dentro de um ambiente. Se tentar implementar uma aplicação container com um ID de aplicação Dapr que já está em uso por outra aplicação, o recurso da app container é criado mas a sua revisão falha em provisionar (provisioningState: Failed). A mensagem de erro identifica o ID da aplicação em conflito e a aplicação que o possui.

Aplicações só para DAPR (sem entrada HTTP)

Podes ativar o Dapr numa aplicação container sem configurar a entrada HTTP. Neste caso, a aplicação não é acessível através de um FQDN ou nome de app, mas outras aplicações com Dapr ainda podem invocá-la através da invocação do serviço Dapr. Este padrão é útil para trabalhadores em segundo plano ou processadores de eventos que só precisam de receber chamadas de outros serviços na malha.

Configuração do sidecar do Dapr

Configuras o sidecar Dapr através das propriedades da tua app container. Definições principais incluem:

Para mais informações sobre a configuração do Dapr com Azure Container Apps, consulte a integração Dapr com Azure Container Apps.

Segurança para comunicação entre aplicações

Azure Container Apps inclui várias funcionalidades de segurança que afetam a forma como as aplicações container comunicam:

• TLS por padrão: Todo o tráfego entre aplicações de contentores é encaminhado através do proxy Envoy, que trata da terminação de TLS. Defina allowInsecure para false (por defeito) para impor redirecionamentos HTTPS.
• Modo de certificado do cliente (mTLS): Configure o TLS mútuo definindo o modo de certificado do cliente para require, accept, ou ignore.
• Restrições de IP: Defina regras de permitir ou recusar para restringir quais endereços IP podem chegar à sua aplicação.
• Políticas CORS: Configure regras de partilha de recursos cross-origin para clientes baseados no navegador que chamam as suas aplicações em contentor.

Para mais informações, consulte Ingress em Azure Container Apps.

Domínios personalizados

Pode mapear os seus próprios nomes de domínio para uma aplicação contentor configurando domínios personalizados nas definições de entrada. Cada domínio personalizado pode referenciar um certificado TLS gerido ou carregado.

Os domínios personalizados são registados juntamente com o FQDN predefinido, por isso a tua aplicação responde a ambos os endereços. Quando outras aplicações container no ambiente precisam de chegar à sua aplicação, podem usar o FQDN predefinido, o nome da aplicação ou o seu domínio personalizado.

Para mais informações, veja Domínios personalizados em Azure Container Apps.

Solução exemplificativa

Um exemplo que mostra como chamar entre contentores usando tanto o FQDN como o Dapr está disponível em Azure Samples.

Conceitos relacionados

Compreender a comunicação entre aplicações no Azure Container Apps liga-se a vários tópicos relacionados:

• Ambientes em Azure Container Apps: A fronteira partilhada onde as aplicações em contentor descobrem e comunicam umas com as outras
• Ingress em Azure Container Apps: Como configurar endpoints externos e internos, TLS e regras de roteamento
• Integração Dapr com os Azure Container Apps: Análise mais aprofundada dos componentes Dapr, publicação/subscrição e gestão de estado juntamente com a invocação de serviços
• Networking in Azure Container Apps: Integração com VNet, endpoints privados e segurança de rede para o seu ambiente
• Revisões em Azure Container Apps : Como os modos de revisão e a divisão do tráfego afetam o encaminhamento entre aplicações

Próximo passo