Hébergement multisite Application Gateway

L’hébergement multisite vous permet de configurer plusieurs applications web sur le même port de passerelles applicatives à l’aide d’écouteurs publics. Vous pouvez ainsi configurer une topologie plus efficace pour vos déploiements en ajoutant jusqu’à 100 sites web à une même passerelle d’application. Chaque site web peut être dirigé vers son propre pool principal. Par exemple, trois domaines (contoso.com, fabrikam.com et adatum.com) pointent vers l’adresse IP de la passerelle d’application. Vous créez trois écouteurs multisites et configurez les paramètres de port et de protocole de chaque écouteur.

Vous pouvez également définir des noms d’hôte avec caractères génériques dans un écouteur multisite et jusqu’à 5 noms d’hôte par écouteur. Pour plus d’informations, consultez Noms d’hôtes avec caractères génériques dans l’écouteur.

Important

Pour la référence SKU v1, les règles sont traitées dans l’ordre où elles sont répertoriées sur le portail. Pour que la référence SKU v2 utilise la priorité des règles afin de spécifier l'ordre de traitement. Il est vivement recommandé de configurer des écouteurs multisites avant un écouteur de base. Vous avez ainsi l’assurance que le trafic est acheminé vers le serveur principal approprié. Si un écouteur de base est indiqué en premier et correspond à une demande entrante, elle est traitée par cet écouteur.

Les requêtes adressées à http://contoso.com sont acheminées vers ContosoServerPool, tandis que les requêtes adressées à http://fabrikam.com sont acheminées vers FabrikamServerPool.

De même, vous pouvez héberger de nombreux sous-domaines du même domaine parent sur le même déploiement de passerelle d’application. Par exemple, vous pouvez héberger http://blog.contoso.com et http://app.contoso.com sur un déploiement unique de passerelle d’application.

Ordre de l’évaluation des règles d’acheminement des requêtes

Lorsque vous utilisez des écouteurs multisite pour vous assurer que le trafic client est acheminé vers le back-end précis, il est important que les règles de routage des requêtes soient présentes dans l’ordre correct. Par exemple, si vous avez 2 écouteurs avec les noms d’hôtes associés de *.contoso.com et de shop.contoso.com, l’écouteur avec le nom d’hôte shop.contoso.com doit être traité avant l’écouteur avec *.contoso.com. Si l’écouteur avec *.contoso.com est traité en premier, aucun trafic client n’est reçu par l’écouteur shop.contoso.com plus spécifique.

L’ordre des règles peut être établi en fournissant une valeur de champ Priorité aux règles de routage des requêtes associées aux écouteurs. Vous pouvez spécifier une valeur d’entier comprise entre 1 et 20000. 1 représente la priorité la plus haute et 20000 la plus basse. Si le trafic client entrant correspond à plusieurs écouteurs, la règle de routage des requêtes avec la priorité la plus élevée est utilisée pour traiter la requête. Chaque règle de routage de requête doit avoir une valeur de priorité unique.

Le champ de priorité n’affecte que l’ordre d’évaluation d’une règle d’acheminement des requêtes. Elle ne modifie pas l’ordre d’évaluation des règles basée sur le chemin d’accès au sein d’une règle d’acheminement des requêtes PathBasedRouting.

Remarque

Pour utiliser la priorité des règles, vous devez spécifier des valeurs de champ de priorité de règle pour toutes les règles de routage de requête existantes. Une fois le champ de priorité de règle utilisé, toute nouvelle règle de routage créée doit avoir une valeur de champ de priorité de règle dans le cadre de sa configuration.

Important

À compter de l’API version 2021-08-01, le champ de priorité de règle est un champ obligatoire dans les règles de routage des requêtes. Les valeurs des champs de priorité de règle pour les règles de routage de requête existantes, en fonction de l’ordre actuel d’évaluation dans le cadre du premier appel PUT, sont automatiquement renseignées si des mises à jour de configuration sont appliquées à l’aide de la version d’API 2021-08-01 et versions ultérieures, du portail, d’Azure PowerShell et d’Azure CLI. Les futures mises à jour des règles de routage des requêtes doivent avoir le champ de priorité de règle fourni dans le cadre de la configuration.

