diff --git a/pages/network/load_balancer/create_faq/guide.en-asia.md b/pages/network/load_balancer/create_faq/guide.en-asia.md index 1a10812d5ed..af443228d6a 100644 --- a/pages/network/load_balancer/create_faq/guide.en-asia.md +++ b/pages/network/load_balancer/create_faq/guide.en-asia.md @@ -1,23 +1,40 @@ --- -title: 'Load Balancer FAQ' -excerpt: 'FAQ Load Balancer' -updated: 2018-03-26 +title: 'OVHcloud Load Balancer FAQ' +excerpt: 'Frequently Asked Questions on the OVHcloud Load Balancer' +updated: 2025-11-12 --- -## How do I configure my Firewall to accept traffic from the OVHcloud Load Balancer? -When using the Load Balancer, your clients do not connect directly to your servers. A good practice is to setup a firewall to allow only traffic from the OVHcloud Load Balancer service. +## Objective -- To determine which IPs to allow in your firewall, you can use the following API call: +This document provides a set of the most frequently asked questions and their corresponding OVHcloud API calls for performing common management and configuration tasks on your OVHcloud Load Balancer service. + +## FAQ + +### How do I configure my Firewall to accept traffic from the OVHcloud Load Balancer? + +When using the Load Balancer, your clients do not connect directly to your servers. A good practice is to set up a firewall to allow only traffic from the OVHcloud Load Balancer service. + +#### Via the OVHcloud API + +To determine which IP addresses you need to allow in your firewall, you can use the following API call: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/natIp > -## How do I know the status of my service? +#### Via the OVHcloud Control Panel + +In your Load Balancer service, navigate to the `Home`{.action} tab, and find the **Information** section. On the **Outbound IPv4** line, click the ellipsis, and select "Read". +A window will open, listing the IP addresses you need to allow in your firewall. + +### How do I know the status of my service? + Sometimes it may be useful to know the status of your OVHcloud Load Balancer. -- To determine the status of your service, you can use the following API call : +#### Via the OVHcloud API + +To determine the status of your service, you can use the following API call: > [!api] > @@ -26,45 +43,75 @@ Sometimes it may be useful to know the status of your OVHcloud Load Balancer. The different statuses of the OVHcloud Load Balancer can be `running`{.action} (Active), `reload`{.action} (Refresh in progress), `unknown`{.action} (Not yet started), or `dead`{.action} (inactive). -## How to add an Additional IP to the OVHcloud Load Balancer? -An Additional IP is an additional IP in which can be joined with your primary IP. The Additional IP can be switched from one server to another in seconds. +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, navigate to the `Home`{.action} tab, and find the **Status** section, which lists the internal service name of your Load Balancer and its status. + +### How to add an Additional IP to the OVHcloud Load Balancer? + +An Additional IP is an secondary IP address which can be associated to your service in addition to your primary IP. The Additional IP can be switched from one server to another in seconds. + +#### Via the OVHcloud API -- To add an Additional IP to an OVHcloud Load Balancer service : +- To add an Additional IP to an OVHcloud Load Balancer service: > [!api] > > @api {v1} /ip POST /ip/{ip}/move > -- Apply the change : +- Apply the change: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/refresh > -## How to list the Additional IPs routed to the OVHcloud Load Balancer? +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, click on `Front-ends`{.action}, then on `Add a front-end`{.action}. +Then, expand the `Advanced settings`{.action}, and select the Additional IPs you would like to add to your front-end *(listed on the interface as "Dedicated failover IP")*. + +### How to list the Additional IPs routed to the OVHcloud Load Balancer? > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/failover > -## How do I order a free SSL certificate ? -It is possible to order a free SSL ceritificate for the OVHcloud Load Balancer.. +### How do I order a free SSL certificate? + +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, navigate to the `SSL certificates`{.action} tab, and click on `Order an SSL certificate`{.action}. +Fill in the FQDN in the dedicated field, then click on `Order`{.action}. + +For the order to be completed, it is required that the domain name points to your OVHcloud Load Balancer. + +#### Via the OVHcloud API + +It is possible to order a free SSL certificate for the OVHcloud Load Balancer. -- To order a free SSL certificate, you can use the following API call and entering your domain in the `fqdn` field: +- To order a free SSL certificate, you can use the following API call and enter your domain in the ‘fqdn’ field: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/freeCertificate > -It is possible to order a multi-domain certificate; the `fqdn` fields accepts a sting type input. +It is possible to order a multi-domain certificate; the `fqdn` field accepts a string type input. -For the orer to be completed, it is required that the domain name points to your OVHcloud Load Balancer. +For the order to be completed, it is required that the domain name points to your OVHcloud Load Balancer. -## How to list the SSL certificates associated with the OVHcloud Load Balancer ? +### How to list the SSL certificates associated with the OVHcloud Load Balancer? + +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, navigate to the `SSL certificates`{.action} section, where you will find a table listing the certificates associated to that Load Balancer. + +To retrieve the details of an SSL certificate, click the ellipsis button to the right of the desired certificate, then click on `See a preview`{.action}. + +#### Via the OVHcloud API - To list the SSL certificates associated with the OVHcloud Load Balancer, you can use the following API call: @@ -73,14 +120,19 @@ For the orer to be completed, it is required that the domain name points to your > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl > -The SSL certificates that have been ordered (free or not) will appear as `built`. Those added by yourself are will appear as `custom`. +The SSL certificates that have been ordered (free or not) will appear as `built`. Those added by yourself will appear as `custom`. -An SSL certificate appearing as `built_not_routed` is a certificate that has been order and delivered, but whose domain cannot be validated. Usually, this is because the domain to longer points to the OVHcloud Load Balancer. +An SSL certificate appearing as `built_not_routed` is a certificate that has been ordered and delivered, but whose domain cannot be validated. Usually, this is because the domain no longer points to the OVHcloud Load Balancer. -- To retrieve the details of an SSL certificate, you can use the following API call : +- To retrieve the details of an SSL certificate, you can use the following API call: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl/{id} > +## Go further + +Find details about all the API calls related to the OVHcloud Load Balancer in [this guide](/pages/network/load_balancer/use_api_details). + +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_faq/guide.en-au.md b/pages/network/load_balancer/create_faq/guide.en-au.md index 1a10812d5ed..af443228d6a 100644 --- a/pages/network/load_balancer/create_faq/guide.en-au.md +++ b/pages/network/load_balancer/create_faq/guide.en-au.md @@ -1,23 +1,40 @@ --- -title: 'Load Balancer FAQ' -excerpt: 'FAQ Load Balancer' -updated: 2018-03-26 +title: 'OVHcloud Load Balancer FAQ' +excerpt: 'Frequently Asked Questions on the OVHcloud Load Balancer' +updated: 2025-11-12 --- -## How do I configure my Firewall to accept traffic from the OVHcloud Load Balancer? -When using the Load Balancer, your clients do not connect directly to your servers. A good practice is to setup a firewall to allow only traffic from the OVHcloud Load Balancer service. +## Objective -- To determine which IPs to allow in your firewall, you can use the following API call: +This document provides a set of the most frequently asked questions and their corresponding OVHcloud API calls for performing common management and configuration tasks on your OVHcloud Load Balancer service. + +## FAQ + +### How do I configure my Firewall to accept traffic from the OVHcloud Load Balancer? + +When using the Load Balancer, your clients do not connect directly to your servers. A good practice is to set up a firewall to allow only traffic from the OVHcloud Load Balancer service. + +#### Via the OVHcloud API + +To determine which IP addresses you need to allow in your firewall, you can use the following API call: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/natIp > -## How do I know the status of my service? +#### Via the OVHcloud Control Panel + +In your Load Balancer service, navigate to the `Home`{.action} tab, and find the **Information** section. On the **Outbound IPv4** line, click the ellipsis, and select "Read". +A window will open, listing the IP addresses you need to allow in your firewall. + +### How do I know the status of my service? + Sometimes it may be useful to know the status of your OVHcloud Load Balancer. -- To determine the status of your service, you can use the following API call : +#### Via the OVHcloud API + +To determine the status of your service, you can use the following API call: > [!api] > @@ -26,45 +43,75 @@ Sometimes it may be useful to know the status of your OVHcloud Load Balancer. The different statuses of the OVHcloud Load Balancer can be `running`{.action} (Active), `reload`{.action} (Refresh in progress), `unknown`{.action} (Not yet started), or `dead`{.action} (inactive). -## How to add an Additional IP to the OVHcloud Load Balancer? -An Additional IP is an additional IP in which can be joined with your primary IP. The Additional IP can be switched from one server to another in seconds. +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, navigate to the `Home`{.action} tab, and find the **Status** section, which lists the internal service name of your Load Balancer and its status. + +### How to add an Additional IP to the OVHcloud Load Balancer? + +An Additional IP is an secondary IP address which can be associated to your service in addition to your primary IP. The Additional IP can be switched from one server to another in seconds. + +#### Via the OVHcloud API -- To add an Additional IP to an OVHcloud Load Balancer service : +- To add an Additional IP to an OVHcloud Load Balancer service: > [!api] > > @api {v1} /ip POST /ip/{ip}/move > -- Apply the change : +- Apply the change: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/refresh > -## How to list the Additional IPs routed to the OVHcloud Load Balancer? +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, click on `Front-ends`{.action}, then on `Add a front-end`{.action}. +Then, expand the `Advanced settings`{.action}, and select the Additional IPs you would like to add to your front-end *(listed on the interface as "Dedicated failover IP")*. + +### How to list the Additional IPs routed to the OVHcloud Load Balancer? > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/failover > -## How do I order a free SSL certificate ? -It is possible to order a free SSL ceritificate for the OVHcloud Load Balancer.. +### How do I order a free SSL certificate? + +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, navigate to the `SSL certificates`{.action} tab, and click on `Order an SSL certificate`{.action}. +Fill in the FQDN in the dedicated field, then click on `Order`{.action}. + +For the order to be completed, it is required that the domain name points to your OVHcloud Load Balancer. + +#### Via the OVHcloud API + +It is possible to order a free SSL certificate for the OVHcloud Load Balancer. -- To order a free SSL certificate, you can use the following API call and entering your domain in the `fqdn` field: +- To order a free SSL certificate, you can use the following API call and enter your domain in the ‘fqdn’ field: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/freeCertificate > -It is possible to order a multi-domain certificate; the `fqdn` fields accepts a sting type input. +It is possible to order a multi-domain certificate; the `fqdn` field accepts a string type input. -For the orer to be completed, it is required that the domain name points to your OVHcloud Load Balancer. +For the order to be completed, it is required that the domain name points to your OVHcloud Load Balancer. -## How to list the SSL certificates associated with the OVHcloud Load Balancer ? +### How to list the SSL certificates associated with the OVHcloud Load Balancer? + +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, navigate to the `SSL certificates`{.action} section, where you will find a table listing the certificates associated to that Load Balancer. + +To retrieve the details of an SSL certificate, click the ellipsis button to the right of the desired certificate, then click on `See a preview`{.action}. + +#### Via the OVHcloud API - To list the SSL certificates associated with the OVHcloud Load Balancer, you can use the following API call: @@ -73,14 +120,19 @@ For the orer to be completed, it is required that the domain name points to your > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl > -The SSL certificates that have been ordered (free or not) will appear as `built`. Those added by yourself are will appear as `custom`. +The SSL certificates that have been ordered (free or not) will appear as `built`. Those added by yourself will appear as `custom`. -An SSL certificate appearing as `built_not_routed` is a certificate that has been order and delivered, but whose domain cannot be validated. Usually, this is because the domain to longer points to the OVHcloud Load Balancer. +An SSL certificate appearing as `built_not_routed` is a certificate that has been ordered and delivered, but whose domain cannot be validated. Usually, this is because the domain no longer points to the OVHcloud Load Balancer. -- To retrieve the details of an SSL certificate, you can use the following API call : +- To retrieve the details of an SSL certificate, you can use the following API call: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl/{id} > +## Go further + +Find details about all the API calls related to the OVHcloud Load Balancer in [this guide](/pages/network/load_balancer/use_api_details). + +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_faq/guide.en-ca.md b/pages/network/load_balancer/create_faq/guide.en-ca.md index 1a10812d5ed..af443228d6a 100644 --- a/pages/network/load_balancer/create_faq/guide.en-ca.md +++ b/pages/network/load_balancer/create_faq/guide.en-ca.md @@ -1,23 +1,40 @@ --- -title: 'Load Balancer FAQ' -excerpt: 'FAQ Load Balancer' -updated: 2018-03-26 +title: 'OVHcloud Load Balancer FAQ' +excerpt: 'Frequently Asked Questions on the OVHcloud Load Balancer' +updated: 2025-11-12 --- -## How do I configure my Firewall to accept traffic from the OVHcloud Load Balancer? -When using the Load Balancer, your clients do not connect directly to your servers. A good practice is to setup a firewall to allow only traffic from the OVHcloud Load Balancer service. +## Objective -- To determine which IPs to allow in your firewall, you can use the following API call: +This document provides a set of the most frequently asked questions and their corresponding OVHcloud API calls for performing common management and configuration tasks on your OVHcloud Load Balancer service. + +## FAQ + +### How do I configure my Firewall to accept traffic from the OVHcloud Load Balancer? + +When using the Load Balancer, your clients do not connect directly to your servers. A good practice is to set up a firewall to allow only traffic from the OVHcloud Load Balancer service. + +#### Via the OVHcloud API + +To determine which IP addresses you need to allow in your firewall, you can use the following API call: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/natIp > -## How do I know the status of my service? +#### Via the OVHcloud Control Panel + +In your Load Balancer service, navigate to the `Home`{.action} tab, and find the **Information** section. On the **Outbound IPv4** line, click the ellipsis, and select "Read". +A window will open, listing the IP addresses you need to allow in your firewall. + +### How do I know the status of my service? + Sometimes it may be useful to know the status of your OVHcloud Load Balancer. -- To determine the status of your service, you can use the following API call : +#### Via the OVHcloud API + +To determine the status of your service, you can use the following API call: > [!api] > @@ -26,45 +43,75 @@ Sometimes it may be useful to know the status of your OVHcloud Load Balancer. The different statuses of the OVHcloud Load Balancer can be `running`{.action} (Active), `reload`{.action} (Refresh in progress), `unknown`{.action} (Not yet started), or `dead`{.action} (inactive). -## How to add an Additional IP to the OVHcloud Load Balancer? -An Additional IP is an additional IP in which can be joined with your primary IP. The Additional IP can be switched from one server to another in seconds. +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, navigate to the `Home`{.action} tab, and find the **Status** section, which lists the internal service name of your Load Balancer and its status. + +### How to add an Additional IP to the OVHcloud Load Balancer? + +An Additional IP is an secondary IP address which can be associated to your service in addition to your primary IP. The Additional IP can be switched from one server to another in seconds. + +#### Via the OVHcloud API -- To add an Additional IP to an OVHcloud Load Balancer service : +- To add an Additional IP to an OVHcloud Load Balancer service: > [!api] > > @api {v1} /ip POST /ip/{ip}/move > -- Apply the change : +- Apply the change: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/refresh > -## How to list the Additional IPs routed to the OVHcloud Load Balancer? +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, click on `Front-ends`{.action}, then on `Add a front-end`{.action}. +Then, expand the `Advanced settings`{.action}, and select the Additional IPs you would like to add to your front-end *(listed on the interface as "Dedicated failover IP")*. + +### How to list the Additional IPs routed to the OVHcloud Load Balancer? > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/failover > -## How do I order a free SSL certificate ? -It is possible to order a free SSL ceritificate for the OVHcloud Load Balancer.. +### How do I order a free SSL certificate? + +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, navigate to the `SSL certificates`{.action} tab, and click on `Order an SSL certificate`{.action}. +Fill in the FQDN in the dedicated field, then click on `Order`{.action}. + +For the order to be completed, it is required that the domain name points to your OVHcloud Load Balancer. + +#### Via the OVHcloud API + +It is possible to order a free SSL certificate for the OVHcloud Load Balancer. -- To order a free SSL certificate, you can use the following API call and entering your domain in the `fqdn` field: +- To order a free SSL certificate, you can use the following API call and enter your domain in the ‘fqdn’ field: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/freeCertificate > -It is possible to order a multi-domain certificate; the `fqdn` fields accepts a sting type input. +It is possible to order a multi-domain certificate; the `fqdn` field accepts a string type input. -For the orer to be completed, it is required that the domain name points to your OVHcloud Load Balancer. +For the order to be completed, it is required that the domain name points to your OVHcloud Load Balancer. -## How to list the SSL certificates associated with the OVHcloud Load Balancer ? +### How to list the SSL certificates associated with the OVHcloud Load Balancer? + +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, navigate to the `SSL certificates`{.action} section, where you will find a table listing the certificates associated to that Load Balancer. + +To retrieve the details of an SSL certificate, click the ellipsis button to the right of the desired certificate, then click on `See a preview`{.action}. + +#### Via the OVHcloud API - To list the SSL certificates associated with the OVHcloud Load Balancer, you can use the following API call: @@ -73,14 +120,19 @@ For the orer to be completed, it is required that the domain name points to your > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl > -The SSL certificates that have been ordered (free or not) will appear as `built`. Those added by yourself are will appear as `custom`. +The SSL certificates that have been ordered (free or not) will appear as `built`. Those added by yourself will appear as `custom`. -An SSL certificate appearing as `built_not_routed` is a certificate that has been order and delivered, but whose domain cannot be validated. Usually, this is because the domain to longer points to the OVHcloud Load Balancer. +An SSL certificate appearing as `built_not_routed` is a certificate that has been ordered and delivered, but whose domain cannot be validated. Usually, this is because the domain no longer points to the OVHcloud Load Balancer. -- To retrieve the details of an SSL certificate, you can use the following API call : +- To retrieve the details of an SSL certificate, you can use the following API call: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl/{id} > +## Go further + +Find details about all the API calls related to the OVHcloud Load Balancer in [this guide](/pages/network/load_balancer/use_api_details). + +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_faq/guide.en-gb.md b/pages/network/load_balancer/create_faq/guide.en-gb.md index 1a10812d5ed..af443228d6a 100644 --- a/pages/network/load_balancer/create_faq/guide.en-gb.md +++ b/pages/network/load_balancer/create_faq/guide.en-gb.md @@ -1,23 +1,40 @@ --- -title: 'Load Balancer FAQ' -excerpt: 'FAQ Load Balancer' -updated: 2018-03-26 +title: 'OVHcloud Load Balancer FAQ' +excerpt: 'Frequently Asked Questions on the OVHcloud Load Balancer' +updated: 2025-11-12 --- -## How do I configure my Firewall to accept traffic from the OVHcloud Load Balancer? -When using the Load Balancer, your clients do not connect directly to your servers. A good practice is to setup a firewall to allow only traffic from the OVHcloud Load Balancer service. +## Objective -- To determine which IPs to allow in your firewall, you can use the following API call: +This document provides a set of the most frequently asked questions and their corresponding OVHcloud API calls for performing common management and configuration tasks on your OVHcloud Load Balancer service. + +## FAQ + +### How do I configure my Firewall to accept traffic from the OVHcloud Load Balancer? + +When using the Load Balancer, your clients do not connect directly to your servers. A good practice is to set up a firewall to allow only traffic from the OVHcloud Load Balancer service. + +#### Via the OVHcloud API + +To determine which IP addresses you need to allow in your firewall, you can use the following API call: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/natIp > -## How do I know the status of my service? +#### Via the OVHcloud Control Panel + +In your Load Balancer service, navigate to the `Home`{.action} tab, and find the **Information** section. On the **Outbound IPv4** line, click the ellipsis, and select "Read". +A window will open, listing the IP addresses you need to allow in your firewall. + +### How do I know the status of my service? + Sometimes it may be useful to know the status of your OVHcloud Load Balancer. -- To determine the status of your service, you can use the following API call : +#### Via the OVHcloud API + +To determine the status of your service, you can use the following API call: > [!api] > @@ -26,45 +43,75 @@ Sometimes it may be useful to know the status of your OVHcloud Load Balancer. The different statuses of the OVHcloud Load Balancer can be `running`{.action} (Active), `reload`{.action} (Refresh in progress), `unknown`{.action} (Not yet started), or `dead`{.action} (inactive). -## How to add an Additional IP to the OVHcloud Load Balancer? -An Additional IP is an additional IP in which can be joined with your primary IP. The Additional IP can be switched from one server to another in seconds. +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, navigate to the `Home`{.action} tab, and find the **Status** section, which lists the internal service name of your Load Balancer and its status. + +### How to add an Additional IP to the OVHcloud Load Balancer? + +An Additional IP is an secondary IP address which can be associated to your service in addition to your primary IP. The Additional IP can be switched from one server to another in seconds. + +#### Via the OVHcloud API -- To add an Additional IP to an OVHcloud Load Balancer service : +- To add an Additional IP to an OVHcloud Load Balancer service: > [!api] > > @api {v1} /ip POST /ip/{ip}/move > -- Apply the change : +- Apply the change: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/refresh > -## How to list the Additional IPs routed to the OVHcloud Load Balancer? +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, click on `Front-ends`{.action}, then on `Add a front-end`{.action}. +Then, expand the `Advanced settings`{.action}, and select the Additional IPs you would like to add to your front-end *(listed on the interface as "Dedicated failover IP")*. + +### How to list the Additional IPs routed to the OVHcloud Load Balancer? > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/failover > -## How do I order a free SSL certificate ? -It is possible to order a free SSL ceritificate for the OVHcloud Load Balancer.. +### How do I order a free SSL certificate? + +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, navigate to the `SSL certificates`{.action} tab, and click on `Order an SSL certificate`{.action}. +Fill in the FQDN in the dedicated field, then click on `Order`{.action}. + +For the order to be completed, it is required that the domain name points to your OVHcloud Load Balancer. + +#### Via the OVHcloud API + +It is possible to order a free SSL certificate for the OVHcloud Load Balancer. -- To order a free SSL certificate, you can use the following API call and entering your domain in the `fqdn` field: +- To order a free SSL certificate, you can use the following API call and enter your domain in the ‘fqdn’ field: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/freeCertificate > -It is possible to order a multi-domain certificate; the `fqdn` fields accepts a sting type input. +It is possible to order a multi-domain certificate; the `fqdn` field accepts a string type input. -For the orer to be completed, it is required that the domain name points to your OVHcloud Load Balancer. +For the order to be completed, it is required that the domain name points to your OVHcloud Load Balancer. -## How to list the SSL certificates associated with the OVHcloud Load Balancer ? +### How to list the SSL certificates associated with the OVHcloud Load Balancer? + +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, navigate to the `SSL certificates`{.action} section, where you will find a table listing the certificates associated to that Load Balancer. + +To retrieve the details of an SSL certificate, click the ellipsis button to the right of the desired certificate, then click on `See a preview`{.action}. + +#### Via the OVHcloud API - To list the SSL certificates associated with the OVHcloud Load Balancer, you can use the following API call: @@ -73,14 +120,19 @@ For the orer to be completed, it is required that the domain name points to your > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl > -The SSL certificates that have been ordered (free or not) will appear as `built`. Those added by yourself are will appear as `custom`. +The SSL certificates that have been ordered (free or not) will appear as `built`. Those added by yourself will appear as `custom`. -An SSL certificate appearing as `built_not_routed` is a certificate that has been order and delivered, but whose domain cannot be validated. Usually, this is because the domain to longer points to the OVHcloud Load Balancer. +An SSL certificate appearing as `built_not_routed` is a certificate that has been ordered and delivered, but whose domain cannot be validated. Usually, this is because the domain no longer points to the OVHcloud Load Balancer. -- To retrieve the details of an SSL certificate, you can use the following API call : +- To retrieve the details of an SSL certificate, you can use the following API call: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl/{id} > +## Go further + +Find details about all the API calls related to the OVHcloud Load Balancer in [this guide](/pages/network/load_balancer/use_api_details). + +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_faq/guide.en-sg.md b/pages/network/load_balancer/create_faq/guide.en-sg.md index 1a10812d5ed..af443228d6a 100644 --- a/pages/network/load_balancer/create_faq/guide.en-sg.md +++ b/pages/network/load_balancer/create_faq/guide.en-sg.md @@ -1,23 +1,40 @@ --- -title: 'Load Balancer FAQ' -excerpt: 'FAQ Load Balancer' -updated: 2018-03-26 +title: 'OVHcloud Load Balancer FAQ' +excerpt: 'Frequently Asked Questions on the OVHcloud Load Balancer' +updated: 2025-11-12 --- -## How do I configure my Firewall to accept traffic from the OVHcloud Load Balancer? -When using the Load Balancer, your clients do not connect directly to your servers. A good practice is to setup a firewall to allow only traffic from the OVHcloud Load Balancer service. +## Objective -- To determine which IPs to allow in your firewall, you can use the following API call: +This document provides a set of the most frequently asked questions and their corresponding OVHcloud API calls for performing common management and configuration tasks on your OVHcloud Load Balancer service. + +## FAQ + +### How do I configure my Firewall to accept traffic from the OVHcloud Load Balancer? + +When using the Load Balancer, your clients do not connect directly to your servers. A good practice is to set up a firewall to allow only traffic from the OVHcloud Load Balancer service. + +#### Via the OVHcloud API + +To determine which IP addresses you need to allow in your firewall, you can use the following API call: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/natIp > -## How do I know the status of my service? +#### Via the OVHcloud Control Panel + +In your Load Balancer service, navigate to the `Home`{.action} tab, and find the **Information** section. On the **Outbound IPv4** line, click the ellipsis, and select "Read". +A window will open, listing the IP addresses you need to allow in your firewall. + +### How do I know the status of my service? + Sometimes it may be useful to know the status of your OVHcloud Load Balancer. -- To determine the status of your service, you can use the following API call : +#### Via the OVHcloud API + +To determine the status of your service, you can use the following API call: > [!api] > @@ -26,45 +43,75 @@ Sometimes it may be useful to know the status of your OVHcloud Load Balancer. The different statuses of the OVHcloud Load Balancer can be `running`{.action} (Active), `reload`{.action} (Refresh in progress), `unknown`{.action} (Not yet started), or `dead`{.action} (inactive). -## How to add an Additional IP to the OVHcloud Load Balancer? -An Additional IP is an additional IP in which can be joined with your primary IP. The Additional IP can be switched from one server to another in seconds. +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, navigate to the `Home`{.action} tab, and find the **Status** section, which lists the internal service name of your Load Balancer and its status. + +### How to add an Additional IP to the OVHcloud Load Balancer? + +An Additional IP is an secondary IP address which can be associated to your service in addition to your primary IP. The Additional IP can be switched from one server to another in seconds. + +#### Via the OVHcloud API -- To add an Additional IP to an OVHcloud Load Balancer service : +- To add an Additional IP to an OVHcloud Load Balancer service: > [!api] > > @api {v1} /ip POST /ip/{ip}/move > -- Apply the change : +- Apply the change: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/refresh > -## How to list the Additional IPs routed to the OVHcloud Load Balancer? +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, click on `Front-ends`{.action}, then on `Add a front-end`{.action}. +Then, expand the `Advanced settings`{.action}, and select the Additional IPs you would like to add to your front-end *(listed on the interface as "Dedicated failover IP")*. + +### How to list the Additional IPs routed to the OVHcloud Load Balancer? > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/failover > -## How do I order a free SSL certificate ? -It is possible to order a free SSL ceritificate for the OVHcloud Load Balancer.. +### How do I order a free SSL certificate? + +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, navigate to the `SSL certificates`{.action} tab, and click on `Order an SSL certificate`{.action}. +Fill in the FQDN in the dedicated field, then click on `Order`{.action}. + +For the order to be completed, it is required that the domain name points to your OVHcloud Load Balancer. + +#### Via the OVHcloud API + +It is possible to order a free SSL certificate for the OVHcloud Load Balancer. -- To order a free SSL certificate, you can use the following API call and entering your domain in the `fqdn` field: +- To order a free SSL certificate, you can use the following API call and enter your domain in the ‘fqdn’ field: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/freeCertificate > -It is possible to order a multi-domain certificate; the `fqdn` fields accepts a sting type input. +It is possible to order a multi-domain certificate; the `fqdn` field accepts a string type input. -For the orer to be completed, it is required that the domain name points to your OVHcloud Load Balancer. +For the order to be completed, it is required that the domain name points to your OVHcloud Load Balancer. -## How to list the SSL certificates associated with the OVHcloud Load Balancer ? +### How to list the SSL certificates associated with the OVHcloud Load Balancer? + +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, navigate to the `SSL certificates`{.action} section, where you will find a table listing the certificates associated to that Load Balancer. + +To retrieve the details of an SSL certificate, click the ellipsis button to the right of the desired certificate, then click on `See a preview`{.action}. + +#### Via the OVHcloud API - To list the SSL certificates associated with the OVHcloud Load Balancer, you can use the following API call: @@ -73,14 +120,19 @@ For the orer to be completed, it is required that the domain name points to your > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl > -The SSL certificates that have been ordered (free or not) will appear as `built`. Those added by yourself are will appear as `custom`. +The SSL certificates that have been ordered (free or not) will appear as `built`. Those added by yourself will appear as `custom`. -An SSL certificate appearing as `built_not_routed` is a certificate that has been order and delivered, but whose domain cannot be validated. Usually, this is because the domain to longer points to the OVHcloud Load Balancer. +An SSL certificate appearing as `built_not_routed` is a certificate that has been ordered and delivered, but whose domain cannot be validated. Usually, this is because the domain no longer points to the OVHcloud Load Balancer. -- To retrieve the details of an SSL certificate, you can use the following API call : +- To retrieve the details of an SSL certificate, you can use the following API call: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl/{id} > +## Go further + +Find details about all the API calls related to the OVHcloud Load Balancer in [this guide](/pages/network/load_balancer/use_api_details). + +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_faq/guide.en-us.md b/pages/network/load_balancer/create_faq/guide.en-us.md index d0644c748ba..af443228d6a 100644 --- a/pages/network/load_balancer/create_faq/guide.en-us.md +++ b/pages/network/load_balancer/create_faq/guide.en-us.md @@ -1,25 +1,40 @@ --- -title: 'Load Balancer FAQ' -excerpt: 'FAQ Load Balancer' -updated: 2018-03-26 +title: 'OVHcloud Load Balancer FAQ' +excerpt: 'Frequently Asked Questions on the OVHcloud Load Balancer' +updated: 2025-11-12 --- -## How do I configure my Firewall to accept traffic from the OVHcloud Load Balancer? +## Objective -When using the Load Balancer, your clients do not connect directly to your servers. A good practice is to setup a firewall to allow only traffic from the OVHcloud Load Balancer service. +This document provides a set of the most frequently asked questions and their corresponding OVHcloud API calls for performing common management and configuration tasks on your OVHcloud Load Balancer service. -- To determine which IPs to allow in your firewall, you can use the following API call: +## FAQ + +### How do I configure my Firewall to accept traffic from the OVHcloud Load Balancer? + +When using the Load Balancer, your clients do not connect directly to your servers. A good practice is to set up a firewall to allow only traffic from the OVHcloud Load Balancer service. + +#### Via the OVHcloud API + +To determine which IP addresses you need to allow in your firewall, you can use the following API call: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/natIp > -## How do I know the status of my service? +#### Via the OVHcloud Control Panel + +In your Load Balancer service, navigate to the `Home`{.action} tab, and find the **Information** section. On the **Outbound IPv4** line, click the ellipsis, and select "Read". +A window will open, listing the IP addresses you need to allow in your firewall. + +### How do I know the status of my service? Sometimes it may be useful to know the status of your OVHcloud Load Balancer. -- To determine the status of your service, you can use the following API call : +#### Via the OVHcloud API + +To determine the status of your service, you can use the following API call: > [!api] > @@ -28,47 +43,75 @@ Sometimes it may be useful to know the status of your OVHcloud Load Balancer. The different statuses of the OVHcloud Load Balancer can be `running`{.action} (Active), `reload`{.action} (Refresh in progress), `unknown`{.action} (Not yet started), or `dead`{.action} (inactive). -## How to add an Additional IP to the OVHcloud Load Balancer? +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, navigate to the `Home`{.action} tab, and find the **Status** section, which lists the internal service name of your Load Balancer and its status. + +### How to add an Additional IP to the OVHcloud Load Balancer? -An Additional IP is an additional IP in which can be joined with your primary IP. The Additional IP can be switched from one server to another in seconds. +An Additional IP is an secondary IP address which can be associated to your service in addition to your primary IP. The Additional IP can be switched from one server to another in seconds. -- To add an Additional IP to an OVHcloud Load Balancer service : +#### Via the OVHcloud API + +- To add an Additional IP to an OVHcloud Load Balancer service: > [!api] > > @api {v1} /ip POST /ip/{ip}/move > -- Apply the change : +- Apply the change: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/refresh > -## How to list the Additional IPs routed to the OVHcloud Load Balancer? +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, click on `Front-ends`{.action}, then on `Add a front-end`{.action}. +Then, expand the `Advanced settings`{.action}, and select the Additional IPs you would like to add to your front-end *(listed on the interface as "Dedicated failover IP")*. + +### How to list the Additional IPs routed to the OVHcloud Load Balancer? > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/failover > -## How do I order a free SSL certificate ? +### How do I order a free SSL certificate? + +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, navigate to the `SSL certificates`{.action} tab, and click on `Order an SSL certificate`{.action}. +Fill in the FQDN in the dedicated field, then click on `Order`{.action}. + +For the order to be completed, it is required that the domain name points to your OVHcloud Load Balancer. + +#### Via the OVHcloud API -It is possible to order a free SSL ceritificate for the OVHcloud Load Balancer.. +It is possible to order a free SSL certificate for the OVHcloud Load Balancer. -- To order a free SSL certificate, you can use the following API call and entering your domain in the `fqdn` field: +- To order a free SSL certificate, you can use the following API call and enter your domain in the ‘fqdn’ field: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/freeCertificate > -It is possible to order a multi-domain certificate; the `fqdn` fields accepts a sting type input. +It is possible to order a multi-domain certificate; the `fqdn` field accepts a string type input. -For the orer to be completed, it is required that the domain name points to your OVHcloud Load Balancer. +For the order to be completed, it is required that the domain name points to your OVHcloud Load Balancer. -## How to list the SSL certificates associated with the OVHcloud Load Balancer ? +### How to list the SSL certificates associated with the OVHcloud Load Balancer? + +#### Via the OVHcloud Control Panel + +In your Load Balancer service dashboard, navigate to the `SSL certificates`{.action} section, where you will find a table listing the certificates associated to that Load Balancer. + +To retrieve the details of an SSL certificate, click the ellipsis button to the right of the desired certificate, then click on `See a preview`{.action}. + +#### Via the OVHcloud API - To list the SSL certificates associated with the OVHcloud Load Balancer, you can use the following API call: @@ -77,11 +120,11 @@ For the orer to be completed, it is required that the domain name points to your > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl > -The SSL certificates that have been ordered (free or not) will appear as `built`. Those added by yourself are will appear as `custom`. +The SSL certificates that have been ordered (free or not) will appear as `built`. Those added by yourself will appear as `custom`. -An SSL certificate appearing as `built_not_routed` is a certificate that has been order and delivered, but whose domain cannot be validated. Usually, this is because the domain to longer points to the OVHcloud Load Balancer. +An SSL certificate appearing as `built_not_routed` is a certificate that has been ordered and delivered, but whose domain cannot be validated. Usually, this is because the domain no longer points to the OVHcloud Load Balancer. -- To retrieve the details of an SSL certificate, you can use the following API call : +- To retrieve the details of an SSL certificate, you can use the following API call: > [!api] > @@ -90,4 +133,6 @@ An SSL certificate appearing as `built_not_routed` is a certificate that has bee ## Go further +Find details about all the API calls related to the OVHcloud Load Balancer in [this guide](/pages/network/load_balancer/use_api_details). + Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_faq/guide.fr-ca.md b/pages/network/load_balancer/create_faq/guide.fr-ca.md index fbe1ac84f2e..425c64479bb 100644 --- a/pages/network/load_balancer/create_faq/guide.fr-ca.md +++ b/pages/network/load_balancer/create_faq/guide.fr-ca.md @@ -1,86 +1,147 @@ --- -title: 'Load Balancer FAQ' -excerpt: 'FAQ Load Balancer' -updated: 2022-09-30 +title: 'OVHcloud Load Balancer FAQ' +excerpt: 'Questions fréquentes concernant le service OVHcloud Load Balancer' +updated: 2025-11-12 --- -## Comment configurer mon Firewall pour accepter le trafic provenant du service Load Balancer OVHcloud ? -Lors de l'utilisation du Load-Balancer, vos clients ne se connectent pas directement à vos serveurs. Une bonne pratique est de mettre en place un Firewall (Pare-Feu) pour autoriser uniquement le trafic provenant du service Load Balancer OVHcloud. +## Objectif -- Pour déterminer les IPs à autoriser dans votre Firewall, vous pouvez utiliser la fonction API suivante : +Retrouvez dans ce document les questions les plus fréquemment posées et les instructions correspondantes pour effectuer des tâches de gestion et de configuration courantes sur votre service OVHcloud Load Balancer. + +## FAQ + +### Comment configurer mon pare-feu pour accepter le trafic provenant de l'OVHcloud Load Balancer ? + +Lorsque vous utilisez le Load Balancer, vos clients ne se connectent pas directement à vos serveurs. Il est recommandé de configurer un pare-feu permettant uniquement le trafic provenant du service OVHcloud Load Balancer. + +#### Via l'API OVHcloud + +Pour identifier les adresses IP que vous devez autoriser dans votre pare-feu, vous pouvez utiliser l'appel API suivant : > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/natIp > -## Comment connaître l'état de mon service ? -Parfois, il peut être utile de connaître l'état de votre service Load Balancer OVHcloud. +#### Via l'espace client OVHcloud + +Dans le tableau de bord de votre service Load Balancer, accédez à l'onglet `Accueil`{.action}. Dans le cadre **Informations**, cliquez sur le bouton `...`{.action} à droite de la mention **IPv4 de sortie** et sélectionnez `Consulter`{.action}. + +Une fenêtre s'ouvrira, listant les adresses IP que vous devez autoriser dans votre pare-feu. + +### Comment connaître le statut de mon service ? -- Pour déterminer l'état de votre service, vous pouvez utiliser la fonction API suivante : +Parfois, il peut être utile de connaître le statut de votre service OVHcloud Load Balancer. + +#### Via l'API OVHcloud + +Pour déterminer le statut de votre service, vous pouvez utiliser l'appel API suivant : > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/instancesState > -L'état des différentes instances du Load Balancer OVHcloud peut être `running` (actif), `reload` (en cours de rafraîchissement), `unknown` (pas encore démarré) ou `dead` (inactif). +Les différents statuts de l'OVHcloud Load Balancer peuvent être : + +- `running` : Actif. +- `reload` : Mise à jour en cours. +- `unknown` : Non encore démarré. +- `dead` : Inactif. + +#### Via l'espace client OVHcloud + +Dans le tableau de bord de votre service Load Balancer, accédez à l'onglet `Accueil`{.action}. Retrouvez dans le cadre **Statut** le nom interne de votre service Load Balancer ainsi que son statut. + +### Comment ajouter une Additional IP à l'OVHcloud Load Balancer ? + +Une Additional IP est une adresse IP secondaire qui peut être associée à votre service en plus de votre adresse IP principale. L'Additional IP peut être transférée d'un serveur à un autre en quelques secondes. -## Comment ajouter une Additional IP au service Load Balancer OVHcloud ? -L'Additional IP est une IP supplémentaire sur laquelle peut être joint votre service en plus de l'IP principale. L'Additional IP peut être basculée d'un service à un autre en quelques secondes. +#### Via l'API OVHcloud -- Pour ajouter une Additional IP à un service Load Balancer OVHcloud : +Pour ajouter une Additional IP à votre service OVHcloud Load Balancer : > [!api] > > @api {v1} /ip POST /ip/{ip}/move > -- Appliquer les modifications : +Appliquez le changement : > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/refresh > -## Comment lister les Additional IP rattachées au service Load Balancer OVHcloud ? +#### Via l'espace client OVHcloud + +Dans le tableau de bord de votre service Load Balancer, accédez à l'onglet `Frontends`{.action} et cliquez sur le bouton `Ajouter un frontend`{.action}. + +Ensuite, affichez les `Paramètres avancés`{.action} et sélectionnez les Additional IPs (listées sur l'interface comme « Dedicated IP failover ») que vous souhaitez ajouter à votre frontend. + +### Comment lister les Additional IPs routées vers le service OVHcloud Load Balancer ? + +Utilisez l'appel API suivant : > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/failover > -## Comment commander un certificat SSL gratuit ? -Il est possible de commander un certificat SSL gratuit pour le Load Balancer OVHcloud. +### Comment commander un certificat SSL gratuit ? + +#### Via l'espace client OVHcloud + +Dans le tableau de bord de votre service Load Balancer, accédez à l'onglet `Certificats SSL`{.action} et cliquez sur le bouton `Commander un certificat SSL`{.action}. +Remplissez le FQDN dans le champ dédié, puis cliquez sur `Commander`{.action}. + +Pour que la commande soit validée, il est nécessaire que le nom de domaine pointe vers votre service OVHcloud Load Balancer. + +#### Via l'API OVHcloud -- Pour commander un certificat gratuit, vous pouvez utiliser la fonction API suivante, en renseignant le champs `fqdn` : +Il est possible de commander un certificat SSL gratuit pour le service OVHcloud Load Balancer. + +Pour ce faire, vous pouvez utiliser l'appel API suivant et renseigner votre domaine dans le champ `fqdn` : > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/freeCertificate > -Il est possible de commander un certificat multi-domaine ; le champs `fqdn` prend comme paramètre un tableau de chaîne de caractères. +Il est possible de commander un certificat multi-domaines ; le champ `fqdn` accepte une entrée de type chaîne de caractères. + +Pour que la commande soit validée, il est nécessaire que le nom de domaine pointe vers votre service OVHcloud Load Balancer. + +### Comment lister les certificats SSL associés à l'OVHcloud Load Balancer ? + +#### Via l'espace client OVHcloud -Pour que la commande se finalise, il faut obligatoirement que le nom de domaine choisi pointe vers votre Load Balancer OVHcloud. +Dans le tableau de bord de votre service Load Balancer, accédez à l'onglet `Certificats SSL`{.action}, où vous trouverez un tableau listant les certificats associés à ce Load Balancer. -## Comment lister les certificats SSL associés au Load Balancer OVHcloud ? +Pour obtenir les détails d'un certificat SSL, cliquez sur le bouton `...`{.action} à droite du certificat souhaité, puis sélectionnez `Voir un aperçu`{.action}. -- Pour lister les certificats SSL associés au Load Balancer OVHcloud, vous pouvez utiliser la fonction API suivante : +#### Via l'API OVHcloud + +Pour lister les certificats SSL associés à l'OVHcloud Load Balancer, vous pouvez utiliser l'appel API suivant : > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl > -Les certificats commandés (gratuit ou non) sont de type `built`. Ceux ajoutés par vous-même sont de type `custom`. +Les certificats SSL commandés (gratuits ou non) apparaîtront comme `built`. Ceux ajoutés par vous-même apparaîtront comme `custom`. -Un certificat de type `built_not_routed` est un certificat qui a été commandé et livré, mais dont le domaine n'a pas put être validé. Usuellement, c'est parce que le domaine ne pointe plus vers le Load Balancer OVHcloud. +Un certificat SSL apparaissant comme `built_not_routed` est un certificat qui a été commandé et livré, mais dont le domaine ne peut pas être validé. Cela est généralement dû au fait que le domaine ne pointe plus vers le service OVHcloud Load Balancer. -- Pour obtenir les détails d'un certificat SSL, vous pouvez utiliser la fonction API suivante : +Pour obtenir les détails d'un certificat SSL, vous pouvez utiliser l'appel API suivant : > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl/{id} > +## Aller plus loin + +Trouvez les détails de tous les appels API liés à l'OVHcloud Load Balancer dans [ce guide](/pages/network/load_balancer/use_api_details). + +Rejoignez notre [communauté d'utilisateurs](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_faq/guide.fr-fr.md b/pages/network/load_balancer/create_faq/guide.fr-fr.md index b68bf71d1d1..34221a92ed7 100644 --- a/pages/network/load_balancer/create_faq/guide.fr-fr.md +++ b/pages/network/load_balancer/create_faq/guide.fr-fr.md @@ -1,52 +1,85 @@ --- -title: 'Load Balancer FAQ' -excerpt: 'FAQ Load Balancer' -updated: 2018-03-26 +title: 'OVHcloud Load Balancer FAQ' +excerpt: 'Questions fréquentes concernant le service OVHcloud Load Balancer' +updated: 2025-11-12 --- -## Comment configurer mon Firewall pour accepter le trafic provenant du service Load Balancer OVHcloud ? +## Objectif -Lors de l'utilisation du Load-Balancer, vos clients ne se connectent pas directement à vos serveurs. Une bonne pratique est de mettre en place un Firewall (Pare-Feu) pour autoriser uniquement le trafic provenant du service Load Balancer OVHcloud. +Retrouvez dans ce document les questions les plus fréquemment posées et les instructions correspondantes pour effectuer des tâches de gestion et de configuration courantes sur votre service OVHcloud Load Balancer. -- Pour déterminer les IPs à autoriser dans votre Firewall, vous pouvez utiliser la fonction API suivante : +## FAQ + +### Comment configurer mon pare-feu pour accepter le trafic provenant de l'OVHcloud Load Balancer ? + +Lorsque vous utilisez le Load Balancer, vos clients ne se connectent pas directement à vos serveurs. Il est recommandé de configurer un pare-feu permettant uniquement le trafic provenant du service OVHcloud Load Balancer. + +#### Via l'API OVHcloud + +Pour identifier les adresses IP que vous devez autoriser dans votre pare-feu, vous pouvez utiliser l'appel API suivant : > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/natIp > -## Comment connaître l'état de mon service ? +#### Via l'espace client OVHcloud + +Dans le tableau de bord de votre service Load Balancer, accédez à l'onglet `Accueil`{.action}. Dans le cadre **Informations**, cliquez sur le bouton `...`{.action} à droite de la mention **IPv4 de sortie** et sélectionnez `Consulter`{.action}. + +Une fenêtre s'ouvrira, listant les adresses IP que vous devez autoriser dans votre pare-feu. -Parfois, il peut être utile de connaître l'état de votre service Load Balancer OVHcloud. +### Comment connaître le statut de mon service ? -- Pour déterminer l'état de votre service, vous pouvez utiliser la fonction API suivante : +Parfois, il peut être utile de connaître le statut de votre service OVHcloud Load Balancer. + +#### Via l'API OVHcloud + +Pour déterminer le statut de votre service, vous pouvez utiliser l'appel API suivant : > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/instancesState > -L'état des différentes instances du Load Balancer OVHcloud peut être `running` (actif), `reload` (en cours de rafraîchissement), `unknown` (pas encore démarré) ou `dead` (inactif). +Les différents statuts de l'OVHcloud Load Balancer peuvent être : + +- `running` : Actif. +- `reload` : Mise à jour en cours. +- `unknown` : Non encore démarré. +- `dead` : Inactif. + +#### Via l'espace client OVHcloud + +Dans le tableau de bord de votre service Load Balancer, accédez à l'onglet `Accueil`{.action}. Retrouvez dans le cadre **Statut** le nom interne de votre service Load Balancer ainsi que son statut. + +### Comment ajouter une Additional IP à l'OVHcloud Load Balancer ? -## Comment ajouter une Additional IP au service Load Balancer OVHcloud ? +Une Additional IP est une adresse IP secondaire qui peut être associée à votre service en plus de votre adresse IP principale. L'Additional IP peut être transférée d'un serveur à un autre en quelques secondes. -L'Additional IP est une IP supplémentaire sur laquelle peut être joint votre service en plus de l'IP principale. L'Additional IP peut être basculée d'un service à un autre en quelques secondes. +#### Via l'API OVHcloud -- Pour ajouter une Additional IP à un service Load Balancer OVHcloud : +Pour ajouter une Additional IP à votre service OVHcloud Load Balancer : > [!api] > > @api {v1} /ip POST /ip/{ip}/move > -- Appliquer les modifications : +Appliquez le changement : > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/refresh > -## Comment lister les Additional IP rattachées au service Load Balancer OVHcloud ? +#### Via l'espace client OVHcloud + +Dans le tableau de bord de votre service Load Balancer, accédez à l'onglet `Frontends`{.action} et cliquez sur le bouton `Ajouter un frontend`{.action}. + +Ensuite, affichez les `Paramètres avancés`{.action} et sélectionnez les Additional IPs (listées sur l'interface comme « Dedicated IP failover ») que vous souhaitez ajouter à votre frontend. + +### Comment lister les Additional IPs routées vers le service OVHcloud Load Balancer ? Utilisez l'appel API suivant : @@ -55,35 +88,52 @@ Utilisez l'appel API suivant : > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/failover > -## Comment commander un certificat SSL gratuit ? +### Comment commander un certificat SSL gratuit ? + +#### Via l'espace client OVHcloud + +Dans le tableau de bord de votre service Load Balancer, accédez à l'onglet `Certificats SSL`{.action} et cliquez sur le bouton `Commander un certificat SSL`{.action}. +Remplissez le FQDN dans le champ dédié, puis cliquez sur `Commander`{.action}. + +Pour que la commande soit validée, il est nécessaire que le nom de domaine pointe vers votre service OVHcloud Load Balancer. -Il est possible de commander un certificat SSL gratuit pour le Load Balancer OVHcloud. +#### Via l'API OVHcloud -- Pour commander un certificat gratuit, vous pouvez utiliser la fonction API suivante, en renseignant le champ `fqdn` : +Il est possible de commander un certificat SSL gratuit pour le service OVHcloud Load Balancer. + +Pour ce faire, vous pouvez utiliser l'appel API suivant et renseigner votre domaine dans le champ `fqdn` : > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/freeCertificate > -Il est possible de commander un certificat multi-domaine ; le champ `fqdn` prend comme paramètre un tableau de chaîne de caractères. +Il est possible de commander un certificat multi-domaines ; le champ `fqdn` accepte une entrée de type chaîne de caractères. + +Pour que la commande soit validée, il est nécessaire que le nom de domaine pointe vers votre service OVHcloud Load Balancer. + +### Comment lister les certificats SSL associés à l'OVHcloud Load Balancer ? -Pour que la commande se finalise, il faut obligatoirement que le nom de domaine choisi pointe vers votre Load Balancer OVHcloud. +#### Via l'espace client OVHcloud -## Comment lister les certificats SSL associés au Load Balancer OVHcloud ? +Dans le tableau de bord de votre service Load Balancer, accédez à l'onglet `Certificats SSL`{.action}, où vous trouverez un tableau listant les certificats associés à ce Load Balancer. -- Pour lister les certificats SSL associés au Load Balancer OVHcloud, vous pouvez utiliser la fonction API suivante : +Pour obtenir les détails d'un certificat SSL, cliquez sur le bouton `...`{.action} à droite du certificat souhaité, puis sélectionnez `Voir un aperçu`{.action}. + +#### Via l'API OVHcloud + +Pour lister les certificats SSL associés à l'OVHcloud Load Balancer, vous pouvez utiliser l'appel API suivant : > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl > -Les certificats commandés (gratuit ou non) sont de type `built`. Ceux ajoutés par vous-même sont de type `custom`. +Les certificats SSL commandés (gratuits ou non) apparaîtront comme `built`. Ceux ajoutés par vous-même apparaîtront comme `custom`. -Un certificat de type `built_not_routed` est un certificat qui a été commandé et livré, mais dont le domaine n'a pas pu être validé. Généralement, c'est parce que le domaine ne pointe plus vers le Load Balancer OVHcloud. +Un certificat SSL apparaissant comme `built_not_routed` est un certificat qui a été commandé et livré, mais dont le domaine ne peut pas être validé. Cela est généralement dû au fait que le domaine ne pointe plus vers le service OVHcloud Load Balancer. -- Pour obtenir les détails d'un certificat SSL, vous pouvez utiliser la fonction API suivante : +Pour obtenir les détails d'un certificat SSL, vous pouvez utiliser l'appel API suivant : > [!api] > @@ -92,4 +142,6 @@ Un certificat de type `built_not_routed` est un certificat qui a été commandé ## Aller plus loin -Échangez avec notre [communauté d'utilisateurs](/links/community). +Trouvez les détails de tous les appels API liés à l'OVHcloud Load Balancer dans [ce guide](/pages/network/load_balancer/use_api_details). + +Rejoignez notre [communauté d'utilisateurs](/links/community). diff --git a/pages/network/load_balancer/create_headers/guide.en-asia.md b/pages/network/load_balancer/create_headers/guide.en-asia.md index 75cecc048dc..aa8adb97bd7 100644 --- a/pages/network/load_balancer/create_headers/guide.en-asia.md +++ b/pages/network/load_balancer/create_headers/guide.en-asia.md @@ -1,97 +1,255 @@ --- -title: OVH Load Balancer - HTTP Header -excerpt: Get HTTP Headers on your services behind OVH Load Balancer -updated: 2018-08-03 +title: "Configuration of an OVHcloud Load Balancer service - HTTP headers" +excerpt: Integrate your web services behind a Load Balancer with HTTP headers +updated: 2025-11-12 --- -## Introduction -With any frontend service like CDN, IP Loadbalancing in front of your services, the IP of your clients is hidden by this service. +## Objective -In your log, you'll only see privateIP, and we'll fix this. +The OVHcloud Load Balancer service acts as a proxy. Like a human proxy, it serves as an intermediary: the client addresses the proxy, which in turn contacts the service provider on behalf of the client. In this configuration, **only the proxy** has information about the **real client** (the visitor of your web service) and the **real service provider** (one of your servers). + +For the visitor, this configuration does not raise any issues. They do not need to know the specific server handling their request; it is an implementation detail. However, for legal and statistical reasons, it is **essential** that the final server knows the client's real IP address. By default, it only identifies the proxy, which is your OVHcloud Load Balancer service. To overcome this issue, your OVHcloud Load Balancer service **adds by default** the standard HTTP headers that allow you to retrieve this information in the case of an HTTP connection. For a TCP connection, other solutions such as the ProxyProtocol exist, but they are beyond the scope of this guide. + +**This guide presents the default headers, their function, how to use them on the most common servers, and how to customize them according to the requirements of your infrastructure.** + +This guide is specifically for you if you only find private IP addresses in your access logs (`access_log`). + +## Requirements + +- Have an [OVHcloud Load Balancer](/links/network/load-balancer) offer in your OVHcloud account. +- You must be logged in to your [OVHcloud Control Panel](/links/manager). +- Have a Web service installed and configured on your servers. +- Have an Nginx service installed and configured on your servers. + +## Instructions ```bash -10.108.0.15 - - [22/Mar/2017:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" -10.108.0.24 - - [22/Mar/2017:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" +10.108.0.15 - - [02/Fev/2022:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" +10.108.0.24 - - [02/Fev/2022/:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" ``` -## Avertissement -You need to restrict access to your webservices from our IP Loadbalancing. +### Legal obligations + +You may be required to keep logs and certain data related to traffic in accordance with the laws and regulations applicable to you. **It is your responsibility to comply with these obligations.** + +**As an example:** + +- [Article L34-1 of the Code of Posts and Electronic Communications](https://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT000006070987&idArticle=LEGIARTI000006465770&dateTexte=&categorieLien=cid) and [Decree No. 2006-358 of 24 March 2006 on the retention of electronic communication data](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000637071&dateTexte=20180110) require any natural or legal person providing a public electronic communications service to retain user identification data for the services provided, etc. ; +- [Law No. 2004-575 of 21 June 2004 on trust in the digital economy](https://www.legifrance.gouv.fr/affichTexteArticle.do?idArticle=JORFARTI000002457442&cidTexte=JORFTEXT000000801164) and [Decree No. 2011-219 of 25 February 2011](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000023646013&categorieLien=id) require, among other things, that persons whose activity consists of providing access to online public communication services retain, for each connection, data relating to the connection identifier, the start and end dates and times of the connection, etc. + +### Default headers + +By default, your OVHcloud Load Balancer service adds **five** standard HTTP headers to each request, allowing you to identify the visitor's IP address and port as well as the initial connection protocol of the visitor to your site. -With this api call you can get IP Range of our servers. +|Header|Description| +|---|---| +|X-Forwarded-For and X-Remote-Ip|IP address of the client, as seen by your OVHcloud Load Balancer.| +|X-Forwarded-Port and X-Remote-Port|Source port of the client, as seen by your OVHcloud Load Balancer.| +|X-Forwarded-Proto|Client protocol (HTTP or HTTPS), as seen by your OVHcloud Load Balancer.| + +> [!warning] +> The `X-Forwarded-*` fields can be manipulated by a malicious client, **so they should only be considered if they come from a trusted source.** +> +> It is therefore **essential** to restrict their use to trusted IP addresses, which are the output IP addresses of your OVHcloud Load Balancer service. Major web servers such as Nginx and Apache have modules that can handle this aspect of security and reliability. +> + +The list of your output IP addresses is available via the OVHcloud Control Panel and the OVHcloud API. + +#### From the OVHcloud Control Panel + +The list of IPv4 output addresses that may be used by your OVHcloud Load Balancer service is available on the homepage of your Load Balancer service under the heading "IPv4 output". + +![IPv4 output address of your OVHcloud Load Balancer service](images/iplb_service.png){.thumbnail} + +#### From the OVHcloud API + +- Retrieving the list of IP addresses used by your OVHcloud Load Balancer service: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/natIp > -If you accept proxy-headers (X-Forwarded-*) from anywhere, some request could bypass your security policies. -## Headers +### Correcting the source IP in the logs + +By default, Apache, Nginx and other web servers record the source IP address in their logs. When you use an OVHcloud Load Balancer in front of your website, the logs then only contain IP addresses of the form "10.108.a.b". These are the internal IP addresses used by the OVHcloud Load Balancer to contact you. + +When a request goes through your OVHcloud Load Balancer service, it records the visitor's IP address in the `X-Forwarded-For` and `X-Remote-Ip` headers. These two fields carry the same information, their names differ only for compatibility with most servers. -### X-Forwarded-For -This header have inside the Ip of your client. +To correct the IP addresses in the logs, one solution would be to modify the log format directive on your server to use one of these headers instead of the Load Balancer's IP address. Unfortunately, this approach is insufficient, as anyone can fill in this header, even without going through your OVHcloud Load Balancer. This manipulation would allow the visitor to impersonate someone else. Apart from the ethical aspect, this practice has legal, security and statistical implications that make its prevention essential. + +This is why the main web servers include specialized modules that allow you to precisely control the level of trust given to these headers based on: + +- The source IP address (must be exclusively that of your OVHcloud Load Balancer service!) +- The depth of the IP in the field. Indeed, each proxy (proxy, load balancer) adds the client's IP address to this field. + +The rest of this guide provides recommended configuration practices for the main web servers. #### Apache +- Create the file `/etc/apache2/conf-available/remoteip.conf`. +- Insert the following configuration: + ```apache -1. LogFormat "%{X-Forwarded-For}i-%h- %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" loadbalancing -2. CustomLog /chemin/fichier.log loadbalancing +1. # Trust X-Forwarded-For headers from the OVHcloud Load Balancer +2. # See https://www.ovh.com/manager/sunrise/iplb/index.html#/iplb for an up to date list +3. RemoteIPHeader X-Forwarded-For +4. RemoteIPInternalProxy 10.108.0.0/14 +``` + +- Then replace the variables `%h` with `%a` in the `LogFormat` directives of the Apache configuration. +- Finally, enable the new configuration with: + +```bash +# Enable the 'remoteip' module and configuration +a2enmod remoteip +a2enconf remoteip + +# Restart apache to load the new module ("reload" is enough if the module was already enabled) +service apache2 restart ``` #### Nginx +For Nginx, the approach is slightly simpler, but the principle remains the same as for Apache: only take into account the `X-Forwarded-For` field if it comes from your OVHcloud Load Balancer service. + +This configuration can be applied: + +- To all sites, by inserting the configuration in the `http {}` section; +- To a specific site, by inserting the configuration in the corresponding `server {}` section; +- To a specific URL, by inserting the configuration in the corresponding `location {}` section. +- Insert the configuration in the desired section(s) (`http {}` for a global configuration): + ```nginx -1. log_format "%{X-Forwarded-For}i-%h- %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" loadbalancing -2. access_log /chemin/fichier.log loadbalancing +1. # Trust X-Forwarded-For headers from the OVHcloud Load Balancer +2. # See https://www.ovh.com/manager/sunrise/iplb/index.html#/iplb for an up to date list +3. set_real_ip_from 10.108.0.0/16; +4. real_ip_header X-Forwarded-For; +``` + +- Then enable the new configuration with: + +```bash +service nginx reload ``` -### X-Forwarded-Proto -You can also get the scheme used by your client to reach OVH Load Balancer. This is helpful to redirect **HTTP** to **HTTPS** +#### Redirecting HTTP visitors to HTTPS + +To enhance security, some content such as login pages, can be restricted to the HTTPS protocol. Some sites even choose to systematically redirect all visits to the HTTPS version. By default, the HTTP and HTTPS protocols use different ports (80 and 443 respectively), so the classic solution is to place the redirection rules directly in the *vhost* dedicated to HTTP. + +When a request goes through a service like the OVHcloud Load Balancer, it handles the reception of HTTP traffic, the decryption of HTTPS traffic and forwards both types of traffic to your servers. Depending on your server configuration, all traffic will be propagated in HTTP or HTTPS, without distinction of the incoming protocol on the Load Balancer. Your server can no longer differentiate the two, as both arrive at the same point. This process is called **SSL Termination**. + +This is why the OVHcloud Load Balancer service automatically adds a header `X-Forwarded-Proto` which indicates the name of the original protocol, either "http" or "https". + +Like `X-Forwarded-For`, this header can be forged by a malicious visitor to make an insecure request appear to come from your OVHcloud Load Balancer service, in HTTPS. It is crucial to trust this header only if it is proven to come from your OVHcloud Load Balancer service. #### Apache -With htaccess, you can redirect your customers in HTTPS. -```htaccess +- Insert the following configuration in your site's `.htaccess` file: + +```apache 1. RewriteEngine on -2. RewriteCond %{HTTP:X_Forwarded_Proto} !https +2. RewriteCond %{HTTP:X-Forwarded-Proto} !https 3. RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] ``` -#### Nginx -This is not a good configuration, you'll reduce your service performance. +- Then enable the new configuration with: ```bash -if ($http_x_forwarded_proto = "http") { - return 301 https://$host/$request_uri; -} +service apache2 reload ``` -#### Nginx (best) -With Nginx, it's best to use a entire VHost to redirect HTTP to HTTPS. +#### Nginx + +- Insert the following configuration in the `server {` section of your site: + +```nginx +1. if ($http_x_forwarded_proto = "http") { +2.         return 301 https://$host/$request_uri; +3. } +``` + +- Then enable the new configuration with: ```bash -server { - listen [::]:80 default_server; - listen 80 default_server; - server_name _; - root /var/www/; - location / { - return 301 https://$server_name$request_uri; - } -} +service nginx reload ``` -### Send headers to PHP +### Passing headers to PHP -#### Apache +PHP uses the `REMOTE_ADDR` header to determine the address of the visitors. This header is automatically configured as soon as the configuration detailed in the section "[Correcting the source IP in the logs](#ip-source-logs)" is applied. -```apache -1. Header set REMOTE_ADDR %{HTTP:X_Forwarded_Proto} -``` +### Adding custom headers -#### Nginx -With RealIP module. +Whether your application requires a specific header format to identify the visitor's IP, port or protocol, or you want to know which *frontend* a request arrived through (or for any other reason), you can add custom headers on your HTTP *frontend*. -```nginx -1. real_ip_header X-Forwarded-For; -2. set_real_ip_from 10.108.0.0/14; +Custom headers must follow the format "X-Header Header Value". The header name and its value are separated by a space. It is possible to specify several headers on the same *frontend*. + +If an existing header is present in the request, it will be overwritten and replaced by the new value, making it impossible for the visitor passing through this *frontend* to forge it. It is not possible to redefine headers reserved for proxies, such as those described in this document, as they are automatically managed by your OVHcloud Load Balancer service. + +When specifying a non-standard header name, it is customary to prefix it with "X-". + +The use of variables in the header values is supported: + +- `%ci` will be replaced by the visitor's IP address. +- `%cp` will be replaced by the visitor's source port. + +Custom headers can be configured via the OVHcloud Control Panel and the API, whether on a new *frontend* or an existing *frontend*. + +#### From the OVHcloud Control Panel + +Go to the `Frontends`{.action} tab in the dashboard of your OVHcloud Load Balancer service and select the *frontend* to edit or click on the `Add a frontend`{.action} button to create a new one. An editing window will appear, displaying an `HTTP Header`{.action} field in the `Advanced Settings`{.action} section. + +If you want to configure multiple headers, they must be separated by commas, *without spaces*. For example, you can define the following headers: `X-Ip-Header %ci,X-Port-Header %cp`. + +![Configuration of HTTP headers of a Frontend via ovh manager API](images/add_headers.png){.thumbnail} + +Click on the `Update`{.action} button after configuring the headers, then on `Deploy zone: YOUR ZONE`{.action} to apply the changes in the concerned zone. + +### From the OVHcloud API + +In the API, the headers are specified within an `httpHeader` list. Unlike the OVHcloud Control Panel, each header must be its own entry in the list. + +In the OVHcloud API console, a `+`{.action} button is available as soon as you start to specify a value, allowing you to add a new field to the list. + +![Configuration of HTTP headers of a Frontend](images/add_headers_with_api.png){.thumbnail} + +If you integrate the API into your code, this corresponds to a JSON list of the type: + +```json +1. { +2.         "httpHeader": [ +3.                 "X-Ip-Header %ci", +4.                 "X-Port-Header %cp" +5.         ] +6. } ``` + +- Modification of an existing `Frontend`{.action} : + +> [!api] +> +> @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} +> + +|Parameter|Meaning| +|---------|-------------| +|serviceName|Name of the Load Balancer service concerned| +|frontendId|Identifier of the frontend where to configure the HTTP headers| +|httpHeader|List of headers to configure| + +- Applying the changes: + +> [!api] +> +> @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/refresh +> + +|Parameter|Meaning| +|---------|-------------| +|serviceName|Name of the Load Balancer service concerned| +|zone|Name of the zone in which to deploy the configuration| + +## Go further + +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_headers/guide.en-au.md b/pages/network/load_balancer/create_headers/guide.en-au.md index 75cecc048dc..aa8adb97bd7 100644 --- a/pages/network/load_balancer/create_headers/guide.en-au.md +++ b/pages/network/load_balancer/create_headers/guide.en-au.md @@ -1,97 +1,255 @@ --- -title: OVH Load Balancer - HTTP Header -excerpt: Get HTTP Headers on your services behind OVH Load Balancer -updated: 2018-08-03 +title: "Configuration of an OVHcloud Load Balancer service - HTTP headers" +excerpt: Integrate your web services behind a Load Balancer with HTTP headers +updated: 2025-11-12 --- -## Introduction -With any frontend service like CDN, IP Loadbalancing in front of your services, the IP of your clients is hidden by this service. +## Objective -In your log, you'll only see privateIP, and we'll fix this. +The OVHcloud Load Balancer service acts as a proxy. Like a human proxy, it serves as an intermediary: the client addresses the proxy, which in turn contacts the service provider on behalf of the client. In this configuration, **only the proxy** has information about the **real client** (the visitor of your web service) and the **real service provider** (one of your servers). + +For the visitor, this configuration does not raise any issues. They do not need to know the specific server handling their request; it is an implementation detail. However, for legal and statistical reasons, it is **essential** that the final server knows the client's real IP address. By default, it only identifies the proxy, which is your OVHcloud Load Balancer service. To overcome this issue, your OVHcloud Load Balancer service **adds by default** the standard HTTP headers that allow you to retrieve this information in the case of an HTTP connection. For a TCP connection, other solutions such as the ProxyProtocol exist, but they are beyond the scope of this guide. + +**This guide presents the default headers, their function, how to use them on the most common servers, and how to customize them according to the requirements of your infrastructure.** + +This guide is specifically for you if you only find private IP addresses in your access logs (`access_log`). + +## Requirements + +- Have an [OVHcloud Load Balancer](/links/network/load-balancer) offer in your OVHcloud account. +- You must be logged in to your [OVHcloud Control Panel](/links/manager). +- Have a Web service installed and configured on your servers. +- Have an Nginx service installed and configured on your servers. + +## Instructions ```bash -10.108.0.15 - - [22/Mar/2017:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" -10.108.0.24 - - [22/Mar/2017:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" +10.108.0.15 - - [02/Fev/2022:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" +10.108.0.24 - - [02/Fev/2022/:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" ``` -## Avertissement -You need to restrict access to your webservices from our IP Loadbalancing. +### Legal obligations + +You may be required to keep logs and certain data related to traffic in accordance with the laws and regulations applicable to you. **It is your responsibility to comply with these obligations.** + +**As an example:** + +- [Article L34-1 of the Code of Posts and Electronic Communications](https://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT000006070987&idArticle=LEGIARTI000006465770&dateTexte=&categorieLien=cid) and [Decree No. 2006-358 of 24 March 2006 on the retention of electronic communication data](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000637071&dateTexte=20180110) require any natural or legal person providing a public electronic communications service to retain user identification data for the services provided, etc. ; +- [Law No. 2004-575 of 21 June 2004 on trust in the digital economy](https://www.legifrance.gouv.fr/affichTexteArticle.do?idArticle=JORFARTI000002457442&cidTexte=JORFTEXT000000801164) and [Decree No. 2011-219 of 25 February 2011](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000023646013&categorieLien=id) require, among other things, that persons whose activity consists of providing access to online public communication services retain, for each connection, data relating to the connection identifier, the start and end dates and times of the connection, etc. + +### Default headers + +By default, your OVHcloud Load Balancer service adds **five** standard HTTP headers to each request, allowing you to identify the visitor's IP address and port as well as the initial connection protocol of the visitor to your site. -With this api call you can get IP Range of our servers. +|Header|Description| +|---|---| +|X-Forwarded-For and X-Remote-Ip|IP address of the client, as seen by your OVHcloud Load Balancer.| +|X-Forwarded-Port and X-Remote-Port|Source port of the client, as seen by your OVHcloud Load Balancer.| +|X-Forwarded-Proto|Client protocol (HTTP or HTTPS), as seen by your OVHcloud Load Balancer.| + +> [!warning] +> The `X-Forwarded-*` fields can be manipulated by a malicious client, **so they should only be considered if they come from a trusted source.** +> +> It is therefore **essential** to restrict their use to trusted IP addresses, which are the output IP addresses of your OVHcloud Load Balancer service. Major web servers such as Nginx and Apache have modules that can handle this aspect of security and reliability. +> + +The list of your output IP addresses is available via the OVHcloud Control Panel and the OVHcloud API. + +#### From the OVHcloud Control Panel + +The list of IPv4 output addresses that may be used by your OVHcloud Load Balancer service is available on the homepage of your Load Balancer service under the heading "IPv4 output". + +![IPv4 output address of your OVHcloud Load Balancer service](images/iplb_service.png){.thumbnail} + +#### From the OVHcloud API + +- Retrieving the list of IP addresses used by your OVHcloud Load Balancer service: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/natIp > -If you accept proxy-headers (X-Forwarded-*) from anywhere, some request could bypass your security policies. -## Headers +### Correcting the source IP in the logs + +By default, Apache, Nginx and other web servers record the source IP address in their logs. When you use an OVHcloud Load Balancer in front of your website, the logs then only contain IP addresses of the form "10.108.a.b". These are the internal IP addresses used by the OVHcloud Load Balancer to contact you. + +When a request goes through your OVHcloud Load Balancer service, it records the visitor's IP address in the `X-Forwarded-For` and `X-Remote-Ip` headers. These two fields carry the same information, their names differ only for compatibility with most servers. -### X-Forwarded-For -This header have inside the Ip of your client. +To correct the IP addresses in the logs, one solution would be to modify the log format directive on your server to use one of these headers instead of the Load Balancer's IP address. Unfortunately, this approach is insufficient, as anyone can fill in this header, even without going through your OVHcloud Load Balancer. This manipulation would allow the visitor to impersonate someone else. Apart from the ethical aspect, this practice has legal, security and statistical implications that make its prevention essential. + +This is why the main web servers include specialized modules that allow you to precisely control the level of trust given to these headers based on: + +- The source IP address (must be exclusively that of your OVHcloud Load Balancer service!) +- The depth of the IP in the field. Indeed, each proxy (proxy, load balancer) adds the client's IP address to this field. + +The rest of this guide provides recommended configuration practices for the main web servers. #### Apache +- Create the file `/etc/apache2/conf-available/remoteip.conf`. +- Insert the following configuration: + ```apache -1. LogFormat "%{X-Forwarded-For}i-%h- %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" loadbalancing -2. CustomLog /chemin/fichier.log loadbalancing +1. # Trust X-Forwarded-For headers from the OVHcloud Load Balancer +2. # See https://www.ovh.com/manager/sunrise/iplb/index.html#/iplb for an up to date list +3. RemoteIPHeader X-Forwarded-For +4. RemoteIPInternalProxy 10.108.0.0/14 +``` + +- Then replace the variables `%h` with `%a` in the `LogFormat` directives of the Apache configuration. +- Finally, enable the new configuration with: + +```bash +# Enable the 'remoteip' module and configuration +a2enmod remoteip +a2enconf remoteip + +# Restart apache to load the new module ("reload" is enough if the module was already enabled) +service apache2 restart ``` #### Nginx +For Nginx, the approach is slightly simpler, but the principle remains the same as for Apache: only take into account the `X-Forwarded-For` field if it comes from your OVHcloud Load Balancer service. + +This configuration can be applied: + +- To all sites, by inserting the configuration in the `http {}` section; +- To a specific site, by inserting the configuration in the corresponding `server {}` section; +- To a specific URL, by inserting the configuration in the corresponding `location {}` section. +- Insert the configuration in the desired section(s) (`http {}` for a global configuration): + ```nginx -1. log_format "%{X-Forwarded-For}i-%h- %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" loadbalancing -2. access_log /chemin/fichier.log loadbalancing +1. # Trust X-Forwarded-For headers from the OVHcloud Load Balancer +2. # See https://www.ovh.com/manager/sunrise/iplb/index.html#/iplb for an up to date list +3. set_real_ip_from 10.108.0.0/16; +4. real_ip_header X-Forwarded-For; +``` + +- Then enable the new configuration with: + +```bash +service nginx reload ``` -### X-Forwarded-Proto -You can also get the scheme used by your client to reach OVH Load Balancer. This is helpful to redirect **HTTP** to **HTTPS** +#### Redirecting HTTP visitors to HTTPS + +To enhance security, some content such as login pages, can be restricted to the HTTPS protocol. Some sites even choose to systematically redirect all visits to the HTTPS version. By default, the HTTP and HTTPS protocols use different ports (80 and 443 respectively), so the classic solution is to place the redirection rules directly in the *vhost* dedicated to HTTP. + +When a request goes through a service like the OVHcloud Load Balancer, it handles the reception of HTTP traffic, the decryption of HTTPS traffic and forwards both types of traffic to your servers. Depending on your server configuration, all traffic will be propagated in HTTP or HTTPS, without distinction of the incoming protocol on the Load Balancer. Your server can no longer differentiate the two, as both arrive at the same point. This process is called **SSL Termination**. + +This is why the OVHcloud Load Balancer service automatically adds a header `X-Forwarded-Proto` which indicates the name of the original protocol, either "http" or "https". + +Like `X-Forwarded-For`, this header can be forged by a malicious visitor to make an insecure request appear to come from your OVHcloud Load Balancer service, in HTTPS. It is crucial to trust this header only if it is proven to come from your OVHcloud Load Balancer service. #### Apache -With htaccess, you can redirect your customers in HTTPS. -```htaccess +- Insert the following configuration in your site's `.htaccess` file: + +```apache 1. RewriteEngine on -2. RewriteCond %{HTTP:X_Forwarded_Proto} !https +2. RewriteCond %{HTTP:X-Forwarded-Proto} !https 3. RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] ``` -#### Nginx -This is not a good configuration, you'll reduce your service performance. +- Then enable the new configuration with: ```bash -if ($http_x_forwarded_proto = "http") { - return 301 https://$host/$request_uri; -} +service apache2 reload ``` -#### Nginx (best) -With Nginx, it's best to use a entire VHost to redirect HTTP to HTTPS. +#### Nginx + +- Insert the following configuration in the `server {` section of your site: + +```nginx +1. if ($http_x_forwarded_proto = "http") { +2.         return 301 https://$host/$request_uri; +3. } +``` + +- Then enable the new configuration with: ```bash -server { - listen [::]:80 default_server; - listen 80 default_server; - server_name _; - root /var/www/; - location / { - return 301 https://$server_name$request_uri; - } -} +service nginx reload ``` -### Send headers to PHP +### Passing headers to PHP -#### Apache +PHP uses the `REMOTE_ADDR` header to determine the address of the visitors. This header is automatically configured as soon as the configuration detailed in the section "[Correcting the source IP in the logs](#ip-source-logs)" is applied. -```apache -1. Header set REMOTE_ADDR %{HTTP:X_Forwarded_Proto} -``` +### Adding custom headers -#### Nginx -With RealIP module. +Whether your application requires a specific header format to identify the visitor's IP, port or protocol, or you want to know which *frontend* a request arrived through (or for any other reason), you can add custom headers on your HTTP *frontend*. -```nginx -1. real_ip_header X-Forwarded-For; -2. set_real_ip_from 10.108.0.0/14; +Custom headers must follow the format "X-Header Header Value". The header name and its value are separated by a space. It is possible to specify several headers on the same *frontend*. + +If an existing header is present in the request, it will be overwritten and replaced by the new value, making it impossible for the visitor passing through this *frontend* to forge it. It is not possible to redefine headers reserved for proxies, such as those described in this document, as they are automatically managed by your OVHcloud Load Balancer service. + +When specifying a non-standard header name, it is customary to prefix it with "X-". + +The use of variables in the header values is supported: + +- `%ci` will be replaced by the visitor's IP address. +- `%cp` will be replaced by the visitor's source port. + +Custom headers can be configured via the OVHcloud Control Panel and the API, whether on a new *frontend* or an existing *frontend*. + +#### From the OVHcloud Control Panel + +Go to the `Frontends`{.action} tab in the dashboard of your OVHcloud Load Balancer service and select the *frontend* to edit or click on the `Add a frontend`{.action} button to create a new one. An editing window will appear, displaying an `HTTP Header`{.action} field in the `Advanced Settings`{.action} section. + +If you want to configure multiple headers, they must be separated by commas, *without spaces*. For example, you can define the following headers: `X-Ip-Header %ci,X-Port-Header %cp`. + +![Configuration of HTTP headers of a Frontend via ovh manager API](images/add_headers.png){.thumbnail} + +Click on the `Update`{.action} button after configuring the headers, then on `Deploy zone: YOUR ZONE`{.action} to apply the changes in the concerned zone. + +### From the OVHcloud API + +In the API, the headers are specified within an `httpHeader` list. Unlike the OVHcloud Control Panel, each header must be its own entry in the list. + +In the OVHcloud API console, a `+`{.action} button is available as soon as you start to specify a value, allowing you to add a new field to the list. + +![Configuration of HTTP headers of a Frontend](images/add_headers_with_api.png){.thumbnail} + +If you integrate the API into your code, this corresponds to a JSON list of the type: + +```json +1. { +2.         "httpHeader": [ +3.                 "X-Ip-Header %ci", +4.                 "X-Port-Header %cp" +5.         ] +6. } ``` + +- Modification of an existing `Frontend`{.action} : + +> [!api] +> +> @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} +> + +|Parameter|Meaning| +|---------|-------------| +|serviceName|Name of the Load Balancer service concerned| +|frontendId|Identifier of the frontend where to configure the HTTP headers| +|httpHeader|List of headers to configure| + +- Applying the changes: + +> [!api] +> +> @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/refresh +> + +|Parameter|Meaning| +|---------|-------------| +|serviceName|Name of the Load Balancer service concerned| +|zone|Name of the zone in which to deploy the configuration| + +## Go further + +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_headers/guide.en-ca.md b/pages/network/load_balancer/create_headers/guide.en-ca.md index 75cecc048dc..aa8adb97bd7 100644 --- a/pages/network/load_balancer/create_headers/guide.en-ca.md +++ b/pages/network/load_balancer/create_headers/guide.en-ca.md @@ -1,97 +1,255 @@ --- -title: OVH Load Balancer - HTTP Header -excerpt: Get HTTP Headers on your services behind OVH Load Balancer -updated: 2018-08-03 +title: "Configuration of an OVHcloud Load Balancer service - HTTP headers" +excerpt: Integrate your web services behind a Load Balancer with HTTP headers +updated: 2025-11-12 --- -## Introduction -With any frontend service like CDN, IP Loadbalancing in front of your services, the IP of your clients is hidden by this service. +## Objective -In your log, you'll only see privateIP, and we'll fix this. +The OVHcloud Load Balancer service acts as a proxy. Like a human proxy, it serves as an intermediary: the client addresses the proxy, which in turn contacts the service provider on behalf of the client. In this configuration, **only the proxy** has information about the **real client** (the visitor of your web service) and the **real service provider** (one of your servers). + +For the visitor, this configuration does not raise any issues. They do not need to know the specific server handling their request; it is an implementation detail. However, for legal and statistical reasons, it is **essential** that the final server knows the client's real IP address. By default, it only identifies the proxy, which is your OVHcloud Load Balancer service. To overcome this issue, your OVHcloud Load Balancer service **adds by default** the standard HTTP headers that allow you to retrieve this information in the case of an HTTP connection. For a TCP connection, other solutions such as the ProxyProtocol exist, but they are beyond the scope of this guide. + +**This guide presents the default headers, their function, how to use them on the most common servers, and how to customize them according to the requirements of your infrastructure.** + +This guide is specifically for you if you only find private IP addresses in your access logs (`access_log`). + +## Requirements + +- Have an [OVHcloud Load Balancer](/links/network/load-balancer) offer in your OVHcloud account. +- You must be logged in to your [OVHcloud Control Panel](/links/manager). +- Have a Web service installed and configured on your servers. +- Have an Nginx service installed and configured on your servers. + +## Instructions ```bash -10.108.0.15 - - [22/Mar/2017:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" -10.108.0.24 - - [22/Mar/2017:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" +10.108.0.15 - - [02/Fev/2022:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" +10.108.0.24 - - [02/Fev/2022/:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" ``` -## Avertissement -You need to restrict access to your webservices from our IP Loadbalancing. +### Legal obligations + +You may be required to keep logs and certain data related to traffic in accordance with the laws and regulations applicable to you. **It is your responsibility to comply with these obligations.** + +**As an example:** + +- [Article L34-1 of the Code of Posts and Electronic Communications](https://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT000006070987&idArticle=LEGIARTI000006465770&dateTexte=&categorieLien=cid) and [Decree No. 2006-358 of 24 March 2006 on the retention of electronic communication data](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000637071&dateTexte=20180110) require any natural or legal person providing a public electronic communications service to retain user identification data for the services provided, etc. ; +- [Law No. 2004-575 of 21 June 2004 on trust in the digital economy](https://www.legifrance.gouv.fr/affichTexteArticle.do?idArticle=JORFARTI000002457442&cidTexte=JORFTEXT000000801164) and [Decree No. 2011-219 of 25 February 2011](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000023646013&categorieLien=id) require, among other things, that persons whose activity consists of providing access to online public communication services retain, for each connection, data relating to the connection identifier, the start and end dates and times of the connection, etc. + +### Default headers + +By default, your OVHcloud Load Balancer service adds **five** standard HTTP headers to each request, allowing you to identify the visitor's IP address and port as well as the initial connection protocol of the visitor to your site. -With this api call you can get IP Range of our servers. +|Header|Description| +|---|---| +|X-Forwarded-For and X-Remote-Ip|IP address of the client, as seen by your OVHcloud Load Balancer.| +|X-Forwarded-Port and X-Remote-Port|Source port of the client, as seen by your OVHcloud Load Balancer.| +|X-Forwarded-Proto|Client protocol (HTTP or HTTPS), as seen by your OVHcloud Load Balancer.| + +> [!warning] +> The `X-Forwarded-*` fields can be manipulated by a malicious client, **so they should only be considered if they come from a trusted source.** +> +> It is therefore **essential** to restrict their use to trusted IP addresses, which are the output IP addresses of your OVHcloud Load Balancer service. Major web servers such as Nginx and Apache have modules that can handle this aspect of security and reliability. +> + +The list of your output IP addresses is available via the OVHcloud Control Panel and the OVHcloud API. + +#### From the OVHcloud Control Panel + +The list of IPv4 output addresses that may be used by your OVHcloud Load Balancer service is available on the homepage of your Load Balancer service under the heading "IPv4 output". + +![IPv4 output address of your OVHcloud Load Balancer service](images/iplb_service.png){.thumbnail} + +#### From the OVHcloud API + +- Retrieving the list of IP addresses used by your OVHcloud Load Balancer service: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/natIp > -If you accept proxy-headers (X-Forwarded-*) from anywhere, some request could bypass your security policies. -## Headers +### Correcting the source IP in the logs + +By default, Apache, Nginx and other web servers record the source IP address in their logs. When you use an OVHcloud Load Balancer in front of your website, the logs then only contain IP addresses of the form "10.108.a.b". These are the internal IP addresses used by the OVHcloud Load Balancer to contact you. + +When a request goes through your OVHcloud Load Balancer service, it records the visitor's IP address in the `X-Forwarded-For` and `X-Remote-Ip` headers. These two fields carry the same information, their names differ only for compatibility with most servers. -### X-Forwarded-For -This header have inside the Ip of your client. +To correct the IP addresses in the logs, one solution would be to modify the log format directive on your server to use one of these headers instead of the Load Balancer's IP address. Unfortunately, this approach is insufficient, as anyone can fill in this header, even without going through your OVHcloud Load Balancer. This manipulation would allow the visitor to impersonate someone else. Apart from the ethical aspect, this practice has legal, security and statistical implications that make its prevention essential. + +This is why the main web servers include specialized modules that allow you to precisely control the level of trust given to these headers based on: + +- The source IP address (must be exclusively that of your OVHcloud Load Balancer service!) +- The depth of the IP in the field. Indeed, each proxy (proxy, load balancer) adds the client's IP address to this field. + +The rest of this guide provides recommended configuration practices for the main web servers. #### Apache +- Create the file `/etc/apache2/conf-available/remoteip.conf`. +- Insert the following configuration: + ```apache -1. LogFormat "%{X-Forwarded-For}i-%h- %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" loadbalancing -2. CustomLog /chemin/fichier.log loadbalancing +1. # Trust X-Forwarded-For headers from the OVHcloud Load Balancer +2. # See https://www.ovh.com/manager/sunrise/iplb/index.html#/iplb for an up to date list +3. RemoteIPHeader X-Forwarded-For +4. RemoteIPInternalProxy 10.108.0.0/14 +``` + +- Then replace the variables `%h` with `%a` in the `LogFormat` directives of the Apache configuration. +- Finally, enable the new configuration with: + +```bash +# Enable the 'remoteip' module and configuration +a2enmod remoteip +a2enconf remoteip + +# Restart apache to load the new module ("reload" is enough if the module was already enabled) +service apache2 restart ``` #### Nginx +For Nginx, the approach is slightly simpler, but the principle remains the same as for Apache: only take into account the `X-Forwarded-For` field if it comes from your OVHcloud Load Balancer service. + +This configuration can be applied: + +- To all sites, by inserting the configuration in the `http {}` section; +- To a specific site, by inserting the configuration in the corresponding `server {}` section; +- To a specific URL, by inserting the configuration in the corresponding `location {}` section. +- Insert the configuration in the desired section(s) (`http {}` for a global configuration): + ```nginx -1. log_format "%{X-Forwarded-For}i-%h- %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" loadbalancing -2. access_log /chemin/fichier.log loadbalancing +1. # Trust X-Forwarded-For headers from the OVHcloud Load Balancer +2. # See https://www.ovh.com/manager/sunrise/iplb/index.html#/iplb for an up to date list +3. set_real_ip_from 10.108.0.0/16; +4. real_ip_header X-Forwarded-For; +``` + +- Then enable the new configuration with: + +```bash +service nginx reload ``` -### X-Forwarded-Proto -You can also get the scheme used by your client to reach OVH Load Balancer. This is helpful to redirect **HTTP** to **HTTPS** +#### Redirecting HTTP visitors to HTTPS + +To enhance security, some content such as login pages, can be restricted to the HTTPS protocol. Some sites even choose to systematically redirect all visits to the HTTPS version. By default, the HTTP and HTTPS protocols use different ports (80 and 443 respectively), so the classic solution is to place the redirection rules directly in the *vhost* dedicated to HTTP. + +When a request goes through a service like the OVHcloud Load Balancer, it handles the reception of HTTP traffic, the decryption of HTTPS traffic and forwards both types of traffic to your servers. Depending on your server configuration, all traffic will be propagated in HTTP or HTTPS, without distinction of the incoming protocol on the Load Balancer. Your server can no longer differentiate the two, as both arrive at the same point. This process is called **SSL Termination**. + +This is why the OVHcloud Load Balancer service automatically adds a header `X-Forwarded-Proto` which indicates the name of the original protocol, either "http" or "https". + +Like `X-Forwarded-For`, this header can be forged by a malicious visitor to make an insecure request appear to come from your OVHcloud Load Balancer service, in HTTPS. It is crucial to trust this header only if it is proven to come from your OVHcloud Load Balancer service. #### Apache -With htaccess, you can redirect your customers in HTTPS. -```htaccess +- Insert the following configuration in your site's `.htaccess` file: + +```apache 1. RewriteEngine on -2. RewriteCond %{HTTP:X_Forwarded_Proto} !https +2. RewriteCond %{HTTP:X-Forwarded-Proto} !https 3. RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] ``` -#### Nginx -This is not a good configuration, you'll reduce your service performance. +- Then enable the new configuration with: ```bash -if ($http_x_forwarded_proto = "http") { - return 301 https://$host/$request_uri; -} +service apache2 reload ``` -#### Nginx (best) -With Nginx, it's best to use a entire VHost to redirect HTTP to HTTPS. +#### Nginx + +- Insert the following configuration in the `server {` section of your site: + +```nginx +1. if ($http_x_forwarded_proto = "http") { +2.         return 301 https://$host/$request_uri; +3. } +``` + +- Then enable the new configuration with: ```bash -server { - listen [::]:80 default_server; - listen 80 default_server; - server_name _; - root /var/www/; - location / { - return 301 https://$server_name$request_uri; - } -} +service nginx reload ``` -### Send headers to PHP +### Passing headers to PHP -#### Apache +PHP uses the `REMOTE_ADDR` header to determine the address of the visitors. This header is automatically configured as soon as the configuration detailed in the section "[Correcting the source IP in the logs](#ip-source-logs)" is applied. -```apache -1. Header set REMOTE_ADDR %{HTTP:X_Forwarded_Proto} -``` +### Adding custom headers -#### Nginx -With RealIP module. +Whether your application requires a specific header format to identify the visitor's IP, port or protocol, or you want to know which *frontend* a request arrived through (or for any other reason), you can add custom headers on your HTTP *frontend*. -```nginx -1. real_ip_header X-Forwarded-For; -2. set_real_ip_from 10.108.0.0/14; +Custom headers must follow the format "X-Header Header Value". The header name and its value are separated by a space. It is possible to specify several headers on the same *frontend*. + +If an existing header is present in the request, it will be overwritten and replaced by the new value, making it impossible for the visitor passing through this *frontend* to forge it. It is not possible to redefine headers reserved for proxies, such as those described in this document, as they are automatically managed by your OVHcloud Load Balancer service. + +When specifying a non-standard header name, it is customary to prefix it with "X-". + +The use of variables in the header values is supported: + +- `%ci` will be replaced by the visitor's IP address. +- `%cp` will be replaced by the visitor's source port. + +Custom headers can be configured via the OVHcloud Control Panel and the API, whether on a new *frontend* or an existing *frontend*. + +#### From the OVHcloud Control Panel + +Go to the `Frontends`{.action} tab in the dashboard of your OVHcloud Load Balancer service and select the *frontend* to edit or click on the `Add a frontend`{.action} button to create a new one. An editing window will appear, displaying an `HTTP Header`{.action} field in the `Advanced Settings`{.action} section. + +If you want to configure multiple headers, they must be separated by commas, *without spaces*. For example, you can define the following headers: `X-Ip-Header %ci,X-Port-Header %cp`. + +![Configuration of HTTP headers of a Frontend via ovh manager API](images/add_headers.png){.thumbnail} + +Click on the `Update`{.action} button after configuring the headers, then on `Deploy zone: YOUR ZONE`{.action} to apply the changes in the concerned zone. + +### From the OVHcloud API + +In the API, the headers are specified within an `httpHeader` list. Unlike the OVHcloud Control Panel, each header must be its own entry in the list. + +In the OVHcloud API console, a `+`{.action} button is available as soon as you start to specify a value, allowing you to add a new field to the list. + +![Configuration of HTTP headers of a Frontend](images/add_headers_with_api.png){.thumbnail} + +If you integrate the API into your code, this corresponds to a JSON list of the type: + +```json +1. { +2.         "httpHeader": [ +3.                 "X-Ip-Header %ci", +4.                 "X-Port-Header %cp" +5.         ] +6. } ``` + +- Modification of an existing `Frontend`{.action} : + +> [!api] +> +> @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} +> + +|Parameter|Meaning| +|---------|-------------| +|serviceName|Name of the Load Balancer service concerned| +|frontendId|Identifier of the frontend where to configure the HTTP headers| +|httpHeader|List of headers to configure| + +- Applying the changes: + +> [!api] +> +> @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/refresh +> + +|Parameter|Meaning| +|---------|-------------| +|serviceName|Name of the Load Balancer service concerned| +|zone|Name of the zone in which to deploy the configuration| + +## Go further + +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_headers/guide.en-gb.md b/pages/network/load_balancer/create_headers/guide.en-gb.md index 97bb5728a06..aa8adb97bd7 100644 --- a/pages/network/load_balancer/create_headers/guide.en-gb.md +++ b/pages/network/load_balancer/create_headers/guide.en-gb.md @@ -1,98 +1,255 @@ --- -title: 'OVH Load Balancer : HTTP Header' -excerpt: 'Get HTTP Headers on your services behind OVH Load Balancer' -updated: 2018-08-03 +title: "Configuration of an OVHcloud Load Balancer service - HTTP headers" +excerpt: Integrate your web services behind a Load Balancer with HTTP headers +updated: 2025-11-12 --- -## Introduction -With any frontend service like CDN, IP Loadbalancing in front of your services, the IP of your clients is hidden by this service. +## Objective -In your log, you'll only see privateIP, and we'll fix this. +The OVHcloud Load Balancer service acts as a proxy. Like a human proxy, it serves as an intermediary: the client addresses the proxy, which in turn contacts the service provider on behalf of the client. In this configuration, **only the proxy** has information about the **real client** (the visitor of your web service) and the **real service provider** (one of your servers). + +For the visitor, this configuration does not raise any issues. They do not need to know the specific server handling their request; it is an implementation detail. However, for legal and statistical reasons, it is **essential** that the final server knows the client's real IP address. By default, it only identifies the proxy, which is your OVHcloud Load Balancer service. To overcome this issue, your OVHcloud Load Balancer service **adds by default** the standard HTTP headers that allow you to retrieve this information in the case of an HTTP connection. For a TCP connection, other solutions such as the ProxyProtocol exist, but they are beyond the scope of this guide. + +**This guide presents the default headers, their function, how to use them on the most common servers, and how to customize them according to the requirements of your infrastructure.** + +This guide is specifically for you if you only find private IP addresses in your access logs (`access_log`). + +## Requirements + +- Have an [OVHcloud Load Balancer](/links/network/load-balancer) offer in your OVHcloud account. +- You must be logged in to your [OVHcloud Control Panel](/links/manager). +- Have a Web service installed and configured on your servers. +- Have an Nginx service installed and configured on your servers. + +## Instructions ```bash -10.108.0.15 - - [22/Mar/2017:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" -10.108.0.24 - - [22/Mar/2017:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" +10.108.0.15 - - [02/Fev/2022:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" +10.108.0.24 - - [02/Fev/2022/:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" ``` -## Warning +### Legal obligations + +You may be required to keep logs and certain data related to traffic in accordance with the laws and regulations applicable to you. **It is your responsibility to comply with these obligations.** + +**As an example:** + +- [Article L34-1 of the Code of Posts and Electronic Communications](https://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT000006070987&idArticle=LEGIARTI000006465770&dateTexte=&categorieLien=cid) and [Decree No. 2006-358 of 24 March 2006 on the retention of electronic communication data](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000637071&dateTexte=20180110) require any natural or legal person providing a public electronic communications service to retain user identification data for the services provided, etc. ; +- [Law No. 2004-575 of 21 June 2004 on trust in the digital economy](https://www.legifrance.gouv.fr/affichTexteArticle.do?idArticle=JORFARTI000002457442&cidTexte=JORFTEXT000000801164) and [Decree No. 2011-219 of 25 February 2011](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000023646013&categorieLien=id) require, among other things, that persons whose activity consists of providing access to online public communication services retain, for each connection, data relating to the connection identifier, the start and end dates and times of the connection, etc. + +### Default headers + +By default, your OVHcloud Load Balancer service adds **five** standard HTTP headers to each request, allowing you to identify the visitor's IP address and port as well as the initial connection protocol of the visitor to your site. -You need to restrict access to your webservices from our IP Loadbalancing. +|Header|Description| +|---|---| +|X-Forwarded-For and X-Remote-Ip|IP address of the client, as seen by your OVHcloud Load Balancer.| +|X-Forwarded-Port and X-Remote-Port|Source port of the client, as seen by your OVHcloud Load Balancer.| +|X-Forwarded-Proto|Client protocol (HTTP or HTTPS), as seen by your OVHcloud Load Balancer.| -With this api call you can get IP Range of our servers. +> [!warning] +> The `X-Forwarded-*` fields can be manipulated by a malicious client, **so they should only be considered if they come from a trusted source.** +> +> It is therefore **essential** to restrict their use to trusted IP addresses, which are the output IP addresses of your OVHcloud Load Balancer service. Major web servers such as Nginx and Apache have modules that can handle this aspect of security and reliability. +> + +The list of your output IP addresses is available via the OVHcloud Control Panel and the OVHcloud API. + +#### From the OVHcloud Control Panel + +The list of IPv4 output addresses that may be used by your OVHcloud Load Balancer service is available on the homepage of your Load Balancer service under the heading "IPv4 output". + +![IPv4 output address of your OVHcloud Load Balancer service](images/iplb_service.png){.thumbnail} + +#### From the OVHcloud API + +- Retrieving the list of IP addresses used by your OVHcloud Load Balancer service: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/natIp > -If you accept proxy-headers (X-Forwarded-*) from anywhere, some request could bypass your security policies. -## Headers +### Correcting the source IP in the logs + +By default, Apache, Nginx and other web servers record the source IP address in their logs. When you use an OVHcloud Load Balancer in front of your website, the logs then only contain IP addresses of the form "10.108.a.b". These are the internal IP addresses used by the OVHcloud Load Balancer to contact you. + +When a request goes through your OVHcloud Load Balancer service, it records the visitor's IP address in the `X-Forwarded-For` and `X-Remote-Ip` headers. These two fields carry the same information, their names differ only for compatibility with most servers. + +To correct the IP addresses in the logs, one solution would be to modify the log format directive on your server to use one of these headers instead of the Load Balancer's IP address. Unfortunately, this approach is insufficient, as anyone can fill in this header, even without going through your OVHcloud Load Balancer. This manipulation would allow the visitor to impersonate someone else. Apart from the ethical aspect, this practice has legal, security and statistical implications that make its prevention essential. -### X-Forwarded-For -This header have inside the Ip of your client. +This is why the main web servers include specialized modules that allow you to precisely control the level of trust given to these headers based on: + +- The source IP address (must be exclusively that of your OVHcloud Load Balancer service!) +- The depth of the IP in the field. Indeed, each proxy (proxy, load balancer) adds the client's IP address to this field. + +The rest of this guide provides recommended configuration practices for the main web servers. #### Apache +- Create the file `/etc/apache2/conf-available/remoteip.conf`. +- Insert the following configuration: + ```apache -1. LogFormat "%{X-Forwarded-For}i-%h- %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" loadbalancing -2. CustomLog /chemin/fichier.log loadbalancing +1. # Trust X-Forwarded-For headers from the OVHcloud Load Balancer +2. # See https://www.ovh.com/manager/sunrise/iplb/index.html#/iplb for an up to date list +3. RemoteIPHeader X-Forwarded-For +4. RemoteIPInternalProxy 10.108.0.0/14 +``` + +- Then replace the variables `%h` with `%a` in the `LogFormat` directives of the Apache configuration. +- Finally, enable the new configuration with: + +```bash +# Enable the 'remoteip' module and configuration +a2enmod remoteip +a2enconf remoteip + +# Restart apache to load the new module ("reload" is enough if the module was already enabled) +service apache2 restart ``` #### Nginx +For Nginx, the approach is slightly simpler, but the principle remains the same as for Apache: only take into account the `X-Forwarded-For` field if it comes from your OVHcloud Load Balancer service. + +This configuration can be applied: + +- To all sites, by inserting the configuration in the `http {}` section; +- To a specific site, by inserting the configuration in the corresponding `server {}` section; +- To a specific URL, by inserting the configuration in the corresponding `location {}` section. +- Insert the configuration in the desired section(s) (`http {}` for a global configuration): + ```nginx -1. log_format "%{X-Forwarded-For}i-%h- %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" loadbalancing -2. access_log /chemin/fichier.log loadbalancing +1. # Trust X-Forwarded-For headers from the OVHcloud Load Balancer +2. # See https://www.ovh.com/manager/sunrise/iplb/index.html#/iplb for an up to date list +3. set_real_ip_from 10.108.0.0/16; +4. real_ip_header X-Forwarded-For; ``` -### X-Forwarded-Proto -You can also get the scheme used by your client to reach OVH Load Balancer. This is helpful to redirect **HTTP** to **HTTPS** +- Then enable the new configuration with: + +```bash +service nginx reload +``` + +#### Redirecting HTTP visitors to HTTPS + +To enhance security, some content such as login pages, can be restricted to the HTTPS protocol. Some sites even choose to systematically redirect all visits to the HTTPS version. By default, the HTTP and HTTPS protocols use different ports (80 and 443 respectively), so the classic solution is to place the redirection rules directly in the *vhost* dedicated to HTTP. + +When a request goes through a service like the OVHcloud Load Balancer, it handles the reception of HTTP traffic, the decryption of HTTPS traffic and forwards both types of traffic to your servers. Depending on your server configuration, all traffic will be propagated in HTTP or HTTPS, without distinction of the incoming protocol on the Load Balancer. Your server can no longer differentiate the two, as both arrive at the same point. This process is called **SSL Termination**. + +This is why the OVHcloud Load Balancer service automatically adds a header `X-Forwarded-Proto` which indicates the name of the original protocol, either "http" or "https". + +Like `X-Forwarded-For`, this header can be forged by a malicious visitor to make an insecure request appear to come from your OVHcloud Load Balancer service, in HTTPS. It is crucial to trust this header only if it is proven to come from your OVHcloud Load Balancer service. #### Apache -With htaccess, you can redirect your customers in HTTPS. -```htaccess +- Insert the following configuration in your site's `.htaccess` file: + +```apache 1. RewriteEngine on -2. RewriteCond %{HTTP:X_Forwarded_Proto} !https +2. RewriteCond %{HTTP:X-Forwarded-Proto} !https 3. RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] ``` -#### Nginx -This is not a good configuration, you'll reduce your service performance. +- Then enable the new configuration with: ```bash -if ($http_x_forwarded_proto = "http") { - return 301 https://$host/$request_uri; -} +service apache2 reload ``` -#### Nginx (best) -With Nginx, it's best to use a entire VHost to redirect HTTP to HTTPS. +#### Nginx + +- Insert the following configuration in the `server {` section of your site: + +```nginx +1. if ($http_x_forwarded_proto = "http") { +2.         return 301 https://$host/$request_uri; +3. } +``` + +- Then enable the new configuration with: ```bash -server { - listen [::]:80 default_server; - listen 80 default_server; - server_name _; - root /var/www/; - location / { - return 301 https://$server_name$request_uri; - } -} +service nginx reload ``` -### Send headers to PHP +### Passing headers to PHP -#### Apache +PHP uses the `REMOTE_ADDR` header to determine the address of the visitors. This header is automatically configured as soon as the configuration detailed in the section "[Correcting the source IP in the logs](#ip-source-logs)" is applied. -```apache -1. Header set REMOTE_ADDR %{HTTP:X_Forwarded_Proto} -``` +### Adding custom headers -#### Nginx -With RealIP module. +Whether your application requires a specific header format to identify the visitor's IP, port or protocol, or you want to know which *frontend* a request arrived through (or for any other reason), you can add custom headers on your HTTP *frontend*. -```nginx -1. real_ip_header X-Forwarded-For; -2. set_real_ip_from 10.108.0.0/14; +Custom headers must follow the format "X-Header Header Value". The header name and its value are separated by a space. It is possible to specify several headers on the same *frontend*. + +If an existing header is present in the request, it will be overwritten and replaced by the new value, making it impossible for the visitor passing through this *frontend* to forge it. It is not possible to redefine headers reserved for proxies, such as those described in this document, as they are automatically managed by your OVHcloud Load Balancer service. + +When specifying a non-standard header name, it is customary to prefix it with "X-". + +The use of variables in the header values is supported: + +- `%ci` will be replaced by the visitor's IP address. +- `%cp` will be replaced by the visitor's source port. + +Custom headers can be configured via the OVHcloud Control Panel and the API, whether on a new *frontend* or an existing *frontend*. + +#### From the OVHcloud Control Panel + +Go to the `Frontends`{.action} tab in the dashboard of your OVHcloud Load Balancer service and select the *frontend* to edit or click on the `Add a frontend`{.action} button to create a new one. An editing window will appear, displaying an `HTTP Header`{.action} field in the `Advanced Settings`{.action} section. + +If you want to configure multiple headers, they must be separated by commas, *without spaces*. For example, you can define the following headers: `X-Ip-Header %ci,X-Port-Header %cp`. + +![Configuration of HTTP headers of a Frontend via ovh manager API](images/add_headers.png){.thumbnail} + +Click on the `Update`{.action} button after configuring the headers, then on `Deploy zone: YOUR ZONE`{.action} to apply the changes in the concerned zone. + +### From the OVHcloud API + +In the API, the headers are specified within an `httpHeader` list. Unlike the OVHcloud Control Panel, each header must be its own entry in the list. + +In the OVHcloud API console, a `+`{.action} button is available as soon as you start to specify a value, allowing you to add a new field to the list. + +![Configuration of HTTP headers of a Frontend](images/add_headers_with_api.png){.thumbnail} + +If you integrate the API into your code, this corresponds to a JSON list of the type: + +```json +1. { +2.         "httpHeader": [ +3.                 "X-Ip-Header %ci", +4.                 "X-Port-Header %cp" +5.         ] +6. } ``` + +- Modification of an existing `Frontend`{.action} : + +> [!api] +> +> @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} +> + +|Parameter|Meaning| +|---------|-------------| +|serviceName|Name of the Load Balancer service concerned| +|frontendId|Identifier of the frontend where to configure the HTTP headers| +|httpHeader|List of headers to configure| + +- Applying the changes: + +> [!api] +> +> @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/refresh +> + +|Parameter|Meaning| +|---------|-------------| +|serviceName|Name of the Load Balancer service concerned| +|zone|Name of the zone in which to deploy the configuration| + +## Go further + +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_headers/guide.en-sg.md b/pages/network/load_balancer/create_headers/guide.en-sg.md index 75cecc048dc..aa8adb97bd7 100644 --- a/pages/network/load_balancer/create_headers/guide.en-sg.md +++ b/pages/network/load_balancer/create_headers/guide.en-sg.md @@ -1,97 +1,255 @@ --- -title: OVH Load Balancer - HTTP Header -excerpt: Get HTTP Headers on your services behind OVH Load Balancer -updated: 2018-08-03 +title: "Configuration of an OVHcloud Load Balancer service - HTTP headers" +excerpt: Integrate your web services behind a Load Balancer with HTTP headers +updated: 2025-11-12 --- -## Introduction -With any frontend service like CDN, IP Loadbalancing in front of your services, the IP of your clients is hidden by this service. +## Objective -In your log, you'll only see privateIP, and we'll fix this. +The OVHcloud Load Balancer service acts as a proxy. Like a human proxy, it serves as an intermediary: the client addresses the proxy, which in turn contacts the service provider on behalf of the client. In this configuration, **only the proxy** has information about the **real client** (the visitor of your web service) and the **real service provider** (one of your servers). + +For the visitor, this configuration does not raise any issues. They do not need to know the specific server handling their request; it is an implementation detail. However, for legal and statistical reasons, it is **essential** that the final server knows the client's real IP address. By default, it only identifies the proxy, which is your OVHcloud Load Balancer service. To overcome this issue, your OVHcloud Load Balancer service **adds by default** the standard HTTP headers that allow you to retrieve this information in the case of an HTTP connection. For a TCP connection, other solutions such as the ProxyProtocol exist, but they are beyond the scope of this guide. + +**This guide presents the default headers, their function, how to use them on the most common servers, and how to customize them according to the requirements of your infrastructure.** + +This guide is specifically for you if you only find private IP addresses in your access logs (`access_log`). + +## Requirements + +- Have an [OVHcloud Load Balancer](/links/network/load-balancer) offer in your OVHcloud account. +- You must be logged in to your [OVHcloud Control Panel](/links/manager). +- Have a Web service installed and configured on your servers. +- Have an Nginx service installed and configured on your servers. + +## Instructions ```bash -10.108.0.15 - - [22/Mar/2017:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" -10.108.0.24 - - [22/Mar/2017:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" +10.108.0.15 - - [02/Fev/2022:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" +10.108.0.24 - - [02/Fev/2022/:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" ``` -## Avertissement -You need to restrict access to your webservices from our IP Loadbalancing. +### Legal obligations + +You may be required to keep logs and certain data related to traffic in accordance with the laws and regulations applicable to you. **It is your responsibility to comply with these obligations.** + +**As an example:** + +- [Article L34-1 of the Code of Posts and Electronic Communications](https://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT000006070987&idArticle=LEGIARTI000006465770&dateTexte=&categorieLien=cid) and [Decree No. 2006-358 of 24 March 2006 on the retention of electronic communication data](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000637071&dateTexte=20180110) require any natural or legal person providing a public electronic communications service to retain user identification data for the services provided, etc. ; +- [Law No. 2004-575 of 21 June 2004 on trust in the digital economy](https://www.legifrance.gouv.fr/affichTexteArticle.do?idArticle=JORFARTI000002457442&cidTexte=JORFTEXT000000801164) and [Decree No. 2011-219 of 25 February 2011](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000023646013&categorieLien=id) require, among other things, that persons whose activity consists of providing access to online public communication services retain, for each connection, data relating to the connection identifier, the start and end dates and times of the connection, etc. + +### Default headers + +By default, your OVHcloud Load Balancer service adds **five** standard HTTP headers to each request, allowing you to identify the visitor's IP address and port as well as the initial connection protocol of the visitor to your site. -With this api call you can get IP Range of our servers. +|Header|Description| +|---|---| +|X-Forwarded-For and X-Remote-Ip|IP address of the client, as seen by your OVHcloud Load Balancer.| +|X-Forwarded-Port and X-Remote-Port|Source port of the client, as seen by your OVHcloud Load Balancer.| +|X-Forwarded-Proto|Client protocol (HTTP or HTTPS), as seen by your OVHcloud Load Balancer.| + +> [!warning] +> The `X-Forwarded-*` fields can be manipulated by a malicious client, **so they should only be considered if they come from a trusted source.** +> +> It is therefore **essential** to restrict their use to trusted IP addresses, which are the output IP addresses of your OVHcloud Load Balancer service. Major web servers such as Nginx and Apache have modules that can handle this aspect of security and reliability. +> + +The list of your output IP addresses is available via the OVHcloud Control Panel and the OVHcloud API. + +#### From the OVHcloud Control Panel + +The list of IPv4 output addresses that may be used by your OVHcloud Load Balancer service is available on the homepage of your Load Balancer service under the heading "IPv4 output". + +![IPv4 output address of your OVHcloud Load Balancer service](images/iplb_service.png){.thumbnail} + +#### From the OVHcloud API + +- Retrieving the list of IP addresses used by your OVHcloud Load Balancer service: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/natIp > -If you accept proxy-headers (X-Forwarded-*) from anywhere, some request could bypass your security policies. -## Headers +### Correcting the source IP in the logs + +By default, Apache, Nginx and other web servers record the source IP address in their logs. When you use an OVHcloud Load Balancer in front of your website, the logs then only contain IP addresses of the form "10.108.a.b". These are the internal IP addresses used by the OVHcloud Load Balancer to contact you. + +When a request goes through your OVHcloud Load Balancer service, it records the visitor's IP address in the `X-Forwarded-For` and `X-Remote-Ip` headers. These two fields carry the same information, their names differ only for compatibility with most servers. -### X-Forwarded-For -This header have inside the Ip of your client. +To correct the IP addresses in the logs, one solution would be to modify the log format directive on your server to use one of these headers instead of the Load Balancer's IP address. Unfortunately, this approach is insufficient, as anyone can fill in this header, even without going through your OVHcloud Load Balancer. This manipulation would allow the visitor to impersonate someone else. Apart from the ethical aspect, this practice has legal, security and statistical implications that make its prevention essential. + +This is why the main web servers include specialized modules that allow you to precisely control the level of trust given to these headers based on: + +- The source IP address (must be exclusively that of your OVHcloud Load Balancer service!) +- The depth of the IP in the field. Indeed, each proxy (proxy, load balancer) adds the client's IP address to this field. + +The rest of this guide provides recommended configuration practices for the main web servers. #### Apache +- Create the file `/etc/apache2/conf-available/remoteip.conf`. +- Insert the following configuration: + ```apache -1. LogFormat "%{X-Forwarded-For}i-%h- %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" loadbalancing -2. CustomLog /chemin/fichier.log loadbalancing +1. # Trust X-Forwarded-For headers from the OVHcloud Load Balancer +2. # See https://www.ovh.com/manager/sunrise/iplb/index.html#/iplb for an up to date list +3. RemoteIPHeader X-Forwarded-For +4. RemoteIPInternalProxy 10.108.0.0/14 +``` + +- Then replace the variables `%h` with `%a` in the `LogFormat` directives of the Apache configuration. +- Finally, enable the new configuration with: + +```bash +# Enable the 'remoteip' module and configuration +a2enmod remoteip +a2enconf remoteip + +# Restart apache to load the new module ("reload" is enough if the module was already enabled) +service apache2 restart ``` #### Nginx +For Nginx, the approach is slightly simpler, but the principle remains the same as for Apache: only take into account the `X-Forwarded-For` field if it comes from your OVHcloud Load Balancer service. + +This configuration can be applied: + +- To all sites, by inserting the configuration in the `http {}` section; +- To a specific site, by inserting the configuration in the corresponding `server {}` section; +- To a specific URL, by inserting the configuration in the corresponding `location {}` section. +- Insert the configuration in the desired section(s) (`http {}` for a global configuration): + ```nginx -1. log_format "%{X-Forwarded-For}i-%h- %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" loadbalancing -2. access_log /chemin/fichier.log loadbalancing +1. # Trust X-Forwarded-For headers from the OVHcloud Load Balancer +2. # See https://www.ovh.com/manager/sunrise/iplb/index.html#/iplb for an up to date list +3. set_real_ip_from 10.108.0.0/16; +4. real_ip_header X-Forwarded-For; +``` + +- Then enable the new configuration with: + +```bash +service nginx reload ``` -### X-Forwarded-Proto -You can also get the scheme used by your client to reach OVH Load Balancer. This is helpful to redirect **HTTP** to **HTTPS** +#### Redirecting HTTP visitors to HTTPS + +To enhance security, some content such as login pages, can be restricted to the HTTPS protocol. Some sites even choose to systematically redirect all visits to the HTTPS version. By default, the HTTP and HTTPS protocols use different ports (80 and 443 respectively), so the classic solution is to place the redirection rules directly in the *vhost* dedicated to HTTP. + +When a request goes through a service like the OVHcloud Load Balancer, it handles the reception of HTTP traffic, the decryption of HTTPS traffic and forwards both types of traffic to your servers. Depending on your server configuration, all traffic will be propagated in HTTP or HTTPS, without distinction of the incoming protocol on the Load Balancer. Your server can no longer differentiate the two, as both arrive at the same point. This process is called **SSL Termination**. + +This is why the OVHcloud Load Balancer service automatically adds a header `X-Forwarded-Proto` which indicates the name of the original protocol, either "http" or "https". + +Like `X-Forwarded-For`, this header can be forged by a malicious visitor to make an insecure request appear to come from your OVHcloud Load Balancer service, in HTTPS. It is crucial to trust this header only if it is proven to come from your OVHcloud Load Balancer service. #### Apache -With htaccess, you can redirect your customers in HTTPS. -```htaccess +- Insert the following configuration in your site's `.htaccess` file: + +```apache 1. RewriteEngine on -2. RewriteCond %{HTTP:X_Forwarded_Proto} !https +2. RewriteCond %{HTTP:X-Forwarded-Proto} !https 3. RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] ``` -#### Nginx -This is not a good configuration, you'll reduce your service performance. +- Then enable the new configuration with: ```bash -if ($http_x_forwarded_proto = "http") { - return 301 https://$host/$request_uri; -} +service apache2 reload ``` -#### Nginx (best) -With Nginx, it's best to use a entire VHost to redirect HTTP to HTTPS. +#### Nginx + +- Insert the following configuration in the `server {` section of your site: + +```nginx +1. if ($http_x_forwarded_proto = "http") { +2.         return 301 https://$host/$request_uri; +3. } +``` + +- Then enable the new configuration with: ```bash -server { - listen [::]:80 default_server; - listen 80 default_server; - server_name _; - root /var/www/; - location / { - return 301 https://$server_name$request_uri; - } -} +service nginx reload ``` -### Send headers to PHP +### Passing headers to PHP -#### Apache +PHP uses the `REMOTE_ADDR` header to determine the address of the visitors. This header is automatically configured as soon as the configuration detailed in the section "[Correcting the source IP in the logs](#ip-source-logs)" is applied. -```apache -1. Header set REMOTE_ADDR %{HTTP:X_Forwarded_Proto} -``` +### Adding custom headers -#### Nginx -With RealIP module. +Whether your application requires a specific header format to identify the visitor's IP, port or protocol, or you want to know which *frontend* a request arrived through (or for any other reason), you can add custom headers on your HTTP *frontend*. -```nginx -1. real_ip_header X-Forwarded-For; -2. set_real_ip_from 10.108.0.0/14; +Custom headers must follow the format "X-Header Header Value". The header name and its value are separated by a space. It is possible to specify several headers on the same *frontend*. + +If an existing header is present in the request, it will be overwritten and replaced by the new value, making it impossible for the visitor passing through this *frontend* to forge it. It is not possible to redefine headers reserved for proxies, such as those described in this document, as they are automatically managed by your OVHcloud Load Balancer service. + +When specifying a non-standard header name, it is customary to prefix it with "X-". + +The use of variables in the header values is supported: + +- `%ci` will be replaced by the visitor's IP address. +- `%cp` will be replaced by the visitor's source port. + +Custom headers can be configured via the OVHcloud Control Panel and the API, whether on a new *frontend* or an existing *frontend*. + +#### From the OVHcloud Control Panel + +Go to the `Frontends`{.action} tab in the dashboard of your OVHcloud Load Balancer service and select the *frontend* to edit or click on the `Add a frontend`{.action} button to create a new one. An editing window will appear, displaying an `HTTP Header`{.action} field in the `Advanced Settings`{.action} section. + +If you want to configure multiple headers, they must be separated by commas, *without spaces*. For example, you can define the following headers: `X-Ip-Header %ci,X-Port-Header %cp`. + +![Configuration of HTTP headers of a Frontend via ovh manager API](images/add_headers.png){.thumbnail} + +Click on the `Update`{.action} button after configuring the headers, then on `Deploy zone: YOUR ZONE`{.action} to apply the changes in the concerned zone. + +### From the OVHcloud API + +In the API, the headers are specified within an `httpHeader` list. Unlike the OVHcloud Control Panel, each header must be its own entry in the list. + +In the OVHcloud API console, a `+`{.action} button is available as soon as you start to specify a value, allowing you to add a new field to the list. + +![Configuration of HTTP headers of a Frontend](images/add_headers_with_api.png){.thumbnail} + +If you integrate the API into your code, this corresponds to a JSON list of the type: + +```json +1. { +2.         "httpHeader": [ +3.                 "X-Ip-Header %ci", +4.                 "X-Port-Header %cp" +5.         ] +6. } ``` + +- Modification of an existing `Frontend`{.action} : + +> [!api] +> +> @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} +> + +|Parameter|Meaning| +|---------|-------------| +|serviceName|Name of the Load Balancer service concerned| +|frontendId|Identifier of the frontend where to configure the HTTP headers| +|httpHeader|List of headers to configure| + +- Applying the changes: + +> [!api] +> +> @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/refresh +> + +|Parameter|Meaning| +|---------|-------------| +|serviceName|Name of the Load Balancer service concerned| +|zone|Name of the zone in which to deploy the configuration| + +## Go further + +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_headers/guide.en-us.md b/pages/network/load_balancer/create_headers/guide.en-us.md index 75cecc048dc..aa8adb97bd7 100644 --- a/pages/network/load_balancer/create_headers/guide.en-us.md +++ b/pages/network/load_balancer/create_headers/guide.en-us.md @@ -1,97 +1,255 @@ --- -title: OVH Load Balancer - HTTP Header -excerpt: Get HTTP Headers on your services behind OVH Load Balancer -updated: 2018-08-03 +title: "Configuration of an OVHcloud Load Balancer service - HTTP headers" +excerpt: Integrate your web services behind a Load Balancer with HTTP headers +updated: 2025-11-12 --- -## Introduction -With any frontend service like CDN, IP Loadbalancing in front of your services, the IP of your clients is hidden by this service. +## Objective -In your log, you'll only see privateIP, and we'll fix this. +The OVHcloud Load Balancer service acts as a proxy. Like a human proxy, it serves as an intermediary: the client addresses the proxy, which in turn contacts the service provider on behalf of the client. In this configuration, **only the proxy** has information about the **real client** (the visitor of your web service) and the **real service provider** (one of your servers). + +For the visitor, this configuration does not raise any issues. They do not need to know the specific server handling their request; it is an implementation detail. However, for legal and statistical reasons, it is **essential** that the final server knows the client's real IP address. By default, it only identifies the proxy, which is your OVHcloud Load Balancer service. To overcome this issue, your OVHcloud Load Balancer service **adds by default** the standard HTTP headers that allow you to retrieve this information in the case of an HTTP connection. For a TCP connection, other solutions such as the ProxyProtocol exist, but they are beyond the scope of this guide. + +**This guide presents the default headers, their function, how to use them on the most common servers, and how to customize them according to the requirements of your infrastructure.** + +This guide is specifically for you if you only find private IP addresses in your access logs (`access_log`). + +## Requirements + +- Have an [OVHcloud Load Balancer](/links/network/load-balancer) offer in your OVHcloud account. +- You must be logged in to your [OVHcloud Control Panel](/links/manager). +- Have a Web service installed and configured on your servers. +- Have an Nginx service installed and configured on your servers. + +## Instructions ```bash -10.108.0.15 - - [22/Mar/2017:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" -10.108.0.24 - - [22/Mar/2017:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" +10.108.0.15 - - [02/Fev/2022:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" +10.108.0.24 - - [02/Fev/2022/:10:56:47 +0100] "GET / HTTP/1.1" 200 706 "-" "Mozilla/5.0 (Linux[...]" ``` -## Avertissement -You need to restrict access to your webservices from our IP Loadbalancing. +### Legal obligations + +You may be required to keep logs and certain data related to traffic in accordance with the laws and regulations applicable to you. **It is your responsibility to comply with these obligations.** + +**As an example:** + +- [Article L34-1 of the Code of Posts and Electronic Communications](https://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT000006070987&idArticle=LEGIARTI000006465770&dateTexte=&categorieLien=cid) and [Decree No. 2006-358 of 24 March 2006 on the retention of electronic communication data](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000637071&dateTexte=20180110) require any natural or legal person providing a public electronic communications service to retain user identification data for the services provided, etc. ; +- [Law No. 2004-575 of 21 June 2004 on trust in the digital economy](https://www.legifrance.gouv.fr/affichTexteArticle.do?idArticle=JORFARTI000002457442&cidTexte=JORFTEXT000000801164) and [Decree No. 2011-219 of 25 February 2011](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000023646013&categorieLien=id) require, among other things, that persons whose activity consists of providing access to online public communication services retain, for each connection, data relating to the connection identifier, the start and end dates and times of the connection, etc. + +### Default headers + +By default, your OVHcloud Load Balancer service adds **five** standard HTTP headers to each request, allowing you to identify the visitor's IP address and port as well as the initial connection protocol of the visitor to your site. -With this api call you can get IP Range of our servers. +|Header|Description| +|---|---| +|X-Forwarded-For and X-Remote-Ip|IP address of the client, as seen by your OVHcloud Load Balancer.| +|X-Forwarded-Port and X-Remote-Port|Source port of the client, as seen by your OVHcloud Load Balancer.| +|X-Forwarded-Proto|Client protocol (HTTP or HTTPS), as seen by your OVHcloud Load Balancer.| + +> [!warning] +> The `X-Forwarded-*` fields can be manipulated by a malicious client, **so they should only be considered if they come from a trusted source.** +> +> It is therefore **essential** to restrict their use to trusted IP addresses, which are the output IP addresses of your OVHcloud Load Balancer service. Major web servers such as Nginx and Apache have modules that can handle this aspect of security and reliability. +> + +The list of your output IP addresses is available via the OVHcloud Control Panel and the OVHcloud API. + +#### From the OVHcloud Control Panel + +The list of IPv4 output addresses that may be used by your OVHcloud Load Balancer service is available on the homepage of your Load Balancer service under the heading "IPv4 output". + +![IPv4 output address of your OVHcloud Load Balancer service](images/iplb_service.png){.thumbnail} + +#### From the OVHcloud API + +- Retrieving the list of IP addresses used by your OVHcloud Load Balancer service: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/natIp > -If you accept proxy-headers (X-Forwarded-*) from anywhere, some request could bypass your security policies. -## Headers +### Correcting the source IP in the logs + +By default, Apache, Nginx and other web servers record the source IP address in their logs. When you use an OVHcloud Load Balancer in front of your website, the logs then only contain IP addresses of the form "10.108.a.b". These are the internal IP addresses used by the OVHcloud Load Balancer to contact you. + +When a request goes through your OVHcloud Load Balancer service, it records the visitor's IP address in the `X-Forwarded-For` and `X-Remote-Ip` headers. These two fields carry the same information, their names differ only for compatibility with most servers. -### X-Forwarded-For -This header have inside the Ip of your client. +To correct the IP addresses in the logs, one solution would be to modify the log format directive on your server to use one of these headers instead of the Load Balancer's IP address. Unfortunately, this approach is insufficient, as anyone can fill in this header, even without going through your OVHcloud Load Balancer. This manipulation would allow the visitor to impersonate someone else. Apart from the ethical aspect, this practice has legal, security and statistical implications that make its prevention essential. + +This is why the main web servers include specialized modules that allow you to precisely control the level of trust given to these headers based on: + +- The source IP address (must be exclusively that of your OVHcloud Load Balancer service!) +- The depth of the IP in the field. Indeed, each proxy (proxy, load balancer) adds the client's IP address to this field. + +The rest of this guide provides recommended configuration practices for the main web servers. #### Apache +- Create the file `/etc/apache2/conf-available/remoteip.conf`. +- Insert the following configuration: + ```apache -1. LogFormat "%{X-Forwarded-For}i-%h- %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" loadbalancing -2. CustomLog /chemin/fichier.log loadbalancing +1. # Trust X-Forwarded-For headers from the OVHcloud Load Balancer +2. # See https://www.ovh.com/manager/sunrise/iplb/index.html#/iplb for an up to date list +3. RemoteIPHeader X-Forwarded-For +4. RemoteIPInternalProxy 10.108.0.0/14 +``` + +- Then replace the variables `%h` with `%a` in the `LogFormat` directives of the Apache configuration. +- Finally, enable the new configuration with: + +```bash +# Enable the 'remoteip' module and configuration +a2enmod remoteip +a2enconf remoteip + +# Restart apache to load the new module ("reload" is enough if the module was already enabled) +service apache2 restart ``` #### Nginx +For Nginx, the approach is slightly simpler, but the principle remains the same as for Apache: only take into account the `X-Forwarded-For` field if it comes from your OVHcloud Load Balancer service. + +This configuration can be applied: + +- To all sites, by inserting the configuration in the `http {}` section; +- To a specific site, by inserting the configuration in the corresponding `server {}` section; +- To a specific URL, by inserting the configuration in the corresponding `location {}` section. +- Insert the configuration in the desired section(s) (`http {}` for a global configuration): + ```nginx -1. log_format "%{X-Forwarded-For}i-%h- %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" loadbalancing -2. access_log /chemin/fichier.log loadbalancing +1. # Trust X-Forwarded-For headers from the OVHcloud Load Balancer +2. # See https://www.ovh.com/manager/sunrise/iplb/index.html#/iplb for an up to date list +3. set_real_ip_from 10.108.0.0/16; +4. real_ip_header X-Forwarded-For; +``` + +- Then enable the new configuration with: + +```bash +service nginx reload ``` -### X-Forwarded-Proto -You can also get the scheme used by your client to reach OVH Load Balancer. This is helpful to redirect **HTTP** to **HTTPS** +#### Redirecting HTTP visitors to HTTPS + +To enhance security, some content such as login pages, can be restricted to the HTTPS protocol. Some sites even choose to systematically redirect all visits to the HTTPS version. By default, the HTTP and HTTPS protocols use different ports (80 and 443 respectively), so the classic solution is to place the redirection rules directly in the *vhost* dedicated to HTTP. + +When a request goes through a service like the OVHcloud Load Balancer, it handles the reception of HTTP traffic, the decryption of HTTPS traffic and forwards both types of traffic to your servers. Depending on your server configuration, all traffic will be propagated in HTTP or HTTPS, without distinction of the incoming protocol on the Load Balancer. Your server can no longer differentiate the two, as both arrive at the same point. This process is called **SSL Termination**. + +This is why the OVHcloud Load Balancer service automatically adds a header `X-Forwarded-Proto` which indicates the name of the original protocol, either "http" or "https". + +Like `X-Forwarded-For`, this header can be forged by a malicious visitor to make an insecure request appear to come from your OVHcloud Load Balancer service, in HTTPS. It is crucial to trust this header only if it is proven to come from your OVHcloud Load Balancer service. #### Apache -With htaccess, you can redirect your customers in HTTPS. -```htaccess +- Insert the following configuration in your site's `.htaccess` file: + +```apache 1. RewriteEngine on -2. RewriteCond %{HTTP:X_Forwarded_Proto} !https +2. RewriteCond %{HTTP:X-Forwarded-Proto} !https 3. RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] ``` -#### Nginx -This is not a good configuration, you'll reduce your service performance. +- Then enable the new configuration with: ```bash -if ($http_x_forwarded_proto = "http") { - return 301 https://$host/$request_uri; -} +service apache2 reload ``` -#### Nginx (best) -With Nginx, it's best to use a entire VHost to redirect HTTP to HTTPS. +#### Nginx + +- Insert the following configuration in the `server {` section of your site: + +```nginx +1. if ($http_x_forwarded_proto = "http") { +2.         return 301 https://$host/$request_uri; +3. } +``` + +- Then enable the new configuration with: ```bash -server { - listen [::]:80 default_server; - listen 80 default_server; - server_name _; - root /var/www/; - location / { - return 301 https://$server_name$request_uri; - } -} +service nginx reload ``` -### Send headers to PHP +### Passing headers to PHP -#### Apache +PHP uses the `REMOTE_ADDR` header to determine the address of the visitors. This header is automatically configured as soon as the configuration detailed in the section "[Correcting the source IP in the logs](#ip-source-logs)" is applied. -```apache -1. Header set REMOTE_ADDR %{HTTP:X_Forwarded_Proto} -``` +### Adding custom headers -#### Nginx -With RealIP module. +Whether your application requires a specific header format to identify the visitor's IP, port or protocol, or you want to know which *frontend* a request arrived through (or for any other reason), you can add custom headers on your HTTP *frontend*. -```nginx -1. real_ip_header X-Forwarded-For; -2. set_real_ip_from 10.108.0.0/14; +Custom headers must follow the format "X-Header Header Value". The header name and its value are separated by a space. It is possible to specify several headers on the same *frontend*. + +If an existing header is present in the request, it will be overwritten and replaced by the new value, making it impossible for the visitor passing through this *frontend* to forge it. It is not possible to redefine headers reserved for proxies, such as those described in this document, as they are automatically managed by your OVHcloud Load Balancer service. + +When specifying a non-standard header name, it is customary to prefix it with "X-". + +The use of variables in the header values is supported: + +- `%ci` will be replaced by the visitor's IP address. +- `%cp` will be replaced by the visitor's source port. + +Custom headers can be configured via the OVHcloud Control Panel and the API, whether on a new *frontend* or an existing *frontend*. + +#### From the OVHcloud Control Panel + +Go to the `Frontends`{.action} tab in the dashboard of your OVHcloud Load Balancer service and select the *frontend* to edit or click on the `Add a frontend`{.action} button to create a new one. An editing window will appear, displaying an `HTTP Header`{.action} field in the `Advanced Settings`{.action} section. + +If you want to configure multiple headers, they must be separated by commas, *without spaces*. For example, you can define the following headers: `X-Ip-Header %ci,X-Port-Header %cp`. + +![Configuration of HTTP headers of a Frontend via ovh manager API](images/add_headers.png){.thumbnail} + +Click on the `Update`{.action} button after configuring the headers, then on `Deploy zone: YOUR ZONE`{.action} to apply the changes in the concerned zone. + +### From the OVHcloud API + +In the API, the headers are specified within an `httpHeader` list. Unlike the OVHcloud Control Panel, each header must be its own entry in the list. + +In the OVHcloud API console, a `+`{.action} button is available as soon as you start to specify a value, allowing you to add a new field to the list. + +![Configuration of HTTP headers of a Frontend](images/add_headers_with_api.png){.thumbnail} + +If you integrate the API into your code, this corresponds to a JSON list of the type: + +```json +1. { +2.         "httpHeader": [ +3.                 "X-Ip-Header %ci", +4.                 "X-Port-Header %cp" +5.         ] +6. } ``` + +- Modification of an existing `Frontend`{.action} : + +> [!api] +> +> @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} +> + +|Parameter|Meaning| +|---------|-------------| +|serviceName|Name of the Load Balancer service concerned| +|frontendId|Identifier of the frontend where to configure the HTTP headers| +|httpHeader|List of headers to configure| + +- Applying the changes: + +> [!api] +> +> @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/refresh +> + +|Parameter|Meaning| +|---------|-------------| +|serviceName|Name of the Load Balancer service concerned| +|zone|Name of the zone in which to deploy the configuration| + +## Go further + +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_headers/guide.fr-ca.md b/pages/network/load_balancer/create_headers/guide.fr-ca.md index 8db8f01c049..d678ae59fcc 100644 --- a/pages/network/load_balancer/create_headers/guide.fr-ca.md +++ b/pages/network/load_balancer/create_headers/guide.fr-ca.md @@ -1,27 +1,27 @@ --- title: "Configuration d'un service OVHcloud Load Balancer - Les en-têtes HTTP" excerpt: Intégrez vos services web derrière un Load Balancer avec les en-têtes HTTP -updated: 2022-07-27 +updated: 2025-11-12 --- ## Objectif -Le service OVHcloud Load Balancer agit comme un mandataire ou "Proxy". Comme un mandataire humain, il agit comme un intermédiaire, de telle sorte que le client s'adresse au mandataire et le mandataire au fournisseur de service, au nom du client. Dans cette configuration, seul le mandataire connait à la fois le véritable client (le visiteur de votre service web) et le véritable fournisseur de service (l'un de vos serveurs). +Le service OVHcloud Load Balancer agit en tant que mandataire ou « Proxy ». À l'instar d'un mandataire humain, il fait office d'intermédiaire : le client s'adresse au mandataire qui, à son tour, contacte le fournisseur de service au nom du client. Dans cette configuration, **seul le mandataire** est en possession des informations concernant le **véritable client** (le visiteur de votre service web) et le **véritable fournisseur de service** (l'un de vos serveurs). -Pour le visiteur, cela ne pose aucun souci. Il n'a pas besoin de connaître avec précision le serveur qui répond à sa requête. C'est un détail d'implémentation. En revanche, pour des raisons à la fois légales et de statistiques, il est indispensable que le serveur final ait connaissance de la véritable adresse du client. Or, par défaut, il ne voit que le mandataire (en l'occurence, votre service OVHcloud Load Balancer). +Pour le visiteur, cette configuration ne soulève aucune difficulté. Il n'a pas besoin de connaître le serveur précis qui traite sa requête ; il s'agit d'un détail d'implémentation. En revanche, pour des raisons à la fois légales et statistiques, il est **impératif** que le serveur final ait connaissance de l'adresse réelle du client. Or, par défaut, il n'identifie que le mandataire, en l'occurrence votre service OVHcloud Load Balancer. -Pour palier à cela, votre service OVHcloud Load Balancer ajoute par défaut les en-têtes HTTP standards permettant de retrouver ces informations dans le cas d'une connexion HTTP. Dans le cas d'une connexion TCP, d'autres solutions existent telles que le ProxyProtocol, mais cela sort du cadre de ce guide. +Afin de pallier cet inconvénient, votre service OVHcloud Load Balancer **ajoute par défaut** les en-têtes HTTP standards qui permettent de retrouver ces informations dans le cas d'une connexion HTTP. Pour une connexion TCP, d'autres solutions telles que le ProxyProtocol existent, mais elles dépassent le cadre de ce guide. -**Ce guide présente les en-têtes par défaut, leur rôle, comment les exploiter depuis les serveurs les plus courants et comment les personnaliser en fonction des contraintes de votre infrastructure.** +**Ce guide présente les en-têtes par défaut, leur fonction, la manière de les exploiter sur les serveurs les plus courants et comment les personnaliser en fonction des exigences de votre infrastructure.** -Si vous retrouvez uniquement des IP privées dans vos acces_log, ce guide est fait pour vous. +Ce guide s'adresse spécifiquement à vous si vous ne retrouvez que des adresses IP privées dans vos journaux d'accès (`access_log`). ## Prérequis -- Posséder une offre [OVHcloud Load balancer](https://www.ovh.com/ca/fr/solutions/load-balancer/) dans votre compte OVHcloud. +- Posséder une offre [OVHcloud Load balancer](/links/network/load-balancer) dans votre compte OVHcloud. - Être connecté à votre [espace client OVHcloud](/links/manager). -- Posséder un service Web installé et configuré sur vos serveurs -- Posséder un service Nginx installé et configuré sur vos serveurs +- Posséder un service Web installé et configuré sur vos serveurs. +- Posséder un service Nginx installé et configuré sur vos serveurs. ## En pratique @@ -32,64 +32,64 @@ Si vous retrouvez uniquement des IP privées dans vos acces_log, ce guide est fa ### Obligations légales -Vous pouvez être tenu de conserver des logs et certaines données relatives au trafic en vertu des lois et règlementations vous étant applicables. Il vous incombe de respecter ces obligations. +Il se peut que vous soyez tenu de conserver des journaux et certaines données relatives au trafic en vertu des lois et réglementations qui vous sont applicables. **Il vous incombe de vous conformer à ces obligations.** -**A titre d’exemple :** +**À titre d'exemple :** -- [L’article L34-1 du Code des postes et des communications électroniques](https://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT000006070987&idArticle=LEGIARTI000006465770&dateTexte=&categorieLien=cid) ainsi que le [décret n°2006-358 du 24 mars 2006 relatif à la conservation des données des communications électroniques](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000637071&dateTexte=20180110) imposent notamment à toute personne physique ou morale fournissant au public un service de communications électroniques de conserver des données d'identification des personnes utilisatrices des services fournis, etc. ; -- La [loi n° 2004-575 du 21 juin 2004 pour la confiance dans l'économie numérique](https://www.legifrance.gouv.fr/affichTexteArticle.do?idArticle=JORFARTI000002457442&cidTexte=JORFTEXT000000801164) et le [décret n° 2011-219 du 25 février 2011](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000023646013&categorieLien=id) imposent notamment aux personnes dont l’activité est d’offrir un accès à des services de communication au public en ligne de conserver pour chaque connexion les données relatives à l’identifiant de la connexion, les dates et heure de début et de fin de la connexion, etc. +- [L'article L34-1 du Code des postes et des communications électroniques](https://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT000006070987&idArticle=LEGIARTI000006465770&dateTexte=&categorieLien=cid) ainsi que le [décret n°2006-358 du 24 mars 2006 relatif à la conservation des données des communications électroniques](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000637071&dateTexte=20180110) imposent notamment à toute personne physique ou morale fournissant un service de communications électroniques au public de conserver les données d'identification des utilisateurs des services fournis, etc. ; +- La [loi n° 2004-575 du 21 juin 2004 pour la confiance dans l'économie numérique](https://www.legifrance.gouv.fr/affichTexteArticle.do?idArticle=JORFARTI000002457442&cidTexte=JORFTEXT000000801164) et le [décret n° 2011-219 du 25 février 2011](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000023646013&categorieLien=id) exigent notamment des personnes dont l'activité consiste à offrir un accès à des services de communication au public en ligne de conserver, pour chaque connexion, les données relatives à l'identifiant de la connexion, les dates et heures de début et de fin de la connexion, etc. -### En-tetes par defaut +### En-têtes par défaut -Par défaut, votre service OVHcloud Load Balancer ajoute à chaque requête HTTP 5 des en-têtes standard permettant de connaître l'adresse et le port du visiteur de votre site ainsi que le protocole de connexion. +Par défaut, votre service OVHcloud Load Balancer ajoute **cinq** en-têtes HTTP standards à chaque requête, permettant d'identifier l'adresse et le port du visiteur de votre site ainsi que le protocole de connexion initial. |En-tête|Description| |---|---| -|X-Forwarded-For et X-Remote-Ip|Adresse du client, telle que vue par votre OVHcloud Load Balancer.| +|X-Forwarded-For et X-Remote-Ip|Adresse IP du client, telle que vue par votre OVHcloud Load Balancer.| |X-Forwarded-Port et X-Remote-Port|Port source du client, tel que vu par votre OVHcloud Load Balancer.| |X-Forwarded-Proto|Protocole du client (HTTP ou HTTPS), tel que vu par votre OVHcloud Load Balancer.| > [!warning] ->Les champs X-Fowarded-* pouvant être forgés par un client malicieux, ils ne doivent être pris en compte que s’ils viennent d’une source de confiance. +> Les champs `X-Forwarded-*` pouvant être manipulés par un client malveillant, **ils ne doivent être pris en compte que s'ils proviennent d'une source de confiance.** > ->Il est donc indispensable de limiter leur utilisation à des adresses IP de confiance, en l'occurence les adresses IP de sortie de votre service OVHcloud Load Balancer. Les principaux serveurs tels que Nginx et Apache disposent de modules capable de gérer cet aspect de sécurité et confiance. +> Il est donc **essentiel** de restreindre leur utilisation aux adresses IP de confiance, qui sont en l'occurrence les adresses IP de sortie de votre service OVHcloud Load Balancer. Les principaux serveurs web tels que Nginx et Apache disposent de modules capables de gérer cet aspect de sécurité et de fiabilité. > -Vous pouvez obtenir la liste de vos adresse IP de sortie depuis l'espace client OVHcloud et via l'API OVHcloud. +La liste de vos adresses IP de sortie est disponible via l'espace client OVHcloud et l'API OVHcloud. #### Depuis l'espace client OVHcloud -La liste des IPv4 de sortie potentiellement utilisées par votre service OVHcloud Load Balancer se trouve sur la page d'accueil de votre service OVHcloud Load Balancer sous le nom « IPv4 de sortie ». +La liste des adresses IPv4 de sortie susceptibles d'être utilisées par votre service OVHcloud Load Balancer est accessible sur la page d'accueil de votre service Load Balancer. Dans le cadre **Informations**, cliquez sur le bouton `...`{.action} à droite de la mention **IPv4 de sortie** et sélectionnez `Consulter`{.action}. ![Adresse IPv4 de sortie de votre service OVHcloud Load Balancer](images/iplb_service.png){.thumbnail} #### Depuis l'API OVHcloud -- Liste des adresses IP utilisées par votre service OVHcloud Load Balancer : +Récupération de la liste des adresses IP utilisées par votre service OVHcloud Load Balancer : > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/natIp > -### Correction de l'IP source dans les logs +### Correction de l'adresse IP source dans les logs -Par défaut, Apache, Nginx et les autres serveurs web prennent en compte l'adresse IP source dans les logs. Quand vous utilisez un OVHcloud Load Balancer en amont de votre site web, les logs ne contiennent alors plus que des adresses IPs qui ressemblent à « 10.108.a.b ». Ce sont les adresses IP utilisées par l'OVHcloud Load Balancer pour vous contacter. +Par défaut, Apache, Nginx et les autres serveurs web enregistrent l'adresse IP source dans leurs journaux. Lorsque vous utilisez un service OVHcloud Load Balancer en amont de votre site web, les logs ne contiennent alors que des adresses IP de la forme « 10.108.a.b ». Il s'agit des adresses IP internes utilisées par le service OVHcloud Load Balancer pour vous contacter. -Lorsque la requête passe par votre service OVHcloud Load Balancer, celui-ci enregistre l'adresse IP de votre visiteur dans les en-têtes X-Forwarded-For et X-Remote-Ip. Ils contiennent la même information. Seul le nom change pour des raisons de compatibilité avec la majorité des serveurs. +Lorsqu'une requête transite par votre service OVHcloud Load Balancer, celui-ci enregistre l'adresse IP de votre visiteur dans les en-têtes `X-Forwarded-For` et `X-Remote-Ip`. Ces deux champs contiennent la même information, leur nom diffère uniquement pour des raisons de compatibilité avec la majorité des serveurs. -Pour corriger les adresses IP dans les logs, la solution évidente serait de modifier la directive de format de logs de votre serveur pour utiliser l'un de ces en-têtes en lieu et place de l'IP du Load Balancer. Malheureusement, cela ne suffit pas car n'importe qui peut renseigner ces en-tête, même s'il ne passe pas par votre OVHcloud Load Balancer. Et cela lui permettrait de se faire passer pour quelqu'un d'autre. En dehors de l'aspect éthique de cette pratique, il y a également des implications légales, de sécurité et de statistiques pour lesquelles cela ne doit pas se produire. +Pour corriger les adresses IP dans les logs, une solution pourrait être de modifier la directive de format de logs de votre serveur pour utiliser l'un de ces en-têtes à la place de l'adresse IP du Load Balancer. Malheureusement, cette approche est insuffisante, car n'importe qui peut renseigner cet en-tête, même sans passer par votre service OVHcloud Load Balancer. Une telle manipulation permettrait au visiteur de se faire passer pour quelqu'un d'autre. Outre l'aspect éthique, cette pratique a des implications légales de sécurité et de statistiques, qui rendent sa prévention indispensable. -Pour cette raison, les principaux serveurs web disposent de modules spécialisées permettant de contrôler exactement le niveau de confiance à accorder à ces en-têtes en fonction de +C'est pourquoi les principaux serveurs web intègrent des modules spécialisés permettant de contrôler avec précision le niveau de confiance accordé à ces en-têtes en se basant sur : -- L'adresse IP source (seulement celle de votre service OVHcloud Load Balancer !) -- Le niveau de profondeur de l'IP dans le champ. En effet, chaque mandataire (proxy, load balancer) ajoute l'IP de son client dans ce champ. +- l'adresse IP source (doit être exclusivement celle de votre service OVHcloud Load Balancer !) ; +- le niveau de profondeur de l'adresse IP dans le champ. En effet, chaque mandataire (proxy, load balancer) ajoute l'adresse IP de son client dans ce champ. -La suite de ce guide vous propose quelques bonnes pratiques de configuration pour les principaux serveurs webs. +La suite de ce guide propose des pratiques de configuration recommandées pour les principaux serveurs web. #### Apache -- Créez le fichier `/etc/apache2/conf-available/remoteip.conf` +- Créez le fichier `/etc/apache2/conf-available/remoteip.conf`. - Insérez la configuration suivante : ```apache @@ -99,7 +99,7 @@ La suite de ce guide vous propose quelques bonnes pratiques de configuration pou 4. RemoteIPInternalProxy 10.108.0.0/14 ``` -- Remplacez les variables `%h` par `%a` dans les directives `LogFormat` de la configuration Apache +- Remplacez les variables `%h` par `%a` dans les directives `LogFormat` de la configuration Apache. - Enfin, activez la nouvelle configuration avec : ```bash @@ -113,14 +113,14 @@ service apache2 restart #### Nginx -Pour Nginx, c'est un peu plus simple mais l'idée reste la même que pour Apache en ne prenant en compte le champ X-Forwarded-For que s'il vient de votre service OVHcloud Load Balancer. +Pour Nginx, l'approche est légèrement plus simple, mais le principe demeure identique à celui d'Apache : ne prendre en compte le champ `X-Forwarded-For` que s'il provient de votre service OVHcloud Load Balancer. -Cette configuration peut être effectuée soit : +Cette configuration peut être appliquée : -- pour l'ensemble des sites en insérant la configuration dans la section `http {}` -- pour un site en particulier en insérant la configuration dans la section `server {}` correspondante -- pour une URL en particulier en insérant la configuration dans la section `location {}` correspondante -- Insérez la configuration dans la ou les sections voulue (`http {}` pour une configuration globale) : +- à l'ensemble des sites, en insérant la configuration dans la section `http {}` ; +- à un site en particulier, en insérant la configuration dans la section `server {}` correspondante ; +- à une URL spécifique, en insérant la configuration dans la section `location {}` correspondante. +- Insérez la configuration dans la ou les sections souhaitées (`http {}` pour une configuration globale) : ```nginx 1. # Trust X-Forwarded-For headers from the OVHcloud Load Balancer @@ -137,39 +137,39 @@ service nginx reload #### Redirection des visiteurs HTTP vers HTTPS -Pour plus de sécurité, certains contenus tels que les pages de connexion peuvent n'être disponible qu'en HTTPS. Certains sites vont même plus loin en redirigeant systématiquement toutes les visites vers la version HTTPS du site. Par défaut, comme les 2 protocoles HTTP et HTTPS passent par des ports différents, respectivement le 80 et le 443, la solution consiste à mettre les règles de redirections directement dans le vhost correspondant au HTTP. +Pour renforcer la sécurité, certains contenus, tels que les pages de connexion, peuvent être restreints au protocole HTTPS. Certains sites optent même pour la redirection systématique de toutes les visites vers la version HTTPS. Par défaut, les protocoles HTTP et HTTPS utilisent des ports différents (respectivement 80 et 443), la solution classique consiste à placer les règles de redirection directement dans le *vhost* dédié au HTTP. -Lorsque la requête passe par un service comme le service OVHcloud Load Balancer, celui-ci s'occupe de recevoir le trafic HTTP, déchiffrer le trafic HTTPS et les fait suivre tous les 2 vers vos serveurs. En fonction de la configuration de vos serveurs, l'ensemble du trafic sera propagé en HTTP ou en HTTPS, sans distinction de protocole d'entrée sur le Load Balancer. Votre serveur ne peut plus faire la différence entre les 2, puisque les 2 arrivent au même endroit. On parle de « Terminaison SSL ». +Lorsqu'une requête passe par un service comme le Load Balancer OVHcloud, celui-ci gère la réception du trafic HTTP, le déchiffrement du trafic HTTPS et transmet les deux types de trafic à vos serveurs. Selon la configuration de vos serveurs, l'ensemble du trafic sera propagé en HTTP ou en HTTPS, sans distinction du protocole d'entrée sur le Load Balancer. Votre serveur ne peut plus différencier les deux, car les deux arrivent au même point. Ce processus est appelé **« Terminaison SSL »**. -Pour cette raison, le service OVHcloud Load Balancer ajoute automatiquement un en-tête `X-Forwarded-Proto` qui contient le nom du protocole d'origine. En l'occurence « http » ou « https ». +C'est pourquoi le service OVHcloud Load Balancer ajoute automatiquement un en-tête `X-Forwarded-Proto` qui indique le nom du protocole d'origine, soit « http » ou « https ». -De même que `X-Forwarded-For`, cet en-tête peut être forgé par un visiteur malicieux pour faire croire qu'une requête non sécurisée proviendrait de votre service OVHcloud Load Balancer, en HTTPS. Il est essentiel de ne faire confiance à cet en-tête que s'il vient bien de votre service OVHcloud Load Balancer. +Tout comme `X-Forwarded-For`, cet en-tête peut être contrefait par un visiteur malveillant pour faire croire qu'une requête non sécurisée provient de votre service OVHcloud Load Balancer, en HTTPS. Il est crucial de ne se fier à cet en-tête que s'il est avéré qu'il provient de votre service OVHcloud Load Balancer. #### Apache -- Insérez la configuration suivante dans le fichier .hatccess de votre site : +- Insérez la configuration suivante dans le fichier `.htaccess` de votre site : -```apache -1. RewriteEngine on -2. RewriteCond %{HTTP:X-Forwarded-Proto} !https -3. RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] -``` + ```apache + 1. RewriteEngine on + 2. RewriteCond %{HTTP:X-Forwarded-Proto} !https + 3. RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] + ``` - Puis activez la nouvelle configuration avec : -```bash -service apache2 reload -``` + ```bash + service apache2 reload + ``` #### Nginx -- Insérez la configuration suivante dans la section `server {`} de votre site : +- Insérez la configuration suivante dans la section `server {` de votre site : -```nginx -1. if ($http_x_forwarded_proto = "http") { -2. return 301 https://$host/$request_uri; -3. } -``` + ```nginx + 1. if ($http_x_forwarded_proto = "http") { + 2.         return 301 https://$host/$request_uri; + 3. } + ``` - Puis activez la nouvelle configuration avec : @@ -177,57 +177,57 @@ service apache2 reload service nginx reload ``` -### Transmissions des en-têtes à PHP +### Transmission des en-têtes à PHP -PHP se base sur l'en-tête `REMOTE_ADDR` pour déterminer l'adresse des visiteurs. Cet en-tête est configuré automatiquement lorsque la configuration de la section « [Correction de l’IP source dans les Logs](#ip-source-logs) » est appliquée. +PHP utilise l'en-tête `REMOTE_ADDR` pour déterminer l'adresse des visiteurs. Cet en-tête est automatiquement configuré dès lors que la configuration détaillée dans la section « [Correction de l'adresse IP source dans les logs](#ip-source-logs) » est appliquée. ### Ajouter des en-têtes personnalisés -Si votre application attend un format particulier d'en-tête pour découvrir l'IP, le port ou le protocole du visiteur ou que vous souhaitez savoir par quel frontend est arrivée une requête ou pour toute autre raison, vous pouvez ajouter des en-têtes personnalisés sur votre frontend HTTP. +Que votre application nécessite un format d'en-tête spécifique pour identifier l'adresse IP, le port ou le protocole du visiteur, ou que vous souhaitiez connaître le *frontend* par lequel une requête est arrivée (ou pour toute autre raison), vous avez la possibilité d'ajouter des en-têtes personnalisés sur votre *frontend* HTTP. -Les en-têtes personnalisés doivent être de la forme « X-En-Tete Valeur de l'Entête ». Le nom de l'en-tête et sa valeur sont séparés par un espace. Il est possible de spécifier plusieurs en-têtes sur un même frontend. +Les en-têtes personnalisés doivent respecter le format « `X-En-Tete Valeur de l'En-tête` ». Le nom de l'en-tête et sa valeur sont séparés par un espace. Il est possible de spécifier plusieurs en-têtes sur un même *frontend*. -Si un autre en-tête existe dans la requête, il sera écrasé et remplacé par la nouvelle valeur de telle sorte qu'il devient impossible pour le visiteur passant par ce frontend de le forger. Il n'est pas possible de re-définir un des en-têtes réservés aux mandataires tels que ceux décrits dans ce document. Ceux ci sont gérés automatiquement par votre service OVHcloud Load Balancer. +Si un en-tête existant est présent dans la requête, il sera écrasé et remplacé par la nouvelle valeur, rendant ainsi impossible sa contrefaçon par le visiteur passant par ce *frontend*. Il n'est pas possible de redéfinir les en-têtes réservés aux mandataires, tels que ceux décrits dans ce document, car ils sont gérés automatiquement par votre service OVHcloud Load Balancer. -Lorsque vous spécifiez un nom d'en-tête non standard, une bonne pratique est de le faire commencer par le préfixe « X- ». +Lors de la spécification d'un nom d'en-tête non standard, il est d'usage de le faire précéder du préfixe « `X-` ». -Il est possible d'utiliser des variables dans la valeur des en-têtes: +L'utilisation de variables dans la valeur des en-têtes est supportée : -- `%ci` sera remplacé par l'adresse IP de votre visiteur -- `%cp` sera remplacé par le port source de votre visiteur +- `%ci` sera remplacé par l'adresse IP de votre visiteur. +- `%cp` sera remplacé par le port source de votre visiteur. -Les en-têtes personnalisés peuvent être spécifiés via l'espace client OVHcloud et via l'API, à la fois sur un nouveau frontend comme sur un frontend existant. +Les en-têtes personnalisés peuvent être configurés via l'espace client OVHcloud et l'API, que ce soit sur un nouveau *frontend* ou un *frontend* existant. #### Depuis l'espace client OVHcloud -Dans la section `Frontends`{.action} de votre espace client OVHcloud, choisissez le frontend à éditer ou cliquez sur le bouton `Ajouter un frontend`{.action} pour en créer un nouveau. Une fenêtre d'édition apparait alors avec un champ `Entête HTTP`{.action} dans la partie `Paramètres avancés`{.action}. +Rendez-vous dans l'onglet `Frontends`{.action} du tableau de bord de votre service OVHcloud Load Balancer et sélectionnez le *frontend* à éditer ou cliquez sur le bouton `Ajouter un frontend`{.action} pour en créer un nouveau. Une fenêtre d'édition apparaîtra, présentant un champ `Entête HTTP`{.action} dans la section `Paramètres avancés`{.action}. -Si vous souhaitez configurer plusieurs en-têtes, ceux-ci doivent être séparés par des virgules *sans espaces*. Par exemple, vous pouvez créer les en-têtes suivants: `X-Ip-Header %ci,X-Port-Header %cp`. +Si vous souhaitez configurer plusieurs en-têtes, ceux-ci doivent être séparés par des virgules, *sans espace*. Par exemple, vous pouvez définir les en-têtes suivants : `X-Ip-Header %ci,X-Port-Header %cp`. ![Configuration des en-têtes HTTP d'un Frontend via ovh manager API](images/add_headers.png){.thumbnail} -Cliquez sur le bouton `Mettre à jour`{.action} une fois les en-têtes configurés puis sur `Déployer la zone: VOTRE ZONE`{.action} pour appliquer vos changements dans la zone concernée. +Cliquez sur le bouton `Mettre à jour`{.action} après avoir configuré les en-têtes, puis sur `Déployer la zone: VOTRE ZONE`{.action} pour appliquer les modifications dans la zone concernée. ### Depuis l'API OVHcloud -Dans l'API, les en-têtes sont spécifiées dans une liste httpHeader. À la différence de l'espace client OVHcloud, chaque en-tête doit être dans sa propre entrée de la liste. +Dans l'API, les en-têtes sont spécifiés au sein d'une liste `httpHeader`. Contrairement à l'espace client OVHcloud, chaque en-tête doit constituer sa propre entrée dans la liste. -Dans la console de l'API OVHcloud, un bouton `+`{.action} est disponible dès que vous commencez à spécifier une valeur, afin d'ajouter un nouveau champ dans la liste. +Dans la console de l'API OVHcloud, un bouton `+`{.action} est disponible dès que vous commencez à spécifier une valeur, permettant d'ajouter un nouveau champ à la liste. ![Configuration des en-têtes HTTP d'un Frontend](images/add_headers_with_api.png){.thumbnail} -Si vous utilisez l'API dans votre code, cela correspond à une liste json telle que : +Si vous intégrez l'API dans votre code, cela correspond à une liste JSON du type : ```json 1. { -2. "httpHeader": [ -3. "X-Ip-Header %ci", -4. "X-Port-Header %cp" -5. ] +2.         "httpHeader": [ +3.                 "X-Ip-Header %ci", +4.                 "X-Port-Header %cp" +5.         ] 6. } ``` -- Modifier un `Frontend`{.action} existant : +- Modification d'un `Frontend`{.action} existant : > [!api] > @@ -240,7 +240,7 @@ Si vous utilisez l'API dans votre code, cela correspond à une liste json telle |frontendId|Identifiant du frontend où configurer les en-têtes HTTP| |httpHeader|Liste d'en-têtes à configurer| -- Appliquer les modifications : +- Application des modifications : > [!api] > @@ -254,4 +254,4 @@ Si vous utilisez l'API dans votre code, cela correspond à une liste json telle ## Aller plus loin -Échangez avec notre [communauté d'utilisateurs](/links/community). +Échangez avec notre [communauté d'utilisateurs](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_headers/guide.fr-fr.md b/pages/network/load_balancer/create_headers/guide.fr-fr.md index 9cee53504d1..b07ed48ee28 100644 --- a/pages/network/load_balancer/create_headers/guide.fr-fr.md +++ b/pages/network/load_balancer/create_headers/guide.fr-fr.md @@ -1,27 +1,27 @@ --- title: "Configuration d'un service OVHcloud Load Balancer - Les en-têtes HTTP" excerpt: Intégrez vos services web derrière un Load Balancer avec les en-têtes HTTP -updated: 2022-07-27 +updated: 2025-11-12 --- ## Objectif -Le service OVHcloud Load Balancer agit comme un mandataire ou "Proxy". Comme un mandataire humain, il agit comme un intermédiaire, de telle sorte que le client s'adresse au mandataire et le mandataire au fournisseur de service, au nom du client. Dans cette configuration, seul le mandataire connait à la fois le véritable client (le visiteur de votre service web) et le véritable fournisseur de service (l'un de vos serveurs). +Le service OVHcloud Load Balancer agit en tant que mandataire ou « Proxy ». À l'instar d'un mandataire humain, il fait office d'intermédiaire : le client s'adresse au mandataire qui, à son tour, contacte le fournisseur de service au nom du client. Dans cette configuration, **seul le mandataire** est en possession des informations concernant le **véritable client** (le visiteur de votre service web) et le **véritable fournisseur de service** (l'un de vos serveurs). -Pour le visiteur, cela ne pose aucun souci. Il n'a pas besoin de connaître avec précision le serveur qui répond à sa requête. C'est un détail d'implémentation. En revanche, pour des raisons à la fois légales et de statistiques, il est indispensable que le serveur final ait connaissance de la véritable adresse du client. Or, par défaut, il ne voit que le mandataire (en l'occurence, votre service OVHcloud Load Balancer). +Pour le visiteur, cette configuration ne soulève aucune difficulté. Il n'a pas besoin de connaître le serveur précis qui traite sa requête ; il s'agit d'un détail d'implémentation. En revanche, pour des raisons à la fois légales et statistiques, il est **impératif** que le serveur final ait connaissance de l'adresse réelle du client. Or, par défaut, il n'identifie que le mandataire, en l'occurrence votre service OVHcloud Load Balancer. -Pour palier à cela, votre service OVHcloud Load Balancer ajoute par défaut les en-têtes HTTP standards permettant de retrouver ces informations dans le cas d'une connexion HTTP. Dans le cas d'une connexion TCP, d'autres solutions existent telles que le ProxyProtocol, mais cela sort du cadre de ce guide. +Afin de pallier cet inconvénient, votre service OVHcloud Load Balancer **ajoute par défaut** les en-têtes HTTP standards qui permettent de retrouver ces informations dans le cas d'une connexion HTTP. Pour une connexion TCP, d'autres solutions telles que le ProxyProtocol existent, mais elles dépassent le cadre de ce guide. -**Ce guide présente les en-têtes par défaut, leur rôle, comment les exploiter depuis les serveurs les plus courants et comment les personnaliser en fonction des contraintes de votre infrastructure.** +**Ce guide présente les en-têtes par défaut, leur fonction, la manière de les exploiter sur les serveurs les plus courants et comment les personnaliser en fonction des exigences de votre infrastructure.** -Si vous retrouvez uniquement des IP privées dans vos acces_log, ce guide est fait pour vous. +Ce guide s'adresse spécifiquement à vous si vous ne retrouvez que des adresses IP privées dans vos journaux d'accès (`access_log`). ## Prérequis - Posséder une offre [OVHcloud Load balancer](/links/network/load-balancer) dans votre compte OVHcloud. - Être connecté à votre [espace client OVHcloud](/links/manager). -- Posséder un service Web installé et configuré sur vos serveurs -- Posséder un service Nginx installé et configuré sur vos serveurs +- Posséder un service Web installé et configuré sur vos serveurs. +- Posséder un service Nginx installé et configuré sur vos serveurs. ## En pratique @@ -32,64 +32,64 @@ Si vous retrouvez uniquement des IP privées dans vos acces_log, ce guide est fa ### Obligations légales -Vous pouvez être tenu de conserver des logs et certaines données relatives au trafic en vertu des lois et règlementations vous étant applicables. Il vous incombe de respecter ces obligations. +Il se peut que vous soyez tenu de conserver des journaux et certaines données relatives au trafic en vertu des lois et réglementations qui vous sont applicables. **Il vous incombe de vous conformer à ces obligations.** -**A titre d’exemple :** +**À titre d'exemple :** -- [L’article L34-1 du Code des postes et des communications électroniques](https://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT000006070987&idArticle=LEGIARTI000006465770&dateTexte=&categorieLien=cid) ainsi que le [décret n°2006-358 du 24 mars 2006 relatif à la conservation des données des communications électroniques](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000637071&dateTexte=20180110) imposent notamment à toute personne physique ou morale fournissant au public un service de communications électroniques de conserver des données d'identification des personnes utilisatrices des services fournis, etc. ; -- La [loi n° 2004-575 du 21 juin 2004 pour la confiance dans l'économie numérique](https://www.legifrance.gouv.fr/affichTexteArticle.do?idArticle=JORFARTI000002457442&cidTexte=JORFTEXT000000801164) et le [décret n° 2011-219 du 25 février 2011](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000023646013&categorieLien=id) imposent notamment aux personnes dont l’activité est d’offrir un accès à des services de communication au public en ligne de conserver pour chaque connexion les données relatives à l’identifiant de la connexion, les dates et heure de début et de fin de la connexion, etc. +- [L'article L34-1 du Code des postes et des communications électroniques](https://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT000006070987&idArticle=LEGIARTI000006465770&dateTexte=&categorieLien=cid) ainsi que le [décret n°2006-358 du 24 mars 2006 relatif à la conservation des données des communications électroniques](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000637071&dateTexte=20180110) imposent notamment à toute personne physique ou morale fournissant un service de communications électroniques au public de conserver les données d'identification des utilisateurs des services fournis, etc. ; +- La [loi n° 2004-575 du 21 juin 2004 pour la confiance dans l'économie numérique](https://www.legifrance.gouv.fr/affichTexteArticle.do?idArticle=JORFARTI000002457442&cidTexte=JORFTEXT000000801164) et le [décret n° 2011-219 du 25 février 2011](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000023646013&categorieLien=id) exigent notamment des personnes dont l'activité consiste à offrir un accès à des services de communication au public en ligne de conserver, pour chaque connexion, les données relatives à l'identifiant de la connexion, les dates et heures de début et de fin de la connexion, etc. -### En-tetes par defaut +### En-têtes par défaut -Par défaut, votre service OVHcloud Load Balancer ajoute à chaque requête HTTP 5 des en-têtes standard permettant de connaître l'adresse et le port du visiteur de votre site ainsi que le protocole de connexion. +Par défaut, votre service OVHcloud Load Balancer ajoute **cinq** en-têtes HTTP standards à chaque requête, permettant d'identifier l'adresse et le port du visiteur de votre site ainsi que le protocole de connexion initial. |En-tête|Description| |---|---| -|X-Forwarded-For et X-Remote-Ip|Adresse du client, telle que vue par votre OVHcloud Load Balancer.| +|X-Forwarded-For et X-Remote-Ip|Adresse IP du client, telle que vue par votre OVHcloud Load Balancer.| |X-Forwarded-Port et X-Remote-Port|Port source du client, tel que vu par votre OVHcloud Load Balancer.| |X-Forwarded-Proto|Protocole du client (HTTP ou HTTPS), tel que vu par votre OVHcloud Load Balancer.| > [!warning] ->Les champs X-Fowarded-* pouvant être forgés par un client malicieux, ils ne doivent être pris en compte que s’ils viennent d’une source de confiance. +> Les champs `X-Forwarded-*` pouvant être manipulés par un client malveillant, **ils ne doivent être pris en compte que s'ils proviennent d'une source de confiance.** > ->Il est donc indispensable de limiter leur utilisation à des adresses IP de confiance, en l'occurence les adresses IP de sortie de votre service OVHcloud Load Balancer. Les principaux serveurs tels que Nginx et Apache disposent de modules capable de gérer cet aspect de sécurité et confiance. +> Il est donc **essentiel** de restreindre leur utilisation aux adresses IP de confiance, qui sont en l'occurrence les adresses IP de sortie de votre service OVHcloud Load Balancer. Les principaux serveurs web tels que Nginx et Apache disposent de modules capables de gérer cet aspect de sécurité et de fiabilité. > -Vous pouvez obtenir la liste de vos adresse IP de sortie depuis l'espace client OVHcloud et via l'API OVHcloud. +La liste de vos adresses IP de sortie est disponible via l'espace client OVHcloud et l'API OVHcloud. #### Depuis l'espace client OVHcloud -La liste des IPv4 de sortie potentiellement utilisées par votre service OVHcloud Load Balancer se trouve sur la page d'accueil de votre service OVHcloud Load Balancer sous le nom « IPv4 de sortie ». +La liste des adresses IPv4 de sortie susceptibles d'être utilisées par votre service OVHcloud Load Balancer est accessible sur la page d'accueil de votre service Load Balancer. Dans le cadre **Informations**, cliquez sur le bouton `...`{.action} à droite de la mention **IPv4 de sortie** et sélectionnez `Consulter`{.action}. ![Adresse IPv4 de sortie de votre service OVHcloud Load Balancer](images/iplb_service.png){.thumbnail} #### Depuis l'API OVHcloud -- Liste des adresses IP utilisées par votre service OVHcloud Load Balancer : +Récupération de la liste des adresses IP utilisées par votre service OVHcloud Load Balancer : > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/natIp > -### Correction de l'IP source dans les logs +### Correction de l'adresse IP source dans les logs -Par défaut, Apache, Nginx et les autres serveurs web prennent en compte l'adresse IP source dans les logs. Quand vous utilisez un OVHcloud Load Balancer en amont de votre site web, les logs ne contiennent alors plus que des adresses IPs qui ressemblent à « 10.108.a.b ». Ce sont les adresses IP utilisées par l'OVHcloud Load Balancer pour vous contacter. +Par défaut, Apache, Nginx et les autres serveurs web enregistrent l'adresse IP source dans leurs journaux. Lorsque vous utilisez un service OVHcloud Load Balancer en amont de votre site web, les logs ne contiennent alors que des adresses IP de la forme « 10.108.a.b ». Il s'agit des adresses IP internes utilisées par le service OVHcloud Load Balancer pour vous contacter. -Lorsque la requête passe par votre service OVHcloud Load Balancer, celui-ci enregistre l'adresse IP de votre visiteur dans les en-têtes X-Forwarded-For et X-Remote-Ip. Ils contiennent la même information. Seul le nom change pour des raisons de compatibilité avec la majorité des serveurs. +Lorsqu'une requête transite par votre service OVHcloud Load Balancer, celui-ci enregistre l'adresse IP de votre visiteur dans les en-têtes `X-Forwarded-For` et `X-Remote-Ip`. Ces deux champs contiennent la même information, leur nom diffère uniquement pour des raisons de compatibilité avec la majorité des serveurs. -Pour corriger les adresses IP dans les logs, la solution évidente serait de modifier la directive de format de logs de votre serveur pour utiliser l'un de ces en-têtes en lieu et place de l'IP du Load Balancer. Malheureusement, cela ne suffit pas car n'importe qui peut renseigner ces en-tête, même s'il ne passe pas par votre OVHcloud Load Balancer. Et cela lui permettrait de se faire passer pour quelqu'un d'autre. En dehors de l'aspect éthique de cette pratique, il y a également des implications légales, de sécurité et de statistiques pour lesquelles cela ne doit pas se produire. +Pour corriger les adresses IP dans les logs, une solution pourrait être de modifier la directive de format de logs de votre serveur pour utiliser l'un de ces en-têtes à la place de l'adresse IP du Load Balancer. Malheureusement, cette approche est insuffisante, car n'importe qui peut renseigner cet en-tête, même sans passer par votre service OVHcloud Load Balancer. Une telle manipulation permettrait au visiteur de se faire passer pour quelqu'un d'autre. Outre l'aspect éthique, cette pratique a des implications légales de sécurité et de statistiques, qui rendent sa prévention indispensable. -Pour cette raison, les principaux serveurs web disposent de modules spécialisées permettant de contrôler exactement le niveau de confiance à accorder à ces en-têtes en fonction de +C'est pourquoi les principaux serveurs web intègrent des modules spécialisés permettant de contrôler avec précision le niveau de confiance accordé à ces en-têtes en se basant sur : -- L'adresse IP source (seulement celle de votre service OVHcloud Load Balancer !) -- Le niveau de profondeur de l'IP dans le champ. En effet, chaque mandataire (proxy, load balancer) ajoute l'IP de son client dans ce champ. +- l'adresse IP source (doit être exclusivement celle de votre service OVHcloud Load Balancer !) ; +- le niveau de profondeur de l'adresse IP dans le champ. En effet, chaque mandataire (proxy, load balancer) ajoute l'adresse IP de son client dans ce champ. -La suite de ce guide vous propose quelques bonnes pratiques de configuration pour les principaux serveurs webs. +La suite de ce guide propose des pratiques de configuration recommandées pour les principaux serveurs web. #### Apache -- Créez le fichier `/etc/apache2/conf-available/remoteip.conf` +- Créez le fichier `/etc/apache2/conf-available/remoteip.conf`. - Insérez la configuration suivante : ```apache @@ -99,7 +99,7 @@ La suite de ce guide vous propose quelques bonnes pratiques de configuration pou 4. RemoteIPInternalProxy 10.108.0.0/14 ``` -- Remplacez les variables `%h` par `%a` dans les directives `LogFormat` de la configuration Apache +- Remplacez les variables `%h` par `%a` dans les directives `LogFormat` de la configuration Apache. - Enfin, activez la nouvelle configuration avec : ```bash @@ -113,14 +113,14 @@ service apache2 restart #### Nginx -Pour Nginx, c'est un peu plus simple mais l'idée reste la même que pour Apache en ne prenant en compte le champ X-Forwarded-For que s'il vient de votre service OVHcloud Load Balancer. +Pour Nginx, l'approche est légèrement plus simple, mais le principe demeure identique à celui d'Apache : ne prendre en compte le champ `X-Forwarded-For` que s'il provient de votre service OVHcloud Load Balancer. -Cette configuration peut être effectuée soit : +Cette configuration peut être appliquée : -- pour l'ensemble des sites en insérant la configuration dans la section `http {}` -- pour un site en particulier en insérant la configuration dans la section `server {}` correspondante -- pour une URL en particulier en insérant la configuration dans la section `location {}` correspondante -- Insérez la configuration dans la ou les sections voulue (`http {}` pour une configuration globale) : +- à l'ensemble des sites, en insérant la configuration dans la section `http {}` ; +- à un site en particulier, en insérant la configuration dans la section `server {}` correspondante ; +- à une URL spécifique, en insérant la configuration dans la section `location {}` correspondante. +- Insérez la configuration dans la ou les sections souhaitées (`http {}` pour une configuration globale) : ```nginx 1. # Trust X-Forwarded-For headers from the OVHcloud Load Balancer @@ -137,39 +137,39 @@ service nginx reload #### Redirection des visiteurs HTTP vers HTTPS -Pour plus de sécurité, certains contenus tels que les pages de connexion peuvent n'être disponible qu'en HTTPS. Certains sites vont même plus loin en redirigeant systématiquement toutes les visites vers la version HTTPS du site. Par défaut, comme les 2 protocoles HTTP et HTTPS passent par des ports différents, respectivement le 80 et le 443, la solution consiste à mettre les règles de redirections directement dans le vhost correspondant au HTTP. +Pour renforcer la sécurité, certains contenus, tels que les pages de connexion, peuvent être restreints au protocole HTTPS. Certains sites optent même pour la redirection systématique de toutes les visites vers la version HTTPS. Par défaut, les protocoles HTTP et HTTPS utilisent des ports différents (respectivement 80 et 443), la solution classique consiste à placer les règles de redirection directement dans le *vhost* dédié au HTTP. -Lorsque la requête passe par un service comme le service OVHcloud Load Balancer, celui-ci s'occupe de recevoir le trafic HTTP, déchiffrer le trafic HTTPS et les fait suivre tous les 2 vers vos serveurs. En fonction de la configuration de vos serveurs, l'ensemble du trafic sera propagé en HTTP ou en HTTPS, sans distinction de protocole d'entrée sur le Load Balancer. Votre serveur ne peut plus faire la différence entre les 2, puisque les 2 arrivent au même endroit. On parle de « Terminaison SSL ». +Lorsqu'une requête passe par un service comme le Load Balancer OVHcloud, celui-ci gère la réception du trafic HTTP, le déchiffrement du trafic HTTPS et transmet les deux types de trafic à vos serveurs. Selon la configuration de vos serveurs, l'ensemble du trafic sera propagé en HTTP ou en HTTPS, sans distinction du protocole d'entrée sur le Load Balancer. Votre serveur ne peut plus différencier les deux, car les deux arrivent au même point. Ce processus est appelé **« Terminaison SSL »**. -Pour cette raison, le service OVHcloud Load Balancer ajoute automatiquement un en-tête `X-Forwarded-Proto` qui contient le nom du protocole d'origine. En l'occurence « http » ou « https ». +C'est pourquoi le service OVHcloud Load Balancer ajoute automatiquement un en-tête `X-Forwarded-Proto` qui indique le nom du protocole d'origine, soit « http » ou « https ». -De même que `X-Forwarded-For`, cet en-tête peut être forgé par un visiteur malicieux pour faire croire qu'une requête non sécurisée proviendrait de votre service OVHcloud Load Balancer, en HTTPS. Il est essentiel de ne faire confiance à cet en-tête que s'il vient bien de votre service OVHcloud Load Balancer. +Tout comme `X-Forwarded-For`, cet en-tête peut être contrefait par un visiteur malveillant pour faire croire qu'une requête non sécurisée provient de votre service OVHcloud Load Balancer, en HTTPS. Il est crucial de ne se fier à cet en-tête que s'il est avéré qu'il provient de votre service OVHcloud Load Balancer. #### Apache -- Insérez la configuration suivante dans le fichier .hatccess de votre site : +- Insérez la configuration suivante dans le fichier `.htaccess` de votre site : -```apache -1. RewriteEngine on -2. RewriteCond %{HTTP:X-Forwarded-Proto} !https -3. RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] -``` + ```apache + 1. RewriteEngine on + 2. RewriteCond %{HTTP:X-Forwarded-Proto} !https + 3. RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] + ``` - Puis activez la nouvelle configuration avec : -```bash -service apache2 reload -``` + ```bash + service apache2 reload + ``` #### Nginx -- Insérez la configuration suivante dans la section `server {`} de votre site : +- Insérez la configuration suivante dans la section `server {` de votre site : -```nginx -1. if ($http_x_forwarded_proto = "http") { -2. return 301 https://$host/$request_uri; -3. } -``` + ```nginx + 1. if ($http_x_forwarded_proto = "http") { + 2.         return 301 https://$host/$request_uri; + 3. } + ``` - Puis activez la nouvelle configuration avec : @@ -177,57 +177,57 @@ service apache2 reload service nginx reload ``` -### Transmissions des en-têtes à PHP +### Transmission des en-têtes à PHP -PHP se base sur l'en-tête `REMOTE_ADDR` pour déterminer l'adresse des visiteurs. Cet en-tête est configuré automatiquement lorsque la configuration de la section « [Correction de l’IP source dans les Logs](#ip-source-logs) » est appliquée. +PHP utilise l'en-tête `REMOTE_ADDR` pour déterminer l'adresse des visiteurs. Cet en-tête est automatiquement configuré dès lors que la configuration détaillée dans la section « [Correction de l'adresse IP source dans les logs](#ip-source-logs) » est appliquée. ### Ajouter des en-têtes personnalisés -Si votre application attend un format particulier d'en-tête pour découvrir l'IP, le port ou le protocole du visiteur ou que vous souhaitez savoir par quel frontend est arrivée une requête ou pour toute autre raison, vous pouvez ajouter des en-têtes personnalisés sur votre frontend HTTP. +Que votre application nécessite un format d'en-tête spécifique pour identifier l'adresse IP, le port ou le protocole du visiteur, ou que vous souhaitiez connaître le *frontend* par lequel une requête est arrivée (ou pour toute autre raison), vous avez la possibilité d'ajouter des en-têtes personnalisés sur votre *frontend* HTTP. -Les en-têtes personnalisés doivent être de la forme « X-En-Tete Valeur de l'Entête ». Le nom de l'en-tête et sa valeur sont séparés par un espace. Il est possible de spécifier plusieurs en-têtes sur un même frontend. +Les en-têtes personnalisés doivent respecter le format « `X-En-Tete Valeur de l'En-tête` ». Le nom de l'en-tête et sa valeur sont séparés par un espace. Il est possible de spécifier plusieurs en-têtes sur un même *frontend*. -Si un autre en-tête existe dans la requête, il sera écrasé et remplacé par la nouvelle valeur de telle sorte qu'il devient impossible pour le visiteur passant par ce frontend de le forger. Il n'est pas possible de re-définir un des en-têtes réservés aux mandataires tels que ceux décrits dans ce document. Ceux ci sont gérés automatiquement par votre service OVHcloud Load Balancer. +Si un en-tête existant est présent dans la requête, il sera écrasé et remplacé par la nouvelle valeur, rendant ainsi impossible sa contrefaçon par le visiteur passant par ce *frontend*. Il n'est pas possible de redéfinir les en-têtes réservés aux mandataires, tels que ceux décrits dans ce document, car ils sont gérés automatiquement par votre service OVHcloud Load Balancer. -Lorsque vous spécifiez un nom d'en-tête non standard, une bonne pratique est de le faire commencer par le préfixe « X- ». +Lors de la spécification d'un nom d'en-tête non standard, il est d'usage de le faire précéder du préfixe « `X-` ». -Il est possible d'utiliser des variables dans la valeur des en-têtes: +L'utilisation de variables dans la valeur des en-têtes est supportée : -- `%ci` sera remplacé par l'adresse IP de votre visiteur -- `%cp` sera remplacé par le port source de votre visiteur +- `%ci` sera remplacé par l'adresse IP de votre visiteur. +- `%cp` sera remplacé par le port source de votre visiteur. -Les en-têtes personnalisés peuvent être spécifiés via l'espace client OVHcloud et via l'API, à la fois sur un nouveau frontend comme sur un frontend existant. +Les en-têtes personnalisés peuvent être configurés via l'espace client OVHcloud et l'API, que ce soit sur un nouveau *frontend* ou un *frontend* existant. #### Depuis l'espace client OVHcloud -Dans la section `Frontends`{.action} de votre espace client OVHcloud, choisissez le frontend à éditer ou cliquez sur le bouton `Ajouter un frontend`{.action} pour en créer un nouveau. Une fenêtre d'édition apparait alors avec un champ `Entête HTTP`{.action} dans la partie `Paramètres avancés`{.action}. +Rendez-vous dans l'onglet `Frontends`{.action} du tableau de bord de votre service OVHcloud Load Balancer et sélectionnez le *frontend* à éditer ou cliquez sur le bouton `Ajouter un frontend`{.action} pour en créer un nouveau. Une fenêtre d'édition apparaîtra, présentant un champ `Entête HTTP`{.action} dans la section `Paramètres avancés`{.action}. -Si vous souhaitez configurer plusieurs en-têtes, ceux-ci doivent être séparés par des virgules *sans espaces*. Par exemple, vous pouvez créer les en-têtes suivants: `X-Ip-Header %ci,X-Port-Header %cp`. +Si vous souhaitez configurer plusieurs en-têtes, ceux-ci doivent être séparés par des virgules, *sans espace*. Par exemple, vous pouvez définir les en-têtes suivants : `X-Ip-Header %ci,X-Port-Header %cp`. ![Configuration des en-têtes HTTP d'un Frontend via ovh manager API](images/add_headers.png){.thumbnail} -Cliquez sur le bouton `Mettre à jour`{.action} une fois les en-têtes configurés puis sur `Déployer la zone: VOTRE ZONE`{.action} pour appliquer vos changements dans la zone concernée. +Cliquez sur le bouton `Mettre à jour`{.action} après avoir configuré les en-têtes, puis sur `Déployer la zone: VOTRE ZONE`{.action} pour appliquer les modifications dans la zone concernée. ### Depuis l'API OVHcloud -Dans l'API, les en-têtes sont spécifiées dans une liste httpHeader. À la différence de l'espace client OVHcloud, chaque en-tête doit être dans sa propre entrée de la liste. +Dans l'API, les en-têtes sont spécifiés au sein d'une liste `httpHeader`. Contrairement à l'espace client OVHcloud, chaque en-tête doit constituer sa propre entrée dans la liste. -Dans la console de l'API OVHcloud, un bouton `+`{.action} est disponible dès que vous commencez à spécifier une valeur, afin d'ajouter un nouveau champ dans la liste. +Dans la console de l'API OVHcloud, un bouton `+`{.action} est disponible dès que vous commencez à spécifier une valeur, permettant d'ajouter un nouveau champ à la liste. ![Configuration des en-têtes HTTP d'un Frontend](images/add_headers_with_api.png){.thumbnail} -Si vous utilisez l'API dans votre code, cela correspond à une liste json telle que : +Si vous intégrez l'API dans votre code, cela correspond à une liste JSON du type : ```json 1. { -2. "httpHeader": [ -3. "X-Ip-Header %ci", -4. "X-Port-Header %cp" -5. ] +2.         "httpHeader": [ +3.                 "X-Ip-Header %ci", +4.                 "X-Port-Header %cp" +5.         ] 6. } ``` -- Modifier un `Frontend`{.action} existant : +- Modification d'un `Frontend`{.action} existant : > [!api] > @@ -240,7 +240,7 @@ Si vous utilisez l'API dans votre code, cela correspond à une liste json telle |frontendId|Identifiant du frontend où configurer les en-têtes HTTP| |httpHeader|Liste d'en-têtes à configurer| -- Appliquer les modifications : +- Application des modifications : > [!api] > diff --git a/pages/network/load_balancer/create_http_https/guide.en-asia.md b/pages/network/load_balancer/create_http_https/guide.en-asia.md index 8b7a5b59a68..6a9e36c3a7e 100644 --- a/pages/network/load_balancer/create_http_https/guide.en-asia.md +++ b/pages/network/load_balancer/create_http_https/guide.en-asia.md @@ -1,81 +1,106 @@ --- -title: 'Configuring a HTTP/HTTPS OVH Load Balancer service' -excerpt: 'Find out how to configure an OVH Load Balancer service' -updated: 2023-11-22 +title: "Configuration of an OVHcloud Load Balancer service with HTTP/HTTPS" +excerpt: "Configure your OVHcloud Load Balancer to distribute HTTP traffic and secure your connections with HTTPS" +updated: 2025-11-12 --- -## Objective + -The purpose of this guide is to help you create your first HTTP/HTTPS service with the new OVHcloud Load Balancer solution. Here, we will set up a basic OVHcloud Load Balancer service configuration to balance the HTTP load for a service like a website. +## Objective -A front-end will be created to listen on port 80, while another listens on port 443 with an SSL/TLS certificate. These front-ends will be configured to direct their traffic to a common HTTP farm. This farm can have one or more servers, depending on the configuration you have chosen/adapted. +This guide aims to help you create your first HTTP/HTTPS service using the OVHcloud Load Balancer offer. We will configure a simple OVHcloud Load Balancer service to distribute HTTP traffic for a service, such as a website. -As a reminder, the OVHcloud Load Balancer has four primary components: +A frontend will be created to listen on port 80, while another will listen on port 443 with an SSL/TLS certificate. These frontends will be configured to direct their traffic to a common HTTP farm. This farm can have one or more servers, depending on the chosen / adapted configuration. -- `front-ends` -- server `farms` and their `servers` -- the advanced `routes` between the front-ends and server farms -- `SSL/TLS` connections that can encrypt TCP and/or HTTP connections +As a reminder, the OVHcloud Load Balancer service is composed of 4 elementary parts: -**This guide will show you how to configure an OVHcloud Load Balancer Service.** +- the `frontends`; +- the `farms` of servers and their `servers`; +- the advanced `routes` between Frontends and Server Farms; +- the `SSL/TLS` certificates allowing TCP and/or HTTP connections to be encrypted. ## Requirements -- an OVHcloud Load Balancer -- the ability to add and configure a farm, a server, a front-end and an SSL certificate +- Have an [OVHcloud Load balancer](/links/network/load-balancer) offer in your OVHcloud account +- You must be logged in to your [OVHcloud Control Panel](/links/manager) +- Have a configured farm +- Have a configured frontend +- Have an SSL certificate + +## Instructions -## Introduction +## Table of contents + +- [Add a server farm](#farm) +- [Add a server](#server) +- [Add a frontend](#frontend) +- [Add an SSL/TLS certificate](#certificate) +- [Apply the changes](#apply) +- [Validation](#validation) > [!warning] > -> This guide will take you through the steps required. Depending on the way you have designed your architecture, some configurations may vary. +> We will guide you through the different steps. Depending on your architecture choices, some configurations may differ. > -If you have not done so already, we recommend reading a general introduction to the OVHcloud Load Balancer service before you get started: [Introduction to the OVHcloud Load Balancer](/pages/network/load_balancer/use_presentation){.ref} +Before you start, it is recommended to consult the [OVHcloud Load Balancer presentation](/pages/network/load_balancer/use_presentation). > [!warning] > -> The order in which elements are created is important. In particular, the server farms must be configured before we can attach an SSL/TLS certificate or servers to them. The front-ends must be configured after the server farms in order to configure the front-end’s default farm. +> The order of element creation is important. In particular, server farms must be configured before being able to attach an SSL/TLS certificate or servers to them. Similarly, frontends must be configured after the server farms in order to be able to configure the frontend's default farm. > -In the control panel of the load balancer, you will see the features detailed below: +The features detailed below are accessible from the OVHcloud Control Panel: -![OVHcloud Load Balancer service](images/iplb_service.png){.thumbnail} +![OVHcloud Load Balancer Service](images/iplb_service.png){.thumbnail} -For more information on the Control Panel’s features, you can consult the following guide: [Managing the Load Balancer from the customer control panel](/pages/network/load_balancer/use-lb){.ref} +For more information about the features of the OVHcloud Control Panel, see the [Managing the Load Balancer service via the OVHcloud Control Panel](/pages/network/load_balancer/use-lb) page. -Similarly, this can be done via the OVHcloud API, in the section: +Via the OVHcloud API, use the following call: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing > -For more information on the API’s features, you can consult the following guide: [Load Balancer API Quick Reference](/pages/network/load_balancer/use_api_reference){.ref} - -## Add a server farm. +For more information on the API features, consult the page [API function details](/pages/network/load_balancer/use_api_details){.ref} -We will add a farm of HTTP servers to our service, which is the part that balances traffic on the servers. +### Add a server farm -### Via the OVHCloud Control Panel. +We will add an HTTP server farm to our service. This part is responsible for distributing traffic to the servers. -Log into the [OVHcloud Control Panel](/links/manager), click `Network`{.action} in the left-hand menu, then `Load Balancer`. Click on your load balancer service. +#### From the OVHcloud Control Panel -In the `Server farms`{.action} tab, click on the `Add a server farm`{.action} button. +In the `Server Farms`{.action} tab, click the `Add a server farm`{.action} button. -Fill in the fields. The only mandatory fields for a basic configuration are *Protocol* and *Datacentre*. We recommend explicitly defining a *Port* (generally port 80 for a web service). If no ports are specified, your OVHcloud Load Balancer will automatically use the same port as the corresponding front-end, and the probes will not be able to work as intended. +Fill in the fields. The only mandatory fields for a simple configuration are the *Protocol* and the *Datacentre*. It is recommended to explicitly define a *Port*, generally port 80 for a web service. If no port is specified, your OVHcloud Load Balancer will automatically use the same port as the corresponding frontend and the probes may not work as expected. -If you add several servers to your farm, we advise configuring an HTTP `availability probe`. When a probe is configured, the OVHcloud Load Balancer service can automatically disable a server that is down or under maintenance, so that your web users are not affected. +If you add several servers in your farm, it is recommended to configure an HTTP `availability probe`. When a probe is configured, the OVHcloud Load Balancer service can automatically disable a server that is down or under maintenance, in order not to affect visitors. -![Add a server farm via the Control Panel](images/add_backend.png){.thumbnail} +![Adding a server farm via the OVHcloud Control Panel](images/add_backend.png){.thumbnail} -Click `Add`{.action} once you have filled in the fields. +Click the `Add`{.action} button once you have filled in the fields. -Your server farm should appear in the list, in the `Server farms`{.action} tab. +Your server farm should appear in the list, under the `Server Farms`{.action} tab. -![Details of the server farm created](images/resume_backend.png){.thumbnail} +![Details of the created server farm](images/resume_backend.png){.thumbnail} -### Via the API +#### From the OVHcloud API - List of HTTP server farms: @@ -91,48 +116,46 @@ Your server farm should appear in the list, in the `Server farms`{.action} tab. > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/farm/{farmId} > -- Add a new HTTP server farm: +- Adding a new HTTP server farm: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/http/farm > -- Modify a specific server farm: +- Modifying a specific server farm: > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/farm/{farmId} > -- Delete a specific server farm: +- Deleting a specific server farm: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/farm/{farmId} > -## Add a server. +### Add a server We will now add a server to our server farm. -### Via the OVHcloud Control Panel. - -Log into the [OVHcloud Control Panel](/links/manager), click `Network`{.action} in the left-hand menu, then `Load Balancer`. Click on your load balancer service. +#### From the OVHcloud Control Panel -In the `Server farms`{.action} tab, select the farm you want to add a server to by clicking on the corresponding line. The list of servers already configured in the farm will appear beneath the list of farms, along with the `Add a server`{.action} button. Click on this button to add a new server. +Still in the `Server Farms`{.action} tab, select the farm to which you want to add a server by clicking on the corresponding line. The list of servers already configured in the farm appears below the list of farms, as well as the `Add a server`{.action} button. Click on this button to add a new server. -Only the *IPv4 address* field is mandatory. If a server does not use the same port as the one defined earlier in the farm, you may overload it by configuring a server. However, to keep the configuration as standardised and easy to maintain as possible, we recommend only using this parameter in advanced cases. +Only the *IPv4 Address* field is mandatory. If a server does not use the same port as the one defined above in the farm, it is possible to override it in the server configuration. However, in order to maintain the most homogeneous and maintainable configuration possible, it is recommended to use this parameter only in advanced cases. -![Add a server to a farm.](images/add_server.png){.thumbnail} +![Adding a server to a Farm.](images/add_server.png){.thumbnail} -Click `Add`{.action} once you have filled in the fields. +Click the `Add`{.action} button once you have filled in the fields. -Your server should appear in the server list, in the `Server farm`{.action} tab, just below the list of farms. +Your server should appear in the list of servers, in the `Server Farms`{.action} tab, just below the list of farms. -![Details of the server created.](images/resume_server.png){.thumbnail} +![Details of the created server.](images/resume_server.png){.thumbnail} -### Via the API +#### From the OVHcloud API - List of servers in the farm: @@ -148,193 +171,198 @@ Your server should appear in the server list, in the `Server farm`{.action} tab, > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server/{serverId} > -- Add a new server: +- Adding a new server: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server > -- Modify a specific server: +- Modifying a specific server: > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server > -- Delete a specific server: +- Deleting a specific server: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server > -## Add a front-end. +### Add a frontend -We will now add a `front-end` to our service, and connect it to our server farm. The front-end is the part of your OVHcloud Load Balancer that exposes your service on the internet. First, we will only configure it in HTTP, without an SSL/TLS certificate. +We will now add a `frontend` to our service and connect it to our server farm. The frontend is the part of your OVHcloud Load Balancer that is used to expose your service on the Internet. At first, we will configure it in HTTP only, without an SSL/TLS certificate. -### Via the OVHcloud Control Panel. +#### From the OVHcloud Control Panel -Go to the `Front-ends`{.action} tab, and click `Add a front-end`{.action}. +In the `Frontends`{.action} tab, click the `Add a frontend`{.action} button. -Fill in the fields. The only mandatory fields for a basic configuration are *Protocol*, *Port* (80 for a standard HTTP web service) and *Datacentre*. If you want your service to be available across several ports at once, you can specify a list of ports, separated by commas, or a range of ports, in the format "START_PORT-END_PORT". +Fill in the fields. The only mandatory fields for a simple configuration are the *Protocol*, the *Port* (80 for a standard HTTP web service) and the *Datacentre*. If you want your service to be available on several ports at the same time, you can specify a list of ports separated by commas or a range of ports in the form "START_PORT-END_PORT". -If you have routed Additional IPs to your OVHcloud Load Balancer service, you can also attach a front-end to one or more specific Additional IPs. +If you have routed Additional IPs to your OVHcloud Load Balancer service, you can also attach a frontend to one or more specific Additional IPs. -![Add a front-end](images/add_frontend.png){.thumbnail} +![Adding a frontend](images/add_frontend.png){.thumbnail} -Click `Add`{.action} once you have filled in the fields. +Click the `Add`{.action} button once you have filled in the fields. -Your front-end must appear in the list, in the `Front-ends`{.action} tab. +Your frontend should appear in the list, under the `Frontends`{.action} tab. -![Details of the front-end created](images/resume_frontend.png){.thumbnail} +![Details of the created frontend](images/resume_frontend.png){.thumbnail} -### Via the API +#### From the OVHcloud API -- List of HTTP front-ends: +- List of HTTP frontends: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/frontend > -- Details of a specific front-end: +- Details of a specific frontend: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} > -- Add a new front-end: +- Adding a new frontend: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/http/frontend > -- Modify a specific front-end: +- Modifying a specific frontend: > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} > -- Delete a specific front-end: +- Deleting a specific frontend: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} > -## Add an SSL/TLS certificate. +### Add an SSL/TLS certificate -The section above described the general configuration of a HTTP front-end. This next section describes the additional steps you need to take to activate support of HTTPS protocol on an HTTP front-end. In particular, you need to: +The previous section described the general configuration for an HTTP frontend. This section describes the additional steps to enable support for the HTTPS protocol on an HTTP frontend. In particular, you will need to: -- switch over the front-end to port 443, which is standard for HTTPS protocol -- configure an SSL/TLS certificate to authenticate and encrypt connections +- switch the frontend to port 443, the standard port for the HTTPS protocol; +- configure an SSL/TLS certificate to authenticate and encrypt the connections. -Whether you choose to configure your service via the API or the OVHcloud Control Panel, you can choose from two methods for adding an SSL/TLS certificate. The choice of method will depend on your needs, as well as the solutions currently set up. You can either: +Whether you choose a configuration via the API or via the OVHcloud Control Panel, you will have a choice between 2 strategies for your SSL/TLS certificates. This choice depends on your needs as well as the current solutions in place: - Import an existing SSL/TLS certificate. -- Order an automatically managed SSL/TLS certificate. DV and EV certificates will be available to order soon. +- Order an automatically managed SSL/TLS certificate. The ordering of DV and EV certificates will be available soon. -If you choose to import an SSL/TLS certificate that you have already ordered and managed yourself, you will need to renew it periodically yourself, and update it in your OVHcloud Load Balancer service. Most certificates are valid for one year. Some remain valid for longer periods of time. However, Let's Encrypt certificates need to be renewed every three months. We recommend using your OVHcloud Load Balancer to automatically manage the service for Let’s Encrypt certificates, so that you do not miss the expiry dates. +If you choose to import an SSL/TLS certificate that you have ordered and managed yourself, you will have to renew it periodically yourself and update it in your OVHcloud Load Balancer service. Most certificates are valid for 1 year. Some may be valid for longer. Let's Encrypt certificates are valid for 3 months. It is recommended to use the service managed automatically by your OVHcloud Load Balancer for Let's Encrypt certificates in order not to accidentally miss a deadline. -If you opt for a certificate managed by the OVHcloud Load Balancer service, it will be automatically ordered, validated, installed and renewed periodically by your OVHcloud Load Balancer. For the validation and renewal operations to work, the domains you are ordering this certificate for need to be routed to your OVHcloud Load Balancer service. This means that your domain’s *A* and *AAAA* DNS records must point to your OVHcloud Load Balancer’s IPv4 and IPv6 fields respectively, or to one of its Additional IPs. When you order, you will receive an email that will guide you through the validation steps. +If you choose a certificate managed by your OVHcloud Load Balancer service, it will be automatically ordered, validated, installed and renewed periodically by your OVHcloud Load Balancer.
+For the validation and renewal operations to work, the domain(s) you are ordering this certificate for must be routed to your OVHcloud Load Balancer service. This implies that the *A* and *AAAA* fields of your domain point respectively to the IPv4 and IPv6 of your OVHcloud Load Balancer or one of its Additional IPs. During the order, you will receive an email that will guide you through the validation steps. +> [!primary] > -> To ensure that your service remains accessible when you switch your domain to your OVHcloud Load Balancer service’s IP address in order to validate your certificate, it is good practice to start by configuring and testing all of the HTTP configuration on port 80. This way, your website will remain accessible without any interruptions. -> If the website already has a HTTPS connection and you want to switch to certificates managed by your OVHcloud Load Balancer service, you can import your existing certificates, configure and test your HTTPS front-end, and order a new certificate for the same domain. It will be taken into account automatically when your old certificate expires. +> To ensure service continuity when switching your domain to the IP of your OVHcloud Load Balancer service to validate your certificate, a good practice is to first configure and fully test the HTTP configuration on port 80. This way, your site remains accessible without interruption. +> If your site already has an HTTPS connection and you want to migrate to certificates managed by your OVHcloud Load Balancer service, you can import your existing certificates, configure and test your HTTPS Frontend and finally order a new certificate for the same domain. It will be automatically taken into account before your old certificate expires. > -The certificates configured on your OVHcloud Load Balancer service are automatically available for all of the front-ends on your service that have *SSL* options enabled. +The certificates configured on your OVHcloud Load Balancer service are automatically available for all frontends of your OVHcloud Load Balancer service on which the *SSL* option is enabled. #### TLS 1.3 support -With the constant evolution of Internet security standards, OVHcloud is committed to providing the latest and most secure technologies for your services. The OVHcloud Load Balancer now supports TLS 1.3. -##### What is TLS 1.3? -TLS 1.3 is the latest version of the TLS protocol, offering significant improvements in security and performance over TLS 1.2. Key benefits include a faster handshake process, reducing the time needed to establish secure connections, and the use of more secure cipher suites to strengthen the security of transmitted data. +With the constant evolution of security standards on the Internet, OVHcloud is committed to providing the most recent and secure technologies for your services. The OVHcloud Load Balancer now supports TLS 1.3. -##### Why use TLS 1.3 with OVHcloud Load Balancer? -By integrating TLS 1.3, your OVHcloud Load Balancer will benefit from enhanced security and improved performance, ensuring an optimal user experience for your visitors. Reduced handshake times speed up page loading, while security enhancements ensure that your data is protected with the latest, most secure standards. +##### **What is TLS 1.3?** -### Via the OVHcloud Control Panel. +TLS 1.3 is the latest version of the TLS protocol, offering significant improvements in terms of security and performance compared to TLS 1.2. The key advantages include a faster *handshake* process, thus reducing the time needed to establish secure connections, and the use of safer encryption suites to strengthen the security of transmitted data. -The list of SSL/TLS certificates configured on the OVHcloud Load Balancer can be found in the `SSL certificates`{.action} tab. In this interface, you can select one of the two options mentioned further up, i.e. importing an existing certificate (`Add an SSL certificate`{.action}) and (`Order an SSL certificate`{.action}) managed automatically by your OVHcloud Load Balancer. +##### **Why use TLS 1.3 with OVHcloud Load Balancer?** -![Buttons for adding certificates](images/certificat.png){.thumbnail} +By integrating TLS 1.3, your OVHcloud Load Balancer will benefit from enhanced security and improved performance, ensuring an optimal user experience for your visitors. The reduction in *handshake* time speeds up page loading, while the security improvements ensure that your data is protected with the most recent and secure standards. -If you choose to import an existing SSL/TLS certificate, click `Add an SSL certificate`{.action}. The *Private key* and *Certificate* fields are obligatory. +#### From the OVHcloud Control Panel -Click `Add`{.action} once you have filled in the fields. Your certificate will appear in the certificate list. +The list of SSL/TLS certificates configured on your OVHcloud Load Balancer service is in the `SSL Certificates`{.action} tab. This interface offers the 2 options mentioned above, namely importing an existing certificate (via the `Add an SSL certificate`{.action} button) and `Order an SSL certificate`{.action} managed automatically by your OVHcloud Load Balancer service. -![Add an existing SSL certificate](images/add_certificat_custom.png){.thumbnail} +![Certificate addition buttons](images/certificat.png){.thumbnail} -To add a Let's Encrypt certificate, click `Order an SSL certificate`{.action}, enter your domains, ensure that they point to your OVHcloud Load Balancer, and follow the instructions set out in the guides you receive. You will then see it appear in the list of available certificates. +If you choose to import an existing SSL/TLS certificate, click on `Add an SSL certificate`{.action}. The *Private Key* and *Certificate* fields are mandatory. -![Order a Let’s Encrypt certificate](images/add_certificat_letsencrypt.png){.thumbnail} +Click the `Add`{.action} button once the fields are filled in. Your certificate will then appear in the certificate list. -Once your certificates have been configured, you can create a HTTPS front-end, on the same model as the HTTP front-end created earlier on with port 443, and the *SSL* option enabled. You can also choose to enable the *HSTS* option. With this option enabled, web browsers will remember that this website should *no longer* be visited without HTTPS after the first time the web user visits in HTTPS. This way, you can improve your infrastructure’s overall security by protecting it against ‘man-in-the-middle’ attacks, where a malicious party can make it seem as though your website is not available in HTTPS, forcing your web users to switch to HTTP. +![Adding an existing certificate](images/add_certificat_custom.png){.thumbnail} + +To add a Let's Encrypt certificate, click on `Order an SSL certificate`{.action}, enter your domain, make sure it points to your OVHcloud Load Balancer service and follow the emails you receive. You will then see it appear in the list of available certificates. + +![Ordering a Let's Encrypt certificate](images/add_certificat_letsencrypt.png){.thumbnail} + +Once your certificate(s) are configured, you can create an HTTPS frontend, on the same model as the HTTP frontend created above with port 443 and the *SSL* option enabled.
+Optionally, you can also enable the *HSTS* option. If this option is enabled, browsers will record that this website should *never again* be visited without HTTPS after their first visit in HTTPS. This strengthens overall security by protecting against "Man-in-the-middle" attacks in which a malicious actor could make your website appear unavailable in HTTPS and force your visitors to switch to "HTTP". > [!warning] +> Although the added security is significant, it is recommended to wait a while before enabling this option, to make sure there are no side effects in HTTPS. Indeed, once HSTS is enabled, there is no going back. > -> All though adding this additional level of security is important, we recommend waiting for a while before you enable this option, to ensure that there are no issues with your website forming HTTPS connections. Once HSTS has been enabled, you cannot undo the change. -> -### Via the API +#### From the OVHcloud API -- To list the SSL/TLS certificates in place: +- List the existing SSL/TLS certificates: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl > -- To view details on an SSL/TLS certificate: +- Get the details of an SSL/TLS certificate: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl/{id} > -- To add a new, existing SSL/TLS certificate: +- Adding a new existing SSL/TLS certificate: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/ssl > -- To modify a specific SSL/TLS certificate (only the display name can be modified): +- Modifying a specific SSL/TLS certificate (only the displayed name can be modified) : > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/ssl/{id} > -- To delete a specific SSL/TLS certificate: +- Deleting a specific SSL/TLS certificate: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/ssl/{id} > -## Apply the modifications +### Apply the changes -The modifications made to your OVHcloud Load Balancer must be *explicitly applied* in each of the zones configured for your OVHcloud Load Balancer service. Only then will they be visible to your website visitors. This way, you can make complex configuration changes in one go. +The changes made to your OVHcloud Load Balancer service must be *explicitly applied* in each of the zones configured for your OVHcloud Load Balancer service. Only then will they be visible to your visitors. This allows a complex configuration change to be made in a single step. -If you have several zones, you must apply the same configuration for each of them. +If you have several zones, you will have to apply the same configuration for each of your zones. -### Via the OVHcloud Control Panel. +#### From the OVHcloud Control Panel -Go to the page for your OVHcloud Load Balancer, and click `Apply configuration`{.action}. +Go to the home page of your OVHcloud Load Balancer service, click on the `...`{.action} dots next to the name of your service and click on `Apply the configuration`{.action}. -![Apply configuration](images/btn_apply_configuration.png){.thumbnail} +![Apply the configuration](images/btn_apply_configuration.png){.thumbnail} -Next, select the zones you want to deploy, and click `Apply configuration`{.action}. +Then select the list of zones you want to deploy and click on the `Apply the configuration`{.action} button. -![Apply configuration to zones](images/btn_apply_configuration_zones.png){.thumbnail} +![Apply the configuration zones](images/btn_apply_configuration_zones.png){.thumbnail} -### Via the API +#### From the OVHcloud API - Refresh a zone: @@ -343,11 +371,10 @@ Next, select the zones you want to deploy, and click `Apply configuration`{.acti > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/refresh > -## Confirmation +### Validation -Once you have completed all of these steps, you should have a functional load balancing service. You can check the service status by visiting your website. +Once all these steps are completed, you should have a functional load balancing service. You can validate the status of the service by visiting your site. ## Go further -Join our community of users on . - +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_http_https/guide.en-au.md b/pages/network/load_balancer/create_http_https/guide.en-au.md index 8b7a5b59a68..6a9e36c3a7e 100644 --- a/pages/network/load_balancer/create_http_https/guide.en-au.md +++ b/pages/network/load_balancer/create_http_https/guide.en-au.md @@ -1,81 +1,106 @@ --- -title: 'Configuring a HTTP/HTTPS OVH Load Balancer service' -excerpt: 'Find out how to configure an OVH Load Balancer service' -updated: 2023-11-22 +title: "Configuration of an OVHcloud Load Balancer service with HTTP/HTTPS" +excerpt: "Configure your OVHcloud Load Balancer to distribute HTTP traffic and secure your connections with HTTPS" +updated: 2025-11-12 --- -## Objective + -The purpose of this guide is to help you create your first HTTP/HTTPS service with the new OVHcloud Load Balancer solution. Here, we will set up a basic OVHcloud Load Balancer service configuration to balance the HTTP load for a service like a website. +## Objective -A front-end will be created to listen on port 80, while another listens on port 443 with an SSL/TLS certificate. These front-ends will be configured to direct their traffic to a common HTTP farm. This farm can have one or more servers, depending on the configuration you have chosen/adapted. +This guide aims to help you create your first HTTP/HTTPS service using the OVHcloud Load Balancer offer. We will configure a simple OVHcloud Load Balancer service to distribute HTTP traffic for a service, such as a website. -As a reminder, the OVHcloud Load Balancer has four primary components: +A frontend will be created to listen on port 80, while another will listen on port 443 with an SSL/TLS certificate. These frontends will be configured to direct their traffic to a common HTTP farm. This farm can have one or more servers, depending on the chosen / adapted configuration. -- `front-ends` -- server `farms` and their `servers` -- the advanced `routes` between the front-ends and server farms -- `SSL/TLS` connections that can encrypt TCP and/or HTTP connections +As a reminder, the OVHcloud Load Balancer service is composed of 4 elementary parts: -**This guide will show you how to configure an OVHcloud Load Balancer Service.** +- the `frontends`; +- the `farms` of servers and their `servers`; +- the advanced `routes` between Frontends and Server Farms; +- the `SSL/TLS` certificates allowing TCP and/or HTTP connections to be encrypted. ## Requirements -- an OVHcloud Load Balancer -- the ability to add and configure a farm, a server, a front-end and an SSL certificate +- Have an [OVHcloud Load balancer](/links/network/load-balancer) offer in your OVHcloud account +- You must be logged in to your [OVHcloud Control Panel](/links/manager) +- Have a configured farm +- Have a configured frontend +- Have an SSL certificate + +## Instructions -## Introduction +## Table of contents + +- [Add a server farm](#farm) +- [Add a server](#server) +- [Add a frontend](#frontend) +- [Add an SSL/TLS certificate](#certificate) +- [Apply the changes](#apply) +- [Validation](#validation) > [!warning] > -> This guide will take you through the steps required. Depending on the way you have designed your architecture, some configurations may vary. +> We will guide you through the different steps. Depending on your architecture choices, some configurations may differ. > -If you have not done so already, we recommend reading a general introduction to the OVHcloud Load Balancer service before you get started: [Introduction to the OVHcloud Load Balancer](/pages/network/load_balancer/use_presentation){.ref} +Before you start, it is recommended to consult the [OVHcloud Load Balancer presentation](/pages/network/load_balancer/use_presentation). > [!warning] > -> The order in which elements are created is important. In particular, the server farms must be configured before we can attach an SSL/TLS certificate or servers to them. The front-ends must be configured after the server farms in order to configure the front-end’s default farm. +> The order of element creation is important. In particular, server farms must be configured before being able to attach an SSL/TLS certificate or servers to them. Similarly, frontends must be configured after the server farms in order to be able to configure the frontend's default farm. > -In the control panel of the load balancer, you will see the features detailed below: +The features detailed below are accessible from the OVHcloud Control Panel: -![OVHcloud Load Balancer service](images/iplb_service.png){.thumbnail} +![OVHcloud Load Balancer Service](images/iplb_service.png){.thumbnail} -For more information on the Control Panel’s features, you can consult the following guide: [Managing the Load Balancer from the customer control panel](/pages/network/load_balancer/use-lb){.ref} +For more information about the features of the OVHcloud Control Panel, see the [Managing the Load Balancer service via the OVHcloud Control Panel](/pages/network/load_balancer/use-lb) page. -Similarly, this can be done via the OVHcloud API, in the section: +Via the OVHcloud API, use the following call: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing > -For more information on the API’s features, you can consult the following guide: [Load Balancer API Quick Reference](/pages/network/load_balancer/use_api_reference){.ref} - -## Add a server farm. +For more information on the API features, consult the page [API function details](/pages/network/load_balancer/use_api_details){.ref} -We will add a farm of HTTP servers to our service, which is the part that balances traffic on the servers. +### Add a server farm -### Via the OVHCloud Control Panel. +We will add an HTTP server farm to our service. This part is responsible for distributing traffic to the servers. -Log into the [OVHcloud Control Panel](/links/manager), click `Network`{.action} in the left-hand menu, then `Load Balancer`. Click on your load balancer service. +#### From the OVHcloud Control Panel -In the `Server farms`{.action} tab, click on the `Add a server farm`{.action} button. +In the `Server Farms`{.action} tab, click the `Add a server farm`{.action} button. -Fill in the fields. The only mandatory fields for a basic configuration are *Protocol* and *Datacentre*. We recommend explicitly defining a *Port* (generally port 80 for a web service). If no ports are specified, your OVHcloud Load Balancer will automatically use the same port as the corresponding front-end, and the probes will not be able to work as intended. +Fill in the fields. The only mandatory fields for a simple configuration are the *Protocol* and the *Datacentre*. It is recommended to explicitly define a *Port*, generally port 80 for a web service. If no port is specified, your OVHcloud Load Balancer will automatically use the same port as the corresponding frontend and the probes may not work as expected. -If you add several servers to your farm, we advise configuring an HTTP `availability probe`. When a probe is configured, the OVHcloud Load Balancer service can automatically disable a server that is down or under maintenance, so that your web users are not affected. +If you add several servers in your farm, it is recommended to configure an HTTP `availability probe`. When a probe is configured, the OVHcloud Load Balancer service can automatically disable a server that is down or under maintenance, in order not to affect visitors. -![Add a server farm via the Control Panel](images/add_backend.png){.thumbnail} +![Adding a server farm via the OVHcloud Control Panel](images/add_backend.png){.thumbnail} -Click `Add`{.action} once you have filled in the fields. +Click the `Add`{.action} button once you have filled in the fields. -Your server farm should appear in the list, in the `Server farms`{.action} tab. +Your server farm should appear in the list, under the `Server Farms`{.action} tab. -![Details of the server farm created](images/resume_backend.png){.thumbnail} +![Details of the created server farm](images/resume_backend.png){.thumbnail} -### Via the API +#### From the OVHcloud API - List of HTTP server farms: @@ -91,48 +116,46 @@ Your server farm should appear in the list, in the `Server farms`{.action} tab. > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/farm/{farmId} > -- Add a new HTTP server farm: +- Adding a new HTTP server farm: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/http/farm > -- Modify a specific server farm: +- Modifying a specific server farm: > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/farm/{farmId} > -- Delete a specific server farm: +- Deleting a specific server farm: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/farm/{farmId} > -## Add a server. +### Add a server We will now add a server to our server farm. -### Via the OVHcloud Control Panel. - -Log into the [OVHcloud Control Panel](/links/manager), click `Network`{.action} in the left-hand menu, then `Load Balancer`. Click on your load balancer service. +#### From the OVHcloud Control Panel -In the `Server farms`{.action} tab, select the farm you want to add a server to by clicking on the corresponding line. The list of servers already configured in the farm will appear beneath the list of farms, along with the `Add a server`{.action} button. Click on this button to add a new server. +Still in the `Server Farms`{.action} tab, select the farm to which you want to add a server by clicking on the corresponding line. The list of servers already configured in the farm appears below the list of farms, as well as the `Add a server`{.action} button. Click on this button to add a new server. -Only the *IPv4 address* field is mandatory. If a server does not use the same port as the one defined earlier in the farm, you may overload it by configuring a server. However, to keep the configuration as standardised and easy to maintain as possible, we recommend only using this parameter in advanced cases. +Only the *IPv4 Address* field is mandatory. If a server does not use the same port as the one defined above in the farm, it is possible to override it in the server configuration. However, in order to maintain the most homogeneous and maintainable configuration possible, it is recommended to use this parameter only in advanced cases. -![Add a server to a farm.](images/add_server.png){.thumbnail} +![Adding a server to a Farm.](images/add_server.png){.thumbnail} -Click `Add`{.action} once you have filled in the fields. +Click the `Add`{.action} button once you have filled in the fields. -Your server should appear in the server list, in the `Server farm`{.action} tab, just below the list of farms. +Your server should appear in the list of servers, in the `Server Farms`{.action} tab, just below the list of farms. -![Details of the server created.](images/resume_server.png){.thumbnail} +![Details of the created server.](images/resume_server.png){.thumbnail} -### Via the API +#### From the OVHcloud API - List of servers in the farm: @@ -148,193 +171,198 @@ Your server should appear in the server list, in the `Server farm`{.action} tab, > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server/{serverId} > -- Add a new server: +- Adding a new server: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server > -- Modify a specific server: +- Modifying a specific server: > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server > -- Delete a specific server: +- Deleting a specific server: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server > -## Add a front-end. +### Add a frontend -We will now add a `front-end` to our service, and connect it to our server farm. The front-end is the part of your OVHcloud Load Balancer that exposes your service on the internet. First, we will only configure it in HTTP, without an SSL/TLS certificate. +We will now add a `frontend` to our service and connect it to our server farm. The frontend is the part of your OVHcloud Load Balancer that is used to expose your service on the Internet. At first, we will configure it in HTTP only, without an SSL/TLS certificate. -### Via the OVHcloud Control Panel. +#### From the OVHcloud Control Panel -Go to the `Front-ends`{.action} tab, and click `Add a front-end`{.action}. +In the `Frontends`{.action} tab, click the `Add a frontend`{.action} button. -Fill in the fields. The only mandatory fields for a basic configuration are *Protocol*, *Port* (80 for a standard HTTP web service) and *Datacentre*. If you want your service to be available across several ports at once, you can specify a list of ports, separated by commas, or a range of ports, in the format "START_PORT-END_PORT". +Fill in the fields. The only mandatory fields for a simple configuration are the *Protocol*, the *Port* (80 for a standard HTTP web service) and the *Datacentre*. If you want your service to be available on several ports at the same time, you can specify a list of ports separated by commas or a range of ports in the form "START_PORT-END_PORT". -If you have routed Additional IPs to your OVHcloud Load Balancer service, you can also attach a front-end to one or more specific Additional IPs. +If you have routed Additional IPs to your OVHcloud Load Balancer service, you can also attach a frontend to one or more specific Additional IPs. -![Add a front-end](images/add_frontend.png){.thumbnail} +![Adding a frontend](images/add_frontend.png){.thumbnail} -Click `Add`{.action} once you have filled in the fields. +Click the `Add`{.action} button once you have filled in the fields. -Your front-end must appear in the list, in the `Front-ends`{.action} tab. +Your frontend should appear in the list, under the `Frontends`{.action} tab. -![Details of the front-end created](images/resume_frontend.png){.thumbnail} +![Details of the created frontend](images/resume_frontend.png){.thumbnail} -### Via the API +#### From the OVHcloud API -- List of HTTP front-ends: +- List of HTTP frontends: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/frontend > -- Details of a specific front-end: +- Details of a specific frontend: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} > -- Add a new front-end: +- Adding a new frontend: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/http/frontend > -- Modify a specific front-end: +- Modifying a specific frontend: > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} > -- Delete a specific front-end: +- Deleting a specific frontend: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} > -## Add an SSL/TLS certificate. +### Add an SSL/TLS certificate -The section above described the general configuration of a HTTP front-end. This next section describes the additional steps you need to take to activate support of HTTPS protocol on an HTTP front-end. In particular, you need to: +The previous section described the general configuration for an HTTP frontend. This section describes the additional steps to enable support for the HTTPS protocol on an HTTP frontend. In particular, you will need to: -- switch over the front-end to port 443, which is standard for HTTPS protocol -- configure an SSL/TLS certificate to authenticate and encrypt connections +- switch the frontend to port 443, the standard port for the HTTPS protocol; +- configure an SSL/TLS certificate to authenticate and encrypt the connections. -Whether you choose to configure your service via the API or the OVHcloud Control Panel, you can choose from two methods for adding an SSL/TLS certificate. The choice of method will depend on your needs, as well as the solutions currently set up. You can either: +Whether you choose a configuration via the API or via the OVHcloud Control Panel, you will have a choice between 2 strategies for your SSL/TLS certificates. This choice depends on your needs as well as the current solutions in place: - Import an existing SSL/TLS certificate. -- Order an automatically managed SSL/TLS certificate. DV and EV certificates will be available to order soon. +- Order an automatically managed SSL/TLS certificate. The ordering of DV and EV certificates will be available soon. -If you choose to import an SSL/TLS certificate that you have already ordered and managed yourself, you will need to renew it periodically yourself, and update it in your OVHcloud Load Balancer service. Most certificates are valid for one year. Some remain valid for longer periods of time. However, Let's Encrypt certificates need to be renewed every three months. We recommend using your OVHcloud Load Balancer to automatically manage the service for Let’s Encrypt certificates, so that you do not miss the expiry dates. +If you choose to import an SSL/TLS certificate that you have ordered and managed yourself, you will have to renew it periodically yourself and update it in your OVHcloud Load Balancer service. Most certificates are valid for 1 year. Some may be valid for longer. Let's Encrypt certificates are valid for 3 months. It is recommended to use the service managed automatically by your OVHcloud Load Balancer for Let's Encrypt certificates in order not to accidentally miss a deadline. -If you opt for a certificate managed by the OVHcloud Load Balancer service, it will be automatically ordered, validated, installed and renewed periodically by your OVHcloud Load Balancer. For the validation and renewal operations to work, the domains you are ordering this certificate for need to be routed to your OVHcloud Load Balancer service. This means that your domain’s *A* and *AAAA* DNS records must point to your OVHcloud Load Balancer’s IPv4 and IPv6 fields respectively, or to one of its Additional IPs. When you order, you will receive an email that will guide you through the validation steps. +If you choose a certificate managed by your OVHcloud Load Balancer service, it will be automatically ordered, validated, installed and renewed periodically by your OVHcloud Load Balancer.
+For the validation and renewal operations to work, the domain(s) you are ordering this certificate for must be routed to your OVHcloud Load Balancer service. This implies that the *A* and *AAAA* fields of your domain point respectively to the IPv4 and IPv6 of your OVHcloud Load Balancer or one of its Additional IPs. During the order, you will receive an email that will guide you through the validation steps. +> [!primary] > -> To ensure that your service remains accessible when you switch your domain to your OVHcloud Load Balancer service’s IP address in order to validate your certificate, it is good practice to start by configuring and testing all of the HTTP configuration on port 80. This way, your website will remain accessible without any interruptions. -> If the website already has a HTTPS connection and you want to switch to certificates managed by your OVHcloud Load Balancer service, you can import your existing certificates, configure and test your HTTPS front-end, and order a new certificate for the same domain. It will be taken into account automatically when your old certificate expires. +> To ensure service continuity when switching your domain to the IP of your OVHcloud Load Balancer service to validate your certificate, a good practice is to first configure and fully test the HTTP configuration on port 80. This way, your site remains accessible without interruption. +> If your site already has an HTTPS connection and you want to migrate to certificates managed by your OVHcloud Load Balancer service, you can import your existing certificates, configure and test your HTTPS Frontend and finally order a new certificate for the same domain. It will be automatically taken into account before your old certificate expires. > -The certificates configured on your OVHcloud Load Balancer service are automatically available for all of the front-ends on your service that have *SSL* options enabled. +The certificates configured on your OVHcloud Load Balancer service are automatically available for all frontends of your OVHcloud Load Balancer service on which the *SSL* option is enabled. #### TLS 1.3 support -With the constant evolution of Internet security standards, OVHcloud is committed to providing the latest and most secure technologies for your services. The OVHcloud Load Balancer now supports TLS 1.3. -##### What is TLS 1.3? -TLS 1.3 is the latest version of the TLS protocol, offering significant improvements in security and performance over TLS 1.2. Key benefits include a faster handshake process, reducing the time needed to establish secure connections, and the use of more secure cipher suites to strengthen the security of transmitted data. +With the constant evolution of security standards on the Internet, OVHcloud is committed to providing the most recent and secure technologies for your services. The OVHcloud Load Balancer now supports TLS 1.3. -##### Why use TLS 1.3 with OVHcloud Load Balancer? -By integrating TLS 1.3, your OVHcloud Load Balancer will benefit from enhanced security and improved performance, ensuring an optimal user experience for your visitors. Reduced handshake times speed up page loading, while security enhancements ensure that your data is protected with the latest, most secure standards. +##### **What is TLS 1.3?** -### Via the OVHcloud Control Panel. +TLS 1.3 is the latest version of the TLS protocol, offering significant improvements in terms of security and performance compared to TLS 1.2. The key advantages include a faster *handshake* process, thus reducing the time needed to establish secure connections, and the use of safer encryption suites to strengthen the security of transmitted data. -The list of SSL/TLS certificates configured on the OVHcloud Load Balancer can be found in the `SSL certificates`{.action} tab. In this interface, you can select one of the two options mentioned further up, i.e. importing an existing certificate (`Add an SSL certificate`{.action}) and (`Order an SSL certificate`{.action}) managed automatically by your OVHcloud Load Balancer. +##### **Why use TLS 1.3 with OVHcloud Load Balancer?** -![Buttons for adding certificates](images/certificat.png){.thumbnail} +By integrating TLS 1.3, your OVHcloud Load Balancer will benefit from enhanced security and improved performance, ensuring an optimal user experience for your visitors. The reduction in *handshake* time speeds up page loading, while the security improvements ensure that your data is protected with the most recent and secure standards. -If you choose to import an existing SSL/TLS certificate, click `Add an SSL certificate`{.action}. The *Private key* and *Certificate* fields are obligatory. +#### From the OVHcloud Control Panel -Click `Add`{.action} once you have filled in the fields. Your certificate will appear in the certificate list. +The list of SSL/TLS certificates configured on your OVHcloud Load Balancer service is in the `SSL Certificates`{.action} tab. This interface offers the 2 options mentioned above, namely importing an existing certificate (via the `Add an SSL certificate`{.action} button) and `Order an SSL certificate`{.action} managed automatically by your OVHcloud Load Balancer service. -![Add an existing SSL certificate](images/add_certificat_custom.png){.thumbnail} +![Certificate addition buttons](images/certificat.png){.thumbnail} -To add a Let's Encrypt certificate, click `Order an SSL certificate`{.action}, enter your domains, ensure that they point to your OVHcloud Load Balancer, and follow the instructions set out in the guides you receive. You will then see it appear in the list of available certificates. +If you choose to import an existing SSL/TLS certificate, click on `Add an SSL certificate`{.action}. The *Private Key* and *Certificate* fields are mandatory. -![Order a Let’s Encrypt certificate](images/add_certificat_letsencrypt.png){.thumbnail} +Click the `Add`{.action} button once the fields are filled in. Your certificate will then appear in the certificate list. -Once your certificates have been configured, you can create a HTTPS front-end, on the same model as the HTTP front-end created earlier on with port 443, and the *SSL* option enabled. You can also choose to enable the *HSTS* option. With this option enabled, web browsers will remember that this website should *no longer* be visited without HTTPS after the first time the web user visits in HTTPS. This way, you can improve your infrastructure’s overall security by protecting it against ‘man-in-the-middle’ attacks, where a malicious party can make it seem as though your website is not available in HTTPS, forcing your web users to switch to HTTP. +![Adding an existing certificate](images/add_certificat_custom.png){.thumbnail} + +To add a Let's Encrypt certificate, click on `Order an SSL certificate`{.action}, enter your domain, make sure it points to your OVHcloud Load Balancer service and follow the emails you receive. You will then see it appear in the list of available certificates. + +![Ordering a Let's Encrypt certificate](images/add_certificat_letsencrypt.png){.thumbnail} + +Once your certificate(s) are configured, you can create an HTTPS frontend, on the same model as the HTTP frontend created above with port 443 and the *SSL* option enabled.
+Optionally, you can also enable the *HSTS* option. If this option is enabled, browsers will record that this website should *never again* be visited without HTTPS after their first visit in HTTPS. This strengthens overall security by protecting against "Man-in-the-middle" attacks in which a malicious actor could make your website appear unavailable in HTTPS and force your visitors to switch to "HTTP". > [!warning] +> Although the added security is significant, it is recommended to wait a while before enabling this option, to make sure there are no side effects in HTTPS. Indeed, once HSTS is enabled, there is no going back. > -> All though adding this additional level of security is important, we recommend waiting for a while before you enable this option, to ensure that there are no issues with your website forming HTTPS connections. Once HSTS has been enabled, you cannot undo the change. -> -### Via the API +#### From the OVHcloud API -- To list the SSL/TLS certificates in place: +- List the existing SSL/TLS certificates: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl > -- To view details on an SSL/TLS certificate: +- Get the details of an SSL/TLS certificate: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl/{id} > -- To add a new, existing SSL/TLS certificate: +- Adding a new existing SSL/TLS certificate: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/ssl > -- To modify a specific SSL/TLS certificate (only the display name can be modified): +- Modifying a specific SSL/TLS certificate (only the displayed name can be modified) : > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/ssl/{id} > -- To delete a specific SSL/TLS certificate: +- Deleting a specific SSL/TLS certificate: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/ssl/{id} > -## Apply the modifications +### Apply the changes -The modifications made to your OVHcloud Load Balancer must be *explicitly applied* in each of the zones configured for your OVHcloud Load Balancer service. Only then will they be visible to your website visitors. This way, you can make complex configuration changes in one go. +The changes made to your OVHcloud Load Balancer service must be *explicitly applied* in each of the zones configured for your OVHcloud Load Balancer service. Only then will they be visible to your visitors. This allows a complex configuration change to be made in a single step. -If you have several zones, you must apply the same configuration for each of them. +If you have several zones, you will have to apply the same configuration for each of your zones. -### Via the OVHcloud Control Panel. +#### From the OVHcloud Control Panel -Go to the page for your OVHcloud Load Balancer, and click `Apply configuration`{.action}. +Go to the home page of your OVHcloud Load Balancer service, click on the `...`{.action} dots next to the name of your service and click on `Apply the configuration`{.action}. -![Apply configuration](images/btn_apply_configuration.png){.thumbnail} +![Apply the configuration](images/btn_apply_configuration.png){.thumbnail} -Next, select the zones you want to deploy, and click `Apply configuration`{.action}. +Then select the list of zones you want to deploy and click on the `Apply the configuration`{.action} button. -![Apply configuration to zones](images/btn_apply_configuration_zones.png){.thumbnail} +![Apply the configuration zones](images/btn_apply_configuration_zones.png){.thumbnail} -### Via the API +#### From the OVHcloud API - Refresh a zone: @@ -343,11 +371,10 @@ Next, select the zones you want to deploy, and click `Apply configuration`{.acti > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/refresh > -## Confirmation +### Validation -Once you have completed all of these steps, you should have a functional load balancing service. You can check the service status by visiting your website. +Once all these steps are completed, you should have a functional load balancing service. You can validate the status of the service by visiting your site. ## Go further -Join our community of users on . - +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_http_https/guide.en-ca.md b/pages/network/load_balancer/create_http_https/guide.en-ca.md index 8fb7329b659..6a9e36c3a7e 100644 --- a/pages/network/load_balancer/create_http_https/guide.en-ca.md +++ b/pages/network/load_balancer/create_http_https/guide.en-ca.md @@ -1,81 +1,106 @@ --- -title: 'Configuring a HTTP/HTTPS OVH Load Balancer service' -excerpt: 'Find out how to configure an OVH Load Balancer service' -updated: 2023-11-22 +title: "Configuration of an OVHcloud Load Balancer service with HTTP/HTTPS" +excerpt: "Configure your OVHcloud Load Balancer to distribute HTTP traffic and secure your connections with HTTPS" +updated: 2025-11-12 --- -## Objective + -The purpose of this guide is to help you create your first HTTP/HTTPS service with the new OVHcloud Load Balancer solution. Here, we will set up a basic OVHcloud Load Balancer service configuration to balance the HTTP load for a service like a website. +## Objective -A front-end will be created to listen on port 80, while another listens on port 443 with an SSL/TLS certificate. These front-ends will be configured to direct their traffic to a common HTTP farm. This farm can have one or more servers, depending on the configuration you have chosen/adapted. +This guide aims to help you create your first HTTP/HTTPS service using the OVHcloud Load Balancer offer. We will configure a simple OVHcloud Load Balancer service to distribute HTTP traffic for a service, such as a website. -As a reminder, the OVHcloud Load Balancer has four primary components: +A frontend will be created to listen on port 80, while another will listen on port 443 with an SSL/TLS certificate. These frontends will be configured to direct their traffic to a common HTTP farm. This farm can have one or more servers, depending on the chosen / adapted configuration. -- `front-ends` -- server `farms` and their `servers` -- the advanced `routes` between the front-ends and server farms -- `SSL/TLS` connections that can encrypt TCP and/or HTTP connections +As a reminder, the OVHcloud Load Balancer service is composed of 4 elementary parts: -**This guide will show you how to configure an OVHcloud Load Balancer Service.** +- the `frontends`; +- the `farms` of servers and their `servers`; +- the advanced `routes` between Frontends and Server Farms; +- the `SSL/TLS` certificates allowing TCP and/or HTTP connections to be encrypted. ## Requirements -- an OVHcloud Load Balancer -- the ability to add and configure a farm, a server, a front-end and an SSL certificate +- Have an [OVHcloud Load balancer](/links/network/load-balancer) offer in your OVHcloud account +- You must be logged in to your [OVHcloud Control Panel](/links/manager) +- Have a configured farm +- Have a configured frontend +- Have an SSL certificate + +## Instructions -## Introduction +## Table of contents + +- [Add a server farm](#farm) +- [Add a server](#server) +- [Add a frontend](#frontend) +- [Add an SSL/TLS certificate](#certificate) +- [Apply the changes](#apply) +- [Validation](#validation) > [!warning] > -> This guide will take you through the steps required. Depending on the way you have designed your architecture, some configurations may vary. +> We will guide you through the different steps. Depending on your architecture choices, some configurations may differ. > -If you have not done so already, we recommend reading a general introduction to the OVHcloud Load Balancer service before you get started: [Introduction to the OVHcloud Load Balancer](/pages/network/load_balancer/use_presentation){.ref} +Before you start, it is recommended to consult the [OVHcloud Load Balancer presentation](/pages/network/load_balancer/use_presentation). > [!warning] > -> The order in which elements are created is important. In particular, the server farms must be configured before we can attach an SSL/TLS certificate or servers to them. The front-ends must be configured after the server farms in order to configure the front-end’s default farm. +> The order of element creation is important. In particular, server farms must be configured before being able to attach an SSL/TLS certificate or servers to them. Similarly, frontends must be configured after the server farms in order to be able to configure the frontend's default farm. > -In the control panel of the load balancer, you will see the features detailed below: +The features detailed below are accessible from the OVHcloud Control Panel: -![OVHcloud Load Balancer service](images/iplb_service.png){.thumbnail} +![OVHcloud Load Balancer Service](images/iplb_service.png){.thumbnail} -For more information on the Control Panel’s features, you can consult the following guide: [Managing the Load Balancer from the customer control panel](/pages/network/load_balancer/use-lb){.ref} +For more information about the features of the OVHcloud Control Panel, see the [Managing the Load Balancer service via the OVHcloud Control Panel](/pages/network/load_balancer/use-lb) page. -Similarly, this can be done via the OVHcloud API, in the section: +Via the OVHcloud API, use the following call: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing > -For more information on the API’s features, you can consult the following guide: [Load Balancer API Quick Reference](/pages/network/load_balancer/use_api_reference){.ref} - -## Add a server farm. +For more information on the API features, consult the page [API function details](/pages/network/load_balancer/use_api_details){.ref} -We will add a farm of HTTP servers to our service, which is the part that balances traffic on the servers. +### Add a server farm -### Via the OVHCloud Control Panel. +We will add an HTTP server farm to our service. This part is responsible for distributing traffic to the servers. -Log into the [OVHcloud Control Panel](/links/manager), click `Network`{.action} in the left-hand menu, then `Load Balancer`. Click on your load balancer service. +#### From the OVHcloud Control Panel -In the `Server farms`{.action} tab, click on the `Add a server farm`{.action} button. +In the `Server Farms`{.action} tab, click the `Add a server farm`{.action} button. -Fill in the fields. The only mandatory fields for a basic configuration are *Protocol* and *Datacentre*. We recommend explicitly defining a *Port* (generally port 80 for a web service). If no ports are specified, your OVHcloud Load Balancer will automatically use the same port as the corresponding front-end, and the probes will not be able to work as intended. +Fill in the fields. The only mandatory fields for a simple configuration are the *Protocol* and the *Datacentre*. It is recommended to explicitly define a *Port*, generally port 80 for a web service. If no port is specified, your OVHcloud Load Balancer will automatically use the same port as the corresponding frontend and the probes may not work as expected. -If you add several servers to your farm, we advise configuring an HTTP `availability probe`. When a probe is configured, the OVHcloud Load Balancer service can automatically disable a server that is down or under maintenance, so that your web users are not affected. +If you add several servers in your farm, it is recommended to configure an HTTP `availability probe`. When a probe is configured, the OVHcloud Load Balancer service can automatically disable a server that is down or under maintenance, in order not to affect visitors. -![Add a server farm via the Control Panel](images/add_backend.png){.thumbnail} +![Adding a server farm via the OVHcloud Control Panel](images/add_backend.png){.thumbnail} -Click `Add`{.action} once you have filled in the fields. +Click the `Add`{.action} button once you have filled in the fields. -Your server farm should appear in the list, in the `Server farms`{.action} tab. +Your server farm should appear in the list, under the `Server Farms`{.action} tab. -![Details of the server farm created](images/resume_backend.png){.thumbnail} +![Details of the created server farm](images/resume_backend.png){.thumbnail} -### Via the API +#### From the OVHcloud API - List of HTTP server farms: @@ -91,48 +116,46 @@ Your server farm should appear in the list, in the `Server farms`{.action} tab. > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/farm/{farmId} > -- Add a new HTTP server farm: +- Adding a new HTTP server farm: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/http/farm > -- Modify a specific server farm: +- Modifying a specific server farm: > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/farm/{farmId} > -- Delete a specific server farm: +- Deleting a specific server farm: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/farm/{farmId} > -## Add a server. +### Add a server We will now add a server to our server farm. -### Via the OVHcloud Control Panel. +#### From the OVHcloud Control Panel -Log into the [OVHcloud Control Panel](/links/manager), click `Network`{.action} in the left-hand menu, then `Load Balancer`. Click on your load balancer service. +Still in the `Server Farms`{.action} tab, select the farm to which you want to add a server by clicking on the corresponding line. The list of servers already configured in the farm appears below the list of farms, as well as the `Add a server`{.action} button. Click on this button to add a new server. -In the `Server farms`{.action} tab, select the farm you want to add a server to by clicking on the corresponding line. The list of servers already configured in the farm will appear beneath the list of farms, along with the `Add a server`{.action} button. Click on this button to add a new server. +Only the *IPv4 Address* field is mandatory. If a server does not use the same port as the one defined above in the farm, it is possible to override it in the server configuration. However, in order to maintain the most homogeneous and maintainable configuration possible, it is recommended to use this parameter only in advanced cases. -Only the *IPv4 address* field is mandatory. If a server does not use the same port as the one defined earlier in the farm, you may overload it by configuring a server. However, to keep the configuration as standardised and easy to maintain as possible, we recommend only using this parameter in advanced cases. +![Adding a server to a Farm.](images/add_server.png){.thumbnail} -![Add a server to a farm.](images/add_server.png){.thumbnail} +Click the `Add`{.action} button once you have filled in the fields. -Click `Add`{.action} once you have filled in the fields. +Your server should appear in the list of servers, in the `Server Farms`{.action} tab, just below the list of farms. -Your server should appear in the server list, in the `Server farm`{.action} tab, just below the list of farms. +![Details of the created server.](images/resume_server.png){.thumbnail} -![Details of the server created.](images/resume_server.png){.thumbnail} - -### Via the API +#### From the OVHcloud API - List of servers in the farm: @@ -148,193 +171,198 @@ Your server should appear in the server list, in the `Server farm`{.action} tab, > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server/{serverId} > -- Add a new server: +- Adding a new server: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server > -- Modify a specific server: +- Modifying a specific server: > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server > -- Delete a specific server: +- Deleting a specific server: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server > -## Add a front-end. +### Add a frontend -We will now add a `front-end` to our service, and connect it to our server farm. The front-end is the part of your OVHcloud Load Balancer that exposes your service on the internet. First, we will only configure it in HTTP, without an SSL/TLS certificate. +We will now add a `frontend` to our service and connect it to our server farm. The frontend is the part of your OVHcloud Load Balancer that is used to expose your service on the Internet. At first, we will configure it in HTTP only, without an SSL/TLS certificate. -### Via the OVHcloud Control Panel. +#### From the OVHcloud Control Panel -Go to the `Front-ends`{.action} tab, and click `Add a front-end`{.action}. +In the `Frontends`{.action} tab, click the `Add a frontend`{.action} button. -Fill in the fields. The only mandatory fields for a basic configuration are *Protocol*, *Port* (80 for a standard HTTP web service) and *Datacentre*. If you want your service to be available across several ports at once, you can specify a list of ports, separated by commas, or a range of ports, in the format "START_PORT-END_PORT". +Fill in the fields. The only mandatory fields for a simple configuration are the *Protocol*, the *Port* (80 for a standard HTTP web service) and the *Datacentre*. If you want your service to be available on several ports at the same time, you can specify a list of ports separated by commas or a range of ports in the form "START_PORT-END_PORT". -If you have routed Additional IPs to your OVHcloud Load Balancer service, you can also attach a front-end to one or more specific Additional IPs. +If you have routed Additional IPs to your OVHcloud Load Balancer service, you can also attach a frontend to one or more specific Additional IPs. -![Add a front-end](images/add_frontend.png){.thumbnail} +![Adding a frontend](images/add_frontend.png){.thumbnail} -Click `Add`{.action} once you have filled in the fields. +Click the `Add`{.action} button once you have filled in the fields. -Your front-end must appear in the list, in the `Front-ends`{.action} tab. +Your frontend should appear in the list, under the `Frontends`{.action} tab. -![Details of the front-end created](images/resume_frontend.png){.thumbnail} +![Details of the created frontend](images/resume_frontend.png){.thumbnail} -### Via the API +#### From the OVHcloud API -- List of HTTP front-ends: +- List of HTTP frontends: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/frontend > -- Details of a specific front-end: +- Details of a specific frontend: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} > -- Add a new front-end: +- Adding a new frontend: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/http/frontend > -- Modify a specific front-end: +- Modifying a specific frontend: > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} > -- Delete a specific front-end: +- Deleting a specific frontend: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} > -## Add an SSL/TLS certificate. +### Add an SSL/TLS certificate -The section above described the general configuration of a HTTP front-end. This next section describes the additional steps you need to take to activate support of HTTPS protocol on an HTTP front-end. In particular, you need to: +The previous section described the general configuration for an HTTP frontend. This section describes the additional steps to enable support for the HTTPS protocol on an HTTP frontend. In particular, you will need to: -- switch over the front-end to port 443, which is standard for HTTPS protocol -- configure an SSL/TLS certificate to authenticate and encrypt connections +- switch the frontend to port 443, the standard port for the HTTPS protocol; +- configure an SSL/TLS certificate to authenticate and encrypt the connections. -Whether you choose to configure your service via the API or the OVHcloud Control Panel, you can choose from two methods for adding an SSL/TLS certificate. The choice of method will depend on your needs, as well as the solutions currently set up. You can either: +Whether you choose a configuration via the API or via the OVHcloud Control Panel, you will have a choice between 2 strategies for your SSL/TLS certificates. This choice depends on your needs as well as the current solutions in place: - Import an existing SSL/TLS certificate. -- Order an automatically managed SSL/TLS certificate. DV and EV certificates will be available to order soon. +- Order an automatically managed SSL/TLS certificate. The ordering of DV and EV certificates will be available soon. -If you choose to import an SSL/TLS certificate that you have already ordered and managed yourself, you will need to renew it periodically yourself, and update it in your OVHcloud Load Balancer service. Most certificates are valid for one year. Some remain valid for longer periods of time. However, Let's Encrypt certificates need to be renewed every three months. We recommend using your OVHcloud Load Balancer to automatically manage the service for Let’s Encrypt certificates, so that you do not miss the expiry dates. +If you choose to import an SSL/TLS certificate that you have ordered and managed yourself, you will have to renew it periodically yourself and update it in your OVHcloud Load Balancer service. Most certificates are valid for 1 year. Some may be valid for longer. Let's Encrypt certificates are valid for 3 months. It is recommended to use the service managed automatically by your OVHcloud Load Balancer for Let's Encrypt certificates in order not to accidentally miss a deadline. -If you opt for a certificate managed by the OVHcloud Load Balancer service, it will be automatically ordered, validated, installed and renewed periodically by your OVHcloud Load Balancer. For the validation and renewal operations to work, the domains you are ordering this certificate for need to be routed to your OVHcloud Load Balancer service. This means that your domain’s *A* and *AAAA* DNS records must point to your OVHcloud Load Balancer’s IPv4 and IPv6 fields respectively, or to one of its Additional IPs. When you order, you will receive an email that will guide you through the validation steps. +If you choose a certificate managed by your OVHcloud Load Balancer service, it will be automatically ordered, validated, installed and renewed periodically by your OVHcloud Load Balancer.
+For the validation and renewal operations to work, the domain(s) you are ordering this certificate for must be routed to your OVHcloud Load Balancer service. This implies that the *A* and *AAAA* fields of your domain point respectively to the IPv4 and IPv6 of your OVHcloud Load Balancer or one of its Additional IPs. During the order, you will receive an email that will guide you through the validation steps. +> [!primary] > -> To ensure that your service remains accessible when you switch your domain to your OVHcloud Load Balancer service’s IP address in order to validate your certificate, it is good practice to start by configuring and testing all of the HTTP configuration on port 80. This way, your website will remain accessible without any interruptions. -> If the website already has a HTTPS connection and you want to switch to certificates managed by your OVHcloud Load Balancer service, you can import your existing certificates, configure and test your HTTPS front-end, and order a new certificate for the same domain. It will be taken into account automatically when your old certificate expires. +> To ensure service continuity when switching your domain to the IP of your OVHcloud Load Balancer service to validate your certificate, a good practice is to first configure and fully test the HTTP configuration on port 80. This way, your site remains accessible without interruption. +> If your site already has an HTTPS connection and you want to migrate to certificates managed by your OVHcloud Load Balancer service, you can import your existing certificates, configure and test your HTTPS Frontend and finally order a new certificate for the same domain. It will be automatically taken into account before your old certificate expires. > -The certificates configured on your OVHcloud Load Balancer service are automatically available for all of the front-ends on your service that have *SSL* options enabled. +The certificates configured on your OVHcloud Load Balancer service are automatically available for all frontends of your OVHcloud Load Balancer service on which the *SSL* option is enabled. #### TLS 1.3 support -With the constant evolution of Internet security standards, OVHcloud is committed to providing the latest and most secure technologies for your services. The OVHcloud Load Balancer now supports TLS 1.3. -##### What is TLS 1.3? -TLS 1.3 is the latest version of the TLS protocol, offering significant improvements in security and performance over TLS 1.2. Key benefits include a faster handshake process, reducing the time needed to establish secure connections, and the use of more secure cipher suites to strengthen the security of transmitted data. +With the constant evolution of security standards on the Internet, OVHcloud is committed to providing the most recent and secure technologies for your services. The OVHcloud Load Balancer now supports TLS 1.3. + +##### **What is TLS 1.3?** + +TLS 1.3 is the latest version of the TLS protocol, offering significant improvements in terms of security and performance compared to TLS 1.2. The key advantages include a faster *handshake* process, thus reducing the time needed to establish secure connections, and the use of safer encryption suites to strengthen the security of transmitted data. -##### Why use TLS 1.3 with OVHcloud Load Balancer? -By integrating TLS 1.3, your OVHcloud Load Balancer will benefit from enhanced security and improved performance, ensuring an optimal user experience for your visitors. Reduced handshake times speed up page loading, while security enhancements ensure that your data is protected with the latest, most secure standards. +##### **Why use TLS 1.3 with OVHcloud Load Balancer?** -### Via the OVHcloud Control Panel. +By integrating TLS 1.3, your OVHcloud Load Balancer will benefit from enhanced security and improved performance, ensuring an optimal user experience for your visitors. The reduction in *handshake* time speeds up page loading, while the security improvements ensure that your data is protected with the most recent and secure standards. -The list of SSL/TLS certificates configured on the OVHcloud Load Balancer can be found in the `SSL certificates`{.action} tab. In this interface, you can select one of the two options mentioned further up, i.e. importing an existing certificate (`Add an SSL certificate`{.action}) and (`Order an SSL certificate`{.action}) managed automatically by your OVHcloud Load Balancer. +#### From the OVHcloud Control Panel -![Buttons for adding certificates](images/certificat.png){.thumbnail} +The list of SSL/TLS certificates configured on your OVHcloud Load Balancer service is in the `SSL Certificates`{.action} tab. This interface offers the 2 options mentioned above, namely importing an existing certificate (via the `Add an SSL certificate`{.action} button) and `Order an SSL certificate`{.action} managed automatically by your OVHcloud Load Balancer service. -If you choose to import an existing SSL/TLS certificate, click `Add an SSL certificate`{.action}. The *Private key* and *Certificate* fields are obligatory. +![Certificate addition buttons](images/certificat.png){.thumbnail} -Click `Add`{.action} once you have filled in the fields. Your certificate will appear in the certificate list. +If you choose to import an existing SSL/TLS certificate, click on `Add an SSL certificate`{.action}. The *Private Key* and *Certificate* fields are mandatory. -![Add an existing SSL certificate](images/add_certificat_custom.png){.thumbnail} +Click the `Add`{.action} button once the fields are filled in. Your certificate will then appear in the certificate list. -To add a Let's Encrypt certificate, click `Order an SSL certificate`{.action}, enter your domains, ensure that they point to your OVHcloud Load Balancer, and follow the instructions set out in the guides you receive. You will then see it appear in the list of available certificates. +![Adding an existing certificate](images/add_certificat_custom.png){.thumbnail} -![Order a Let’s Encrypt certificate](images/add_certificat_letsencrypt.png){.thumbnail} +To add a Let's Encrypt certificate, click on `Order an SSL certificate`{.action}, enter your domain, make sure it points to your OVHcloud Load Balancer service and follow the emails you receive. You will then see it appear in the list of available certificates. -Once your certificates have been configured, you can create a HTTPS front-end, on the same model as the HTTP front-end created earlier on with port 443, and the *SSL* option enabled. You can also choose to enable the *HSTS* option. With this option enabled, web browsers will remember that this website should *no longer* be visited without HTTPS after the first time the web user visits in HTTPS. This way, you can improve your infrastructure’s overall security by protecting it against ‘man-in-the-middle’ attacks, where a malicious party can make it seem as though your website is not available in HTTPS, forcing your web users to switch to HTTP. +![Ordering a Let's Encrypt certificate](images/add_certificat_letsencrypt.png){.thumbnail} + +Once your certificate(s) are configured, you can create an HTTPS frontend, on the same model as the HTTP frontend created above with port 443 and the *SSL* option enabled.
+Optionally, you can also enable the *HSTS* option. If this option is enabled, browsers will record that this website should *never again* be visited without HTTPS after their first visit in HTTPS. This strengthens overall security by protecting against "Man-in-the-middle" attacks in which a malicious actor could make your website appear unavailable in HTTPS and force your visitors to switch to "HTTP". > [!warning] +> Although the added security is significant, it is recommended to wait a while before enabling this option, to make sure there are no side effects in HTTPS. Indeed, once HSTS is enabled, there is no going back. > -> All though adding this additional level of security is important, we recommend waiting for a while before you enable this option, to ensure that there are no issues with your website forming HTTPS connections. Once HSTS has been enabled, you cannot undo the change. -> -### Via the API +#### From the OVHcloud API -- To list the SSL/TLS certificates in place: +- List the existing SSL/TLS certificates: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl > -- To view details on an SSL/TLS certificate: +- Get the details of an SSL/TLS certificate: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl/{id} > -- To add a new, existing SSL/TLS certificate: +- Adding a new existing SSL/TLS certificate: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/ssl > -- To modify a specific SSL/TLS certificate (only the display name can be modified): +- Modifying a specific SSL/TLS certificate (only the displayed name can be modified) : > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/ssl/{id} > -- To delete a specific SSL/TLS certificate: +- Deleting a specific SSL/TLS certificate: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/ssl/{id} > -## Apply the modifications +### Apply the changes -The modifications made to your OVHcloud Load Balancer must be *explicitly applied* in each of the zones configured for your OVHcloud Load Balancer service. Only then will they be visible to your website visitors. This way, you can make complex configuration changes in one go. +The changes made to your OVHcloud Load Balancer service must be *explicitly applied* in each of the zones configured for your OVHcloud Load Balancer service. Only then will they be visible to your visitors. This allows a complex configuration change to be made in a single step. -If you have several zones, you must apply the same configuration for each of them. +If you have several zones, you will have to apply the same configuration for each of your zones. -### Via the OVHcloud Control Panel. +#### From the OVHcloud Control Panel -Go to the page for your OVHcloud Load Balancer, and click `Apply configuration`{.action}. +Go to the home page of your OVHcloud Load Balancer service, click on the `...`{.action} dots next to the name of your service and click on `Apply the configuration`{.action}. -![Apply configuration](images/btn_apply_configuration.png){.thumbnail} +![Apply the configuration](images/btn_apply_configuration.png){.thumbnail} -Next, select the zones you want to deploy, and click `Apply configuration`{.action}. +Then select the list of zones you want to deploy and click on the `Apply the configuration`{.action} button. -![Apply configuration to zones](images/btn_apply_configuration_zones.png){.thumbnail} +![Apply the configuration zones](images/btn_apply_configuration_zones.png){.thumbnail} -### Via the API +#### From the OVHcloud API - Refresh a zone: @@ -343,10 +371,10 @@ Next, select the zones you want to deploy, and click `Apply configuration`{.acti > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/refresh > -## Confirmation +### Validation -Once you have completed all of these steps, you should have a functional load balancing service. You can check the service status by visiting your website. +Once all these steps are completed, you should have a functional load balancing service. You can validate the status of the service by visiting your site. ## Go further -Join our community of users on . \ No newline at end of file +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_http_https/guide.en-gb.md b/pages/network/load_balancer/create_http_https/guide.en-gb.md index 8fb7329b659..1840964e7a0 100644 --- a/pages/network/load_balancer/create_http_https/guide.en-gb.md +++ b/pages/network/load_balancer/create_http_https/guide.en-gb.md @@ -1,81 +1,106 @@ --- -title: 'Configuring a HTTP/HTTPS OVH Load Balancer service' -excerpt: 'Find out how to configure an OVH Load Balancer service' -updated: 2023-11-22 +title: "Configuration of an OVHcloud Load Balancer service with HTTP/HTTPS" +excerpt: "Configure your OVHcloud Load Balancer to distribute HTTP traffic and secure your connections with HTTPS" +updated: 2025-11-12 --- -## Objective + -The purpose of this guide is to help you create your first HTTP/HTTPS service with the new OVHcloud Load Balancer solution. Here, we will set up a basic OVHcloud Load Balancer service configuration to balance the HTTP load for a service like a website. +## Objective -A front-end will be created to listen on port 80, while another listens on port 443 with an SSL/TLS certificate. These front-ends will be configured to direct their traffic to a common HTTP farm. This farm can have one or more servers, depending on the configuration you have chosen/adapted. +This guide aims to help you create your first HTTP/HTTPS service using the OVHcloud Load Balancer offer. We will configure a simple OVHcloud Load Balancer service to distribute HTTP traffic for a service, such as a website. -As a reminder, the OVHcloud Load Balancer has four primary components: +A frontend will be created to listen on port 80, while another will listen on port 443 with an SSL/TLS certificate. These frontends will be configured to direct their traffic to a common HTTP farm. This farm can have one or more servers, depending on the chosen / adapted configuration. -- `front-ends` -- server `farms` and their `servers` -- the advanced `routes` between the front-ends and server farms -- `SSL/TLS` connections that can encrypt TCP and/or HTTP connections +As a reminder, the OVHcloud Load Balancer service is composed of 4 elementary parts: -**This guide will show you how to configure an OVHcloud Load Balancer Service.** +- the `frontends`; +- the `farms` of servers and their `servers`; +- the advanced `routes` between Frontends and Server Farms; +- the `SSL/TLS` certificates allowing TCP and/or HTTP connections to be encrypted. ## Requirements -- an OVHcloud Load Balancer -- the ability to add and configure a farm, a server, a front-end and an SSL certificate +- Have an [OVHcloud Load balancer](/links/network/load-balancer) offer in your OVHcloud account +- You must be logged in to your [OVHcloud Control Panel](/links/manager) +- Have a configured farm +- Have a configured frontend +- Have an SSL certificate + +## Instructions -## Introduction +## Table of contents + +- [Add a server farm](#farm) +- [Add a server](#server) +- [Add a frontend](#frontend) +- [Add an SSL/TLS certificate](#certificate) +- [Apply the changes](#apply) +- [Validation](#validation) > [!warning] > -> This guide will take you through the steps required. Depending on the way you have designed your architecture, some configurations may vary. +> We will guide you through the different steps. Depending on your architecture choices, some configurations may differ. > -If you have not done so already, we recommend reading a general introduction to the OVHcloud Load Balancer service before you get started: [Introduction to the OVHcloud Load Balancer](/pages/network/load_balancer/use_presentation){.ref} +Before you start, it is recommended to consult the [OVHcloud Load Balancer presentation](/pages/network/load_balancer/use_presentation). > [!warning] > -> The order in which elements are created is important. In particular, the server farms must be configured before we can attach an SSL/TLS certificate or servers to them. The front-ends must be configured after the server farms in order to configure the front-end’s default farm. +> The order of element creation is important. In particular, server farms must be configured before being able to attach an SSL/TLS certificate or servers to them. Similarly, frontends must be configured after the server farms in order to be able to configure the frontend's default farm. > -In the control panel of the load balancer, you will see the features detailed below: +The features detailed below are accessible from the OVHcloud Control Panel: -![OVHcloud Load Balancer service](images/iplb_service.png){.thumbnail} +![OVHcloud Load Balancer Service](images/iplb_service.png){.thumbnail} -For more information on the Control Panel’s features, you can consult the following guide: [Managing the Load Balancer from the customer control panel](/pages/network/load_balancer/use-lb){.ref} +For more information about the features of the OVHcloud Control Panel, see the [Managing the Load Balancer service via the OVHcloud Control Panel](/pages/network/load_balancer/use-lb) page. -Similarly, this can be done via the OVHcloud API, in the section: +Via the OVHcloud API, use the following call: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing > -For more information on the API’s features, you can consult the following guide: [Load Balancer API Quick Reference](/pages/network/load_balancer/use_api_reference){.ref} - -## Add a server farm. +For more information on the API features, consult the page [API function details](/pages/network/load_balancer/use_api_details){.ref} -We will add a farm of HTTP servers to our service, which is the part that balances traffic on the servers. +### Add a server farm -### Via the OVHCloud Control Panel. +We will add an HTTP server farm to our service. This part is responsible for distributing traffic to the servers. -Log into the [OVHcloud Control Panel](/links/manager), click `Network`{.action} in the left-hand menu, then `Load Balancer`. Click on your load balancer service. +#### From the OVHcloud Control Panel -In the `Server farms`{.action} tab, click on the `Add a server farm`{.action} button. +In the `Server Farms`{.action} tab, click the `Add a server farm`{.action} button. -Fill in the fields. The only mandatory fields for a basic configuration are *Protocol* and *Datacentre*. We recommend explicitly defining a *Port* (generally port 80 for a web service). If no ports are specified, your OVHcloud Load Balancer will automatically use the same port as the corresponding front-end, and the probes will not be able to work as intended. +Fill in the fields. The only mandatory fields for a simple configuration are the *Protocol* and the *Datacentre*. It is recommended to explicitly define a *Port*, generally port 80 for a web service. If no port is specified, your OVHcloud Load Balancer will automatically use the same port as the corresponding frontend and the probes may not work as expected. -If you add several servers to your farm, we advise configuring an HTTP `availability probe`. When a probe is configured, the OVHcloud Load Balancer service can automatically disable a server that is down or under maintenance, so that your web users are not affected. +If you add several servers in your farm, it is recommended to configure an HTTP `availability probe`. When a probe is configured, the OVHcloud Load Balancer service can automatically disable a server that is down or under maintenance, in order not to affect visitors. -![Add a server farm via the Control Panel](images/add_backend.png){.thumbnail} +![Adding a server farm via the OVHcloud Control Panel](images/add_backend.png){.thumbnail} -Click `Add`{.action} once you have filled in the fields. +Click the `Add`{.action} button once you have filled in the fields. -Your server farm should appear in the list, in the `Server farms`{.action} tab. +Your server farm should appear in the list, under the `Server Farms`{.action} tab. -![Details of the server farm created](images/resume_backend.png){.thumbnail} +![Details of the created server farm](images/resume_backend.png){.thumbnail} -### Via the API +#### From the OVHcloud API - List of HTTP server farms: @@ -91,48 +116,46 @@ Your server farm should appear in the list, in the `Server farms`{.action} tab. > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/farm/{farmId} > -- Add a new HTTP server farm: +- Adding a new HTTP server farm: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/http/farm > -- Modify a specific server farm: +- Modifying a specific server farm: > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/farm/{farmId} > -- Delete a specific server farm: +- Deleting a specific server farm: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/farm/{farmId} > -## Add a server. +### Add a server We will now add a server to our server farm. -### Via the OVHcloud Control Panel. +#### From the OVHcloud Control Panel -Log into the [OVHcloud Control Panel](/links/manager), click `Network`{.action} in the left-hand menu, then `Load Balancer`. Click on your load balancer service. +Still in the `Server Farms`{.action} tab, select the farm to which you want to add a server by clicking on the corresponding line. The list of servers already configured in the farm appears below the list of farms, as well as the `Add a server`{.action} button. Click on this button to add a new server. -In the `Server farms`{.action} tab, select the farm you want to add a server to by clicking on the corresponding line. The list of servers already configured in the farm will appear beneath the list of farms, along with the `Add a server`{.action} button. Click on this button to add a new server. +Only the *IPv4 Address* field is mandatory. If a server does not use the same port as the one defined above in the farm, it is possible to override it in the server configuration. However, in order to maintain the most homogeneous and maintainable configuration possible, it is recommended to use this parameter only in advanced cases. -Only the *IPv4 address* field is mandatory. If a server does not use the same port as the one defined earlier in the farm, you may overload it by configuring a server. However, to keep the configuration as standardised and easy to maintain as possible, we recommend only using this parameter in advanced cases. +![Adding a server to a Farm.](images/add_server.png){.thumbnail} -![Add a server to a farm.](images/add_server.png){.thumbnail} +Click the `Add`{.action} button once you have filled in the fields. -Click `Add`{.action} once you have filled in the fields. +Your server should appear in the list of servers, in the `Server Farms`{.action} tab, just below the list of farms. -Your server should appear in the server list, in the `Server farm`{.action} tab, just below the list of farms. +![Details of the created server.](images/resume_server.png){.thumbnail} -![Details of the server created.](images/resume_server.png){.thumbnail} - -### Via the API +#### From the OVHcloud API - List of servers in the farm: @@ -148,193 +171,198 @@ Your server should appear in the server list, in the `Server farm`{.action} tab, > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server/{serverId} > -- Add a new server: +- Adding a new server: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server > -- Modify a specific server: +- Modifying a specific server: > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server > -- Delete a specific server: +- Deleting a specific server: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server > -## Add a front-end. +### Add a frontend -We will now add a `front-end` to our service, and connect it to our server farm. The front-end is the part of your OVHcloud Load Balancer that exposes your service on the internet. First, we will only configure it in HTTP, without an SSL/TLS certificate. +We will now add a `frontend` to our service and connect it to our server farm. The frontend is the part of your OVHcloud Load Balancer that is used to expose your service on the Internet. At first, we will configure it in HTTP only, without an SSL/TLS certificate. -### Via the OVHcloud Control Panel. +#### From the OVHcloud Control Panel -Go to the `Front-ends`{.action} tab, and click `Add a front-end`{.action}. +In the `Frontends`{.action} tab, click the `Add a frontend`{.action} button. -Fill in the fields. The only mandatory fields for a basic configuration are *Protocol*, *Port* (80 for a standard HTTP web service) and *Datacentre*. If you want your service to be available across several ports at once, you can specify a list of ports, separated by commas, or a range of ports, in the format "START_PORT-END_PORT". +Fill in the fields. The only mandatory fields for a simple configuration are the *Protocol*, the *Port* (80 for a standard HTTP web service) and the *Datacentre*. If you want your service to be available on several ports at the same time, you can specify a list of ports separated by commas or a range of ports in the form "START_PORT-END_PORT". -If you have routed Additional IPs to your OVHcloud Load Balancer service, you can also attach a front-end to one or more specific Additional IPs. +If you have routed Additional IPs to your OVHcloud Load Balancer service, you can also attach a frontend to one or more specific Additional IPs. -![Add a front-end](images/add_frontend.png){.thumbnail} +![Adding a frontend](images/add_frontend.png){.thumbnail} -Click `Add`{.action} once you have filled in the fields. +Click the `Add`{.action} button once you have filled in the fields. -Your front-end must appear in the list, in the `Front-ends`{.action} tab. +Your frontend should appear in the list, under the `Frontends`{.action} tab. -![Details of the front-end created](images/resume_frontend.png){.thumbnail} +![Details of the created frontend](images/resume_frontend.png){.thumbnail} -### Via the API +#### From the OVHcloud API -- List of HTTP front-ends: +- List of HTTP frontends: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/frontend > -- Details of a specific front-end: +- Details of a specific frontend: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} > -- Add a new front-end: +- Adding a new frontend: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/http/frontend > -- Modify a specific front-end: +- Modifying a specific frontend: > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} > -- Delete a specific front-end: +- Deleting a specific frontend: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} > -## Add an SSL/TLS certificate. +### Add an SSL/TLS certificate -The section above described the general configuration of a HTTP front-end. This next section describes the additional steps you need to take to activate support of HTTPS protocol on an HTTP front-end. In particular, you need to: +The previous section described the general configuration for an HTTP frontend. This section describes the additional steps to enable support for the HTTPS protocol on an HTTP frontend. In particular, you will need to: -- switch over the front-end to port 443, which is standard for HTTPS protocol -- configure an SSL/TLS certificate to authenticate and encrypt connections +- switch the frontend to port 443, the standard port for the HTTPS protocol; +- configure an SSL/TLS certificate to authenticate and encrypt the connections. -Whether you choose to configure your service via the API or the OVHcloud Control Panel, you can choose from two methods for adding an SSL/TLS certificate. The choice of method will depend on your needs, as well as the solutions currently set up. You can either: +Whether you choose a configuration via the API or via the OVHcloud Control Panel, you will have a choice between 2 strategies for your SSL/TLS certificates. This choice depends on your needs as well as the current solutions in place: - Import an existing SSL/TLS certificate. -- Order an automatically managed SSL/TLS certificate. DV and EV certificates will be available to order soon. +- Order an automatically managed SSL/TLS certificate. The ordering of DV and EV certificates will be available soon. -If you choose to import an SSL/TLS certificate that you have already ordered and managed yourself, you will need to renew it periodically yourself, and update it in your OVHcloud Load Balancer service. Most certificates are valid for one year. Some remain valid for longer periods of time. However, Let's Encrypt certificates need to be renewed every three months. We recommend using your OVHcloud Load Balancer to automatically manage the service for Let’s Encrypt certificates, so that you do not miss the expiry dates. +If you choose to import an SSL/TLS certificate that you have ordered and managed yourself, you will have to renew it periodically yourself and update it in your OVHcloud Load Balancer service. Most certificates are valid for 1 year. Some may be valid for longer. Let's Encrypt certificates are valid for 3 months. It is recommended to use the service managed automatically by your OVHcloud Load Balancer for Let's Encrypt certificates in order not to accidentally miss a deadline. -If you opt for a certificate managed by the OVHcloud Load Balancer service, it will be automatically ordered, validated, installed and renewed periodically by your OVHcloud Load Balancer. For the validation and renewal operations to work, the domains you are ordering this certificate for need to be routed to your OVHcloud Load Balancer service. This means that your domain’s *A* and *AAAA* DNS records must point to your OVHcloud Load Balancer’s IPv4 and IPv6 fields respectively, or to one of its Additional IPs. When you order, you will receive an email that will guide you through the validation steps. +If you choose a certificate managed by your OVHcloud Load Balancer service, it will be automatically ordered, validated, installed and renewed periodically by your OVHcloud Load Balancer.
+For the validation and renewal operations to work, the domain(s) you are ordering this certificate for must be routed to your OVHcloud Load Balancer service. This implies that the *A* and *AAAA* fields of your domain point respectively to the IPv4 and IPv6 of your OVHcloud Load Balancer or one of its Additional IPs. During the order, you will receive an email that will guide you through the validation steps. +> [!primary] > -> To ensure that your service remains accessible when you switch your domain to your OVHcloud Load Balancer service’s IP address in order to validate your certificate, it is good practice to start by configuring and testing all of the HTTP configuration on port 80. This way, your website will remain accessible without any interruptions. -> If the website already has a HTTPS connection and you want to switch to certificates managed by your OVHcloud Load Balancer service, you can import your existing certificates, configure and test your HTTPS front-end, and order a new certificate for the same domain. It will be taken into account automatically when your old certificate expires. +> To ensure service continuity when switching your domain to the IP of your OVHcloud Load Balancer service to validate your certificate, a good practice is to first configure and fully test the HTTP configuration on port 80. This way, your site remains accessible without interruption. +> If your site already has an HTTPS connection and you want to migrate to certificates managed by your OVHcloud Load Balancer service, you can import your existing certificates, configure and test your HTTPS Frontend and finally order a new certificate for the same domain. It will be automatically taken into account before your old certificate expires. > -The certificates configured on your OVHcloud Load Balancer service are automatically available for all of the front-ends on your service that have *SSL* options enabled. +The certificates configured on your OVHcloud Load Balancer service are automatically available for all frontends of your OVHcloud Load Balancer service on which the *SSL* option is enabled. #### TLS 1.3 support -With the constant evolution of Internet security standards, OVHcloud is committed to providing the latest and most secure technologies for your services. The OVHcloud Load Balancer now supports TLS 1.3. -##### What is TLS 1.3? -TLS 1.3 is the latest version of the TLS protocol, offering significant improvements in security and performance over TLS 1.2. Key benefits include a faster handshake process, reducing the time needed to establish secure connections, and the use of more secure cipher suites to strengthen the security of transmitted data. +With the constant evolution of security standards on the Internet, OVHcloud is committed to providing the most recent and secure technologies for your services. The OVHcloud Load Balancer now supports TLS 1.3. + +##### **What is TLS 1.3?** + +TLS 1.3 is the latest version of the TLS protocol, offering significant improvements in terms of security and performance compared to TLS 1.2. The key advantages include a faster *handshake* process, thus reducing the time needed to establish secure connections, and the use of safer encryption suites to strengthen the security of transmitted data. -##### Why use TLS 1.3 with OVHcloud Load Balancer? -By integrating TLS 1.3, your OVHcloud Load Balancer will benefit from enhanced security and improved performance, ensuring an optimal user experience for your visitors. Reduced handshake times speed up page loading, while security enhancements ensure that your data is protected with the latest, most secure standards. +##### **Why use TLS 1.3 with OVHcloud Load Balancer?** -### Via the OVHcloud Control Panel. +By integrating TLS 1.3, your OVHcloud Load Balancer will benefit from enhanced security and improved performance, ensuring an optimal user experience for your visitors. The reduction in *handshake* time speeds up page loading, while the security improvements ensure that your data is protected with the most recent and secure standards. -The list of SSL/TLS certificates configured on the OVHcloud Load Balancer can be found in the `SSL certificates`{.action} tab. In this interface, you can select one of the two options mentioned further up, i.e. importing an existing certificate (`Add an SSL certificate`{.action}) and (`Order an SSL certificate`{.action}) managed automatically by your OVHcloud Load Balancer. +#### From the OVHcloud Control Panel -![Buttons for adding certificates](images/certificat.png){.thumbnail} +The list of SSL/TLS certificates configured on your OVHcloud Load Balancer service is in the `SSL Certificates`{.action} tab. This interface offers the 2 options mentioned above, namely importing an existing certificate (via the `Add an SSL certificate`{.action} button) and `Order an SSL certificate`{.action} managed automatically by your OVHcloud Load Balancer service. -If you choose to import an existing SSL/TLS certificate, click `Add an SSL certificate`{.action}. The *Private key* and *Certificate* fields are obligatory. +![Certificate addition buttons](images/certificat.png){.thumbnail} -Click `Add`{.action} once you have filled in the fields. Your certificate will appear in the certificate list. +If you choose to import an existing SSL/TLS certificate, click on `Add an SSL certificate`{.action}. The *Private Key* and *Certificate* fields are mandatory. -![Add an existing SSL certificate](images/add_certificat_custom.png){.thumbnail} +Click the `Add`{.action} button once the fields are filled in. Your certificate will then appear in the certificate list. -To add a Let's Encrypt certificate, click `Order an SSL certificate`{.action}, enter your domains, ensure that they point to your OVHcloud Load Balancer, and follow the instructions set out in the guides you receive. You will then see it appear in the list of available certificates. +![Adding an existing certificate](images/add_certificat_custom.png){.thumbnail} -![Order a Let’s Encrypt certificate](images/add_certificat_letsencrypt.png){.thumbnail} +To add a Let's Encrypt certificate, click on `Order an SSL certificate`{.action}, enter your domain, make sure it points to your OVHcloud Load Balancer service and follow the emails you receive. You will then see it appear in the list of available certificates. -Once your certificates have been configured, you can create a HTTPS front-end, on the same model as the HTTP front-end created earlier on with port 443, and the *SSL* option enabled. You can also choose to enable the *HSTS* option. With this option enabled, web browsers will remember that this website should *no longer* be visited without HTTPS after the first time the web user visits in HTTPS. This way, you can improve your infrastructure’s overall security by protecting it against ‘man-in-the-middle’ attacks, where a malicious party can make it seem as though your website is not available in HTTPS, forcing your web users to switch to HTTP. +![Ordering a Let's Encrypt certificate](images/add_certificat_letsencrypt.png){.thumbnail} + +Once your certificate(s) are configured, you can create an HTTPS frontend, on the same model as the HTTP frontend created above with port 443 and the *SSL* option enabled.
+Optionally, you can also enable the *HSTS* option. If this option is enabled, browsers will record that this website should *never again* be visited without HTTPS after their first visit in HTTPS. This strengthens overall security by protecting against "Man-in-the-middle" attacks in which a malicious actor could make your website appear unavailable in HTTPS and force your visitors to switch to "HTTP". > [!warning] +> Although the added security is significant, it is recommended to wait a while before enabling this option, to make sure there are no side effects in HTTPS. Indeed, once HSTS is enabled, there is no going back. > -> All though adding this additional level of security is important, we recommend waiting for a while before you enable this option, to ensure that there are no issues with your website forming HTTPS connections. Once HSTS has been enabled, you cannot undo the change. -> -### Via the API +#### From the OVHcloud API -- To list the SSL/TLS certificates in place: +- List the existing SSL/TLS certificates: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl > -- To view details on an SSL/TLS certificate: +- Get the details of an SSL/TLS certificate: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl/{id} > -- To add a new, existing SSL/TLS certificate: +- Adding a new existing SSL/TLS certificate: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/ssl > -- To modify a specific SSL/TLS certificate (only the display name can be modified): +- Modifying a specific SSL/TLS certificate (only the displayed name can be modified) : > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/ssl/{id} > -- To delete a specific SSL/TLS certificate: +- Deleting a specific SSL/TLS certificate: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/ssl/{id} > -## Apply the modifications +### Apply the changes -The modifications made to your OVHcloud Load Balancer must be *explicitly applied* in each of the zones configured for your OVHcloud Load Balancer service. Only then will they be visible to your website visitors. This way, you can make complex configuration changes in one go. +The changes made to your OVHcloud Load Balancer service must be *explicitly applied* in each of the zones configured for your OVHcloud Load Balancer service. Only then will they be visible to your visitors. This allows a complex configuration change to be made in a single step. -If you have several zones, you must apply the same configuration for each of them. +If you have several zones, you will have to apply the same configuration for each of your zones. -### Via the OVHcloud Control Panel. +#### From the OVHcloud Control Panel -Go to the page for your OVHcloud Load Balancer, and click `Apply configuration`{.action}. +Go to the home page of your OVHcloud Load Balancer service, click on the `...`{.action} dots next to the name of your service and click on `Apply the configuration`{.action}. -![Apply configuration](images/btn_apply_configuration.png){.thumbnail} +![Apply the configuration](images/btn_apply_configuration.png){.thumbnail} -Next, select the zones you want to deploy, and click `Apply configuration`{.action}. +Then select the list of zones you want to deploy and click on the `Apply the configuration`{.action} button. -![Apply configuration to zones](images/btn_apply_configuration_zones.png){.thumbnail} +![Apply the configuration zones](images/btn_apply_configuration_zones.png){.thumbnail} -### Via the API +#### From the OVHcloud API - Refresh a zone: @@ -343,10 +371,10 @@ Next, select the zones you want to deploy, and click `Apply configuration`{.acti > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/refresh > -## Confirmation +### Validation -Once you have completed all of these steps, you should have a functional load balancing service. You can check the service status by visiting your website. +Once all these steps are completed, you should have a functional load balancing service. You can validate the status of the service by visiting your site. ## Go further -Join our community of users on . \ No newline at end of file +Join our [community of users](/links/community). diff --git a/pages/network/load_balancer/create_http_https/guide.en-sg.md b/pages/network/load_balancer/create_http_https/guide.en-sg.md index 8fb7329b659..6a9e36c3a7e 100644 --- a/pages/network/load_balancer/create_http_https/guide.en-sg.md +++ b/pages/network/load_balancer/create_http_https/guide.en-sg.md @@ -1,81 +1,106 @@ --- -title: 'Configuring a HTTP/HTTPS OVH Load Balancer service' -excerpt: 'Find out how to configure an OVH Load Balancer service' -updated: 2023-11-22 +title: "Configuration of an OVHcloud Load Balancer service with HTTP/HTTPS" +excerpt: "Configure your OVHcloud Load Balancer to distribute HTTP traffic and secure your connections with HTTPS" +updated: 2025-11-12 --- -## Objective + -The purpose of this guide is to help you create your first HTTP/HTTPS service with the new OVHcloud Load Balancer solution. Here, we will set up a basic OVHcloud Load Balancer service configuration to balance the HTTP load for a service like a website. +## Objective -A front-end will be created to listen on port 80, while another listens on port 443 with an SSL/TLS certificate. These front-ends will be configured to direct their traffic to a common HTTP farm. This farm can have one or more servers, depending on the configuration you have chosen/adapted. +This guide aims to help you create your first HTTP/HTTPS service using the OVHcloud Load Balancer offer. We will configure a simple OVHcloud Load Balancer service to distribute HTTP traffic for a service, such as a website. -As a reminder, the OVHcloud Load Balancer has four primary components: +A frontend will be created to listen on port 80, while another will listen on port 443 with an SSL/TLS certificate. These frontends will be configured to direct their traffic to a common HTTP farm. This farm can have one or more servers, depending on the chosen / adapted configuration. -- `front-ends` -- server `farms` and their `servers` -- the advanced `routes` between the front-ends and server farms -- `SSL/TLS` connections that can encrypt TCP and/or HTTP connections +As a reminder, the OVHcloud Load Balancer service is composed of 4 elementary parts: -**This guide will show you how to configure an OVHcloud Load Balancer Service.** +- the `frontends`; +- the `farms` of servers and their `servers`; +- the advanced `routes` between Frontends and Server Farms; +- the `SSL/TLS` certificates allowing TCP and/or HTTP connections to be encrypted. ## Requirements -- an OVHcloud Load Balancer -- the ability to add and configure a farm, a server, a front-end and an SSL certificate +- Have an [OVHcloud Load balancer](/links/network/load-balancer) offer in your OVHcloud account +- You must be logged in to your [OVHcloud Control Panel](/links/manager) +- Have a configured farm +- Have a configured frontend +- Have an SSL certificate + +## Instructions -## Introduction +## Table of contents + +- [Add a server farm](#farm) +- [Add a server](#server) +- [Add a frontend](#frontend) +- [Add an SSL/TLS certificate](#certificate) +- [Apply the changes](#apply) +- [Validation](#validation) > [!warning] > -> This guide will take you through the steps required. Depending on the way you have designed your architecture, some configurations may vary. +> We will guide you through the different steps. Depending on your architecture choices, some configurations may differ. > -If you have not done so already, we recommend reading a general introduction to the OVHcloud Load Balancer service before you get started: [Introduction to the OVHcloud Load Balancer](/pages/network/load_balancer/use_presentation){.ref} +Before you start, it is recommended to consult the [OVHcloud Load Balancer presentation](/pages/network/load_balancer/use_presentation). > [!warning] > -> The order in which elements are created is important. In particular, the server farms must be configured before we can attach an SSL/TLS certificate or servers to them. The front-ends must be configured after the server farms in order to configure the front-end’s default farm. +> The order of element creation is important. In particular, server farms must be configured before being able to attach an SSL/TLS certificate or servers to them. Similarly, frontends must be configured after the server farms in order to be able to configure the frontend's default farm. > -In the control panel of the load balancer, you will see the features detailed below: +The features detailed below are accessible from the OVHcloud Control Panel: -![OVHcloud Load Balancer service](images/iplb_service.png){.thumbnail} +![OVHcloud Load Balancer Service](images/iplb_service.png){.thumbnail} -For more information on the Control Panel’s features, you can consult the following guide: [Managing the Load Balancer from the customer control panel](/pages/network/load_balancer/use-lb){.ref} +For more information about the features of the OVHcloud Control Panel, see the [Managing the Load Balancer service via the OVHcloud Control Panel](/pages/network/load_balancer/use-lb) page. -Similarly, this can be done via the OVHcloud API, in the section: +Via the OVHcloud API, use the following call: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing > -For more information on the API’s features, you can consult the following guide: [Load Balancer API Quick Reference](/pages/network/load_balancer/use_api_reference){.ref} - -## Add a server farm. +For more information on the API features, consult the page [API function details](/pages/network/load_balancer/use_api_details){.ref} -We will add a farm of HTTP servers to our service, which is the part that balances traffic on the servers. +### Add a server farm -### Via the OVHCloud Control Panel. +We will add an HTTP server farm to our service. This part is responsible for distributing traffic to the servers. -Log into the [OVHcloud Control Panel](/links/manager), click `Network`{.action} in the left-hand menu, then `Load Balancer`. Click on your load balancer service. +#### From the OVHcloud Control Panel -In the `Server farms`{.action} tab, click on the `Add a server farm`{.action} button. +In the `Server Farms`{.action} tab, click the `Add a server farm`{.action} button. -Fill in the fields. The only mandatory fields for a basic configuration are *Protocol* and *Datacentre*. We recommend explicitly defining a *Port* (generally port 80 for a web service). If no ports are specified, your OVHcloud Load Balancer will automatically use the same port as the corresponding front-end, and the probes will not be able to work as intended. +Fill in the fields. The only mandatory fields for a simple configuration are the *Protocol* and the *Datacentre*. It is recommended to explicitly define a *Port*, generally port 80 for a web service. If no port is specified, your OVHcloud Load Balancer will automatically use the same port as the corresponding frontend and the probes may not work as expected. -If you add several servers to your farm, we advise configuring an HTTP `availability probe`. When a probe is configured, the OVHcloud Load Balancer service can automatically disable a server that is down or under maintenance, so that your web users are not affected. +If you add several servers in your farm, it is recommended to configure an HTTP `availability probe`. When a probe is configured, the OVHcloud Load Balancer service can automatically disable a server that is down or under maintenance, in order not to affect visitors. -![Add a server farm via the Control Panel](images/add_backend.png){.thumbnail} +![Adding a server farm via the OVHcloud Control Panel](images/add_backend.png){.thumbnail} -Click `Add`{.action} once you have filled in the fields. +Click the `Add`{.action} button once you have filled in the fields. -Your server farm should appear in the list, in the `Server farms`{.action} tab. +Your server farm should appear in the list, under the `Server Farms`{.action} tab. -![Details of the server farm created](images/resume_backend.png){.thumbnail} +![Details of the created server farm](images/resume_backend.png){.thumbnail} -### Via the API +#### From the OVHcloud API - List of HTTP server farms: @@ -91,48 +116,46 @@ Your server farm should appear in the list, in the `Server farms`{.action} tab. > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/farm/{farmId} > -- Add a new HTTP server farm: +- Adding a new HTTP server farm: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/http/farm > -- Modify a specific server farm: +- Modifying a specific server farm: > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/farm/{farmId} > -- Delete a specific server farm: +- Deleting a specific server farm: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/farm/{farmId} > -## Add a server. +### Add a server We will now add a server to our server farm. -### Via the OVHcloud Control Panel. +#### From the OVHcloud Control Panel -Log into the [OVHcloud Control Panel](/links/manager), click `Network`{.action} in the left-hand menu, then `Load Balancer`. Click on your load balancer service. +Still in the `Server Farms`{.action} tab, select the farm to which you want to add a server by clicking on the corresponding line. The list of servers already configured in the farm appears below the list of farms, as well as the `Add a server`{.action} button. Click on this button to add a new server. -In the `Server farms`{.action} tab, select the farm you want to add a server to by clicking on the corresponding line. The list of servers already configured in the farm will appear beneath the list of farms, along with the `Add a server`{.action} button. Click on this button to add a new server. +Only the *IPv4 Address* field is mandatory. If a server does not use the same port as the one defined above in the farm, it is possible to override it in the server configuration. However, in order to maintain the most homogeneous and maintainable configuration possible, it is recommended to use this parameter only in advanced cases. -Only the *IPv4 address* field is mandatory. If a server does not use the same port as the one defined earlier in the farm, you may overload it by configuring a server. However, to keep the configuration as standardised and easy to maintain as possible, we recommend only using this parameter in advanced cases. +![Adding a server to a Farm.](images/add_server.png){.thumbnail} -![Add a server to a farm.](images/add_server.png){.thumbnail} +Click the `Add`{.action} button once you have filled in the fields. -Click `Add`{.action} once you have filled in the fields. +Your server should appear in the list of servers, in the `Server Farms`{.action} tab, just below the list of farms. -Your server should appear in the server list, in the `Server farm`{.action} tab, just below the list of farms. +![Details of the created server.](images/resume_server.png){.thumbnail} -![Details of the server created.](images/resume_server.png){.thumbnail} - -### Via the API +#### From the OVHcloud API - List of servers in the farm: @@ -148,193 +171,198 @@ Your server should appear in the server list, in the `Server farm`{.action} tab, > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server/{serverId} > -- Add a new server: +- Adding a new server: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server > -- Modify a specific server: +- Modifying a specific server: > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server > -- Delete a specific server: +- Deleting a specific server: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server > -## Add a front-end. +### Add a frontend -We will now add a `front-end` to our service, and connect it to our server farm. The front-end is the part of your OVHcloud Load Balancer that exposes your service on the internet. First, we will only configure it in HTTP, without an SSL/TLS certificate. +We will now add a `frontend` to our service and connect it to our server farm. The frontend is the part of your OVHcloud Load Balancer that is used to expose your service on the Internet. At first, we will configure it in HTTP only, without an SSL/TLS certificate. -### Via the OVHcloud Control Panel. +#### From the OVHcloud Control Panel -Go to the `Front-ends`{.action} tab, and click `Add a front-end`{.action}. +In the `Frontends`{.action} tab, click the `Add a frontend`{.action} button. -Fill in the fields. The only mandatory fields for a basic configuration are *Protocol*, *Port* (80 for a standard HTTP web service) and *Datacentre*. If you want your service to be available across several ports at once, you can specify a list of ports, separated by commas, or a range of ports, in the format "START_PORT-END_PORT". +Fill in the fields. The only mandatory fields for a simple configuration are the *Protocol*, the *Port* (80 for a standard HTTP web service) and the *Datacentre*. If you want your service to be available on several ports at the same time, you can specify a list of ports separated by commas or a range of ports in the form "START_PORT-END_PORT". -If you have routed Additional IPs to your OVHcloud Load Balancer service, you can also attach a front-end to one or more specific Additional IPs. +If you have routed Additional IPs to your OVHcloud Load Balancer service, you can also attach a frontend to one or more specific Additional IPs. -![Add a front-end](images/add_frontend.png){.thumbnail} +![Adding a frontend](images/add_frontend.png){.thumbnail} -Click `Add`{.action} once you have filled in the fields. +Click the `Add`{.action} button once you have filled in the fields. -Your front-end must appear in the list, in the `Front-ends`{.action} tab. +Your frontend should appear in the list, under the `Frontends`{.action} tab. -![Details of the front-end created](images/resume_frontend.png){.thumbnail} +![Details of the created frontend](images/resume_frontend.png){.thumbnail} -### Via the API +#### From the OVHcloud API -- List of HTTP front-ends: +- List of HTTP frontends: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/frontend > -- Details of a specific front-end: +- Details of a specific frontend: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} > -- Add a new front-end: +- Adding a new frontend: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/http/frontend > -- Modify a specific front-end: +- Modifying a specific frontend: > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} > -- Delete a specific front-end: +- Deleting a specific frontend: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} > -## Add an SSL/TLS certificate. +### Add an SSL/TLS certificate -The section above described the general configuration of a HTTP front-end. This next section describes the additional steps you need to take to activate support of HTTPS protocol on an HTTP front-end. In particular, you need to: +The previous section described the general configuration for an HTTP frontend. This section describes the additional steps to enable support for the HTTPS protocol on an HTTP frontend. In particular, you will need to: -- switch over the front-end to port 443, which is standard for HTTPS protocol -- configure an SSL/TLS certificate to authenticate and encrypt connections +- switch the frontend to port 443, the standard port for the HTTPS protocol; +- configure an SSL/TLS certificate to authenticate and encrypt the connections. -Whether you choose to configure your service via the API or the OVHcloud Control Panel, you can choose from two methods for adding an SSL/TLS certificate. The choice of method will depend on your needs, as well as the solutions currently set up. You can either: +Whether you choose a configuration via the API or via the OVHcloud Control Panel, you will have a choice between 2 strategies for your SSL/TLS certificates. This choice depends on your needs as well as the current solutions in place: - Import an existing SSL/TLS certificate. -- Order an automatically managed SSL/TLS certificate. DV and EV certificates will be available to order soon. +- Order an automatically managed SSL/TLS certificate. The ordering of DV and EV certificates will be available soon. -If you choose to import an SSL/TLS certificate that you have already ordered and managed yourself, you will need to renew it periodically yourself, and update it in your OVHcloud Load Balancer service. Most certificates are valid for one year. Some remain valid for longer periods of time. However, Let's Encrypt certificates need to be renewed every three months. We recommend using your OVHcloud Load Balancer to automatically manage the service for Let’s Encrypt certificates, so that you do not miss the expiry dates. +If you choose to import an SSL/TLS certificate that you have ordered and managed yourself, you will have to renew it periodically yourself and update it in your OVHcloud Load Balancer service. Most certificates are valid for 1 year. Some may be valid for longer. Let's Encrypt certificates are valid for 3 months. It is recommended to use the service managed automatically by your OVHcloud Load Balancer for Let's Encrypt certificates in order not to accidentally miss a deadline. -If you opt for a certificate managed by the OVHcloud Load Balancer service, it will be automatically ordered, validated, installed and renewed periodically by your OVHcloud Load Balancer. For the validation and renewal operations to work, the domains you are ordering this certificate for need to be routed to your OVHcloud Load Balancer service. This means that your domain’s *A* and *AAAA* DNS records must point to your OVHcloud Load Balancer’s IPv4 and IPv6 fields respectively, or to one of its Additional IPs. When you order, you will receive an email that will guide you through the validation steps. +If you choose a certificate managed by your OVHcloud Load Balancer service, it will be automatically ordered, validated, installed and renewed periodically by your OVHcloud Load Balancer.
+For the validation and renewal operations to work, the domain(s) you are ordering this certificate for must be routed to your OVHcloud Load Balancer service. This implies that the *A* and *AAAA* fields of your domain point respectively to the IPv4 and IPv6 of your OVHcloud Load Balancer or one of its Additional IPs. During the order, you will receive an email that will guide you through the validation steps. +> [!primary] > -> To ensure that your service remains accessible when you switch your domain to your OVHcloud Load Balancer service’s IP address in order to validate your certificate, it is good practice to start by configuring and testing all of the HTTP configuration on port 80. This way, your website will remain accessible without any interruptions. -> If the website already has a HTTPS connection and you want to switch to certificates managed by your OVHcloud Load Balancer service, you can import your existing certificates, configure and test your HTTPS front-end, and order a new certificate for the same domain. It will be taken into account automatically when your old certificate expires. +> To ensure service continuity when switching your domain to the IP of your OVHcloud Load Balancer service to validate your certificate, a good practice is to first configure and fully test the HTTP configuration on port 80. This way, your site remains accessible without interruption. +> If your site already has an HTTPS connection and you want to migrate to certificates managed by your OVHcloud Load Balancer service, you can import your existing certificates, configure and test your HTTPS Frontend and finally order a new certificate for the same domain. It will be automatically taken into account before your old certificate expires. > -The certificates configured on your OVHcloud Load Balancer service are automatically available for all of the front-ends on your service that have *SSL* options enabled. +The certificates configured on your OVHcloud Load Balancer service are automatically available for all frontends of your OVHcloud Load Balancer service on which the *SSL* option is enabled. #### TLS 1.3 support -With the constant evolution of Internet security standards, OVHcloud is committed to providing the latest and most secure technologies for your services. The OVHcloud Load Balancer now supports TLS 1.3. -##### What is TLS 1.3? -TLS 1.3 is the latest version of the TLS protocol, offering significant improvements in security and performance over TLS 1.2. Key benefits include a faster handshake process, reducing the time needed to establish secure connections, and the use of more secure cipher suites to strengthen the security of transmitted data. +With the constant evolution of security standards on the Internet, OVHcloud is committed to providing the most recent and secure technologies for your services. The OVHcloud Load Balancer now supports TLS 1.3. + +##### **What is TLS 1.3?** + +TLS 1.3 is the latest version of the TLS protocol, offering significant improvements in terms of security and performance compared to TLS 1.2. The key advantages include a faster *handshake* process, thus reducing the time needed to establish secure connections, and the use of safer encryption suites to strengthen the security of transmitted data. -##### Why use TLS 1.3 with OVHcloud Load Balancer? -By integrating TLS 1.3, your OVHcloud Load Balancer will benefit from enhanced security and improved performance, ensuring an optimal user experience for your visitors. Reduced handshake times speed up page loading, while security enhancements ensure that your data is protected with the latest, most secure standards. +##### **Why use TLS 1.3 with OVHcloud Load Balancer?** -### Via the OVHcloud Control Panel. +By integrating TLS 1.3, your OVHcloud Load Balancer will benefit from enhanced security and improved performance, ensuring an optimal user experience for your visitors. The reduction in *handshake* time speeds up page loading, while the security improvements ensure that your data is protected with the most recent and secure standards. -The list of SSL/TLS certificates configured on the OVHcloud Load Balancer can be found in the `SSL certificates`{.action} tab. In this interface, you can select one of the two options mentioned further up, i.e. importing an existing certificate (`Add an SSL certificate`{.action}) and (`Order an SSL certificate`{.action}) managed automatically by your OVHcloud Load Balancer. +#### From the OVHcloud Control Panel -![Buttons for adding certificates](images/certificat.png){.thumbnail} +The list of SSL/TLS certificates configured on your OVHcloud Load Balancer service is in the `SSL Certificates`{.action} tab. This interface offers the 2 options mentioned above, namely importing an existing certificate (via the `Add an SSL certificate`{.action} button) and `Order an SSL certificate`{.action} managed automatically by your OVHcloud Load Balancer service. -If you choose to import an existing SSL/TLS certificate, click `Add an SSL certificate`{.action}. The *Private key* and *Certificate* fields are obligatory. +![Certificate addition buttons](images/certificat.png){.thumbnail} -Click `Add`{.action} once you have filled in the fields. Your certificate will appear in the certificate list. +If you choose to import an existing SSL/TLS certificate, click on `Add an SSL certificate`{.action}. The *Private Key* and *Certificate* fields are mandatory. -![Add an existing SSL certificate](images/add_certificat_custom.png){.thumbnail} +Click the `Add`{.action} button once the fields are filled in. Your certificate will then appear in the certificate list. -To add a Let's Encrypt certificate, click `Order an SSL certificate`{.action}, enter your domains, ensure that they point to your OVHcloud Load Balancer, and follow the instructions set out in the guides you receive. You will then see it appear in the list of available certificates. +![Adding an existing certificate](images/add_certificat_custom.png){.thumbnail} -![Order a Let’s Encrypt certificate](images/add_certificat_letsencrypt.png){.thumbnail} +To add a Let's Encrypt certificate, click on `Order an SSL certificate`{.action}, enter your domain, make sure it points to your OVHcloud Load Balancer service and follow the emails you receive. You will then see it appear in the list of available certificates. -Once your certificates have been configured, you can create a HTTPS front-end, on the same model as the HTTP front-end created earlier on with port 443, and the *SSL* option enabled. You can also choose to enable the *HSTS* option. With this option enabled, web browsers will remember that this website should *no longer* be visited without HTTPS after the first time the web user visits in HTTPS. This way, you can improve your infrastructure’s overall security by protecting it against ‘man-in-the-middle’ attacks, where a malicious party can make it seem as though your website is not available in HTTPS, forcing your web users to switch to HTTP. +![Ordering a Let's Encrypt certificate](images/add_certificat_letsencrypt.png){.thumbnail} + +Once your certificate(s) are configured, you can create an HTTPS frontend, on the same model as the HTTP frontend created above with port 443 and the *SSL* option enabled.
+Optionally, you can also enable the *HSTS* option. If this option is enabled, browsers will record that this website should *never again* be visited without HTTPS after their first visit in HTTPS. This strengthens overall security by protecting against "Man-in-the-middle" attacks in which a malicious actor could make your website appear unavailable in HTTPS and force your visitors to switch to "HTTP". > [!warning] +> Although the added security is significant, it is recommended to wait a while before enabling this option, to make sure there are no side effects in HTTPS. Indeed, once HSTS is enabled, there is no going back. > -> All though adding this additional level of security is important, we recommend waiting for a while before you enable this option, to ensure that there are no issues with your website forming HTTPS connections. Once HSTS has been enabled, you cannot undo the change. -> -### Via the API +#### From the OVHcloud API -- To list the SSL/TLS certificates in place: +- List the existing SSL/TLS certificates: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl > -- To view details on an SSL/TLS certificate: +- Get the details of an SSL/TLS certificate: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl/{id} > -- To add a new, existing SSL/TLS certificate: +- Adding a new existing SSL/TLS certificate: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/ssl > -- To modify a specific SSL/TLS certificate (only the display name can be modified): +- Modifying a specific SSL/TLS certificate (only the displayed name can be modified) : > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/ssl/{id} > -- To delete a specific SSL/TLS certificate: +- Deleting a specific SSL/TLS certificate: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/ssl/{id} > -## Apply the modifications +### Apply the changes -The modifications made to your OVHcloud Load Balancer must be *explicitly applied* in each of the zones configured for your OVHcloud Load Balancer service. Only then will they be visible to your website visitors. This way, you can make complex configuration changes in one go. +The changes made to your OVHcloud Load Balancer service must be *explicitly applied* in each of the zones configured for your OVHcloud Load Balancer service. Only then will they be visible to your visitors. This allows a complex configuration change to be made in a single step. -If you have several zones, you must apply the same configuration for each of them. +If you have several zones, you will have to apply the same configuration for each of your zones. -### Via the OVHcloud Control Panel. +#### From the OVHcloud Control Panel -Go to the page for your OVHcloud Load Balancer, and click `Apply configuration`{.action}. +Go to the home page of your OVHcloud Load Balancer service, click on the `...`{.action} dots next to the name of your service and click on `Apply the configuration`{.action}. -![Apply configuration](images/btn_apply_configuration.png){.thumbnail} +![Apply the configuration](images/btn_apply_configuration.png){.thumbnail} -Next, select the zones you want to deploy, and click `Apply configuration`{.action}. +Then select the list of zones you want to deploy and click on the `Apply the configuration`{.action} button. -![Apply configuration to zones](images/btn_apply_configuration_zones.png){.thumbnail} +![Apply the configuration zones](images/btn_apply_configuration_zones.png){.thumbnail} -### Via the API +#### From the OVHcloud API - Refresh a zone: @@ -343,10 +371,10 @@ Next, select the zones you want to deploy, and click `Apply configuration`{.acti > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/refresh > -## Confirmation +### Validation -Once you have completed all of these steps, you should have a functional load balancing service. You can check the service status by visiting your website. +Once all these steps are completed, you should have a functional load balancing service. You can validate the status of the service by visiting your site. ## Go further -Join our community of users on . \ No newline at end of file +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_http_https/guide.en-us.md b/pages/network/load_balancer/create_http_https/guide.en-us.md index 8fb7329b659..6a9e36c3a7e 100644 --- a/pages/network/load_balancer/create_http_https/guide.en-us.md +++ b/pages/network/load_balancer/create_http_https/guide.en-us.md @@ -1,81 +1,106 @@ --- -title: 'Configuring a HTTP/HTTPS OVH Load Balancer service' -excerpt: 'Find out how to configure an OVH Load Balancer service' -updated: 2023-11-22 +title: "Configuration of an OVHcloud Load Balancer service with HTTP/HTTPS" +excerpt: "Configure your OVHcloud Load Balancer to distribute HTTP traffic and secure your connections with HTTPS" +updated: 2025-11-12 --- -## Objective + -The purpose of this guide is to help you create your first HTTP/HTTPS service with the new OVHcloud Load Balancer solution. Here, we will set up a basic OVHcloud Load Balancer service configuration to balance the HTTP load for a service like a website. +## Objective -A front-end will be created to listen on port 80, while another listens on port 443 with an SSL/TLS certificate. These front-ends will be configured to direct their traffic to a common HTTP farm. This farm can have one or more servers, depending on the configuration you have chosen/adapted. +This guide aims to help you create your first HTTP/HTTPS service using the OVHcloud Load Balancer offer. We will configure a simple OVHcloud Load Balancer service to distribute HTTP traffic for a service, such as a website. -As a reminder, the OVHcloud Load Balancer has four primary components: +A frontend will be created to listen on port 80, while another will listen on port 443 with an SSL/TLS certificate. These frontends will be configured to direct their traffic to a common HTTP farm. This farm can have one or more servers, depending on the chosen / adapted configuration. -- `front-ends` -- server `farms` and their `servers` -- the advanced `routes` between the front-ends and server farms -- `SSL/TLS` connections that can encrypt TCP and/or HTTP connections +As a reminder, the OVHcloud Load Balancer service is composed of 4 elementary parts: -**This guide will show you how to configure an OVHcloud Load Balancer Service.** +- the `frontends`; +- the `farms` of servers and their `servers`; +- the advanced `routes` between Frontends and Server Farms; +- the `SSL/TLS` certificates allowing TCP and/or HTTP connections to be encrypted. ## Requirements -- an OVHcloud Load Balancer -- the ability to add and configure a farm, a server, a front-end and an SSL certificate +- Have an [OVHcloud Load balancer](/links/network/load-balancer) offer in your OVHcloud account +- You must be logged in to your [OVHcloud Control Panel](/links/manager) +- Have a configured farm +- Have a configured frontend +- Have an SSL certificate + +## Instructions -## Introduction +## Table of contents + +- [Add a server farm](#farm) +- [Add a server](#server) +- [Add a frontend](#frontend) +- [Add an SSL/TLS certificate](#certificate) +- [Apply the changes](#apply) +- [Validation](#validation) > [!warning] > -> This guide will take you through the steps required. Depending on the way you have designed your architecture, some configurations may vary. +> We will guide you through the different steps. Depending on your architecture choices, some configurations may differ. > -If you have not done so already, we recommend reading a general introduction to the OVHcloud Load Balancer service before you get started: [Introduction to the OVHcloud Load Balancer](/pages/network/load_balancer/use_presentation){.ref} +Before you start, it is recommended to consult the [OVHcloud Load Balancer presentation](/pages/network/load_balancer/use_presentation). > [!warning] > -> The order in which elements are created is important. In particular, the server farms must be configured before we can attach an SSL/TLS certificate or servers to them. The front-ends must be configured after the server farms in order to configure the front-end’s default farm. +> The order of element creation is important. In particular, server farms must be configured before being able to attach an SSL/TLS certificate or servers to them. Similarly, frontends must be configured after the server farms in order to be able to configure the frontend's default farm. > -In the control panel of the load balancer, you will see the features detailed below: +The features detailed below are accessible from the OVHcloud Control Panel: -![OVHcloud Load Balancer service](images/iplb_service.png){.thumbnail} +![OVHcloud Load Balancer Service](images/iplb_service.png){.thumbnail} -For more information on the Control Panel’s features, you can consult the following guide: [Managing the Load Balancer from the customer control panel](/pages/network/load_balancer/use-lb){.ref} +For more information about the features of the OVHcloud Control Panel, see the [Managing the Load Balancer service via the OVHcloud Control Panel](/pages/network/load_balancer/use-lb) page. -Similarly, this can be done via the OVHcloud API, in the section: +Via the OVHcloud API, use the following call: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing > -For more information on the API’s features, you can consult the following guide: [Load Balancer API Quick Reference](/pages/network/load_balancer/use_api_reference){.ref} - -## Add a server farm. +For more information on the API features, consult the page [API function details](/pages/network/load_balancer/use_api_details){.ref} -We will add a farm of HTTP servers to our service, which is the part that balances traffic on the servers. +### Add a server farm -### Via the OVHCloud Control Panel. +We will add an HTTP server farm to our service. This part is responsible for distributing traffic to the servers. -Log into the [OVHcloud Control Panel](/links/manager), click `Network`{.action} in the left-hand menu, then `Load Balancer`. Click on your load balancer service. +#### From the OVHcloud Control Panel -In the `Server farms`{.action} tab, click on the `Add a server farm`{.action} button. +In the `Server Farms`{.action} tab, click the `Add a server farm`{.action} button. -Fill in the fields. The only mandatory fields for a basic configuration are *Protocol* and *Datacentre*. We recommend explicitly defining a *Port* (generally port 80 for a web service). If no ports are specified, your OVHcloud Load Balancer will automatically use the same port as the corresponding front-end, and the probes will not be able to work as intended. +Fill in the fields. The only mandatory fields for a simple configuration are the *Protocol* and the *Datacentre*. It is recommended to explicitly define a *Port*, generally port 80 for a web service. If no port is specified, your OVHcloud Load Balancer will automatically use the same port as the corresponding frontend and the probes may not work as expected. -If you add several servers to your farm, we advise configuring an HTTP `availability probe`. When a probe is configured, the OVHcloud Load Balancer service can automatically disable a server that is down or under maintenance, so that your web users are not affected. +If you add several servers in your farm, it is recommended to configure an HTTP `availability probe`. When a probe is configured, the OVHcloud Load Balancer service can automatically disable a server that is down or under maintenance, in order not to affect visitors. -![Add a server farm via the Control Panel](images/add_backend.png){.thumbnail} +![Adding a server farm via the OVHcloud Control Panel](images/add_backend.png){.thumbnail} -Click `Add`{.action} once you have filled in the fields. +Click the `Add`{.action} button once you have filled in the fields. -Your server farm should appear in the list, in the `Server farms`{.action} tab. +Your server farm should appear in the list, under the `Server Farms`{.action} tab. -![Details of the server farm created](images/resume_backend.png){.thumbnail} +![Details of the created server farm](images/resume_backend.png){.thumbnail} -### Via the API +#### From the OVHcloud API - List of HTTP server farms: @@ -91,48 +116,46 @@ Your server farm should appear in the list, in the `Server farms`{.action} tab. > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/farm/{farmId} > -- Add a new HTTP server farm: +- Adding a new HTTP server farm: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/http/farm > -- Modify a specific server farm: +- Modifying a specific server farm: > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/farm/{farmId} > -- Delete a specific server farm: +- Deleting a specific server farm: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/farm/{farmId} > -## Add a server. +### Add a server We will now add a server to our server farm. -### Via the OVHcloud Control Panel. +#### From the OVHcloud Control Panel -Log into the [OVHcloud Control Panel](/links/manager), click `Network`{.action} in the left-hand menu, then `Load Balancer`. Click on your load balancer service. +Still in the `Server Farms`{.action} tab, select the farm to which you want to add a server by clicking on the corresponding line. The list of servers already configured in the farm appears below the list of farms, as well as the `Add a server`{.action} button. Click on this button to add a new server. -In the `Server farms`{.action} tab, select the farm you want to add a server to by clicking on the corresponding line. The list of servers already configured in the farm will appear beneath the list of farms, along with the `Add a server`{.action} button. Click on this button to add a new server. +Only the *IPv4 Address* field is mandatory. If a server does not use the same port as the one defined above in the farm, it is possible to override it in the server configuration. However, in order to maintain the most homogeneous and maintainable configuration possible, it is recommended to use this parameter only in advanced cases. -Only the *IPv4 address* field is mandatory. If a server does not use the same port as the one defined earlier in the farm, you may overload it by configuring a server. However, to keep the configuration as standardised and easy to maintain as possible, we recommend only using this parameter in advanced cases. +![Adding a server to a Farm.](images/add_server.png){.thumbnail} -![Add a server to a farm.](images/add_server.png){.thumbnail} +Click the `Add`{.action} button once you have filled in the fields. -Click `Add`{.action} once you have filled in the fields. +Your server should appear in the list of servers, in the `Server Farms`{.action} tab, just below the list of farms. -Your server should appear in the server list, in the `Server farm`{.action} tab, just below the list of farms. +![Details of the created server.](images/resume_server.png){.thumbnail} -![Details of the server created.](images/resume_server.png){.thumbnail} - -### Via the API +#### From the OVHcloud API - List of servers in the farm: @@ -148,193 +171,198 @@ Your server should appear in the server list, in the `Server farm`{.action} tab, > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server/{serverId} > -- Add a new server: +- Adding a new server: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server > -- Modify a specific server: +- Modifying a specific server: > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server > -- Delete a specific server: +- Deleting a specific server: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server > -## Add a front-end. +### Add a frontend -We will now add a `front-end` to our service, and connect it to our server farm. The front-end is the part of your OVHcloud Load Balancer that exposes your service on the internet. First, we will only configure it in HTTP, without an SSL/TLS certificate. +We will now add a `frontend` to our service and connect it to our server farm. The frontend is the part of your OVHcloud Load Balancer that is used to expose your service on the Internet. At first, we will configure it in HTTP only, without an SSL/TLS certificate. -### Via the OVHcloud Control Panel. +#### From the OVHcloud Control Panel -Go to the `Front-ends`{.action} tab, and click `Add a front-end`{.action}. +In the `Frontends`{.action} tab, click the `Add a frontend`{.action} button. -Fill in the fields. The only mandatory fields for a basic configuration are *Protocol*, *Port* (80 for a standard HTTP web service) and *Datacentre*. If you want your service to be available across several ports at once, you can specify a list of ports, separated by commas, or a range of ports, in the format "START_PORT-END_PORT". +Fill in the fields. The only mandatory fields for a simple configuration are the *Protocol*, the *Port* (80 for a standard HTTP web service) and the *Datacentre*. If you want your service to be available on several ports at the same time, you can specify a list of ports separated by commas or a range of ports in the form "START_PORT-END_PORT". -If you have routed Additional IPs to your OVHcloud Load Balancer service, you can also attach a front-end to one or more specific Additional IPs. +If you have routed Additional IPs to your OVHcloud Load Balancer service, you can also attach a frontend to one or more specific Additional IPs. -![Add a front-end](images/add_frontend.png){.thumbnail} +![Adding a frontend](images/add_frontend.png){.thumbnail} -Click `Add`{.action} once you have filled in the fields. +Click the `Add`{.action} button once you have filled in the fields. -Your front-end must appear in the list, in the `Front-ends`{.action} tab. +Your frontend should appear in the list, under the `Frontends`{.action} tab. -![Details of the front-end created](images/resume_frontend.png){.thumbnail} +![Details of the created frontend](images/resume_frontend.png){.thumbnail} -### Via the API +#### From the OVHcloud API -- List of HTTP front-ends: +- List of HTTP frontends: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/frontend > -- Details of a specific front-end: +- Details of a specific frontend: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} > -- Add a new front-end: +- Adding a new frontend: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/http/frontend > -- Modify a specific front-end: +- Modifying a specific frontend: > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} > -- Delete a specific front-end: +- Deleting a specific frontend: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} > -## Add an SSL/TLS certificate. +### Add an SSL/TLS certificate -The section above described the general configuration of a HTTP front-end. This next section describes the additional steps you need to take to activate support of HTTPS protocol on an HTTP front-end. In particular, you need to: +The previous section described the general configuration for an HTTP frontend. This section describes the additional steps to enable support for the HTTPS protocol on an HTTP frontend. In particular, you will need to: -- switch over the front-end to port 443, which is standard for HTTPS protocol -- configure an SSL/TLS certificate to authenticate and encrypt connections +- switch the frontend to port 443, the standard port for the HTTPS protocol; +- configure an SSL/TLS certificate to authenticate and encrypt the connections. -Whether you choose to configure your service via the API or the OVHcloud Control Panel, you can choose from two methods for adding an SSL/TLS certificate. The choice of method will depend on your needs, as well as the solutions currently set up. You can either: +Whether you choose a configuration via the API or via the OVHcloud Control Panel, you will have a choice between 2 strategies for your SSL/TLS certificates. This choice depends on your needs as well as the current solutions in place: - Import an existing SSL/TLS certificate. -- Order an automatically managed SSL/TLS certificate. DV and EV certificates will be available to order soon. +- Order an automatically managed SSL/TLS certificate. The ordering of DV and EV certificates will be available soon. -If you choose to import an SSL/TLS certificate that you have already ordered and managed yourself, you will need to renew it periodically yourself, and update it in your OVHcloud Load Balancer service. Most certificates are valid for one year. Some remain valid for longer periods of time. However, Let's Encrypt certificates need to be renewed every three months. We recommend using your OVHcloud Load Balancer to automatically manage the service for Let’s Encrypt certificates, so that you do not miss the expiry dates. +If you choose to import an SSL/TLS certificate that you have ordered and managed yourself, you will have to renew it periodically yourself and update it in your OVHcloud Load Balancer service. Most certificates are valid for 1 year. Some may be valid for longer. Let's Encrypt certificates are valid for 3 months. It is recommended to use the service managed automatically by your OVHcloud Load Balancer for Let's Encrypt certificates in order not to accidentally miss a deadline. -If you opt for a certificate managed by the OVHcloud Load Balancer service, it will be automatically ordered, validated, installed and renewed periodically by your OVHcloud Load Balancer. For the validation and renewal operations to work, the domains you are ordering this certificate for need to be routed to your OVHcloud Load Balancer service. This means that your domain’s *A* and *AAAA* DNS records must point to your OVHcloud Load Balancer’s IPv4 and IPv6 fields respectively, or to one of its Additional IPs. When you order, you will receive an email that will guide you through the validation steps. +If you choose a certificate managed by your OVHcloud Load Balancer service, it will be automatically ordered, validated, installed and renewed periodically by your OVHcloud Load Balancer.
+For the validation and renewal operations to work, the domain(s) you are ordering this certificate for must be routed to your OVHcloud Load Balancer service. This implies that the *A* and *AAAA* fields of your domain point respectively to the IPv4 and IPv6 of your OVHcloud Load Balancer or one of its Additional IPs. During the order, you will receive an email that will guide you through the validation steps. +> [!primary] > -> To ensure that your service remains accessible when you switch your domain to your OVHcloud Load Balancer service’s IP address in order to validate your certificate, it is good practice to start by configuring and testing all of the HTTP configuration on port 80. This way, your website will remain accessible without any interruptions. -> If the website already has a HTTPS connection and you want to switch to certificates managed by your OVHcloud Load Balancer service, you can import your existing certificates, configure and test your HTTPS front-end, and order a new certificate for the same domain. It will be taken into account automatically when your old certificate expires. +> To ensure service continuity when switching your domain to the IP of your OVHcloud Load Balancer service to validate your certificate, a good practice is to first configure and fully test the HTTP configuration on port 80. This way, your site remains accessible without interruption. +> If your site already has an HTTPS connection and you want to migrate to certificates managed by your OVHcloud Load Balancer service, you can import your existing certificates, configure and test your HTTPS Frontend and finally order a new certificate for the same domain. It will be automatically taken into account before your old certificate expires. > -The certificates configured on your OVHcloud Load Balancer service are automatically available for all of the front-ends on your service that have *SSL* options enabled. +The certificates configured on your OVHcloud Load Balancer service are automatically available for all frontends of your OVHcloud Load Balancer service on which the *SSL* option is enabled. #### TLS 1.3 support -With the constant evolution of Internet security standards, OVHcloud is committed to providing the latest and most secure technologies for your services. The OVHcloud Load Balancer now supports TLS 1.3. -##### What is TLS 1.3? -TLS 1.3 is the latest version of the TLS protocol, offering significant improvements in security and performance over TLS 1.2. Key benefits include a faster handshake process, reducing the time needed to establish secure connections, and the use of more secure cipher suites to strengthen the security of transmitted data. +With the constant evolution of security standards on the Internet, OVHcloud is committed to providing the most recent and secure technologies for your services. The OVHcloud Load Balancer now supports TLS 1.3. + +##### **What is TLS 1.3?** + +TLS 1.3 is the latest version of the TLS protocol, offering significant improvements in terms of security and performance compared to TLS 1.2. The key advantages include a faster *handshake* process, thus reducing the time needed to establish secure connections, and the use of safer encryption suites to strengthen the security of transmitted data. -##### Why use TLS 1.3 with OVHcloud Load Balancer? -By integrating TLS 1.3, your OVHcloud Load Balancer will benefit from enhanced security and improved performance, ensuring an optimal user experience for your visitors. Reduced handshake times speed up page loading, while security enhancements ensure that your data is protected with the latest, most secure standards. +##### **Why use TLS 1.3 with OVHcloud Load Balancer?** -### Via the OVHcloud Control Panel. +By integrating TLS 1.3, your OVHcloud Load Balancer will benefit from enhanced security and improved performance, ensuring an optimal user experience for your visitors. The reduction in *handshake* time speeds up page loading, while the security improvements ensure that your data is protected with the most recent and secure standards. -The list of SSL/TLS certificates configured on the OVHcloud Load Balancer can be found in the `SSL certificates`{.action} tab. In this interface, you can select one of the two options mentioned further up, i.e. importing an existing certificate (`Add an SSL certificate`{.action}) and (`Order an SSL certificate`{.action}) managed automatically by your OVHcloud Load Balancer. +#### From the OVHcloud Control Panel -![Buttons for adding certificates](images/certificat.png){.thumbnail} +The list of SSL/TLS certificates configured on your OVHcloud Load Balancer service is in the `SSL Certificates`{.action} tab. This interface offers the 2 options mentioned above, namely importing an existing certificate (via the `Add an SSL certificate`{.action} button) and `Order an SSL certificate`{.action} managed automatically by your OVHcloud Load Balancer service. -If you choose to import an existing SSL/TLS certificate, click `Add an SSL certificate`{.action}. The *Private key* and *Certificate* fields are obligatory. +![Certificate addition buttons](images/certificat.png){.thumbnail} -Click `Add`{.action} once you have filled in the fields. Your certificate will appear in the certificate list. +If you choose to import an existing SSL/TLS certificate, click on `Add an SSL certificate`{.action}. The *Private Key* and *Certificate* fields are mandatory. -![Add an existing SSL certificate](images/add_certificat_custom.png){.thumbnail} +Click the `Add`{.action} button once the fields are filled in. Your certificate will then appear in the certificate list. -To add a Let's Encrypt certificate, click `Order an SSL certificate`{.action}, enter your domains, ensure that they point to your OVHcloud Load Balancer, and follow the instructions set out in the guides you receive. You will then see it appear in the list of available certificates. +![Adding an existing certificate](images/add_certificat_custom.png){.thumbnail} -![Order a Let’s Encrypt certificate](images/add_certificat_letsencrypt.png){.thumbnail} +To add a Let's Encrypt certificate, click on `Order an SSL certificate`{.action}, enter your domain, make sure it points to your OVHcloud Load Balancer service and follow the emails you receive. You will then see it appear in the list of available certificates. -Once your certificates have been configured, you can create a HTTPS front-end, on the same model as the HTTP front-end created earlier on with port 443, and the *SSL* option enabled. You can also choose to enable the *HSTS* option. With this option enabled, web browsers will remember that this website should *no longer* be visited without HTTPS after the first time the web user visits in HTTPS. This way, you can improve your infrastructure’s overall security by protecting it against ‘man-in-the-middle’ attacks, where a malicious party can make it seem as though your website is not available in HTTPS, forcing your web users to switch to HTTP. +![Ordering a Let's Encrypt certificate](images/add_certificat_letsencrypt.png){.thumbnail} + +Once your certificate(s) are configured, you can create an HTTPS frontend, on the same model as the HTTP frontend created above with port 443 and the *SSL* option enabled.
+Optionally, you can also enable the *HSTS* option. If this option is enabled, browsers will record that this website should *never again* be visited without HTTPS after their first visit in HTTPS. This strengthens overall security by protecting against "Man-in-the-middle" attacks in which a malicious actor could make your website appear unavailable in HTTPS and force your visitors to switch to "HTTP". > [!warning] +> Although the added security is significant, it is recommended to wait a while before enabling this option, to make sure there are no side effects in HTTPS. Indeed, once HSTS is enabled, there is no going back. > -> All though adding this additional level of security is important, we recommend waiting for a while before you enable this option, to ensure that there are no issues with your website forming HTTPS connections. Once HSTS has been enabled, you cannot undo the change. -> -### Via the API +#### From the OVHcloud API -- To list the SSL/TLS certificates in place: +- List the existing SSL/TLS certificates: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl > -- To view details on an SSL/TLS certificate: +- Get the details of an SSL/TLS certificate: > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/ssl/{id} > -- To add a new, existing SSL/TLS certificate: +- Adding a new existing SSL/TLS certificate: > [!api] > > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/ssl > -- To modify a specific SSL/TLS certificate (only the display name can be modified): +- Modifying a specific SSL/TLS certificate (only the displayed name can be modified) : > [!api] > > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/ssl/{id} > -- To delete a specific SSL/TLS certificate: +- Deleting a specific SSL/TLS certificate: > [!api] > > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/ssl/{id} > -## Apply the modifications +### Apply the changes -The modifications made to your OVHcloud Load Balancer must be *explicitly applied* in each of the zones configured for your OVHcloud Load Balancer service. Only then will they be visible to your website visitors. This way, you can make complex configuration changes in one go. +The changes made to your OVHcloud Load Balancer service must be *explicitly applied* in each of the zones configured for your OVHcloud Load Balancer service. Only then will they be visible to your visitors. This allows a complex configuration change to be made in a single step. -If you have several zones, you must apply the same configuration for each of them. +If you have several zones, you will have to apply the same configuration for each of your zones. -### Via the OVHcloud Control Panel. +#### From the OVHcloud Control Panel -Go to the page for your OVHcloud Load Balancer, and click `Apply configuration`{.action}. +Go to the home page of your OVHcloud Load Balancer service, click on the `...`{.action} dots next to the name of your service and click on `Apply the configuration`{.action}. -![Apply configuration](images/btn_apply_configuration.png){.thumbnail} +![Apply the configuration](images/btn_apply_configuration.png){.thumbnail} -Next, select the zones you want to deploy, and click `Apply configuration`{.action}. +Then select the list of zones you want to deploy and click on the `Apply the configuration`{.action} button. -![Apply configuration to zones](images/btn_apply_configuration_zones.png){.thumbnail} +![Apply the configuration zones](images/btn_apply_configuration_zones.png){.thumbnail} -### Via the API +#### From the OVHcloud API - Refresh a zone: @@ -343,10 +371,10 @@ Next, select the zones you want to deploy, and click `Apply configuration`{.acti > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/refresh > -## Confirmation +### Validation -Once you have completed all of these steps, you should have a functional load balancing service. You can check the service status by visiting your website. +Once all these steps are completed, you should have a functional load balancing service. You can validate the status of the service by visiting your site. ## Go further -Join our community of users on . \ No newline at end of file +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_http_https/guide.fr-ca.md b/pages/network/load_balancer/create_http_https/guide.fr-ca.md index 1e8eacde8fb..6eac01e82c8 100644 --- a/pages/network/load_balancer/create_http_https/guide.fr-ca.md +++ b/pages/network/load_balancer/create_http_https/guide.fr-ca.md @@ -1,14 +1,31 @@ --- title: "Configuration d'un service OVHcloud Load Balancer avec HTTP/HTTPS" -excerpt: Configuration d’un service Load Balancer -updated: 2023-11-22 +excerpt: "Découvrez comment configurer votre Load Balancer OVHcloud pour répartir la charge HTTP et sécuriser vos connexions avec HTTPS" +updated: 2025-11-12 --- + + ## Objectif -Ce guide a pour but de vous aider à créer votre premier service HTTP/HTTPS avec l'offre OVHcloud Load Balancer OVHcloud. Nous allons ici configurer un service OVHcloud Load Balancer simple pour répartir la charge HTTP d'un service, tel qu'un site web. +Ce guide a pour but de vous aider à créer votre premier service HTTP/HTTPS avec l'offre OVHcloud Load Balancer. Nous allons ici configurer un service OVHcloud Load Balancer simple pour répartir la charge HTTP d'un service, tel qu'un site web. -Un frontend sera créé pour écouter sur le port 80, tandis qu'un autre écoutera sur le port 443 avec un certificat SSL/TLS. Ces frontends seront configurés pour diriger leur trafic vers une ferme HTTP commune. Cette ferme peut disposer d'un ou plusieurs serveurs, selon la configuration choisie / adaptée. +Un frontend sera créé pour écouter sur le port 80, tandis qu'un autre écoutera sur le port 443 avec un certificat SSL/TLS. Ces frontends seront configurés pour diriger leur trafic vers une ferme HTTP commune. Cette ferme peut disposer d'un ou plusieurs serveurs, selon la configuration choisie/adaptée. Pour rappel, le service OVHcloud Load Balancer est composé de 4 parties élémentaires : @@ -17,6 +34,8 @@ Pour rappel, le service OVHcloud Load Balancer est composé de 4 parties éléme - les `routes` avancées entre les Frontends et les Fermes de serveurs ; - les certificats `SSL/TLS` permettant de chiffrer les connexions TCP et/ou HTTP. +**Découvrez comment configurer votre service Load Balancer OVHcloud pour répartir la charge HTTP et sécuriser vos connexions avec HTTPS.** + ## Prérequis - Posséder une offre [OVHcloud Load balancer](/links/network/load-balancer) dans votre compte OVHcloud. @@ -27,19 +46,28 @@ Pour rappel, le service OVHcloud Load Balancer est composé de 4 parties éléme ## En pratique +## Sommaire + +- [Ajouter une ferme de serveurs](#farm) +- [Ajouter un serveur](#server) +- [Ajouter un frontend](#frontend) +- [Ajouter un certificat SSL/TLS](#certificate) +- [Appliquer les modifications](#apply) +- [Validation](#validation) + > [!warning] > > Nous allons vous guider au travers des différentes étapes. Selon vos choix d'architecture, certaines configurations peuvent différer. > -Avant de vous lancer, si vous ne l'avez pas encore lue, nous vous conseillons de consulter la présentation générale du service OVHcloud Load Balancer: [Présentation de l'OVHcloud Load Balancer](/pages/network/load_balancer/use_presentation). +Avant de vous lancer, il est conseillé de consulter la [présentation du service OVHcloud Load Balancer](/pages/network/load_balancer/use_presentation). > [!warning] > > L'ordre de création des éléments est important. En particulier, les fermes de serveurs doivent être configurées avant de pouvoir leur attacher un certificat SSL/TLS ou des serveurs. De même, les frontends doivent être configurés après les fermes de serveurs afin de pouvoir configurer la ferme par défaut du frontend. > -Dans l'espace client OVHcloud, nous allons retrouver les fonctionnalités détaillées ci-dessous: +Les fonctionnalités détaillées ci-dessous sont accessibles depuis l'espace client OVHcloud : ![Service OVHcloud Load Balancer](images/iplb_service.png){.thumbnail} @@ -54,23 +82,23 @@ Via l'API OVHcloud, utilisez l'appel suivant : Pour plus d'informations sur les fonctionnalités de l'API, consultez la page [Détails des fonctions API](/pages/network/load_balancer/use_api_details){.ref} -### Ajouter une ferme de serveurs +### Ajouter une ferme de serveurs -Nous allons ajouter une ferme de serveurs HTTP à notre service, la partie en charge de répartir le trafic sur les serveurs. +Nous allons ajouter une ferme de serveurs HTTP à notre service. Cette partie est en charge de répartir le trafic sur les serveurs. #### Depuis l'espace client OVHcloud Dans l'onglet `Fermes de serveurs`{.action}, cliquez sur le bouton `Ajouter une ferme de serveurs`{.action}. -Remplissez les champs. Les seuls champs obligatoires pour une configuration simple sont le *Protocole* et le *Datacentre*. Il est recommandé de définir explicitement un *Port*, généralement le port 80 pour un service web. Si aucun port n'est spécifié, votre OVHcloud Load Balancer utilisera automatiquement le même port que le frontend correspondant et les sondes pourront ne pas fonctionner comme prévu. +Remplissez les champs. Les seuls champs obligatoires pour une configuration simple sont le *Protocole* et le *Datacentre*. Il est recommandé de définir explicitement un *Port*, généralement le port 80 pour un service web. Si aucun port n'est spécifié, votre service OVHcloud Load Balancer utilisera automatiquement le même port que le frontend correspondant et les sondes pourront ne pas fonctionner comme prévu. Si vous ajoutez plusieurs serveurs dans votre ferme, il est recommandé de configurer une `sonde de disponibilité` HTTP. Lorsqu'une sonde est configurée, le service OVHcloud Load Balancer pourra automatiquement désactiver un serveur qui serait en panne ou en maintenance, de manière à ne pas affecter les visiteurs. -![Ajout d'une ferme de serveurs via le Manager](images/add_backend.png){.thumbnail} +![Ajout d'une ferme de serveurs via l'espace client OVHcloud](images/add_backend.png){.thumbnail} Cliquez sur le bouton `Ajouter`{.action} une fois les champs remplis. -Votre ferme de serveurs devrait apparaitre dans la liste, sous l'onglet `Fermes de serveurs`{.action}. +Votre ferme de serveurs devrait apparaître dans la liste, sous l'onglet `Fermes de serveurs`{.action}. ![Détails de la ferme de serveurs créée](images/resume_backend.png){.thumbnail} @@ -111,13 +139,13 @@ Votre ferme de serveurs devrait apparaitre dans la liste, sous l'onglet `Fermes > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/farm/{farmId} > -### Ajouter un Serveur +### Ajouter un serveur Nous allons maintenant ajouter un serveur à notre ferme de serveurs. #### Depuis l'espace client OVHcloud -Toujours dans l'onglet `Fermes de serveurs`{.action}, sélectionnez la ferme dans laquelle vous souhaitez ajouter un serveur en cliquant sur la ligne correspondante. La liste des Serveurs déjà configurés dans la ferme apparaît en dessous de la liste des fermes, ainsi qu'un bouton `Ajouter un serveur`{.action}. Cliquez sur ce bouton pour ajouter un nouveau serveur. +Toujours dans l'onglet `Fermes de serveurs`{.action}, sélectionnez la ferme à laquelle vous souhaitez ajouter un serveur en cliquant sur la ligne correspondante. La liste des serveurs déjà configurés dans la ferme apparaît en dessous de la liste des fermes, ainsi qu'un bouton `Ajouter un serveur`{.action}. Cliquez sur ce bouton pour ajouter un nouveau serveur. Seul le champ *Adresse IPv4* est obligatoire. Si un serveur n'utilise pas le même port que celui défini plus haut dans la ferme, il est possible de le surcharger dans la configuration du serveur. Cependant, afin de conserver une configuration la plus homogène et maintenable possible, il est recommandé de n'utiliser ce paramètre que dans les cas avancés. @@ -152,7 +180,7 @@ Votre serveur devrait apparaître dans la liste des serveurs, dans l'onglet `Fer > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server > -- Modification d'un Serveur spécifique : +- Modification d'un serveur spécifique : > [!api] > @@ -166,9 +194,9 @@ Votre serveur devrait apparaître dans la liste des serveurs, dans l'onglet `Fer > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server > -### Ajouter un frontend +### Ajouter un frontend -Nous allons maintenant ajouter un `frontend` à notre service et le connecter à notre ferme de serveurs. Le frontend est la partie de votre OVHcloud Load Balancer qui sert à exposer votre service sur Internet. Dans un premier temps, nous allons le configurer en HTTP uniquement, sans certificat SSL/TLS. +Nous allons maintenant ajouter un `frontend` à notre service et le connecter à notre ferme de serveurs. Le frontend est la partie de votre service OVHcloud Load Balancer qui sert à exposer votre service sur Internet. Dans un premier temps, nous allons le configurer en HTTP uniquement, sans certificat SSL/TLS. #### Depuis l'espace client OVHcloud @@ -223,40 +251,46 @@ Votre frontend devrait apparaître dans la liste, sous l'onglet `Frontends`{.act > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} > -### Ajouter un certificat SSL/TLS +### Ajouter un certificat SSL/TLS -La section précédente décrivait la configuration générale pour un frontend HTTP. Cette section décrit les étapes supplémentaires pour activer le support du protocole HTTPS sur un Frontend HTTP. En particulier, il faudra : +La section précédente décrivait la configuration générale pour un frontend HTTP. Cette section décrit les étapes supplémentaires pour activer le support du protocole HTTPS sur un frontend HTTP. En particulier, il faudra : -- basculer le Frontend sur le port 443, standard pour le protocole HTTPS ; +- basculer le frontend sur le port 443, standard pour le protocole HTTPS ; - configurer un certificat SSL/TLS afin d'authentifier et chiffrer les connexions. -Que vous optiez pour une configuration via l'API ou via l'espace client OVHcloud, vous aurez le choix entre 2 stratégies pour vos certificats SSL/TLS, ce choix dépendant de vos besoins ainsi que des solutions actuellement en place : +Que vous optiez pour une configuration via l'API ou via l'espace client OVHcloud, vous aurez le choix entre 2 stratégies pour vos certificats SSL/TLS : - Importer un certificat SSL/TLS existant. -- Commander un certificat SSL/TLS géré automatiquement. La commande de certificats DV et EV arrivera prochainement. +- Commander un certificat SSL/TLS géré automatiquement. La commande de certificats DV et EV sera disponible prochainement. -Si vous optez pour l'importation d'un certificat SSL/TLS commandé et géré par vos soins, vous devrez le renouveler périodiquement vous-même et le mettre à jour dans votre service OVHcloud Load Balancer. La majorité des certificats sont valides pour 1 an. Certains peuvent l'être plus longtemps. Les certificats Let's Encrypt ne sont quant à eux valides que 3 mois. Il est recommandé d'utiliser le service géré automatiquement par votre OVHcloud Load Balancer pour les certificats Let's Encrypt afin de ne pas accidentellement rater une échéance. +> [!primary] +> +> Ce choix dépend de vos besoins ainsi que des solutions actuellement en place. + +Si vous optez pour l'importation d'un certificat SSL/TLS commandé et géré par vos soins, vous devrez le renouveler périodiquement vous-même et le mettre à jour dans votre service OVHcloud Load Balancer. La majorité des certificats sont valides pour 1 an. Certains peuvent l'être plus longtemps. Les certificats `Let's Encrypt` ne sont quant à eux valides que 3 mois. Il est recommandé d'utiliser le service géré automatiquement par votre service OVHcloud Load Balancer pour les certificats `Let's Encrypt` afin de ne pas accidentellement rater une échéance. Si vous optez pour un certificat géré par votre service OVHcloud Load Balancer, celui-ci sera automatiquement commandé, validé, installé et renouvelé périodiquement par votre OVHcloud Load Balancer.
-Pour que les opérations de validation et de renouvellement fonctionnent, il est nécessaire que le ou les domaines pour lesquels vous commandez ce certificat soient routés vers votre service OVHcloud Load Balancer. Cela implique que les champs *A* et *AAAA* de votre domaine pointent respectivement sur l'IPv4 et l'IPv6 de votre OVHcloud Load Balancer ou l'une de ses Additional IPs. Lors de la commande, vous recevrez un email qui vous guidera dans les étapes de la validation. +Pour que les opérations de validation et de renouvellement fonctionnent, il est nécessaire que le ou les domaines pour lesquels vous commandez ce certificat soient routés vers votre service OVHcloud Load Balancer. Cela implique que les champs *A* et *AAAA* de votre domaine pointent respectivement sur l'IPv4 et l'IPv6 de votre Load Balancer ou l'une de ses Additional IPs. Lors de la commande, vous recevrez un e-mail qui vous guidera dans les étapes de la validation. > [!primary] > -> Pour assurer la continuité de service lors du basculement de votre domaine vers l'IP de votre service OVHcloud Load Balancer afin de valider votre certificat, une bonne pratique est de commencer par configurer et tester complètement la configuration HTTP sur le port 80. De cette manière, votre site reste accessible sans interruption. +> Pour assurer la continuité de service lors du basculement de votre domaine vers l'IP de votre service OVHcloud Load Balancer afin de valider votre certificat, une bonne pratique consiste à commencer par configurer et tester complètement la configuration HTTP sur le port 80. De cette manière, votre site reste accessible sans interruption. > Si votre site dispose déjà d'une connexion HTTPS et que vous souhaitez migrer vers des certificats gérés par votre service OVHcloud Load Balancer, vous pouvez importer vos certificats existants, configurer et tester votre Frontend HTTPS et enfin commander un nouveau certificat pour le même domaine. Il sera automatiquement pris en compte avant l'expiration de votre ancien certificat. > -Les certificats configurés sur votre service OVHcloud Load Balancer sont automatiquement disponibles pour l'ensemble des frontend de votre service OVHcloud Load Balancer sur lesquels l'options *SSL* est activée. +Les certificats configurés sur votre service OVHcloud Load Balancer sont automatiquement disponibles pour l'ensemble des frontends de votre service OVHcloud Load Balancer sur lesquels l'option *SSL* est activée. #### Support de TLS 1.3 + Avec l'évolution constante des normes de sécurité sur Internet, OVHcloud s'engage à fournir les technologies les plus récentes et les plus sûres pour vos services. Le Load Balancer OVHcloud supporte désormais TLS 1.3. -##### Qu'est-ce que TLS 1.3 ? -TLS 1.3 est la dernière version du protocole TLS, offrant des améliorations significatives en matière de sécurité et de performance par rapport à TLS 1.2. Les avantages clés incluent un processus de handshake plus rapide, réduisant ainsi le temps nécessaire pour établir des connexions sécurisées, et l'utilisation de suites de chiffrement plus sûres pour renforcer la sécurité des données transmises. +##### **Qu'est-ce que TLS 1.3 ?** + +TLS 1.3 est la dernière version du protocole TLS. Elle améliore significativement la sécurité et les performances par rapport à TLS 1.2, notamment grâce à un processus de *handshake* plus rapide, réduisant le temps nécessaire pour établir des connexions sécurisées, et à l’utilisation de suites de chiffrement plus sûres pour renforcer la sécurité des données transmises. -##### Pourquoi utiliser TLS 1.3 avec OVHcloud Load Balancer ? +##### **Pourquoi utiliser TLS 1.3 avec OVHcloud Load Balancer ?** -En intégrant TLS 1.3, votre Load Balancer OVHcloud bénéficiera d'une sécurité renforcée et d'une performance améliorée, assurant une expérience utilisateur optimale pour vos visiteurs. La réduction du temps de handshake accélère le chargement des pages, tandis que les améliorations de sécurité garantissent que vos données sont protégées avec les normes les plus récentes et les plus sûres. +En intégrant TLS 1.3, votre service OVHcloud Load Balancer bénéficiera d'une sécurité renforcée et d'une performance améliorée, assurant une expérience utilisateur optimale pour vos visiteurs. La réduction du temps de *handshake* accélère le chargement des pages, tandis que les améliorations de sécurité garantissent que vos données sont protégées avec les normes les plus récentes et les plus sûres. #### Depuis l'espace client OVHcloud @@ -270,12 +304,12 @@ Cliquez sur le bouton `Ajouter`{.action} une fois les champs remplis. Votre cert ![Ajout d'un certificat existant](images/add_certificat_custom.png){.thumbnail} -Pour ajouter un certificat Let's Encrypt, cliquez sur `Commander un certificat SSL`{.action}, renseignez votre domaine, assurez vous que celui-ci pointe bien sur votre service OVHcloud Load Balancer et laissez-vous guider par les e-mails que vous recevrez. Vous le verrez ensuite apparaître dans la liste des certificats disponibles. +Pour ajouter un certificat `Let's Encrypt`, cliquez sur `Commander un certificat SSL`{.action}, renseignez votre domaine, assurez-vous que celui-ci pointe bien sur votre service OVHcloud Load Balancer et laissez-vous guider par les e-mails que vous recevrez. Vous le verrez ensuite apparaître dans la liste des certificats disponibles. ![Command d'un certificat Let's Encrypt](images/add_certificat_letsencrypt.png){.thumbnail} -Une fois votre / vos certificats configurés, vous pouvez créer un frontend HTTPS, sur le même modèle que le frontend HTTP créé plus haut avec le port 443 et l'option *SSL* active.
-Optionnellement, vous pouvez également activer l'option *HSTS*. Si cette option est active, les navigateurs enregistreront que ce site Internet ne doit *plus jamais* être visité sans HTTPS après leur première visite en HTTPS. Cela permet de renforcer la sécurité globale en se protégeant contre les attaques de type « Homme du milieu » dans laquelle un acteur malveillant pour faire croire que votre site Internet n'est pas disponible en HTTPS et forcer vos visiteurs à basculer en « HTTP ». +Une fois votre/vos certificats configurés, vous pouvez créer un frontend HTTPS, sur le même modèle que le frontend HTTP créé plus haut avec le port 443 et l'option *SSL* active.
+Optionnellement, vous pouvez également activer l'option *HSTS*. Si cette option est active, les navigateurs enregistreront que ce site Internet ne doit *plus jamais* être visité sans HTTPS après leur première visite en HTTPS. Cela permet de renforcer la sécurité globale en se protégeant contre les attaques de type « Homme du milieu » dans laquelle un acteur malveillant pourrait faire croire que votre site Internet n'est pas disponible en HTTPS et forcer vos visiteurs à basculer en « HTTP ». > [!warning] > @@ -319,9 +353,9 @@ Optionnellement, vous pouvez également activer l'option *HSTS*. Si cette option > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/ssl/{id} > -### Appliquer les modifications +### Appliquer les modifications -Les modifications apportées à votre service OVHcloud Load Balancer soivent être *appliquées explicitement* dans chacune des zones configurées pour votre service OVHcloud Load Balancer. C'est seulement à ce moment qu'elles seront visibles pour vos visiteurs. Cela permet de faire un changement complexe de configuration en une seule fois. +Les modifications apportées à votre service OVHcloud Load Balancer doivent être *appliquées explicitement* dans chacune des zones configurées pour votre service OVHcloud Load Balancer. C'est seulement à ce moment qu'elles seront visibles pour vos visiteurs. Cela permet de faire un changement complexe de configuration en une seule fois. Si vous avez plusieurs zones, vous devrez appliquer la même configuration pour chacune de vos zones. @@ -331,7 +365,7 @@ Rendez-vous sur la page d'accueil de votre service OVHcloud Load Balancer et cli ![Appliquer la configuration](images/btn_apply_configuration.png){.thumbnail} -Selectionnez ensuite la liste des zones que vous souhaitez deployer et cliquez sur le bouton `Appliquer la configuration`{.action}. +Sélectionnez ensuite la liste des zones que vous souhaitez déployer et cliquez sur le bouton `Appliquer la configuration`{.action}. ![Appliquer la configuration zones](images/btn_apply_configuration_zones.png){.thumbnail} @@ -344,10 +378,10 @@ Selectionnez ensuite la liste des zones que vous souhaitez deployer et cliquez s > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/refresh > -### Validation +### Validation Une fois toutes ces étapes terminées, vous devriez disposer d'un service de répartition de charge fonctionnel. Vous pouvez valider l'état du service en visitant votre site. ## Aller plus loin -Échangez avec notre [communauté d'utilisateurs](/links/community). +Échangez avec notre [communauté d'utilisateurs](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_http_https/guide.fr-fr.md b/pages/network/load_balancer/create_http_https/guide.fr-fr.md index 9a8e4374316..d71a77bfa11 100644 --- a/pages/network/load_balancer/create_http_https/guide.fr-fr.md +++ b/pages/network/load_balancer/create_http_https/guide.fr-fr.md @@ -1,14 +1,31 @@ --- title: "Configuration d'un service OVHcloud Load Balancer avec HTTP/HTTPS" -excerpt: Configuration d’un service Load Balancer -updated: 2023-11-22 +excerpt: "Découvrez comment configurer votre Load Balancer OVHcloud pour répartir la charge HTTP et sécuriser vos connexions avec HTTPS" +updated: 2025-11-12 --- + + ## Objectif -Ce guide a pour but de vous aider à créer votre premier service HTTP/HTTPS avec l'offre OVHcloud Load Balancer OVHcloud. Nous allons ici configurer un service OVHcloud Load Balancer simple pour répartir la charge HTTP d'un service, tel qu'un site web. +Ce guide a pour but de vous aider à créer votre premier service HTTP/HTTPS avec l'offre OVHcloud Load Balancer. Nous allons ici configurer un service OVHcloud Load Balancer simple pour répartir la charge HTTP d'un service, tel qu'un site web. -Un frontend sera créé pour écouter sur le port 80, tandis qu'un autre écoutera sur le port 443 avec un certificat SSL/TLS. Ces frontends seront configurés pour diriger leur trafic vers une ferme HTTP commune. Cette ferme peut disposer d'un ou plusieurs serveurs, selon la configuration choisie / adaptée. +Un frontend sera créé pour écouter sur le port 80, tandis qu'un autre écoutera sur le port 443 avec un certificat SSL/TLS. Ces frontends seront configurés pour diriger leur trafic vers une ferme HTTP commune. Cette ferme peut disposer d'un ou plusieurs serveurs, selon la configuration choisie/adaptée. Pour rappel, le service OVHcloud Load Balancer est composé de 4 parties élémentaires : @@ -17,6 +34,8 @@ Pour rappel, le service OVHcloud Load Balancer est composé de 4 parties éléme - les `routes` avancées entre les Frontends et les Fermes de serveurs ; - les certificats `SSL/TLS` permettant de chiffrer les connexions TCP et/ou HTTP. +**Découvrez comment configurer votre service Load Balancer OVHcloud pour répartir la charge HTTP et sécuriser vos connexions avec HTTPS.** + ## Prérequis - Posséder une offre [OVHcloud Load balancer](/links/network/load-balancer) dans votre compte OVHcloud. @@ -27,19 +46,28 @@ Pour rappel, le service OVHcloud Load Balancer est composé de 4 parties éléme ## En pratique +## Sommaire + +- [Ajouter une ferme de serveurs](#farm) +- [Ajouter un serveur](#server) +- [Ajouter un frontend](#frontend) +- [Ajouter un certificat SSL/TLS](#certificate) +- [Appliquer les modifications](#apply) +- [Validation](#validation) + > [!warning] > > Nous allons vous guider au travers des différentes étapes. Selon vos choix d'architecture, certaines configurations peuvent différer. > -Avant de vous lancer, si vous ne l'avez pas encore lue, nous vous conseillons de consulter la présentation générale du service OVHcloud Load Balancer: [Présentation de l'OVHcloud Load Balancer](/pages/network/load_balancer/use_presentation). +Avant de vous lancer, il est conseillé de consulter la [présentation du service OVHcloud Load Balancer](/pages/network/load_balancer/use_presentation). > [!warning] > > L'ordre de création des éléments est important. En particulier, les fermes de serveurs doivent être configurées avant de pouvoir leur attacher un certificat SSL/TLS ou des serveurs. De même, les frontends doivent être configurés après les fermes de serveurs afin de pouvoir configurer la ferme par défaut du frontend. > -Dans l'espace client OVHcloud, nous allons retrouver les fonctionnalités détaillées ci-dessous: +Les fonctionnalités détaillées ci-dessous sont accessibles depuis l'espace client OVHcloud : ![Service OVHcloud Load Balancer](images/iplb_service.png){.thumbnail} @@ -54,23 +82,23 @@ Via l'API OVHcloud, utilisez l'appel suivant : Pour plus d'informations sur les fonctionnalités de l'API, consultez la page [Détails des fonctions API](/pages/network/load_balancer/use_api_details){.ref} -### Ajouter une ferme de serveurs +### Ajouter une ferme de serveurs -Nous allons ajouter une ferme de serveurs HTTP à notre service, la partie en charge de répartir le trafic sur les serveurs. +Nous allons ajouter une ferme de serveurs HTTP à notre service. Cette partie est en charge de répartir le trafic sur les serveurs. #### Depuis l'espace client OVHcloud Dans l'onglet `Fermes de serveurs`{.action}, cliquez sur le bouton `Ajouter une ferme de serveurs`{.action}. -Remplissez les champs. Les seuls champs obligatoires pour une configuration simple sont le *Protocole* et le *Datacentre*. Il est recommandé de définir explicitement un *Port*, généralement le port 80 pour un service web. Si aucun port n'est spécifié, votre OVHcloud Load Balancer utilisera automatiquement le même port que le frontend correspondant et les sondes pourront ne pas fonctionner comme prévu. +Remplissez les champs. Les seuls champs obligatoires pour une configuration simple sont le *Protocole* et le *Datacentre*. Il est recommandé de définir explicitement un *Port*, généralement le port 80 pour un service web. Si aucun port n'est spécifié, votre service OVHcloud Load Balancer utilisera automatiquement le même port que le frontend correspondant et les sondes pourront ne pas fonctionner comme prévu. Si vous ajoutez plusieurs serveurs dans votre ferme, il est recommandé de configurer une `sonde de disponibilité` HTTP. Lorsqu'une sonde est configurée, le service OVHcloud Load Balancer pourra automatiquement désactiver un serveur qui serait en panne ou en maintenance, de manière à ne pas affecter les visiteurs. -![Ajout d'une ferme de serveurs via le Manager](images/add_backend.png){.thumbnail} +![Ajout d'une ferme de serveurs via l'espace client OVHcloud](images/add_backend.png){.thumbnail} Cliquez sur le bouton `Ajouter`{.action} une fois les champs remplis. -Votre ferme de serveurs devrait apparaitre dans la liste, sous l'onglet `Fermes de serveurs`{.action}. +Votre ferme de serveurs devrait apparaître dans la liste, sous l'onglet `Fermes de serveurs`{.action}. ![Détails de la ferme de serveurs créée](images/resume_backend.png){.thumbnail} @@ -111,13 +139,13 @@ Votre ferme de serveurs devrait apparaitre dans la liste, sous l'onglet `Fermes > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/farm/{farmId} > -### Ajouter un Serveur +### Ajouter un serveur Nous allons maintenant ajouter un serveur à notre ferme de serveurs. #### Depuis l'espace client OVHcloud -Toujours dans l'onglet `Fermes de serveurs`{.action}, sélectionnez la ferme dans laquelle vous souhaitez ajouter un serveur en cliquant sur la ligne correspondante. La liste des Serveurs déjà configurés dans la ferme apparaît en dessous de la liste des fermes, ainsi qu'un bouton `Ajouter un serveur`{.action}. Cliquez sur ce bouton pour ajouter un nouveau serveur. +Toujours dans l'onglet `Fermes de serveurs`{.action}, sélectionnez la ferme à laquelle vous souhaitez ajouter un serveur en cliquant sur la ligne correspondante. La liste des serveurs déjà configurés dans la ferme apparaît en dessous de la liste des fermes, ainsi qu'un bouton `Ajouter un serveur`{.action}. Cliquez sur ce bouton pour ajouter un nouveau serveur. Seul le champ *Adresse IPv4* est obligatoire. Si un serveur n'utilise pas le même port que celui défini plus haut dans la ferme, il est possible de le surcharger dans la configuration du serveur. Cependant, afin de conserver une configuration la plus homogène et maintenable possible, il est recommandé de n'utiliser ce paramètre que dans les cas avancés. @@ -152,7 +180,7 @@ Votre serveur devrait apparaître dans la liste des serveurs, dans l'onglet `Fer > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server > -- Modification d'un Serveur spécifique : +- Modification d'un serveur spécifique : > [!api] > @@ -166,9 +194,9 @@ Votre serveur devrait apparaître dans la liste des serveurs, dans l'onglet `Fer > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/farm/{farmId}/server > -### Ajouter un frontend +### Ajouter un frontend -Nous allons maintenant ajouter un `frontend` à notre service et le connecter à notre ferme de serveurs. Le frontend est la partie de votre OVHcloud Load Balancer qui sert à exposer votre service sur Internet. Dans un premier temps, nous allons le configurer en HTTP uniquement, sans certificat SSL/TLS. +Nous allons maintenant ajouter un `frontend` à notre service et le connecter à notre ferme de serveurs. Le frontend est la partie de votre service OVHcloud Load Balancer qui sert à exposer votre service sur Internet. Dans un premier temps, nous allons le configurer en HTTP uniquement, sans certificat SSL/TLS. #### Depuis l'espace client OVHcloud @@ -223,39 +251,46 @@ Votre frontend devrait apparaître dans la liste, sous l'onglet `Frontends`{.act > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/http/frontend/{frontendId} > -### Ajouter un certificat SSL/TLS +### Ajouter un certificat SSL/TLS -La section précédente décrivait la configuration générale pour un frontend HTTP. Cette section décrit les étapes supplémentaires pour activer le support du protocole HTTPS sur un Frontend HTTP. En particulier, il faudra : +La section précédente décrivait la configuration générale pour un frontend HTTP. Cette section décrit les étapes supplémentaires pour activer le support du protocole HTTPS sur un frontend HTTP. En particulier, il faudra : -- basculer le Frontend sur le port 443, standard pour le protocole HTTPS ; +- basculer le frontend sur le port 443, standard pour le protocole HTTPS ; - configurer un certificat SSL/TLS afin d'authentifier et chiffrer les connexions. -Que vous optiez pour une configuration via l'API ou via l'espace client OVHcloud, vous aurez le choix entre 2 stratégies pour vos certificats SSL/TLS, ce choix dépendant de vos besoins ainsi que des solutions actuellement en place : +Que vous optiez pour une configuration via l'API ou via l'espace client OVHcloud, vous aurez le choix entre 2 stratégies pour vos certificats SSL/TLS : - Importer un certificat SSL/TLS existant. -- Commander un certificat SSL/TLS géré automatiquement. La commande de certificats DV et EV arrivera prochainement. +- Commander un certificat SSL/TLS géré automatiquement. La commande de certificats DV et EV sera disponible prochainement. + +> [!primary] +> +> Ce choix dépend de vos besoins ainsi que des solutions actuellement en place. -Si vous optez pour l'importation d'un certificat SSL/TLS commandé et géré par vos soins, vous devrez le renouveler périodiquement vous-même et le mettre à jour dans votre service OVHcloud Load Balancer. La majorité des certificats sont valides pour 1 an. Certains peuvent l'être plus longtemps. Les certificats Let's Encrypt ne sont quant à eux valides que 3 mois. Il est recommandé d'utiliser le service géré automatiquement par votre OVHcloud Load Balancer pour les certificats Let's Encrypt afin de ne pas accidentellement rater une échéance. +Si vous optez pour l'importation d'un certificat SSL/TLS commandé et géré par vos soins, vous devrez le renouveler périodiquement vous-même et le mettre à jour dans votre service OVHcloud Load Balancer. La majorité des certificats sont valides pour 1 an. Certains peuvent l'être plus longtemps. Les certificats `Let's Encrypt` ne sont quant à eux valides que 3 mois. Il est recommandé d'utiliser le service géré automatiquement par votre service OVHcloud Load Balancer pour les certificats `Let's Encrypt` afin de ne pas accidentellement rater une échéance. Si vous optez pour un certificat géré par votre service OVHcloud Load Balancer, celui-ci sera automatiquement commandé, validé, installé et renouvelé périodiquement par votre OVHcloud Load Balancer.
-Pour que les opérations de validation et de renouvellement fonctionnent, il est nécessaire que le ou les domaines pour lesquels vous commandez ce certificat soient routés vers votre service OVHcloud Load Balancer. Cela implique que les champs *A* et *AAAA* de votre domaine pointent respectivement sur l'IPv4 et l'IPv6 de votre OVHcloud Load Balancer ou l'une de ses Additional IPs. Lors de la commande, vous recevrez un email qui vous guidera dans les étapes de la validation. +Pour que les opérations de validation et de renouvellement fonctionnent, il est nécessaire que le ou les domaines pour lesquels vous commandez ce certificat soient routés vers votre service OVHcloud Load Balancer. Cela implique que les champs *A* et *AAAA* de votre domaine pointent respectivement sur l'IPv4 et l'IPv6 de votre Load Balancer ou l'une de ses Additional IPs. Lors de la commande, vous recevrez un e-mail qui vous guidera dans les étapes de la validation. > [!primary] > -> Pour assurer la continuité de service lors du basculement de votre domaine vers l'IP de votre service OVHcloud Load Balancer afin de valider votre certificat, une bonne pratique est de commencer par configurer et tester complètement la configuration HTTP sur le port 80. De cette manière, votre site reste accessible sans interruption. +> Pour assurer la continuité de service lors du basculement de votre domaine vers l'IP de votre service OVHcloud Load Balancer afin de valider votre certificat, une bonne pratique consiste à commencer par configurer et tester complètement la configuration HTTP sur le port 80. De cette manière, votre site reste accessible sans interruption. > Si votre site dispose déjà d'une connexion HTTPS et que vous souhaitez migrer vers des certificats gérés par votre service OVHcloud Load Balancer, vous pouvez importer vos certificats existants, configurer et tester votre Frontend HTTPS et enfin commander un nouveau certificat pour le même domaine. Il sera automatiquement pris en compte avant l'expiration de votre ancien certificat. > -Les certificats configurés sur votre service OVHcloud Load Balancer sont automatiquement disponibles pour l'ensemble des frontend de votre service OVHcloud Load Balancer sur lesquels l'options *SSL* est activée. +Les certificats configurés sur votre service OVHcloud Load Balancer sont automatiquement disponibles pour l'ensemble des frontends de votre service OVHcloud Load Balancer sur lesquels l'option *SSL* est activée. #### Support de TLS 1.3 + Avec l'évolution constante des normes de sécurité sur Internet, OVHcloud s'engage à fournir les technologies les plus récentes et les plus sûres pour vos services. Le Load Balancer OVHcloud supporte désormais TLS 1.3. -##### Qu'est-ce que TLS 1.3 ? -TLS 1.3 est la dernière version du protocole TLS, offrant des améliorations significatives en matière de sécurité et de performance par rapport à TLS 1.2. Les avantages clés incluent un processus de handshake plus rapide, réduisant ainsi le temps nécessaire pour établir des connexions sécurisées, et l'utilisation de suites de chiffrement plus sûres pour renforcer la sécurité des données transmises. +##### **Qu'est-ce que TLS 1.3 ?** + +TLS 1.3 est la dernière version du protocole TLS. Elle améliore significativement la sécurité et les performances par rapport à TLS 1.2, notamment grâce à un processus de *handshake* plus rapide, réduisant le temps nécessaire pour établir des connexions sécurisées, et à l’utilisation de suites de chiffrement plus sûres pour renforcer la sécurité des données transmises. + +##### **Pourquoi utiliser TLS 1.3 avec OVHcloud Load Balancer ?** -##### Pourquoi utiliser TLS 1.3 avec OVHcloud Load Balancer ? -En intégrant TLS 1.3, votre Load Balancer OVHcloud bénéficiera d'une sécurité renforcée et d'une performance améliorée, assurant une expérience utilisateur optimale pour vos visiteurs. La réduction du temps de handshake accélère le chargement des pages, tandis que les améliorations de sécurité garantissent que vos données sont protégées avec les normes les plus récentes et les plus sûres. +En intégrant TLS 1.3, votre service OVHcloud Load Balancer bénéficiera d'une sécurité renforcée et d'une performance améliorée, assurant une expérience utilisateur optimale pour vos visiteurs. La réduction du temps de *handshake* accélère le chargement des pages, tandis que les améliorations de sécurité garantissent que vos données sont protégées avec les normes les plus récentes et les plus sûres. #### Depuis l'espace client OVHcloud @@ -269,12 +304,12 @@ Cliquez sur le bouton `Ajouter`{.action} une fois les champs remplis. Votre cert ![Ajout d'un certificat existant](images/add_certificat_custom.png){.thumbnail} -Pour ajouter un certificat Let's Encrypt, cliquez sur `Commander un certificat SSL`{.action}, renseignez votre domaine, assurez vous que celui-ci pointe bien sur votre service OVHcloud Load Balancer et laissez-vous guider par les e-mails que vous recevrez. Vous le verrez ensuite apparaître dans la liste des certificats disponibles. +Pour ajouter un certificat `Let's Encrypt`, cliquez sur `Commander un certificat SSL`{.action}, renseignez votre domaine, assurez-vous que celui-ci pointe bien sur votre service OVHcloud Load Balancer et laissez-vous guider par les e-mails que vous recevrez. Vous le verrez ensuite apparaître dans la liste des certificats disponibles. ![Command d'un certificat Let's Encrypt](images/add_certificat_letsencrypt.png){.thumbnail} -Une fois votre / vos certificats configurés, vous pouvez créer un frontend HTTPS, sur le même modèle que le frontend HTTP créé plus haut avec le port 443 et l'option *SSL* active.
-Optionnellement, vous pouvez également activer l'option *HSTS*. Si cette option est active, les navigateurs enregistreront que ce site Internet ne doit *plus jamais* être visité sans HTTPS après leur première visite en HTTPS. Cela permet de renforcer la sécurité globale en se protégeant contre les attaques de type « Homme du milieu » dans laquelle un acteur malveillant pour faire croire que votre site Internet n'est pas disponible en HTTPS et forcer vos visiteurs à basculer en « HTTP ». +Une fois votre/vos certificats configurés, vous pouvez créer un frontend HTTPS, sur le même modèle que le frontend HTTP créé plus haut avec le port 443 et l'option *SSL* active.
+Optionnellement, vous pouvez également activer l'option *HSTS*. Si cette option est active, les navigateurs enregistreront que ce site Internet ne doit *plus jamais* être visité sans HTTPS après leur première visite en HTTPS. Cela permet de renforcer la sécurité globale en se protégeant contre les attaques de type « Homme du milieu » dans laquelle un acteur malveillant pourrait faire croire que votre site Internet n'est pas disponible en HTTPS et forcer vos visiteurs à basculer en « HTTP ». > [!warning] > @@ -318,9 +353,9 @@ Optionnellement, vous pouvez également activer l'option *HSTS*. Si cette option > @api {v1} /ipLoadbalancing DELETE /ipLoadbalancing/{serviceName}/ssl/{id} > -### Appliquer les modifications +### Appliquer les modifications -Les modifications apportées à votre service OVHcloud Load Balancer soivent être *appliquées explicitement* dans chacune des zones configurées pour votre service OVHcloud Load Balancer. C'est seulement à ce moment qu'elles seront visibles pour vos visiteurs. Cela permet de faire un changement complexe de configuration en une seule fois. +Les modifications apportées à votre service OVHcloud Load Balancer doivent être *appliquées explicitement* dans chacune des zones configurées pour votre service OVHcloud Load Balancer. C'est seulement à ce moment qu'elles seront visibles pour vos visiteurs. Cela permet de faire un changement complexe de configuration en une seule fois. Si vous avez plusieurs zones, vous devrez appliquer la même configuration pour chacune de vos zones. @@ -330,7 +365,7 @@ Rendez-vous sur la page d'accueil de votre service OVHcloud Load Balancer et cli ![Appliquer la configuration](images/btn_apply_configuration.png){.thumbnail} -Selectionnez ensuite la liste des zones que vous souhaitez deployer et cliquez sur le bouton `Appliquer la configuration`{.action}. +Sélectionnez ensuite la liste des zones que vous souhaitez déployer et cliquez sur le bouton `Appliquer la configuration`{.action}. ![Appliquer la configuration zones](images/btn_apply_configuration_zones.png){.thumbnail} @@ -343,7 +378,7 @@ Selectionnez ensuite la liste des zones que vous souhaitez deployer et cliquez s > @api {v1} /ipLoadbalancing POST /ipLoadbalancing/{serviceName}/refresh > -### Validation +### Validation Une fois toutes ces étapes terminées, vous devriez disposer d'un service de répartition de charge fonctionnel. Vous pouvez valider l'état du service en visitant votre site. diff --git a/pages/network/load_balancer/create_probes/guide.en-asia.md b/pages/network/load_balancer/create_probes/guide.en-asia.md index 52be1704be5..d774b695308 100644 --- a/pages/network/load_balancer/create_probes/guide.en-asia.md +++ b/pages/network/load_balancer/create_probes/guide.en-asia.md @@ -1,45 +1,69 @@ --- -title: 'Working with probes' -excerpt: 'Find out about the general principles behind probes, and why they are used' -updated: 2019-02-12 +title: "Configuration of probes on an OVHcloud Load Balancer service" +excerpt: "Discover the general principles and use cases for probes" +updated: 2025-11-12 --- -## Objective + -With the OVH Load Balancer, you can distribute a front-end’s incoming traffic across a set of servers in a destination farm. +## Objective -There may be instances where a server in your farm becomes unavailable for a number of reasons, including oversaturation, an incident, or scheduled maintenance. When the OVH Load Balancer detects a connection error, it will try to redirect traffic to another server. The connection will be slower, but it will continue to work. +The OVHcloud Load Balancer allows you to distribute incoming traffic on a frontend to a set of servers in a destination farm. -However, the reasons behind certain types of unavailability can be harder to pinpoint. For example, if a new version of code is being deployed, the application may momentarily experience a glitch, and return a 500 error. In this particular case, a solution would be to mark the servers concerned as unavailable in the API before you begin the maintenance work, apply the configuration and update, then mark the server as available again. This method is not ideal, but it works. For more information on deploying a blue-green architecture with an OVH Load Balancer, please read our guide: . +It may happen that one of the servers in your farm is no longer available for various reasons, such as overload, an incident, or scheduled maintenance. When it encounters a connection error, your OVHcloud Load Balancer attempts to switch traffic to another server. The connection will be slowed down, but it will continue to function. -The purpose of a probe is to test an infrastructure’s health. It periodically examines each of your servers, to ensure that they are working properly. If it detects an error, the server is automatically disabled until the situation is resolved. +However, the causes of some unavailability are more subtle. For example, if a new version of the code is being deployed, the application may temporarily be in a transitional state and return 500 errors. In this specific case, one solution would be to mark the affected servers as unavailable in the API before the start of the maintenance, apply the configuration and update, and then mark the server as available again. This method is not ideal, but it works.
+For more details on deploying a Blue-Green architecture with your OVHcloud Load Balancer, refer to [this guide](/pages/network/load_balancer/case_blue_green). -Since this service is still very new, its basic features are only available in the API. +Probes are health checks. They periodically query each of your servers to ensure they are operational. If an error is detected, the server is automatically disabled until the situation is resolved. -**This guide will explain the general principles behind probes, and provide practical examples of probes being used.** +**This guide will present the general principles, as well as usage scenarios for probes, drawn from real-world use cases.** ## Requirements -- a correctly configured OVH Load Balancer, with farms and servers set +- Have an [OVHcloud Load Balancer](/links/network/load-balancer) offer in your OVHcloud account. The service must be properly configured, with farms and servers set up. +- Be logged in to your [OVHcloud Control Panel](/links/manager). ## Instructions -### An introduction to the API. +**Table of contents** + +- [Probe API overview](#probe-api) +- [Examples](#examples) +- [Reference](#reference) +- [From the OVHcloud Control Panel](#manager) + +### Probe API overview -The API for probes in the OVH Load Balancer is designed to be flexible and scalable. +The probe API of your OVHcloud Load Balancer has been designed to be flexible and scalable. -The probes can be configured directly on the farms. All of the servers from a single farm will have exactly the same probe applied. However, probe activation and deactivation is specific for each server. As a result, it is possible to only monitor certain servers within a single farm. +Probes are configured directly on the farms. All servers in the same farm thus apply exactly the same probe. However, enabling or disabling a probe is specific to each server. It is therefore possible to "monitor" only certain servers in the same farm. -You can view the list of available probes and their settings with the following API call: +The list of available probes and their parameters can be consulted with the API call : > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/availableFarmProbes > -For more information on this call, please read the *Available probes* section at the bottom of this guide. +For more information on this call, we invite you to consult the [Available probes](#available-probes) section at the bottom of this guide. -The probes in this list can be configured on `http` and `tcp` farms via the following calls: +The probes returned by this list can be configured on `http` and `tcp` farms via the following calls : > [!api] > @@ -61,56 +85,58 @@ The probes in this list can be configured on `http` and `tcp` farms via the foll > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/tcp/farm/{farmId} > -For more information on these calls, please read the *Probe configuration* section at the bottom of this guide. +For more information on these calls, you can refer to the [Probe handling](#handling-probes) section of this guide. -### Examples +### Examples -#### Check if the server accepts TCP connections. +#### Check if the server accepts TCP connections -This is the simplest method to set up. It is compatible with `tcp` and `http` farms. If no other probes are configured, you can activate it to start. It works by periodically attempting to establish a connection on each of your servers. If the connection fails twice in a row, the server is put aside until it responds again. +This is the simplest probe to set up. It is compatible with `tcp` and `http` farms. If no other probe is configured, you can activate this one to start. It works by periodically trying to open a connection on each of your servers. If the connection fails twice in a row, the server is put aside until it responds again. -In practice, this gives a probe: +In practice, this gives a probe : |Field|Value and description| |---|---| -|serviceName|Your OVH Load Balancer ID| -|farmId|Your TCP or HTTP farm| +|serviceName|Identifier of your OVHcloud Load Balancer| +|farmId|Identifier of your TCP or HTTP farm| |probe.type|"tcp"| -All other probe fields can keep their default values. Just apply the configuration to the zone concerned, and the probe will begin to work. +All other `probe` fields can remain at their default values. You just need to apply the configuration in the relevant area. -#### Test a specific HTTP page. +#### Test a specific HTTP page -By default, the HTTP `probe` sends an "OPTIONS" request on "/" in HTTP/1.0, without a domain name. In many cases, this is sufficient, but some servers do not manage this method. You can carry out much more powerful tests with the HTTP probe. For example, a good practice when exposing a HTTP service is to add a router dedicated to probes. It is normal to see "/status", "/health", and "/check", which summarise the service’s status. +By default, the HTTP probe sends an `OPTIONS` request on `/` in HTTP/1.0, without a domain name. This is sufficient in many cases, but some servers do not handle this method.
+It is possible to perform much more powerful tests with the HTTP probe. For example, a good practice when exposing an HTTP service is to add a dedicated route for probes. It is common to find `/status`, `/health`, `/check` which return a summary of the service's status. -In practice, if you want to configure the probe to send a "GET" request on [http://api.example.com/status](http://api.example.com/status), it gives: +In practice, if you want to configure the probe to send a `GET` request to [http://api.example.com/status](http://api.example.com/status), this gives : |Field|Value and description| |---|---| -|serviceName|Your OVH Load Balancer ID| -|farmId|Your TCP or HTTP farm| +|serviceName|Identifier of your OVHcloud Load Balancer| +|farmId|Identifier of your TCP or HTTP farm| |probe.type|http| |probe.method|GET| |probe.url|[http://api.example.com/status](http://api.example.com/status)| |probe.match|status| -|probe.pattern|200 (multiple status codes can be added, provided they are separated by commas)| +|probe.pattern|200 (several status codes can be added, separated by commas)| -All other probe fields can keep their default values. Finally, apply the configuration to the zone concerned. +All other `probe` fields can remain at their default values. It is then sufficient to apply the configuration in the relevant area. -#### Use an external HTTP test. +#### Use an external HTTP test -What happens if, for example, your service is an IMAP server that relies on an LDAP server for authentication? The server may accept connections, but experience a temporary connection issue with the LDAP server. If this happens, the customers redirected to this server would be able to connect, but wouldn’t be able to authenticate. As a result, the server would need to be removed from the farm. +What if your service is, for example, an IMAP server that relies on an LDAP server for authentication ?
+It is possible that the server accepts connections, but has a temporary connection issue with the LDAP server. If this happens, clients who are directed to this server could connect but not authenticate. The server should therefore be removed from the farm. -If you are using a `tcp` probe, it will manage to connect. As a result, it will consider the service to be available, even though this is not the case. +If a `tcp` type probe is used, it will be able to connect and consider the service available even though it is not the case. -In this situation, the health test would ideally be able to confirm that the basic service works. You can provide a specific port to use in the tests. This way, you can set up arbitrary tests for a service, and expose them to HTTP on a dedicated port. +In this scenario, the ideal would be for the health check to confirm that the base service is working. It is possible to indicate a specific port to use in the tests. This allows arbitrary tests to be set up for a service and exposed in HTTP, on a dedicated port. -For example, in this situation, you can have a HTTP server on port 8080\. It will test the IMAP server via the URL "/service/imap/status", and will return ‘OK’ when everything is working properly. In practice, this will return: +For example, in this scenario, it would be possible to have an HTTP server on port 8080 that tests the IMAP server via the url `/service/imap/status` and returns *OK* when everything is fine. This would give in practice : |Field|Value and description| |---|---| -|serviceName|Your OVH Load Balancer ID| -|farmId|Your TCP or HTTP farm| +|serviceName|Identifier of your OVHcloud Load Balancer| +|farmId|Identifier of your TCP or HTTP farm| |probe.type|http| |probe.port|8080| |probe.method|GET| @@ -118,24 +144,24 @@ For example, in this situation, you can have a HTTP server on port 8080\. It wil |probe.match|contains| |probe.pattern|OK| -Just apply the configuration to the zone concerned, and the probe will begin to work. +It is then sufficient to apply the configuration in the relevant area. > [!warning] > -> If the HTTP service dedicated to monitoring your IMAP service experiences a fault, the IMAP service will also be considered faulty, even if it is working properly. +> If the HTTP service dedicated to monitoring your IMAP service itself fails, the IMAP service will also be considered as failed, even if it is in perfect working condition. > -### Reference +### Reference -#### Probe configuration. +#### Probe handling -##### Configure a probe. +##### **Configure a probe** -Probes can be configured on a new farm (`POST`) or an existing one (`PUT`). Since the two methods are equivalent, only the second (`PUT`) method is presented here. +Probes can be configured on a new farm (`POST`) or an existing farm (`PUT`). The two methods being equivalent, only the second one (`PUT`) will be presented here. > [!faq] > -> Service: +> Service : > >> > [!api] >> > @@ -143,85 +169,86 @@ Probes can be configured on a new farm (`POST`) or an existing one (`PUT`). Sinc >> > >> > -> Settings: +> Parameters : > >> > **serviceName** >> > ->> >> Your OVH Load Balancer ID. +>> >> The identifier of your OVHcloud Load Balancer. >> > >> > **farmId** >> > ->> >> Your `farm` ID number. +>> >> The numeric identifier of your `farm`. >> > >> > **probe** >> > >> >> **type** >> >> ->> >> > The type of `probe` to activate. The probe types managed are: +>> >> > The type of `probe` to enable. The probe types handled are : >> >> > ->> >> > `tcp` for a basic TCP connection test. +>> >> > `tcp` for a basic TCP connection test ; >> >> > ->> >> > `http` for a HTTP connection test. You can specify the URL and the method. +>> >> > `http` for an HTTP connection test. It is possible to specify the URL and method ; >> >> > ->> >> > `smtp` for a basic SMTP connection test. +>> >> > `smtp` for a basic SMTP connection test ; >> >> > ->> >> > `mysql` for a basic MySQL connection test. +>> >> > `mysql` for a basic MySQL connection test ; >> >> > ->> >> > `pgsql` for a basic PostgreSQL connection test. +>> >> > `pgslq` for a basic PostgreSQL connection test ; >> >> > ->> >> > `oco` for a confirmation of the general status returned on port 79. +>> >> > `oco` for a general status validation returned on port 79. >> > >> >> **interval** >> >> ->> >> > The interval (in seconds) between a probe’s two connection attempts. It must be at least 30 seconds. +>> >> > The interval in seconds between two probe attempts. It must be at least 30 seconds. >> > >> >> **port** >> >> ->> >> > The port that the probe must use, if it is different to the port configured on the farm. ->> >> > This enables you to delegate a server’s status validation to a separate service on the machine, and carry out arbitrary probes. +>> >> > The port that the probe should use, if it is different from the one configured on the farm. +>> >> > This allows you to delegate the server status validation to a third-party service on the machine and perform arbitrary probes. >> > >> >> **method** >> >> ->> >> > The HTTP method to use if the probe is a “http” probe. ->> >> > Compatible methods are `GET`, `HEAD` and `OPTIONS` (by default). +>> >> > The HTTP method to use if the probe is of type "http". +>> >> > The compatible methods are `GET`, `HEAD` and `OPTIONS` (default). >> > >> >> **url** >> >> ->> >> > The URL to use for tests, if it is a “http” probe type. ->> >> > It should be formulated as follows: `[[https?://]www.example.com]/path/to/check`. ->> >> > If a domain is specified, its request will be sent to HTTP/1.1 rather than HTTP/1.0 by default. +>> >> > The URL to use for the tests, if the probe is of type "http". +>> >> > Its form must be `[[https?://]www.example.com]/path/to/check`. +>> >> > If a domain is specified, the request will be sent in HTTP/1.1 instead of HTTP/1.0 by default. >> > >> >> **match** >> >> ->> >> > The type of comparison to use to check if the server is in good health. ->> >> > The managed comparison types are `default`, `status`, `contains` and `matches`. ->> >> > Comparison types are compatible with both “http” and “tcp” probes. +>> >> > The type of comparator to use to check that the server is healthy. +>> >> > The comparators handled are `default`, `status`, `contains` and `matches`. +>> >> > The comparators are compatible with "http" and "tcp" probes. >> > >> >> **pattern** >> >> ->> >> > The value to use as an argument of the comparison type if it is different from “default”. +>> >> > The value to use as an argument for the comparator if it is different from "default". >> > >> >> **forceSsl** >> >> ->> >> > This defines whether the probe must work in SSL/TLS, even if the farm is configured to connect via standard TCP. ->> >> > This can be useful when, for example, your OVH Load Balancer is configured to monitor HTTPS traffic in TCP without decrypting it. +>> >> > Defines whether the probe should work in SSL/TLS even if the farm is configured to connect in classic TCP. +>> >> > This can be useful, for example, when your OVHcloud Load Balancer is configured to forward HTTPS traffic in TCP without decrypting it. > -Other settings can be edited via this call. Since this guide focuses on probes, they are not documented here. +Other parameters can be edited via this call. As this guide focuses on probes, they are not documented here. -If a port other than the farm’s base port is configured on the probe, the `proxyprotocol` and `ssl` settings are reset. As an example, we will take a configured farm to use `proxyprotocol` on **port 4242**, and an associated probe using **port 8080**. The probe will not send the `proxyprotocol` header when it connects on **port 8080**. The same goes for `ssl`, but it can be forced. +If a port other than the base port of the farm is configured on the probe, the `proxyprotocol` and `ssl` parameters are reset. Take the example of a farm configured to use `proxyprotocol` on port **4242** and a probe associated with port **8080**: the latter will not send the `proxyprotocol` header when connecting to port **8080**. The same applies to `ssl`, which can nevertheless be forced. > [!warning] > -> When a probe is configured on a farm, it must be activated on the servers. +> When a probe is configured on a farm, it must also be enabled on the servers. > -##### Activate probes on a server. -For a probe to be active, it must be configured on the farm and activated on the servers concerned. With this call, you can activate the probe being taken into account: +##### **Enable probes on a server** + +For a probe to be active, it must have been configured on the farm and enabled on the relevant servers. This call allows you to enable the probe : > [!faq] > -> Service: +> Service : > >> > [!api] >> > @@ -229,47 +256,47 @@ For a probe to be active, it must be configured on the farm and activated on the >> > >> > -> Settings: +> Parameters : > >> > **serviceName** >> > ->> >> Your OVH Load Balancer ID. +>> >> The identifier of your OVHcloud Load Balancer. >> > >> > **farmId** >> > ->> >> Your `farm` ID number. +>> >> The numeric identifier of your `farm`. >> > >> > **serverId** >> > ->> >> Your `server’s` ID number. +>> >> The numeric identifier of your `server`. >> > >> > **probe** >> > ->> >> Whether or not the `probes` must be taken into account. +>> >> Indicates whether `probe` should be taken into account or not. > -Other settings can be edited via this call. Since this guide focuses on probes, they are not documented here. +Other parameters can be edited via this call. As this guide focuses on probes, they are not documented here. -#### Available comparison types. +#### Available comparators -Four comparison types are available to confirm a probe’s results: +Four comparators are available to validate the result of a probe : -|Comparison type|Description| +|Comparator|Description| |---|---| -|default|Launches a basic test, without any settings.| -|status|A list of valid HTTP response codes, separated by commas.| -|contains|Checks that the pattern can be found in the response.| -|matches|Checks that the response corresponds to a regular expression pattern.| +|default|Runs a basic test, without parameters.| +|status|Comma-separated list of valid HTTP return codes.| +|contains|Checks that the pattern is in the response.| +|matches|Checks that the response matches the pattern regular expression.| -‘Contains’ and ‘matches’ comparison types find a correspondence in the first 16 KB of the response. If the response is longer than 16 KB, whatever comes afterwards will be ignored during the test. Please note that to optimise your performance, we recommend returning as little information as possible in your probes. +The `contains` and `matches` comparators look for a match in the first 16 KB of the response. If it is longer, the part beyond will be ignored during the search. Note that for better performance, we recommend returning as little information as possible in your probes. -#### Available probes. +#### Available probes -You can get a list of the available probes using the following API call: +The list of available probes can be obtained with the API call : > [!faq] > -> Service: +> Service : > >> > [!api] >> > @@ -277,56 +304,56 @@ You can get a list of the available probes using the following API call: >> > >> > -> Response: +> Response : > >> > **type** >> > ->> >> The type of `probe` to configure in the `probe.type` of `farms`. +>> >> The type of `probe` to configure in the `probe.type` field of the `farms`. >> >> ->> >> The probe types managed are: +>> >> The probe types handled are : >> >> ->> >> `tcp` for a basic TCP connection test. +>> >> `tcp` for a basic TCP connection test ; >> >> ->> >> `http` for a HTTP connection test. You can specify the URL and the method. +>> >> `http` for an HTTP connection test. It is possible to specify the URL and method ; >> >> ->> >> `smtp` for a basic SMTP connection test. +>> >> `smtp` for a basic SMTP connection test ; >> >> ->> >> `mysql` for a basic MySQL connection test. +>> >> `mysql` for a basic MySQL connection test ; >> >> ->> >> `pgsql` for a basic PostgreSQL connection test. +>> >> `pgslq` for a basic PostgreSQL connection test ; >> >> ->> >> `oco` for a confirmation of the general status returned on port 79. +>> >> `oco` for a general status validation returned on port 79. >> > >> > **port** >> > ->> >> This defines whether the port can be configured for this probe. +>> >> Indicates whether the port can be configured for this probe. >> > >> > **method** >> > ->> >> The list of HTTP methods managed, or `null` if none are managed. +>> >> The list of HTTP methods handled or `null` if none exist. >> > >> > **url** >> > ->> >> This defines if the probe’s URL can be configured. +>> >> Indicates whether the probe URL can be configured. >> > >> > **matches** >> > ->> >> The list of comparison types available for this probe. +>> >> The list of available comparators for this probe. >> >> The interpretation of the `probe.pattern` field depends on this field. ->> >> The comparison types potentially managed are: +>> >> The potentially handled comparators are : >> >> ->> >> `default`. The most simple test, without any particular conditions.`probe.pattern` must be empty. +>> >> `default` the simplest test, without specific conditions. `probe.pattern` must be empty ; >> >> ->> >> `status`. Checks if the HTTP status code is in the list separated by commas. +>> >> `status` checks that the HTTP status code is in the comma-separated list ; >> >> ->> >> `contains`. Checks that the server response contains `probe.pattern`. +>> >> `contains` checks that the server response contains `probe.pattern` ; >> >> ->> >> `matches`. Checks that the server response matches `probe.pattern`. +>> >> `matches` checks that the server response matches `probe.pattern`. > -##### TCP +##### **TCP** -This probe attempts to establish a TCP connection to the server. If the server sends a “banner”, you can check if it matches a schema. The default test simply ensures that the connection can be established. +This probe attempts to establish a TCP connection with the server. If the latter sends a "banner", it is possible to check that it matches a pattern. The default test simply ensures that the connection can be established. |Fields|Description| |---|---| @@ -336,29 +363,29 @@ This probe attempts to establish a TCP connection to the server. If the server s |URL|Not supported| |matches|`default`, `contains` or `matches`| -##### HTTP +##### **HTTP** -This probe attempts to establish a HTTP connection to the server. If the server responds, you can check its HTTP status code, and that the response body matches a schema. The default test sends an OPTIONS request to the '/' page in HTTP/1.0, without a Host field. +This probe attempts to establish an HTTP connection with the server. If the latter responds, it is possible to check its HTTP status code or that the response body matches a pattern. The default test sends an OPTIONS request to the '/' page in HTTP/1.0, without the Host field. |Fields|Description| |---|---| |type|`http`| |port|Configurable| |method|`GET`, `HEAD` or `OPTIONS`| -|URL|URL in the form: \[\[https?://]www.example.com]/path/to/check| +|URL|URL of the form [[https?://]www.example.com]/path/to/check| |matches|`default`, `contains` or `matches`| -If the URL is specified, the domain name and protocol are operational. If a domain name is specified, the “Host” field of the request will be filled in, and the request will be sent to HTTP/1.1. If the protocol is specified, it must be consistent with the farm’s SSL configuration. +If a URL is specified, the domain name and protocol are operational. If a domain name is specified, the "Host" field of the request will be filled in and the request will be sent in HTTP/1.1. If the protocol is specified, it must be consistent with the SSL configuration of the farm. > [!primary] > -> We recommend configuring the method, at least, with GET. -> Some servers, including NGINX, do not manage the OPTIONS method without it being configured in advance. +> It is recommended to configure at least the method with GET. +> Indeed, some servers -including Nginx- do not handle the OPTIONS method without prior configuration. > -##### SMTP +##### **SMTP** -This probe attempts to establish an SMTP connection with the server, and sends the command "HELLO localhost". If the server responds, the probe checks that the response code starts with a ‘2’ (success). This probe does not have any specific configuration options. +This probe attempts to establish an SMTP connection with the server and sends the "HELLO localhost" command. If the latter responds, the probe checks that the return code starts with a "2" (success). This probe has no specific configuration options. |Fields|Description| |---|---| @@ -368,9 +395,9 @@ This probe attempts to establish an SMTP connection with the server, and sends t |URL|Not supported| |matches|`default`| -##### MySQL +##### **MySQL** -This probe attempts to establish a MySQL connection with the server, and analyses the server’s response. This probe does not have any specific configuration options. +This probe attempts to establish a MySQL connection with the server and analyses the server's response. This probe has no specific configuration options. |Fields|Description| |---|---| @@ -380,9 +407,9 @@ This probe attempts to establish a MySQL connection with the server, and analyse |URL|Not supported| |matches|`default`| -##### PostgreSQL +##### **PostgreSQL** -This probe attempts to establish a PostgreSQL connection with the server, and analyses the server’s response. This probe does not have any specific configuration options. +This probe attempts to establish a PostgreSQL connection with the server and analyses the server's response. This probe has no specific configuration options. |Fields|Description| |---|---| @@ -392,9 +419,9 @@ This probe attempts to establish a PostgreSQL connection with the server, and an |URL|Not supported| |matches|`default`| -##### oco +##### **oco** -This probe attempts to establish a TCP connection on port 79 of your server, and checks that the response starts with a ‘2’ (success). This probe does not have any specific configuration options. +This probe attempts to establish a TCP connection on port 79 of your server and checks that the response starts with a "2" (success). This probe has no specific configuration options. |Fields|Description| |---|---| @@ -404,20 +431,24 @@ This probe attempts to establish a TCP connection on port 79 of your server, and |URL|Not supported| |matches|`default`| -## Via the OVH Control Panel. +### From the OVHcloud Control Panel -You can configure probes when you add (or modify) a server farm, in advanced settings. +You can configure probes when you add or modify a server farm, in advanced settings. -![Advanced settings for a farm](images/farm_advanced_settings.png){.thumbnail} +![Advanced farm settings](images/farm_advanced_settings.png){.thumbnail} -This is how you access the probe type’s configuration. +You will then have access to the configuration for the probe type. ![Probe settings](images/farm_advanced_settings_unfolded.png){.thumbnail} -If you are able to do so with the probe type you have selected, you can configure specific advanced settings for the probe. +If the probe type you have selected allows it, you can configure advanced settings that are specific to that probe. -![Advanced settings for a probe](images/probe_settings.png){.thumbnail} +![Advanced probe settings](images/probe_settings.png){.thumbnail} A new configuration window will appear, with the probe’s settings. -![Advanced settings for a probe](images/probe_settings_dialog.png){.thumbnail} +![Advanced probe settings](images/probe_settings_dialog.png){.thumbnail} + +## Go further + +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_probes/guide.en-au.md b/pages/network/load_balancer/create_probes/guide.en-au.md index 52be1704be5..d774b695308 100644 --- a/pages/network/load_balancer/create_probes/guide.en-au.md +++ b/pages/network/load_balancer/create_probes/guide.en-au.md @@ -1,45 +1,69 @@ --- -title: 'Working with probes' -excerpt: 'Find out about the general principles behind probes, and why they are used' -updated: 2019-02-12 +title: "Configuration of probes on an OVHcloud Load Balancer service" +excerpt: "Discover the general principles and use cases for probes" +updated: 2025-11-12 --- -## Objective + -With the OVH Load Balancer, you can distribute a front-end’s incoming traffic across a set of servers in a destination farm. +## Objective -There may be instances where a server in your farm becomes unavailable for a number of reasons, including oversaturation, an incident, or scheduled maintenance. When the OVH Load Balancer detects a connection error, it will try to redirect traffic to another server. The connection will be slower, but it will continue to work. +The OVHcloud Load Balancer allows you to distribute incoming traffic on a frontend to a set of servers in a destination farm. -However, the reasons behind certain types of unavailability can be harder to pinpoint. For example, if a new version of code is being deployed, the application may momentarily experience a glitch, and return a 500 error. In this particular case, a solution would be to mark the servers concerned as unavailable in the API before you begin the maintenance work, apply the configuration and update, then mark the server as available again. This method is not ideal, but it works. For more information on deploying a blue-green architecture with an OVH Load Balancer, please read our guide: . +It may happen that one of the servers in your farm is no longer available for various reasons, such as overload, an incident, or scheduled maintenance. When it encounters a connection error, your OVHcloud Load Balancer attempts to switch traffic to another server. The connection will be slowed down, but it will continue to function. -The purpose of a probe is to test an infrastructure’s health. It periodically examines each of your servers, to ensure that they are working properly. If it detects an error, the server is automatically disabled until the situation is resolved. +However, the causes of some unavailability are more subtle. For example, if a new version of the code is being deployed, the application may temporarily be in a transitional state and return 500 errors. In this specific case, one solution would be to mark the affected servers as unavailable in the API before the start of the maintenance, apply the configuration and update, and then mark the server as available again. This method is not ideal, but it works.
+For more details on deploying a Blue-Green architecture with your OVHcloud Load Balancer, refer to [this guide](/pages/network/load_balancer/case_blue_green). -Since this service is still very new, its basic features are only available in the API. +Probes are health checks. They periodically query each of your servers to ensure they are operational. If an error is detected, the server is automatically disabled until the situation is resolved. -**This guide will explain the general principles behind probes, and provide practical examples of probes being used.** +**This guide will present the general principles, as well as usage scenarios for probes, drawn from real-world use cases.** ## Requirements -- a correctly configured OVH Load Balancer, with farms and servers set +- Have an [OVHcloud Load Balancer](/links/network/load-balancer) offer in your OVHcloud account. The service must be properly configured, with farms and servers set up. +- Be logged in to your [OVHcloud Control Panel](/links/manager). ## Instructions -### An introduction to the API. +**Table of contents** + +- [Probe API overview](#probe-api) +- [Examples](#examples) +- [Reference](#reference) +- [From the OVHcloud Control Panel](#manager) + +### Probe API overview -The API for probes in the OVH Load Balancer is designed to be flexible and scalable. +The probe API of your OVHcloud Load Balancer has been designed to be flexible and scalable. -The probes can be configured directly on the farms. All of the servers from a single farm will have exactly the same probe applied. However, probe activation and deactivation is specific for each server. As a result, it is possible to only monitor certain servers within a single farm. +Probes are configured directly on the farms. All servers in the same farm thus apply exactly the same probe. However, enabling or disabling a probe is specific to each server. It is therefore possible to "monitor" only certain servers in the same farm. -You can view the list of available probes and their settings with the following API call: +The list of available probes and their parameters can be consulted with the API call : > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/availableFarmProbes > -For more information on this call, please read the *Available probes* section at the bottom of this guide. +For more information on this call, we invite you to consult the [Available probes](#available-probes) section at the bottom of this guide. -The probes in this list can be configured on `http` and `tcp` farms via the following calls: +The probes returned by this list can be configured on `http` and `tcp` farms via the following calls : > [!api] > @@ -61,56 +85,58 @@ The probes in this list can be configured on `http` and `tcp` farms via the foll > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/tcp/farm/{farmId} > -For more information on these calls, please read the *Probe configuration* section at the bottom of this guide. +For more information on these calls, you can refer to the [Probe handling](#handling-probes) section of this guide. -### Examples +### Examples -#### Check if the server accepts TCP connections. +#### Check if the server accepts TCP connections -This is the simplest method to set up. It is compatible with `tcp` and `http` farms. If no other probes are configured, you can activate it to start. It works by periodically attempting to establish a connection on each of your servers. If the connection fails twice in a row, the server is put aside until it responds again. +This is the simplest probe to set up. It is compatible with `tcp` and `http` farms. If no other probe is configured, you can activate this one to start. It works by periodically trying to open a connection on each of your servers. If the connection fails twice in a row, the server is put aside until it responds again. -In practice, this gives a probe: +In practice, this gives a probe : |Field|Value and description| |---|---| -|serviceName|Your OVH Load Balancer ID| -|farmId|Your TCP or HTTP farm| +|serviceName|Identifier of your OVHcloud Load Balancer| +|farmId|Identifier of your TCP or HTTP farm| |probe.type|"tcp"| -All other probe fields can keep their default values. Just apply the configuration to the zone concerned, and the probe will begin to work. +All other `probe` fields can remain at their default values. You just need to apply the configuration in the relevant area. -#### Test a specific HTTP page. +#### Test a specific HTTP page -By default, the HTTP `probe` sends an "OPTIONS" request on "/" in HTTP/1.0, without a domain name. In many cases, this is sufficient, but some servers do not manage this method. You can carry out much more powerful tests with the HTTP probe. For example, a good practice when exposing a HTTP service is to add a router dedicated to probes. It is normal to see "/status", "/health", and "/check", which summarise the service’s status. +By default, the HTTP probe sends an `OPTIONS` request on `/` in HTTP/1.0, without a domain name. This is sufficient in many cases, but some servers do not handle this method.
+It is possible to perform much more powerful tests with the HTTP probe. For example, a good practice when exposing an HTTP service is to add a dedicated route for probes. It is common to find `/status`, `/health`, `/check` which return a summary of the service's status. -In practice, if you want to configure the probe to send a "GET" request on [http://api.example.com/status](http://api.example.com/status), it gives: +In practice, if you want to configure the probe to send a `GET` request to [http://api.example.com/status](http://api.example.com/status), this gives : |Field|Value and description| |---|---| -|serviceName|Your OVH Load Balancer ID| -|farmId|Your TCP or HTTP farm| +|serviceName|Identifier of your OVHcloud Load Balancer| +|farmId|Identifier of your TCP or HTTP farm| |probe.type|http| |probe.method|GET| |probe.url|[http://api.example.com/status](http://api.example.com/status)| |probe.match|status| -|probe.pattern|200 (multiple status codes can be added, provided they are separated by commas)| +|probe.pattern|200 (several status codes can be added, separated by commas)| -All other probe fields can keep their default values. Finally, apply the configuration to the zone concerned. +All other `probe` fields can remain at their default values. It is then sufficient to apply the configuration in the relevant area. -#### Use an external HTTP test. +#### Use an external HTTP test -What happens if, for example, your service is an IMAP server that relies on an LDAP server for authentication? The server may accept connections, but experience a temporary connection issue with the LDAP server. If this happens, the customers redirected to this server would be able to connect, but wouldn’t be able to authenticate. As a result, the server would need to be removed from the farm. +What if your service is, for example, an IMAP server that relies on an LDAP server for authentication ?
+It is possible that the server accepts connections, but has a temporary connection issue with the LDAP server. If this happens, clients who are directed to this server could connect but not authenticate. The server should therefore be removed from the farm. -If you are using a `tcp` probe, it will manage to connect. As a result, it will consider the service to be available, even though this is not the case. +If a `tcp` type probe is used, it will be able to connect and consider the service available even though it is not the case. -In this situation, the health test would ideally be able to confirm that the basic service works. You can provide a specific port to use in the tests. This way, you can set up arbitrary tests for a service, and expose them to HTTP on a dedicated port. +In this scenario, the ideal would be for the health check to confirm that the base service is working. It is possible to indicate a specific port to use in the tests. This allows arbitrary tests to be set up for a service and exposed in HTTP, on a dedicated port. -For example, in this situation, you can have a HTTP server on port 8080\. It will test the IMAP server via the URL "/service/imap/status", and will return ‘OK’ when everything is working properly. In practice, this will return: +For example, in this scenario, it would be possible to have an HTTP server on port 8080 that tests the IMAP server via the url `/service/imap/status` and returns *OK* when everything is fine. This would give in practice : |Field|Value and description| |---|---| -|serviceName|Your OVH Load Balancer ID| -|farmId|Your TCP or HTTP farm| +|serviceName|Identifier of your OVHcloud Load Balancer| +|farmId|Identifier of your TCP or HTTP farm| |probe.type|http| |probe.port|8080| |probe.method|GET| @@ -118,24 +144,24 @@ For example, in this situation, you can have a HTTP server on port 8080\. It wil |probe.match|contains| |probe.pattern|OK| -Just apply the configuration to the zone concerned, and the probe will begin to work. +It is then sufficient to apply the configuration in the relevant area. > [!warning] > -> If the HTTP service dedicated to monitoring your IMAP service experiences a fault, the IMAP service will also be considered faulty, even if it is working properly. +> If the HTTP service dedicated to monitoring your IMAP service itself fails, the IMAP service will also be considered as failed, even if it is in perfect working condition. > -### Reference +### Reference -#### Probe configuration. +#### Probe handling -##### Configure a probe. +##### **Configure a probe** -Probes can be configured on a new farm (`POST`) or an existing one (`PUT`). Since the two methods are equivalent, only the second (`PUT`) method is presented here. +Probes can be configured on a new farm (`POST`) or an existing farm (`PUT`). The two methods being equivalent, only the second one (`PUT`) will be presented here. > [!faq] > -> Service: +> Service : > >> > [!api] >> > @@ -143,85 +169,86 @@ Probes can be configured on a new farm (`POST`) or an existing one (`PUT`). Sinc >> > >> > -> Settings: +> Parameters : > >> > **serviceName** >> > ->> >> Your OVH Load Balancer ID. +>> >> The identifier of your OVHcloud Load Balancer. >> > >> > **farmId** >> > ->> >> Your `farm` ID number. +>> >> The numeric identifier of your `farm`. >> > >> > **probe** >> > >> >> **type** >> >> ->> >> > The type of `probe` to activate. The probe types managed are: +>> >> > The type of `probe` to enable. The probe types handled are : >> >> > ->> >> > `tcp` for a basic TCP connection test. +>> >> > `tcp` for a basic TCP connection test ; >> >> > ->> >> > `http` for a HTTP connection test. You can specify the URL and the method. +>> >> > `http` for an HTTP connection test. It is possible to specify the URL and method ; >> >> > ->> >> > `smtp` for a basic SMTP connection test. +>> >> > `smtp` for a basic SMTP connection test ; >> >> > ->> >> > `mysql` for a basic MySQL connection test. +>> >> > `mysql` for a basic MySQL connection test ; >> >> > ->> >> > `pgsql` for a basic PostgreSQL connection test. +>> >> > `pgslq` for a basic PostgreSQL connection test ; >> >> > ->> >> > `oco` for a confirmation of the general status returned on port 79. +>> >> > `oco` for a general status validation returned on port 79. >> > >> >> **interval** >> >> ->> >> > The interval (in seconds) between a probe’s two connection attempts. It must be at least 30 seconds. +>> >> > The interval in seconds between two probe attempts. It must be at least 30 seconds. >> > >> >> **port** >> >> ->> >> > The port that the probe must use, if it is different to the port configured on the farm. ->> >> > This enables you to delegate a server’s status validation to a separate service on the machine, and carry out arbitrary probes. +>> >> > The port that the probe should use, if it is different from the one configured on the farm. +>> >> > This allows you to delegate the server status validation to a third-party service on the machine and perform arbitrary probes. >> > >> >> **method** >> >> ->> >> > The HTTP method to use if the probe is a “http” probe. ->> >> > Compatible methods are `GET`, `HEAD` and `OPTIONS` (by default). +>> >> > The HTTP method to use if the probe is of type "http". +>> >> > The compatible methods are `GET`, `HEAD` and `OPTIONS` (default). >> > >> >> **url** >> >> ->> >> > The URL to use for tests, if it is a “http” probe type. ->> >> > It should be formulated as follows: `[[https?://]www.example.com]/path/to/check`. ->> >> > If a domain is specified, its request will be sent to HTTP/1.1 rather than HTTP/1.0 by default. +>> >> > The URL to use for the tests, if the probe is of type "http". +>> >> > Its form must be `[[https?://]www.example.com]/path/to/check`. +>> >> > If a domain is specified, the request will be sent in HTTP/1.1 instead of HTTP/1.0 by default. >> > >> >> **match** >> >> ->> >> > The type of comparison to use to check if the server is in good health. ->> >> > The managed comparison types are `default`, `status`, `contains` and `matches`. ->> >> > Comparison types are compatible with both “http” and “tcp” probes. +>> >> > The type of comparator to use to check that the server is healthy. +>> >> > The comparators handled are `default`, `status`, `contains` and `matches`. +>> >> > The comparators are compatible with "http" and "tcp" probes. >> > >> >> **pattern** >> >> ->> >> > The value to use as an argument of the comparison type if it is different from “default”. +>> >> > The value to use as an argument for the comparator if it is different from "default". >> > >> >> **forceSsl** >> >> ->> >> > This defines whether the probe must work in SSL/TLS, even if the farm is configured to connect via standard TCP. ->> >> > This can be useful when, for example, your OVH Load Balancer is configured to monitor HTTPS traffic in TCP without decrypting it. +>> >> > Defines whether the probe should work in SSL/TLS even if the farm is configured to connect in classic TCP. +>> >> > This can be useful, for example, when your OVHcloud Load Balancer is configured to forward HTTPS traffic in TCP without decrypting it. > -Other settings can be edited via this call. Since this guide focuses on probes, they are not documented here. +Other parameters can be edited via this call. As this guide focuses on probes, they are not documented here. -If a port other than the farm’s base port is configured on the probe, the `proxyprotocol` and `ssl` settings are reset. As an example, we will take a configured farm to use `proxyprotocol` on **port 4242**, and an associated probe using **port 8080**. The probe will not send the `proxyprotocol` header when it connects on **port 8080**. The same goes for `ssl`, but it can be forced. +If a port other than the base port of the farm is configured on the probe, the `proxyprotocol` and `ssl` parameters are reset. Take the example of a farm configured to use `proxyprotocol` on port **4242** and a probe associated with port **8080**: the latter will not send the `proxyprotocol` header when connecting to port **8080**. The same applies to `ssl`, which can nevertheless be forced. > [!warning] > -> When a probe is configured on a farm, it must be activated on the servers. +> When a probe is configured on a farm, it must also be enabled on the servers. > -##### Activate probes on a server. -For a probe to be active, it must be configured on the farm and activated on the servers concerned. With this call, you can activate the probe being taken into account: +##### **Enable probes on a server** + +For a probe to be active, it must have been configured on the farm and enabled on the relevant servers. This call allows you to enable the probe : > [!faq] > -> Service: +> Service : > >> > [!api] >> > @@ -229,47 +256,47 @@ For a probe to be active, it must be configured on the farm and activated on the >> > >> > -> Settings: +> Parameters : > >> > **serviceName** >> > ->> >> Your OVH Load Balancer ID. +>> >> The identifier of your OVHcloud Load Balancer. >> > >> > **farmId** >> > ->> >> Your `farm` ID number. +>> >> The numeric identifier of your `farm`. >> > >> > **serverId** >> > ->> >> Your `server’s` ID number. +>> >> The numeric identifier of your `server`. >> > >> > **probe** >> > ->> >> Whether or not the `probes` must be taken into account. +>> >> Indicates whether `probe` should be taken into account or not. > -Other settings can be edited via this call. Since this guide focuses on probes, they are not documented here. +Other parameters can be edited via this call. As this guide focuses on probes, they are not documented here. -#### Available comparison types. +#### Available comparators -Four comparison types are available to confirm a probe’s results: +Four comparators are available to validate the result of a probe : -|Comparison type|Description| +|Comparator|Description| |---|---| -|default|Launches a basic test, without any settings.| -|status|A list of valid HTTP response codes, separated by commas.| -|contains|Checks that the pattern can be found in the response.| -|matches|Checks that the response corresponds to a regular expression pattern.| +|default|Runs a basic test, without parameters.| +|status|Comma-separated list of valid HTTP return codes.| +|contains|Checks that the pattern is in the response.| +|matches|Checks that the response matches the pattern regular expression.| -‘Contains’ and ‘matches’ comparison types find a correspondence in the first 16 KB of the response. If the response is longer than 16 KB, whatever comes afterwards will be ignored during the test. Please note that to optimise your performance, we recommend returning as little information as possible in your probes. +The `contains` and `matches` comparators look for a match in the first 16 KB of the response. If it is longer, the part beyond will be ignored during the search. Note that for better performance, we recommend returning as little information as possible in your probes. -#### Available probes. +#### Available probes -You can get a list of the available probes using the following API call: +The list of available probes can be obtained with the API call : > [!faq] > -> Service: +> Service : > >> > [!api] >> > @@ -277,56 +304,56 @@ You can get a list of the available probes using the following API call: >> > >> > -> Response: +> Response : > >> > **type** >> > ->> >> The type of `probe` to configure in the `probe.type` of `farms`. +>> >> The type of `probe` to configure in the `probe.type` field of the `farms`. >> >> ->> >> The probe types managed are: +>> >> The probe types handled are : >> >> ->> >> `tcp` for a basic TCP connection test. +>> >> `tcp` for a basic TCP connection test ; >> >> ->> >> `http` for a HTTP connection test. You can specify the URL and the method. +>> >> `http` for an HTTP connection test. It is possible to specify the URL and method ; >> >> ->> >> `smtp` for a basic SMTP connection test. +>> >> `smtp` for a basic SMTP connection test ; >> >> ->> >> `mysql` for a basic MySQL connection test. +>> >> `mysql` for a basic MySQL connection test ; >> >> ->> >> `pgsql` for a basic PostgreSQL connection test. +>> >> `pgslq` for a basic PostgreSQL connection test ; >> >> ->> >> `oco` for a confirmation of the general status returned on port 79. +>> >> `oco` for a general status validation returned on port 79. >> > >> > **port** >> > ->> >> This defines whether the port can be configured for this probe. +>> >> Indicates whether the port can be configured for this probe. >> > >> > **method** >> > ->> >> The list of HTTP methods managed, or `null` if none are managed. +>> >> The list of HTTP methods handled or `null` if none exist. >> > >> > **url** >> > ->> >> This defines if the probe’s URL can be configured. +>> >> Indicates whether the probe URL can be configured. >> > >> > **matches** >> > ->> >> The list of comparison types available for this probe. +>> >> The list of available comparators for this probe. >> >> The interpretation of the `probe.pattern` field depends on this field. ->> >> The comparison types potentially managed are: +>> >> The potentially handled comparators are : >> >> ->> >> `default`. The most simple test, without any particular conditions.`probe.pattern` must be empty. +>> >> `default` the simplest test, without specific conditions. `probe.pattern` must be empty ; >> >> ->> >> `status`. Checks if the HTTP status code is in the list separated by commas. +>> >> `status` checks that the HTTP status code is in the comma-separated list ; >> >> ->> >> `contains`. Checks that the server response contains `probe.pattern`. +>> >> `contains` checks that the server response contains `probe.pattern` ; >> >> ->> >> `matches`. Checks that the server response matches `probe.pattern`. +>> >> `matches` checks that the server response matches `probe.pattern`. > -##### TCP +##### **TCP** -This probe attempts to establish a TCP connection to the server. If the server sends a “banner”, you can check if it matches a schema. The default test simply ensures that the connection can be established. +This probe attempts to establish a TCP connection with the server. If the latter sends a "banner", it is possible to check that it matches a pattern. The default test simply ensures that the connection can be established. |Fields|Description| |---|---| @@ -336,29 +363,29 @@ This probe attempts to establish a TCP connection to the server. If the server s |URL|Not supported| |matches|`default`, `contains` or `matches`| -##### HTTP +##### **HTTP** -This probe attempts to establish a HTTP connection to the server. If the server responds, you can check its HTTP status code, and that the response body matches a schema. The default test sends an OPTIONS request to the '/' page in HTTP/1.0, without a Host field. +This probe attempts to establish an HTTP connection with the server. If the latter responds, it is possible to check its HTTP status code or that the response body matches a pattern. The default test sends an OPTIONS request to the '/' page in HTTP/1.0, without the Host field. |Fields|Description| |---|---| |type|`http`| |port|Configurable| |method|`GET`, `HEAD` or `OPTIONS`| -|URL|URL in the form: \[\[https?://]www.example.com]/path/to/check| +|URL|URL of the form [[https?://]www.example.com]/path/to/check| |matches|`default`, `contains` or `matches`| -If the URL is specified, the domain name and protocol are operational. If a domain name is specified, the “Host” field of the request will be filled in, and the request will be sent to HTTP/1.1. If the protocol is specified, it must be consistent with the farm’s SSL configuration. +If a URL is specified, the domain name and protocol are operational. If a domain name is specified, the "Host" field of the request will be filled in and the request will be sent in HTTP/1.1. If the protocol is specified, it must be consistent with the SSL configuration of the farm. > [!primary] > -> We recommend configuring the method, at least, with GET. -> Some servers, including NGINX, do not manage the OPTIONS method without it being configured in advance. +> It is recommended to configure at least the method with GET. +> Indeed, some servers -including Nginx- do not handle the OPTIONS method without prior configuration. > -##### SMTP +##### **SMTP** -This probe attempts to establish an SMTP connection with the server, and sends the command "HELLO localhost". If the server responds, the probe checks that the response code starts with a ‘2’ (success). This probe does not have any specific configuration options. +This probe attempts to establish an SMTP connection with the server and sends the "HELLO localhost" command. If the latter responds, the probe checks that the return code starts with a "2" (success). This probe has no specific configuration options. |Fields|Description| |---|---| @@ -368,9 +395,9 @@ This probe attempts to establish an SMTP connection with the server, and sends t |URL|Not supported| |matches|`default`| -##### MySQL +##### **MySQL** -This probe attempts to establish a MySQL connection with the server, and analyses the server’s response. This probe does not have any specific configuration options. +This probe attempts to establish a MySQL connection with the server and analyses the server's response. This probe has no specific configuration options. |Fields|Description| |---|---| @@ -380,9 +407,9 @@ This probe attempts to establish a MySQL connection with the server, and analyse |URL|Not supported| |matches|`default`| -##### PostgreSQL +##### **PostgreSQL** -This probe attempts to establish a PostgreSQL connection with the server, and analyses the server’s response. This probe does not have any specific configuration options. +This probe attempts to establish a PostgreSQL connection with the server and analyses the server's response. This probe has no specific configuration options. |Fields|Description| |---|---| @@ -392,9 +419,9 @@ This probe attempts to establish a PostgreSQL connection with the server, and an |URL|Not supported| |matches|`default`| -##### oco +##### **oco** -This probe attempts to establish a TCP connection on port 79 of your server, and checks that the response starts with a ‘2’ (success). This probe does not have any specific configuration options. +This probe attempts to establish a TCP connection on port 79 of your server and checks that the response starts with a "2" (success). This probe has no specific configuration options. |Fields|Description| |---|---| @@ -404,20 +431,24 @@ This probe attempts to establish a TCP connection on port 79 of your server, and |URL|Not supported| |matches|`default`| -## Via the OVH Control Panel. +### From the OVHcloud Control Panel -You can configure probes when you add (or modify) a server farm, in advanced settings. +You can configure probes when you add or modify a server farm, in advanced settings. -![Advanced settings for a farm](images/farm_advanced_settings.png){.thumbnail} +![Advanced farm settings](images/farm_advanced_settings.png){.thumbnail} -This is how you access the probe type’s configuration. +You will then have access to the configuration for the probe type. ![Probe settings](images/farm_advanced_settings_unfolded.png){.thumbnail} -If you are able to do so with the probe type you have selected, you can configure specific advanced settings for the probe. +If the probe type you have selected allows it, you can configure advanced settings that are specific to that probe. -![Advanced settings for a probe](images/probe_settings.png){.thumbnail} +![Advanced probe settings](images/probe_settings.png){.thumbnail} A new configuration window will appear, with the probe’s settings. -![Advanced settings for a probe](images/probe_settings_dialog.png){.thumbnail} +![Advanced probe settings](images/probe_settings_dialog.png){.thumbnail} + +## Go further + +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_probes/guide.en-ca.md b/pages/network/load_balancer/create_probes/guide.en-ca.md index 52be1704be5..d774b695308 100644 --- a/pages/network/load_balancer/create_probes/guide.en-ca.md +++ b/pages/network/load_balancer/create_probes/guide.en-ca.md @@ -1,45 +1,69 @@ --- -title: 'Working with probes' -excerpt: 'Find out about the general principles behind probes, and why they are used' -updated: 2019-02-12 +title: "Configuration of probes on an OVHcloud Load Balancer service" +excerpt: "Discover the general principles and use cases for probes" +updated: 2025-11-12 --- -## Objective + -With the OVH Load Balancer, you can distribute a front-end’s incoming traffic across a set of servers in a destination farm. +## Objective -There may be instances where a server in your farm becomes unavailable for a number of reasons, including oversaturation, an incident, or scheduled maintenance. When the OVH Load Balancer detects a connection error, it will try to redirect traffic to another server. The connection will be slower, but it will continue to work. +The OVHcloud Load Balancer allows you to distribute incoming traffic on a frontend to a set of servers in a destination farm. -However, the reasons behind certain types of unavailability can be harder to pinpoint. For example, if a new version of code is being deployed, the application may momentarily experience a glitch, and return a 500 error. In this particular case, a solution would be to mark the servers concerned as unavailable in the API before you begin the maintenance work, apply the configuration and update, then mark the server as available again. This method is not ideal, but it works. For more information on deploying a blue-green architecture with an OVH Load Balancer, please read our guide: . +It may happen that one of the servers in your farm is no longer available for various reasons, such as overload, an incident, or scheduled maintenance. When it encounters a connection error, your OVHcloud Load Balancer attempts to switch traffic to another server. The connection will be slowed down, but it will continue to function. -The purpose of a probe is to test an infrastructure’s health. It periodically examines each of your servers, to ensure that they are working properly. If it detects an error, the server is automatically disabled until the situation is resolved. +However, the causes of some unavailability are more subtle. For example, if a new version of the code is being deployed, the application may temporarily be in a transitional state and return 500 errors. In this specific case, one solution would be to mark the affected servers as unavailable in the API before the start of the maintenance, apply the configuration and update, and then mark the server as available again. This method is not ideal, but it works.
+For more details on deploying a Blue-Green architecture with your OVHcloud Load Balancer, refer to [this guide](/pages/network/load_balancer/case_blue_green). -Since this service is still very new, its basic features are only available in the API. +Probes are health checks. They periodically query each of your servers to ensure they are operational. If an error is detected, the server is automatically disabled until the situation is resolved. -**This guide will explain the general principles behind probes, and provide practical examples of probes being used.** +**This guide will present the general principles, as well as usage scenarios for probes, drawn from real-world use cases.** ## Requirements -- a correctly configured OVH Load Balancer, with farms and servers set +- Have an [OVHcloud Load Balancer](/links/network/load-balancer) offer in your OVHcloud account. The service must be properly configured, with farms and servers set up. +- Be logged in to your [OVHcloud Control Panel](/links/manager). ## Instructions -### An introduction to the API. +**Table of contents** + +- [Probe API overview](#probe-api) +- [Examples](#examples) +- [Reference](#reference) +- [From the OVHcloud Control Panel](#manager) + +### Probe API overview -The API for probes in the OVH Load Balancer is designed to be flexible and scalable. +The probe API of your OVHcloud Load Balancer has been designed to be flexible and scalable. -The probes can be configured directly on the farms. All of the servers from a single farm will have exactly the same probe applied. However, probe activation and deactivation is specific for each server. As a result, it is possible to only monitor certain servers within a single farm. +Probes are configured directly on the farms. All servers in the same farm thus apply exactly the same probe. However, enabling or disabling a probe is specific to each server. It is therefore possible to "monitor" only certain servers in the same farm. -You can view the list of available probes and their settings with the following API call: +The list of available probes and their parameters can be consulted with the API call : > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/availableFarmProbes > -For more information on this call, please read the *Available probes* section at the bottom of this guide. +For more information on this call, we invite you to consult the [Available probes](#available-probes) section at the bottom of this guide. -The probes in this list can be configured on `http` and `tcp` farms via the following calls: +The probes returned by this list can be configured on `http` and `tcp` farms via the following calls : > [!api] > @@ -61,56 +85,58 @@ The probes in this list can be configured on `http` and `tcp` farms via the foll > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/tcp/farm/{farmId} > -For more information on these calls, please read the *Probe configuration* section at the bottom of this guide. +For more information on these calls, you can refer to the [Probe handling](#handling-probes) section of this guide. -### Examples +### Examples -#### Check if the server accepts TCP connections. +#### Check if the server accepts TCP connections -This is the simplest method to set up. It is compatible with `tcp` and `http` farms. If no other probes are configured, you can activate it to start. It works by periodically attempting to establish a connection on each of your servers. If the connection fails twice in a row, the server is put aside until it responds again. +This is the simplest probe to set up. It is compatible with `tcp` and `http` farms. If no other probe is configured, you can activate this one to start. It works by periodically trying to open a connection on each of your servers. If the connection fails twice in a row, the server is put aside until it responds again. -In practice, this gives a probe: +In practice, this gives a probe : |Field|Value and description| |---|---| -|serviceName|Your OVH Load Balancer ID| -|farmId|Your TCP or HTTP farm| +|serviceName|Identifier of your OVHcloud Load Balancer| +|farmId|Identifier of your TCP or HTTP farm| |probe.type|"tcp"| -All other probe fields can keep their default values. Just apply the configuration to the zone concerned, and the probe will begin to work. +All other `probe` fields can remain at their default values. You just need to apply the configuration in the relevant area. -#### Test a specific HTTP page. +#### Test a specific HTTP page -By default, the HTTP `probe` sends an "OPTIONS" request on "/" in HTTP/1.0, without a domain name. In many cases, this is sufficient, but some servers do not manage this method. You can carry out much more powerful tests with the HTTP probe. For example, a good practice when exposing a HTTP service is to add a router dedicated to probes. It is normal to see "/status", "/health", and "/check", which summarise the service’s status. +By default, the HTTP probe sends an `OPTIONS` request on `/` in HTTP/1.0, without a domain name. This is sufficient in many cases, but some servers do not handle this method.
+It is possible to perform much more powerful tests with the HTTP probe. For example, a good practice when exposing an HTTP service is to add a dedicated route for probes. It is common to find `/status`, `/health`, `/check` which return a summary of the service's status. -In practice, if you want to configure the probe to send a "GET" request on [http://api.example.com/status](http://api.example.com/status), it gives: +In practice, if you want to configure the probe to send a `GET` request to [http://api.example.com/status](http://api.example.com/status), this gives : |Field|Value and description| |---|---| -|serviceName|Your OVH Load Balancer ID| -|farmId|Your TCP or HTTP farm| +|serviceName|Identifier of your OVHcloud Load Balancer| +|farmId|Identifier of your TCP or HTTP farm| |probe.type|http| |probe.method|GET| |probe.url|[http://api.example.com/status](http://api.example.com/status)| |probe.match|status| -|probe.pattern|200 (multiple status codes can be added, provided they are separated by commas)| +|probe.pattern|200 (several status codes can be added, separated by commas)| -All other probe fields can keep their default values. Finally, apply the configuration to the zone concerned. +All other `probe` fields can remain at their default values. It is then sufficient to apply the configuration in the relevant area. -#### Use an external HTTP test. +#### Use an external HTTP test -What happens if, for example, your service is an IMAP server that relies on an LDAP server for authentication? The server may accept connections, but experience a temporary connection issue with the LDAP server. If this happens, the customers redirected to this server would be able to connect, but wouldn’t be able to authenticate. As a result, the server would need to be removed from the farm. +What if your service is, for example, an IMAP server that relies on an LDAP server for authentication ?
+It is possible that the server accepts connections, but has a temporary connection issue with the LDAP server. If this happens, clients who are directed to this server could connect but not authenticate. The server should therefore be removed from the farm. -If you are using a `tcp` probe, it will manage to connect. As a result, it will consider the service to be available, even though this is not the case. +If a `tcp` type probe is used, it will be able to connect and consider the service available even though it is not the case. -In this situation, the health test would ideally be able to confirm that the basic service works. You can provide a specific port to use in the tests. This way, you can set up arbitrary tests for a service, and expose them to HTTP on a dedicated port. +In this scenario, the ideal would be for the health check to confirm that the base service is working. It is possible to indicate a specific port to use in the tests. This allows arbitrary tests to be set up for a service and exposed in HTTP, on a dedicated port. -For example, in this situation, you can have a HTTP server on port 8080\. It will test the IMAP server via the URL "/service/imap/status", and will return ‘OK’ when everything is working properly. In practice, this will return: +For example, in this scenario, it would be possible to have an HTTP server on port 8080 that tests the IMAP server via the url `/service/imap/status` and returns *OK* when everything is fine. This would give in practice : |Field|Value and description| |---|---| -|serviceName|Your OVH Load Balancer ID| -|farmId|Your TCP or HTTP farm| +|serviceName|Identifier of your OVHcloud Load Balancer| +|farmId|Identifier of your TCP or HTTP farm| |probe.type|http| |probe.port|8080| |probe.method|GET| @@ -118,24 +144,24 @@ For example, in this situation, you can have a HTTP server on port 8080\. It wil |probe.match|contains| |probe.pattern|OK| -Just apply the configuration to the zone concerned, and the probe will begin to work. +It is then sufficient to apply the configuration in the relevant area. > [!warning] > -> If the HTTP service dedicated to monitoring your IMAP service experiences a fault, the IMAP service will also be considered faulty, even if it is working properly. +> If the HTTP service dedicated to monitoring your IMAP service itself fails, the IMAP service will also be considered as failed, even if it is in perfect working condition. > -### Reference +### Reference -#### Probe configuration. +#### Probe handling -##### Configure a probe. +##### **Configure a probe** -Probes can be configured on a new farm (`POST`) or an existing one (`PUT`). Since the two methods are equivalent, only the second (`PUT`) method is presented here. +Probes can be configured on a new farm (`POST`) or an existing farm (`PUT`). The two methods being equivalent, only the second one (`PUT`) will be presented here. > [!faq] > -> Service: +> Service : > >> > [!api] >> > @@ -143,85 +169,86 @@ Probes can be configured on a new farm (`POST`) or an existing one (`PUT`). Sinc >> > >> > -> Settings: +> Parameters : > >> > **serviceName** >> > ->> >> Your OVH Load Balancer ID. +>> >> The identifier of your OVHcloud Load Balancer. >> > >> > **farmId** >> > ->> >> Your `farm` ID number. +>> >> The numeric identifier of your `farm`. >> > >> > **probe** >> > >> >> **type** >> >> ->> >> > The type of `probe` to activate. The probe types managed are: +>> >> > The type of `probe` to enable. The probe types handled are : >> >> > ->> >> > `tcp` for a basic TCP connection test. +>> >> > `tcp` for a basic TCP connection test ; >> >> > ->> >> > `http` for a HTTP connection test. You can specify the URL and the method. +>> >> > `http` for an HTTP connection test. It is possible to specify the URL and method ; >> >> > ->> >> > `smtp` for a basic SMTP connection test. +>> >> > `smtp` for a basic SMTP connection test ; >> >> > ->> >> > `mysql` for a basic MySQL connection test. +>> >> > `mysql` for a basic MySQL connection test ; >> >> > ->> >> > `pgsql` for a basic PostgreSQL connection test. +>> >> > `pgslq` for a basic PostgreSQL connection test ; >> >> > ->> >> > `oco` for a confirmation of the general status returned on port 79. +>> >> > `oco` for a general status validation returned on port 79. >> > >> >> **interval** >> >> ->> >> > The interval (in seconds) between a probe’s two connection attempts. It must be at least 30 seconds. +>> >> > The interval in seconds between two probe attempts. It must be at least 30 seconds. >> > >> >> **port** >> >> ->> >> > The port that the probe must use, if it is different to the port configured on the farm. ->> >> > This enables you to delegate a server’s status validation to a separate service on the machine, and carry out arbitrary probes. +>> >> > The port that the probe should use, if it is different from the one configured on the farm. +>> >> > This allows you to delegate the server status validation to a third-party service on the machine and perform arbitrary probes. >> > >> >> **method** >> >> ->> >> > The HTTP method to use if the probe is a “http” probe. ->> >> > Compatible methods are `GET`, `HEAD` and `OPTIONS` (by default). +>> >> > The HTTP method to use if the probe is of type "http". +>> >> > The compatible methods are `GET`, `HEAD` and `OPTIONS` (default). >> > >> >> **url** >> >> ->> >> > The URL to use for tests, if it is a “http” probe type. ->> >> > It should be formulated as follows: `[[https?://]www.example.com]/path/to/check`. ->> >> > If a domain is specified, its request will be sent to HTTP/1.1 rather than HTTP/1.0 by default. +>> >> > The URL to use for the tests, if the probe is of type "http". +>> >> > Its form must be `[[https?://]www.example.com]/path/to/check`. +>> >> > If a domain is specified, the request will be sent in HTTP/1.1 instead of HTTP/1.0 by default. >> > >> >> **match** >> >> ->> >> > The type of comparison to use to check if the server is in good health. ->> >> > The managed comparison types are `default`, `status`, `contains` and `matches`. ->> >> > Comparison types are compatible with both “http” and “tcp” probes. +>> >> > The type of comparator to use to check that the server is healthy. +>> >> > The comparators handled are `default`, `status`, `contains` and `matches`. +>> >> > The comparators are compatible with "http" and "tcp" probes. >> > >> >> **pattern** >> >> ->> >> > The value to use as an argument of the comparison type if it is different from “default”. +>> >> > The value to use as an argument for the comparator if it is different from "default". >> > >> >> **forceSsl** >> >> ->> >> > This defines whether the probe must work in SSL/TLS, even if the farm is configured to connect via standard TCP. ->> >> > This can be useful when, for example, your OVH Load Balancer is configured to monitor HTTPS traffic in TCP without decrypting it. +>> >> > Defines whether the probe should work in SSL/TLS even if the farm is configured to connect in classic TCP. +>> >> > This can be useful, for example, when your OVHcloud Load Balancer is configured to forward HTTPS traffic in TCP without decrypting it. > -Other settings can be edited via this call. Since this guide focuses on probes, they are not documented here. +Other parameters can be edited via this call. As this guide focuses on probes, they are not documented here. -If a port other than the farm’s base port is configured on the probe, the `proxyprotocol` and `ssl` settings are reset. As an example, we will take a configured farm to use `proxyprotocol` on **port 4242**, and an associated probe using **port 8080**. The probe will not send the `proxyprotocol` header when it connects on **port 8080**. The same goes for `ssl`, but it can be forced. +If a port other than the base port of the farm is configured on the probe, the `proxyprotocol` and `ssl` parameters are reset. Take the example of a farm configured to use `proxyprotocol` on port **4242** and a probe associated with port **8080**: the latter will not send the `proxyprotocol` header when connecting to port **8080**. The same applies to `ssl`, which can nevertheless be forced. > [!warning] > -> When a probe is configured on a farm, it must be activated on the servers. +> When a probe is configured on a farm, it must also be enabled on the servers. > -##### Activate probes on a server. -For a probe to be active, it must be configured on the farm and activated on the servers concerned. With this call, you can activate the probe being taken into account: +##### **Enable probes on a server** + +For a probe to be active, it must have been configured on the farm and enabled on the relevant servers. This call allows you to enable the probe : > [!faq] > -> Service: +> Service : > >> > [!api] >> > @@ -229,47 +256,47 @@ For a probe to be active, it must be configured on the farm and activated on the >> > >> > -> Settings: +> Parameters : > >> > **serviceName** >> > ->> >> Your OVH Load Balancer ID. +>> >> The identifier of your OVHcloud Load Balancer. >> > >> > **farmId** >> > ->> >> Your `farm` ID number. +>> >> The numeric identifier of your `farm`. >> > >> > **serverId** >> > ->> >> Your `server’s` ID number. +>> >> The numeric identifier of your `server`. >> > >> > **probe** >> > ->> >> Whether or not the `probes` must be taken into account. +>> >> Indicates whether `probe` should be taken into account or not. > -Other settings can be edited via this call. Since this guide focuses on probes, they are not documented here. +Other parameters can be edited via this call. As this guide focuses on probes, they are not documented here. -#### Available comparison types. +#### Available comparators -Four comparison types are available to confirm a probe’s results: +Four comparators are available to validate the result of a probe : -|Comparison type|Description| +|Comparator|Description| |---|---| -|default|Launches a basic test, without any settings.| -|status|A list of valid HTTP response codes, separated by commas.| -|contains|Checks that the pattern can be found in the response.| -|matches|Checks that the response corresponds to a regular expression pattern.| +|default|Runs a basic test, without parameters.| +|status|Comma-separated list of valid HTTP return codes.| +|contains|Checks that the pattern is in the response.| +|matches|Checks that the response matches the pattern regular expression.| -‘Contains’ and ‘matches’ comparison types find a correspondence in the first 16 KB of the response. If the response is longer than 16 KB, whatever comes afterwards will be ignored during the test. Please note that to optimise your performance, we recommend returning as little information as possible in your probes. +The `contains` and `matches` comparators look for a match in the first 16 KB of the response. If it is longer, the part beyond will be ignored during the search. Note that for better performance, we recommend returning as little information as possible in your probes. -#### Available probes. +#### Available probes -You can get a list of the available probes using the following API call: +The list of available probes can be obtained with the API call : > [!faq] > -> Service: +> Service : > >> > [!api] >> > @@ -277,56 +304,56 @@ You can get a list of the available probes using the following API call: >> > >> > -> Response: +> Response : > >> > **type** >> > ->> >> The type of `probe` to configure in the `probe.type` of `farms`. +>> >> The type of `probe` to configure in the `probe.type` field of the `farms`. >> >> ->> >> The probe types managed are: +>> >> The probe types handled are : >> >> ->> >> `tcp` for a basic TCP connection test. +>> >> `tcp` for a basic TCP connection test ; >> >> ->> >> `http` for a HTTP connection test. You can specify the URL and the method. +>> >> `http` for an HTTP connection test. It is possible to specify the URL and method ; >> >> ->> >> `smtp` for a basic SMTP connection test. +>> >> `smtp` for a basic SMTP connection test ; >> >> ->> >> `mysql` for a basic MySQL connection test. +>> >> `mysql` for a basic MySQL connection test ; >> >> ->> >> `pgsql` for a basic PostgreSQL connection test. +>> >> `pgslq` for a basic PostgreSQL connection test ; >> >> ->> >> `oco` for a confirmation of the general status returned on port 79. +>> >> `oco` for a general status validation returned on port 79. >> > >> > **port** >> > ->> >> This defines whether the port can be configured for this probe. +>> >> Indicates whether the port can be configured for this probe. >> > >> > **method** >> > ->> >> The list of HTTP methods managed, or `null` if none are managed. +>> >> The list of HTTP methods handled or `null` if none exist. >> > >> > **url** >> > ->> >> This defines if the probe’s URL can be configured. +>> >> Indicates whether the probe URL can be configured. >> > >> > **matches** >> > ->> >> The list of comparison types available for this probe. +>> >> The list of available comparators for this probe. >> >> The interpretation of the `probe.pattern` field depends on this field. ->> >> The comparison types potentially managed are: +>> >> The potentially handled comparators are : >> >> ->> >> `default`. The most simple test, without any particular conditions.`probe.pattern` must be empty. +>> >> `default` the simplest test, without specific conditions. `probe.pattern` must be empty ; >> >> ->> >> `status`. Checks if the HTTP status code is in the list separated by commas. +>> >> `status` checks that the HTTP status code is in the comma-separated list ; >> >> ->> >> `contains`. Checks that the server response contains `probe.pattern`. +>> >> `contains` checks that the server response contains `probe.pattern` ; >> >> ->> >> `matches`. Checks that the server response matches `probe.pattern`. +>> >> `matches` checks that the server response matches `probe.pattern`. > -##### TCP +##### **TCP** -This probe attempts to establish a TCP connection to the server. If the server sends a “banner”, you can check if it matches a schema. The default test simply ensures that the connection can be established. +This probe attempts to establish a TCP connection with the server. If the latter sends a "banner", it is possible to check that it matches a pattern. The default test simply ensures that the connection can be established. |Fields|Description| |---|---| @@ -336,29 +363,29 @@ This probe attempts to establish a TCP connection to the server. If the server s |URL|Not supported| |matches|`default`, `contains` or `matches`| -##### HTTP +##### **HTTP** -This probe attempts to establish a HTTP connection to the server. If the server responds, you can check its HTTP status code, and that the response body matches a schema. The default test sends an OPTIONS request to the '/' page in HTTP/1.0, without a Host field. +This probe attempts to establish an HTTP connection with the server. If the latter responds, it is possible to check its HTTP status code or that the response body matches a pattern. The default test sends an OPTIONS request to the '/' page in HTTP/1.0, without the Host field. |Fields|Description| |---|---| |type|`http`| |port|Configurable| |method|`GET`, `HEAD` or `OPTIONS`| -|URL|URL in the form: \[\[https?://]www.example.com]/path/to/check| +|URL|URL of the form [[https?://]www.example.com]/path/to/check| |matches|`default`, `contains` or `matches`| -If the URL is specified, the domain name and protocol are operational. If a domain name is specified, the “Host” field of the request will be filled in, and the request will be sent to HTTP/1.1. If the protocol is specified, it must be consistent with the farm’s SSL configuration. +If a URL is specified, the domain name and protocol are operational. If a domain name is specified, the "Host" field of the request will be filled in and the request will be sent in HTTP/1.1. If the protocol is specified, it must be consistent with the SSL configuration of the farm. > [!primary] > -> We recommend configuring the method, at least, with GET. -> Some servers, including NGINX, do not manage the OPTIONS method without it being configured in advance. +> It is recommended to configure at least the method with GET. +> Indeed, some servers -including Nginx- do not handle the OPTIONS method without prior configuration. > -##### SMTP +##### **SMTP** -This probe attempts to establish an SMTP connection with the server, and sends the command "HELLO localhost". If the server responds, the probe checks that the response code starts with a ‘2’ (success). This probe does not have any specific configuration options. +This probe attempts to establish an SMTP connection with the server and sends the "HELLO localhost" command. If the latter responds, the probe checks that the return code starts with a "2" (success). This probe has no specific configuration options. |Fields|Description| |---|---| @@ -368,9 +395,9 @@ This probe attempts to establish an SMTP connection with the server, and sends t |URL|Not supported| |matches|`default`| -##### MySQL +##### **MySQL** -This probe attempts to establish a MySQL connection with the server, and analyses the server’s response. This probe does not have any specific configuration options. +This probe attempts to establish a MySQL connection with the server and analyses the server's response. This probe has no specific configuration options. |Fields|Description| |---|---| @@ -380,9 +407,9 @@ This probe attempts to establish a MySQL connection with the server, and analyse |URL|Not supported| |matches|`default`| -##### PostgreSQL +##### **PostgreSQL** -This probe attempts to establish a PostgreSQL connection with the server, and analyses the server’s response. This probe does not have any specific configuration options. +This probe attempts to establish a PostgreSQL connection with the server and analyses the server's response. This probe has no specific configuration options. |Fields|Description| |---|---| @@ -392,9 +419,9 @@ This probe attempts to establish a PostgreSQL connection with the server, and an |URL|Not supported| |matches|`default`| -##### oco +##### **oco** -This probe attempts to establish a TCP connection on port 79 of your server, and checks that the response starts with a ‘2’ (success). This probe does not have any specific configuration options. +This probe attempts to establish a TCP connection on port 79 of your server and checks that the response starts with a "2" (success). This probe has no specific configuration options. |Fields|Description| |---|---| @@ -404,20 +431,24 @@ This probe attempts to establish a TCP connection on port 79 of your server, and |URL|Not supported| |matches|`default`| -## Via the OVH Control Panel. +### From the OVHcloud Control Panel -You can configure probes when you add (or modify) a server farm, in advanced settings. +You can configure probes when you add or modify a server farm, in advanced settings. -![Advanced settings for a farm](images/farm_advanced_settings.png){.thumbnail} +![Advanced farm settings](images/farm_advanced_settings.png){.thumbnail} -This is how you access the probe type’s configuration. +You will then have access to the configuration for the probe type. ![Probe settings](images/farm_advanced_settings_unfolded.png){.thumbnail} -If you are able to do so with the probe type you have selected, you can configure specific advanced settings for the probe. +If the probe type you have selected allows it, you can configure advanced settings that are specific to that probe. -![Advanced settings for a probe](images/probe_settings.png){.thumbnail} +![Advanced probe settings](images/probe_settings.png){.thumbnail} A new configuration window will appear, with the probe’s settings. -![Advanced settings for a probe](images/probe_settings_dialog.png){.thumbnail} +![Advanced probe settings](images/probe_settings_dialog.png){.thumbnail} + +## Go further + +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_probes/guide.en-gb.md b/pages/network/load_balancer/create_probes/guide.en-gb.md index 52be1704be5..d774b695308 100644 --- a/pages/network/load_balancer/create_probes/guide.en-gb.md +++ b/pages/network/load_balancer/create_probes/guide.en-gb.md @@ -1,45 +1,69 @@ --- -title: 'Working with probes' -excerpt: 'Find out about the general principles behind probes, and why they are used' -updated: 2019-02-12 +title: "Configuration of probes on an OVHcloud Load Balancer service" +excerpt: "Discover the general principles and use cases for probes" +updated: 2025-11-12 --- -## Objective + -With the OVH Load Balancer, you can distribute a front-end’s incoming traffic across a set of servers in a destination farm. +## Objective -There may be instances where a server in your farm becomes unavailable for a number of reasons, including oversaturation, an incident, or scheduled maintenance. When the OVH Load Balancer detects a connection error, it will try to redirect traffic to another server. The connection will be slower, but it will continue to work. +The OVHcloud Load Balancer allows you to distribute incoming traffic on a frontend to a set of servers in a destination farm. -However, the reasons behind certain types of unavailability can be harder to pinpoint. For example, if a new version of code is being deployed, the application may momentarily experience a glitch, and return a 500 error. In this particular case, a solution would be to mark the servers concerned as unavailable in the API before you begin the maintenance work, apply the configuration and update, then mark the server as available again. This method is not ideal, but it works. For more information on deploying a blue-green architecture with an OVH Load Balancer, please read our guide: . +It may happen that one of the servers in your farm is no longer available for various reasons, such as overload, an incident, or scheduled maintenance. When it encounters a connection error, your OVHcloud Load Balancer attempts to switch traffic to another server. The connection will be slowed down, but it will continue to function. -The purpose of a probe is to test an infrastructure’s health. It periodically examines each of your servers, to ensure that they are working properly. If it detects an error, the server is automatically disabled until the situation is resolved. +However, the causes of some unavailability are more subtle. For example, if a new version of the code is being deployed, the application may temporarily be in a transitional state and return 500 errors. In this specific case, one solution would be to mark the affected servers as unavailable in the API before the start of the maintenance, apply the configuration and update, and then mark the server as available again. This method is not ideal, but it works.
+For more details on deploying a Blue-Green architecture with your OVHcloud Load Balancer, refer to [this guide](/pages/network/load_balancer/case_blue_green). -Since this service is still very new, its basic features are only available in the API. +Probes are health checks. They periodically query each of your servers to ensure they are operational. If an error is detected, the server is automatically disabled until the situation is resolved. -**This guide will explain the general principles behind probes, and provide practical examples of probes being used.** +**This guide will present the general principles, as well as usage scenarios for probes, drawn from real-world use cases.** ## Requirements -- a correctly configured OVH Load Balancer, with farms and servers set +- Have an [OVHcloud Load Balancer](/links/network/load-balancer) offer in your OVHcloud account. The service must be properly configured, with farms and servers set up. +- Be logged in to your [OVHcloud Control Panel](/links/manager). ## Instructions -### An introduction to the API. +**Table of contents** + +- [Probe API overview](#probe-api) +- [Examples](#examples) +- [Reference](#reference) +- [From the OVHcloud Control Panel](#manager) + +### Probe API overview -The API for probes in the OVH Load Balancer is designed to be flexible and scalable. +The probe API of your OVHcloud Load Balancer has been designed to be flexible and scalable. -The probes can be configured directly on the farms. All of the servers from a single farm will have exactly the same probe applied. However, probe activation and deactivation is specific for each server. As a result, it is possible to only monitor certain servers within a single farm. +Probes are configured directly on the farms. All servers in the same farm thus apply exactly the same probe. However, enabling or disabling a probe is specific to each server. It is therefore possible to "monitor" only certain servers in the same farm. -You can view the list of available probes and their settings with the following API call: +The list of available probes and their parameters can be consulted with the API call : > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/availableFarmProbes > -For more information on this call, please read the *Available probes* section at the bottom of this guide. +For more information on this call, we invite you to consult the [Available probes](#available-probes) section at the bottom of this guide. -The probes in this list can be configured on `http` and `tcp` farms via the following calls: +The probes returned by this list can be configured on `http` and `tcp` farms via the following calls : > [!api] > @@ -61,56 +85,58 @@ The probes in this list can be configured on `http` and `tcp` farms via the foll > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/tcp/farm/{farmId} > -For more information on these calls, please read the *Probe configuration* section at the bottom of this guide. +For more information on these calls, you can refer to the [Probe handling](#handling-probes) section of this guide. -### Examples +### Examples -#### Check if the server accepts TCP connections. +#### Check if the server accepts TCP connections -This is the simplest method to set up. It is compatible with `tcp` and `http` farms. If no other probes are configured, you can activate it to start. It works by periodically attempting to establish a connection on each of your servers. If the connection fails twice in a row, the server is put aside until it responds again. +This is the simplest probe to set up. It is compatible with `tcp` and `http` farms. If no other probe is configured, you can activate this one to start. It works by periodically trying to open a connection on each of your servers. If the connection fails twice in a row, the server is put aside until it responds again. -In practice, this gives a probe: +In practice, this gives a probe : |Field|Value and description| |---|---| -|serviceName|Your OVH Load Balancer ID| -|farmId|Your TCP or HTTP farm| +|serviceName|Identifier of your OVHcloud Load Balancer| +|farmId|Identifier of your TCP or HTTP farm| |probe.type|"tcp"| -All other probe fields can keep their default values. Just apply the configuration to the zone concerned, and the probe will begin to work. +All other `probe` fields can remain at their default values. You just need to apply the configuration in the relevant area. -#### Test a specific HTTP page. +#### Test a specific HTTP page -By default, the HTTP `probe` sends an "OPTIONS" request on "/" in HTTP/1.0, without a domain name. In many cases, this is sufficient, but some servers do not manage this method. You can carry out much more powerful tests with the HTTP probe. For example, a good practice when exposing a HTTP service is to add a router dedicated to probes. It is normal to see "/status", "/health", and "/check", which summarise the service’s status. +By default, the HTTP probe sends an `OPTIONS` request on `/` in HTTP/1.0, without a domain name. This is sufficient in many cases, but some servers do not handle this method.
+It is possible to perform much more powerful tests with the HTTP probe. For example, a good practice when exposing an HTTP service is to add a dedicated route for probes. It is common to find `/status`, `/health`, `/check` which return a summary of the service's status. -In practice, if you want to configure the probe to send a "GET" request on [http://api.example.com/status](http://api.example.com/status), it gives: +In practice, if you want to configure the probe to send a `GET` request to [http://api.example.com/status](http://api.example.com/status), this gives : |Field|Value and description| |---|---| -|serviceName|Your OVH Load Balancer ID| -|farmId|Your TCP or HTTP farm| +|serviceName|Identifier of your OVHcloud Load Balancer| +|farmId|Identifier of your TCP or HTTP farm| |probe.type|http| |probe.method|GET| |probe.url|[http://api.example.com/status](http://api.example.com/status)| |probe.match|status| -|probe.pattern|200 (multiple status codes can be added, provided they are separated by commas)| +|probe.pattern|200 (several status codes can be added, separated by commas)| -All other probe fields can keep their default values. Finally, apply the configuration to the zone concerned. +All other `probe` fields can remain at their default values. It is then sufficient to apply the configuration in the relevant area. -#### Use an external HTTP test. +#### Use an external HTTP test -What happens if, for example, your service is an IMAP server that relies on an LDAP server for authentication? The server may accept connections, but experience a temporary connection issue with the LDAP server. If this happens, the customers redirected to this server would be able to connect, but wouldn’t be able to authenticate. As a result, the server would need to be removed from the farm. +What if your service is, for example, an IMAP server that relies on an LDAP server for authentication ?
+It is possible that the server accepts connections, but has a temporary connection issue with the LDAP server. If this happens, clients who are directed to this server could connect but not authenticate. The server should therefore be removed from the farm. -If you are using a `tcp` probe, it will manage to connect. As a result, it will consider the service to be available, even though this is not the case. +If a `tcp` type probe is used, it will be able to connect and consider the service available even though it is not the case. -In this situation, the health test would ideally be able to confirm that the basic service works. You can provide a specific port to use in the tests. This way, you can set up arbitrary tests for a service, and expose them to HTTP on a dedicated port. +In this scenario, the ideal would be for the health check to confirm that the base service is working. It is possible to indicate a specific port to use in the tests. This allows arbitrary tests to be set up for a service and exposed in HTTP, on a dedicated port. -For example, in this situation, you can have a HTTP server on port 8080\. It will test the IMAP server via the URL "/service/imap/status", and will return ‘OK’ when everything is working properly. In practice, this will return: +For example, in this scenario, it would be possible to have an HTTP server on port 8080 that tests the IMAP server via the url `/service/imap/status` and returns *OK* when everything is fine. This would give in practice : |Field|Value and description| |---|---| -|serviceName|Your OVH Load Balancer ID| -|farmId|Your TCP or HTTP farm| +|serviceName|Identifier of your OVHcloud Load Balancer| +|farmId|Identifier of your TCP or HTTP farm| |probe.type|http| |probe.port|8080| |probe.method|GET| @@ -118,24 +144,24 @@ For example, in this situation, you can have a HTTP server on port 8080\. It wil |probe.match|contains| |probe.pattern|OK| -Just apply the configuration to the zone concerned, and the probe will begin to work. +It is then sufficient to apply the configuration in the relevant area. > [!warning] > -> If the HTTP service dedicated to monitoring your IMAP service experiences a fault, the IMAP service will also be considered faulty, even if it is working properly. +> If the HTTP service dedicated to monitoring your IMAP service itself fails, the IMAP service will also be considered as failed, even if it is in perfect working condition. > -### Reference +### Reference -#### Probe configuration. +#### Probe handling -##### Configure a probe. +##### **Configure a probe** -Probes can be configured on a new farm (`POST`) or an existing one (`PUT`). Since the two methods are equivalent, only the second (`PUT`) method is presented here. +Probes can be configured on a new farm (`POST`) or an existing farm (`PUT`). The two methods being equivalent, only the second one (`PUT`) will be presented here. > [!faq] > -> Service: +> Service : > >> > [!api] >> > @@ -143,85 +169,86 @@ Probes can be configured on a new farm (`POST`) or an existing one (`PUT`). Sinc >> > >> > -> Settings: +> Parameters : > >> > **serviceName** >> > ->> >> Your OVH Load Balancer ID. +>> >> The identifier of your OVHcloud Load Balancer. >> > >> > **farmId** >> > ->> >> Your `farm` ID number. +>> >> The numeric identifier of your `farm`. >> > >> > **probe** >> > >> >> **type** >> >> ->> >> > The type of `probe` to activate. The probe types managed are: +>> >> > The type of `probe` to enable. The probe types handled are : >> >> > ->> >> > `tcp` for a basic TCP connection test. +>> >> > `tcp` for a basic TCP connection test ; >> >> > ->> >> > `http` for a HTTP connection test. You can specify the URL and the method. +>> >> > `http` for an HTTP connection test. It is possible to specify the URL and method ; >> >> > ->> >> > `smtp` for a basic SMTP connection test. +>> >> > `smtp` for a basic SMTP connection test ; >> >> > ->> >> > `mysql` for a basic MySQL connection test. +>> >> > `mysql` for a basic MySQL connection test ; >> >> > ->> >> > `pgsql` for a basic PostgreSQL connection test. +>> >> > `pgslq` for a basic PostgreSQL connection test ; >> >> > ->> >> > `oco` for a confirmation of the general status returned on port 79. +>> >> > `oco` for a general status validation returned on port 79. >> > >> >> **interval** >> >> ->> >> > The interval (in seconds) between a probe’s two connection attempts. It must be at least 30 seconds. +>> >> > The interval in seconds between two probe attempts. It must be at least 30 seconds. >> > >> >> **port** >> >> ->> >> > The port that the probe must use, if it is different to the port configured on the farm. ->> >> > This enables you to delegate a server’s status validation to a separate service on the machine, and carry out arbitrary probes. +>> >> > The port that the probe should use, if it is different from the one configured on the farm. +>> >> > This allows you to delegate the server status validation to a third-party service on the machine and perform arbitrary probes. >> > >> >> **method** >> >> ->> >> > The HTTP method to use if the probe is a “http” probe. ->> >> > Compatible methods are `GET`, `HEAD` and `OPTIONS` (by default). +>> >> > The HTTP method to use if the probe is of type "http". +>> >> > The compatible methods are `GET`, `HEAD` and `OPTIONS` (default). >> > >> >> **url** >> >> ->> >> > The URL to use for tests, if it is a “http” probe type. ->> >> > It should be formulated as follows: `[[https?://]www.example.com]/path/to/check`. ->> >> > If a domain is specified, its request will be sent to HTTP/1.1 rather than HTTP/1.0 by default. +>> >> > The URL to use for the tests, if the probe is of type "http". +>> >> > Its form must be `[[https?://]www.example.com]/path/to/check`. +>> >> > If a domain is specified, the request will be sent in HTTP/1.1 instead of HTTP/1.0 by default. >> > >> >> **match** >> >> ->> >> > The type of comparison to use to check if the server is in good health. ->> >> > The managed comparison types are `default`, `status`, `contains` and `matches`. ->> >> > Comparison types are compatible with both “http” and “tcp” probes. +>> >> > The type of comparator to use to check that the server is healthy. +>> >> > The comparators handled are `default`, `status`, `contains` and `matches`. +>> >> > The comparators are compatible with "http" and "tcp" probes. >> > >> >> **pattern** >> >> ->> >> > The value to use as an argument of the comparison type if it is different from “default”. +>> >> > The value to use as an argument for the comparator if it is different from "default". >> > >> >> **forceSsl** >> >> ->> >> > This defines whether the probe must work in SSL/TLS, even if the farm is configured to connect via standard TCP. ->> >> > This can be useful when, for example, your OVH Load Balancer is configured to monitor HTTPS traffic in TCP without decrypting it. +>> >> > Defines whether the probe should work in SSL/TLS even if the farm is configured to connect in classic TCP. +>> >> > This can be useful, for example, when your OVHcloud Load Balancer is configured to forward HTTPS traffic in TCP without decrypting it. > -Other settings can be edited via this call. Since this guide focuses on probes, they are not documented here. +Other parameters can be edited via this call. As this guide focuses on probes, they are not documented here. -If a port other than the farm’s base port is configured on the probe, the `proxyprotocol` and `ssl` settings are reset. As an example, we will take a configured farm to use `proxyprotocol` on **port 4242**, and an associated probe using **port 8080**. The probe will not send the `proxyprotocol` header when it connects on **port 8080**. The same goes for `ssl`, but it can be forced. +If a port other than the base port of the farm is configured on the probe, the `proxyprotocol` and `ssl` parameters are reset. Take the example of a farm configured to use `proxyprotocol` on port **4242** and a probe associated with port **8080**: the latter will not send the `proxyprotocol` header when connecting to port **8080**. The same applies to `ssl`, which can nevertheless be forced. > [!warning] > -> When a probe is configured on a farm, it must be activated on the servers. +> When a probe is configured on a farm, it must also be enabled on the servers. > -##### Activate probes on a server. -For a probe to be active, it must be configured on the farm and activated on the servers concerned. With this call, you can activate the probe being taken into account: +##### **Enable probes on a server** + +For a probe to be active, it must have been configured on the farm and enabled on the relevant servers. This call allows you to enable the probe : > [!faq] > -> Service: +> Service : > >> > [!api] >> > @@ -229,47 +256,47 @@ For a probe to be active, it must be configured on the farm and activated on the >> > >> > -> Settings: +> Parameters : > >> > **serviceName** >> > ->> >> Your OVH Load Balancer ID. +>> >> The identifier of your OVHcloud Load Balancer. >> > >> > **farmId** >> > ->> >> Your `farm` ID number. +>> >> The numeric identifier of your `farm`. >> > >> > **serverId** >> > ->> >> Your `server’s` ID number. +>> >> The numeric identifier of your `server`. >> > >> > **probe** >> > ->> >> Whether or not the `probes` must be taken into account. +>> >> Indicates whether `probe` should be taken into account or not. > -Other settings can be edited via this call. Since this guide focuses on probes, they are not documented here. +Other parameters can be edited via this call. As this guide focuses on probes, they are not documented here. -#### Available comparison types. +#### Available comparators -Four comparison types are available to confirm a probe’s results: +Four comparators are available to validate the result of a probe : -|Comparison type|Description| +|Comparator|Description| |---|---| -|default|Launches a basic test, without any settings.| -|status|A list of valid HTTP response codes, separated by commas.| -|contains|Checks that the pattern can be found in the response.| -|matches|Checks that the response corresponds to a regular expression pattern.| +|default|Runs a basic test, without parameters.| +|status|Comma-separated list of valid HTTP return codes.| +|contains|Checks that the pattern is in the response.| +|matches|Checks that the response matches the pattern regular expression.| -‘Contains’ and ‘matches’ comparison types find a correspondence in the first 16 KB of the response. If the response is longer than 16 KB, whatever comes afterwards will be ignored during the test. Please note that to optimise your performance, we recommend returning as little information as possible in your probes. +The `contains` and `matches` comparators look for a match in the first 16 KB of the response. If it is longer, the part beyond will be ignored during the search. Note that for better performance, we recommend returning as little information as possible in your probes. -#### Available probes. +#### Available probes -You can get a list of the available probes using the following API call: +The list of available probes can be obtained with the API call : > [!faq] > -> Service: +> Service : > >> > [!api] >> > @@ -277,56 +304,56 @@ You can get a list of the available probes using the following API call: >> > >> > -> Response: +> Response : > >> > **type** >> > ->> >> The type of `probe` to configure in the `probe.type` of `farms`. +>> >> The type of `probe` to configure in the `probe.type` field of the `farms`. >> >> ->> >> The probe types managed are: +>> >> The probe types handled are : >> >> ->> >> `tcp` for a basic TCP connection test. +>> >> `tcp` for a basic TCP connection test ; >> >> ->> >> `http` for a HTTP connection test. You can specify the URL and the method. +>> >> `http` for an HTTP connection test. It is possible to specify the URL and method ; >> >> ->> >> `smtp` for a basic SMTP connection test. +>> >> `smtp` for a basic SMTP connection test ; >> >> ->> >> `mysql` for a basic MySQL connection test. +>> >> `mysql` for a basic MySQL connection test ; >> >> ->> >> `pgsql` for a basic PostgreSQL connection test. +>> >> `pgslq` for a basic PostgreSQL connection test ; >> >> ->> >> `oco` for a confirmation of the general status returned on port 79. +>> >> `oco` for a general status validation returned on port 79. >> > >> > **port** >> > ->> >> This defines whether the port can be configured for this probe. +>> >> Indicates whether the port can be configured for this probe. >> > >> > **method** >> > ->> >> The list of HTTP methods managed, or `null` if none are managed. +>> >> The list of HTTP methods handled or `null` if none exist. >> > >> > **url** >> > ->> >> This defines if the probe’s URL can be configured. +>> >> Indicates whether the probe URL can be configured. >> > >> > **matches** >> > ->> >> The list of comparison types available for this probe. +>> >> The list of available comparators for this probe. >> >> The interpretation of the `probe.pattern` field depends on this field. ->> >> The comparison types potentially managed are: +>> >> The potentially handled comparators are : >> >> ->> >> `default`. The most simple test, without any particular conditions.`probe.pattern` must be empty. +>> >> `default` the simplest test, without specific conditions. `probe.pattern` must be empty ; >> >> ->> >> `status`. Checks if the HTTP status code is in the list separated by commas. +>> >> `status` checks that the HTTP status code is in the comma-separated list ; >> >> ->> >> `contains`. Checks that the server response contains `probe.pattern`. +>> >> `contains` checks that the server response contains `probe.pattern` ; >> >> ->> >> `matches`. Checks that the server response matches `probe.pattern`. +>> >> `matches` checks that the server response matches `probe.pattern`. > -##### TCP +##### **TCP** -This probe attempts to establish a TCP connection to the server. If the server sends a “banner”, you can check if it matches a schema. The default test simply ensures that the connection can be established. +This probe attempts to establish a TCP connection with the server. If the latter sends a "banner", it is possible to check that it matches a pattern. The default test simply ensures that the connection can be established. |Fields|Description| |---|---| @@ -336,29 +363,29 @@ This probe attempts to establish a TCP connection to the server. If the server s |URL|Not supported| |matches|`default`, `contains` or `matches`| -##### HTTP +##### **HTTP** -This probe attempts to establish a HTTP connection to the server. If the server responds, you can check its HTTP status code, and that the response body matches a schema. The default test sends an OPTIONS request to the '/' page in HTTP/1.0, without a Host field. +This probe attempts to establish an HTTP connection with the server. If the latter responds, it is possible to check its HTTP status code or that the response body matches a pattern. The default test sends an OPTIONS request to the '/' page in HTTP/1.0, without the Host field. |Fields|Description| |---|---| |type|`http`| |port|Configurable| |method|`GET`, `HEAD` or `OPTIONS`| -|URL|URL in the form: \[\[https?://]www.example.com]/path/to/check| +|URL|URL of the form [[https?://]www.example.com]/path/to/check| |matches|`default`, `contains` or `matches`| -If the URL is specified, the domain name and protocol are operational. If a domain name is specified, the “Host” field of the request will be filled in, and the request will be sent to HTTP/1.1. If the protocol is specified, it must be consistent with the farm’s SSL configuration. +If a URL is specified, the domain name and protocol are operational. If a domain name is specified, the "Host" field of the request will be filled in and the request will be sent in HTTP/1.1. If the protocol is specified, it must be consistent with the SSL configuration of the farm. > [!primary] > -> We recommend configuring the method, at least, with GET. -> Some servers, including NGINX, do not manage the OPTIONS method without it being configured in advance. +> It is recommended to configure at least the method with GET. +> Indeed, some servers -including Nginx- do not handle the OPTIONS method without prior configuration. > -##### SMTP +##### **SMTP** -This probe attempts to establish an SMTP connection with the server, and sends the command "HELLO localhost". If the server responds, the probe checks that the response code starts with a ‘2’ (success). This probe does not have any specific configuration options. +This probe attempts to establish an SMTP connection with the server and sends the "HELLO localhost" command. If the latter responds, the probe checks that the return code starts with a "2" (success). This probe has no specific configuration options. |Fields|Description| |---|---| @@ -368,9 +395,9 @@ This probe attempts to establish an SMTP connection with the server, and sends t |URL|Not supported| |matches|`default`| -##### MySQL +##### **MySQL** -This probe attempts to establish a MySQL connection with the server, and analyses the server’s response. This probe does not have any specific configuration options. +This probe attempts to establish a MySQL connection with the server and analyses the server's response. This probe has no specific configuration options. |Fields|Description| |---|---| @@ -380,9 +407,9 @@ This probe attempts to establish a MySQL connection with the server, and analyse |URL|Not supported| |matches|`default`| -##### PostgreSQL +##### **PostgreSQL** -This probe attempts to establish a PostgreSQL connection with the server, and analyses the server’s response. This probe does not have any specific configuration options. +This probe attempts to establish a PostgreSQL connection with the server and analyses the server's response. This probe has no specific configuration options. |Fields|Description| |---|---| @@ -392,9 +419,9 @@ This probe attempts to establish a PostgreSQL connection with the server, and an |URL|Not supported| |matches|`default`| -##### oco +##### **oco** -This probe attempts to establish a TCP connection on port 79 of your server, and checks that the response starts with a ‘2’ (success). This probe does not have any specific configuration options. +This probe attempts to establish a TCP connection on port 79 of your server and checks that the response starts with a "2" (success). This probe has no specific configuration options. |Fields|Description| |---|---| @@ -404,20 +431,24 @@ This probe attempts to establish a TCP connection on port 79 of your server, and |URL|Not supported| |matches|`default`| -## Via the OVH Control Panel. +### From the OVHcloud Control Panel -You can configure probes when you add (or modify) a server farm, in advanced settings. +You can configure probes when you add or modify a server farm, in advanced settings. -![Advanced settings for a farm](images/farm_advanced_settings.png){.thumbnail} +![Advanced farm settings](images/farm_advanced_settings.png){.thumbnail} -This is how you access the probe type’s configuration. +You will then have access to the configuration for the probe type. ![Probe settings](images/farm_advanced_settings_unfolded.png){.thumbnail} -If you are able to do so with the probe type you have selected, you can configure specific advanced settings for the probe. +If the probe type you have selected allows it, you can configure advanced settings that are specific to that probe. -![Advanced settings for a probe](images/probe_settings.png){.thumbnail} +![Advanced probe settings](images/probe_settings.png){.thumbnail} A new configuration window will appear, with the probe’s settings. -![Advanced settings for a probe](images/probe_settings_dialog.png){.thumbnail} +![Advanced probe settings](images/probe_settings_dialog.png){.thumbnail} + +## Go further + +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_probes/guide.en-sg.md b/pages/network/load_balancer/create_probes/guide.en-sg.md index 52be1704be5..d774b695308 100644 --- a/pages/network/load_balancer/create_probes/guide.en-sg.md +++ b/pages/network/load_balancer/create_probes/guide.en-sg.md @@ -1,45 +1,69 @@ --- -title: 'Working with probes' -excerpt: 'Find out about the general principles behind probes, and why they are used' -updated: 2019-02-12 +title: "Configuration of probes on an OVHcloud Load Balancer service" +excerpt: "Discover the general principles and use cases for probes" +updated: 2025-11-12 --- -## Objective + -With the OVH Load Balancer, you can distribute a front-end’s incoming traffic across a set of servers in a destination farm. +## Objective -There may be instances where a server in your farm becomes unavailable for a number of reasons, including oversaturation, an incident, or scheduled maintenance. When the OVH Load Balancer detects a connection error, it will try to redirect traffic to another server. The connection will be slower, but it will continue to work. +The OVHcloud Load Balancer allows you to distribute incoming traffic on a frontend to a set of servers in a destination farm. -However, the reasons behind certain types of unavailability can be harder to pinpoint. For example, if a new version of code is being deployed, the application may momentarily experience a glitch, and return a 500 error. In this particular case, a solution would be to mark the servers concerned as unavailable in the API before you begin the maintenance work, apply the configuration and update, then mark the server as available again. This method is not ideal, but it works. For more information on deploying a blue-green architecture with an OVH Load Balancer, please read our guide: . +It may happen that one of the servers in your farm is no longer available for various reasons, such as overload, an incident, or scheduled maintenance. When it encounters a connection error, your OVHcloud Load Balancer attempts to switch traffic to another server. The connection will be slowed down, but it will continue to function. -The purpose of a probe is to test an infrastructure’s health. It periodically examines each of your servers, to ensure that they are working properly. If it detects an error, the server is automatically disabled until the situation is resolved. +However, the causes of some unavailability are more subtle. For example, if a new version of the code is being deployed, the application may temporarily be in a transitional state and return 500 errors. In this specific case, one solution would be to mark the affected servers as unavailable in the API before the start of the maintenance, apply the configuration and update, and then mark the server as available again. This method is not ideal, but it works.
+For more details on deploying a Blue-Green architecture with your OVHcloud Load Balancer, refer to [this guide](/pages/network/load_balancer/case_blue_green). -Since this service is still very new, its basic features are only available in the API. +Probes are health checks. They periodically query each of your servers to ensure they are operational. If an error is detected, the server is automatically disabled until the situation is resolved. -**This guide will explain the general principles behind probes, and provide practical examples of probes being used.** +**This guide will present the general principles, as well as usage scenarios for probes, drawn from real-world use cases.** ## Requirements -- a correctly configured OVH Load Balancer, with farms and servers set +- Have an [OVHcloud Load Balancer](/links/network/load-balancer) offer in your OVHcloud account. The service must be properly configured, with farms and servers set up. +- Be logged in to your [OVHcloud Control Panel](/links/manager). ## Instructions -### An introduction to the API. +**Table of contents** + +- [Probe API overview](#probe-api) +- [Examples](#examples) +- [Reference](#reference) +- [From the OVHcloud Control Panel](#manager) + +### Probe API overview -The API for probes in the OVH Load Balancer is designed to be flexible and scalable. +The probe API of your OVHcloud Load Balancer has been designed to be flexible and scalable. -The probes can be configured directly on the farms. All of the servers from a single farm will have exactly the same probe applied. However, probe activation and deactivation is specific for each server. As a result, it is possible to only monitor certain servers within a single farm. +Probes are configured directly on the farms. All servers in the same farm thus apply exactly the same probe. However, enabling or disabling a probe is specific to each server. It is therefore possible to "monitor" only certain servers in the same farm. -You can view the list of available probes and their settings with the following API call: +The list of available probes and their parameters can be consulted with the API call : > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/availableFarmProbes > -For more information on this call, please read the *Available probes* section at the bottom of this guide. +For more information on this call, we invite you to consult the [Available probes](#available-probes) section at the bottom of this guide. -The probes in this list can be configured on `http` and `tcp` farms via the following calls: +The probes returned by this list can be configured on `http` and `tcp` farms via the following calls : > [!api] > @@ -61,56 +85,58 @@ The probes in this list can be configured on `http` and `tcp` farms via the foll > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/tcp/farm/{farmId} > -For more information on these calls, please read the *Probe configuration* section at the bottom of this guide. +For more information on these calls, you can refer to the [Probe handling](#handling-probes) section of this guide. -### Examples +### Examples -#### Check if the server accepts TCP connections. +#### Check if the server accepts TCP connections -This is the simplest method to set up. It is compatible with `tcp` and `http` farms. If no other probes are configured, you can activate it to start. It works by periodically attempting to establish a connection on each of your servers. If the connection fails twice in a row, the server is put aside until it responds again. +This is the simplest probe to set up. It is compatible with `tcp` and `http` farms. If no other probe is configured, you can activate this one to start. It works by periodically trying to open a connection on each of your servers. If the connection fails twice in a row, the server is put aside until it responds again. -In practice, this gives a probe: +In practice, this gives a probe : |Field|Value and description| |---|---| -|serviceName|Your OVH Load Balancer ID| -|farmId|Your TCP or HTTP farm| +|serviceName|Identifier of your OVHcloud Load Balancer| +|farmId|Identifier of your TCP or HTTP farm| |probe.type|"tcp"| -All other probe fields can keep their default values. Just apply the configuration to the zone concerned, and the probe will begin to work. +All other `probe` fields can remain at their default values. You just need to apply the configuration in the relevant area. -#### Test a specific HTTP page. +#### Test a specific HTTP page -By default, the HTTP `probe` sends an "OPTIONS" request on "/" in HTTP/1.0, without a domain name. In many cases, this is sufficient, but some servers do not manage this method. You can carry out much more powerful tests with the HTTP probe. For example, a good practice when exposing a HTTP service is to add a router dedicated to probes. It is normal to see "/status", "/health", and "/check", which summarise the service’s status. +By default, the HTTP probe sends an `OPTIONS` request on `/` in HTTP/1.0, without a domain name. This is sufficient in many cases, but some servers do not handle this method.
+It is possible to perform much more powerful tests with the HTTP probe. For example, a good practice when exposing an HTTP service is to add a dedicated route for probes. It is common to find `/status`, `/health`, `/check` which return a summary of the service's status. -In practice, if you want to configure the probe to send a "GET" request on [http://api.example.com/status](http://api.example.com/status), it gives: +In practice, if you want to configure the probe to send a `GET` request to [http://api.example.com/status](http://api.example.com/status), this gives : |Field|Value and description| |---|---| -|serviceName|Your OVH Load Balancer ID| -|farmId|Your TCP or HTTP farm| +|serviceName|Identifier of your OVHcloud Load Balancer| +|farmId|Identifier of your TCP or HTTP farm| |probe.type|http| |probe.method|GET| |probe.url|[http://api.example.com/status](http://api.example.com/status)| |probe.match|status| -|probe.pattern|200 (multiple status codes can be added, provided they are separated by commas)| +|probe.pattern|200 (several status codes can be added, separated by commas)| -All other probe fields can keep their default values. Finally, apply the configuration to the zone concerned. +All other `probe` fields can remain at their default values. It is then sufficient to apply the configuration in the relevant area. -#### Use an external HTTP test. +#### Use an external HTTP test -What happens if, for example, your service is an IMAP server that relies on an LDAP server for authentication? The server may accept connections, but experience a temporary connection issue with the LDAP server. If this happens, the customers redirected to this server would be able to connect, but wouldn’t be able to authenticate. As a result, the server would need to be removed from the farm. +What if your service is, for example, an IMAP server that relies on an LDAP server for authentication ?
+It is possible that the server accepts connections, but has a temporary connection issue with the LDAP server. If this happens, clients who are directed to this server could connect but not authenticate. The server should therefore be removed from the farm. -If you are using a `tcp` probe, it will manage to connect. As a result, it will consider the service to be available, even though this is not the case. +If a `tcp` type probe is used, it will be able to connect and consider the service available even though it is not the case. -In this situation, the health test would ideally be able to confirm that the basic service works. You can provide a specific port to use in the tests. This way, you can set up arbitrary tests for a service, and expose them to HTTP on a dedicated port. +In this scenario, the ideal would be for the health check to confirm that the base service is working. It is possible to indicate a specific port to use in the tests. This allows arbitrary tests to be set up for a service and exposed in HTTP, on a dedicated port. -For example, in this situation, you can have a HTTP server on port 8080\. It will test the IMAP server via the URL "/service/imap/status", and will return ‘OK’ when everything is working properly. In practice, this will return: +For example, in this scenario, it would be possible to have an HTTP server on port 8080 that tests the IMAP server via the url `/service/imap/status` and returns *OK* when everything is fine. This would give in practice : |Field|Value and description| |---|---| -|serviceName|Your OVH Load Balancer ID| -|farmId|Your TCP or HTTP farm| +|serviceName|Identifier of your OVHcloud Load Balancer| +|farmId|Identifier of your TCP or HTTP farm| |probe.type|http| |probe.port|8080| |probe.method|GET| @@ -118,24 +144,24 @@ For example, in this situation, you can have a HTTP server on port 8080\. It wil |probe.match|contains| |probe.pattern|OK| -Just apply the configuration to the zone concerned, and the probe will begin to work. +It is then sufficient to apply the configuration in the relevant area. > [!warning] > -> If the HTTP service dedicated to monitoring your IMAP service experiences a fault, the IMAP service will also be considered faulty, even if it is working properly. +> If the HTTP service dedicated to monitoring your IMAP service itself fails, the IMAP service will also be considered as failed, even if it is in perfect working condition. > -### Reference +### Reference -#### Probe configuration. +#### Probe handling -##### Configure a probe. +##### **Configure a probe** -Probes can be configured on a new farm (`POST`) or an existing one (`PUT`). Since the two methods are equivalent, only the second (`PUT`) method is presented here. +Probes can be configured on a new farm (`POST`) or an existing farm (`PUT`). The two methods being equivalent, only the second one (`PUT`) will be presented here. > [!faq] > -> Service: +> Service : > >> > [!api] >> > @@ -143,85 +169,86 @@ Probes can be configured on a new farm (`POST`) or an existing one (`PUT`). Sinc >> > >> > -> Settings: +> Parameters : > >> > **serviceName** >> > ->> >> Your OVH Load Balancer ID. +>> >> The identifier of your OVHcloud Load Balancer. >> > >> > **farmId** >> > ->> >> Your `farm` ID number. +>> >> The numeric identifier of your `farm`. >> > >> > **probe** >> > >> >> **type** >> >> ->> >> > The type of `probe` to activate. The probe types managed are: +>> >> > The type of `probe` to enable. The probe types handled are : >> >> > ->> >> > `tcp` for a basic TCP connection test. +>> >> > `tcp` for a basic TCP connection test ; >> >> > ->> >> > `http` for a HTTP connection test. You can specify the URL and the method. +>> >> > `http` for an HTTP connection test. It is possible to specify the URL and method ; >> >> > ->> >> > `smtp` for a basic SMTP connection test. +>> >> > `smtp` for a basic SMTP connection test ; >> >> > ->> >> > `mysql` for a basic MySQL connection test. +>> >> > `mysql` for a basic MySQL connection test ; >> >> > ->> >> > `pgsql` for a basic PostgreSQL connection test. +>> >> > `pgslq` for a basic PostgreSQL connection test ; >> >> > ->> >> > `oco` for a confirmation of the general status returned on port 79. +>> >> > `oco` for a general status validation returned on port 79. >> > >> >> **interval** >> >> ->> >> > The interval (in seconds) between a probe’s two connection attempts. It must be at least 30 seconds. +>> >> > The interval in seconds between two probe attempts. It must be at least 30 seconds. >> > >> >> **port** >> >> ->> >> > The port that the probe must use, if it is different to the port configured on the farm. ->> >> > This enables you to delegate a server’s status validation to a separate service on the machine, and carry out arbitrary probes. +>> >> > The port that the probe should use, if it is different from the one configured on the farm. +>> >> > This allows you to delegate the server status validation to a third-party service on the machine and perform arbitrary probes. >> > >> >> **method** >> >> ->> >> > The HTTP method to use if the probe is a “http” probe. ->> >> > Compatible methods are `GET`, `HEAD` and `OPTIONS` (by default). +>> >> > The HTTP method to use if the probe is of type "http". +>> >> > The compatible methods are `GET`, `HEAD` and `OPTIONS` (default). >> > >> >> **url** >> >> ->> >> > The URL to use for tests, if it is a “http” probe type. ->> >> > It should be formulated as follows: `[[https?://]www.example.com]/path/to/check`. ->> >> > If a domain is specified, its request will be sent to HTTP/1.1 rather than HTTP/1.0 by default. +>> >> > The URL to use for the tests, if the probe is of type "http". +>> >> > Its form must be `[[https?://]www.example.com]/path/to/check`. +>> >> > If a domain is specified, the request will be sent in HTTP/1.1 instead of HTTP/1.0 by default. >> > >> >> **match** >> >> ->> >> > The type of comparison to use to check if the server is in good health. ->> >> > The managed comparison types are `default`, `status`, `contains` and `matches`. ->> >> > Comparison types are compatible with both “http” and “tcp” probes. +>> >> > The type of comparator to use to check that the server is healthy. +>> >> > The comparators handled are `default`, `status`, `contains` and `matches`. +>> >> > The comparators are compatible with "http" and "tcp" probes. >> > >> >> **pattern** >> >> ->> >> > The value to use as an argument of the comparison type if it is different from “default”. +>> >> > The value to use as an argument for the comparator if it is different from "default". >> > >> >> **forceSsl** >> >> ->> >> > This defines whether the probe must work in SSL/TLS, even if the farm is configured to connect via standard TCP. ->> >> > This can be useful when, for example, your OVH Load Balancer is configured to monitor HTTPS traffic in TCP without decrypting it. +>> >> > Defines whether the probe should work in SSL/TLS even if the farm is configured to connect in classic TCP. +>> >> > This can be useful, for example, when your OVHcloud Load Balancer is configured to forward HTTPS traffic in TCP without decrypting it. > -Other settings can be edited via this call. Since this guide focuses on probes, they are not documented here. +Other parameters can be edited via this call. As this guide focuses on probes, they are not documented here. -If a port other than the farm’s base port is configured on the probe, the `proxyprotocol` and `ssl` settings are reset. As an example, we will take a configured farm to use `proxyprotocol` on **port 4242**, and an associated probe using **port 8080**. The probe will not send the `proxyprotocol` header when it connects on **port 8080**. The same goes for `ssl`, but it can be forced. +If a port other than the base port of the farm is configured on the probe, the `proxyprotocol` and `ssl` parameters are reset. Take the example of a farm configured to use `proxyprotocol` on port **4242** and a probe associated with port **8080**: the latter will not send the `proxyprotocol` header when connecting to port **8080**. The same applies to `ssl`, which can nevertheless be forced. > [!warning] > -> When a probe is configured on a farm, it must be activated on the servers. +> When a probe is configured on a farm, it must also be enabled on the servers. > -##### Activate probes on a server. -For a probe to be active, it must be configured on the farm and activated on the servers concerned. With this call, you can activate the probe being taken into account: +##### **Enable probes on a server** + +For a probe to be active, it must have been configured on the farm and enabled on the relevant servers. This call allows you to enable the probe : > [!faq] > -> Service: +> Service : > >> > [!api] >> > @@ -229,47 +256,47 @@ For a probe to be active, it must be configured on the farm and activated on the >> > >> > -> Settings: +> Parameters : > >> > **serviceName** >> > ->> >> Your OVH Load Balancer ID. +>> >> The identifier of your OVHcloud Load Balancer. >> > >> > **farmId** >> > ->> >> Your `farm` ID number. +>> >> The numeric identifier of your `farm`. >> > >> > **serverId** >> > ->> >> Your `server’s` ID number. +>> >> The numeric identifier of your `server`. >> > >> > **probe** >> > ->> >> Whether or not the `probes` must be taken into account. +>> >> Indicates whether `probe` should be taken into account or not. > -Other settings can be edited via this call. Since this guide focuses on probes, they are not documented here. +Other parameters can be edited via this call. As this guide focuses on probes, they are not documented here. -#### Available comparison types. +#### Available comparators -Four comparison types are available to confirm a probe’s results: +Four comparators are available to validate the result of a probe : -|Comparison type|Description| +|Comparator|Description| |---|---| -|default|Launches a basic test, without any settings.| -|status|A list of valid HTTP response codes, separated by commas.| -|contains|Checks that the pattern can be found in the response.| -|matches|Checks that the response corresponds to a regular expression pattern.| +|default|Runs a basic test, without parameters.| +|status|Comma-separated list of valid HTTP return codes.| +|contains|Checks that the pattern is in the response.| +|matches|Checks that the response matches the pattern regular expression.| -‘Contains’ and ‘matches’ comparison types find a correspondence in the first 16 KB of the response. If the response is longer than 16 KB, whatever comes afterwards will be ignored during the test. Please note that to optimise your performance, we recommend returning as little information as possible in your probes. +The `contains` and `matches` comparators look for a match in the first 16 KB of the response. If it is longer, the part beyond will be ignored during the search. Note that for better performance, we recommend returning as little information as possible in your probes. -#### Available probes. +#### Available probes -You can get a list of the available probes using the following API call: +The list of available probes can be obtained with the API call : > [!faq] > -> Service: +> Service : > >> > [!api] >> > @@ -277,56 +304,56 @@ You can get a list of the available probes using the following API call: >> > >> > -> Response: +> Response : > >> > **type** >> > ->> >> The type of `probe` to configure in the `probe.type` of `farms`. +>> >> The type of `probe` to configure in the `probe.type` field of the `farms`. >> >> ->> >> The probe types managed are: +>> >> The probe types handled are : >> >> ->> >> `tcp` for a basic TCP connection test. +>> >> `tcp` for a basic TCP connection test ; >> >> ->> >> `http` for a HTTP connection test. You can specify the URL and the method. +>> >> `http` for an HTTP connection test. It is possible to specify the URL and method ; >> >> ->> >> `smtp` for a basic SMTP connection test. +>> >> `smtp` for a basic SMTP connection test ; >> >> ->> >> `mysql` for a basic MySQL connection test. +>> >> `mysql` for a basic MySQL connection test ; >> >> ->> >> `pgsql` for a basic PostgreSQL connection test. +>> >> `pgslq` for a basic PostgreSQL connection test ; >> >> ->> >> `oco` for a confirmation of the general status returned on port 79. +>> >> `oco` for a general status validation returned on port 79. >> > >> > **port** >> > ->> >> This defines whether the port can be configured for this probe. +>> >> Indicates whether the port can be configured for this probe. >> > >> > **method** >> > ->> >> The list of HTTP methods managed, or `null` if none are managed. +>> >> The list of HTTP methods handled or `null` if none exist. >> > >> > **url** >> > ->> >> This defines if the probe’s URL can be configured. +>> >> Indicates whether the probe URL can be configured. >> > >> > **matches** >> > ->> >> The list of comparison types available for this probe. +>> >> The list of available comparators for this probe. >> >> The interpretation of the `probe.pattern` field depends on this field. ->> >> The comparison types potentially managed are: +>> >> The potentially handled comparators are : >> >> ->> >> `default`. The most simple test, without any particular conditions.`probe.pattern` must be empty. +>> >> `default` the simplest test, without specific conditions. `probe.pattern` must be empty ; >> >> ->> >> `status`. Checks if the HTTP status code is in the list separated by commas. +>> >> `status` checks that the HTTP status code is in the comma-separated list ; >> >> ->> >> `contains`. Checks that the server response contains `probe.pattern`. +>> >> `contains` checks that the server response contains `probe.pattern` ; >> >> ->> >> `matches`. Checks that the server response matches `probe.pattern`. +>> >> `matches` checks that the server response matches `probe.pattern`. > -##### TCP +##### **TCP** -This probe attempts to establish a TCP connection to the server. If the server sends a “banner”, you can check if it matches a schema. The default test simply ensures that the connection can be established. +This probe attempts to establish a TCP connection with the server. If the latter sends a "banner", it is possible to check that it matches a pattern. The default test simply ensures that the connection can be established. |Fields|Description| |---|---| @@ -336,29 +363,29 @@ This probe attempts to establish a TCP connection to the server. If the server s |URL|Not supported| |matches|`default`, `contains` or `matches`| -##### HTTP +##### **HTTP** -This probe attempts to establish a HTTP connection to the server. If the server responds, you can check its HTTP status code, and that the response body matches a schema. The default test sends an OPTIONS request to the '/' page in HTTP/1.0, without a Host field. +This probe attempts to establish an HTTP connection with the server. If the latter responds, it is possible to check its HTTP status code or that the response body matches a pattern. The default test sends an OPTIONS request to the '/' page in HTTP/1.0, without the Host field. |Fields|Description| |---|---| |type|`http`| |port|Configurable| |method|`GET`, `HEAD` or `OPTIONS`| -|URL|URL in the form: \[\[https?://]www.example.com]/path/to/check| +|URL|URL of the form [[https?://]www.example.com]/path/to/check| |matches|`default`, `contains` or `matches`| -If the URL is specified, the domain name and protocol are operational. If a domain name is specified, the “Host” field of the request will be filled in, and the request will be sent to HTTP/1.1. If the protocol is specified, it must be consistent with the farm’s SSL configuration. +If a URL is specified, the domain name and protocol are operational. If a domain name is specified, the "Host" field of the request will be filled in and the request will be sent in HTTP/1.1. If the protocol is specified, it must be consistent with the SSL configuration of the farm. > [!primary] > -> We recommend configuring the method, at least, with GET. -> Some servers, including NGINX, do not manage the OPTIONS method without it being configured in advance. +> It is recommended to configure at least the method with GET. +> Indeed, some servers -including Nginx- do not handle the OPTIONS method without prior configuration. > -##### SMTP +##### **SMTP** -This probe attempts to establish an SMTP connection with the server, and sends the command "HELLO localhost". If the server responds, the probe checks that the response code starts with a ‘2’ (success). This probe does not have any specific configuration options. +This probe attempts to establish an SMTP connection with the server and sends the "HELLO localhost" command. If the latter responds, the probe checks that the return code starts with a "2" (success). This probe has no specific configuration options. |Fields|Description| |---|---| @@ -368,9 +395,9 @@ This probe attempts to establish an SMTP connection with the server, and sends t |URL|Not supported| |matches|`default`| -##### MySQL +##### **MySQL** -This probe attempts to establish a MySQL connection with the server, and analyses the server’s response. This probe does not have any specific configuration options. +This probe attempts to establish a MySQL connection with the server and analyses the server's response. This probe has no specific configuration options. |Fields|Description| |---|---| @@ -380,9 +407,9 @@ This probe attempts to establish a MySQL connection with the server, and analyse |URL|Not supported| |matches|`default`| -##### PostgreSQL +##### **PostgreSQL** -This probe attempts to establish a PostgreSQL connection with the server, and analyses the server’s response. This probe does not have any specific configuration options. +This probe attempts to establish a PostgreSQL connection with the server and analyses the server's response. This probe has no specific configuration options. |Fields|Description| |---|---| @@ -392,9 +419,9 @@ This probe attempts to establish a PostgreSQL connection with the server, and an |URL|Not supported| |matches|`default`| -##### oco +##### **oco** -This probe attempts to establish a TCP connection on port 79 of your server, and checks that the response starts with a ‘2’ (success). This probe does not have any specific configuration options. +This probe attempts to establish a TCP connection on port 79 of your server and checks that the response starts with a "2" (success). This probe has no specific configuration options. |Fields|Description| |---|---| @@ -404,20 +431,24 @@ This probe attempts to establish a TCP connection on port 79 of your server, and |URL|Not supported| |matches|`default`| -## Via the OVH Control Panel. +### From the OVHcloud Control Panel -You can configure probes when you add (or modify) a server farm, in advanced settings. +You can configure probes when you add or modify a server farm, in advanced settings. -![Advanced settings for a farm](images/farm_advanced_settings.png){.thumbnail} +![Advanced farm settings](images/farm_advanced_settings.png){.thumbnail} -This is how you access the probe type’s configuration. +You will then have access to the configuration for the probe type. ![Probe settings](images/farm_advanced_settings_unfolded.png){.thumbnail} -If you are able to do so with the probe type you have selected, you can configure specific advanced settings for the probe. +If the probe type you have selected allows it, you can configure advanced settings that are specific to that probe. -![Advanced settings for a probe](images/probe_settings.png){.thumbnail} +![Advanced probe settings](images/probe_settings.png){.thumbnail} A new configuration window will appear, with the probe’s settings. -![Advanced settings for a probe](images/probe_settings_dialog.png){.thumbnail} +![Advanced probe settings](images/probe_settings_dialog.png){.thumbnail} + +## Go further + +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_probes/guide.en-us.md b/pages/network/load_balancer/create_probes/guide.en-us.md index 52be1704be5..d774b695308 100644 --- a/pages/network/load_balancer/create_probes/guide.en-us.md +++ b/pages/network/load_balancer/create_probes/guide.en-us.md @@ -1,45 +1,69 @@ --- -title: 'Working with probes' -excerpt: 'Find out about the general principles behind probes, and why they are used' -updated: 2019-02-12 +title: "Configuration of probes on an OVHcloud Load Balancer service" +excerpt: "Discover the general principles and use cases for probes" +updated: 2025-11-12 --- -## Objective + -With the OVH Load Balancer, you can distribute a front-end’s incoming traffic across a set of servers in a destination farm. +## Objective -There may be instances where a server in your farm becomes unavailable for a number of reasons, including oversaturation, an incident, or scheduled maintenance. When the OVH Load Balancer detects a connection error, it will try to redirect traffic to another server. The connection will be slower, but it will continue to work. +The OVHcloud Load Balancer allows you to distribute incoming traffic on a frontend to a set of servers in a destination farm. -However, the reasons behind certain types of unavailability can be harder to pinpoint. For example, if a new version of code is being deployed, the application may momentarily experience a glitch, and return a 500 error. In this particular case, a solution would be to mark the servers concerned as unavailable in the API before you begin the maintenance work, apply the configuration and update, then mark the server as available again. This method is not ideal, but it works. For more information on deploying a blue-green architecture with an OVH Load Balancer, please read our guide: . +It may happen that one of the servers in your farm is no longer available for various reasons, such as overload, an incident, or scheduled maintenance. When it encounters a connection error, your OVHcloud Load Balancer attempts to switch traffic to another server. The connection will be slowed down, but it will continue to function. -The purpose of a probe is to test an infrastructure’s health. It periodically examines each of your servers, to ensure that they are working properly. If it detects an error, the server is automatically disabled until the situation is resolved. +However, the causes of some unavailability are more subtle. For example, if a new version of the code is being deployed, the application may temporarily be in a transitional state and return 500 errors. In this specific case, one solution would be to mark the affected servers as unavailable in the API before the start of the maintenance, apply the configuration and update, and then mark the server as available again. This method is not ideal, but it works.
+For more details on deploying a Blue-Green architecture with your OVHcloud Load Balancer, refer to [this guide](/pages/network/load_balancer/case_blue_green). -Since this service is still very new, its basic features are only available in the API. +Probes are health checks. They periodically query each of your servers to ensure they are operational. If an error is detected, the server is automatically disabled until the situation is resolved. -**This guide will explain the general principles behind probes, and provide practical examples of probes being used.** +**This guide will present the general principles, as well as usage scenarios for probes, drawn from real-world use cases.** ## Requirements -- a correctly configured OVH Load Balancer, with farms and servers set +- Have an [OVHcloud Load Balancer](/links/network/load-balancer) offer in your OVHcloud account. The service must be properly configured, with farms and servers set up. +- Be logged in to your [OVHcloud Control Panel](/links/manager). ## Instructions -### An introduction to the API. +**Table of contents** + +- [Probe API overview](#probe-api) +- [Examples](#examples) +- [Reference](#reference) +- [From the OVHcloud Control Panel](#manager) + +### Probe API overview -The API for probes in the OVH Load Balancer is designed to be flexible and scalable. +The probe API of your OVHcloud Load Balancer has been designed to be flexible and scalable. -The probes can be configured directly on the farms. All of the servers from a single farm will have exactly the same probe applied. However, probe activation and deactivation is specific for each server. As a result, it is possible to only monitor certain servers within a single farm. +Probes are configured directly on the farms. All servers in the same farm thus apply exactly the same probe. However, enabling or disabling a probe is specific to each server. It is therefore possible to "monitor" only certain servers in the same farm. -You can view the list of available probes and their settings with the following API call: +The list of available probes and their parameters can be consulted with the API call : > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/availableFarmProbes > -For more information on this call, please read the *Available probes* section at the bottom of this guide. +For more information on this call, we invite you to consult the [Available probes](#available-probes) section at the bottom of this guide. -The probes in this list can be configured on `http` and `tcp` farms via the following calls: +The probes returned by this list can be configured on `http` and `tcp` farms via the following calls : > [!api] > @@ -61,56 +85,58 @@ The probes in this list can be configured on `http` and `tcp` farms via the foll > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/tcp/farm/{farmId} > -For more information on these calls, please read the *Probe configuration* section at the bottom of this guide. +For more information on these calls, you can refer to the [Probe handling](#handling-probes) section of this guide. -### Examples +### Examples -#### Check if the server accepts TCP connections. +#### Check if the server accepts TCP connections -This is the simplest method to set up. It is compatible with `tcp` and `http` farms. If no other probes are configured, you can activate it to start. It works by periodically attempting to establish a connection on each of your servers. If the connection fails twice in a row, the server is put aside until it responds again. +This is the simplest probe to set up. It is compatible with `tcp` and `http` farms. If no other probe is configured, you can activate this one to start. It works by periodically trying to open a connection on each of your servers. If the connection fails twice in a row, the server is put aside until it responds again. -In practice, this gives a probe: +In practice, this gives a probe : |Field|Value and description| |---|---| -|serviceName|Your OVH Load Balancer ID| -|farmId|Your TCP or HTTP farm| +|serviceName|Identifier of your OVHcloud Load Balancer| +|farmId|Identifier of your TCP or HTTP farm| |probe.type|"tcp"| -All other probe fields can keep their default values. Just apply the configuration to the zone concerned, and the probe will begin to work. +All other `probe` fields can remain at their default values. You just need to apply the configuration in the relevant area. -#### Test a specific HTTP page. +#### Test a specific HTTP page -By default, the HTTP `probe` sends an "OPTIONS" request on "/" in HTTP/1.0, without a domain name. In many cases, this is sufficient, but some servers do not manage this method. You can carry out much more powerful tests with the HTTP probe. For example, a good practice when exposing a HTTP service is to add a router dedicated to probes. It is normal to see "/status", "/health", and "/check", which summarise the service’s status. +By default, the HTTP probe sends an `OPTIONS` request on `/` in HTTP/1.0, without a domain name. This is sufficient in many cases, but some servers do not handle this method.
+It is possible to perform much more powerful tests with the HTTP probe. For example, a good practice when exposing an HTTP service is to add a dedicated route for probes. It is common to find `/status`, `/health`, `/check` which return a summary of the service's status. -In practice, if you want to configure the probe to send a "GET" request on [http://api.example.com/status](http://api.example.com/status), it gives: +In practice, if you want to configure the probe to send a `GET` request to [http://api.example.com/status](http://api.example.com/status), this gives : |Field|Value and description| |---|---| -|serviceName|Your OVH Load Balancer ID| -|farmId|Your TCP or HTTP farm| +|serviceName|Identifier of your OVHcloud Load Balancer| +|farmId|Identifier of your TCP or HTTP farm| |probe.type|http| |probe.method|GET| |probe.url|[http://api.example.com/status](http://api.example.com/status)| |probe.match|status| -|probe.pattern|200 (multiple status codes can be added, provided they are separated by commas)| +|probe.pattern|200 (several status codes can be added, separated by commas)| -All other probe fields can keep their default values. Finally, apply the configuration to the zone concerned. +All other `probe` fields can remain at their default values. It is then sufficient to apply the configuration in the relevant area. -#### Use an external HTTP test. +#### Use an external HTTP test -What happens if, for example, your service is an IMAP server that relies on an LDAP server for authentication? The server may accept connections, but experience a temporary connection issue with the LDAP server. If this happens, the customers redirected to this server would be able to connect, but wouldn’t be able to authenticate. As a result, the server would need to be removed from the farm. +What if your service is, for example, an IMAP server that relies on an LDAP server for authentication ?
+It is possible that the server accepts connections, but has a temporary connection issue with the LDAP server. If this happens, clients who are directed to this server could connect but not authenticate. The server should therefore be removed from the farm. -If you are using a `tcp` probe, it will manage to connect. As a result, it will consider the service to be available, even though this is not the case. +If a `tcp` type probe is used, it will be able to connect and consider the service available even though it is not the case. -In this situation, the health test would ideally be able to confirm that the basic service works. You can provide a specific port to use in the tests. This way, you can set up arbitrary tests for a service, and expose them to HTTP on a dedicated port. +In this scenario, the ideal would be for the health check to confirm that the base service is working. It is possible to indicate a specific port to use in the tests. This allows arbitrary tests to be set up for a service and exposed in HTTP, on a dedicated port. -For example, in this situation, you can have a HTTP server on port 8080\. It will test the IMAP server via the URL "/service/imap/status", and will return ‘OK’ when everything is working properly. In practice, this will return: +For example, in this scenario, it would be possible to have an HTTP server on port 8080 that tests the IMAP server via the url `/service/imap/status` and returns *OK* when everything is fine. This would give in practice : |Field|Value and description| |---|---| -|serviceName|Your OVH Load Balancer ID| -|farmId|Your TCP or HTTP farm| +|serviceName|Identifier of your OVHcloud Load Balancer| +|farmId|Identifier of your TCP or HTTP farm| |probe.type|http| |probe.port|8080| |probe.method|GET| @@ -118,24 +144,24 @@ For example, in this situation, you can have a HTTP server on port 8080\. It wil |probe.match|contains| |probe.pattern|OK| -Just apply the configuration to the zone concerned, and the probe will begin to work. +It is then sufficient to apply the configuration in the relevant area. > [!warning] > -> If the HTTP service dedicated to monitoring your IMAP service experiences a fault, the IMAP service will also be considered faulty, even if it is working properly. +> If the HTTP service dedicated to monitoring your IMAP service itself fails, the IMAP service will also be considered as failed, even if it is in perfect working condition. > -### Reference +### Reference -#### Probe configuration. +#### Probe handling -##### Configure a probe. +##### **Configure a probe** -Probes can be configured on a new farm (`POST`) or an existing one (`PUT`). Since the two methods are equivalent, only the second (`PUT`) method is presented here. +Probes can be configured on a new farm (`POST`) or an existing farm (`PUT`). The two methods being equivalent, only the second one (`PUT`) will be presented here. > [!faq] > -> Service: +> Service : > >> > [!api] >> > @@ -143,85 +169,86 @@ Probes can be configured on a new farm (`POST`) or an existing one (`PUT`). Sinc >> > >> > -> Settings: +> Parameters : > >> > **serviceName** >> > ->> >> Your OVH Load Balancer ID. +>> >> The identifier of your OVHcloud Load Balancer. >> > >> > **farmId** >> > ->> >> Your `farm` ID number. +>> >> The numeric identifier of your `farm`. >> > >> > **probe** >> > >> >> **type** >> >> ->> >> > The type of `probe` to activate. The probe types managed are: +>> >> > The type of `probe` to enable. The probe types handled are : >> >> > ->> >> > `tcp` for a basic TCP connection test. +>> >> > `tcp` for a basic TCP connection test ; >> >> > ->> >> > `http` for a HTTP connection test. You can specify the URL and the method. +>> >> > `http` for an HTTP connection test. It is possible to specify the URL and method ; >> >> > ->> >> > `smtp` for a basic SMTP connection test. +>> >> > `smtp` for a basic SMTP connection test ; >> >> > ->> >> > `mysql` for a basic MySQL connection test. +>> >> > `mysql` for a basic MySQL connection test ; >> >> > ->> >> > `pgsql` for a basic PostgreSQL connection test. +>> >> > `pgslq` for a basic PostgreSQL connection test ; >> >> > ->> >> > `oco` for a confirmation of the general status returned on port 79. +>> >> > `oco` for a general status validation returned on port 79. >> > >> >> **interval** >> >> ->> >> > The interval (in seconds) between a probe’s two connection attempts. It must be at least 30 seconds. +>> >> > The interval in seconds between two probe attempts. It must be at least 30 seconds. >> > >> >> **port** >> >> ->> >> > The port that the probe must use, if it is different to the port configured on the farm. ->> >> > This enables you to delegate a server’s status validation to a separate service on the machine, and carry out arbitrary probes. +>> >> > The port that the probe should use, if it is different from the one configured on the farm. +>> >> > This allows you to delegate the server status validation to a third-party service on the machine and perform arbitrary probes. >> > >> >> **method** >> >> ->> >> > The HTTP method to use if the probe is a “http” probe. ->> >> > Compatible methods are `GET`, `HEAD` and `OPTIONS` (by default). +>> >> > The HTTP method to use if the probe is of type "http". +>> >> > The compatible methods are `GET`, `HEAD` and `OPTIONS` (default). >> > >> >> **url** >> >> ->> >> > The URL to use for tests, if it is a “http” probe type. ->> >> > It should be formulated as follows: `[[https?://]www.example.com]/path/to/check`. ->> >> > If a domain is specified, its request will be sent to HTTP/1.1 rather than HTTP/1.0 by default. +>> >> > The URL to use for the tests, if the probe is of type "http". +>> >> > Its form must be `[[https?://]www.example.com]/path/to/check`. +>> >> > If a domain is specified, the request will be sent in HTTP/1.1 instead of HTTP/1.0 by default. >> > >> >> **match** >> >> ->> >> > The type of comparison to use to check if the server is in good health. ->> >> > The managed comparison types are `default`, `status`, `contains` and `matches`. ->> >> > Comparison types are compatible with both “http” and “tcp” probes. +>> >> > The type of comparator to use to check that the server is healthy. +>> >> > The comparators handled are `default`, `status`, `contains` and `matches`. +>> >> > The comparators are compatible with "http" and "tcp" probes. >> > >> >> **pattern** >> >> ->> >> > The value to use as an argument of the comparison type if it is different from “default”. +>> >> > The value to use as an argument for the comparator if it is different from "default". >> > >> >> **forceSsl** >> >> ->> >> > This defines whether the probe must work in SSL/TLS, even if the farm is configured to connect via standard TCP. ->> >> > This can be useful when, for example, your OVH Load Balancer is configured to monitor HTTPS traffic in TCP without decrypting it. +>> >> > Defines whether the probe should work in SSL/TLS even if the farm is configured to connect in classic TCP. +>> >> > This can be useful, for example, when your OVHcloud Load Balancer is configured to forward HTTPS traffic in TCP without decrypting it. > -Other settings can be edited via this call. Since this guide focuses on probes, they are not documented here. +Other parameters can be edited via this call. As this guide focuses on probes, they are not documented here. -If a port other than the farm’s base port is configured on the probe, the `proxyprotocol` and `ssl` settings are reset. As an example, we will take a configured farm to use `proxyprotocol` on **port 4242**, and an associated probe using **port 8080**. The probe will not send the `proxyprotocol` header when it connects on **port 8080**. The same goes for `ssl`, but it can be forced. +If a port other than the base port of the farm is configured on the probe, the `proxyprotocol` and `ssl` parameters are reset. Take the example of a farm configured to use `proxyprotocol` on port **4242** and a probe associated with port **8080**: the latter will not send the `proxyprotocol` header when connecting to port **8080**. The same applies to `ssl`, which can nevertheless be forced. > [!warning] > -> When a probe is configured on a farm, it must be activated on the servers. +> When a probe is configured on a farm, it must also be enabled on the servers. > -##### Activate probes on a server. -For a probe to be active, it must be configured on the farm and activated on the servers concerned. With this call, you can activate the probe being taken into account: +##### **Enable probes on a server** + +For a probe to be active, it must have been configured on the farm and enabled on the relevant servers. This call allows you to enable the probe : > [!faq] > -> Service: +> Service : > >> > [!api] >> > @@ -229,47 +256,47 @@ For a probe to be active, it must be configured on the farm and activated on the >> > >> > -> Settings: +> Parameters : > >> > **serviceName** >> > ->> >> Your OVH Load Balancer ID. +>> >> The identifier of your OVHcloud Load Balancer. >> > >> > **farmId** >> > ->> >> Your `farm` ID number. +>> >> The numeric identifier of your `farm`. >> > >> > **serverId** >> > ->> >> Your `server’s` ID number. +>> >> The numeric identifier of your `server`. >> > >> > **probe** >> > ->> >> Whether or not the `probes` must be taken into account. +>> >> Indicates whether `probe` should be taken into account or not. > -Other settings can be edited via this call. Since this guide focuses on probes, they are not documented here. +Other parameters can be edited via this call. As this guide focuses on probes, they are not documented here. -#### Available comparison types. +#### Available comparators -Four comparison types are available to confirm a probe’s results: +Four comparators are available to validate the result of a probe : -|Comparison type|Description| +|Comparator|Description| |---|---| -|default|Launches a basic test, without any settings.| -|status|A list of valid HTTP response codes, separated by commas.| -|contains|Checks that the pattern can be found in the response.| -|matches|Checks that the response corresponds to a regular expression pattern.| +|default|Runs a basic test, without parameters.| +|status|Comma-separated list of valid HTTP return codes.| +|contains|Checks that the pattern is in the response.| +|matches|Checks that the response matches the pattern regular expression.| -‘Contains’ and ‘matches’ comparison types find a correspondence in the first 16 KB of the response. If the response is longer than 16 KB, whatever comes afterwards will be ignored during the test. Please note that to optimise your performance, we recommend returning as little information as possible in your probes. +The `contains` and `matches` comparators look for a match in the first 16 KB of the response. If it is longer, the part beyond will be ignored during the search. Note that for better performance, we recommend returning as little information as possible in your probes. -#### Available probes. +#### Available probes -You can get a list of the available probes using the following API call: +The list of available probes can be obtained with the API call : > [!faq] > -> Service: +> Service : > >> > [!api] >> > @@ -277,56 +304,56 @@ You can get a list of the available probes using the following API call: >> > >> > -> Response: +> Response : > >> > **type** >> > ->> >> The type of `probe` to configure in the `probe.type` of `farms`. +>> >> The type of `probe` to configure in the `probe.type` field of the `farms`. >> >> ->> >> The probe types managed are: +>> >> The probe types handled are : >> >> ->> >> `tcp` for a basic TCP connection test. +>> >> `tcp` for a basic TCP connection test ; >> >> ->> >> `http` for a HTTP connection test. You can specify the URL and the method. +>> >> `http` for an HTTP connection test. It is possible to specify the URL and method ; >> >> ->> >> `smtp` for a basic SMTP connection test. +>> >> `smtp` for a basic SMTP connection test ; >> >> ->> >> `mysql` for a basic MySQL connection test. +>> >> `mysql` for a basic MySQL connection test ; >> >> ->> >> `pgsql` for a basic PostgreSQL connection test. +>> >> `pgslq` for a basic PostgreSQL connection test ; >> >> ->> >> `oco` for a confirmation of the general status returned on port 79. +>> >> `oco` for a general status validation returned on port 79. >> > >> > **port** >> > ->> >> This defines whether the port can be configured for this probe. +>> >> Indicates whether the port can be configured for this probe. >> > >> > **method** >> > ->> >> The list of HTTP methods managed, or `null` if none are managed. +>> >> The list of HTTP methods handled or `null` if none exist. >> > >> > **url** >> > ->> >> This defines if the probe’s URL can be configured. +>> >> Indicates whether the probe URL can be configured. >> > >> > **matches** >> > ->> >> The list of comparison types available for this probe. +>> >> The list of available comparators for this probe. >> >> The interpretation of the `probe.pattern` field depends on this field. ->> >> The comparison types potentially managed are: +>> >> The potentially handled comparators are : >> >> ->> >> `default`. The most simple test, without any particular conditions.`probe.pattern` must be empty. +>> >> `default` the simplest test, without specific conditions. `probe.pattern` must be empty ; >> >> ->> >> `status`. Checks if the HTTP status code is in the list separated by commas. +>> >> `status` checks that the HTTP status code is in the comma-separated list ; >> >> ->> >> `contains`. Checks that the server response contains `probe.pattern`. +>> >> `contains` checks that the server response contains `probe.pattern` ; >> >> ->> >> `matches`. Checks that the server response matches `probe.pattern`. +>> >> `matches` checks that the server response matches `probe.pattern`. > -##### TCP +##### **TCP** -This probe attempts to establish a TCP connection to the server. If the server sends a “banner”, you can check if it matches a schema. The default test simply ensures that the connection can be established. +This probe attempts to establish a TCP connection with the server. If the latter sends a "banner", it is possible to check that it matches a pattern. The default test simply ensures that the connection can be established. |Fields|Description| |---|---| @@ -336,29 +363,29 @@ This probe attempts to establish a TCP connection to the server. If the server s |URL|Not supported| |matches|`default`, `contains` or `matches`| -##### HTTP +##### **HTTP** -This probe attempts to establish a HTTP connection to the server. If the server responds, you can check its HTTP status code, and that the response body matches a schema. The default test sends an OPTIONS request to the '/' page in HTTP/1.0, without a Host field. +This probe attempts to establish an HTTP connection with the server. If the latter responds, it is possible to check its HTTP status code or that the response body matches a pattern. The default test sends an OPTIONS request to the '/' page in HTTP/1.0, without the Host field. |Fields|Description| |---|---| |type|`http`| |port|Configurable| |method|`GET`, `HEAD` or `OPTIONS`| -|URL|URL in the form: \[\[https?://]www.example.com]/path/to/check| +|URL|URL of the form [[https?://]www.example.com]/path/to/check| |matches|`default`, `contains` or `matches`| -If the URL is specified, the domain name and protocol are operational. If a domain name is specified, the “Host” field of the request will be filled in, and the request will be sent to HTTP/1.1. If the protocol is specified, it must be consistent with the farm’s SSL configuration. +If a URL is specified, the domain name and protocol are operational. If a domain name is specified, the "Host" field of the request will be filled in and the request will be sent in HTTP/1.1. If the protocol is specified, it must be consistent with the SSL configuration of the farm. > [!primary] > -> We recommend configuring the method, at least, with GET. -> Some servers, including NGINX, do not manage the OPTIONS method without it being configured in advance. +> It is recommended to configure at least the method with GET. +> Indeed, some servers -including Nginx- do not handle the OPTIONS method without prior configuration. > -##### SMTP +##### **SMTP** -This probe attempts to establish an SMTP connection with the server, and sends the command "HELLO localhost". If the server responds, the probe checks that the response code starts with a ‘2’ (success). This probe does not have any specific configuration options. +This probe attempts to establish an SMTP connection with the server and sends the "HELLO localhost" command. If the latter responds, the probe checks that the return code starts with a "2" (success). This probe has no specific configuration options. |Fields|Description| |---|---| @@ -368,9 +395,9 @@ This probe attempts to establish an SMTP connection with the server, and sends t |URL|Not supported| |matches|`default`| -##### MySQL +##### **MySQL** -This probe attempts to establish a MySQL connection with the server, and analyses the server’s response. This probe does not have any specific configuration options. +This probe attempts to establish a MySQL connection with the server and analyses the server's response. This probe has no specific configuration options. |Fields|Description| |---|---| @@ -380,9 +407,9 @@ This probe attempts to establish a MySQL connection with the server, and analyse |URL|Not supported| |matches|`default`| -##### PostgreSQL +##### **PostgreSQL** -This probe attempts to establish a PostgreSQL connection with the server, and analyses the server’s response. This probe does not have any specific configuration options. +This probe attempts to establish a PostgreSQL connection with the server and analyses the server's response. This probe has no specific configuration options. |Fields|Description| |---|---| @@ -392,9 +419,9 @@ This probe attempts to establish a PostgreSQL connection with the server, and an |URL|Not supported| |matches|`default`| -##### oco +##### **oco** -This probe attempts to establish a TCP connection on port 79 of your server, and checks that the response starts with a ‘2’ (success). This probe does not have any specific configuration options. +This probe attempts to establish a TCP connection on port 79 of your server and checks that the response starts with a "2" (success). This probe has no specific configuration options. |Fields|Description| |---|---| @@ -404,20 +431,24 @@ This probe attempts to establish a TCP connection on port 79 of your server, and |URL|Not supported| |matches|`default`| -## Via the OVH Control Panel. +### From the OVHcloud Control Panel -You can configure probes when you add (or modify) a server farm, in advanced settings. +You can configure probes when you add or modify a server farm, in advanced settings. -![Advanced settings for a farm](images/farm_advanced_settings.png){.thumbnail} +![Advanced farm settings](images/farm_advanced_settings.png){.thumbnail} -This is how you access the probe type’s configuration. +You will then have access to the configuration for the probe type. ![Probe settings](images/farm_advanced_settings_unfolded.png){.thumbnail} -If you are able to do so with the probe type you have selected, you can configure specific advanced settings for the probe. +If the probe type you have selected allows it, you can configure advanced settings that are specific to that probe. -![Advanced settings for a probe](images/probe_settings.png){.thumbnail} +![Advanced probe settings](images/probe_settings.png){.thumbnail} A new configuration window will appear, with the probe’s settings. -![Advanced settings for a probe](images/probe_settings_dialog.png){.thumbnail} +![Advanced probe settings](images/probe_settings_dialog.png){.thumbnail} + +## Go further + +Join our [community of users](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_probes/guide.fr-ca.md b/pages/network/load_balancer/create_probes/guide.fr-ca.md index cd48aa0bb0b..9a553f4fae5 100644 --- a/pages/network/load_balancer/create_probes/guide.fr-ca.md +++ b/pages/network/load_balancer/create_probes/guide.fr-ca.md @@ -1,43 +1,67 @@ --- -title: Travailler avec les sondes -excerpt: Découvrez les principes généraux et des cas d'usage pour les sondes -updated: 2019-02-12 +title: "Configuration des sondes sur un service OVHcloud Load Balancer" +excerpt: "Découvrez les principes généraux et des cas d'usage pour les sondes" +updated: 2025-11-12 --- -## Objectif + -L'OVH Load Balancer permet de répartir le trafic entrant sur un front-end vers un ensemble de serveurs d'une ferme de destination. +## Objectif -Il peut arriver que l'un des serveurs de votre ferme ne soit plus disponible pour différentes raisons, comme une surcharge, un incident ou une maintenance planifiée. Lorsqu'il rencontre une erreur de connexion, votre OVH Load Balancer va tenter de basculer le trafic sur un autre serveur. La connexion sera ralentie, mais continuera de fonctionner. +L'OVHcloud Load Balancer permet de répartir le trafic entrant sur un frontend vers un ensemble de serveurs d'une ferme de destination. -Cependant, les causes de certaines indisponibilités sont plus subtiles. Par exemple, si une nouvelle version du code est en cours de déploiement, l'application peut se trouver momentanément dans un état transitoire et retourner des erreurs 500. Dans ce cas précis, une solution serait de marquer les serveurs concernés comme indisponibles dans l'API avant le début de la maintenance, appliquer la configuration et la mise à jour, puis marquer à nouveau le serveur comme disponible. Cette méthode n'est pas idéale mais fonctionne. Pour plus de détail sur le déploiement d'une architecture Blue-Green avec votre OVH Load Balancer, référez-vous à la documentation suivante : . +Il peut arriver que l'un des serveurs de votre ferme ne soit plus disponible pour diverses raisons, telles qu'une surcharge, un incident ou une maintenance planifiée. Lorsqu'il rencontre une erreur de connexion, votre OVHcloud Load Balancer tente de basculer le trafic sur un autre serveur. La connexion sera ralentie, mais continuera de fonctionner. -Les sondes (probes en anglais) sont des tests de santé. Elles interrogent périodiquement chacun de vos serveurs pour s'assurer qu'ils sont opérationnels. Si une erreur est détectée, le serveur est automatiquement désactivé jusqu'à ce que la situation soit rétablie. +Cependant, les causes de certaines indisponibilités sont plus subtiles. Par exemple, si une nouvelle version du code est en cours de déploiement, l'application peut se trouver momentanément dans un état transitoire et retourner des erreurs 500. Dans ce cas précis, une solution consisterait à marquer les serveurs concernés comme indisponibles dans l'API avant le début de la maintenance, appliquer la configuration et la mise à jour, puis marquer à nouveau le serveur comme disponible. Cette méthode n'est pas idéale, mais elle fonctionne.
+Pour plus de détails sur le déploiement d'une architecture Blue-Green avec votre OVHcloud Load Balancer, référez-vous à [ce guide](/pages/network/load_balancer/case_blue_green). -Ce service étant encore jeune, l'essentiel de ses fonctionnalités est uniquement disponible dans l'API. +Les sondes (*probes* en anglais) sont des tests de santé. Elles interrogent périodiquement chacun de vos serveurs pour s'assurer qu'ils sont opérationnels. Si une erreur est détectée, le serveur est automatiquement désactivé jusqu'à ce que la situation soit rétablie. -**Ce guide vous présentera les principes généraux, ainsi que des scénarios d'utilisation des sondes tirés de cas d'usages réels.** +**Ce guide vous présente les principes généraux des sondes, ainsi que des scénarios d'utilisation inspirés de cas d'usage réels.** ## Prérequis -- Disposer d'un OVH Load Balancer correctement configuré, avec un paramétrage des fermes et des serveurs. +- Posséder une offre [OVHcloud Load balancer](/links/network/load-balancer) dans votre compte OVHcloud. Le service doit être correctement configuré, avec un paramétrage des fermes et des serveurs. +- Être connecté à votre [espace client OVHcloud](/links/manager). ## En pratique -### Présentation de l'API +## Sommaire + +- [Présentation de l'API des sondes](#probe-api) +- [Exemples](#examples) +- [Référence](#reference) +- [Depuis l'espace client OVHcloud](#manager) + +### Présentation de l'API des sondes -L'API des sondes de votre OVH Load Balancer a été pensée pour être souple et évolutive. +L'API des sondes de votre service OVHcloud Load Balancer a été conçue pour être souple et évolutive. -Les sondes se configurent directement sur les fermes. Tous les serveurs d'une même ferme appliquent ainsi exactement la même sonde. Cependant, l'activation ou la désactivation d'une sonde est spécifique à chaque serveur : il est donc possible de ne « surveiller » que certains serveurs d'une même ferme. +Les sondes se configurent directement sur les fermes. Tous les serveurs d'une même ferme appliquent ainsi exactement la même sonde. Cependant, l'activation ou la désactivation d'une sonde est spécifique à chaque serveur. Il est donc possible de ne « surveiller » que certains serveurs d'une même ferme. -La liste des sondes disponibles et de leurs paramètres peut être consultée avec l'appel d'API : +La liste des sondes disponibles et de leurs paramètres peut être consultée avec l'appel API suivant : > [!api] > > @api {v1} /ipLoadbalancing GET /ipLoadbalancing/{serviceName}/availableFarmProbes > -Pour plus d'informations sur cet appel, nous vous invitons à consulter la section *Sondes disponibles* en bas de ce guide. +Pour plus d'informations sur cet appel, nous vous invitons à consulter la section [Sondes disponibles](#available-probes) en bas de ce guide. Les sondes retournées par cette liste peuvent être configurées sur les fermes `http` et `tcp` via les appels : @@ -61,9 +85,9 @@ Les sondes retournées par cette liste peuvent être configurées sur les fermes > @api {v1} /ipLoadbalancing PUT /ipLoadbalancing/{serviceName}/tcp/farm/{farmId} > -Pour plus d'informations sur ces appels, vous pouvez consulter la section *Manipulation des sondes* en bas de ce guide. +Pour plus d'informations sur ces appels, vous pouvez consulter la section [Manipulation des sondes](#handling-probes) de ce guide. -### Exemples +### Exemples #### Vérifier si le serveur accepte des connexions TCP @@ -73,43 +97,45 @@ Dans la pratique, cela donne une sonde : |Champ|Valeur et description| |---|---| -|serviceName|Identifiant de votre OVH Load Balancer| +|serviceName|Identifiant de votre OVHcloud Load Balancer| |farmId|Identifiant de votre ferme TCP ou HTTP| |probe.type|"tcp"| -Tous les autres champs probe peuvent rester à leur valeur par défaut. Il ne reste ensuite qu'à appliquer la configuration dans la zone concernée et le tour est joué. +Tous les autres champs `probe` peuvent rester à leur valeur par défaut. Il ne reste ensuite qu'à appliquer la configuration dans la zone concernée. #### Tester une page HTTP spécifique -Par défaut, la `sonde` HTTP envoie une requête "OPTIONS" sur "/" en HTTP/1.0, sans nom de domaine. Cela suffit dans beaucoup de cas, mais certains serveurs ne gèrent pas cette méthode. Et il est possible de faire des tests beaucoup plus puissants avec la sonde HTTP. Par exemple, une bonne pratique lors de l'exposition d'un service HTTP consiste à ajouter une route dédiée aux sondes. Il est courant de retrouver des "/status", "/health", "/check" qui renvoient une synthèse de l'état du service. +Par défaut, la sonde HTTP envoie une requête `OPTIONS` sur `/` en HTTP/1.0, sans nom de domaine. Cela suffit dans beaucoup de cas, mais certains serveurs ne gèrent pas cette méthode.
+Il est possible de réaliser des tests beaucoup plus puissants avec la sonde HTTP. Par exemple, une bonne pratique lors de l'exposition d'un service HTTP consiste à ajouter une route dédiée aux sondes. Il est courant de retrouver des `/status`, `/health`, `/check` qui renvoient une synthèse de l'état du service. -Dans la pratique, si vous voulez configurer la sonde pour envoyer une requête "GET" sur [http://api.example.com/status](http://api.example.com/status), cela donne : +Dans la pratique, si vous voulez configurer la sonde pour envoyer une requête `GET` sur [http://api.example.com/status](http://api.example.com/status), cela donne : |Champ|Valeur et description| |---|---| -|serviceName|Identifiant de votre OVH Load Balancer| +|serviceName|Identifiant de votre OVHcloud Load Balancer| |farmId|Identifiant de votre ferme TCP ou HTTP| |probe.type|http| |probe.method|GET| |probe.url|[http://api.example.com/status](http://api.example.com/status)| |probe.match|status| -|probe.pattern|200 (Plusieurs codes d'état peuvent être ajoutés, en les séparant par des virgules)| +|probe.pattern|200 (plusieurs codes d'état peuvent être ajoutés, en les séparant par des virgules)| -Tous les autres champs probe peuvent rester à leur valeur par défaut. Il suffit ensuite d'appliquer la configuration dans la zone concernée. +Tous les autres champs `probe` peuvent rester à leur valeur par défaut. Il suffit ensuite d'appliquer la configuration dans la zone concernée. #### Utiliser un test HTTP externe -Que se passe-t-il si votre service est, par exemple, un serveur IMAP qui repose sur un serveur LDAP pour l'authentification ? Il est possible que le serveur accepte des connexions mais qu'il ait un souci temporaire de connexion avec le serveur LDAP. Si cela arrive, les clients qui seraient dirigés vers ce serveur pourraient se connecter mais pas s'authentifier. Le serveur devrait donc être retiré de la ferme. +Que se passe-t-il si votre service est, par exemple, un serveur IMAP qui repose sur un serveur LDAP pour l'authentification ?
+Il est possible que le serveur accepte des connexions, mais qu'il ait un souci temporaire de connexion avec le serveur LDAP. Si cela arrive, les clients qui seraient dirigés vers ce serveur pourraient se connecter mais pas s'authentifier. Le serveur devrait donc être retiré de la ferme. Si une sonde de type `tcp` est utilisée, elle arrivera à se connecter et considérera que le service est disponible bien que ce ne soit pas le cas. Dans ce scénario, l'idéal serait que le test de santé puisse confirmer que le service de base fonctionne. Il est possible d'indiquer un port spécifique à utiliser dans les tests. Cela permet de mettre en place des tests arbitraires pour un service et les exposer en HTTP, sur un port dédié. -Par exemple, dans ce scénario, il serait possible d'avoir un serveur HTTP sur le port 8080 qui teste le serveur IMAP via l'url "/service/imap/status" et retourne *OK* lorsque tout va bien. Ce qui donnerait dans la pratique : +Par exemple, dans ce scénario, il serait possible d'avoir un serveur HTTP sur le port 8080 qui teste le serveur IMAP via l'url `/service/imap/status` et retourne *OK* lorsque tout va bien. Ce qui donnerait dans la pratique : |Champ|Valeur et description| |---|---| -|serviceName|Identifiant de votre OVH Load Balancer| +|serviceName|Identifiant de votre OVHcloud Load Balancer| |farmId|Identifiant de votre ferme TCP ou HTTP| |probe.type|http| |probe.port|8080| @@ -118,18 +144,18 @@ Par exemple, dans ce scénario, il serait possible d'avoir un serveur HTTP sur l |probe.match|contains| |probe.pattern|OK| -Il ne reste ensuite qu'à appliquer la configuration dans la zone concernée et le tour est joué. +Il ne reste ensuite qu'à appliquer la configuration dans la zone concernée. > [!warning] > > Si le service HTTP dédié à la surveillance de votre service IMAP tombe lui-même en panne, le service IMAP sera considéré comme en panne lui aussi, même s'il est en parfait état de fonctionnement. > -### Référence +### Référence -#### Manipulation des sondes +#### Manipulation des sondes -##### Configurer une sonde +##### **Configurer une sonde** Les sondes peuvent être configurées sur une nouvelle ferme (`POST`) ou une ferme existante (`PUT`). Les deux méthodes étant équivalentes, seule la seconde (`PUT`) sera présentée ici. @@ -147,7 +173,7 @@ Les sondes peuvent être configurées sur une nouvelle ferme (`POST`) ou une fer > >> > **serviceName** >> > ->> >> L'identifiant de votre OVH Load Balancer. +>> >> L'identifiant de votre OVHcloud Load Balancer. >> > >> > **farmId** >> > @@ -203,20 +229,21 @@ Les sondes peuvent être configurées sur une nouvelle ferme (`POST`) ou une fer >> > >> >> **forceSsl** >> >> ->> >> > Cela définit si la sonde doit fonctionner en SSL/TLS même si la ferme est configurée pour se connecter en TCP classique. ->> >> > Cela peut servir par exemple lorsque votre OVH Load Balancer est configuré pour faire suivre le trafic HTTPS en TCP sans le déchiffrer. +>> >> > Définit si la sonde doit fonctionner en SSL/TLS même si la ferme est configurée pour se connecter en TCP classique. +>> >> > Ceci peut être utile, par exemple, lorsque votre OVHcloud Load Balancer est configuré pour faire suivre le trafic HTTPS en TCP sans le déchiffrer. > D'autres paramètres peuvent être édités via cet appel. Dans la mesure où ce guide se concentre sur les sondes, ils ne sont pas documentés ici. -Si un port autre que le port de base de la ferme est configuré sur la sonde, les paramètres `proxyprotocol` et `ssl` sont réinitialisés. Prenons l'exemple d'une ferme configurée pour utiliser le `proxyprotocol` sur le *port* **4242** et d'une sonde associée employant le *port* **8080** : cette dernière n'enverra pas l'entête `proxyprotocol` lorsqu'elle se connectera sur le *port* **8080**. Il en est de même pour le `ssl`, qui peut néanmoins être forcé. +Si un port autre que le port de base de la ferme est configuré sur la sonde, les paramètres `proxyprotocol` et `ssl` sont réinitialisés. Prenons l'exemple d'une ferme configurée pour utiliser le `proxyprotocol` sur le *port* **4242** et d'une sonde associée employant le *port* **8080** : cette dernière n'enverra pas l'en-tête `proxyprotocol` lorsqu'elle se connectera sur le *port* **8080**. Il en est de même pour le `ssl`, qui peut néanmoins être forcé. > [!warning] > -> Lorsqu'une sonde est configurée sur une ferme, elle doit être activée sur les serveurs. +> Lorsqu'une sonde est configurée sur une ferme, elle doit également être activée sur les serveurs. > -##### Activer les sondes sur un serveur +##### **Activer les sondes sur un serveur** + Pour qu'une sonde soit active, il faut qu'elle ait été configurée sur la ferme et activée sur les serveurs concernés. Cet appel permet d'activer la prise en compte de la sonde : > [!faq] @@ -233,7 +260,7 @@ Pour qu'une sonde soit active, il faut qu'elle ait été configurée sur la ferm > >> > **serviceName** >> > ->> >> L'identifiant de votre OVH Load Balancer. +>> >> L'identifiant de votre OVHcloud Load Balancer. >> > >> > **farmId** >> > @@ -245,7 +272,7 @@ Pour qu'une sonde soit active, il faut qu'elle ait été configurée sur la ferm >> > >> > **probe** >> > ->> >> Si les `probe` doivent être prises en compte ou non. +>> >> Indique si les `probe` doivent être prises en compte ou non. > D'autres paramètres peuvent être édités via cet appel. Dans la mesure où ce guide se concentre sur les sondes, ils ne sont pas documentés ici. @@ -257,13 +284,13 @@ Quatre comparateurs sont disponibles pour valider le résultat d'une sonde : |Comparateur|Description| |---|---| |default|Lance un test de base, sans paramètre.| -|status|Liste séparée par des virgules de code de retour HTTP valides.| +|status|Liste de codes de retour HTTP valides, séparés par des virgules.| |contains|Vérifie que le pattern se trouve dans la réponse.| -|matches|Vérifie que la réponse correspond à l'expression régulière pattern.| +|matches|Vérifie que la réponse correspond à l'expression régulière du pattern.| -Les comparateurs contains et matches cherchent une correspondance dans les 16 premiers ko de la réponse. Si celle-ci est plus longue, la partie au-delà sera ignorée lors de la recherche. Notez que pour de meilleures performances, nous vous recommandons de retourner le moins d'informations possible dans vos sondes. +Les comparateurs `contains` et `matches` cherchent une correspondance dans les 16 premiers ko de la réponse. Si celle-ci est plus longue, la partie au-delà sera ignorée lors de la recherche. Notez que pour de meilleures performances, nous vous recommandons de retourner le moins d'informations possible dans vos sondes. -#### Sondes disponibles +#### Sondes disponibles La liste des sondes disponibles peut être obtenue avec l'appel API : @@ -299,15 +326,15 @@ La liste des sondes disponibles peut être obtenue avec l'appel API : >> > >> > **port** >> > ->> >> Cela définit si le port peut être configuré pour cette sonde. +>> >> Indique si le port peut être configuré pour cette sonde. >> > >> > **method** >> > ->> >> La liste de méthodes HTTP gérées ou `null` s'il n'en existe aucune. +>> >> La liste des méthodes HTTP gérées ou `null` s'il n'en existe aucune. >> > >> > **url** >> > ->> >> Cela définit si l'URL de la sonde peut être configurée. +>> >> Indique si l'URL de la sonde peut être configurée. >> > >> > **matches** >> > @@ -324,7 +351,7 @@ La liste des sondes disponibles peut être obtenue avec l'appel API : >> >> `matches` vérifie que la réponse du serveur correspond à `probe.pattern`. > -##### TCP +##### **TCP** Cette sonde tente d'établir une connexion TCP avec le serveur. Si ce dernier envoie une « bannière », il est possible de vérifier qu'elle correspond à un schéma. Le test par défaut s'assure simplement que la connexion peut être établie. @@ -336,7 +363,7 @@ Cette sonde tente d'établir une connexion TCP avec le serveur. Si ce dernier en |URL|Non supporté| |matches|`default`, `contains` ou `matches`| -##### HTTP +##### **HTTP** Cette sonde tente d'établir une connexion HTTP avec le serveur. Si ce dernier répond, il est possible de vérifier son code d'état HTTP ou que le corps de la réponse correspond à un schéma. Le test par défaut envoie une requête OPTIONS sur la page '/' en HTTP/1.0, sans champ Host. @@ -348,7 +375,7 @@ Cette sonde tente d'établir une connexion HTTP avec le serveur. Si ce dernier r |URL|URL de la forme [[https?://]www.example.com]/path/to/check| |matches|`default`, `contains` ou `matches`| -Si une URL est spécifiée, le nom de domaine et le protocole sont opérationels. Si un nom de domaine est spécifié, le champ "Host" de la requête sera renseigné et la requête sera envoyée en HTTP/1.1. Si le protocole est spécifié, il doit être cohérent avec la configuration SSL de la ferme. +Si une URL est spécifiée, le nom de domaine et le protocole sont opérationnels. Si un nom de domaine est spécifié, le champ "Host" de la requête sera renseigné et la requête sera envoyée en HTTP/1.1. Si le protocole est spécifié, il doit être cohérent avec la configuration SSL de la ferme. > [!primary] > @@ -356,7 +383,7 @@ Si une URL est spécifiée, le nom de domaine et le protocole sont opérationels > En effet, certains serveurs -dont Nginx- ne gèrent pas la méthode OPTIONS sans configuration préalable. > -##### SMTP +##### **SMTP** Cette sonde tente d'établir une connexion SMTP avec le serveur et envoie la commande "HELLO localhost". Si ce dernier répond, la sonde vérifie que le code de retour commence par un "2" (succès). Cette sonde n'a pas d'options de configuration particulières. @@ -368,7 +395,7 @@ Cette sonde tente d'établir une connexion SMTP avec le serveur et envoie la com |URL|Non supporté| |matches|`default`| -##### MySQL +##### **MySQL** Cette sonde tente d'établir une connexion MySQL avec le serveur et analyse la réponse du serveur. Cette sonde n'a pas d'options de configuration particulières. @@ -380,7 +407,7 @@ Cette sonde tente d'établir une connexion MySQL avec le serveur et analyse la r |URL|Non supporté| |matches|`default`| -##### PostgreSQL +##### **PostgreSQL** Cette sonde tente d'établir une connexion PostgreSQL avec le serveur et analyse la réponse du serveur. Cette sonde n'a pas d'options de configuration particulières. @@ -392,7 +419,7 @@ Cette sonde tente d'établir une connexion PostgreSQL avec le serveur et analyse |URL|Non supporté| |matches|`default`| -##### oco +##### **oco** Cette sonde tente d'établir une connexion TCP sur le port 79 de votre serveur et vérifie que la réponse commence par un "2" (succès). Cette sonde n'a pas d'options de configuration particulières. @@ -404,9 +431,9 @@ Cette sonde tente d'établir une connexion TCP sur le port 79 de votre serveur e |URL|Non supporté| |matches|`default`| -## Depuis le manager +### Depuis l'espace client OVHcloud -La configuration des sondes se fait lors de l'ajout (ou modification) d'une ferme de serveurs, dans les paramètres avancés. +La configuration des sondes se fait lors de l'ajout ou de la modification d'une ferme de serveurs, dans les paramètres avancés. ![Paramètres avancés d'une ferme](images/farm_advanced_settings.png){.thumbnail} @@ -414,10 +441,14 @@ Vous avez alors accès à la configuration du type de sonde. ![Paramètres d'une sonde](images/farm_advanced_settings_unfolded.png){.thumbnail} -Si le type de sonde séléctionné le permet, vous pouvez configurer les paramètres avancés spécifiques à cette sonde. +Si le type de sonde sélectionné le permet, vous pouvez configurer les paramètres avancés spécifiques à cette sonde. ![Paramètres avancés d'une sonde](images/probe_settings.png){.thumbnail} Une nouvelle fenêtre de configuration apparaît avec les paramètres de la sonde. ![Paramètres avancés d'une sonde](images/probe_settings_dialog.png){.thumbnail} + +## Aller plus loin + +Échangez avec notre [communauté d'utilisateurs](/links/community). \ No newline at end of file diff --git a/pages/network/load_balancer/create_probes/guide.fr-fr.md b/pages/network/load_balancer/create_probes/guide.fr-fr.md index 0dda6298009..0a79894d0a0 100644 --- a/pages/network/load_balancer/create_probes/guide.fr-fr.md +++ b/pages/network/load_balancer/create_probes/guide.fr-fr.md @@ -1,23 +1,38 @@ --- title: "Configuration des sondes sur un service OVHcloud Load Balancer" excerpt: "Découvrez les principes généraux et des cas d'usage pour les sondes" -updated: 2022-03-25 +updated: 2025-11-12 --- + + ## Objectif L'OVHcloud Load Balancer permet de répartir le trafic entrant sur un frontend vers un ensemble de serveurs d'une ferme de destination. -Il peut arriver que l'un des serveurs de votre ferme ne soit plus disponible pour différentes raisons, comme une surcharge, un incident ou une maintenance planifiée. Lorsqu'il rencontre une erreur de connexion, votre OVHcloud Load Balancer va tenter de basculer le trafic sur un autre serveur. La connexion sera ralentie, mais continuera de fonctionner. +Il peut arriver que l'un des serveurs de votre ferme ne soit plus disponible pour diverses raisons, telles qu'une surcharge, un incident ou une maintenance planifiée. Lorsqu'il rencontre une erreur de connexion, votre OVHcloud Load Balancer tente de basculer le trafic sur un autre serveur. La connexion sera ralentie, mais continuera de fonctionner. -Cependant, les causes de certaines indisponibilités sont plus subtiles. Par exemple, si une nouvelle version du code est en cours de déploiement, l'application peut se trouver momentanément dans un état transitoire et retourner des erreurs 500. Dans ce cas précis, une solution serait de marquer les serveurs concernés comme indisponibles dans l'API avant le début de la maintenance, appliquer la configuration et la mise à jour, puis marquer à nouveau le serveur comme disponible. Cette méthode n'est pas idéale mais fonctionne.
+Cependant, les causes de certaines indisponibilités sont plus subtiles. Par exemple, si une nouvelle version du code est en cours de déploiement, l'application peut se trouver momentanément dans un état transitoire et retourner des erreurs 500. Dans ce cas précis, une solution consisterait à marquer les serveurs concernés comme indisponibles dans l'API avant le début de la maintenance, appliquer la configuration et la mise à jour, puis marquer à nouveau le serveur comme disponible. Cette méthode n'est pas idéale, mais elle fonctionne.
Pour plus de détails sur le déploiement d'une architecture Blue-Green avec votre OVHcloud Load Balancer, référez-vous à [ce guide](/pages/network/load_balancer/case_blue_green). Les sondes (*probes* en anglais) sont des tests de santé. Elles interrogent périodiquement chacun de vos serveurs pour s'assurer qu'ils sont opérationnels. Si une erreur est détectée, le serveur est automatiquement désactivé jusqu'à ce que la situation soit rétablie. -Ce service étant encore jeune, l'essentiel de ses fonctionnalités est uniquement disponible dans l'API. - -**Ce guide vous présentera les principes généraux, ainsi que des scénarios d'utilisation des sondes, tirés de cas d'usages réels.** +**Ce guide vous présente les principes généraux des sondes, ainsi que des scénarios d'utilisation inspirés de cas d'usage réels.** ## Prérequis @@ -26,13 +41,20 @@ Ce service étant encore jeune, l'essentiel de ses fonctionnalités est uniqueme ## En pratique -### Présentation de l'API des sondes +## Sommaire + +- [Présentation de l'API des sondes](#probe-api) +- [Exemples](#examples) +- [Référence](#reference) +- [Depuis l'espace client OVHcloud](#manager) + +### Présentation de l'API des sondes -L'API des sondes de votre OVHcloud Load Balancer a été pensée pour être souple et évolutive. +L'API des sondes de votre service OVHcloud Load Balancer a été conçue pour être souple et évolutive. Les sondes se configurent directement sur les fermes. Tous les serveurs d'une même ferme appliquent ainsi exactement la même sonde. Cependant, l'activation ou la désactivation d'une sonde est spécifique à chaque serveur. Il est donc possible de ne « surveiller » que certains serveurs d'une même ferme. -La liste des sondes disponibles et de leurs paramètres peut être consultée avec l'appel d'API : +La liste des sondes disponibles et de leurs paramètres peut être consultée avec l'appel API suivant : > [!api] > @@ -65,7 +87,7 @@ Les sondes retournées par cette liste peuvent être configurées sur les fermes Pour plus d'informations sur ces appels, vous pouvez consulter la section [Manipulation des sondes](#handling-probes) de ce guide. -### Exemples +### Exemples #### Vérifier si le serveur accepte des connexions TCP @@ -79,12 +101,12 @@ Dans la pratique, cela donne une sonde : |farmId|Identifiant de votre ferme TCP ou HTTP| |probe.type|"tcp"| -Tous les autres champs probe peuvent rester à leur valeur par défaut. Il ne reste ensuite qu'à appliquer la configuration dans la zone concernée. +Tous les autres champs `probe` peuvent rester à leur valeur par défaut. Il ne reste ensuite qu'à appliquer la configuration dans la zone concernée. #### Tester une page HTTP spécifique Par défaut, la sonde HTTP envoie une requête `OPTIONS` sur `/` en HTTP/1.0, sans nom de domaine. Cela suffit dans beaucoup de cas, mais certains serveurs ne gèrent pas cette méthode.
-Il est possible de faire des tests beaucoup plus puissants avec la sonde HTTP. Par exemple, une bonne pratique lors de l'exposition d'un service HTTP consiste à ajouter une route dédiée aux sondes. Il est courant de retrouver des `/status`, `/health`, `/check` qui renvoient une synthèse de l'état du service. +Il est possible de réaliser des tests beaucoup plus puissants avec la sonde HTTP. Par exemple, une bonne pratique lors de l'exposition d'un service HTTP consiste à ajouter une route dédiée aux sondes. Il est courant de retrouver des `/status`, `/health`, `/check` qui renvoient une synthèse de l'état du service. Dans la pratique, si vous voulez configurer la sonde pour envoyer une requête `GET` sur [http://api.example.com/status](http://api.example.com/status), cela donne : @@ -98,12 +120,12 @@ Dans la pratique, si vous voulez configurer la sonde pour envoyer une requête ` |probe.match|status| |probe.pattern|200 (plusieurs codes d'état peuvent être ajoutés, en les séparant par des virgules)| -Tous les autres champs probe peuvent rester à leur valeur par défaut. Il suffit ensuite d'appliquer la configuration dans la zone concernée. +Tous les autres champs `probe` peuvent rester à leur valeur par défaut. Il suffit ensuite d'appliquer la configuration dans la zone concernée. #### Utiliser un test HTTP externe Que se passe-t-il si votre service est, par exemple, un serveur IMAP qui repose sur un serveur LDAP pour l'authentification ?
-Il est possible que le serveur accepte des connexions mais qu'il ait un souci temporaire de connexion avec le serveur LDAP. Si cela arrive, les clients qui seraient dirigés vers ce serveur pourraient se connecter mais pas s'authentifier. Le serveur devrait donc être retiré de la ferme. +Il est possible que le serveur accepte des connexions, mais qu'il ait un souci temporaire de connexion avec le serveur LDAP. Si cela arrive, les clients qui seraient dirigés vers ce serveur pourraient se connecter mais pas s'authentifier. Le serveur devrait donc être retiré de la ferme. Si une sonde de type `tcp` est utilisée, elle arrivera à se connecter et considérera que le service est disponible bien que ce ne soit pas le cas. @@ -129,7 +151,7 @@ Il ne reste ensuite qu'à appliquer la configuration dans la zone concernée. > Si le service HTTP dédié à la surveillance de votre service IMAP tombe lui-même en panne, le service IMAP sera considéré comme en panne lui aussi, même s'il est en parfait état de fonctionnement. > -### Référence +### Référence #### Manipulation des sondes @@ -207,8 +229,8 @@ Les sondes peuvent être configurées sur une nouvelle ferme (`POST`) ou une fer >> > >> >> **forceSsl** >> >> ->> >> > Cela définit si la sonde doit fonctionner en SSL/TLS même si la ferme est configurée pour se connecter en TCP classique. ->> >> > Cela peut servir par exemple lorsque votre OVHcloud Load Balancer est configuré pour faire suivre le trafic HTTPS en TCP sans le déchiffrer. +>> >> > Définit si la sonde doit fonctionner en SSL/TLS même si la ferme est configurée pour se connecter en TCP classique. +>> >> > Ceci peut être utile, par exemple, lorsque votre OVHcloud Load Balancer est configuré pour faire suivre le trafic HTTPS en TCP sans le déchiffrer. > D'autres paramètres peuvent être édités via cet appel. Dans la mesure où ce guide se concentre sur les sondes, ils ne sont pas documentés ici. @@ -217,7 +239,7 @@ Si un port autre que le port de base de la ferme est configuré sur la sonde, le > [!warning] > -> Lorsqu'une sonde est configurée sur une ferme, elle doit être activée sur les serveurs. +> Lorsqu'une sonde est configurée sur une ferme, elle doit également être activée sur les serveurs. > ##### **Activer les sondes sur un serveur** @@ -250,7 +272,7 @@ Pour qu'une sonde soit active, il faut qu'elle ait été configurée sur la ferm >> > >> > **probe** >> > ->> >> Si les `probe` doivent être prises en compte ou non. +>> >> Indique si les `probe` doivent être prises en compte ou non. > D'autres paramètres peuvent être édités via cet appel. Dans la mesure où ce guide se concentre sur les sondes, ils ne sont pas documentés ici. @@ -262,9 +284,9 @@ Quatre comparateurs sont disponibles pour valider le résultat d'une sonde : |Comparateur|Description| |---|---| |default|Lance un test de base, sans paramètre.| -|status|Liste séparée par des virgules de code de retour HTTP valides.| +|status|Liste de codes de retour HTTP valides, séparés par des virgules.| |contains|Vérifie que le pattern se trouve dans la réponse.| -|matches|Vérifie que la réponse correspond à l'expression régulière pattern.| +|matches|Vérifie que la réponse correspond à l'expression régulière du pattern.| Les comparateurs `contains` et `matches` cherchent une correspondance dans les 16 premiers ko de la réponse. Si celle-ci est plus longue, la partie au-delà sera ignorée lors de la recherche. Notez que pour de meilleures performances, nous vous recommandons de retourner le moins d'informations possible dans vos sondes. @@ -304,15 +326,15 @@ La liste des sondes disponibles peut être obtenue avec l'appel API : >> > >> > **port** >> > ->> >> Cela définit si le port peut être configuré pour cette sonde. +>> >> Indique si le port peut être configuré pour cette sonde. >> > >> > **method** >> > ->> >> La liste de méthodes HTTP gérées ou `null` s'il n'en existe aucune. +>> >> La liste des méthodes HTTP gérées ou `null` s'il n'en existe aucune. >> > >> > **url** >> > ->> >> Cela définit si l'URL de la sonde peut être configurée. +>> >> Indique si l'URL de la sonde peut être configurée. >> > >> > **matches** >> > @@ -353,7 +375,7 @@ Cette sonde tente d'établir une connexion HTTP avec le serveur. Si ce dernier r |URL|URL de la forme [[https?://]www.example.com]/path/to/check| |matches|`default`, `contains` ou `matches`| -Si une URL est spécifiée, le nom de domaine et le protocole sont opérationels. Si un nom de domaine est spécifié, le champ "Host" de la requête sera renseigné et la requête sera envoyée en HTTP/1.1. Si le protocole est spécifié, il doit être cohérent avec la configuration SSL de la ferme. +Si une URL est spécifiée, le nom de domaine et le protocole sont opérationnels. Si un nom de domaine est spécifié, le champ "Host" de la requête sera renseigné et la requête sera envoyée en HTTP/1.1. Si le protocole est spécifié, il doit être cohérent avec la configuration SSL de la ferme. > [!primary] > @@ -409,9 +431,9 @@ Cette sonde tente d'établir une connexion TCP sur le port 79 de votre serveur e |URL|Non supporté| |matches|`default`| -### Depuis l'espace client OVHcloud +### Depuis l'espace client OVHcloud -La configuration des sondes se fait lors de l'ajout (ou modification) d'une ferme de serveurs, dans les paramètres avancés. +La configuration des sondes se fait lors de l'ajout ou de la modification d'une ferme de serveurs, dans les paramètres avancés. ![Paramètres avancés d'une ferme](images/farm_advanced_settings.png){.thumbnail}