OVH Guide

Travailler avec les Routes HTTP

Dirigez dynamiquement vos requêtes vers une ferme en particulier

Introduction

Le service OVH Load Balancer permet d'attacher des Frontend à un port ou une IP Failover spécifiques. Ces Frontend peuvent ensuite être attachés à une Farm ou une redirection par défaut. Dans l'API ces paramètres sont respectivement exposés sous les noms defaultFarmId et redirectLocation. Cela permet de router les requêtes entrantes en fonction de paramètres L3 et L4 du modèle OSI, c'est-à-dire en fonction de l'IP ou du port de destination.

Dans le cas d'un service HTTP(S), il est possible d'aller plus loin et router, rediriger ou rejeter du trafic en fonction de la méthode HTTP, de l'URL ou même de la valeur d'un Cookie ou d'un En-Tête ! Dans le service OVH Load Balancer, ce sont les Route. Une Route est une action particulière à réaliser si une ou plusieurs conditions sont réalisées.

Par exemple, SI l'URL commence par '/wp-admin/' ET que la connexion est en HTTP ALORS rediriger vers la version HTTPS de la page. Dans cet exemple, il y a 2 règles : La connexion doit venir d'un Frontend HTTP et son URL doit commencer par les pages d'administration de Wordpress. Il y a une action : rediriger vers la version HTTPS de la page. Il s'agit d'une action "finale". C'est à dire que si les règles sont validées, l'évaluation des routes s'arrête et l'action est exécutée.

Cette fonctionnalité étant encore très jeune, elle est uniquement disponible dans l'API. Ce guide vous présentera les principes généraux ainsi que des scénarii d'utilisation des routes tirés de cas d'usages réels.

Bien que ce guide se concentre sur les Routes HTTP, le même principe fonctionne avec les Farms TCP. Cela peut servir pour diriger le trafic HTTP/2 vers une Farm en particulier ou pour rejeter les requêtes venant de certaines IPs.

Présentation de l'API

L'API des Routes de votre service OVH Load Balancer a été pensée spécialement pour être souple, puissante et évolutive. Elle est organisée autour de 3 sections principales :

  1. Les APIs listant les règles et actions disponibles.
  2. Les APIs listant les routes configurées sur votre service OVH Load Balancer.
  3. Les APIs de configuration des routes de votre service OVH Load Balancer.

Pour n'afficher que les APIs liées aux Routes dans la console d'API OVH, vous pouvez utiliser le champ filter avec le mot clé route.

Lorsque vous souhaitez configurer une route ou des règles, la première chose à faire est de consulter les actions et les règles disponibles. Cela vous donnera les valeurs possibles pour les champs des APIs de configuration des routes et des règles.

  • Une Route peut avoir plusieurs Règles.
  • Une Route peut être attachée à un et un seul Frontend.
  • Un Frontend peut avoir plusieurs Routes. Dans ce cas, l'ordre d'évaluation dépend de leur type et de leur poids.

Quand une requête arrive sur votre service OVH Load Balancer, les routes sont évaluées successivement en suivant ces principes :

  1. D'abord les routes de type reject et rewrite puis enfin les routes de type farm.
  2. À l'intérieur de ces catégories, les routes sont évaluées par poids croissant.
  3. Si 2 routes ont le même poids, la première créée sera la première évaluée.
  4. Seule la première action dont toutes les règles sont validées est exécutée.

Règles et actions disponibles

Cette première section de l'API contient une liste à jour des actions et règles disponibles pour votre service OVH Load Balancer. Elle contient un appel pour les actions et un autre pour les règles. Ces 2 appels retournent une liste d'objets. Chaque objet indique son nom et s'il s'applique aux routes TCP ou aux routes HTTP ainsi que les valeurs ou types de valeur attendues pour les différents champs de l'API. Si un champ est "null", cela signifie qu'aucune valeur n'est attendue. Si une valeur invalide est fournie, l'API retournera une erreur de validation.

Actions

Règles

Routes configurées

Cette deuxième section de l'API ne contient qu'un seul appel. Il a principalement été pensé pour faciliter l'implémentation de mécanismes d'auto-complétion. Il retourne l'identifiant, le nom et le type de chaque route définie. Les détails d'une route peuvent être obtenus avec un appel GET /ipLoadbalancing/{serviceName}/route/{type}/{routeId} défini plus bas.

Configuration des routes

