Les applications SAE sont isolées d'Internet public par défaut. Pour accepter le trafic entrant, configurez le routage de passerelle ALB afin d'exposer vos applications via un écouteur Application Load Balancer (ALB). Chaque règle d'écouteur définie côté SAE constitue une règle de transfert entrant : elle met en correspondance les requêtes entrantes avec une ou plusieurs conditions, puis exécute une ou plusieurs actions.
Cette rubrique détaille les décisions clés relatives aux paramètres. Pour obtenir des instructions étape par étape sur la création de routes de passerelle, consultez Configuration des règles de routage par Application Load Balancer (ALB) .
Fonctionnement des règles de transfert
Une règle de transfert se compose de deux éléments : les conditions de transfert et les actions de transfert. Lorsqu'une requête entrante satisfait toutes les conditions d'une règle, ALB exécute les actions spécifiées.
Pour les instances ALB Standard Edition et WAF-Enabled Edition :
Règles entrantes : ALB les applique à la requête avant de la transférer vers le backend. Configurez les règles entrantes depuis la console SAE.
Règles sortantes : ALB les applique à la réponse du backend avant de la renvoyer au client. Configurez les règles sortantes depuis la console SLB, et non depuis la console SAE.
Lors de la création d'une règle :
Une règle entrante ne peut contenir que des conditions et des actions entrantes.
Une règle sortante peut contenir des conditions entrantes et sortantes, mais uniquement des actions sortantes.
Chaque règle doit inclure l'une des actions suivantes : Forward to, Redirect to ou Return fixed response.
Accéder au routage de passerelle
Connectez-vous à la console SAE. Dans le volet de navigation de gauche, cliquez sur Namespaces et sélectionnez la région cible.
Sur la page Namespace, cliquez sur le nom du namespace cible.
Sur la page Basic Information, cliquez sur Gateway Routing dans le volet de navigation de gauche, puis cliquez sur Create Gateway Route.
Conditions de transfert
Côté SAE, vous pouvez configurer des conditions de transfert en fonction du nom de domaine, du port d'accès et du chemin. Les sections ci-dessous décrivent chaque type de condition et ses options de correspondance.
Nom de domaine
ALB prend en charge trois types de correspondance pour les noms de domaine :
| Type de correspondance | Fonctionnement | Contraintes de saisie | |
|---|---|---|---|
| Correspondance exacte | Le nom de domaine de la requête doit être strictement égal à la valeur configurée | 3 à 128 caractères ; lettres majuscules/minuscules, chiffres et `. - ? = ~ _ + \ ^ * ! $ & | ( ) [ ]` |
| Correspondance avec joker | Le nom de domaine de la requête doit correspondre au modèle avec joker ; les caractères * et ? sont pris en charge |
Même jeu de caractères que pour la correspondance exacte | |
| Correspondance par expression régulière | Le nom de domaine de la requête doit correspondre à l'expression régulière (insensible à la casse) | 3 à 128 caractères ; lettres majuscules/minuscules, chiffres et `. - ? = ~ _ - + \ ^ * ! $ & | ( ) [ ]` |
Exemples pour www.example.com :
| Type de correspondance | Saisie | Correspond ? |
|---|---|---|
| Exacte | www.example.com |
Oui |
| Exacte | www.example.org |
Non |
| Avec joker | *.example.com |
Oui |
| Avec joker | www.example.* |
Oui |
| Avec joker | *.other.com |
Non |
| Regex | ^www.example.com$ |
Oui |
| Regex | ^api\.example\.com$ |
Non |
Chemin
ALB prend en charge trois types de correspondance pour les chemins de requête. Toutes les valeurs de chemin doivent commencer par /.
| Type de correspondance | Fonctionnement | Contraintes de saisie | |
|---|---|---|---|
| Correspondance exacte | Le chemin de la requête doit être strictement égal à la valeur configurée | Lettres majuscules/minuscules, chiffres et $ - _ . + / & ~ @ : |
|
| Correspondance avec joker | Le chemin de la requête doit correspondre au modèle avec joker ; les caractères * et ? sont pris en charge |
Même jeu de caractères que pour la correspondance exacte | |
| Correspondance par expression régulière | Le chemin de la requête doit correspondre à l'expression régulière | `. - _ / = ? ~ ^ * $ : ( ) [ ] + | ` |
ALB ne prend pas en charge la correspondance par préfixe le plus long (contrairement à Nginx). Pour reproduirelocation /abcdans Nginx, utilisez le modèle avec joker/abc/*dans ALB.
Exemples pour /sys/aaa/HOST :
| Type de correspondance | Saisie | Correspond ? |
|---|---|---|
| Exacte | /example/text |
Oui |
| Exacte | /example/text/ |
Non — la barre oblique finale n'est pas prise en compte |
| Exacte | /example |
Non — le chemin partiel n'est pas pris en compte |
| Avec joker | /example/* |
Oui |
| Avec joker | /other/* |
Non |
| Regex (sensible à la casse) | ^/sys/(.*)/HOST$ |
Oui |
| Regex (insensible à la casse) | ^/sys/(.*)/host$ |
Oui |
| Regex (sensible à la casse) | ^/example/other$ |
Non |
Actions de transfert
L'action de transfert détermine le traitement qu'ALB applique à une requête correspondante. Avant de choisir un type d'action, comprenez la différence fondamentale entre la redirection et la réécriture :
| Dimension | Redirection | Réécriture |
|---|---|---|
| URL visible par l'utilisateur | Change dans la barre d'adresse du navigateur | Aucun changement — l'URL d'origine est conservée |
| Emplacement du traitement | Côté navigateur (le client suit la redirection) | Côté serveur (ALB réécrit de manière transparente) |
| Code d'état HTTP | 301, 302, 303, 307 ou 308 | Aucun changement de code d'état |
| Usages courants | Migration de domaine, application forcée du protocole HTTPS, correction de liens brisés | URLs propres, masquage des structures de chemin internes |
Politique de réécriture
Une politique de réécriture est disponible lorsque vous sélectionnez Forward to comme action. Elle modifie le chemin ou la chaîne de requête avant le transfert vers le backend ; le client ne voit jamais l'URL réécrite.
Réécriture de chemin avec groupes de capture regex
Lorsque la condition de transfert utilise une expression régulière, vous pouvez utiliser des groupes de capture dans le chemin de réécriture.
Fonctionnement : Chaque paire de parenthèses()dans l'expression régulière de la condition capture un segment du chemin correspondant. Les trois premiers groupes capturés sont stockés sous forme de${1},${2}et${3}. Utilisez ces variables dans le chemin de réécriture pour construire la nouvelle URL envoyée au backend. Règles : - Le nombre de groupes()dans la condition doit être égal au nombre de variables${}dans le chemin de réécriture. - Seules les variables${1},${2}et${3}sont prises en charge — vous ne pouvez pas substituer d'autres caractères.
Exemple : Supprimer un préfixe et un suffixe de chemin à l'aide de deux groupes de capture.
Expression régulière du chemin de condition : /sys/(.*)/(.*)/aaa Chemin de réécriture : /${1}/${2}
| Chemin de la requête client | **${1}** |
**${2}** |
Le backend reçoit |
|---|---|---|---|
/sys/ccc/bbb/aaa |
ccc |
bbb |
/ccc/bbb |
/sys/foo/bar/aaa |
foo |
bar |
/foo/bar |
/sys/x/y/aaa |
x |
y |
/x/y |
Réécriture de requête
La chaîne de requête est la partie de l'URL située après ?. Définissez la requête de réécriture sur ${query} pour transmettre les paramètres de requête d'origine au backend sans modification.
Exemple : Pour www.example.com/test/test1?x=1, le contenu de la requête est x=1.
Politique de redirection
Une politique de redirection envoie le client vers une URL différente. Configurez six paramètres : protocole, nom de domaine, port d'accès, chemin, requête et code d'état.
Variables réservées
Utilisez les variables suivantes pour conserver les composants de la requête d'origine dans votre cible de redirection :
| Variable | Ce qu'elle conserve |
|---|---|
$(protocol) |
Protocole d'origine (HTTP ou HTTPS) |
${host} |
Nom de domaine d'origine |
${port} |
Port d'origine |
${query} |
Paramètres de requête d'origine |
Protocole
Un écouteur HTTP peut rediriger vers HTTP ou HTTPS. Un écouteur HTTPS ne peut rediriger que vers HTTPS.
Redirection de chemin avec groupes de capture regex
La redirection de chemin suit la même mécanique de groupe de capture que la réécriture de chemin. L'expression régulière du chemin de condition capture les segments dans ${1}, ${2} et ${3}, et le chemin de redirection utilise ces variables pour construire l'URL cible.
Règles (identiques à la réécriture) :
Le nombre de groupes
()dans la condition doit être égal au nombre de variables${}dans le chemin de redirection.Seules les variables
${1},${2}et${3}sont prises en charge.
Exemple : Supprimer un préfixe et un suffixe de chemin à l'aide de deux groupes de capture.
Expression régulière du chemin de condition : /sys/(.*)/(.*)/aaa Chemin de redirection : /${1}/${2}
| Chemin de la requête client | **${1}** |
**${2}** |
Redirigé vers |
|---|---|---|---|
/sys/ccc/bbb/aaa |
ccc |
bbb |
/ccc/bbb |
/sys/foo/bar/aaa |
foo |
bar |
/foo/bar |
Codes d'état
Le code d'état par défaut est 301. Choisissez le code d'état en fonction du caractère permanent ou temporaire de la redirection et de la nécessité de conserver la méthode HTTP :
| Code d'état | Type | Méthode HTTP conservée ? |
|---|---|---|
| 301 (par défaut) | Redirection permanente | Non |
| 302 | Redirection temporaire | Non |
| 303 | Voir autre emplacement | Non |
| 307 | Redirection temporaire | Oui |
| 308 | Redirection permanente | Oui |
Utilisez 307 ou 308 lorsque les clients envoient des requêtes POST ou PUT et que le point de terminaison redirigé doit recevoir la même méthode.