Partager via

Entrées dans Azure Container Apps

  • Article

Azure Container Apps, par l'activation de l'entrée, vous permet d'exposer votre application conteneur au web public, à votre réseau virtuel (VNET) et à d'autres applications conteneurs dans votre environnement. Les paramètres d’entrée sont appliqués via un ensemble de règles qui contrôlent le routage du trafic externe et interne vers votre application conteneur. Lorsque vous activez l’entrée, vous n’avez pas besoin de créer d’équilibreur de charge Azure, d’adresse IP publique ou d’autres ressources Azure pour activer les requêtes HTTP entrantes ou le trafic TCP.

L'entrée prend en charge :

Exemple de configuration d'entrée présentant l'entrée fractionnée entre deux révisions :

Diagramme montrant une configuration d’entrée divisant le trafic entre deux révisions.

Pour plus d’informations sur la configuration, consultez Configurer les entrées.

l'entrée externe et interne.

Lorsque vous activez l'entrée, vous pouvez choisir entre deux types d'entrées :

  • Externe : Accepte le trafic à partir de l'Internet public et de l'environnement interne de votre application conteneur.
  • Interne : Autorise uniquement l'accès interne à partir de l'environnement de votre application conteneur.

Chaque application conteneur au sein d'un environnement peut être configurée avec différents paramètres d'entrée. Par exemple, dans un scénario avec plusieurs applications de microservice, pour renforcer la sécurité, vous pouvez avoir une application conteneur unique qui reçoit des demandes publiques et transmet les demandes à un service en arrière-plan. Dans ce scénario, vous configurerez l'application conteneur orientée vers le public avec une entrée externe et l'application conteneur orientée vers l'intérieur avec une entrée interne.

Types de protocoles

Container Apps prend en charge deux protocoles d'entrée : HTTP et TCP.

HTTP

Lorsque l'entrée HTTP est activée, votre application conteneur dispose :

  • d'une prise en charge de la terminaison TLS
  • d'une prise en charge de HTTP/1.1 et HTTP/2
  • d'une prise en charge de WebSocket et gRPC
  • Les points de terminaison HTTPS qui utilisent toujours TLS 1.2 ou 1.3, avec terminaison au point d’entrée
  • Les points de terminaison exposent toujours les ports 80 (pour HTTP) et 443 (pour HTTPS).
    • Par défaut, les requêtes HTTP sur le port 80 sont automatiquement redirigées vers HTTPS sur le port 443.
  • Nom de domaine complet (FQDN)
  • Le délai d’expiration de la requête est de 240 secondes.

En-têtes HTTP

L’entrée HTTP ajoute des en-têtes pour transmettre des métadonnées sur la requête cliente à votre application conteneur. Par exemple, l’en-tête X-Forwarded-Proto est utilisé pour identifier le protocole utilisé par le client pour se connecter au service Container Apps. Le tableau suivant répertorie les en-têtes HTTP pertinents pour l’entrée dans Container Apps :

En-tête Description Valeurs
X-Forwarded-Proto Protocole utilisé par le client pour se connecter au service Container Apps. http ou https
X-Forwarded-For Adresse IP du client qui a envoyé la requête.
X-Forwarded-Host Nom d’hôte utilisé pour se connecter au service Container Apps.
X-Forwarded-Client-Cert Certificat client si clientCertificateMode est défini. Liste séparée par des points-virgules de codes de hachage, de certificats et de chaînes. Par exemple : Hash=....;Cert="...";Chain="...";

TCP

Container Apps prend en charge les protocoles TCP autres que HTTP ou HTTPS. Par exemple, vous pouvez utiliser l’entrée TCP pour exposer une application conteneur qui utilise le protocole Redis.

Remarque

L’entrée TCP externe n’est prise en charge que pour les environnements Container Apps qui utilisent un réseau virtuel personnalisé. L’entrée TCP n’est pas prise en charge pour les applications qui acceptent le trafic entrant via un point de terminaison privé.

Une fois l'entrée TCP activée, votre application conteneur :

  • Est accessible à d’autres applications conteneur dans le même environnement via son nom (défini par la propriété name dans la ressource Container Apps) et le numéro de port exposé.
  • Est accessible de l’extérieur via son nom de domaine complet (FQDN) et son numéro de port exposé si l’entrée est définie sur external.

Ports TCP supplémentaires