Avec ces principes de base que sont les actions et règles disponibles et l'ordre d'évaluation des routes, les Routes peuvent être manipulées de la même manière que les Farms. Création d'une Route, sur laquelle il est possible d'attacher des Règles. Les valeurs possibles pour les règles et les actions étant définies par les appels d'API.

Pour plus d'informations sur ces méthodes, vous pouvez consulter la section Manipulation des Routes, en bas de ce guide.

Exemples

Si vous n'êtes pas encore convaincu par la puissance des routes, cette section devrait vous convaincre pour de bon. Sans rentrer dans le détail des appels d'APIs, elle a pour vocation de présenter comment réaliser plusieurs cas d'utilisation inspirés de nos besoins internes chez OVH.

Vous trouverez le détail des appels d'API dans la section Manipulation des Routes, en bas de ce guide et les sections suivantes.

Forcer le HTTPS pour les pages de login Wordpress

Le HTTPS est devenu la norme. L'objectif est de rendre tous les sites disponibles de manière sécurisée en HTTPS grâce au protocole SSL/TLS. Si vous avez besoin d'un certificat SSL/TLS, vous pouvez utiliser votre service OVH Load Balancer pour en commander un qui sera géré pour vous de manière complètement automatique.

Migrer un site en HTTPS demande du travail, notamment pour éviter les problèmes de "Mixed-Content". Il peut être intéressant de migrer section par section, en commençant par sécuriser les pages envoyant des identifiants.

Une approche pourrait être de se baser sur le début des URLs Wordpress. Par défaut, l'URL des pages de connexion de Wordpress commencent par "/wp-login". Nous aurions donc besoin :

  • D'une route avec une action de redirection.
  • D'un règle dans cette route qui détecte les URLs commençant par "/wp-login".

Dans la pratique, cela donne une route :

Champ Valeur et description
serviceName Identifiant de votre service OVH Load Balancer
frontendId Identifiant de votre Frontend HTTP
displayName "Redirection des connexions Wordpress vers HTTPS"
weight (vide)
action.type "redirect"
action.status 302 pour une redirection temporaire, 301 pour une redirection permanente
action.target "https://${host}${path}${arguments}" pour reprendre le même host, chemin et arguments

Et sur cette route, on vient attacher une règle :

Champ Valeur et description
serviceName Identifiant de votre service OVH Load Balancer
routeId Identifiant de la Route créée juste au dessus
field "uri"
subField (vide)
match "startswith"
negate false
pattern "/wp-login"

Il ne reste qu'à appliquer la configuration dans la zone concernée et le tour est joué.

Pour ajouter une nouvelle redirection, il faudra renouveler cette opération. Création d'une route, puis création d'une règle. Si une seconde règle est ajoutée sur la même route, les 2 devront être validées pour que la redirection fonctionne. Concrètement, si les règles sont "startswith /wp-login" et "startswith /wp-admin", la redirection ne fonctionnera jamais car il est impossible que ces 2 conditions soient vraies simultanément.

Router en fonction d'un domaine (VHost)

C'est la fonctionnalité qui a rendu possible l'essor du web quand il en était à ses balbutiements, avec la possibilité d'exposer plusieurs sites derrière une même adresse IP grâce au champ "Host" des En-Têtes HTTP.

Par exemple, si votre infrastructure est composée d'un VPS par site Internet et d'un service OVH Load Balancer pour assurer la terminaison SSL/TLS et la redirection vers une page de maintenance avec un serveur de "backup" dans les Farms, il était auparavant nécessaire de disposer d'une IP Failover par site, routée vers votre service OVH Load Balancer et un Frontend par IP.

Avec Les Routes, il devient possible de mutualiser le même Frontend et choisir la Farm de serveurs dynamiquement en fonction du champ "Host".

Pour cela, vous aurez besoin :

  • D'une Route par VHost.
  • D'une Règle par Route détectant un domaine spécifique.

Dans la pratique, pour router le domaine www.example.com, cela donne une route :

Champ Valeur et description
serviceName Identifiant de votre service OVH Load Balancer
frontendId Identifiant de votre Frontend
displayName "VHost - www.example.com"
weight (vide)
action.type "farm"
action.status (vide)
action.target Identifiant de la Farm vers laquelle diriger ce domaine

Et sur cette route, on vient attacher une règle :

Champ Valeur et description
serviceName Identifiant de votre service OVH Load Balancer
routeId Identifiant de la Route créée juste au dessus
field "host"
subField (vide)
match "is"
negate false
pattern "www.example.com" ou le domaine de votre choix

Il ne reste qu'à appliquer la configuration.

Réserver une IP Failover à un site en particulier

