Compartir vía

Comunicación entre aplicaciones de contenedor en Azure Container Apps

Azure Container Apps proporciona detección y enrutamiento de servicios integrados para que las aplicaciones de contenedor puedan comunicarse entre sí sin administrar la infraestructura. Al implementar varias aplicaciones de contenedor en el mismo entorno, la plataforma controla automáticamente la resolución DNS, el equilibrio de carga y el enrutamiento de tráfico seguro.

Si la entrada está habilitada, cada aplicación contenedora obtiene un nombre de dominio. Puede hacer que ese punto de conexión esté disponible públicamente o restringirlo a otras aplicaciones de contenedor en el mismo entorno.

Las aplicaciones de contenedor pueden comunicarse entre sí a través de cualquiera de estos métodos:

  • Nombre de dominio completo (FQDN): el dominio generado predeterminado
  • Nombre de la aplicación: una dirección de forma http://<APP_NAME> abreviada para llamadas internas
  • Invocación del servicio Dapr: un enfoque basado en sidecar con reintentos integrados y observabilidad
  • Dominio personalizado: su propio nombre de dominio con un certificado administrado

Nota:

Cuando se llama a otra aplicación contenedora en el mismo entorno mediante el nombre de aplicación o FQDN, el tráfico de red nunca deja el entorno.

¿Por qué es importante?

En una arquitectura de microservicios, los servicios deben llamarse entre sí de forma confiable. Azure Container Apps elimina la carga operativa de configurar la detección de servicios, administrar registros DNS y configurar servidores proxy inversos.

Esto es lo que gestiona la plataforma para ti:

  • Registro DNS automático: cada aplicación contenedora obtiene un nombre de host que se puede resolver en cuanto se implementa.
  • Enrutamiento administrado por proxy: todo el tráfico entre aplicaciones fluye a través de una capa de proxy de Envoy integrada que controla la terminación TLS, la división del tráfico y el equilibrio de carga.
  • Aislamiento delimitado por entorno: los endpoints internos solo son accesibles desde dentro del mismo entorno, lo que crea un límite de seguridad natural.
  • Flexibilidad del protocolo: comunicación a través de HTTP/1.1, HTTP/2 (para gRPC) o TCP sin procesar en función de las necesidades de la carga de trabajo.

Estas funcionalidades significan que puede centrarse en la lógica de la aplicación en lugar de en la fontanería de red.

Ubicación de la aplicación contenedor (FQDN)

El nombre de dominio completo de cada aplicación contenedor se compone del nombre de la aplicación, un identificador de entorno único y la región. Todos estos fragmentos de dominio se encuentran en el dominio de azurecontainerapps.io nivel superior.

Nombre de dominio completamente calificado para la aplicación de contenedor de Azure Container Apps.

FQDN externos e internos

La configuración de visibilidad de entrada controla si la aplicación es accesible desde fuera del entorno:

Visibilidad Patrón FQDN Accesible desde
Externo <APP_NAME>.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io Cualquier lugar (internet público)
Interno <APP_NAME>.internal.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io Solo en el mismo entorno

Al establecer la entrada en interna, el FQDN incluye un .internal. segmento. Otras aplicaciones de contenedor del mismo entorno todavía pueden llegar a la aplicación mediante esta dirección, pero las solicitudes desde fuera del entorno reciben una 404 respuesta del proxy del entorno. El nombre DNS se resuelve en la dirección IP compartida del entorno, pero el proxy rechaza la solicitud porque la aplicación es solo interna.

Obtención de un nombre de dominio completo

El comando az containerapp show devuelve el nombre de dominio completo de una aplicación contenedora.

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

En este ejemplo, reemplace los marcadores de posición rodeados por <> por sus valores.

El valor devuelto por este comando es similar a un nombre de dominio como el del ejemplo siguiente:

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

Etiquetas de revisión de FQDNs

Al asignar etiquetas a revisiones específicas, cada etiqueta obtiene su propio FQDN único mediante un separador de tres guiones:

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

En el caso de las aplicaciones internas, el patrón incluye el .internal. segmento:

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

Los FQDN de etiqueta permiten enviar tráfico directamente a una revisión específica. Esta práctica es útil para probar nuevas versiones, ejecutar experimentos A/B o proporcionar puntos de conexión estables para implementaciones de revisiones específicas.

Llame a una app contenedor por su nombre

La manera más sencilla de llamar a otra aplicación contenedora desde el mismo entorno es por su nombre. Envíe una solicitud a http://<CONTAINER_APP_NAME>y el DNS integrado del entorno resuelve automáticamente el nombre.

