← Accueil · Réseau · Layouts · VMs

bige-ops Beta démo

LBU · l’entrée publique

Le LBU est la porte d’entrée HTTP de vos layouts multi-VM. bige-ops en crée un, avec un listener, et attache vos VMs derrière. Au-delà de ça, c’est votre console Outscale.

À retenir. Un LBU porte un nom DNS, pas une EIP. Le public tape le DNS du load balancer ; vos VMs restent derrière, sans IP publique.
flowchart LR
  U[Internet] --> DNS["DNS du LBU"]
  DNS --> L["listener HTTP :80"]
  L --> A1["VM app :3000"]
  L --> A2["VM app :3000"]
  A1 --> D["VM data — privée"]
      
Un listener, des backends, une couche data qui ne voit jamais Internet.

Ce que bige-ops crée

Ce que bige-ops ne crée pas

Pas de HTTPS généré. Les listeners produits sont en HTTP. Aucune ressource de certificat n’est générée. Si vous voulez du TLS, la terminaison se fait dans la console Outscale ou en amont du LBU. Ne lisez pas « entrée publique » comme « entrée chiffrée ».
CapacitéÉtat
Plusieurs listenersle modèle interne les accepte, l’app n’en expose qu’un
Health check avancé (intervalle, seuils, timeout)non — chemin seulement
Sticky sessions, choix d’algorithmenon
Certificat / terminaison TLSnon

Un LBU importé est un croquis

L’inventaire liste vos load balancers existants. L’import en écrit un composant marqué observé : sans listeners, sans backends, et exclu du Terraform de création. C’est volontaire — un apply ne doit pas recréer par-dessus un LBU que vous avez réglé à la main.

Limite d’affichage. Sur le canvas, un LBU importé ressemble aujourd’hui à un LBU pilotable. Il ne l’est pas. Tant que le badge « observé » n’est pas posé sur ce nœud, fiez-vous à la matrice d’inventaire.

Security groups et LBU

Le LBU a ses propres règles côté Outscale, distinctes de celles des VMs qu’il sert. Ouvrir le listener ne suffit pas si le SG de la VM backend ne laisse pas entrer le load balancer. Les principes d’exposition sont sur Réseau · ouvrir ou non.

Doc produit Outscale (référence)

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