CAPÍTULO 3 · Cada pieza encuentra su responsabilidad
Preparar una base donde aprender sin comprometer datos reales
La configuración y las primeras defensas están listas, pero todavía no hemos comprobado cómo se comportará el proyecto al guardar información. Empezar directamente contra una base usada por otras personas mezclaría aprendizaje con operación. Necesitamos poder equivocarnos al definir una tabla, corregir una conexión y repetir una prueba sin afectar el trabajo de nadie.
Preparamos PostgreSQL en un entorno local controlado. Aprendemos a distinguir el servidor de la base, el puerto del nombre de usuario y una contraseña incorrecta de un servicio que no está disponible. Esa separación ayuda a diagnosticar: si Django no conecta, no necesariamente hay un error en el modelo o en la vista que acabamos de escribir.
Una vez confirmada la conexión, podemos trabajar con datos de prueba. Más adelante revisaremos alojamiento, cuentas y recuperación con mayor profundidad. Ahora la pregunta es más elemental: qué hace que una estación o un sensor siga siendo el mismo objeto aunque cambien su nombre o sus atributos.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
Una base para practicar
Las flechas resumen el recorrido conceptual. Los controles y dependencias se detallan debajo.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Contenedor. Aísla el laboratorio
- Volumen. Conserva datos locales
- Roles. Separa tareas y permisos
- Django. Conecta con usuario limitado
01 / EL PROBLEMA
¿Para qué sirve?
Una conexión rechazada y un permiso denegado pertenecen a capas diferentes. Distinguirlas evita cambios innecesarios en Django o en roles.
02 / COMPRENDER
El concepto, explicado
Para practicar puedes usar una instalación local o un contenedor. El ejemplo usa PostgreSQL 16 como versión explícita del laboratorio; no asume que sea la más reciente. Requiere Docker instalado y en ejecución.
Publica el puerto solo en 127.0.0.1 y conserva datos en un volumen. Las variables POSTGRES_* inicializan un volumen vacío; cambiar POSTGRES_PASSWORD después no cambia automáticamente la contraseña de un clúster existente.
La cuenta de bootstrap configura el laboratorio. Crea luego roles de runtime y migración con el recorrido de gobernanza de PostgreSQL. Django usa DB_* para conectarse; no dejes el superusuario como cuenta cotidiana.
Diagnostica por capas: proceso detenido o conexión rechazada; red/puerto; base inexistente; autenticación; privilegios de esquema/tablas. Una lista vacía en la interfaz tampoco demuestra un fallo de conexión.
03 / CONSTRUIR
Implementación paso a paso
- Arranca Docker y prepara una contraseña solo para el laboratorio.
- Crea el contenedor con volumen y puerto de loopback.
- Comprueba estado y disponibilidad con pg_isready.
- Crea los roles limitados y la base de práctica.
- Instala el driver PostgreSQL del proyecto y configura DATABASES desde DB_*.
04 / APLICAR
Ejemplo en SensorHub
# PowerShell. SENSORHUB_LAB_PASSWORD debe existir en esta sesión.
if (-not $env:SENSORHUB_LAB_PASSWORD) { throw "Falta contraseña del laboratorio" }
docker run -d --name sensorhub-pg `
-e POSTGRES_USER=lab_admin `
-e "POSTGRES_PASSWORD=$env:SENSORHUB_LAB_PASSWORD" `
-e POSTGRES_DB=sensorhub_dev `
-p 127.0.0.1:5432:5432 `
-v sensorhub_pgdata:/var/lib/postgresql/data postgres:16
docker exec sensorhub-pg pg_isready -U lab_admin -d sensorhub_dev
# Entrar al laboratorio para gestionar roles:
docker exec -it sensorhub-pg psql -U lab_admin -d sensorhub_dev
# Ya en psql: \conninfo
# Cambiar contraseña de un rol con prompt: \password nombre_rol
# Fragmento de base.py del proyecto de práctica, con psycopg instalado:
# import os
# DATABASES = {"default": {
# "ENGINE": "django.db.backends.postgresql",
# "NAME": os.environ["DB_NAME"],
# "USER": os.environ["DB_USER"],
# "PASSWORD": os.environ["DB_PASSWORD"],
# "HOST": os.environ["DB_HOST"],
# "PORT": os.getenv("DB_PORT", "5432"),
# }}Cómo leer el ejemplo
- La contraseña del contenedor local puede ser visible al administrador de Docker; no reutilices secretos productivos.
- El volumen conserva datos al recrear el contenedor. No uses borrado del volumen como solución genérica.
- La academia no necesita Docker para arrancar: este es un laboratorio separado.
Error habitual
No desactives el firewall global ni borres migraciones para resolver connection refused.
05 / PRACTICAR
Tu turno
pg_isready responde pero Django dice permission denied for schema public. ¿Qué capa falla?
Ver solución orientativa
La red y el servidor responden. Revisa rol efectivo, USAGE del esquema y permisos necesarios; las migraciones requieren otro alcance que el runtime.
06 / VERIFICAR
Cómo sabes que funciona
- El puerto solo está publicado en loopback.
- Puedes explicar la diferencia entre conexión, autenticación y autorización.
Para profundizar
Documentación oficial para comprobar configuración, permisos y condiciones vigentes. Revisión del tema: 11 de octubre de 2026.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Modelos base y UUID →Continuar en modo relato