Índice de la documentación

IT / Sistemas

Despliegue y mantenimiento

Cómo se levanta el sistema, dónde mirar cuando algo falla, y cómo respaldar la base de datos. Todo vía Docker Compose sobre el mismo host.

Los servicios

Un único docker-compose.yaml (repositorio Dockers) orquesta todo:

leon-databases
PostgreSQL 16, con volumen persistente.
leon-redis
Broker/result-backend de Celery.
leon-backend
Django + Gunicorn, la API.
leon-celery
Worker de tareas en segundo plano.
leon-intranet
Astro (build estático) + nginx.
leon-frontend
La tienda pública, Astro + nginx.
leon-documentation
Este sitio: HTML estático + nginx.

Levantar / reconstruir un servicio

Tras cambiar código de un servicio, hay que reconstruir su imagen y recrear el contenedor — no basta con reiniciarlo:

# desde el repo Dockers/
docker compose build backend
docker compose up -d --no-deps backend celery   # celery comparte imagen con backend

Para la intranet, la tienda o la documentación (todas estáticas, nginx sirviendo archivos ya compilados):

docker compose build intranet
docker compose up -d --no-deps intranet

Cambios de esquema (sin migraciones de Django)

Como los modelos de negocio son managed=False, no existen migraciones de Django que crear. El esquema vive en archivos .sql (repositorio Databases), y un cambio de esquema es:

1. Editar el .sql correspondiente (para que una instalación nueva ya nazca con el cambio).
2. Escribir un archivo de alter aparte, idempotente (ADD COLUMN IF NOT EXISTS, etc.), para aplicar a una base ya viva sin recrearla.
3. Aplicarlo con psql directamente contra el contenedor: docker exec -i leon-databases psql -U postgres -d leon_principal -f archivo.sql.
python manage.py migrate sí corre en cada arranque del backend (entrypoint.sh), pero solo afecta a las tablas internas de Django (auth, sesiones, admin, blacklist de tokens) — nunca a las tablas de negocio.

Logs

docker logs leon-backend --tail 100 -f
docker logs leon-celery --tail 100 -f
docker logs leon-intranet --tail 50

No hay agregación centralizada de logs (sin ELK/Loki) — es docker logs por contenedor.

Backup de la base de datos

Manual, con pg_dump. No hay un cron ni una tarea automática configurada todavía — es un procedimiento a ejecutar a mano:

docker exec leon-databases pg_dump -U postgres -d leon_principal > principal_$(date +%F).sql
docker exec leon-databases pg_dump -U postgres -d leon_fotos     > fotos_$(date +%F).sql
docker exec leon-databases pg_dump -U postgres -d leon_facturas  > facturas_$(date +%F).sql

Restaurar es psql -U postgres -d <base> -f archivo.sql contra una base vacía (creada primero con Databases/00_databases_and_roles.sql).

Problemas frecuentes

Página de la intranet en blanco tras un despliegue: el navegador puede tener cacheado un HTML viejo que apunta a un bundle .js con hash que ya no existe. La propia intranet tiene una red de seguridad (aviso a los 6s con botón "Recargar"); si persiste, verificar que nginx no esté cacheando el HTML (solo /_astro/ debe cachearse "para siempre").
Cambié un modelo y no veo el campo nuevo: revisar que el .sql real se haya aplicado contra la base viva (paso 3 de arriba) — Django no lo hace por ti.
Una tarea de Celery no corre: comprobar que el contenedor leon-celery esté arriba (docker ps) y que Redis responda; revisar sus logs directamente, no hay dashboard de monitoreo de colas.

Variables de entorno por servicio en Dockers/.env y Backend/.env (no versionadas, solo sus .env.example). El detalle de arquitectura general está en Arquitectura del ERP.