Noms d’hôtes avec caractères génériques dans l’écouteur

Application Gateway autorise l’acheminement en fonction de l’hôte à l’aide de l’écouteur HTTP(S) multisite. Il est maintenant possible d’utiliser des caractères génériques comme l’astérisque (*) et le point d’interrogation (?) dans le nom d’hôte, et jusqu’à 5 noms d’hôtes par écouteur HTTP(S) multisite. Par exemple : *.contoso.com.

En utilisant un caractère générique dans le nom d’hôte, vous pouvez faire correspondre plusieurs noms d’hôtes dans un seul écouteur. Par exemple, *.contoso.com peut correspondre à ecom.contoso.com, b2b.contoso.com et customer1.b2b.contoso.com, etc. À l’aide d’un tableau de noms d’hôtes, il est possible de configurer plusieurs noms d’hôtes pour un écouteur, pour acheminer les demandes vers un pool principal. Par exemple, un écouteur peut contenir contoso.com, fabrikam.com qui accepte les demandes des deux noms d’hôte.

Remarque

Cette fonction est disponible uniquement pour les SKU Standard_v2 et WAF_v2 d'Application Gateway.

Dans Azure PowerShell, vous devez utiliser -HostNames au lieu de -HostName. Avec -HostNames, vous pouvez spécifier jusqu’à cinq noms d’hôtes sous forme de valeurs séparées par des virgules et utiliser des caractères génériques. Par exemple : -HostNames "*.contoso.com","*.fabrikam.com".

Dans Azure CLI, vous devez utiliser --host-names au lieu de --host-name. Avec --host-names, vous pouvez spécifier jusqu’à cinq noms d’hôtes sous forme de valeurs séparées par des virgules et utiliser des caractères génériques. Par exemple : --host-names "*.contoso.com,*.fabrikam.com".

Dans le Portail Azure, sous l’écouteur multisite, vous devez choisir le type d’hôte Plusieurs/caractère générique pour mentionner jusqu’à 5 noms d’hôte dotés de caractères génériques autorisés.

Caractères autorisés dans le champ des noms d’hôtes

• (A-Z,a-z,0-9) : caractères alphanumériques
• - : trait d’union ou signe moins
• . : point comme délimiteur
• * : peut correspondre à plusieurs caractères dans la plage autorisée
• ? : peut correspondre à un seul caractère dans la plage autorisée

Conditions pour utiliser des caractères génériques et plusieurs noms d’hôtes dans un écouteur

• Il n’est possible de spécifier que cinq noms d’hôtes maximum dans un même écouteur.
• L’astérisque * ne peut être spécifié qu’une seule fois dans un composant de nom de style de domaine ou de nom d’hôte, Par exemple, composant1*.composant2*.composant3. (*.contoso-*.com) est valide.
• Un nom d’hôte ne peut contenir que deux astérisques * maximum. Par exemple, *.contoso.* est valide, *.contoso.*.*.com non.
• Un nom d’hôte ne peut contenir que quatre caractères génériques maximum. Par exemple, ????.contoso.com et w??.contoso*.edu.* sont valides, ????.contoso.* non.
• Il n’est pas possible d’utiliser conjointement un astérisque * et un point d’interrogation ? dans un composant de nom d’hôte (*?, ?* ou **). Par exemple, ni *?.contoso.com ni **.contoso.com ne sont valides.

Considérations et limitations liées à l’utilisation d’un nom d’hôte avec caractères génériques ou de plusieurs noms d’hôtes dans un écouteur

• L’arrêt SSL et le protocole SSL de bout en bout obligent à configurer le protocole en tant que protocole HTTPS et à charger un certificat qui sera utilisé dans la configuration de l’écouteur. S’il s’agit d’un écouteur multisite, vous pouvez également entrer le nom d’hôte, généralement le nom commun du certificat SSL. Lorsque vous spécifiez plusieurs noms d’hôtes dans l’écouteur ou utilisez des caractères génériques, vous devez tenir compte des points suivants :
  • S’il s’agit d’un nom d’hôte avec caractères génériques comme *.contoso.com, vous devez charger un certificat générique avec nom commun du type *.contoso.com
  • Si plusieurs noms d’hôtes sont spécifiés dans le même écouteur, vous devez charger un certificat SAN (autre nom de l’objet) dont le nom commun correspond aux noms d’hôtes.
