Base de données personnalisée (BYO Database)

Périmètre : remplacement du Postgres en cluster déployé par infra.db par une instance gérée par le client. Couvre AWS RDS, GCP Cloud SQL, Azure Database for PostgreSQL (Flexible Server), Supabase, Neon, CloudNativePG, le Zalando Postgres Operator, ou tout autre Postgres ≥ 15 avec pgvector.

Voir aussi : Sauvegarde et restauration (le CronJob de sauvegarde intégré est limité à la base en cluster — les utilisateurs d'une base managée doivent s'appuyer sur le PITR natif du fournisseur).

Pourquoi

Le infra.db intégré est un Postgres mono-pod adossé à un PVC — adapté aux preuves de concept et aux clusters mono-nœud, mais sans récupération point-in-time, réplication synchrone, basculement automatique ni réplication de snapshots régionaux. Les clients en production et la plupart des audits de conformité (SOC 2, ISO 27001 A.8.13, SecNumCloud 3.2, NIST CP-9/CP-10) exigent un service managé ou un cluster dédié opéré par un DBA.

Prérequis

Pré-création des bases de données et de l'extension

À exécuter une seule fois, depuis n'importe quel client ayant accès à votre base managée. Le chart par défaut active tous les composants, ce qui correspond à cinq bases de données ; supprimez les lignes des services désactivés dans votre fichier de valeurs.

psql "$ADMIN_URL" <<'SQL'
CREATE DATABASE auth;
CREATE DATABASE agentic;
CREATE DATABASE analytics;   -- only if analytics.enabled (default true)
CREATE DATABASE cortex;      -- only if cortex.enabled (default true)
CREATE DATABASE ontology;    -- only if apiOntology.enabled (default true)

\c auth
CREATE EXTENSION IF NOT EXISTS vector;

\c agentic
CREATE EXTENSION IF NOT EXISTS vector;

\c cortex
CREATE EXTENSION IF NOT EXISTS vector;
SQL

Le chart intégré crée ces bases automatiquement via un script initdb sur le Postgres en cluster ; pour les bases managées, vous devez le faire vous-même. analytics et ontology ne requièrent pas pgvector ; auth, agentic et cortex en ont besoin.

Pourquoi cela doit être fait avant helm install : le chart exécute des Jobs de migration Drizzle par service en tant que hooks post-install contre DATABASE_URL directement — drizzle-kit migrate ne crée pas la base elle-même. Une base manquante se manifeste par des Jobs auth-migration / agentic-migration / cortex-migration / api-ontology-migration en CrashLoopBackOff peu après l'installation.

Configuration

Le chart supporte deux modes. Choisissez-en un par application — lorsque les deux sont définis pour une application, infra.db.external.existingSecrets.<app> prend la priorité sur infra.db.external.<app>Url.

Mode A — Secrets externes (recommandé)

Gardez les DSN hors des fichiers de valeurs et des journaux CI. Pré-créez un Secret par application, chacun dans l'espace de noms cible de l'application, portant un seul DSN sous la clé attendue par l'application. Le chart ajoute chacun en second envFrom sur les déploiements correspondants.

1. Créez un Secret par composant activé (cinq avec les valeurs par défaut du chart) :

NS=scrydon-platform   # adjust if you use split namespaces

# auth → key DATABASE_URL → auth DB
kubectl create secret generic scrydon-db-auth -n "$NS" \
  --from-literal=DATABASE_URL='postgres://scrydon:REDACTED@pg.example.com:5432/auth?sslmode=require'

# agentic → key DATABASE_URL → agentic DB
kubectl create secret generic scrydon-db-agentic -n "$NS" \
  --from-literal=DATABASE_URL='postgres://scrydon:REDACTED@pg.example.com:5432/agentic?sslmode=require'

# analytics → key DATABASE_URL_ANALYTICS → analytics DB
kubectl create secret generic scrydon-db-analytics -n "$NS" \
  --from-literal=DATABASE_URL_ANALYTICS='postgres://scrydon:REDACTED@pg.example.com:5432/analytics?sslmode=require'

# cortex → key DATABASE_URL_CORTEX → cortex DB
kubectl create secret generic scrydon-db-cortex -n "$NS" \
  --from-literal=DATABASE_URL_CORTEX='postgres://scrydon:REDACTED@pg.example.com:5432/cortex?sslmode=require'

# ontology → key DATABASE_URL_ONTOLOGY → ontology DB
kubectl create secret generic scrydon-db-ontology -n "$NS" \
  --from-literal=DATABASE_URL_ONTOLOGY='postgres://scrydon:REDACTED@pg.example.com:5432/ontology?sslmode=require'

