Cuando pg_dump no puede encontrar tu base de datos

pg_dump: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432"
  failed: FATAL: database "flin-postgres" does not exist

Este error apareció la primera vez que un usuario disparó un respaldo de base de datos para una instancia PostgreSQL desplegada vía plantilla. El motor de respaldos ejecutó pg_dump -U postgres flin-postgres dentro del contenedor. La base de datos dentro del contenedor se llamaba "0cron" (de la variable de entorno POSTGRES_DB). La app se llamaba "flin-postgres" (la etiqueta legible por humanos en el dashboard).

Dos sistemas, una base de datos

sh0 tiene dos formas de ejecutar una base de datos:

Bases de datos formales se crean a través de la API de Gestión de Bases de Datos. Tienen una tabla databases dedicada con campos para engine, name, version, container_id y port. El campo name es el nombre real de la base de datos.

Bases de datos desplegadas por plantilla se crean a través del sistema de Stack/Template. El nombre real de la base de datos está enterrado en una variable de entorno -- POSTGRES_DB -- que fue configurada durante el despliegue de la plantilla y encriptada con AES-256-GCM antes de almacenarse.

La cadena de almacenamiento de credenciales

Los valores resueltos se encriptan con la clave maestra y se almacenan en la tabla env_vars. El contenedor Docker se inicia con los valores descifrados como variables de entorno. PostgreSQL lee POSTGRES_DB y crea la base de datos al arrancar. Desde este punto, el único registro de ese nombre es la env var encriptada en SQLite.

El pipeline de descifrado

La corrección fue descifrar las env vars al momento del respaldo y extraer el nombre real de la base de datos. Cada motor de base de datos tiene su propia convención de env vars: PostgreSQL usa POSTGRES_DB, MySQL usa MYSQL_DATABASE, MongoDB usa MONGO_INITDB_DATABASE.

Lo que esto enseña sobre sistemas de plantillas

Los servicios desplegados por plantilla llevan su identidad en dos lugares: el registro de app (nombre, stack, estado) y las env vars (configuración real de runtime). Cualquier funcionalidad que interactúe con el runtime -- respaldos, monitoreo, visualización de credenciales -- debe leer las env vars, no el registro de app.

La tarjeta de credenciales ya sabía esto. El motor de respaldos no. La lección fue arquitectónica: cuando una plantilla crea un servicio, las variables de la plantilla son la fuente de verdad para la identidad de ese servicio.

Siguiente en la serie: Los volúmenes Docker no son rutas del host -- por qué tar::Builder::append_dir_all falla para volúmenes Docker, cómo funciona la API de archivos de Docker, y el bug de corrupción de datos binarios en el parser de stream multiplexado.