Répartiteurs de charge

Un répartiteur reçoit le trafic sur sa propre adresse publique IPv4 et IPv6 et le distribue aux machines d'un de vos réseaux privés, en TCP ou en HTTP(S). C'est un service géré : FFxF le fait tourner, le tient à jour et obtient ses certificats Let's Encrypt ; vous décrivez seulement où va le trafic.

Comment ça s'articule

• Un pool regroupe les machines qui rendent le même service (frontend, backend, db). Chaque cible est une machine du réseau privé et un port. Une cible en panne ne reçoit plus rien.
• Un port d'entrée (listener) s'ouvre sur l'adresse du répartiteur, en http, https ou tcp, avec un pool par défaut.
• Sur un port HTTP(S), des règles envoient un nom et/ou un début de chemin vers un autre pool : app.exemple.com vers frontend, app.exemple.com/api/ ou api.exemple.com vers backend.

Les cibles gardent leur adresse privée : pas besoin d'IP publique, et leurs propres pare-feux peuvent fermer 80 et 443 côté Internet, puisque le réseau privé n'est jamais filtré.

Créer un répartiteur

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": "site-web", "vpc": 12}'

{ "data": { "id": 4, "name": "site-web", "status": "pending", "vpc": 12, "ipv4": "23.159.52.40", "ipv6": "2602:f3a4:0:100::40", "pools": [], "listeners": [] } }

La facturation commence tout de suite, à l'heure, comme pour une machine (le compte doit couvrir 24 heures). Le répartiteur est prêt en quelques minutes : status passe de pending à active. Pools et ports peuvent se préparer entre-temps ; ils s'appliquent dès qu'il est prêt.

Pools et cibles

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

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

PUT …/targets remplace toute la liste : décrivez l'état voulu et rejouez-le autant de fois que nécessaire ; une cible conservée garde son état de santé. Une machine se désigne par son id, celui de GET /vms, et doit être dans le réseau privé du répartiteur. Un pool http sert les ports http et https ; un pool tcp sert les ports tcp et peut envoyer le PROXY protocol v2 (send_proxy).

Les contrôles de santé passent toutes les 5 secondes par défaut : une connexion TCP, ou pour un pool HTTP un GET sur health_path, sain pour tout code 2xx ou 3xx. Trois échecs sortent une cible, deux succès la remettent.

Ports d'entrée

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

redirect_https fait rediriger le port 80 vers ce port. Les requêtes HTTP portent X-Forwarded-For, X-Forwarded-Proto et X-Forwarded-Port. Les ports 22 et 8402 sont réservés ; avec un port HTTPS, le 80 ne peut être que HTTP. Un port tcp transmet tout à son pool par défaut sans le lire.

Règles de routage

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

La liste est remplacée d'un bloc. Quel que soit l'ordre envoyé, les règles sont évaluées de la plus précise à la plus large, et la première qui correspond l'emporte :

Les noms passent en minuscules et les noms accentués en punycode. Un joker est refusé en HTTPS : aucun certificat ne pourrait le couvrir.

Certificats et DNS

Chaque nom des règles d'un port HTTPS reçoit son propre certificat Let's Encrypt, renouvelé 30 jours avant l'échéance. Il n'est demandé qu'une fois le nom pointé vers le répartiteur : un enregistrement A vers son ipv4 et un AAAA vers son ipv6. D'ici là, certificates affiche dns_pending ; un échec affiche failed avec sa raison, et la demande repart une heure plus tard.

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, une liste d'adresses ou de plages IPv4/IPv6, pour restreindre qui s'y connecte (une base de données, un bureau, un CDN) ; null laisse entrer tout le monde. Tant qu'un port HTTPS existe, le 80 reste ouvert à tous : Let's Encrypt y valide les certificats.

curl -s -X PATCH https://api.ffxf.net/v1/load-balancers/4/listeners/16 \
     -H "Authorization: Bearer $FFXF_TOKEN" -H "Content-Type: application/json" \
     -d '{"sources": ["203.0.113.0/24", "2001:db8::/32"]}'

Au quotidien

Limites et facturation

Trois répartiteurs par compte par défaut ; par répartiteur, 10 pools, 25 cibles par pool, 5 ports d'entrée, 25 règles par port et 15 noms en HTTPS. Un répartiteur se paie à l'heure. Son trafic est compté sur les machines cibles, comme si elles l'avaient servi elles-mêmes : il puise dans leur trafic inclus.

Détails utiles

La lecture demande vms.read ; la création, vms.create et une Idempotency-Key ; la suppression, vms.destroy ; pools, cibles, ports et règles, network.write. Le serveur MCP expose les mêmes actions : voir Outils MCP.