Pourquoi un Secret par application : chaque application lit sa variable d'environnement DSN (DATABASE_URL, DATABASE_URL_ANALYTICS, DATABASE_URL_CORTEX, DATABASE_URL_ONTOLOGY) via envFrom, qui fusionne toutes les clés du Secret référencé dans l'environnement du conteneur. Partager un seul Secret forcerait les applications qui lisent DATABASE_URL (auth, agentic) à voir la même valeur et à pointer vers la même base — ce qui est incorrect. Les Secrets par application maintiennent chaque application liée à sa propre base tout en permettant à toutes les applications de partager un espace de noms.

2. Installez le chart :

# values.customer.yaml
infra:
  db:
    enabled: false
    tls:
      enabled: false
    backup:
      enabled: false
    external:
      existingSecrets:
        auth: scrydon-db-auth
        agentic: scrydon-db-agentic
        analytics: scrydon-db-analytics
        cortex: scrydon-db-cortex
        ontology: scrydon-db-ontology

helm upgrade --install scrydon oci://scrydonops.azurecr.io/scrydon/charts/scrydon \
  --version <version> \
  --namespace scrydon-platform \
  -f values.customer.yaml

Si vous gérez les secrets via External Secrets Operator, Sealed Secrets ou SOPS, assurez-vous que le Secret résultant possède la bonne clé (DATABASE_URL ou DATABASE_URL_ANALYTICS) dans le bon espace de noms — le chart ne vérifie jamais comment le Secret a été créé.

Vous pouvez également mixer les modes par application (par exemple existingSecrets.auth pour auth, agenticUrl pour agentic) — le Mode A prend la priorité par application lorsque les deux sont définis.

Mode B — DSN en ligne

Plus simple — un seul bloc de valeurs, sans Secret pré-créé. Les DSN se retrouvent dans le Secret secrets-<app> géré par le chart à l'intérieur du cluster. Convient pour les environnements de staging ; à éviter en production (les DSN se retrouvent dans les fichiers de valeurs, les journaux CI et la sortie de helm get values).

# values.customer.yaml
infra:
  db:
    enabled: false
    tls:
      enabled: false
    backup:
      enabled: false
    external:
      authUrl:      "postgres://scrydon:REDACTED@pg.example.com:5432/auth"
      agenticUrl:   "postgres://scrydon:REDACTED@pg.example.com:5432/agentic"
      analyticsUrl: "postgres://scrydon:REDACTED@pg.example.com:5432/analytics"
      cortexUrl:    "postgres://scrydon:REDACTED@pg.example.com:5432/cortex"
      ontologyUrl:  "postgres://scrydon:REDACTED@pg.example.com:5432/ontology"
      sslMode: require   # appended as ?sslmode=require to each DSN

Ce qui doit rester dans le cluster

Migrations

Le chart exécute un Job hook Helm par composant activé — auth-migration, agentic-migration et (si activés) analytics-migration, cortex-migration, api-ontology-migration — en tant que hooks post-install / pre-upgrade. Chacun sources son DSN depuis le même Secret qu'utilise le runtime, et s'applique donc à votre base managée.

Le conteneur init wait-for-db qui teste le ping du FQDN du service en cluster est ignoré lorsque infra.db.enabled=false — la disponibilité de la base externe relève de la responsabilité du fournisseur.

Pour relancer toutes les migrations manuellement après un changement de valeurs :

kubectl delete job -l 'app in (auth-migration,agentic-migration,analytics-migration,cortex-migration,api-ontology-migration)' -n scrydon-platform
helm upgrade scrydon oci://scrydonops.azurecr.io/scrydon/charts/scrydon \
  --version <version> \
  --namespace scrydon-platform \
  -f values.customer.yaml

Vérification

# Apps should be Ready with Dapr sidecars injected (2/2). The chart defaults
# every service to scrydon-platform; add your namespaces.* targets if you split.
kubectl get pods -n scrydon-platform

# No in-cluster Postgres should exist
kubectl get deploy db -n scrydon-platform
# Expected: Error from server (NotFound)

# Migration Jobs should have run successfully
kubectl get jobs -n scrydon-platform
# auth-migration-<rev>, agentic-migration-<rev>, and (when enabled)
# analytics-migration-<rev>, cortex-migration-<rev>, api-ontology-migration-<rev> — Complete

# A running app pod should have DATABASE_URL pointing at the managed host
kubectl exec deploy/api-platform -n scrydon-platform -c api-platform -- \
  sh -c 'echo "$DATABASE_URL" | sed -E "s#//[^@]+@#//REDACTED@#"'

Notes par fournisseur

AWS RDS / Aurora

