bige-ops Beta démo

Réseau · ouvrir ou non

Ouvrir un pod, une VM, ou seulement une face d’un layout multi-VM — ce n’est pas un toggle marketing. Deux sources de vérité : les règles de votre projet (simulation / YAML) et les règles Outscale (Net, Security Groups, LBU).

Principe court. Exposer le minimum : entrée publique (LBU / HTTP) si besoin ; data et admin en privé (VPC / SG). Pas de 0.0.0.0/0 sur SSH ou ports admin « parce que pratique ».

flowchart LR
  NET[Internet] --> LBU[LBU / face publique]
  LBU --> APP[VM app / pods front]
  APP --> DATA[VM data / pods DB]
  DATA -.->|pas d’EIP| X[fermé]

Schéma type multi-VM / node-app : public sur le LBU, data privée.

Ce qu’on ouvre (ou pas)

Face publique d’un layout VMs — souvent la VM app (+ LBU). Ports app derrière le load balancer ; pas toute la machine ouverte au monde.
VM data / bases — subnet privée, SG VPC only. Pas d’EIP « pour dépanner ».
Pod OKS — Service / Ingress selon le besoin ; réplicas ≠ exposition. Admin kube : CIDR restreint (OKS_ADMIN_CIDR), pas le monde.
SSH / deploy — sur la face app si nécessaire ; jamais sur mongo/redis « ouverts ».

Règles projet + règles Outscale

Dans bige-ops, le layout (mono-VM, multi-VM, OKS) et les liens Visual / YAML disent quoi exposer. Outscale applique le comment : Net, subnets, Security Groups, routes, LBU. Inventaire et reverse engineering montrent l’existant ; un apply ne réécrit pas magiquement votre contrat réseau.

Doc produit Outscale (référence) :

Layouts « pas simples » à maintenir

Multi-VM + LBU + SG + pods : ça dérive vite (ports orphelins, clés partout, setups parallèles). L’ agent LLM travaille avec vos clés API perso (locales) pour lire la simulation, la maintenir dans les clous, et éviter la cascade de clés / setups hors règles projet + Outscale — pas pour remplacer votre politique sécurité.

VMs · VPS · OKS & pods · OKS · attention contrat · Périmètre