Configuring an OVHcloud Load Balancer with HTTP routes

The OVHcloud Load Balancer service redirects the front-end’s incoming traffic to the servers that make up the front-end’s default farm, or its default redirection.

In some cases, you can go further and route, redirect, or block traffic according to a range of criteria. For example, in the case of an HTTP(S) service, you can filter traffic based on the HTTP method, the URL, or even the value of a cookie or header.

In the OVHcloud Load Balancer service, these elements are called routes. A route is a specific action to perform if one or more conditions are met.

Requirements

• An OVHcloud Load Balancer on a solution that lets you create routes
• Access to the OVHcloud API

Topics

• Instructions
  • Introduction to routes
  • API presentation
  • Available rules and actions
    • Actions
    • Rules
  • Configured routes
  • Route configuration
• Examples
  • Force HTTPS for WordPress login pages
  • Route based on a domain (VHost)
  • Reserve an Additional IP for a specific website
  • Route based on a URL and an HTTP method
    • Route certain IPs and voluntary clients to preproduction
    • Route WebSockets to a dedicated server cluster
  • References
    • Handling routes
    • Handling rules
    • Available actions
    • Available rules

Instructions

This feature is only available via the API. This guide will present the general principles as well as use cases for routes drawn from real-life scenarios.

Introduction to routes

A route controls traffic according to different criteria. You can express these criteria as rules, conditions, or actions.

For example, IF the URL starts with '/wp-admin/' (1) AND the connection is in HTTP (2) THEN redirect to the HTTPS version of the page (3).

In this example, there are two rules:

• the connection must come from an HTTP front-end (2)
• its URL must begin with the WordPress admin pages (1)

There is an action associated with these rules: redirect to the HTTPS version of the page (3).

This is what is known as an "end action." It means that if the rules are confirmed, the evaluation of routes stops, and the action is executed.

API presentation

You can only manage routes via the OVHcloud API. It is only valid for http and tcp protocols, and the /ipLoadbalancing/{serviceName}/{protocol}/route/ pathway exposes the API dedicated to routes.

The API for routes to the OVHcloud Load Balancer is specially designed for flexibility, power, and scalability. It is organized around three main sections:

1. the APIs listing available rules and actions
2. the APIs listing the routes configured on the OVHcloud Load Balancer service
3. the APIs for configuring routes on the OVHcloud Load Balancer service

When you want to configure a route or rules, the first thing you need to do is to consult the available actions and rules. This will give you the possible values for the configuration fields of the route and rule APIs.

• A route can have several rules.
• A route can only be attached to a single front-end.
• A front-end can have several routes. In this case, the order of evaluation depends on its type and weight.

When a request arrives at your OVHcloud Load Balancer service, the routes are evaluated successively according to the following principles:

1. First, reject and rewrite routes, then the server cluster routes.
2. Within categories, the routes are evaluated in increasing weight order.
3. If two routes are the same weight, the first route created is evaluated first.
4. Only the first action from all the validated rules is executed.

Available rules and actions

This first section of the API contains an updated list of actions and rules available for the OVHcloud Load Balancer service. It contains one call for actions and another for rules. These two calls return a list of objects. Each object is named and indicates whether it applies to TCP or HTTP routers, as well as the expected values or types of values for the different fields of the API. If a field is “null”, this means that no value is expected. If an invalid value is entered, the API will return a validation error.

Actions

For more information on this call, please read the Available actions section at the bottom of this guide.

Rules

For more information on this call, please read the Available rules section at the bottom of this guide.

Configured routes

This section of the API only contains one call. It was mainly designed to help implement auto-completion mechanisms. It returns the ID, name, and type of each defined route. The details of a route can be obtained with a GET /ipLoadbalancing/{serviceName}/<http or tcp>/route/{type}/{routeId} call, defined further below.

For more information on this call, please read the Handling routes section at the bottom of this guide.

Route configuration

With these basic principles for available actions and rules, and the route evaluation order, these routes can be manipulated in the same way as server clusters. When you create a route, you can attach rules to it. The possible values for rules and actions are defined by the API calls.

For more information on these methods, please read the Handling routes section at the bottom of this guide.

Examples

To demonstrate the utility of routes, this section will offer some practical examples of the use of this technology for OVHcloud's internal needs, without going into the details of the API calls.