Si l'on reste sur le scénario de l'hébergement à base de VPS, on peut souhaiter dédier une adresse IP à un client donné. Rendre l'IP disponible se fait facilement en la routant vers votre service OVH Load Balancer puis en configurant un Frontend dédié attaché à cette adresse IP Failover et ayant comme defaultFarmId le VPS cible de ce client.

Néanmoins, que se passe-t-il si un autre client détecte cela et configure son domaine pour pointer vers l'adresse IP du client premium ? Par défaut, cela fonctionnera et son site sera routé vers l'autre VPS. S'il y a un certificat SSL/TLS, cela fonctionnera quand même car l'ensemble des certificats sont automatiquement disponibles pour l'ensemble des Frontends.

Dans ce scénario, l'idée est d'ajouter une règle qui va rejeter les requêtes si le domaine n'est pas le domaine premium. Cela peut se faire simplement avec une route de rejet et une règle.

Dans la pratique, pour réserver un Frontend avec une IP dédiée au domaine www.example.com, cela donne une route :

Champ Valeur et description
serviceName Identifiant de votre service OVH Load Balancer
frontendId Identifiant de votre Frontend
displayName "Restrict to www.example.com"
weight (vide)
action.type "reject"
action.status 403
action.target (vide)

Et sur cette route, on vient attacher une règle :

Champ Valeur et description
serviceName Identifiant de votre service OVH Load Balancer
routeId Identifiant de la Route créée juste au dessus
field "host"
subField (vide)
match "is"
negate true
pattern "www.example.com" ou le domaine de votre choix

Il ne reste qu'à appliquer la configuration.

Router en fonction d'une URL et d'une méthode HTTP

Sur certaines infrastructures spécifiques, il est nécessaire de router certaines requêtes vers une Farm spécifique. Par exemple, pour gérer des requêtes rares mais coûteuses sans impacter de la production telles que des requêtes analytiques que l'on ferait fonctionner sur un réplicat en lecture seul des données avec une machine avec plus de mémoire.

Disons par exemple que la requête est envoyée :

  • Avec la méthode POST.
  • Sur une URL correspondant à "^/.*/batch-analytics$"

Pour cet exemple, vous aurez besoin d'une route avec 2 règles, l'une d'entre elles utilisant une expression régulière.

Dans la pratique, cela donne une route :

Champ Valeur et description
serviceName Identifiant de votre service OVH Load Balancer
frontendId Identifiant de votre Frontend
displayName "Route batch analytics to dedicated farm"
weight (vide)
action.type "farm"
action.status (vide)
action.target Identifiant de la Farm vers laquelle diriger ces opérations

Et sur cette route, on vient attacher 2 règles :

Champ Règle 1 Règle 2
serviceName Identifiant de votre service OVH Load Balancer idem
routeId Identifiant de la Route créée juste au dessus idem
field "method" "uri"
subField (vide) (vide)
match "is" "matches"
negate false false
pattern "POST" "^/.*/batch-analytics$"

Ici, la première règle s'applique sur une énumération. Seules les méthodes HTTP standards sont disponibles. La deuxième règle au contraire exploite toute la puissance des routes en utilisant une expression régulière. Bien que ce soit possible d'utiliser de telles expressions, si vous pouvez vous en passer, les performances n'en seront que meilleures.

Il ne reste qu'à appliquer la configuration dans la zone concernée.

Router certaines IP et les clients volontaires vers la preproduction

Quand un site prend de l'ampleur, on peut souhaiter mettre en place un environnement de préproduction permettant de valider les évolutions en cours, sans impacter la majorité des utilisateurs. Généralement, lorsque l'on configure ce type environnement, on cherche à réduire autant que possible l'écart entre la production et la préproduction de manière à détecter les problèmes avec le plus de précision possible. Une source de problème classique et pourtant souvent négligée est le nom de domaine. Il est parfois codé "en dur" dans un fichier ou un article. À ce moment, un lien pourra fonctionner en préproduction mais pas en production. Oups...

Au lieu de mettre en place des règles basées sur le nom de domaine, on pourrait mettre en place des règles basées sur l'adresse IP source (par exemple, un proxy d'entreprise) et, éventuellement un Cookie pour les clients volontaires. Ces configurations peuvent être détectées avec deux Routes sur votre service OVH Load Balancer.

Pour cet exemple, on considérera :

  • Que le proxy d'entreprise peut utiliser les adresses 42.42.42.0/24 et que le VPN utilise 1.2.3.4/32.
  • Que les utilisateurs volontaires ont un Cookie "PreprodOptIn", dont la valeur n'a pas d'importance.

