Configurer l’entrée pour un environnement Azure Container Apps

Azure Container Apps s’exécute dans le contexte d’un environnement, avec son propre réseau virtuel (VNet). Ce réseau virtuel crée une limite sécurisée autour de votre environnement Azure Container Apps.

La configuration d’entrée dans Azure Container Apps détermine la façon dont le trafic réseau externe atteint vos applications. La configuration de l’entrée vous permet de contrôler le routage du trafic, d’améliorer les performances des applications et d’implémenter des stratégies de déploiement avancées. Cet article vous guide tout au long des options de configuration d’entrée disponibles dans Azure Container Apps et vous aide à choisir les paramètres appropriés pour vos charges de travail.

Un environnement Azure Container Apps inclut un proxy d’entrée de périphérie évolutif responsable des fonctionnalités suivantes :

• Protocole TLS (Transport Layer Security),qui déchiffre le trafic TLS au fur et à mesure qu’il entre dans l’environnement. Cette opération déplace le travail de déchiffrement de vos applications conteneur, ce qui réduit leur consommation de ressources et améliore leurs performances.

• Équilibrage de charge et fractionnement du trafic entre les révisions d’application conteneur active. Avoir un contrôle sur l’endroit où vous dirigez le trafic entrant vous permet d’implémenter des modèles tels que le déploiement bleu-vert et effectuer des tests A/B.

• Affinité de session, qui vous permet de générer des applications avec état qui nécessitent une connexion cohérente au même réplica d’application conteneur.

Le diagramme suivant illustre un exemple d’environnement avec le proxy d'entrée routant le trafic vers deux applications conteneurisées.

Par défaut, Azure Container Apps crée votre environnement d’application conteneur avec le mode d’entrée par défaut. Si votre application doit fonctionner à des niveaux de grande échelle, vous pouvez définir le mode d’entrée sur Premium.

Mode d’entrée par défaut

Avec le mode d’entrée par défaut, votre environnement Container Apps a deux instances proxy d’entrée. Les applications conteneur créent davantage d’instances si nécessaire, jusqu’à un maximum de 10. Chaque instance est allouée jusqu’à 1 cœur de processeur virtuel et 2 Go de mémoire.

En mode d’entrée par défaut, aucune facturation n’est appliquée pour la mise à l’échelle du proxy d’entrée ou pour les cœurs de processeur virtuel et la mémoire allouée.

Mode d’entrée Premium

Le mode d’entrée par défaut peut devenir un goulot d’étranglement dans les environnements à grande échelle. En guise d’alternative, le mode d’entrée Premium inclut des fonctionnalités avancées pour vous assurer que votre entrée respecte les demandes de trafic.

Ces fonctionnalités sont les suivantes :

• Prise en charge du profil de charge de travail : les instances proxy d’entrée s’exécutent dans un profil de charge de travail de votre choix. Vous avez le contrôle sur le nombre de cœurs de processeurs virtuels et de ressources de mémoire disponibles pour le proxy.

• Règles de plage d’échelle configurables : les règles de plage d’échelle de proxy sont configurables pour vous assurer que vous disposez autant d’instances que votre application.

• Paramètres avancés : vous pouvez configurer des paramètres avancés tels que des délais d’inactivité pour les instances proxy d’entrée.

Pour choisir entre le mode d’entrée par défaut et premium, vous évaluez les ressources consommées par l’instance proxy en tenant compte des demandes traitées. Commencez par examiner les cœurs de processeur virtuel et les ressources de mémoire consommées par l’instance proxy. Si votre environnement maintient le nombre maximal de proxys d’entrée (par défaut 10) pendant une période prolongée, envisagez de passer en mode d’entrée Premium. Pour plus d’informations, consultez les métriques. Pour savoir comment configurer le mode d’entrée Premium, consultez l’application Utiliser l’entrée Premium dans Azure Container Apps.

Profil de charge de travail

Vous pouvez sélectionner un profil de charge de travail pour fournir des nœuds dédiés à vos instances proxy d’entrée qui s’adapte à vos besoins. Les types de profils de charge de travail D4-D32 sont recommandés. Chaque instance proxy d’entrée est allouée à 1 cœur de processeur virtuel. Pour plus d’informations, consultez Profils de charge de travail dans Azure Container Apps.

Profil de charge de travail :

• Il ne doit pas s’agir du profil de charge de travail Consommation.
• Ne doit pas être partagé avec des applications ou des travaux de conteneur.
• Ne doit pas être supprimé lorsque vous l’utilisez pour votre proxy d’entrée.

L’exécution de votre proxy d’entrée dans un profil de charge de travail est facturée au tarif de ce profil de charge de travail. Pour plus d’informations, consultez Facturation.

Vous pouvez également configurer le nombre de nœuds de profil de charge de travail. Un profil de charge de travail est un pool évolutif de nœuds. Chaque nœud contient plusieurs instances proxy d’entrée. Le nombre de nœuds évolue en fonction de l'utilisation des vCPU et de la mémoire. Le nombre minimal d’instances de nœud est de deux.

Croissance

Le proxy d’entrée est mis à l’échelle indépendamment de la mise à l’échelle de votre application conteneur.

Lorsque votre proxy d’entrée atteint une utilisation élevée du processeur virtuel ou de la mémoire, Container Apps crée davantage d’instances proxy d’entrée. Lorsque l’utilisation diminue, les instances proxy d’entrée supplémentaires sont supprimées.

Vos instances proxy d’entrée minimale et maximale sont déterminées comme suit :

• Minimum : il existe un minimum de deux instances de nœud.

• Maximum : vos instances de nœud maximales multipliées par vos cœurs de processeur virtuel. Par exemple, si vous avez 50 instances de nœud maximales et 4 cœurs de processeurs virtuels, vous avez un maximum de 200 instances proxy d’entrée.

