Configuration d'un service OVHcloud Load Balancer avec les routes HTTP

Objectif

Le service Load Balancer OVHcloud redirige le trafic entrant du frontend vers les serveurs de la ferme par défaut de ce frontend, ou sa redirection par défaut.

Dans certains cas, il est possible d'aller plus loin et de router, rediriger ou rejeter le trafic selon divers critères. Par exemple, dans le cas d'un service HTTP(S), il est possible de filtrer le 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 OVHcloud Load Balancer, ces éléments sont appelés routes. Une route est une action particulière à effectuer si une ou plusieurs conditions sont remplies.

Ce guide vous montrera comment diriger vos requêtes dynamiquement vers une ferme spécifique grâce à l'utilisation de routes.

Prérequis

• Disposer d'un Load Balancer OVHcloud sur une offre autorisant la création des routes.
• Avoir accès à l'API OVHcloud.

En pratique

Cette fonctionnalité n'est disponible que via l'API. Ce guide vous présentera les principes généraux ainsi que des scénarios d'utilisation des routes tirés de cas d'usages réels.

Introduction aux routes

Une route sert à contrôler le trafic selon différents critères. Il est possible de les exprimer sous forme de règles, de conditions ou d'actions.

Par exemple, SI l'URL commence par '/wp-admin/' (1) ET la connexion est en HTTP (2) ALORS rediriger vers la version HTTPS de la page (3).

Dans cet exemple, il y a deux règles :

• la connexion doit provenir d'un frontend HTTP (2) ;
• son URL doit commencer par les pages d'administration de WordPress (1).

Il y a une action associée à ces règles : rediriger vers la version HTTPS de la page (3).

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.

Présentation de l'API

La gestion des routes n'est accessible qu'au travers de l'API OVHcloud. Elle n'est valable que pour les protocoles http et tcp, et le chemin /ipLoadbalancing/{serviceName}/{protocol}/route/ expose l'API dédiée aux routes.

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

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

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

• Une route peut avoir plusieurs règles.
• Une route ne peut être attachée qu'à un seul frontend.
• Un frontend peut avoir plusieurs routes. Dans ce cas, l'ordre d'évaluation dépend de son type et de son poids.

Quand une requête arrive sur votre service OVHcloud Load Balancer, les routes sont évaluées successivement selon les principes suivants :

1. D'abord, les routes de type reject et rewrite, puis les routes de type farm ;
2. À l'intérieur de ces catégories, les routes sont évaluées par poids croissant ;
3. Si deux routes ont le même poids, la première route créée est évaluée en premier ;
4. Seule la première action de toutes les règles 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 OVHcloud Load Balancer. Elle contient un appel pour les actions et un autre pour les règles. Ces deux appels retournent une liste d'objets. Chaque objet est nommé, et indique s'il s'applique aux routes TCP ou HTTP, ainsi que les valeurs ou types de valeurs attendus 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

Pour plus d'information sur cet appel, nous vous invitons à consulter la section Actions disponibles, en bas de ce guide.

Règles

Pour plus d'information sur cet appel, nous vous invitons à consulter la section Règles disponibles, en bas de ce guide.

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.

Pour plus d'information sur cet appel, nous vous invitons à consulter la section "Manipulation des routes", en bas de ce guide.

Configuration des routes

Avec ces principes de base sur les actions et règles disponibles, et l'ordre d'évaluation des routes, ces routes peuvent être manipulées de la même manière que les fermes. Lorsque vous créez une route, vous pouvez y attacher des règles. Les valeurs possibles pour les règles et les actions sont définies par les appels API.

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

Exemples

Afin de démontrer l'utilité des routes, cette section offrira quelques exemples pratiques de l'utilisation de cette technologie pour les besoins internes d'OVHcloud, sans entrer dans les détails des appels API.

Vous trouverez le détail des appels 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 protocole HTTPS est devenu la norme. Son objectif est de rendre tous les sites web disponibles en HTTPS de manière sécurisée, grâce au protocole SSL/TLS. Si vous avez besoin d'un certificat SSL/TLS, vous pouvez utiliser votre service OVHcloud Load Balancer pour en commander un nouveau, qui sera géré pour vous de manière complètement automatique.

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

Une approche pourrait être de s'appuyer sur le début des URLs WordPress. Par défaut, l'URL des pages de connexion de WordPress commence par /wp-login. Nous aurions donc besoin des élements suivants :

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

En pratique, cela donne une route comme suit :

Sur cette route, nous allons attacher une règle :

Ensuite, appliquez la configuration à la zone concernée.

Route 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 pour votre site web, d'un OVHcloud Load Balancer pour assurer la terminaison SSL/TLS, et de redirections vers une page de maintenance avec un serveur de secours dans les fermes, vous auriez autrefois eu besoin d'une Additional IP par site web, routée vers votre OVHcloud Load Balancer, et d'un frontend par IP.