Dans la pratique, vous aurez besoin de 2 routes identiques :

Champ Valeur et description
serviceName Identifiant de votre service OVH Load Balancer
frontendId Identifiant de votre Frontend
displayName "Route Opt-In and internal users to preproduction environment"
weight (vide)
action.type "farm"
action.status (vide)
action.target Identifiant de la Farm de préproduction

Puis on vient attacher les 2 règles suivantes, chacune sur une des routes (1 règle par route) :

Champ Règle 1 Règle 2
serviceName Identifiant de votre service OVH Load Balancer idem
routeId Identifiant de la 1ère Route Identifiant de la 2ème Route
field "source" "cookie"
subField (vide) "PreprodOptIn"
match "in" "exists"
negate false false
pattern "42.42.42.0/24, 1.2.3.4" (vide)

La première règle teste si l'IP source est dans une liste de plage d'adresse. Dans ce cas, les différentes plages d'adresses sont séparées par des virgules et peuvent être entourées d'espace pour plus de lisibilité. Si une plage ne contient qu'une seule adresse, le "/32" est implicite mais peut être mis explicitement. Dans tous les cas, la taille de ce champ est limité à 255 caractères.

La seconde règle teste simplement l'existence du cookie. Il serait possible de tester si sa valeur correspond à une expression régulière ou se trouve dans une liste de possibilité, mais cela permet de montrer un exemple simple de ce qui peut être fait avec des cookies. Les règles basées sur les En-Têtes HTTP fonctionnent suivant une approche similaire.

Il ne reste qu'à appliquer la configuration dans la zone concernée.

Router les WebSockets vers une Ferme dédiée

Lorsqu'un site dispose de fonctions interactives basées sur des WebSockets telles qu'un chat-bot, on peut souhaiter diriger ces connexions vers une Farm de serveurs dédiée à cette tâche. Et c'est en fait très simple. Quand un navigateur cherche à ouvrir une connexion WebSockets, il envoie une requête HTTP standard avec les En-Têtes :

Upgrade: websocket
Connection: Upgrade

Dans la pratique, il suffit de détecter le premier En-Tête. Cela peut se faire très facilement avec une route et une règle :

Champ Valeur et description
serviceName Identifiant de votre service OVH Load Balancer
frontendId Identifiant de votre Frontend
displayName "Route WebSockets to a dedicated farm"
weight (vide)
action.type "farm"
action.status (vide)
action.target Identifiant de la Farm dédiée au WebSockets

Et sur cette route, on vient attacher une règle :

Champ Valeur et description
serviceName Identifiant de votre service OVH Load Balancer
routeId Identifiant de la Route créée juste au dessus
field "header"
subField "Upgrade"
match "is"
negate false
pattern "websocket" (sensible aux majuscules / minuscules)

Il ne reste qu'à appliquer la configuration dans la zone concernée.

Référence

Vous trouverez ici le détail des appels d'API liés aux routes. Pour une vue plus générale des fonctionnalités des routes, nous vous invitons d'abord à consulter la section Présentation de l'API un peu plus haut dans ce guide.

Manipulation des Routes

Les Routes TCP et HTTP se configurent de la même manière. Les routes étant plus puissantes en HTTP, cette section se concentre sur les routes et les règles HTTP. Le fonctionnement des routes TCP peut être extrapolé en remplaçant "http" par "tcp" dans les routes. Certains champs n'ayant de sens qu'en HTTP, ils ne sont pas disponibles en TCP.

Lister les routes

Cet appel retourne la liste des identifiants numériques des routes définies pour le protocole HTTP. Il est possible de filtrer cette liste par frontendId. Cet appel retourne les routes dans l'ordre dans lequel elles seront évaluées. L'ordre d'évaluation peut être en partie contrôlé avec le "poids" (weight) de la route.

Paramètre Requis Signification
serviceName Requis Identifiant de votre service Load Balancer
frontendId Identifiant numérique d'un Frontend HTTP auquel les routes sont attachées

Créer une route

Cet appel permet de créer une route. Seule l'action est obligatoire. Une route peut être attachée et détachée d'un Frontend. Il est possible de créer jusqu'à 20 routes sur un service OVH Load Balancer. Cet appel retourne la route créée en cas de succès. Votre service OVH Load Balancer doit être re-déployé pour appliquer les changements.

