Utiliser Azure Front Door dans une solution multilocataire

Azure Front Door est un réseau de diffusion de contenu cloud (CDN) moderne qui fournit un accès rapide et fiable entre les utilisateurs et le contenu web statique et dynamique des applications dans le monde entier. Cet article décrit certaines des fonctionnalités d’Azure Front Door qui sont utiles lorsque vous travaillez dans des systèmes multilocataires. Il fournit également des liens vers des conseils et des exemples supplémentaires.

Lorsque vous utilisez Azure Front Door dans le cadre d’une solution mutualisée, vous devez prendre des décisions en fonction de la conception et des exigences de votre solution. Vous devez prendre en compte les facteurs suivants :

• Combien de locataires avez-vous et combien prévoyez-vous d’avoir à l’avenir ?
• Partagez-vous votre niveau Application entre plusieurs locataires, déployez-vous de nombreuses instances d’application mono-locataire ou déployez-vous des empreintes de déploiement distinctes partagées par plusieurs locataires ?
• Vos locataires veulent-ils apporter leurs propres noms de domaine ?
• Utiliserez-vous des domaines génériques ?
• Avez-vous besoin d’utiliser vos propres certificats TLS ou Microsoft gérera-t-il vos certificats TLS ?
• Avez-vous pris en compte les quotas et les limites qui s’appliquent à Azure Front Door ? Savez-vous quelles limites vous aborderez à mesure que vous grandirez ? Si vous pensez que vous allez aborder ces limites, envisagez d’utiliser plusieurs profils Azure Front Door. Vous pouvez également déterminer si vous pouvez modifier la façon dont vous utilisez Azure Front Door pour éviter les limites. Notez que la référence SKU Premium a des limites plus élevées que la référence SKU Standard.
• Avez-vous ou vos locataires des exigences en matière de filtrage d’adresses IP, de blocage géographique ou de personnalisation des règles WAF ?
• Tous les serveurs d’applications de vos locataires sont-ils connectés à Internet ?

Fonctionnalités d’Azure Front Door qui prennent en charge l’architecture mutualisée

Cette section décrit plusieurs fonctionnalités clés d’Azure Front Door qui sont utiles pour les solutions mutualisées. Il décrit comment Azure Front Door peut vous aider à configurer des domaines personnalisés, notamment des informations sur les domaines génériques et les certificats TLS. Il résume également la façon dont vous pouvez utiliser les fonctionnalités de routage Azure Front Door pour prendre en charge l’architecture mutualisée.

Domaines personnalisés

Azure Front Door fournit un nom d’hôte par défaut pour chaque point de terminaison que vous créez, par exemple, contoso.z01.azurefd.net. Pour la plupart des solutions, vous associez plutôt votre propre nom de domaine au point de terminaison Azure Front Door. Les noms de domaine personnalisés vous permettent d’utiliser votre propre personnalisation et de configurer le routage en fonction du nom d’hôte fourni dans la demande d’un client.

Dans une solution multilocataire, vous pouvez utiliser des noms de domaine ou des sous-domaines spécifiques au locataire et configurer Azure Front Door pour acheminer le trafic du locataire vers le groupe d’origine approprié pour la charge de travail de ce locataire. Par exemple, vous pouvez configurer un nom de domaine personnalisé comme tenant1.app.contoso.com. Avec Azure Front Door, vous pouvez configurer plusieurs domaines personnalisés sur un seul profil Azure Front Door.

Pour plus d’informations, consultez Ajouter un domaine personnalisé à votre Front Door.

Domaines génériques

Les domaines génériques simplifient la configuration des enregistrements DNS et de la configuration du routage du trafic Azure Front Door lorsque vous utilisez un domaine stem partagé et des sous-domaines spécifiques au locataire. Par exemple, supposons que vos locataires accèdent à leurs applications à l’aide de sous-domaines tels que tenant1.app.contoso.com et tenant2.app.contoso.com. Vous pouvez configurer un domaine générique, *.app.contoso.com, au lieu de configurer chaque domaine spécifique au locataire individuellement.