Les instances proxy d’entrée sont réparties entre les nœuds de profil de charge de travail disponibles.

Paramètres d’entrée avancés

Avec le mode d’entrée Premium activé, vous pouvez également configurer les paramètres suivants :

Réglage	Descriptif	Minimum	Maximale	Par défaut
Période de grâce pour résiliation	Durée (en secondes) pour que l’application conteneur termine le traitement des demandes avant qu’elles ne soient annulées pendant l’arrêt.	0	3 600	500
Délai d’inactivité de la demande	Durée du délai d'expiration des demandes inactives, exprimée en minutes.	4	30	4
Nom de l’en-tête de la requête	Augmentez ce paramètre si vous avez des clients qui envoient un grand nombre d’en-têtes de requête.	1	N/A	100

Vous ne devez augmenter ces paramètres que si nécessaire, car le déclenchement de ces paramètres peut entraîner l’utilisation de vos instances proxy d’entrée qui consomment plus de ressources pendant de longues périodes, devenant plus vulnérables à l’épuisement des ressources et aux attaques par déni de service.

Configurez une entrée

Vous pouvez configurer l’entrée pour votre environnement une fois que vous l’avez créé.

1. Accédez à votre environnement dans le portail Azure.

2. Sélectionnez Mise en réseau.

3. Sélectionnez Paramètres d’entrée.

4. Configurez vos paramètres d’entrée comme suit.

   Réglage	Valeur
   Mode d’entrée	Sélectionnez Par défaut ou Premium.
   Taille du profil de charge de travail	Sélectionnez une taille entre D4 et D32.
   Instances de nœud minimales	Entrez les instances minimales du nœud de profil de charge de travail.
   Nombre maximal d’instances de nœud	Entrez les instances maximales du nœud de profil de charge de travail.
   Période de grâce pour résiliation	Entrez la période de grâce d’arrêt en minutes.
   Délai d’inactivité de la demande	Entrez le délai d’expiration de la demande inactive en minutes.
   Nom de l’en-tête de la requête	Entrer l'en-tête de demande.

5. Sélectionnez Appliquer.

Routage basé sur des règles

Avec le routage basé sur des règles, vous créez un nom de domaine complet (FQDN) sur votre environnement d’applications conteneur. Vous utilisez ensuite des règles pour router les demandes vers ce nom de domaine complet vers différentes applications conteneur, en fonction du chemin d’accès de chaque requête. Cela offre les avantages suivants.

• Isolation : en acheminant différents chemins vers différentes applications conteneur, vous pouvez déployer et mettre à jour des composants individuels sans affecter l’ensemble de l’application.

• Scalabilité : avec le routage basé sur des règles, vous pouvez mettre à l’échelle des applications conteneur individuelles indépendamment en fonction du trafic reçu par chaque application conteneur.

• Règles de routage personnalisées : vous pouvez, par exemple, rediriger les utilisateurs vers différentes versions de votre application ou implémenter des tests A/B.

• Sécurité : vous pouvez implémenter des mesures de sécurité adaptées à chaque application conteneur. Cela vous permet de réduire la surface d’attaque de votre application.

Pour savoir comment configurer le routage basé sur des règles sur votre environnement d’applications de conteneur, consultez Utiliser le routage basé sur des règles.

Chiffrement pair à pair dans l’environnement Azure Container Apps

Azure Container Apps prend en charge le chiffrement TLS pair à pair au sein de l’environnement. L’activation de cette fonctionnalité chiffre tout le trafic réseau au sein de l’environnement avec un certificat privé valide dans l’étendue de l’environnement Azure Container Apps. Azure Container Apps gère automatiquement ces certificats.

Remarque

Par défaut, le chiffrement pair à pair est désactivé. L’activation du chiffrement pair à pair pour vos applications peut augmenter la latence de réponse et réduire le débit maximal dans les scénarios à charge élevée.

L’exemple suivant montre un environnement avec le chiffrement pair à pair activé.

¹ Le trafic TLS entrant est arrêté au niveau du proxy d’entrée sur la périphérie de l’environnement.

² Le trafic vers et depuis le proxy d’entrée au sein de l’environnement est chiffré par TLS avec un certificat privé et déchiffré par le récepteur.

³ Les appels effectués à partir de l’application A au nom de domaine complet de l’application B sont d’abord envoyés au proxy d’entrée en périphérie et sont chiffrés par TLS.

⁴ Les appels effectués à partir de l’application A vers l’application B avec le nom de l’application B sont envoyés directement à l’application B et sont chiffrés par TLS. Les appels entre les applications et les composants Java sont traités de la même manière que la communication d'application à application et cryptés TLS.

Les applications dans un environnement Container Apps sont automatiquement authentifiées. Toutefois, le runtime Container Apps ne prend pas en charge l’autorisation pour le contrôle d’accès entre les applications à l’aide du chiffrement pair à pair intégré.

Lorsque vos applications communiquent avec un client en dehors de l’environnement, l’authentification bidirectionnelle avec mTLS est prise en charge. Pour plus d’informations, consultez Configurer des certificats clients.

Azure CLI

Vous pouvez activer le chiffrement pair à pair en utilisant les commandes suivantes.

Lors de la création :

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

Pour une application conteneur existante :

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

Modèle ARM

Vous pouvez activer le chiffrement d’égal à égal dans le modèle ARM pour les environnements Container Apps à l’aide de la configuration suivante.

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

Contenu connexe

• Entrées dans Azure Container Apps
• Mise en réseau dans Azure Container Apps
• Configuration des réseaux virtuels environnements Azure Container Apps
• Intégrer un réseau virtuel à un environnement Azure Container Apps interne