• Groupe de paramètres : définissez rds.force_ssl=1.
• Extension : pgvector disponible depuis Postgres 15.3 sur RDS et Aurora. Installez via CREATE EXTENSION vector; depuis un rôle appartenant à rds_superuser.
• Rôle : créez un rôle avec les moindres privilèges (CREATE ROLE scrydon LOGIN PASSWORD '…' CREATEDB;) et accordez-lui la propriété par base.
• Auth IAM : non supportée par le chart actuellement — utilisez l'authentification par mot de passe.

GCP Cloud SQL

• L'indicateur cloudsql.iam_authentication=on est optionnel ; le chart utilise l'authentification par mot de passe.
• pgvector activé par défaut sur Postgres 15+ Enterprise Plus ; sur les niveaux standard, exécutez CREATE EXTENSION vector; une fois.
• IP privée : exécutez le cluster dans le même VPC que votre instance Cloud SQL, ou utilisez un sidecar Cloud SQL Auth Proxy.

Azure Database for PostgreSQL (Flexible Server)

• Paramètre serveur : ajoutez VECTOR à azure.extensions avant le premier CREATE EXTENSION.
• Réseau : la zone DNS privée avec peering VNet est recommandée ; sinon, ouvrez des règles de pare-feu pour l'IP de sortie AKS.
• Bundle CA : Azure publie un bundle CA combiné. Montez-le et utilisez sslmode=verify-full&sslrootcert=/etc/ssl/azure-ca.pem pour une vérification complète.

Supabase / Neon

• pgvector activé par défaut.
• Format de la chaîne de connexion (poolée, mode transaction) : postgres://postgres.<project>:<pass>@aws-0-<region>.pooler.supabase.com:6543/postgres. Vérifiez que vos migrations s'exécutent via la connexion poolée ; certains DDL peuvent nécessiter la connexion directe (5432).
• La suspension automatique de Neon gèle les branches inactives — configurez un keepalive ou utilisez un niveau payant pour les plateformes qui s'arrêtent entre les exécutions de workflows.

Restauration sur Postgres managé

Pour restaurer une archive pg_dump --format=custom produite par le CronJob de sauvegarde intégré (voir Sauvegarde et restauration) :

# decompress if you used gzip
gunzip -k /backups/auth-20260416T020000Z.sql.gz

# restore into the managed DB (run from any client with network access)
pg_restore -d "$DATABASE_URL" --no-owner --no-privileges \
  /backups/auth-20260416T020000Z.sql

--no-owner --no-privileges est important — les noms de rôles sur la base managée diffèrent généralement du Postgres intégré (postgres vs scrydon / rds_superuser / cloudsqlsuperuser).

Après la restauration, redémarrez les pods d'application pour qu'ils établissent de nouvelles connexions :

kubectl rollout restart deployment -n scrydon-platform

Dépannage

CREATE EXTENSION vector échoue — le fournisseur managé ne dispose pas de pgvector pour votre version / niveau Postgres actuel. Mettez à niveau l'instance ; aucune solution de contournement n'existe.

Pods en CrashLoopBackOff avec ECONNREFUSED ou SSL required — hôte/port DSN incorrect, TLS obligatoire mais sslmode absent, ou la politique réseau bloque la sortie vers la base. Consultez kubectl logs pour le pod, vérifiez la valeur DSN avec la commande kubectl exec sous Vérification.

Les migrations restent bloquées — le conteneur init wait-for-db est ignoré, le Job passe donc directement à la migration. S'il reste bloqué, le DSN est incorrect ou le rôle n'a pas les privilèges CREATE. Inspectez kubectl logs job/auth-migration-<rev>.

Table d'état du workflow Dapr introuvable — le composant Dapr Workflows crée son schéma automatiquement au premier démarrage. Si vous remplacez la base intégrée par une base managée existante déjà utilisée ailleurs, assurez-vous que les valeurs tablePrefix (dapr_workflow_state, analytics_dapr_workflow_state) ne sont pas en conflit.

Correspondance de conformité

• ISO 27001:2022 A.8.13 (sauvegarde des informations) — la sauvegarde native du fournisseur managé satisfait cette exigence ; désactivez infra.db.backup.enabled.
• ISO 27001:2022 A.8.24 (TLS en transit) — sslmode=require minimum, verify-full recommandé.
• NIST CP-9 / CP-10 (sauvegarde et restauration) — couverture PITR managée ; documentez le RPO/RTO du fournisseur dans votre PCA.
• SecNumCloud 3.2 (continuité) — exige une réplication régionale ou multi-AZ que le Postgres en cluster intégré ne peut pas offrir. BYO Postgres managé est la voie supportée.