Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Ajouter des règles à une passerelle
Les règles de passerelle vous permettent de contrôler le routage du trafic et de modifier 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 :
-
A/B Testez les versions du bundle de configuration
-
Épinglez des principes spécifiques à une version du bundle de configuration pour le 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 ensemble de configuration par défaut ou une cible pour l'ensemble du trafic
Comment fonctionnent les règles de passerelle
Chaque règle de passerelle contient les éléments suivants :
| Composant | Description |
|---|---|
|
Priority |
Un entier compris entre 1 et 1 000 000. Les chiffres les plus faibles 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) |
L'action à effectuer lorsque la règle correspond. Vous pouvez remplacer les ensembles de configuration, effectuer un routage 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 chiffres les plus faibles d'abord). La passerelle résout chaque type d'action indépendamment à l'aide de la sémantique de première correspondance.
Le tableau suivant montre comment la passerelle résout les règles relatives à un exemple de demande. Dans cet exemple, le rôle QA envoie une demande à/my-target-canary/chat.
| Priority | Conditions | Actions | Demande de matchs ? | Résultat |
|---|---|---|---|---|
|
100 |
Un rôle |
|
Oui |
Passage |
|
200 |
Sentier |
|
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 du bundle A 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 correspond une règle. Une règle peut comporter au maximum 2 conditions. Une règle sans conditions correspond à l'ensemble du trafic.
La passerelle prend en charge les types de conditions suivants :
- Match Principals
-
Fait correspondre les demandes en fonction du principal IAM de l'appelant. La
anyOfliste contient de 1 à 100 entrées. Chaque entrée spécifie etiamPrincipalcontient les champs suivants :-
arn— L'ARN principal de l'IAM à faire correspondre. -
operator(facultatif) — L'opérateur de comparaison. Les valeurs valides sontStringEquals(par défaut) etStringLike. À utiliserStringLikepour la mise en correspondance de caractères génériques.
-
- MatchPaths
-
Fait correspondre les 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 le 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 de l'état
-
Dans un type de condition : la passerelle utilise la logique OR. Une demande correspond si elle répond à une entrée de la
anyOfliste. -
Quels que soient les types de conditions : la passerelle utilise la logique AND. Si une règle comporte à la fois
matchPrincipalsetmatchPaths, la demande doit correspondre à au moins une entrée de 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 au bundle de configuration ()
configurationBundle -
Remplacez le bundle de configuration appliqué au trafic correspondant.
-
staticOverride— Épingle tout le trafic correspondant à une version spécifique du bundle de configuration. Spécifiez l'ARN du bundle et l'ID de version. -
weightedOverride— Répartit le trafic entre deux versions du bundle de configuration. LatrafficSplitliste doit contenir exactement 2 entrées dont la somme des pondérations est égale à 100. Le bundle de configuration doit se trouver dans le même compte que la passerelle.
-
- Routage cible (
routeToTarget) -
Routes 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 dont la somme des pondérations est égale à 100. Les noms des entrées fractionnées 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 |
|
Plage de priorités |
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
