bige-ops Beta démo

Repos, VMs & Dockerfiles

Trois pièces à ne pas mélanger : le repo qui versionne la stack (config-history), les repos applicatifs (code + Dockerfile), et les VMs Outscale où tourne Docker Compose après deploy.

Commits bige-ops = stack seulement. Pour le moment, l’app ne commit / ne push pas sur les repos applicatifs. Seul le repo qui gère la stack (config-history GitHub) est synchronisé. Si un problème de build/deploy survient, il vient en général d’un mauvais setup Dockerfile dans un repo app pris en charge (chemin, nom, contexte de build) — pas d’un commit fantôme de l’outil sur votre monorepo.

Review lecture / écriture sous container Docker : WIP. Inspecter ou éditer des fichiers depuis un container en cours (shell / FS live) n’est pas encore un flux produit abouti. Aujourd’hui : logs deploy, compose sur la VM, mode expert sur les fichiers de la simulation — pas une revue interactive complète du FS container.

flowchart TB
  CH[Config-history GitHub] -->|commits / push via app| Stack[Simulation · project.yaml]
  Stack -->|apply| VM[VM Outscale]
  AppRepo[Repo applicatif] -->|clone au deploy| VM
  AppRepo -.->|Dockerfile dans le repo| Build[docker compose build]
  Override[Override dockerfile path] -.->|service_config.git.dockerfile| Build
  Build --> VM

Stack versionnée d’un côté · code + Dockerfile de l’autre · runtime sur la VM.

Deux familles de repositories

Repo	Rôle	bige-ops y commit ?
Config-history (`*-infra`)	Blueprint simulation : `project.yaml`, TF généré, specs, layout	Oui — sync depuis l’app (GitHub)
Repo applicatif	Code métier (api, web, worker…) cloné au `deploy`	Non (pour le moment)

Détail branches / promote / rollback Git : GitHub config-history. Autres forges que GitHub : WIP.

VMs (= VPS catalogue) : où ça tourne

Après apply, les VMs (Outscale parle aussi de VPS) portent le runtime — mono-VM *-all, multi-VM app / data, ou nœuds OKS. deploy pousse compose / scripts / coffre vers la VM publique et clone le(s) repo(s) app déclarés dans la simulation, puis docker compose build / up.

Les bases (mongo, postgres…) sont sur la même VM (mono-VM) ou sur des VMs data (multi-VM) — voir VMs · VPS et bases. Le Dockerfile concerne surtout les services app (api, web, worker, customs git).

Dockerfile : dans le repo ou override

Deux façons, exclusives côté intention :

Dans le repo — le fichier Dockerfile (ou chemin relatif au monorepo) vit dans le dépôt applicatif. Au deploy, compose build utilise ce contexte. C’est le cas nominal « repo pris en charge ».
Override — dans la simulation, service_config.<svc>.git.dockerfile pointe un nom / chemin (ex. Dockerfile, Dockerfile.dev, sous-dossier monorepo). Utile pour un preset ou un fichier hors racine. Ce n’est pas un commit automatique dans le repo app : c’est une instruction de build dans la stack.

Alternative sans git : image catalogue (service_config.*.image) — pas de build Dockerfile.

service_config:
  api:
    git:
      repo: https://github.com/org/monorepo.git
      ref: main
      path: apps/api          # contexte
      dockerfile: Dockerfile # dans le repo, ou override de nom

Si ça casse au deploy

Les échecs fréquents viennent d’un mauvais setup Dockerfile sur un repo app pris en charge : mauvais path / dockerfile, contexte de build incomplet, secrets de build manquants, image de base inaccessible — pas d’un push de bige-ops sur votre monorepo (il n’en fait pas).

Checklist courte : Visual / expert → vérifier git.repo · ref · path · dockerfile → préflight → logs deploy sur la VM. Optionnel : l’agent peut proposer une PR Dockerfile sur le repo app — vous mergez ; ce n’est pas le sync stack automatique.

Suite : VMs · config-history · mode expert · OKS.