← Accueil · Périmètre

Bases de données

Postgres, MongoDB, Redis (et bases custom) : tu choisis où elles tournent (même VM, VM dédiée, ou pods OKS), tu règles réplicas et volumes dans le formulaire, et le setup se met à jour tout de suite. Le tuning fin et la stratégie de sauvegarde restent les tiens. Pour MongoDB 8, Postgres pour le RAG, Cassandra ou Elasticsearch : bases complexes.

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

1 · Coloc ou VM dédiée

En mono-VM (code single-vm), la base est colocalisée avec l’app : un seul blast radius, une estimation basse, idéal pour projeter. Pour isoler la data, passe à une VM dédiée (rôle data en multi-VM) : sizing propre, disque racine io1 par défaut pour Postgres, MongoDB et les autres bases persistantes, et un volume attaché pour la persistance. Le canvas lie le service à sa VM et à son volume ; Save réécrit project.yaml sans questionnaire.

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 de pods

En topologie oks, la base est un Deployment. Le champ réplicas (service_config.*.replicas) règle le nombre de pods. Ce n’est pas un replica set MongoDB ni un cluster Postgres répliqué : la réplication au niveau du moteur se configure dans la base elle-même, ou avec un opérateur. Les pods de base démarrent sur un volume emptyDir : leurs données vivent avec le pod, et le backup vers OOS est le filet. Voir aussi OKS & pods.

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

3 · Stockage bloc et sauvegardes objet

Sur une VM, la persistance passe par le volume BSU attaché à la VM data, et les snapshots de volume sont le premier filet. Pour les dumps applicatifs, on branche OOS (l’Object Storage Outscale, compatible S3) : bucket dédié, lien backup base → OOS dans Visual, script backup.sh préparé après generate. Détail : OOS & backups.

Pas de backup, pas de filet. À la destruction, bige-ops affiche les risques selon le setup : en mono-VM, app et bases partagent le même disque, et le filet, c’est le dump vers OOS. En multi-VM ou sur OKS, détruire une VM data ou des pods efface les données vivantes ; les buckets OOS, eux, restent protégés.

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: mise à jour directe du setup
  Sim->>Gen: Save
  Gen->>Gen: Terraform + manifests + backup.sh
  Gen->>Cloud: apply / deploy (tes clés)
      

Presets par type

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

Au-delà du démarrage

Tuning SQL, index, sharding, opérateurs Kubernetes spécialisés et haute disponibilité du moteur s’ajoutent ensuite, dans ton exploitation — périmètre.