http://my-backend-api

Funcionamiento de la resolución DNS

En segundo plano, Azure Container Apps usa una configuración DNS personalizada que traduce los nombres de aplicación de contenedor en direcciones enrutables. Cuando la aplicación realiza una solicitud al nombre o el FQDN de otra aplicación:

  1. El servidor DNS del entorno resuelve el nombre de host en la dirección del servicio proxy de Envoy.
  2. El proxy de Envoy identifica la aplicación de destino del nombre de host original.
  3. El proxy enruta la solicitud a las revisiones correctas en función de la configuración del tráfico.

Esta arquitectura significa que las aplicaciones de contenedor nunca se comunican directamente con los pods de los demás. Todo el tráfico pasa a través de la capa de proxy, que proporciona terminación TLS, equilibrio de carga y división de tráfico.

Sugerencia

Use el nombre corto de la aplicación (http://<APP_NAME>) para las llamadas entre aplicaciones de contenedor en el mismo entorno. Es más sencillo que el FQDN completo y funciona de la misma manera, ya que DNS resuelve ambos patrones a través del mismo proxy.

Protocolos de transporte

Las aplicaciones de contenedor admiten tres modos de transporte para la entrada, configurados a través de la transport propiedad :

Transporte Caso de uso Detalles
Automático (valor predeterminado) API web estándar y servicios Negocia http/1.1 y HTTP/2 automáticamente
HTTP/2 Servicios gRPC Habilita HTTP/2 de un extremo a otro, necesario para gRPC
TCP Protocolos no HTTP (bases de datos, protocolos personalizados) Conexiones TCP crudas con asignación de puertos

Nota:

La entrada TCP externa requiere una red virtual personalizada. Si intenta crear una aplicación TCP externa sin una red virtual personalizada, recibirá un ContainerAppTcpRequiresVnet error. La entrada TCP interna funciona sin una red virtual personalizada.

Al usar el transporte TCP, también puede exponer puertos adicionales más allá del puerto de entrada principal. Cada puerto adicional crea un punto de conexión TCP independiente al que otras aplicaciones del entorno se pueden conectar.

División de tráfico y enrutamiento de revisiones

Azure Container Apps admite tres modos de revisión que afectan a cómo se distribuye el tráfico entre aplicaciones de contenedor:

Modo Comportamiento
único Todo el tráfico va a la revisión activa más reciente.
Varios El tráfico se divide entre revisiones por porcentaje, en función de las reglas de tráfico.
Etiquetas Cada revisión etiquetada obtiene un FQDN único para el acceso directo.

En varios modos, cuando otra aplicación contenedora llama al FQDN de la aplicación, el proxy distribuye automáticamente las solicitudes entre revisiones según los pesos configurados. En el modo de etiquetas , los autores de llamadas pueden tener como destino una revisión específica mediante su FQDN de etiqueta.

Para obtener más información, consulte Revisiones en Azure Container Apps.

Invocación del servicio Dapr

Dapr (Distributed Application Runtime) proporciona un enfoque basado en sidecar para la comunicación entre aplicaciones. Al habilitar Dapr, las aplicaciones de contenedor obtienen invocación de servicio integrada con TLS mutua, reintentos automáticos y seguimiento distribuido a través de Aplicación de Azure Insights.

El diagrama que muestra la ubicación de la aplicación de contenedor de Azure Container Apps con Dapr.

Funcionamiento de la invocación de Dapr

Cada aplicación contenedora habilitada para Dapr ejecuta un proceso "sidecar" junto a su aplicación. Para llamar a otra aplicación habilitada para Dapr, realice una solicitud HTTP local al sidecar de Dapr, que controla la detección y el enrutamiento del servicio:

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

Por ejemplo, para llamar al método catalog en una aplicación con un ID de aplicación Dapr de order-processor:

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

Sidecar resuelve la aplicación de destino a través de un dominio DNS dedicado y enruta la solicitud a través de la capa de proxy de Envoy. Esta es la misma infraestructura que controla el enrutamiento basado en FQDN.

Nota:

Dapr usa su propia ruta de acceso de resolución DNS (el dominio .dapr) independiente de la resolución de FQDN estándar. Ambas rutas de acceso se enrutan a través de la infraestructura de proxy del entorno.

Id. de aplicación de Dapr

El id. de aplicación de Dapr es la identidad que usan otras aplicaciones para invocar el servicio. Si no establece un identificador de aplicación explícito, el entorno de ejecución de Dapr tiene como valor predeterminado el nombre de la aplicación contenedora. La API de ARM muestra appId: null cuando no configura un identificador personalizado, pero el tiempo de ejecución aplica automáticamente el nombre de la aplicación. Establezca un identificador de aplicación personalizado en la configuración de Dapr si necesita un identificador diferente.

Los identificadores de aplicación dapr deben ser únicos dentro de un entorno. Si intenta implementar una aplicación contenedora con un identificador de aplicación de Dapr que ya está en uso por otra aplicación, se crea el recurso de aplicación contenedor, pero su revisión no se puede aprovisionar (provisioningState: Failed). El mensaje de error identifica el identificador de aplicación en conflicto y la aplicación que la posee.

Aplicaciones solo Dapr (sin entrada HTTP)

Puede habilitar Dapr en una aplicación contenedora sin configurar la entrada HTTP. En este caso, la aplicación no es accesible a través de un nombre de aplicación o FQDN, pero otras aplicaciones habilitadas para Dapr todavía pueden invocarla a través de la invocación del servicio Dapr. Este patrón es útil para trabajos en segundo plano o procesadores de eventos que solo necesitan recibir llamadas de otros servicios de la malla.

Sugerencia

Al crear una aplicación sin entrada con el CLI de Azure, omita las marcas --ingress y --target-port. Incluir --target-port sin --ingress devuelve un error de uso.

Configuración de sidecar de Dapr

Configure el sidecar de Dapr a través de las propiedades de la aplicación contenedora. Entre las opciones de configuración clave se incluyen:

Configuración Descripción
appId Id. de aplicación de Dapr (el valor predeterminado es el nombre de la aplicación contenedora)
appPort El puerto en el que escucha la aplicación (retrocede al puerto de destino de entrada)
appProtocol Protocolo para la comunicación de Dapr a aplicación (por ejemplo, http, grpc)
logLevel Verbosidad del registro del sidecar de Dapr
enableApiLogging Indica si se deben registrar llamadas API de Dapr
httpMaxRequestSize Tamaño máximo del cuerpo de la solicitud en MB para el servidor HTTP de Dapr
httpReadBufferSize Tamaño máximo del búfer de lectura HTTP en KB

Para obtener más información sobre cómo configurar Dapr con Azure Container Apps, consulte Dapr integration with Azure Container Apps.

Seguridad para la comunicación entre aplicaciones

Azure Container Apps incluye varias características de seguridad que afectan a cómo se comunican las aplicaciones de contenedor:

  • TLS de forma predeterminada: todo el tráfico entre las aplicaciones de contenedor se enruta a través del proxy de Envoy, que controla la terminación TLS. Establézcalo allowInsecure en false (valor predeterminado) para aplicar redirecciones HTTPS.
  • Modo de certificado de cliente (mTLS): Configure el TLS mutuo estableciendo el modo de certificado de cliente en require, accept o ignore.
  • Restricciones de IP: defina reglas de permiso o denegación para restringir qué direcciones IP pueden llegar a la aplicación.
  • Directivas de CORS: configure reglas de uso compartido de recursos entre orígenes para clientes basados en explorador que llaman a las aplicaciones de contenedor.

Nota:

Cuando utilizas la invocación de servicios de Dapr, los sidecars de Dapr aseguran automáticamente la comunicación con TLS mutua entre servicios. No es necesario configurar mTLS por separado para las llamadas de Dapr a Dapr.

Para obtener más información, consulte Ingress en Azure Container Apps.

Dominios personalizados

Puede asignar sus propios nombres de dominio a una aplicación contenedora configurando dominios personalizados en la configuración de entrada. Cada dominio personalizado puede hacer referencia a un certificado TLS administrado o cargado.

Los dominios personalizados se registran junto con el FQDN predeterminado, por lo que la aplicación responde a ambas direcciones. Cuando otras aplicaciones de contenedor del entorno necesitan llegar a la aplicación, pueden usar el FQDN predeterminado, el nombre de la aplicación o el dominio personalizado.

Para obtener más información, consulte Dominios personalizados en Azure Container Apps.

Solución de ejemplo

Un ejemplo que muestra cómo llamar entre contenedores mediante el FQDN y Dapr está disponible en Azure Samples.

Comprender la comunicación entre aplicaciones en Azure Container Apps se conecta a varios temas relacionados:

Paso siguiente

Configuración de la entrada para la aplicación contenedora

  • Last updated on