Azure Front Door prend en charge la création de domaines personnalisés qui utilisent des caractères génériques. Vous pouvez ensuite configurer un itinéraire pour les requêtes qui arrivent sur le domaine générique. Lorsque vous intégrez un nouveau locataire, vous n’avez pas besoin de reconfigurer vos serveurs DNS, d’émettre de nouveaux certificats TLS ou de mettre à jour la configuration de votre profil Azure Front Door.

Les domaines génériques fonctionnent bien si vous envoyez tout votre trafic à un seul groupe d’origines. Toutefois, si vous avez des empreintes distinctes de votre solution, un domaine générique à un seul niveau n’est pas suffisant. Vous devez utiliser des domaines stem à plusieurs niveaux ou fournir une configuration supplémentaire, par exemple, en remplaçant les itinéraires à utiliser pour le sous-domaine de chaque locataire. Pour plus d’informations, consultez Considérations relatives à l’utilisation de noms de domaine dans une solution multilocataire.

Azure Front Door n’émet pas de certificats TLS managés pour les domaines génériques. Vous devez donc acheter et fournir votre propre certificat.

Pour plus d’informations, consultez Domaines génériques.

Certificats TLS managés

L’acquisition et l’installation de certificats TLS peuvent être complexes et sujettes aux erreurs. Les certificats TLS expirent au bout d’un délai, généralement un an, et doivent être réédités et réinstallés pour éviter toute interruption du trafic d’application. Lorsque vous utilisez des certificats TLS managés Azure Front Door, Microsoft est responsable de l’émission, de l’installation et du renouvellement des certificats pour votre domaine personnalisé.

Votre application d’origine peut être hébergée sur un autre service Azure qui fournit également des certificats TLS managés, comme Azure App Service. Azure Front Door fonctionne en toute transparence avec l’autre service pour synchroniser vos certificats TLS.

Si vous autorisez vos locataires à fournir leurs propres domaines personnalisés et que vous souhaitez qu’Azure Front Door émette des certificats pour ces noms de domaine, vos locataires ne doivent pas configurer d’enregistrements CAA sur leurs serveurs DNS qui pourraient empêcher Azure Front Door d’émettre des certificats en leur nom. Pour plus d’informations, consultez la section Certificats TLS/SSL.

Pour plus d’informations sur les certificats TLS, consultez TLS de bout en bout avec Azure Front Door.

Routage

Une application multilocataire peut avoir un ou plusieurs tampons d’application qui servent les locataires. Les empreintes sont fréquemment utilisées pour activer les déploiements multi-régions et prendre en charge la mise à l’échelle d’une solution sur un grand nombre de locataires.

Azure Front Door dispose d’un ensemble puissant de fonctionnalités de routage qui peuvent prendre en charge un certain nombre d’architectures mutualisées. Vous pouvez utiliser le routage pour distribuer le trafic entre les origines au sein d’un tampon ou pour envoyer le trafic vers le bon tampon pour un locataire spécifique. Vous pouvez configurer le routage en fonction des noms de domaine individuels, des noms de domaine génériques et des chemins d’URL. Vous pouvez également utiliser le moteur de règles pour personnaliser davantage le comportement de routage.

Pour plus d’informations, consultez Vue d’ensemble de l’architecture de routage.

Moteur de règles

Vous pouvez utiliser le moteur de règles Azure Front Door pour personnaliser la façon dont Azure Front Door traite les demandes à la périphérie du réseau. Le moteur de règles vous permet d’exécuter de petits blocs de logique dans le pipeline de traitement des requêtes Azure Front Door. Vous pouvez utiliser le moteur de règles pour diverses tâches, notamment les suivantes :

• Récupérer des informations sur la requête HTTP, notamment des segments de l'URL et du chemin d'accès, et propager ces informations à une autre partie de la requête.
• Modifier des éléments de la requête HTTP avant qu'elle ne soit envoyée à l'origine.
• Modifier certaines parties de la réponse HTTP avant qu'elle ne soit renvoyée au client.
• Remplacer la configuration de routage d'une requête, par exemple en modifiant le groupe d'origine auquel une requête doit être envoyée.

Voici quelques exemples d'approches pour l'utilisation du moteur de règles Azure Front Door dans une solution multi-tenant :

