Répartiteur de charge : une adresse, plusieurs VM

Une seule machine derrière un nom de domaine, c'est simple jusqu'au jour où il faut la redémarrer pour une mise à jour, ou où la charge dépasse ce qu'elle tient. Un répartiteur de charge prend le trafic sur sa propre adresse et le distribue entre plusieurs machines : on en retire une pour la maintenance, les autres continuent de servir.

Le répartiteur FFxF est un service géré. Vous décrivez où va le trafic, FFxF fait tourner le répartiteur, obtient ses certificats Let's Encrypt et le tient à jour. Ce guide en monte un de bout en bout, avec les sorties réelles d'un répartiteur en service.

1. Comment ça s'articule

• Un pool regroupe les machines qui rendent le même service, chacune avec un port : web pour le site, api pour l'API.
• Un port d'entrée s'ouvre sur l'adresse du répartiteur, en HTTP, HTTPS ou TCP, avec un pool par défaut.
• Des règles envoient un nom de domaine ou un début de chemin vers un autre pool : /api/ vers api, le reste vers web.

Les machines cibles sont dans un réseau privé avec le répartiteur. Elles n'ont pas besoin d'adresse publique, et leurs pare-feux peuvent fermer 80 et 443 côté Internet : le réseau privé n'est jamais filtré.

2. Créer le répartiteur

Dans la console, sous Répartiteurs, donnez un nom et choisissez le réseau privé de vos machines. La même chose par l'API :

curl -s -X POST https://api.ffxf.net/v1/load-balancers \
     -H "Authorization: Bearer $FFXF_TOKEN" \
     -H "Idempotency-Key: $(uuidgen)" \
     -H "Content-Type: application/json" \
     -d '{"name": "pilote", "vpc": 15}'

{"data":{"id":1,"name":"pilote","status":"pending","billing":{"mode":"hourly","rate":"0.010","currency":"CAD"}}}

Le répartiteur se paie à l'heure, 0,010 CAD, soit environ 7,30 CAD pour un mois complet. Il est prêt en quelques minutes : son statut passe de pending à active, et il reçoit une adresse IPv4 et une adresse IPv6. Pools et ports peuvent se préparer pendant ce temps.

3. Un pool et ses cibles

Pour la démonstration, une seule machine du réseau privé, à l'adresse 10.50.0.2, fait tourner trois petits serveurs HTTP sur les ports 8081, 8082 et 8083. En production, ce seraient des machines distinctes ; le répartiteur les traite de la même façon.

curl -s -X POST https://api.ffxf.net/v1/load-balancers/1/pools \
     -H "Authorization: Bearer $FFXF_TOKEN" -H "Content-Type: application/json" \
     -d '{"name": "web", "protocol": "http", "health_type": "http", "health_path": "/"}'

curl -s -X PUT https://api.ffxf.net/v1/load-balancers/1/pools/1/targets \
     -H "Authorization: Bearer $FFXF_TOKEN" -H "Content-Type: application/json" \
     -d '{"targets": [{"vm": 150, "port": 8081}, {"vm": 150, "port": 8082}]}'

Une machine se désigne par son numéro, celui de la console et de l'API. Le répartiteur vérifie chaque cible toutes les 5 secondes, ici par une requête HTTP sur / : trois échecs la sortent du pool, deux succès l'y remettent. Un second pool, api, vise le port 8083.

4. Un port HTTPS et le DNS

curl -s -X POST https://api.ffxf.net/v1/load-balancers/1/listeners \
     -H "Authorization: Bearer $FFXF_TOKEN" -H "Content-Type: application/json" \
     -d '{"port": 443, "protocol": "https", "default_pool": 1, "redirect_https": true}'

Avec redirect_https, le port 80 redirige vers HTTPS. Pour le certificat, faites pointer votre nom vers le répartiteur : un enregistrement A vers son IPv4, un AAAA vers son IPv6. Dès que le nom pointe au bon endroit, le répartiteur demande son certificat à Let's Encrypt ; sur notre démonstration, il était actif une trentaine de secondes après la création du port.

