Concevoir et configurer Azure Front Door
Azure Front Door est le réseau de distribution de contenu (CDN) cloud moderne de Microsoft, qui fournit un accès rapide, fiable et sécurisé entre vos utilisateurs et vos applications. Azure Front Door fournit votre contenu à l’aide du réseau de périmètre mondial de Microsoft, avec des centaines de POP globaux et locaux répartis dans le monde entier près des utilisateurs finaux de votre entreprise et de vos utilisateurs finaux consommateurs.
De nombreuses organisations disposent d’applications qu’elles souhaitent mettre à la disposition de leurs clients, de leurs fournisseurs et bien entendu de leurs utilisateurs. Le plus délicat est d’assurer la haute disponibilité de ces applications. De plus, elles ont besoin d’être capables de répondre rapidement tout en étant sécurisées de manière appropriée. Azure Front Door fournit différentes références SKU (niveaux tarifaires) qui répondent à ces exigences. Passons rapidement en revue les fonctionnalités et les avantages de ces références SKU pour vous permettre de déterminer l’option qui répond le mieux à vos besoins.
Un réseau CDN cloud moderne et sécurisé fournit une plateforme distribuée de serveurs. Les serveurs distribués réduisent la latence quand les utilisateurs accèdent aux pages web. Jusqu’ici, le service informatique a probablement utilisé un CDN et un pare-feu d’applications web pour contrôler le trafic HTTP et HTTPS à destination et en provenance des applications cibles.
Si une organisation utilise Azure, elle peut atteindre ces objectifs en implémentant les produits décrits dans ce tableau.
| Produit | Description |
|---|---|
| Azure Front Door | Active un point d’entrée dans vos applications situées dans le réseau de périmètre global de Microsoft. Offre un accès scalable, plus rapide et plus sécurisé à vos applications web. |
| Azure Content Delivery Network | Distribue du contenu large bande à vos utilisateurs en mettant en cache ce contenu dans des nœuds physiques répartis de manière stratégique dans le monde entier. |
| Pare-feu d’applications web Azure | Aide à fournir une meilleure protection centralisée des applications web contre les attaques et les vulnérabilités courantes. |
Comparaison du niveau Azure Front Door
Azure Front Door est proposé dans deux niveaux différents, Azure Front Door Standard et Azure Front Door Premium. Les niveaux Azure Front Door Standard et Premium combinent les fonctionnalités d’Azure Front Door (classique), d’Azure CDN Standard de Microsoft (classique) et d’Azure WAF en une seule plateforme CDN cloud sécurisée avec une protection intelligente contre les menaces. Azure Front Door réside dans la périphérie et gère l’accès des demandes des utilisateurs à vos applications hébergées. Les utilisateurs se connectent à votre application par le biais du réseau global Microsoft. Azure Front Door route ensuite ces demandes utilisateur vers le back-end d’application le plus rapide et le plus disponible.
Pour une comparaison des fonctionnalités prises en charge dans Azure Front Door, consultez le tableau de comparaison des fonctionnalités.
Créer une instance Front Door dans le portail Azure
Passez en revue le Guide de démarrage rapide pour savoir comment créer un profil Azure Front Door à l’aide du portail Azure. Vous pouvez créer un profil Azure Front Door via Création rapide avec des configurations de base ou via Création personnalisée qui permet une configuration plus avancée.
Vue d’ensemble de l’architecture de routage
Le routage du trafic de Front Door s’effectue en plusieurs étapes. Tout d’abord, le trafic est routé du client vers Front Door. Ensuite, Front Door utilise votre configuration pour déterminer l’origine à laquelle envoyer le trafic. Le pare-feu d’applications Web, les règles de routage, le moteur de règles et la configuration de la mise en cache de Front Door ont tous une incidence sur le processus de routage. Le diagramme suivant illustre l’architecture de routage :
Structure de configuration des règles d’acheminement Front Door
La configuration d’une règle de routage Front Door se compose de deux parties principales.
Correspondance entrante
Ces propriétés déterminent si la requête entrante correspond à la règle de routage.
- Protocoles HTTP (HTTP/HTTPS)
- Hôtes (par exemple www.foo.com, *.bar.com)
- Chemins d’accès (par exemple, /, /users/, /file.gif)
Ces propriétés sont développées en interne de telle sorte que chaque combinaison Protocole/Hôte/Chemin d’accès constitue une correspondance potentielle.
Données de routage
Front Door accélère le traitement des requêtes à l’aide de la mise en cache. Si la mise en cache est activée pour un itinéraire spécifique, elle utilise la réponse mise en cache. En l’absence de réponse mise en cache pour la requête, Front Door transfère la requête au back-end approprié dans le pool de back-ends configuré.
Mise en correspondance avec un itinéraire
Front Door tente de trouver la correspondance la plus spécifique en premier. L’algorithme établit une première correspondance en fonction du protocole HTTP, de l’hôte front-end, puis du chemin d’accès.
Mise en correspondance avec des hôtes front-end :
- Recherche d’un routage ayant une correspondance parfaite sur l’hôte.
- Si aucune correspondance exacte n’est trouvée sur l’hôte frontend, la demande est rejetée et une erreur 400 Demande incorrecte est envoyée.
Mise en correspondance avec un chemin :
- Recherchez une règle d’acheminement ayant une correspondance exacte dans le chemin.
- Si aucune correspondance exacte n’est trouvée dans le chemin, recherchez des règles d’acheminement avec un chemin générique qui correspond.
- Si aucune règle de routage n’est trouvée avec un chemin correspondant, la demande est rejetée et une réponse HTTP 400 : Demande incorrecte est retournée.
En l’absence de règle de routage pour un hôte front-end ayant une correspondance exacte avec un chemin d’accès qui intercepte tout (/*), il n’existe pas de correspondance..
Azure Front Door redirige le trafic à chacun de ces niveaux : protocole, nom d’hôte, chemin d’accès, chaîne de requête. Ces fonctionnalités peuvent être configurées pour des microservices individuels dans la mesure où la redirection est basée sur le chemin d'accès.
Types de redirection
Un type de redirection définit le code d’état de réponse pour aider les clients à comprendre l’objectif de la redirection. Ces types de redirections sont pris en charge.
| Type de redirection | Action | Description |
|---|---|---|
| 301 | Déplacé définitivement | Indique qu’un nouvel URI permanent a été affecté à la ressource cible. Toute référence future à cette ressource utilise l’un des URI inclus. Utilisez le code d’état 301 pour la redirection du protocole HTTP vers HTTPS. |
| 302 | Trouvé | Indique que la ressource cible se trouve temporairement sous un autre URI. Étant donné que la redirection peut changer à l'occasion, le client doit continuer à utiliser l'URI de requête effectif pour les demandes ultérieures. |
| 307 | Redirection temporaire | Indique que la ressource cible se trouve temporairement sous un autre URI. L'agent utilisateur NE DOIT PAS modifier la méthode de demande s'il procède à une redirection automatique vers cet URI. Étant donné que la redirection peut changer au fil du temps, le client doit continuer à utiliser l’URI de requête en effet d’origine pour les requêtes ultérieures. |
| 308 | Redirection permanente | Indique qu’un nouvel URI permanent a été affecté à la ressource cible. Toute référence future à cette ressource devra utiliser l'un des URI inclus. |
Protocole de redirection
Vous pouvez définir le protocole utilisé pour la redirection. Le cas d'usage le plus courant de la fonctionnalité de redirection est la définition de la redirection HTTP sur HTTPS.
- HTTPS uniquement : définissez le protocole sur HTTPS uniquement si vous cherchez à rediriger le trafic HTTP vers HTTPS. Azure Front Door recommande de toujours définir la redirection vers HTTPS uniquement.
- HTTP uniquement : Redirige la requête entrante vers HTTP. Utilisez cette valeur uniquement si vous voulez que votre trafic reste de type HTTP, c’est-à-dire non chiffré.
- Faire correspondre la requête : Cette option conserve le protocole utilisé par la requête entrante. Par conséquent, une requête HTTP reste HTTP et une requête HTTPS reste une redirection HTTPS.
Hôte de destination
Dans le cadre de la configuration d’un routage de redirection, vous pouvez également modifier le nom d’hôte ou le domaine pour la requête de redirection. Vous pouvez définir ce champ pour modifier le nom d’hôte dans l’URL pour la redirection, ou bien conserver le nom d’hôte de la demande entrante. Ainsi, avec ce champ, vous pouvez rediriger toutes les requêtes envoyées sur https://www.contoso.com/* vers https://www.fabrikam.com/*.
Chemin de destination
Pour les cas où vous souhaiteriez remplacer le segment de chemin d’accès d’une URL dans le cadre de la redirection, vous pouvez définir ce champ avec la nouvelle valeur de chemin d’accès. Sinon, vous pouvez choisir de conserver la valeur de chemin d’accès dans le cadre de la redirection. Ainsi, avec ce champ, vous pouvez rediriger toutes les requêtes envoyées à https://www.contoso.com/* vers https://www.contoso.com/redirected-site.
Fragment de destination
Le fragment de destination correspond à la partie de l’URL située après le signe dièze (#). Vous pouvez définir ce champ pour ajouter un fragment à l’URL de redirection.
Paramètres de chaîne de requête
Vous pouvez également remplacer les paramètres de chaîne de requête dans l’URL redirigée. Pour remplacer une chaîne de requête existante de l'URL de requête entrante, définissez ce champ sur « Remplacer », puis définissez la valeur appropriée. Sinon, conservez l’ensemble des chaînes de requête d’origine en affectant au champ la valeur Conserver. Ce champ permet par exemple de rediriger tout le trafic envoyé sur https://www.contoso.com/foo/bar vers https://www.contoso.com/foo/bar?&utm_referrer=https%3A%2F%2Fwww.bing.com%2F.
Configurer les stratégies de réécriture
Azure Front Door prend en charge la réécriture d'URL en configurant un chemin de transfert personnalisé facultatif à utiliser lors de la construction d'une requête à transférer au back-end. L’en-tête d’hôte utilisé dans la requête transférée est tel que configuré pour le backend sélectionné. Pour découvrir ce qu’il fait et comment vous pouvez le configurer, consultez En-tête d’hôte backend.
L’aspect le plus intéressant de la réécriture d’URL réside dans le fait que le chemin d’accès de transfert personnalisé copie toute partie du chemin d’accès entrant correspondant à un chemin d’accès avec des caractères génériques dans le chemin d’accès transféré.
Configurer des sondes d’intégrité, y compris la personnalisation des codes de réponse HTTP
Pour déterminer l’intégrité et de la proximité de chaque serveur principal d’un environnement de service Front Door donné, celui-ci envoie régulièrement une requête HTTP/HTTPS synthétique à chaque serveur principal configuré. Front Door utilise alors les réponses fournies par la sonde pour identifier les « meilleurs » backends vers lesquels acheminer les demandes de vos clients.
Dans la mesure où Front Door comporte de nombreux environnements de périphérie dans le monde, le volume de sondes d’intégrité pour vos back-ends peut être élevé, allant de 25 requêtes par minute à 1 200 requêtes par minute, selon la fréquence configurée des sondes d’intégrité. À la fréquence de sonde par défaut de 30 secondes, le volume des requêtes de sonde sur votre serveur principal doit être d’environ 200 requêtes par minute.
Méthodes HTTP prises en charge pour les sondes d’intégrité
La porte d’entrée prend en charge l’envoi de sondes via les protocoles HTTP ou HTTPS. Ces sondes d’intégrité sont envoyées sur les mêmes ports TCP que ceux configurés pour le routage des requêtes des clients, et ne peuvent pas être remplacées.
Front Door prend en charge les méthodes HTTP suivantes pour l’envoi des sondes d’intégrité :
GET : La méthode GET récupère les informations relatives à l’entité dans l’URI de requête.
HEAD : La méthode HEAD est identique à la méthode GET, sauf que le serveur NE DOIT PAS retourner de corps de message dans la réponse. Étant donné que la charge et les coûts sont inférieurs sur vos serveurs principaux, pour les nouveaux profils Front Door, par défaut, la méthode de sondage est définie sur HEAD.
Réponses des sondes d’intégrité
Ce tableau décrit les réponses à la sonde d’intégrité :
| Response | Description |
|---|---|
| Détermination de l’intégrité | Le code d’état 200 OK indique que le backend est sain. Tous les autres sont considérés comme un défaillance. Si, pour une raison quelconque (notamment une défaillance réseau), la réponse HTTP valide d’une sonde n’est pas reçue, la sonde est considérée comme défectueuse. |
| Mesure de la latence | La latence est le temps horloge mesuré à partir du moment où la requête de sondage est envoyée jusqu’à ce que le dernier octet de la réponse soit reçu. Une nouvelle connexion TCP est utilisée à chaque demande, cette mesure n’est pas orientée vers les serveurs principaux ayant des connexions à chaud. |
Azure Front Door utilise le même processus en trois étapes pour tous les algorithmes afin de déterminer l’intégrité.
Excluez les backends désactivés.
Excluez les serveurs principaux qui présentent des erreurs de sonde d’intégrité :
- Pour effectuer cette sélection, examinez les n dernières réponses de sonde d’intégrité. Si au moins x sont saines, le backend est considéré comme sain.
- Pour configurer la valeur n, modifiez la propriété SampleSize dans les paramètres d’équilibrage de charge.
- Pour configurer la valeur x, modifiez la propriété SuccessfulSamplesRequired dans les paramètres d’équilibrage de charge.
Front Door mesure et maintient la latence (durée aller-retour) pour chaque ensemble de backends considérés comme sains.
Si vous avez un seul serveur principal dans votre pool principal, vous pouvez désactiver les sondes d’intégrité afin de réduire la charge sur le serveur principal de votre application. Même si vous avez plus d’un serveur principal dans le pool principal, il suffit qu’un seul soit activé pour que vous puissiez désactiver les sondes d’intégrité.
Sécuriser Front Door avec TSL/SSL
L’utilisation du protocole HTTPS permet de vérifier que les données sensibles sont remises de manière sécurisée. Quand votre navigateur web est connecté à un site web via HTTPS, il valide le certificat de sécurité du site web, et vérifie s’il provient d’une autorité de certification légitime. Ce processus assure la sécurité et protège également vos applications web contre les attaques.
Voici quelques-uns des attributs clés de la fonctionnalité HTTPS personnalisée :
- Aucun coût supplémentaire : l’acquisition ou le renouvellement de certificat n’entraîne aucun coût supplémentaire, tout comme le trafic HTTPS.
- Activation simple : L’approvisionnement simplifié est disponible à partir du portail Azure. Vous pouvez également utiliser l’API REST ou d’autres outils de développeur pour activer la fonctionnalité.
- Gestion complète de certificats : l’approvisionnement et la gestion de tous les certificats sont assurés pour vous. Les certificats sont automatiquement provisionnés et renouvelés avant expiration, ce qui élimine les risques d’interruption de service en raison d’une expiration de certificat.
Pour plus d’informations sur la configuration du protocole HTTPS sur Front Door, consultez Tutoriel : configurer HTTPS sur un domaine personnalisé pour Azure Front Door | Microsoft Learn.