← Accueil · Périmètre

Bases de données

Postgres, Mongo, Redis (et customs) : vous choisissez où ça tourne (même VM, VM dédiée, ou pods OKS), vous réglez réplicas / volumes dans le formulaire, le setup se met à jour tout de suite. Le DBA fin et la stratégie backup restent les vôtres — on kickoff. Pour Mongo 8, RAG Postgres, Cassandra, Elastic et les gaps produit : bases chiantes & gourmandes.

flowchart TB
  DB[(Base)]
  DB --> C1[Coloc sur VM app]
  DB --> C2[VM data dédiée]
  DB --> C3[Pods OKS]
  C2 --> VOL[Volume block]
  C3 --> REP[Réplicas Deployment]
  C1 --> VOL
  VOL -.->|backup optionnel| OOS[(OOS bucket)]
  REP -.->|backup optionnel| OOS
      

1 · Coloc vs VM dédiée

En mono-VM (code single-vm) / multi-VM simple, la DB est souvent colocalisée avec l’app : un seul blast radius, estimate bas, parfait pour projeter. Dès que vous isolez le risque data, vous passez une VM dédiée (rôle data en multi-VM) : sizing + volume attaché pour la persistance. Le canvas / inspector lie le service DB à la VM et au volume ; Save réécrit project.yaml sans re-interview.

flowchart LR
  subgraph coloc [Démarrage]
    A1[VM app + DB]
  end
  subgraph dedi [Isolement]
    A2[VM app]
    D2[VM data + volume]
  end
  coloc -->|scale / risque| dedi
      

2 · Sur OKS : réplicas pods ≠ replica-set géré

Topologie oks : la DB est un Deployment. Le champ réplicas (service_config.*.replicas) scale le nombre de pods. C’est le bon levier pour démarrer — ce n’est pas encore un replica-set Mongo ou un cluster Postgres managé. HA moteur = votre run (ou un opérateur plus tard). Voir aussi OKS & pods.

service_config:
  postgres:
    replicas: 1
  mongodb:
    replicas: 1

3 · Storage local vs backups objet

La persistance chaude passe par le volume (block storage) attaché à la VM data, ou le stockage du cluster OKS selon le layout. Les snapshots de volume sont le premier filet block. Pour les sauvegardes applicatives / dumps vers l’objet, on branche OOS (Object Storage Outscale, S3-compatible) : bucket dédié, lien backup DB → OOS dans Visual, scripts générés après generate. Détail : OOS & backups.

Pas de backup = tu auras un problème. À la destruction, bige-ops affiche les risques selon le setup : en mono-VM, app + bases partagent le même disque (on ne peut pas « geler » la DB seule sans bloquer toute la VM) — le filet, c’est le dump → OOS. En multi-VM / OKS, destroy d’une VM data / des pods = perte live ; OOS reste indestructible via l’outil.

sequenceDiagram
  participant UI as Formulaire Visual
  participant Sim as Simulation
  participant Gen as generate
  participant Cloud as Outscale
  UI->>Sim: réplicas / VM / volume / backup OOS
  Note over Sim: maj directe du setup
  Sim->>Gen: Save
  Gen->>Gen: TF + manifests + backup.sh
  Gen->>Cloud: apply / deploy (vos keys)
      

Presets par type

Chaque type amène une image catalogue et des champs utiles dans l’inspector. Postgres : volume data, attache VM ou pod, réplicas OKS. Mongo / Redis : même logique (coloc, dédiée, ou OKS). Custom : image + port + les mêmes leviers sizing / réplicas. Pas de wizard qui recommence : un champ changé = setup à jour.

Hors kickoff (volontaire)

Tuning SQL, indexes, sharding, operators K8s spécialisés, promesse HA sans relecture humaine : pas le job du starter kit. Quand la data scale, l’intelligence reste humaine — périmètre.