bige-ops Gratuit

Repos, VMs & Dockerfiles

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

bige-ops commite la stack, pas ton code. L’app synchronise le repo qui décrit la stack (config-history GitHub) ; elle ne commite ni ne pousse dans tes repos applicatifs. Quand un build ou un deploy échoue, regarde d’abord le setup Dockerfile du repo app (chemin, nom, contexte de build).

Inspecter un conteneur en cours. Aujourd’hui : logs de deploy, Compose sur la VM, et mode expert sur les fichiers de la simulation. La revue interactive du système de fichiers d’un conteneur se fait depuis la VM.

flowchart TB
  CH[Config-history GitHub] -->|commits / push via l’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[Chemin de Dockerfile imposé] -.->|service_config.git.dockerfile| Build
  Build --> VM

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

Deux familles de repositories

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

Branches, promote et retour arrière Git : GitHub config-history. La forge prise en charge aujourd’hui est GitHub.

Les VMs : là où ça tourne

Après l’apply, les VMs Outscale (ce que beaucoup appellent un VPS) portent l’exécution : mono-VM *-all, multi-VM app / data, ou nœuds OKS. Le deploy pousse Compose, scripts et secrets vers la VM publique, clone le ou les repos app déclarés dans la simulation, puis lance docker compose build et up.

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

Dockerfile : dans le repo, ou chemin imposé

Dans le repo — le Dockerfile (ou un chemin relatif dans un monorepo) vit dans le dépôt applicatif. Au deploy, compose build utilise ce contexte. C’est le cas nominal.
Chemin imposé — dans la simulation, service_config.<svc>.git.dockerfile désigne un nom ou un chemin (Dockerfile, Dockerfile.dev, sous-dossier de monorepo). C’est une instruction de build portée par la stack, pas un commit dans le repo app.

Sans git : une image publiée (service_config.*.image), sans build.

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

Si le deploy échoue

Les causes fréquentes : path ou dockerfile erronés, contexte de build incomplet, secrets de build manquants, image de base inaccessible.

Checklist : Visual ou mode expert → vérifier git.repo · ref · path · dockerfile → préflight → logs de deploy sur la VM. En option, l’agent peut proposer une pull request sur le Dockerfile du repo app ; c’est toi qui merges.

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