Paramètre Requis Signification
serviceName Requis Identifiant de votre service Load Balancer
displayName Nom d'affichage de votre route (255 caractères maximum)
frontendId Identifiant numérique d'un Frontend HTTP auquel rattacher la route
weight Priorité de la route, entre 1 (passe d'abord) et 255 (passe après les autres)
action.type Requis Nom du type d'action à exécuter si l'ensemble des règles associées à la route sont validées
action.status Code d'état HTTP pour les actions reject et redirect
action.target Identifiant numérique de la ferme cible pour les actions farm, ou modèle d'URL pour les actions redirect

Les types d'actions possibles sont :

action Signification
redirect Rediriger une requète vers action.target avec le code d'état HTTP action.status
reject Rejeter une requête avec le code d'état HTTP action.status
farm Router une requête vers la ferme dont l'identifiant est renseigné dans action.target

Pour plus d'information sur les actions gérées ainsi que le format des paramètres, nous vous invitons à consulter la section Actions disponibles plus bas dans ce guide.

Voir le détail d'une route

Cet appel permet de consulter le détail d'une route HTTP, connaissant son identifiant.

Requête

Paramètre Signification
serviceName Identifiant de votre service Load Balancer
routeId Identifiant numérique de la route

Réponse

Paramètre Signification
routeId Identifiant numérique de la route
displayName Nom d'affichage de votre route
frontendId Identifiant numérique du frontend auquel votre route est rattachée
weight Priorité de votre route
action.type Nom du type d'action de votre route
action.status Code d'état HTTP associé
action.target Identifiant numérique de la ferme ou modèle d'URL associé
rules Liste des règles devant être validées pour déclencher l'action de la route. Plus de détails sont disponibles dans la section Manipulation des Règles.

Pour plus d'information sur les actions gérées ainsi que le format des paramètres, nous vous invitons à consulter la section Actions disponibles plus bas dans ce guide.

Modifier une route

Cet appel permet de modifier une route HTTP, connaissant son identifiant. Votre service OVH Load Balancer doit être re-déployé pour appliquer les changements.

Paramètre Requis Signification
serviceName Requis Identifiant de votre service Load Balancer
routeId Requis Identifiant numérique de la route
displayName Nom d'affichage de votre route (255 caractères maximum)
frontendId Identifiant numérique d'un Frontend HTTP auquel rattacher la route
weight Priorité de la route, entre 1 (passe d'abord) et 255 (passe après les autres)
action.type Requis Nom du type d'action à exécuter si l'ensemble des règles associées à la route sont validées
action.status Code d'état HTTP pour les actions reject et redirect
action.target Identifiant numérique de la ferme cible pour les actions farm, ou modèle d'URL pour les actions redirect

Pour plus d'information sur les actions gérées ainsi que le format des paramètres, nous vous invitons à consulter la section Actions disponibles plus bas dans ce guide.

Supprimer une route

Cet appel permet de supprimer une route HTTP, connaissant son identifiant. Lorsqu'une route est supprimée, l'ensemble des règles associées à cette route sont supprimées également. Il n'est pas nécessaire de les supprimer individuellement. Votre service OVH Load Balancer doit être re-déployé pour appliquer les changements.

Paramètre Requis Signification
serviceName Requis Identifiant de votre service Load Balancer
routeId Requis Identifiant numérique de la route

Manipulation des Règles

Lister les règles

Cet appel retourne la liste des identifiants numérique des règles définies pour une route donnée.

Paramètre Requis Signification
serviceName Requis Identifiant de votre service Load Balancer
routeId Requis Identifiant numérique de la route

Attacher une règle

Cet appel permet d'attacher une règle à une route. Il est possible d'attacher jusqu'à 5 règles par route sur un service OVH Load Balancer. Cet appel retourne la règle créée en cas de succès. Votre service OVH Load Balancer doit être re-déployé pour appliquer les changements.

Paramètre Requis Signification
serviceName Requis Identifiant de votre service Load Balancer
routeId Requis Identifiant numérique de la route
field Requis Nom du paramèter HTTP sur lequel appliquer cette règle
subField Nom de l'en-tête HTTP pour les règles header ou nom du cookie pour les règles cookie
match Requis Nom du comparateur à appliquer pour valider la règle
negate Inverse le résultat du comparateur
pattern Argument du comparateur

field

Valeur Signification
source Adresse ou liste d'adresses source sous la forme d'IP (a.b.c.d/z)
protocol Protocole. "http" ou "https"
method Méthode HTTP (GET, HEAD, POST, PUT, DELETE, OPTIONS, CONNECT, TRACE)
host Nom de domaine (vhost), sans le numéro de port
uri Chamin de la requête tel que compris entre le premier "/" et le premier "?"
param Paramètre HTTP venant de la partie après le premeir "?"
header En-tête HTTP
cookie Cookie HTTP

match

Valeur Signification
exists La propriété doit exister (en-tête ou cookie HTTP par exemple)
is La propriété doit correspondre exactement à pattern
in La propriété doit être dans la liste de valeurs (séparées par des virgules) définie par parttern
contains La propriété doit contenir la valeur de pattern
startswith La propriété doit commencer par la valeur de pattern
endswith La propriété doit se terminer par la valeur de pattern
matches La propriété doit correspondre à l'expression régulière de pattern

Pour plus d'information sur les règles gérées ainsi que le format des paramètres, nous vous invitons à consulter la section Règles disponibles plus bas dans ce guide.

Voir le détail d'une règle

Cet appel permet de consulter le détail d'une règle attachée à une route HTTP, connaissant son identifiant.

Requête

Paramètre Signification
serviceName Identifiant de votre service Load Balancer
routeId Identifiant numérique de la route
ruleId Identifiant numérique de la règle

Réponse

Paramètre Signification
ruleId Identifiant numérique de la règle
field Nom du paramèter HTTP sur lequel appliquer la règle
subField Nom de l'en-tête HTTP ou du cookie pour la règle
match Nom du comparateur à appliquer pour valider la règle
negate "true" si le résultat du comparateur est inversé
pattern Argument du comparateur. Le sens et la syntaxe dépendent de match et de field

Pour plus d'information sur les règles gérées ainsi que le format des paramètres, nous vous invitons à consulter la section Règles disponibles plus bas dans ce guide.

Modifier une règle

Cet appel permet de modifier une règle attachée à une route HTTP, connaissant son identifiant. Votre service OVH Load Balancer doit être re-déployé pour appliquer les changements.

Paramètre Requis Signification
serviceName Requis Identifiant de votre service Load Balancer
routeId Requis Identifiant numérique de la route
ruleId Requis Identifiant numérique de la règle
field Requis Nom du paramèter HTTP sur lequel appliquer cette règle
subField Nom de l'en-tête HTTP pour les règles header ou nom du cookie pour les règles cookie
match Requis Nom du comparateur à appliquer pour valider la règle
negate Inverse le résultat du comparateur
pattern Argument du comparateur

Pour plus d'information sur les règles gérées ainsi que le format des paramètres, nous vous invitons à consulter la section Règles disponibles plus bas dans ce guide.

Supprimer une règle

Cet appel permet de supprimer une règle attachée à une route HTTP, connaissant son identifiant. Votre service OVH Load Balancer doit être re-déployé pour appliquer les changements.

Paramètre Requis Signification
serviceName Requis Identifiant de votre service Load Balancer
routeId Requis Identifiant numérique de la route
ruleId Requis Identifiant numérique de la règle

Si vous souhaitez supprimer une route, il n'est pas nécessaire de supprimer l'ensemble des règles attachées à celle-ci. Les règles sont automatiquement supprimées lorsque vous supprimez une route.

Lister l'ensemble des routes TCP et HTTP

Cet appel permet de lister l'ensemble des identifiants, nom d'affichage et type ("http"/"tcp") des routes définies sur un service OVH Load Balancer. Il a été pensé pour simplifier l'implémentation d'auto-complétion.

Requête

Paramètre Signification
serviceName Idenfiant de votre service Load Balancer

Réponse

Paramètre Signification
type Type de protocole de la route: "tcp" pour les routes TCP, "http" pour les routes HTTP
routeId Identifiant numérique de la route
displayName Nom d'affichage de la route

Actions disponibles

Cet appel retourne la liste des actions disponibles pour les Routes TCP et HTTP ainsi que les valeurs attendues pour chacun des champs.

Si un champ est "null", cela signifie qu'aucune valeur n'est attendue. Si une valeur invalide est fournie, l'API retournera une erreur de validation.

L'ensemble des actions gérées par le service OVH Load Balancer sont finales. C'est à dire que l’exécution d'une action entraîne également la fin de l'évaluation des routes.

Requête

Paramètre Signification
serviceName Idenfiant de votre service Load Balancer

Réponse

Paramètre Signification
type Indique si cette action est valide pour une route HTTP ou une route TCP
name Nom de l'action à renseigner dans le champs type des routes
status Liste des codes d'état HTTP disponibles pour cette action (champs status des routes)
destination Type de valeur attendue dans le champs destination des routes

Redirection

Cette action renvoie une redirection au visiteur. Le type de redirection peut être configuré avec le champ status. Lorsque cette action est sélectionnée, aucune Farm ne recevra la requête.

Paramètre Valeur
type redirect
status 301, 302, 303, 307 ou 308
target URL de destination (peut contenir des variables)

Seuls les codes d'état HTTP de redirection peuvent être spécifiés. Les plus courant sont les codes 301 et 302. Si vous hésitez, vous pouvez prendre le 302 "Redirection temporaire". Les codes d'état HTTP reconnus pour les redirections sont :

Code de status Description
301 Redirection permanente. La redirection peut être enregistrée par le navigateur.
302 (default) Redirection temporaire. La redirection doit être revalidée à chaque requête par le navigateur.
307 Comme le 302 et force l'utilisation de la méthode HTTP GET.
307 Comme le 302 et force le ré-utilisation de la même méthode HTTP (GET, POST, ...).
308 Comme le 301 et force le ré-utilisation de la même méthode HTTP (GET, POST, ...).

L'URL de destination peut contenir des variables simples. Cela permet de rediriger simplement vers un autre domaine, un autre protocole ou ajouter un suffixe / préfixe à une URL. Les variables reconnues sont :

Variable Description
protocol Protocole de la requête ("http" ou "https")
domain Nom de domaine de la requête, sans le numéro de port
host Champ "Host" de la requête, incluant le numéro de port s'il y en a un
port Port de la requête
path Chemin de la requête, commence par un '/' et fini avant le premier '?'
arguments Arguments de la requête, commence par le '?' si présent

Par exemple, pour :

  • rediriger vers https : https://${host}${path}${arguments}
  • rediriger vers un nouveau domaine : ${protocol}://new.example.com${path}${arguments}
  • préfixer l'url: ${protocol}://${host}/staging${path}${arguments}

Rejet

Cette action renvoie un code d'état HTTP d'erreur au visiteur. Le code d'erreur HTTP peut être configuré avec le champ status. Lorsque cette action est sélectionnée, aucune Farm ne recevra la requête.

Paramètre Valeur
type reject
status 200, 400, 403, 405, 408, 429, 500, 502, 503 ou 504
target non disponible

Cette action est aussi disponible en TCP. Dans ce cas, le paramètre status n'est pas disponible et la requête est terminée. Les requêtes TCP terminées de cette manière ne sont pas comptabilisées dans de débit de requêtes.

Seuls les codes d'erreur HTTP listés dans l'API peuvent être spécifiés. Les plus courant sont les codes 400 "Bad request" et 403 "Forbidden". 200 peut être utilisé pour bloquer un type de requête tout en simulant un succès et 503 peut être utilisé pour simuler une panne serveur.

Code de status Description
200 La requête a été exécutée avec succès.
400 Requête invalide.
403 (default) Accès interdit.
405 Méthode (GET, POST, PUT, ...) invalide ou non gérée.
408 La requête a pris trop de temps à être envoyée par le client.
429 La client a envoyé trop de requêtes (rate-limiting).
500 Erreur serveur générique.
502 Erreur de communication avec le serveur.
503 Le service est temporairement indisponible.
504 Le serveur a mis trop de temps à répondre.

Routage

Cette action dirige les requêtes vers une Farm spécifique, autre que la Ferme par défaut configurée sur le Frontend. La Ferme de destination doit être du même type que le Frontend ("http" ou "tcp").

Paramètre Valeur
type farm
status non disponible
target Identifiant numérique de la Ferme de destination. Celle-ci doit être du même type

Cette action est aussi disponible en TCP. Dans ce cas, la Farm de destination doit être de type "tcp".

Règles disponibles

Cet appel retourne la liste des règles disponibles pour les Routes TCP et HTTP ainsi que les valeurs attendues pour chacun des champs.

Si un champ est "null", cela signifie qu'aucune valeur n'est attendue. Si une valeur invalide est fournie, l'API retournera une erreur de validation.

Requête

Paramètre Signification
serviceName Identifiant de votre service Load Balancer

Réponse

Paramètre Signification
type Type de protocole de la route: "tcp" pour les routes TCP, "http" pour les routes HTTP
name Nom de la propriété sur laquelle s'applique cette règle, à renseigner dans le champs field
hasSubField "true" si cette propriété à une "sous propriété" (par exemple : un en-tête ou un cookie)
matches Liste des comparateurs disponibles pour cette règle, à renseigner dans le champs match
pattern Tupe de valeur attendue pour le champs pattern
enum Liste des valeurs possibles pour le chmaps pattern si celui-ci est une énumération

Les différents types de pattern sont :

Valeur Signification
cidr Adresse IP (a.b.c.d) ou sous-réseau (a.b.c.d/z)
string Texte libre. Pour l'opérateur in, liste de valeurs séparées par des virgules (255 caractères maximum)
enum Le champs est une énumération définie dans enum

Protocole

Cette règle permet de filtrer les requêtes en fonction de leur protocole. Dans la pratique, les cas d'usage de cette règle sont assez limités car le protocole dépend du Frontend auquel la Route est attachée or un Frontend ne gère qu'un seul protocole qui est alors connu au moment de la définition de la route.

Champs Valeur
name protocol
hasSubField non
matches is ou in
pattern tcp, tls, http ou https

Cette action est aussi disponible en TCP. Dans ce cas, le protocole "http/2.0" est également disponible. Il se base sur le champ SSL/TLS "ALPN" utilisé par les navigateurs pour annoncer qu'ils tentent d'établir une connexion HTTP/2.0. Cela permet d'avoir un Frontend TCP commun pour la terminaison SSL/TLS du HTTP 1 et 2 puis diriger ces flux en fonction de la version du protocole.

Adresse source

Cette règle permet de filtrer les requêtes en fonction de leur adresse source. En la combinant avec une règle basée sur l'URI ou le nom de domaine, cela permet par exemple de restreindre certaines ressources à un proxy d'entreprise tout en exposant toutes les autres ressources sans restrictions au niveau de votre service OVH Load Balancer.

Champs Valeur
name source
hasSubField non
matches is ou in
pattern Sous-réseau (a.b.c.d/z) ou adresse (a.b.c.d)

Cette action est aussi disponible en TCP avec le même comportement.

Par exemple, pour bloquer un réseau et une adresse en particulier, on pourra utiliser un pattern tel que "4.4.0.0/16, 8.8.8.8".

Nom de domaine

Cette règle permet de filtrer les requêtes en fonction de leur nom de domaine. Cela permet par exemple de reproduire la fonction "vhost" de Apache ou router l'ensemble des domaines commençant par "mail." vers un serveur dédié au webmail.

Champs Valeur
name host
hasSubField non
matches is, in, contains, startswith, endswith ou matches
pattern Chaîne de caractères ou expression régulière

Cette action est aussi disponible en TCP. Elle n'aura de sens que si le Frontend est configuré pour accepter des connexions SSL/TLS et que le client envoie une option "SNI". C'est notamment le cas des navigateurs web récents.

Méthode HTTP

Cette règle permet de filtrer les requêtes en fonction de la méthode HTTP. Elle sera communément utilisée de paire avec une règle basée sur l'URI ou chemin de la requête pour rendre la règle plus sélective.

Champs Valeur
name method
hasSubField non
matches is ou in
pattern GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS ou TRACE

Chemin de la requête

Cette règle permet de filtrer les requêtes en fonction du chemin de la requête ou URI. Le chemin de la requête est la portion comprise entre le 1er '/' inclus et le premier '?' exclu.

Champs Valeur
name uri
hasSubField non
matches is, in, contains, startswith, endswith ou matches
pattern Chaîne de caractères ou expression régulière

Paramètre de la requête

Cette règle permet de filtrer les requêtes en fonction de l'existence ou de la valeur d'un paramètre spécifique de la requête HTTP. Il s'agit de la partie après le premier '?'. Si un paramètre est spécifié plusieurs fois dans la requête, seul le premier est pris en compte.

Champs Valeur
name param
hasSubField oui
matches is, in, contains, startswith, endswith ou matches
pattern Chaîne de caractères ou expression régulière

En-Tête HTTP

Cette règle permet de filtrer les requêtes en fonction de l'existence ou de la valeur d'un En-Tête HTTP spécifique. Cela permet par exemple de détecter l'ouverture d'une connexion websocket et la diriger vers une Ferme dédiée.

Champs Valeur
name header
hasSubField oui
matches is, in, contains, startswith, endswith ou matches
pattern Chaîne de caractères ou expression régulière

Cookie

Cette règle permet de filtrer les requêtes en fonction de l'existence ou de la valeur d'un Cookie HTTP spécifique. Cela permet par exemple de diriger les visiteurs volontaires vers une Ferme de préproduction.

Champs Valeur
name cookie
hasSubField oui
matches is, in, contains, startswith, endswith ou matches
pattern Chaîne de caractères ou expression régulière