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 les extensions requises par les composants activés.

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 à six 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)
CREATE DATABASE lakekeeper;  -- only if infra.lakekeeper.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;

\c lakekeeper
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
CREATE EXTENSION IF NOT EXISTS pgcrypto;
CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE EXTENSION IF NOT EXISTS btree_gin;
CREATE EXTENSION IF NOT EXISTS btree_gist;
SQL

Le chart intégré crée automatiquement les bases et pgvector via un script initdb ; le conteneur init de migration de Lakekeeper crée ses propres extensions. Pour une base managée, pré-créez tous les éléments ci-dessus afin que l'installation échoue avant le déploiement si le fournisseur ou le rôle de migration ne peut pas créer une extension. 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. Lakekeeper exécute également un conteneur init lakekeeper migrate. Une base absente se manifeste peu après l'installation par des Jobs de migration en échec ou un pod Lakekeeper bloqué pendant l'initialisation.

Configuration

Les cinq bases applicatives prennent en charge 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. Lakekeeper ne prend actuellement en charge que le mode en ligne : définissez infra.db.external.lakekeeperUrl lorsque infra.db.enabled=false et infra.lakekeeper.enabled=true.

Mode A — Secrets externes (recommandé)

Gardez les DSN des applications 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 base applicative activée (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
      lakekeeperUrl: "postgres://scrydon:REDACTED@pg.example.com:5432/lakekeeper"

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

Lakekeeper constitue l'exception au Mode A : son DSN doit actuellement être fourni avec lakekeeperUrl. Le chart ajoute sslMode et écrit le même DSN dans les variables de lecture et d'écriture de Lakekeeper au sein du Secret secrets-lakekeeper géré par le chart, avec sa clé de chiffrement. La valeur apparaît donc dans les fichiers de valeurs et dans helm get values.

Si vous gérez les secrets applicatifs via External Secrets Operator, Sealed Secrets ou SOPS, assurez-vous que le Secret résultant possède la bonne clé (DATABASE_URL, DATABASE_URL_ANALYTICS, DATABASE_URL_CORTEX ou DATABASE_URL_ONTOLOGY) 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. Lakekeeper requiert toujours lakekeeperUrl.

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"
      lakekeeperUrl: "postgres://scrydon:REDACTED@pg.example.com:5432/lakekeeper"
      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.

Lorsque Lakekeeper est activé, son conteneur init lakekeeper-migrate applique les migrations du catalogue via lakekeeperUrl avant le démarrage du serveur de catalogue.

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

# Le conteneur init de migration de Lakekeeper doit s'être terminé avec succès
kubectl logs deploy/lakekeeper -n scrydon-platform -c lakekeeper-migrate

# 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>.

Lakekeeper reste en état Init — vérifiez lakekeeperUrl, l'accès réseau, la base lakekeeper et les cinq extensions Lakekeeper. Inspectez kubectl logs deploy/lakekeeper -c lakekeeper-migrate.

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.