bige-ops Beta démo

Layouts & topologies

Un layout est un point de départ : un runtime, des bases, des services, et une topologie qui décide combien de machines existent et qui est exposé. Trois topologies, huit layouts nommés, un bâtisseur pour le reste.

Les trois topologies

flowchart LR
  L[Layout choisi] --> S[single-vm]
  L --> M[multi-vm]
  L --> O[oks]
  S --> S1[Une VM all-in-one]
  M --> M1[VM app publique]
  M --> M2[Une VM privee par base]
  O --> O1[Cluster OKS et manifests]

La topologie n’est pas un détail cosmétique : elle fixe le blast radius.

single-vm (mono-VM) — une seule VM {name}-all, une EIP publique, docker installé (+ nodejs si des services applicatifs sont présents). Simple, pas cher, et un seul blast radius : tout tombe ensemble.
multi-vm — une VM app publique, plus une VM privée par base de données. Isolation réelle, coût plus élevé, câblage réseau à comprendre.
oks — un cluster OKS et des manifests Kubernetes générés. Aucune VM app n’est matérialisée : les services deviennent des Deployments. Voir OKS & pods.

Les huit layouts nommés

id	runtime	topologie	LBU	bases	services
`node-app`	nodejs	multi-vm	oui	mongodb, redis, weaviate	api, web, worker
`python-app`	python	multi-vm	oui	postgres, redis	api, web, worker
`java-spring`	java	multi-vm	oui	postgres, redis	api, web
`elixir-phoenix`	elixir	multi-vm	oui	postgres, redis	api, web, worker
`php-app`	php	multi-vm	oui	postgres, redis	api, web, worker
`go-app`	go	multi-vm	oui	postgres, redis	api, web, worker
`node-lite`	nodejs	single-vm	non	postgres	api, web
`python-ml`	python	multi-vm	oui	postgres, redis, weaviate	api, web, worker

Un layout n’est pas un contrat. Il pose une simulation cohérente en un appel, puis vous éditez : types de VM, tailles de volumes, réplicas, ouverture réseau. Le prix se lit ensuite — voir projets & simulations.

Bâtisseur de stack

Quand aucun preset ne colle, le bâtisseur de stack (alias custom ou build) construit le layout à la demande. Il exige --runtime. Par défaut : postgres + redis, topologie multi-vm, LBU activé, worker inclus. Dans l’app desktop, c’est le wizard Setup / « Bâtisseur de stack ».

bige-ops add layouts                 # lister les layouts
bige-ops add layouts -q spring       # rechercher par mot-clé
bige-ops add layout node-app --name mon-app
bige-ops add layout custom --runtime python --db postgres --db redis --web spa --lbu

Runtimes et services disponibles

Runtimes app : nodejs, python, go, rust, java, elixir, php, custom.

Catalogue de services : api, web, worker, mongodb, redis, postgres, weaviate, database (alias Postgres générique). En plus, vous déclarez des services custom au nom libre via service_config, avec kind: custom et soit une image, soit un dépôt git.

service_config:
  moteur-pdf:
    kind: custom
    image: ghcr.io/moi/moteur-pdf:1.4
  api:
    replicas: 2

Ce que ça n’est pas

Les workers partagent la VM app. Il n’y a pas de VM worker dédiée : si votre worker mange le CPU, il le mange à l’API.
En multi-vm, les URLs de bases n’existent qu’après l’apply : elles remontent du coffre vers le .env. Ne les codez pas en dur avant.
Le premier deploy doit être complet. Un deploy ciblé --service suppose que la stack a déjà été déployée entièrement au moins une fois.
Aucun layout ne remplace une revue d’architecture. C’est un kickoff : quand vous scalez pour de vrai, vous opérez — périmètre.

Machines : VMs. Kubernetes : OKS & pods. Data : bases de données. Exposition : réseau. Vocabulaire : glossaire.