• Supposons que vous déployez un niveau d'application multitenant dans lequel vous utilisez également des sous-domaines de caractères génériques spécifiques aux locataires, comme décrit dans les exemples de scénarios suivants. Vous pouvez utiliser le moteur de règles pour extraire l'identifiant du locataire du sous-domaine de la requête et l'ajouter à un en-tête de requête. Cette règle peut aider le niveau Application à déterminer le locataire d’où provient la demande.
• Supposons que vous déployez un niveau d'application multilocataire et que vous utilisez un routage basé sur le chemin (par exemple, https://application.contoso.com/tenant1/welcome et https://application.contoso.com/tenant2/welcome pour les locataires 1 et 2, respectivement). Vous pouvez utiliser le moteur de règles pour extraire le segment de l'identifiant du locataire du segment du chemin d'accès à l'URL et réécrire l'URL pour inclure l'identifiant du locataire dans un paramètre de chaîne de requête ou dans un en-tête de requête que l'application doit consommer.

Pour plus d’informations, consultez Qu’est-ce que le moteur de règles Azure Front Door ?.

Exemples de scénarios

Les exemples de scénarios suivants illustrent comment vous pouvez configurer différentes architectures mutualisées dans Azure Front Door et comment les décisions que vous prenez peuvent affecter votre configuration DNS et TLS.

De nombreuses solutions mutualisées implémentent le Modèle Empreintes de déploiement. Lorsque vous utilisez cette approche de déploiement, vous déployez généralement un seul profil Azure Front Door partagé et utilisez Azure Front Door pour acheminer le trafic entrant vers l’empreinte appropriée. Ce modèle de déploiement est le plus courant et les scénarios 1 à 4 de cet article montrent comment vous pouvez l’utiliser pour répondre à toute une série de conditions requises.

Toutefois, dans certains cas, vous pouvez déployer un profil Azure Front Door dans chaque empreinte de votre solution. Le scénario 5 décrit ce modèle de déploiement.

Scénario 1 : domaine générique géré par le fournisseur, empreinte unique

Contoso crée une petite solution multilocataire. L’entreprise déploie un tampon unique dans une seule région, et ce tampon sert tous ses locataires. Toutes les requêtes sont routées vers le même serveur d’applications. Contoso a décidé d’utiliser des domaines génériques pour tous les locataires, tels que tenant1.contoso.com et tenant2.contoso.com.

Contoso déploie Azure Front Door à l’aide de cette configuration :

Configuration DNS

Configuration ponctuelle : Contoso configure deux entrées DNS :

• Enregistrement TXT générique pour *.contoso.com. Il est défini sur la valeur spécifiée par Azure Front Door pendant le processus d’intégration de domaine personnalisé.
• Enregistrement CNAME générique, *.contoso.com, qui est un alias pour le point de terminaison Azure Front Door de Contoso : contoso.z01.azurefd.net.

Lorsqu’un nouveau locataire est intégré : Aucune configuration supplémentaire n’est requise.

Configuration TLS

Configuration ponctuelle : Contoso achète un certificat TLS générique, l’ajoute à un coffre de clés et accorde à Azure Front Door l’accès au coffre.

Lorsqu’un nouveau locataire est intégré : Aucune configuration supplémentaire n’est requise.

Configuration Azure Front Door

Configuration ponctuelle : Contoso crée un profil Azure Front Door et un point de terminaison unique. Ils ajoutent un domaine personnalisé portant le nom *.contoso.com et associent leur certificat TLS générique à la ressource de domaine personnalisé. Ils configurent ensuite un groupe d’origines unique qui contient une origine unique pour leur serveur d’applications. Enfin, ils configurent un itinéraire pour connecter le domaine personnalisé au groupe d’origine.

Lorsqu’un nouveau locataire est intégré : Aucune configuration supplémentaire n’est requise.

Avantages

• Cette configuration est relativement facile à configurer et fournit aux clients des URL de marque Contoso.
• L’approche prend en charge un grand nombre de locataires.
• Lorsqu’un nouveau locataire est intégré, Contoso n’a pas besoin d’apporter des modifications aux certificats Azure Front Door, DNS ou TLS.

Inconvénients