You can read about API calls in more detail in the Handling routes section at the bottom of this guide, and the sections that follow it.

Force HTTPS for WordPress login pages

The HTTPS protocol has become the norm. Its purpose is to make all websites available in HTTPS in a secure manner, thanks to the SSL/TLS protocol. If you need an SSL/TLS certificate, you can use the OVHcloud Load Balancer service to order a new one, which will be automatically managed for you.

Migrating a website to HTTPS requires work, especially to avoid mixed content problems. It may be worth migrating your website section by section, starting by securing pages that send login credentials.

One approach could be to base it on the beginning of WordPress URLs. By default, the URLs of login pages for WordPress start with "/wp-login". So we would need:

• a route with a redirection action
• a rule in this route that detects URLs starting with "/wp-login"

In practice, this gives a route like this:

On this route, we will attach a rule:

Next, apply the configuration to the zone concerned.

Route based on a domain (VHost)

This is the feature that made the web possible when it was in its infancy, with the possibility of exposing several sites behind the same IP address, thanks to the "Host" field of HTTP headers.

For example, if your infrastructure is made up of a VPS for your website, an OVHcloud Load Balancer for SSL/TLS termination, and redirections to a maintenance page with a backup server in the server clusters, you would need an Additional IP per website, routed to your OVHcloud Load Balancer, and one front-end per IP.

With routes, you can share the same front-end and choose the server cluster dynamically, with the [a-z] field.

To do this, you will need:

• one route per VHost
• one rule per route detecting a specific domain

In practice, to route the domain www.example.com, this would give the following route:

And on this route, we will attach a rule:

Finally, apply the configuration.

Reserve an Additional IP for a specific website

If you are hosting a website on a VPS, you may want to dedicate an IP address to a specific customer. You can easily make the IP available by routing it to your OVHcloud Load Balancer service, then configuring a dedicated front-end attached to this Additional IP, and setting the client's target VPS as the defaultFarmId.

However, what will happen if another client detects this and configures their domain to point to the premium client's IP? By default, this will work, and their website will be routed to another client's VPS. If an SSL/TLS certificate is present, this will still work, as all certificates are automatically available for all frontends.

In such scenarios, the solution is to add a rule that rejects requests if the domain is not a premium one. You can do this with a reject route and a rule.

In practice, reserving a front-end with an IP dedicated to the domain www.example.com will give the following route:

And on this route, we will attach a rule:

Finally, apply the configuration.

Route based on a URL and an HTTP method

On some specific infrastructures, certain requests must be routed to a specific server cluster. For example, to handle rare but data-intensive requests without impacting production, such as analytical requests that work on a read-only duplicate of the data, with a server that has a higher volume of memory.

If, for example, the request is sent:

• with the POST method
• on a URL corresponding to "^/.*/batch-analytics$"

Then, you would need a route with two rules, one of which uses a regular expression.

In practice, this gives a route like this:

And on this route, we will attach two rules:

Here, the first rule applies to an enumeration. Only standard HTTP methods are available. The second rule, on the other hand, exploits the full power of routes by using a regular expression. Although it is possible to use such expressions, avoiding them results in enhanced performance.

All that remains is to apply the configuration in the concerned area.

Route certain IPs and voluntary clients to preproduction

When a site grows, you may want to set up a preproduction environment to validate ongoing changes, without affecting the majority of users. Generally, when configuring this type of environment, you want to reduce the gap as much as possible between production and preproduction to detect problems as accurately as possible. A classic and often neglected source of problems is the domain name. It is sometimes hardcoded in a file or an article. At that point, a link may work in preproduction but not in production.

Instead of setting up rules based on the domain name, you could set up rules based on the source IP address (for example, an enterprise proxy) and possibly a cookie for voluntary clients. These configurations can be detected with two routes on the OVHcloud Load Balancer service.

For this example, we will consider that:

• the enterprise proxy can use the addresses 42.42.42.0/24, and the VPN uses 1.2.3.4/32
• the voluntary users have a "PreprodOptIn" cookie — the value is not important

In practice, will need two identical routes:

Then we will attach the following two rules to each of the routes (one rule per route):

