← Accueil · Réseau · Layouts · VMs
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.
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"]
Ce que bige-ops crée
- Sept des huit layouts nommés créent un LBU. Seul
node-lite, qui est mono-VM, n’en a pas : il expose une EIP. - Le scheme :
internet-facingouinternal. - Un listener, en HTTP : port d’entrée, port et protocole backend.
- Les VMs backend attachées.
- Un health check optionnel, défini par un chemin.
Ce que bige-ops ne crée pas
| Capacité | État |
|---|---|
| Plusieurs listeners | le 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’algorithme | non |
| Certificat / terminaison TLS | non |
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.
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