Cette rubrique présente des exemples de configuration des règles de transfert ALB, couvrant la correspondance des noms de domaine et des chemins, ainsi que les fonctionnalités de réécriture et de redirection.
Exemples de configuration
Scénario 1 : Redirection du trafic HTTP vers HTTPS
Redirigez les requêtes HTTP vers HTTPS afin de garantir le chiffrement des données en transit. Pour ce faire, ajoutez une règle de transfert à l'écouteur HTTP (port 80).
Paramètre | Description |
Add Condition | Définissez Path sur Exact Match and Wildcard et saisissez |
Action | Sélectionnez Redirect to.
|
Résultat : Lorsqu'un utilisateur accède à http://www.example.com/page, le navigateur est automatiquement redirigé vers https://www.example.com/page.
Configurez cette règle sur l'écouteur HTTP (port 80). Vérifiez également qu'un écouteur HTTPS (port 443) a été créé et qu'il est associé à un certificat SSL valide. Pour connaître la liste complète des prérequis et des procédures, consultez Utilisation d'ALB pour rediriger les requêtes HTTP vers HTTPS .
Scénario 2 : Routage du trafic par chemin
Pour un même domaine, vous pouvez acheminer les requêtes ayant des chemins différents vers des groupes de serveurs distincts. Par exemple, il est possible de diriger les requêtes API et les requêtes relatives aux ressources statiques vers des backends séparés.
Règle 1 : Acheminez les requêtes destinées à /api/* vers le groupe de serveurs API.
|
Paramètre |
Description |
|
Add Condition |
Définissez Path sur Exact Match and Wildcard et saisissez |
|
Action |
Sélectionnez Forward to, puis choisissez le groupe de serveurs API. |
Règle 2 : Acheminez les requêtes destinées à /static/* vers le groupe de serveurs de ressources statiques.
|
Paramètre |
Description |
|
Add Condition |
Définissez Path sur Exact Match and Wildcard et saisissez |
|
Action |
Sélectionnez Forward to, puis choisissez le groupe de serveurs de ressources statiques. |
ALB évalue les règles de transfert séquentiellement en fonction de leur numéro de priorité. Placez les règles de chemin les plus spécifiques (avec un numéro de priorité inférieur) avant les règles plus générales afin d'éviter qu'elles ne soient capturées par une règle générique. Par exemple, la règle pour/api/v2/*doit avoir un numéro de priorité inférieur à celui de la règle pour/api/*.
Scénario 3 : Transfert pour plusieurs domaines
Hébergez plusieurs domaines sur une seule instance ALB et transférez les requêtes de chaque domaine vers son groupe de serveurs backend respectif.
Règle 1 : Transférez les requêtes pour www.example.com vers le groupe de serveurs web.
|
Paramètre |
Description |
|
Add Condition |
Définissez Domain Name sur Exact Match and Wildcard et saisissez |
|
Action |
Sélectionnez Forward to, puis choisissez le groupe de serveurs web. |
Règle 2 : Transférez les requêtes pour api.example.com vers le groupe de serveurs API.
|
Paramètre |
Description |
|
Add Condition |
Définissez Domain Name sur Exact Match and Wildcard et saisissez |
|
Action |
Sélectionnez Forward to, puis choisissez le groupe de serveurs API. |
Scénario 4 : Suppression d'un préfixe de chemin avant le transfert
Supprimez un préfixe spécifique du chemin de la requête avant de la transférer au backend, tout en conservant les sous-chemins multiniveaux situés après ce préfixe. Par exemple, lorsqu'ALB transfère des requêtes pour www.example.com/api/aaa/bbb/..., vous devez retirer la partie /api du chemin tout en conservant les sous-chemins suivants tels que /aaa/bbb/....
Une opération de réécriture modifie le chemin en interne au sein d'ALB ; l'URL affichée dans la barre d'adresse du navigateur du client reste inchangée. Une redirection renvoie une nouvelle URL au client, et la barre d'adresse du navigateur est mise à jour avec cette nouvelle URL. Utilisez la réécriture si seul le backend doit recevoir le chemin sans le préfixe. Utilisez la redirection si le client doit être informé du changement d'URL.
Réécriture
Paramètre | Description | |
Add Condition | Domain Name | Définissez sur Exact Match and Wildcard et saisissez |
Path | Définissez sur Regular Expression Match | Case Insensitive et saisissez | |
Action | Rewrite |
|
Forward to | Sélectionnez le groupe de serveurs cible. | |
Redirection
Paramètre | Description | |
Add Condition | Domain Name | Définissez sur Exact Match and Wildcard et saisissez |
Path | Définissez sur Regular Expression Match | Case Insensitive et saisissez | |
Action | Redirect to |
|
Résultat : Pour une requête adressée à www.example.com/api/aaa/bbb/..., le serveur backend reçoit le chemin /aaa/bbb/....
Scénario 5 : Redirection du domaine nu vers www
Redirigez les requêtes provenant d'un domaine nu (tel que example.com) vers www.example.com. Cette pratique unifie le point d'entrée, ce qui améliore le référencement naturel (SEO) et simplifie la gestion.
Paramètre | Description |
Add Condition | Définissez Domain Name sur Exact Match and Wildcard et saisissez |
Action | Sélectionnez Redirect to.
|
Résultat : Lorsqu'un utilisateur accède à example.com, le navigateur est automatiquement redirigé vers www.example.com. Le protocole et le port restent inchangés.
Si vous devez également rediriger les requêtes HTTP vers HTTPS, combinez cette configuration avec le scénario 1.
Scénario 6 : Correspondance avec un domaine générique (wildcard)
Utilisez un domaine générique pour faire correspondre tous les sous-domaines et acheminer leurs requêtes vers le même groupe de serveurs.
|
Paramètre |
Description |
|
Add Condition |
Définissez Domain Name sur Exact Match and Wildcard et saisissez |
|
Action |
Sélectionnez Forward to, puis choisissez le groupe de serveurs cible. |
Résultat : Les requêtes adressées à tous les sous-domaines correspondants, tels que a.example.com, b.example.com et tenant1.example.com, sont transférées vers le même groupe de serveurs.
Pour acheminer un sous-domaine spécifique vers un groupe de serveurs différent, créez une règle pour ce domaine exact et attribuez-lui un numéro de priorité inférieur à celui de la règle générique. ALB évalue les règles en fonction de leur numéro de priorité, et non selon la spécificité de la correspondance de domaine.
Scénario 7 : Déploiement canari basé sur un en-tête HTTP
Utilisez un en-tête HTTP pour mettre en œuvre un déploiement canari. Cette méthode permet de transférer les requêtes contenant un en-tête spécifique vers le groupe de serveurs de la nouvelle version, tandis que les autres requêtes sont dirigées vers le groupe de serveurs de la version actuelle.
Règle 1 (règle canari, priorité supérieure) : Transférez les requêtes contenant l'en-tête X-Canary: true vers le groupe de serveurs de la nouvelle version.
|
Paramètre |
Description |
|
Add Condition |
Sélectionnez HTTP Header, définissez la clé sur |
|
Action |
Sélectionnez Forward to, puis choisissez le groupe de serveurs de la nouvelle version. |
Règle 2 (règle par défaut, priorité inférieure) : Les requêtes ne contenant pas l'en-tête canari sont transférées vers le groupe de serveurs de la version actuelle. Cela peut être mis en œuvre à l'aide de la règle de transfert par défaut de l'écouteur.
Résultat : Lorsqu'une requête client inclut l'en-tête X-Canary: true, le trafic est transféré vers le groupe de serveurs de la nouvelle version. Les requêtes dépourvues de cet en-tête sont dirigées vers le groupe de serveurs de la version actuelle.
Afin de garantir que le trafic canari soit traité en premier, la règle canari doit avoir un numéro de priorité inférieur (indiquant une priorité plus élevée) que la règle par défaut. Pour obtenir des informations sur les méthodes de déploiement canari basées sur les cookies et les pondérations des groupes de serveurs, consultez Utilisation d'ALB pour mettre en œuvre un déploiement canari .
Correspondance de domaine dans les règles de transfert
ALB évalue les règles de transfert selon leur numéro de priorité, du plus faible au plus élevé, et s'arrête à la première règle correspondante. Les règles ne sont pas automatiquement triées par spécificité de domaine. Ce comportement diffère de celui de CLB, qui hiérarchise automatiquement les règles en fonction de leur spécificité (par exemple, exact match > narrower wildcard > broader wildcard).
Prenons l'exemple d'un écouteur disposant des deux règles suivantes :
|
Numéro de priorité |
Condition de correspondance |
|
Règle 1 (Priorité : 1) |
Domain = |
|
Règle 2 (Priorité : 2) |
Domain = |
Une requête adressée à www.example.com correspond à la règle 1 (la règle générique), et non à la règle 2 (la règle de correspondance exacte), car la règle 1 possède un numéro de priorité inférieur.
Bonnes pratiques : Pour garantir qu'une règle plus spécifique soit évaluée en premier, attribuez-lui un numéro de priorité inférieur à celui d'une règle moins spécifique. Par exemple, définissez la règle pourwww.example.comavec la priorité 1 et la règle pour*.example.comavec la priorité 2.
Type de correspondance | Description |
Correspondance exacte et correspondance générique |
|
Correspondance par expression régulière |
|
Correspondance de chemin dans les règles de transfert
Les règles de correspondance de chemin d'ALB diffèrent de celles de Nginx. ALB ne prend pas en charge le principe de correspondance du préfixe le plus long. Par exemple, Nginx utilise la méthode de correspondance du préfixe le plus long pour une configuration courante telle que location /api. Pour obtenir le même effet avec ALB, vous devez utiliser un caractère générique. Vous pouvez configurer le chemin sous la forme /api/* (une combinaison de correspondance exacte et de caractère générique).
Si un écouteur dispose de règles pour/api/*et/api/v2/*, vous devez placer la règle/api/v2/*avant la règle/api/*en lui attribuant un numéro de règle inférieur. Sinon, la règle/api/*correspondra à toutes les requêtes en premier.
Type de correspondance | Description |
Correspondance exacte et générique |
|
Correspondance par expression régulière |
|
En mode de correspondance par expression régulière, une barre oblique finale (/) dans le chemin affecte le résultat de la correspondance. Par exemple, l'expression régulière ~^/ws/(.*) correspond uniquement aux chemins commençant par /ws/ (tels que /ws/ et /ws/abc), et ne correspond pas à /ws (sans barre oblique finale). Si vous souhaitez faire correspondre à la fois /ws et les chemins commençant par /ws/, utilisez l'expression régulière ~^/ws(/.*)?$.
Configuration avancée des chemins pour les réécritures et les redirections
Si vous utilisez une expression régulière pour définir un chemin dans une condition de transfert, vous pouvez appliquer une substitution par expression régulière dans le chemin d'une action de réécriture ou de redirection.
-
Remarques
Le nombre de groupes de capture, définis par des parenthèses
( ), dans l'expression régulière de la condition de transfert doit correspondre au nombre de variables ${n} présentes dans le chemin de réécriture ou de redirection de l'action de transfert.Le chemin de réécriture ou de redirection dans l'action de transfert doit inclure une ou plusieurs des variables suivantes :
${1},${2}et${3}. Ne remplacez pas ces variables par d'autres caractères.Dans un chemin de réécriture ou de redirection, utilisez le caractère
$uniquement pour référencer les variables suivantes :${host},${path},${port},${protocol}, ainsi que les variables de groupe de capture d'expression régulière telles que${1},${2}et${3}. Aucune autre variable n'est prise en charge.
-
Fonctionnement
Correspondance de chemin : un client envoie une requête qui correspond à l'expression régulière définie dans une règle de transfert.
Extraction et substitution : le système extrait le contenu des trois premiers groupes de capture, définis par des parenthèses
( ), et l'enregistre dans les variables${1},${2}et${3}. Ces variables sont ensuite utilisées pour la substitution dans le chemin de réécriture ou de redirection de l'action de transfert.Construction du chemin : le système remplace les variables
${1},${2}et${3}par leurs valeurs capturées et construit le chemin final pour la réécriture ou la redirection.
N°
Étape
Exemple
1
Configurez la condition de transfert et l'action de transfert pour une règle de transfert.
Chemin dans la condition de transfert :
/app/(.)/(.)/settingsChemin pour l'action de réécriture ou de redirection :
/${1}/${2}
2
Un client envoie une requête correspondant au chemin.
Chemin de la requête du client :
/app/users/profile/settingsChemin correspondant dans la condition de transfert :
/app/(.)/(.)/settings
3
Extraction et substitution des valeurs.
Le système extrait
usersetprofiledes deux groupes de capture(.*)dans le chemin de la condition de transfert, puis enregistre les valeurs dans les variables ${1} et ${2} pour l'action de transfert.${1}est remplacé parusers.${2}est remplacé parprofile.
4
Construction du chemin.
Chemin reçu par le serveur backend :
/users/profile -
Exemples de configuration
Lors de l'ajout de règles de transfert dans la console, référez-vous aux remarques précédentes et à la description du flux de travail.
Exemple 1 : Définir l'action de transfert sur Rewrite et Forward to
Cet exemple montre comment réécrire le chemin
/app/users/profile/settingsen/users/profileavant de transférer la requête à un serveur backend. L'expression régulière/app/(.*)/(.*)/settingsutilise deux groupes de capture pour extraireusersetprofile. Le chemin réécrit utilise ensuite/${1}/${2}pour construire le chemin final.Paramètre
Description
Add Condition
Path
Sélectionnez Regular Expression Match | Case Insensitive et saisissez l'expression régulière
/app/(.)/(.)/settings.Par exemple, si un client demande le chemin
/app/users/profile/settings, la règle correspond. Les groupes de capture extraientusersetprofile, qui sont enregistrés respectivement dans les variables${1}et${2}.Action
Rewrite
Domain Name :
${host}Path :
/${1}/${2}Search :
${query}
Le champ Search correspond à la partie de l'URL qui suit le point d'interrogation. Par exemple, pour l'URL
www.example.com/test/test1?x=1, la valeur de Search estx=1.Forward to
Sélectionnez le groupe de serveurs cible dans la liste des groupes de serveurs.
Exemple 2 : Définir l'action de transfert sur une redirection
L'exemple suivant redirige le chemin
/app/users/profile/settingsvers/users/profile. Contrairement à l'exemple 1, cette redirection renvoie un code d'état 301 et l'URL dans la barre d'adresse du navigateur change.Paramètre
Description
Add Condition
Path
Sélectionnez Regular Expression Match | Case Insensitive et saisissez l'expression régulière
/app/(.)/(.)/settings.Par exemple, si un client demande le chemin
/app/users/profile/settings, la règle correspond. Les groupes de capture extraientusersetprofile, qui sont enregistrés respectivement dans les variables${1}et${2}.Action
Redirect to
Protocol :
${protocol}Domain Name :
${host}Port :
${port}Path :
/${1}/${2}Search :
${query}Status Code :
301
FAQ
Réécriture du nom de domaine uniquement
Pour réécrire le nom de domaine demandé vers un autre tout en conservant le chemin et la chaîne de requête inchangés, configurez la règle comme suit :
Add Condition : définissez le nom de domaine sur le domaine d'origine, par exemple
old.example.com.Action : sélectionnez la réécriture. Définissez le nom de domaine sur le nouveau domaine (par exemple
new.example.com), le chemin sur${path}et la requête sur${query}. Configurez également Forward to pour spécifier un groupe de serveurs.
Ajout d'un préfixe à un chemin
Pour ajouter un préfixe à un chemin (par exemple, réécrire /users/list en /v2/users/list), configurez la règle comme suit :
Add Condition : définissez le chemin pour qu'il corresponde à l'expression régulière
^/(.*).Action : sélectionnez la réécriture et définissez le chemin sur
/v2/${1}. Configurez également Forward to pour spécifier un groupe de serveurs.
Après configuration de la règle, ALB réécrit une requête pour /users/list en /v2/users/list et la transfère au serveur backend.
Suppression d'un préfixe de chemin
Consultez le Cas d'utilisation 4 : Transfert des requêtes après suppression d'un préfixe de chemin de cette rubrique. Ce cas d'utilisation fournit un exemple de configuration complet pour supprimer un préfixe, tel que /api/*, en utilisant une correspondance par expression régulière avec une action de réécriture ou de redirection.
Dépannage de la correspondance et du routage des règles de transfert
Si vos règles de transfert n'acheminent pas les requêtes comme prévu, suivez les étapes de dépannage ci-dessous :
Vérifiez la priorité des règles : ALB évalue les règles par ordre croissant de leur numéro de priorité et s'arrête à la première correspondance. Si une règle plus générale possède un numéro de priorité inférieur (et est donc évaluée en premier), une règle plus spécifique avec un numéro de priorité supérieur ne sera pas prise en compte.
Vérifiez le type de correspondance : assurez-vous d'utiliser le type de correspondance approprié (correspondance exacte, caractère générique ou expression régulière). Par exemple, une correspondance exacte pour
/apine correspond pas à/api/users. Pour correspondre aux deux, vous devez utiliser un caractère générique, tel que/api/*.Vérifiez les conditions multiples : lors de la configuration de plusieurs conditions pour une seule règle de transfert, les conditions de types différents sont combinées avec un opérateur AND, tandis que plusieurs valeurs pour le même type de condition sont combinées avec un opérateur OR. Pour plus d'informations, consultez la rubrique Configuration des règles de transfert des écouteurs.
Vérifiez les journaux d'accès : utilisez les champs
hostetrequest_uridans le journal d'accès ALB pour vérifier que les détails de la requête reçus par ALB correspondent à vos attentes.
Réécriture versus redirection
|
Élément |
Réécriture |
Redirection |
|
Barre d'adresse du navigateur |
Inchangée (transparente pour l'utilisateur) |
Modifiée pour afficher la nouvelle URL |
|
Fonctionnement |
ALB réécrit le chemin de la requête en interne, puis transfère la requête au serveur backend. L'ensemble du processus se déroule en une seule requête. |
ALB renvoie un code d'état 3xx et le navigateur initie une seconde requête vers la nouvelle URL. |
|
Cas d'utilisation |
Ajustements internes de chemin, tels que la suppression de préfixes ou l'ajout de numéros de version. |
Redirections HTTP vers HTTPS, redirections de domaine nu vers www et migrations d'URL héritées. |
|
Nécessite "Forward to" |
Oui. Une action de réécriture doit être configurée avec une action "Forward to" spécifiant un groupe de serveurs. |
Non. Une action de redirection est autonome. |
Documents connexes
Pour obtenir des instructions sur la configuration des règles de transfert des écouteurs pour un ALB, consultez la rubrique Configuration des règles de transfert des écouteurs.