Avec les routes, vous pouvez partager le même frontend et choisir la ferme de serveurs dynamiquement, grâce au champ "[a-z]*".

Pour cela, vous aurez besoin :

• d'une route par VHost ;
• d'une règle par route détectant un domaine spécifique.

En pratique, pour router le domaine www.example.com, cela donnera la route suivante :

Et sur cette route, nous allons attacher une règle :

Enfin, appliquez la configuration.

Réserver une Additional IP à un site web particulier

Si vous hébergez un site web sur un VPS, vous pourriez vouloir dédier une adresse IP à un client donné. Vous pouvez facilement rendre l'IP disponible en la routant vers votre service OVHcloud Load Balancer, puis en configurant un frontend dédié attaché à cette Additional IP, et en définissant le VPS cible du client comme defaultFarmId.

Néanmoins, que se passera-t-il si un autre client détecte cela et configure son domaine pour pointer vers l'IP du client premium ? Par défaut, cela fonctionnera, et son site web sera routé vers le VPS d'un autre client. Si un certificat SSL/TLS est présent, cela fonctionnera toujours, car tous les certificats sont automatiquement disponibles pour l'ensemble des frontends.

Dans de tels scénarios, la solution est d'ajouter une règle qui rejettera les requêtes si le domaine n'est pas un domaine premium. Vous pouvez le faire avec une route de rejet et une règle.

En pratique, pour réserver un frontend avec une IP dédiée au domaine www.example.com, cela donnera la route suivante :

Et sur cette route, nous allons attacher une règle :

Enfin, appliquez la configuration.

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

Sur certaines infrastructures spécifiques, certaines requêtes doivent être routées vers une ferme spécifique. Par exemple, pour gérer des requêtes rares mais gourmandes en données sans impacter la production, comme des requêtes analytiques qui travailleraient sur une copie en lecture seule des données avec un serveur disposant d'un volume de mémoire plus élevé.

Si, par exemple, la requête est envoyée :

• avec la méthode POST ;
• sur une URL correspondant à "^/.*/batch-analytics$".

Alors, vous auriez besoin d'une route avec deux règles, dont une utilisant une expression régulière.

En pratique, cela donne une route comme suit :

Et sur cette route, nous allons attacher deux règles :

Ici, la première règle s'applique sur une énumération. Seules les méthodes HTTP standard sont disponibles. La deuxième règle exploite quant à elle 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 plus 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 affecter la majorité des utilisateurs. Généralement, lorsque l'on configure ce type d'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.

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 OVHcloud 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 deux routes identiques :

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

La première règle teste si l'IP source est dans une liste de plage d'adresses. Dans ce cas, les différentes plages d'adresses sont séparées par des virgules et peuvent être entourées d'espaces 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és, 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 plus 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 ferme de serveurs dédiée à cette tâche. Et c'est en réalité 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 :

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

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

Références

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.

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'à 50 routes sur un service OVHcloud Load Balancer. Cet appel retourne la route créée en cas de succès. Votre service OVHcloud Load Balancer doit être re-déployé pour appliquer les changements.

Les types d'actions possibles sont :

Pour plus d'informations 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 :

• Réponse :

Pour plus d'informations 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 OVHcloud Load Balancer doit être re-déployé pour appliquer les changements.

Pour plus d'informations 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 OVHcloud Load Balancer doit être re-déployé pour appliquer les changements.

Manipulation des règles

Lister les règles

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

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 OVHcloud Load Balancer. Cet appel retourne la règle créée en cas de succès. Votre service OVHcloud Load Balancer doit être re-déployé pour appliquer les changements.

• field

• match

Pour plus d'informations 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 :

• Réponse :

Pour plus d'informations 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 OVHcloud Load Balancer doit être re-déployé pour appliquer les changements.

Pour plus d'informations 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 OVHcloud Load Balancer doit être re-déployé pour appliquer les changements.

Lister l'ensemble des routes TCP et HTTP

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

• Requête :

• Réponse :

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 OVHcloud 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 :

• Réponse :

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 ferme ne recevra la requête.

Seuls les codes d'état HTTP de redirection peuvent être spécifiés. Les plus courants 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 :

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 :

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 ferme ne recevra la requête.

Seuls les codes d'erreur HTTP listés dans l'API peuvent être spécifiés. Les plus courants 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.

Routage

Cette action dirige les requêtes vers une ferme 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").

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 :

• Réponse :

Les différents types de pattern sont :

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.

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 OVHcloud Load Balancer.

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.

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.

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.

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.

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.

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.

Aller plus loin

Échangez avec notre communauté d'utilisateurs.