En plus du port HTTP/TCP principal pour vos applications conteneur, vous pouvez exposer des ports TCP supplémentaires pour permettre aux applications qui acceptent des connexions TCP sur plusieurs ports.

Remarque

Pour utiliser cette fonctionnalité, vous devez disposer de l’extension CLI des applications conteneur. Exécutez az extension add -n containerapp pour installer la dernière version de l’extension CLI des applications conteneur.

Les éléments suivants s’appliquent aux ports TCP supplémentaires :

  • Les ports TCP supplémentaires ne peuvent être externes que si l’application elle-même est définie comme externe et que l’application conteneur utilise un réseau virtuel personnalisé.
  • Tous les ports TCP supplémentaires exposés en externe doivent être uniques dans l’ensemble de l’environnement Container Apps. Cela inclut tous les ports TCP supplémentaires externes, les ports TCP principaux externes et les ports 80/443 utilisés par les entrées HTTP intégrées. Si les ports supplémentaires sont internes, le même port peut être partagé par plusieurs applications.
  • Si aucun port exposé n’est fourni, le port exposé correspond par défaut au port cible.
  • Chaque port cible doit être unique et le même port cible ne peut pas être exposé sur différents ports exposés.
  • Il existe un maximum de cinq ports supplémentaires par application. Si des ports supplémentaires sont requis, ouvrez une demande de support.
  • Seul le port d’entrée principal prend en charge les fonctionnalités HTTP intégrées telles que CORS et l’affinité de session. Lors de l’exécution de HTTP sur les ports TCP supplémentaires, ces fonctionnalités intégrées ne sont pas prises en charge.

Consultez l’article sur les entrées pour plus d’informations sur l’activation de ports supplémentaires pour vos applications conteneur.

Noms de domaine

Vous pouvez accéder à votre application de la manière suivante :

  • Nom de domaine complet (FQDN) par défaut : chaque application dans un environnement Container Apps reçoit automatiquement un nom de domaine complet basé sur le suffixe DNS de l’environnement. Pour personnaliser le suffixe DNS d’un environnement, consultez Suffixe DNS d’environnement personnalisé.
  • Nom de domaine personnalisé : vous pouvez configurer un domaine DNS personnalisé pour votre environnement Container Apps. Pour plus d’informations, consultez Noms de domaine et certificats personnalisés.
  • Nom de l’application : vous pouvez utiliser le nom de l’application pour la communication entre les applications dans le même environnement.

Pour obtenir le FQDN de votre application, consultez Emplacement.

Restrictions d’adresse IP

Container Apps prend en charge les restrictions IP pour les entrées. Vous pouvez créer des règles pour configurer des adresses IP autorisées ou refusées d’accès à votre application conteneur. Pour plus d’informations, consultez Configurer les restrictions IP.

Authentification

Azure Container Apps fournit des fonctionnalités d’authentification et d’autorisation intégrées, pour sécuriser votre application conteneur avec entrée externe. Pour plus d’informations, consultez la page Authentification et autorisation dans Azure Container Apps.

Vous pouvez configurer votre application pour prendre en charge les certificats clients (mTLS) pour l’authentification et le chiffrement du trafic. Pour plus d’informations, consultez Configurer des certificats clients.

Pour plus d’informations sur l’utilisation du chiffrement réseau pair à pair au niveau de l’environnement, consultez la Vue d’ensemble de la mise en réseau.

Fractionnement du trafic

Container Apps vous permet de fractionner le trafic entrant entre les révisions actives. Lorsque vous définissez une règle de fractionnement, vous affectez le pourcentage de trafic entrant pour accéder à différentes révisions. Pour plus d’informations, consultez Fractionnement du trafic.

Affinité de session

L’affinité de session, également appelée sessions collantes, est une fonctionnalité qui vous permet d’acheminer toutes les requêtes HTTP d’un client vers le même réplica d’application conteneur. Cette fonctionnalité est utile pour les applications avec état qui nécessitent une connexion cohérente au même réplica. Pour plus d’informations, consultez l’article Affinité de session.

Partage de ressources cross-origin (CORS)

Par défaut, toutes les requêtes effectuées via le navigateur d’une page vers un domaine qui ne correspondent pas au domaine d’origine de la page sont bloquées. Pour éviter cette restriction pour les services déployés sur Container Apps, vous pouvez activer le partage de ressources inter-origines (CORS).

Pour plus d’informations, consultez Configurer CORS dans Azure Container Apps.

Étapes suivantes

Configurer les entrées