• Vous ne pouvez pas recourir à une expression régulière pour spécifier le nom d’hôte. Seuls des caractères génériques comme l’astérisque (*) et le point d’interrogation (?) peuvent être utilisés pour former le modèle de nom d’hôte.
• Pour le contrôle d’intégrité du serveur principal, il n’est pas possible d’associer plusieurs sondes personnalisées par paramètre HTTP. Vous pouvez en revanche sonder l’un des sites web du serveur principal ou utiliser « 127.0.0.1 » pour sonder le localhost sur le serveur principal. Toutefois, lorsque vous utilisez des noms d’hôte génériques ou multiples dans un écouteur, les demandes de tous les modèles de domaine spécifiés sont routées vers le pool principal en fonction du type de règle (de base ou basé sur le chemin).
• La propriété « hostname » prend une chaîne comme entrée, où vous ne pouvez mentionner qu’un seul nom de domaine non générique. La propriété « hostnames » prend un tableau de chaînes comme entrée, où vous pouvez mentionner jusqu’à 5 noms de domaines génériques. Ces deux propriétés ne peuvent pas être utilisées simultanément.

Pour des instructions pas à pas de configuration des noms d’hôtes avec caractères génériques dans un écouteur multisite, consultez Création de plusieurs sites à l’aide d’Azure PowerShell ou à l’aide d’Azure CLI.

Écouteur multisite pour les écouteurs de protocole TLS et TCP

La fonctionnalité multisite est également disponible pour le proxy Layer4, mais uniquement pour ses écouteurs TLS. Vous pouvez diriger le trafic de chaque application vers son pool de back-ends en fournissant des noms de domaine dans l’écouteur TLS. Pour que la fonctionnalité multisite marche sur les écouteurs TLS, Application Gateway utilise la valeur SNI (Server Name Indication) (les clients présentent principalement l’extension SNI pour récupérer le bon certificat TLS). Un écouteur TLS multisite choisirait cette valeur SNI à partir des données de négociation TLS d’une connexion entrante et acheminerait cette connexion vers le pool de back-ends approprié. La connexion TCP n’a pas de concept inhérent de nom d’hôte ou de nom de domaine ; par conséquent, cela n’est pas disponible pour les écouteurs TCP.

En-têtes d’hôte et Indication du nom du serveur (SNI)

Il existe trois mécanismes courants pour activer l’hébergement multisite dans la même infrastructure.

1. Hébergez plusieurs applications web, chacune sur une adresse IP unique.
2. Utilisez le nom d’hôte pour héberger plusieurs applications web sur la même adresse IP.
3. Utilisez des ports différents pour héberger plusieurs applications web sur la même adresse IP.

Actuellement, le service Application Gateway prend en charge une seule IP publique sur laquelle il écoute le trafic. Par conséquent, la prise en charge de plusieurs applications, chacune avec sa propre adresse IP, n’est pas disponible actuellement.

Application Gateway prend en charge plusieurs applications à l’écoute sur différents ports, mais ce scénario exige que les applications acceptent le trafic sur des ports non standard.

Application Gateway se base sur des en-têtes d’hôte HTTP 1.1 pour héberger plusieurs sites web sur les mêmes adresses IP et port. Les sites hébergés sur Application Gateway peuvent également prendre en charge le déchargement TLS avec l’extension Indication du nom du serveur (SNI) TLS. Ce scénario signifie que le navigateur du client et la batterie de serveurs web principale doivent prendre en charge HTTP/1.1 et l’extension TLS définie dans RFC 6066.

Étapes suivantes

Apprendre à configurer l’hébergement multisite dans Application Gateway

• À l’aide du portail Azure
• Utilisation de Microsoft Azure PowerShell
• Utilisation de l’interface de ligne de commande Azure

Consultez Modèle Resource Manager avec l’hébergement multisite pour un déploiement basé sur un modèle de bout en bout.