Ajouter des règles à une passerelle
Les règles de passerelle vous permettent de contrôler le routage du trafic et de remplacer les configurations cibles sur votre passerelle sans redéployer les cibles. Vous créez des ensembles de configuration qui remplacent le comportement d'une cible, puis vous utilisez des règles pour contrôler quelle version de bundle s'applique à quel trafic. Les règles permettent également d'acheminer les demandes vers différentes cibles en fonction du chemin de la demande ou de l'identité de l'appelant.
Utilisez les règles de passerelle pour atteindre les objectifs suivants :
-
Testez les versions des ensembles de configuration par le biais A/B de tests
-
Associer des principes spécifiques à une version du bundle de configuration à des fins de débogage
-
Acheminer le trafic vers des cibles spécifiques en fonction du chemin de la demande ou de l'identité de l'appelant
-
Définissez un bundle ou une cible de configuration par défaut pour l'ensemble du trafic
Comment fonctionnent les règles de passerelle
Chaque règle de passerelle contient les composants suivants :
| Composant | Description |
|---|---|
|
Priority |
Nombre entier compris entre 1 et 1 000 000. Les chiffres inférieurs indiquent une priorité plus élevée. Chaque valeur de priorité doit être unique au sein d'une passerelle. |
|
Conditions (facultatives) |
Critères qui déterminent si la règle correspond à une demande. Une règle sans conditions agit comme un fourre-tout qui correspond à l'ensemble du trafic. |
|
Actions (obligatoires) |
Action à effectuer lorsque la règle correspond. Vous pouvez remplacer les ensembles de configuration, les acheminer vers des cibles spécifiques, ou les deux. |
|
Description (facultative) |
Description textuelle de l'objectif de la règle. |
Résolution des règles
La passerelle évalue les règles par ordre de priorité croissant (les nombres les plus bas en premier). La passerelle résout chaque type d'action indépendamment en utilisant la sémantique du premier match.
Le tableau suivant montre comment la passerelle résout les règles pour un exemple de demande. Dans cet exemple, le rôle QA envoie une demande à/my-target-canary/chat.
| Priority | Conditions | Actions | Correspond à la demande ? | Résultat |
|---|---|---|---|---|
|
100 |
Rôle QA |
|
Oui |
Résout |
|
200 |
Chemin |
|
Oui |
Décide |
|
1000000 |
Aucun (fourre-tout) |
|
Oui |
Les deux types d'actions sont déjà résolus. Ignoré. |
Résultat final : La demande utilise la version A du bundle et est acheminée versmy-target-canary.
Astuce
Laissez des espaces entre les numéros de priorité (par exemple, 100, 200, 300) afin de pouvoir insérer des règles ultérieurement sans renuméroter les règles existantes.
Conditions
Les conditions déterminent les demandes auxquelles une règle correspond. Une règle peut comporter au maximum 2 conditions. Une règle sans conditions s'applique à l'ensemble du trafic.
La passerelle prend en charge les types de conditions suivants :
- Principaux du match
-
Correspond aux demandes en fonction du principal IAM de l'appelant. La
anyOfliste contient de 1 à 100 entrées. Chaque entrée spécifie uniamPrincipalavec les champs suivants :-
arn— L'ARN principal IAM à associer. -
operator(facultatif) — L'opérateur de comparaison. Les valeurs valides sontStringEquals(par défaut) etStringLike. À utiliserStringLikepour faire correspondre des caractères génériques.
-
- Chemins de match
-
Correspond aux demandes en fonction du chemin de la demande. La
anyOfliste contient de 1 à 10 entrées. Chaque entrée doit utiliser le format/<targetName>/*, où<targetName>correspond au nom d'une cible HTTP existante sur la passerelle. La cible doit être enReadyétat. LamatchPathscondition n'est prise en charge que pour les passerelles avec des cibles HTTP. Les préfixes de chemin réservés suivants ne sont pas autorisés :/mcp,/a2a,,/responses/converse,/.well-known.
Logique d'évaluation des conditions
-
Dans un type de condition : la passerelle utilise la logique OR. Une demande correspond si elle répond à l'une des entrées de la
anyOfliste. -
Quels que soient les types de conditions : la passerelle utilise la logique AND. Si une règle possède les deux
matchPrincipalsetmatchPaths, la demande doit correspondre à au moins une entrée pour chaque type de condition.
Actions
Les actions définissent ce que fait la passerelle lorsqu'une règle correspond. Une règle peut comporter au maximum 2 actions.
La passerelle prend en charge les types d'actions suivants :
- Dérogations du bundle de configuration ()
configurationBundle -
Remplacez le bundle de configuration appliqué au trafic correspondant.
-
staticOverride— Épingle tout le trafic correspondant à une version de bundle de configuration spécifique. Spécifiez l'ARN du bundle et l'ID de version. -
weightedOverride— Répartit le trafic entre deux versions de bundle de configuration. LatrafficSplitliste doit contenir exactement 2 entrées avec des pondérations dont la somme est égale à 100. Le bundle de configuration doit se trouver sur le même compte que la passerelle.
-
- Routage cible (
routeToTarget) -
Itinéraires correspondant au trafic vers une cible spécifique. La cible doit utiliser le protocole HTTP et être en
Readyétat.-
staticRoute— Achemine tout le trafic correspondant vers une cible spécifique par son nom. -
weightedRoute— Répartit le trafic entre deux cibles. LatrafficSplitliste doit contenir exactement 2 entrées avec des pondérations dont la somme est égale à 100. Les noms des entrées de répartition du trafic doivent être uniques.
-
Restrictions
Le tableau suivant répertorie les limites des règles de passerelle.
| Ressource | Limite |
|---|---|
|
Règles par passerelle |
20 |
|
Fourchette de priorité |
1 à 1 000 000 |
|
Conditions maximales par règle |
2 |
|
Nombre maximum d'actions par règle |
2 |
|
|
100 |
|
|
10 |
|
|
Exactement 2 |
|
|
1 à 99 |
Rubriques
