pg_dump: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432"
failed: FATAL: database "flin-postgres" does not existCette erreur est apparue dans les logs la première fois qu'un utilisateur a déclenché un backup de base de données pour une instance PostgreSQL déployée via un template. Le moteur de backup a exécuté pg_dump -U postgres flin-postgres à l'intérieur du conteneur. La base de données dans le conteneur s'appelait « 0cron » (d'après la variable d'environnement POSTGRES_DB). L'application s'appelait « flin-postgres » (le label lisible dans le tableau de bord).
Le moteur de backup a utilisé le mauvais nom parce qu'il n'avait aucun moyen de distinguer les deux. Cet article explique pourquoi cette distinction est importante, comment les bases de données déployées par template stockent leurs identifiants, et le pipeline de déchiffrement que nous avons construit pour résoudre le problème.
Deux systèmes, une base de données
sh0 dispose de deux manières d'exécuter une base de données :
Les bases de données formelles sont créées via l'API de gestion de bases de données (POST /api/v1/databases). Elles ont une table dédiée databases dans SQLite avec les champs engine, name, version, container_id et port. Le champ name est le véritable nom de la base de données (par exemple « my_app_db »). Les backups pour les bases de données formelles fonctionnent correctement parce que db_name correspond directement à la base PostgreSQL.
Les bases de données déployées par template sont créées via le système de Stack/Template. Un utilisateur déploie le template « postgres », ce qui crée un enregistrement App dans la table apps. L'application a un name (par exemple « flin-postgres »), un stack (par exemple « postgres ») et un container_id. Mais le véritable nom de la base de données est enfoui dans une variable d'environnement -- POSTGRES_DB -- qui a été définie lors du déploiement du template et chiffrée avec AES-256-GCM avant stockage.
Quand le moteur de backup recevait source_type: "database" et source_id: <uuid>, il essayait d'abord Database::find_by_id(). Pour les bases déployées par template, cela retournait « not found » parce que l'enregistrement est dans apps, pas dans databases. Le fallback chargeait alors l'application et utilisait app.name comme db_name.
Le nom de l'application est un label. Le nom de la base de données est un identifiant PostgreSQL. Ils n'ont rien à voir l'un avec l'autre.
La chaîne de stockage des identifiants
Comprendre la correction nécessite de comprendre comment les variables d'environnement des templates circulent dans le système :
Étape 1 : Définition du template
Le template postgres.yaml définit des variables :
yamlvariables:
- name: POSTGRES_PASSWORD
required: true
generated: secret_32
- name: POSTGRES_DB
default: "app"Étape 2 : Déploiement du template
Quand un utilisateur déploie le template, le moteur de substitution résout ${POSTGRES_PASSWORD} en un secret aléatoire de 32 caractères et ${POSTGRES_DB} en la valeur saisie par l'utilisateur ou la valeur par défaut « app ».
Étape 3 : Chiffrement et stockage
Les valeurs résolues sont chiffrées avec la clé maître et stockées dans la table env_vars :
rustlet value_encrypted = sh0_auth::crypto::encrypt(
&master_key,
value.as_bytes(),
)?;
EnvVar {
id: uuid::Uuid::new_v4().to_string(),
app_id: Some(app_id.to_string()),
key: "POSTGRES_DB".to_string(),
value_encrypted,
// ...
}.insert(&pool)?;Étape 4 : Lancement du conteneur
Le conteneur Docker est démarré avec les valeurs déchiffrées comme variables d'environnement. PostgreSQL lit POSTGRES_DB et crée la base de données au démarrage. À partir de ce moment, le conteneur possède une base de données en cours d'exécution nommée selon la valeur de POSTGRES_DB -- mais le seul enregistrement de ce nom est la variable d'environnement chiffrée dans SQLite.
Le pipeline de déchiffrement
La correction a consisté à déchiffrer les variables d'environnement au moment du backup et à extraire le vrai nom de la base de données. Le handler d'identifiants (get_db_credentials) faisait déjà cela pour la carte « Database Credentials » du tableau de bord. Nous avons extrait le pattern dans une fonction réutilisable :
rustfn decrypt_env_map(
master_key: &Option<Arc<MasterKey>>,
env_vars: &[EnvVar],
) -> HashMap<String, String> {
let mut map = HashMap::new();
let Some(key) = master_key.as_ref() else {
return map;
};
for ev in env_vars {
if let Ok(plaintext) = sh0_auth::crypto::decrypt(key, &ev.value_encrypted) {
map.insert(
ev.key.clone(),
String::from_utf8_lossy(&plaintext).into_owned(),
);
}
}
map
}Ensuite, avant de construire le BackupSource, on interroge et déchiffre :
rustlet env_vars = EnvVar::list_by_app_id(&pool, &app.id)?;
let env_map = decrypt_env_map(&master_key, &env_vars);
let (db_name, db_user, db_password) = match engine.as_str() {
"postgres" | "postgresql" | "timescaledb" | "pgvector" => {
let name = env_map.get("POSTGRES_DB")
.cloned()
.unwrap_or_else(|| "postgres".into());
let user = env_map.get("POSTGRES_USER")
.cloned()
.unwrap_or_else(|| "postgres".into());
let pass = env_map.get("POSTGRES_PASSWORD").cloned();
(name, user, pass)
}
"mysql" | "mariadb" => {
let name = env_map.get("MYSQL_DATABASE")
.cloned()
.unwrap_or_else(|| "app".into());
let user = "root".to_string();
let pass = env_map.get("MYSQL_ROOT_PASSWORD").cloned();
(name, user, pass)
}
"mongodb" | "mongo" => {
let name = env_map.get("MONGO_INITDB_DATABASE")
.cloned()
.unwrap_or_else(|| "app".into());
let user = env_map.get("MONGO_INITDB_ROOT_USERNAME")
.cloned()
.unwrap_or_else(|| "admin".into());
let pass = env_map.get("MONGO_INITDB_ROOT_PASSWORD").cloned();
(name, user, pass)
}
_ => (app.name.clone(), "root".to_string(), None),
};Chaque moteur de base de données a sa propre convention de variables d'environnement. PostgreSQL utilise POSTGRES_DB, POSTGRES_USER, POSTGRES_PASSWORD. MySQL utilise MYSQL_DATABASE, MYSQL_ROOT_PASSWORD. MongoDB utilise MONGO_INITDB_DATABASE, MONGO_INITDB_ROOT_USERNAME, MONGO_INITDB_ROOT_PASSWORD. Le fallback n'utilise app.name que pour les moteurs non reconnus.
La même correction à deux endroits
La résolution des identifiants devait se faire à la fois dans le handler de déclenchement (backups.rs) et dans le planificateur cron (scheduler.rs). Le handler de déclenchement s'exécute quand un utilisateur clique sur « Sauvegarder maintenant ». Le planificateur s'exécute toutes les 60 secondes et vérifie les planifications dues.
Les deux chemins avaient le même bug db_name: app.name. Les deux avaient besoin de la même recherche de variables d'environnement. Nous avons ajouté les helpers decrypt_env_map et extract_db_credentials dans les deux fichiers (ils sont suffisamment petits pour que l'extraction dans un crate partagé ne justifie pas la complexité de dépendance).
Le planificateur avait besoin d'accéder à la clé maître via le BackupEngine :
rustpub(crate) master_key: Option<Arc<MasterKey>>,Nous avons rendu le champ pub(crate) pour que le planificateur (dans le même crate) puisse le lire sans méthode getter.
Le problème des chemins de volumes
La même session a révélé un bug parallèle dans les backups de volumes. Quand aucun enregistrement de montage n'existait en base de données (fréquent pour les applications déployées par template), le planificateur utilisait par défaut /data comme chemin de volume. PostgreSQL stocke ses données dans /var/lib/postgresql/data. MySQL utilise /var/lib/mysql. L'API d'archive Docker retournait 404 - Could not find the file /data in container.
La correction était une table de correspondance par défaut adaptée à la stack :
rustfn default_volume_path(stack: &str) -> &'static str {
match stack {
"postgres" | "postgresql" => "/var/lib/postgresql/data",
"mysql" | "mariadb" => "/var/lib/mysql",
"mongodb" | "mongo" => "/data/db",
"redis" | "dragonfly" => "/data",
"clickhouse" => "/var/lib/clickhouse",
"cassandra" | "scylladb" => "/var/lib/cassandra",
_ => "/data",
}
}Ces chemins sont des conventions des images Docker, pas de la configuration -- chaque image postgres:16-alpine stocke ses données dans /var/lib/postgresql/data. En connaissant la stack, on connaît le chemin.
Ce que cela nous apprend sur les systèmes de templates
Les services déployés par template portent leur identité à deux endroits : l'enregistrement de l'application (nom, stack, statut) et les variables d'environnement (configuration d'exécution réelle). L'enregistrement de l'application est l'identité côté humain. Les variables d'environnement sont l'identité côté machine. Toute fonctionnalité qui interagit avec l'exécution -- backups, monitoring, affichage des identifiants -- doit lire les variables d'environnement, pas l'enregistrement de l'application.
La carte d'identifiants le savait déjà. Le moteur de backup ne le savait pas. La correction n'était pas techniquement complexe (30 lignes de déchiffrement de variables d'environnement). La leçon était architecturale : quand un template crée un service, les variables du template sont la source de vérité pour l'identité de ce service.
La prochaine fois que nous construirons une fonctionnalité qui touche aux services déployés par template -- streaming de logs, analyse de performance, connection pooling -- nous commencerons par les variables d'environnement, pas par le nom de l'application.
Prochain dans la série : Les volumes Docker ne sont pas des chemins hôte -- pourquoi tar::Builder::append_dir_all échoue pour les volumes Docker, comment fonctionne l'API d'archive Docker, et le bug de corruption de données binaires dans le parseur de flux multiplexé.