The first rule checks if the source IP is in a list of address ranges. In this case, the different address ranges are separated by commas and can be surrounded by spaces for better readability. If a range contains only one address, the "/32" is implicit but can be added explicitly. In any case, the size of this field is limited to 255 characters.

The second rule simply checks the existence of the cookie. It would be possible to check if its value matches a regular expression or is in a list of possibilities, but this allows to show a simple example of what can be done with cookies. Rules based on HTTP Headers work according to a similar approach.

All that remains is to apply the configuration in the concerned area.

Route WebSockets to a dedicated server cluster

When a website has interactive functions based on WebSockets — a chatbot, for example — you may want to direct these connections to a server cluster dedicated to this task. This is quite simple. When a browser tries to open a WebSockets connection, it sends a standard HTTP request with these headers:

Upgrade: websocket
Connection: Upgrade

In this case, only the first header needs to be detected. This can be done very easily with a route and a rule:

And on this route, we will attach a rule:

Next, apply the configuration to the zone concerned.

References

You will find here the details of the API calls related to routes. For a more general overview of route features, we invite you to first consult the section " API presentation " a little further up in this guide.

Handling routes

TCP and HTTP routes are configured in the same way. Since HTTP routes are more powerful, this section focuses on HTTP routes and rules. The operation of TCP routes can be extrapolated by replacing "http" with "tcp" in the routes. Some fields only make sense in HTTP, so they are not available in TCP.

List the routes

This call returns the list of ID numbers of routes defined for HTTP protocol. You can filter this list by frontendId. This call returns the routes in the order in which they will be evaluated. The evaluation order can be partially controlled by the weight of the route.

Create a route

With this call, you can create a route. Only the action is mandatory. A route can be attached to and detached from a front-end. You can create up to 50 routes on an OVHcloud Load Balancer. This call returns the created route in case of success. Your OVHcloud Load Balancer service must be redeployed to apply the changes.

For further information on the actions managed and the format of parameters, please read the Available actions section further down.

View details on a route

With this call, you can view details on an HTTP route if you know its ID.

For further information on the actions managed and the format of parameters, please read the Available actions section further down.

Modify a route

With this call, you can modify an HTTP route if you know its ID. You will need to redeploy your OVHcloud Load Balancer to apply the changes.

For further information on the actions managed and the format of parameters, please read the Available actions section further down.

Delete a route

With this call, you can delete an HTTP route if you know its ID. When a route is deleted, all of the rules associated with the route are deleted, too. You do not need to delete them individually. You will need to redeploy your OVHcloud Load Balancer to apply the changes.

Handling rules

List the rules

This call returns the list of ID numbers of rules defined for a particular route.

Attach a rule

With this call, you can attach a rule to a route. You can attach up to 5 rules per route on an OVHcloud Load Balancer. This call returns the route created, if it is successful. You will need to redeploy your OVHcloud Load Balancer to apply the changes.

For further information on the rules managed and the format of parameters, please read the Available rules section further down.

View details on a rule

With this call instruction, you can view the details on a rule attached to an HTTP route if you know its ID.

For further information on the rules managed and the format of parameters, please read the Available rules section further down.

Modify a rule

With this call, you can modify a rule attached to an HTTP route if you know its ID. You will need to redeploy your OVHcloud Load Balancer to apply the changes.

For further information on the rules managed and the format of parameters, please read the Available rules section further down.

Delete a rule

With this call, you can delete a rule attached to an HTTP route if you know its ID. You will need to redeploy your OVHcloud Load Balancer to apply the changes.

List all of the TCP and HTTP routes

With this call, you can get a list of all the IDs, display names, and types ("http"/"tcp") of routes defined on an OVHcloud Load Balancer service. It is designed to simplify the implementation of auto-completion.

Available actions

This call returns the list of actions available for TCP and HTTP routes, as well as the values expected for each of the fields.

If a field is “null”, this means that no value is expected. If an invalid value is entered, the API will return a validation error.

All of the actions managed by the OVHcloud Load Balancer service are final. This means that executing an action also triggers the end of route evaluation.

Available rules

This call returns the list of rules available for TCP and HTTP routes, as well as the values expected for each of the fields.

If a field is “null”, this means that no value is expected. If an invalid value is entered, the API will return a validation error.

Go further

For more information and tutorials, please see our other OVHcloud Load Balancer guides or explore the guides for other OVHcloud products and services.