• Cette approche n’est pas facilement mise à l’échelle au-delà d’un tampon d’application ou d’une seule région.
• Contoso doit acheter un certificat TLS générique et renouveler et installer le certificat à son expiration.

Scénario 2 : domaine générique géré par le fournisseur, plusieurs empreintes

Proseware crée une solution multilocataire sur plusieurs empreintes déployées en Australie et en Europe. Toutes les demandes au sein d’une même région sont traitées par l’empreinte dans cette région. Comme Contoso, Proseware a décidé d’utiliser des domaines génériques pour tous les locataires, comme tenant1.proseware.com et tenant2.proseware.com.

Proseware déploie Azure Front Door à l’aide de la configuration suivante :

Configuration DNS

Configuration unique : Proseware configure deux entrées DNS :

• Enregistrement TXT de caractère générique pour *.proseware.com. Il est défini sur la valeur spécifiée par Azure Front Door pendant le processus d’intégration de domaine personnalisé.
• Un enregistrement CNAME générique, *.proseware.com, qui est un alias pour le point de terminaison Azure Front Door de Proseware : proseware.z01.azurefd.net.

Lorsqu’un nouveau locataire est intégré : Aucune configuration supplémentaire n’est requise.

Configuration TLS

Configuration unique : Proseware achète un certificat TLS générique, l’ajoute à un coffre de clés et accorde à Azure Front Door l’accès au coffre.

Lorsqu’un nouveau locataire est intégré : Aucune configuration supplémentaire n’est requise.

Configuration Azure Front Door

Configuration unique: Proseware crée un profil Azure Front Door et un point de terminaison unique. L’entreprise configure plusieurs groupes d’origines, un par tampon/serveur d’application dans chaque région.

Lorsqu’un nouveau locataire est intégré : Proseware ajoute une ressource de domaine personnalisé à Azure Front Door. Ils utilisent le nom *.proseware.com et associent leur certificat TLS générique à la ressource de domaine personnalisé. Ils créent ensuite un itinéraire pour spécifier le groupe d’origines (empreinte) vers lequel les demandes du locataire doivent être dirigées. Dans le diagramme précédent, tenant1.proseware.com les itinéraires vers le groupe d’origines dans la région Australie et les itinérairestenant2.proseware.com vers le groupe d’origines dans la région Europe.

Avantages

• Lorsque de nouveaux locataires sont intégrés, aucune modification de configuration DNS ou TLS n’est requise.
• Proseware gère une seule instance d’Azure Front Door pour acheminer le trafic vers plusieurs empreintes dans plusieurs régions.

Inconvénients

• Proseware doit reconfigurer Azure Front Door chaque fois qu’un nouveau locataire est intégré.
• Proseware doit prêter attention aux quotas et aux limites d’Azure Front Door, en particulier sur le nombre d’itinéraires et de domaines personnalisés, ainsi que sur la limite de routage composite.
• Proseware doit acheter un certificat TLS générique.
• Proseware est responsable du renouvellement et de l’installation du certificat lorsqu’il expire.

Scénario 3 : sous-domaines génériques gérés par un fournisseur et basés sur des empreintes

Fabrikam crée une solution multilocataire. La société déploie des timbres en Australie et dans le États-Unis. Toutes les demandes au sein d’une même région seront traitées par le tampon dans cette région. Fabrikam utilisera des domaines de tige basés sur des empreintes, comme tenant1.australia.fabrikam.com, tenant2.australia.fabrikam.comet tenant3.us.fabrikam.com.

L’entreprise déploie Azure Front Door à l’aide de la configuration suivante :

Configuration DNS

Configuration unique : Fabrikam configure les deux entrées DNS génériques suivantes pour chaque empreinte.

• Enregistrement TXT générique pour chaque empreinte : *.australia.fabrikam.com et *.us.fabrikam.com. Elles sont définies sur les valeurs spécifiées par Azure Front Door pendant le processus d’intégration de domaine personnalisé.
• Un enregistrement CNAME générique pour chaque empreinte, *.australia.fabrikam.com et *.us.fabrikam.com, qui sont tous deux des alias pour le point de terminaison Azure Front Door : fabrikam.z01.azurefd.net.

Lorsqu’un nouveau locataire est intégré : Aucune configuration supplémentaire n’est requise.