5. Router par chemin

curl -s -X PUT https://api.ffxf.net/v1/load-balancers/1/listeners/1/rules \
     -H "Authorization: Bearer $FFXF_TOKEN" -H "Content-Type: application/json" \
     -d '{"rules": [
           {"hostname": "app.exemple.com", "pool": 1},
           {"hostname": "app.exemple.com", "path_prefix": "/api/", "pool": 2}
         ]}'

Peu importe l'ordre envoyé : le répartiteur évalue les règles de la plus précise à la plus large (nom et chemin, puis nom seul, puis chemin seul), et la première qui correspond l'emporte. L'onglet Routage de la console les affiche dans cet ordre, suivies de la ligne « Sinon », qui mène au pool par défaut.

6. Vérifier

$ for i in 1 2 3 4; do curl -s https://app.exemple.com/; done
pilote 8081
pilote 8082
pilote 8081
pilote 8082
$ curl -s https://app.exemple.com/api/
pilote 8083
$ curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" http://app.exemple.com/
301 https://app.exemple.com/

Les requêtes alternent entre les deux cibles du pool web, le chemin /api/ part vers l'autre pool, et le HTTP est redirigé. Côté application, l'adresse du visiteur arrive dans l'en-tête X-Forwarded-For, avec X-Forwarded-Proto et X-Forwarded-Port.

7. Une maintenance sans coupure

Avant de mettre à jour une machine, cliquez sur Drainer à côté d'elle dans l'onglet Pools (ou envoyez {"drain": true} par l'API). Elle ne reçoit plus de nouvelles connexions, celles en cours vont à leur terme, et le changement est en place en une dizaine de secondes. Une fois la mise à jour faite, Remettre la réintègre.

Une cible qui tombe sans prévenir est retirée par les contrôles de santé, et l'onglet Pools la montre en panne. Si toutes les cibles d'un pool tombent, le répartiteur répond 503 plutôt que de laisser les visiteurs attendre.

8. Qui peut se connecter

Seuls 80, 443 et vos ports d'entrée sont ouverts sur l'adresse du répartiteur. Chaque port accepte des sources autorisées : un port TCP 5432 vers un pool de bases de données peut n'accepter que l'adresse de votre bureau. Tant qu'un port HTTPS existe, le 80 reste ouvert à tous, car Let's Encrypt y valide les certificats.

9. Statistiques et consommation

L'onglet Statistiques trace sur 1 heure, 24 heures ou 7 jours les requêtes par classe de réponse, le trafic et les sessions simultanées. La vue d'ensemble donne le coût du mois en cours et l'activité de la dernière minute.

Le trafic qui passe par le répartiteur est compté sur les machines cibles, comme si elles l'avaient servi elles-mêmes : il puise dans leur trafic inclus. Sur la démonstration, deux téléchargements de 10 Mo à travers le répartiteur ont ajouté 20 972 166 octets au compteur de la machine cible.

10. Par un agent IA

Le serveur MCP FFxF expose les mêmes étapes : create_load_balancer, upsert_pool, set_targets, upsert_listener et set_rules. Un agent peut monter le répartiteur complet à partir d'une phrase, et sa consigne lui demande d'annoncer le prix avant de commander, puis de vous indiquer les enregistrements DNS à créer.

Checklist

• Les machines dans un même réseau privé, avec leur service sur un port connu.
• Un pool par service, avec un contrôle de santé qui teste vraiment l'application.
• Un port HTTPS avec redirection depuis le 80.
• Le DNS pointé, puis le certificat actif dans l'onglet Certificats.
• Les ports 80 et 443 des cibles fermés côté Internet par leur pare-feu.
• Drainer avant chaque maintenance.

Le détail de chaque appel est dans la documentation des répartiteurs, et le pare-feu des cibles dans le guide protéger une VM avec le pare-feu cloud.