bige-ops Gratuit

LBU · l’entrée publique

Le LBU (Load Balancer Unit) est le load balancer d’Outscale : la porte d’entrée HTTP ou HTTPS de tes layouts multi-VM. bige-ops le crée avec ses listeners, son health check et ses VMs backend, et sait y brancher un certificat EIM pour le HTTPS.

À retenir. Le public tape le nom DNS du LBU, attribué automatiquement. Un LBU internet-facing reçoit aussi une IP publique (fournie par Outscale, ou la tienne si tu la précises). Tes VMs app restent derrière, la couche data reste privée.

flowchart LR
  U[Internet] --> DNS["DNS du LBU"]
  DNS --> L["listener HTTPS :443
certificat EIM"]
  L --> A1["VM app :3000"]
  L --> A2["VM app :3000"]
  A1 --> D["VM data — privée"]

TLS terminé sur le LBU, trafic HTTP vers les backends, data jamais exposée.

Ce que bige-ops crée

Sept des huit layouts nommés posent un LBU. Seul node-lite, en mono-VM, s’en passe : sa VM porte une IP publique.
Le scheme : internet-facing (subnet public) ou internal (subnet privé, joignable depuis le Net seulement).
Un ou plusieurs listeners : protocole et port d’entrée, protocole et port backend.
Le HTTPS (ou SSL) : un listener HTTPS avec le server_certificate_id, c’est-à-dire l’ORN du certificat chargé dans EIM. Sans ORN, la validation refuse le listener HTTPS.
Les VMs backend attachées.
Le health check : protocole, port, chemin, intervalle, timeout, seuils sain et non sain.

components:
  - type: load_balancer
    name: front
    scheme: internet-facing
    listeners:
      - load_balancer_protocol: HTTPS
        load_balancer_port: 443
        backend_protocol: HTTP
        backend_port: 3000
        server_certificate_id: "orn:ows:idauth::123456789012:server-certificate/front"
    backend_vms: [app]
    health_check: { protocol: HTTP, port: 3000, path: /health }

Comment un LBU Outscale fonctionne

Round-robin. Les requêtes sont réparties à parts égales entre les backends sains ; les sticky sessions (cookie) s’activent sur les listeners HTTP et HTTPS.
Protocoles appariés. Un frontal HTTP ou HTTPS parle HTTP aux backends ; un frontal TCP ou SSL leur parle TCP. Le chiffrement s’arrête au LBU (TLS 1.1 à 1.3) ; entre le LBU et les VMs, ce sont les security groups qui protègent le trafic.
Un listener ne se modifie pas. On en ajoute et on en retire. Changer un port ou un protocole dans la simulation, c’est remplacer le listener : lis le plan Terraform pour voir ce qui sera recréé.
Un health check par LBU. Intervalle de 5 à 600 s, timeout de 2 à 60 s, seuils de 2 à 10. Outscale recommande donc un LBU par service.

Le certificat EIM

Pour le HTTPS, le certificat serveur se charge dans EIM (Cockpit ou API), puis se référence par son ORN. Outscale attend un certificat x509 et sa clé privée encodés en PEM, une clé RSA au format PKCS#1 sans phrase de passe, et la chaîne des autorités intermédiaires si besoin. Le certificat d’un LBU se remplace à tout moment, sans recréer le load balancer. Source : certificats serveurs dans EIM.

Security groups et LBU

Dans un Net, Outscale n’associe aucun security group par défaut à un LBU : celui du LBU doit laisser entrer Internet et laisser sortir vers les backends, et celui des VMs backend doit accepter le LBU. bige-ops place le LBU dans le subnet public ou privé du Net avec le security group du module réseau. Les principes d’exposition sont sur Réseau · ouvrir ou non.

Un LBU importé est observé

L’inventaire liste tes load balancers existants. L’import en écrit un composant observé : sans listeners ni backends, et exclu du Terraform de création, pour qu’un apply ne recrée jamais par-dessus un LBU réglé à la main. Dans l’inspector, il s’affiche en lecture seule avec la mention « Ressource observée ».

Sticky sessions, listener rules par chemin et access logs vers OOS se règlent dans Cockpit ou par l’API Outscale.

Doc Outscale

Réseau · ouvrir ou non · Réseau avancé · Inventaire & import