Configuration TLS

Configuration unique : Fabrikam achète un certificat TLS générique pour chaque empreinte, les ajoute à un coffre de clés et accorde à Azure Front Door l’accès au coffre.

Lorsqu’un nouveau locataire est intégré : Aucune configuration supplémentaire n’est requise.

Configuration Azure Front Door

Configuration unique : Fabrikam crée un profil Azure Front Door et un point de terminaison unique. Ils configurent un groupe d’origines pour chaque empreinte. Ils créent des domaines personnalisés, à l’aide d’un caractère générique, pour chaque sous-domaine basé sur un tampon : *.australia.fabrikam.com et *.us.fabrikam.com. Ils créent un itinéraire pour le domaine personnalisé de chaque empreinte afin d’envoyer le trafic vers le groupe d’origines approprié.

Lorsqu’un nouveau locataire est intégré : Aucune configuration supplémentaire n’est requise.

Avantages

• Cette approche permet à Fabrikam de mettre à l’échelle un grand nombre de locataires sur plusieurs empreintes.
• Lorsque de nouveaux locataires sont intégrés, aucune modification de configuration DNS ou TLS n’est requise.
• Fabrikam gère une seule instance d’Azure Front Door pour acheminer le trafic vers plusieurs empreintes dans plusieurs régions.

Inconvénients

• Étant donné que les URL utilisent une structure de domaine stem en plusieurs parties, les URL peuvent être plus complexes à utiliser pour les utilisateurs.
• Fabrikam doit acheter plusieurs certificats TLS génériques.
• Fabrikam est responsable du renouvellement et de l’installation des certificats TLS lorsqu’ils expirent.

Scénario 4 : Domaines de vanité

Adventure Works Cycles crée une solution multilocataire. La société déploie des timbres dans plusieurs régions, comme l’Australie et les États-Unis. Toutes les demandes au sein d’une même région seront traitées par le tampon dans cette région. Adventure Works permettra à ses locataires d’apporter leurs propres noms de domaine. Par exemple, le locataire 1 peut configurer un nom de domaine personnalisé comme tenant1app.tenant1.com.

L’entreprise déploie Azure Front Door à l’aide de la configuration suivante :

Configuration DNS

Configuration unique : Aucun.

Lorsqu’un nouveau locataire est intégré : Le locataire doit créer deux enregistrements sur son propre serveur DNS :

• Enregistrement TXT pour la validation de domaine. Par exemple, le locataire 1 doit configurer un enregistrement TXT nommé tenant1app.tenant1.com et lui affecter la valeur spécifiée par Azure Front Door pendant le processus d’intégration de domaine personnalisé.
• Un enregistrement CNAME qui a un alias pour le point de terminaison Azure Front Door Adventure Works. Par exemple, le locataire 1 doit configurer un enregistrement CNAME nommé tenant1app.tenant1.com et le mapper à adventureworks.z01.azurefd.net.

Configuration TLS

Adventure Works et ses locataires doivent décider qui émet des certificats TLS :

• L’option la plus simple consiste à utiliser Azure Front Door pour émettre et gérer les certificats, mais les locataires ne doivent pas configurer les enregistrements CCA sur leurs serveurs DNS. Dans ce cas, les enregistrements peuvent empêcher l’autorité de certification Azure Front Door d’émettre des certificats.
• Les locataires peuvent également fournir leurs propres certificats. Ils doivent travailler avec Adventure Works pour charger le certificat dans un coffre de clés et fournir l’accès à Azure Front Door.

Configuration Azure Front Door

Configuration unique : Adventure Works crée un profil Azure Front Door et un point de terminaison unique. Ils configurent un groupe d’origines pour chaque empreinte. Ils ne créent pas de ressources de domaine ou d’itinéraires personnalisés.

Lorsqu’un nouveau locataire est intégré : Adventure Works ajoute une ressource de domaine personnalisé à Azure Front Door. Ils utilisent le nom de domaine fourni par le locataire et associent le certificat TLS approprié à la ressource de domaine personnalisé. Ils créent ensuite un itinéraire pour spécifier le groupe d’origines (empreinte) vers lequel les demandes du locataire doivent être dirigées. Dans le diagramme précédent, tenant1app.tenant1.com est routé vers le groupe d’origines dans la région Australie et tenant2app.tenant3.com est routé vers le groupe d’origines dans la région des États-Unis.

Avantages

• Les clients peuvent fournir leurs propres noms de domaine. Azure Front Door achemine en toute transparence les demandes vers la solution multilocataire.
• Adventure Works gère une seule instance d’Azure Front Door pour acheminer le trafic vers plusieurs empreintes dans plusieurs régions.

Inconvénients

• Adventure Works doit reconfigurer Azure Front Door chaque fois qu’un nouveau locataire est intégré.
• Les locataires doivent être impliqués dans le processus d’intégration. Ils doivent apporter des modifications DNS et éventuellement émettre des certificats TLS.
• Les locataires contrôlent leurs enregistrements DNS. Les modifications apportées aux enregistrements DNS peuvent affecter leur capacité à accéder à la solution Adventure Works.
• Adventure Works doit prêter attention aux quotas et limites Azure Front Door, en particulier au nombre d’itinéraires et de domaines personnalisés, ainsi qu’à la limite de routage composite.

Scénario 5 : Profil Azure Front Door par empreinte

Vous pouvez déployer un profil Azure Front Door pour chaque empreinte. Si vous avez 10 empreintes, vous déployez 10 instances d’Azure Front Door. Cette approche peut être utile si vous devez restreindre l’accès à la gestion de la configuration Azure Front Door de chaque empreinte. Il peut également être utile si vous devez utiliser plusieurs profils Azure Front Door pour éviter de dépasser les quotas ou limites de ressources.

Conseil

Azure Front Door est une ressource globale. Même si vous déployez des empreintes de portée régionale, chaque profil Azure Front Door est distribué à l’échelle mondiale. Vous devez déterminer si vous avez vraiment besoin de déployer plusieurs profils Azure Front Door et quels avantages vous bénéficiez de cette opération.

Si vous avez un tampon qui sert plusieurs locataires, vous devez réfléchir à la façon dont vous acheminez le trafic vers chaque locataire. Passez en revue les approches décrites dans les scénarios précédents et envisagez de combiner des approches en fonction de vos besoins.

Avantages

• Si vous étendez votre configuration sur plusieurs profils, vous êtes moins susceptible d’atteindre les limites de ressources Azure Front Door. Par exemple, si vous devez prendre en charge un grand nombre de domaines personnalisés, vous pouvez diviser les domaines entre plusieurs profils Azure Front Door et rester dans les limites de chaque profil.
• Cette approche vous permet d’étendre vos autorisations de gestion des ressources Azure Front Door. Vous pouvez utiliser le contrôle d’accès en fonction du rôle (RBAC) Azure pour accorder aux administrateurs l’accès au profil d’une empreinte unique.

Inconvénients

• Cette approche entraîne généralement un coût élevé, car vous déployez plus de profils. Pour plus d’informations, consultez Comprendre la facturation Front Door.
• Il existe une limite au nombre de profils Azure Front Door que vous pouvez déployer dans un seul abonnement Azure. Pour plus d’informations, consultez Quotas et limites Front Door.
• Vous devez configurer le profil Azure Front Door de chaque empreinte séparément, et vous devez gérer la configuration DNS, les certificats TLS et la configuration TLS pour chaque empreinte.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

• Raj Nemani | Directeur, Stratégiste de la technologie partenaire
• John Downs | Ingénieur logiciel principal

Autres contributeurs :

• Mick Alberts | Rédacteur technique
• Fernando Antivero | Fullstack Developer & Cloud Platform Engineer
• Duong Au | Senior Content Developer, C+E Skilling Content R&D
• Harikrishnan M B (HARI) | Product Manager 2, Azure Networking
• Arsen Vladimirskiy | Ingénieur client principal, FastTrack for Azure

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

• Formation : Présentation Azure Front Door
• Présentation d’Azure Front Door
• Qu’est-ce qu’Azure Front Door ?

Ressources associées

• Définir l’architecture de solutions multilocataires sur Azure
• Liste de contrôle de l’architecture et de la création de solutions mutualisées sur Azure
• Modèles à prendre en compte pour une solution mutualisée