senzapaura_es/despliegue/LEEME.md

Despliegue de web y administración

El código se publica conjuntamente; las claves y los medios quedan fuera de cada release.

Estructura

/var/www/senzapaura/
  .env                 # sitio: DATABASE_URL, ORIGIN=https://senzapaura.es, claves
  .env.panel           # misma DATABASE_URL; ORIGIN=https://admin.senzapaura.es
  current -> releases/<version>
  releases/<version>/  # build, build-panel, node_modules, migraciones y scripts
  media/audio/         # originales y descargas MP3 privadas
  media/escucha/       # escucha completa privada
  media/ondas/         # ondas compartidas
  media/imagenes/      # imágenes cargadas desde el panel

Las dos unidades fijan rutas absolutas de medios, HOST=127.0.0.1 y puertos 3000/3001. El panel reserva 260 MiB por petición para un archivo de hasta 256 MiB más el formulario. Nginx permite 260m en el dominio administrativo.

Instalación y actualización

1. Preparar Node.js compatible con el proyecto, PostgreSQL, ffmpeg y ffprobe. Crear el usuario de servicio y los dos archivos de entorno con permisos 600. Ambos deben usar la misma base. El script comprueba la coincidencia sin mostrar claves.
2. En desarrollo, ejecutar bash despliegue/desplegar.sh usuario@servidor. Comprueba tipos, formato, tests y ambos builds con código de salida correcto. Sube las dependencias a una release nueva y copia medios sin sobrescribir.
3. Las migraciones se ejecutan en el destino con su .env. Las de esta entrega son 0024_intenciones_pago.sql y 0025_guardas_publicacion.sql.
4. La primera vez, ejecutar en el servidor sudo bash /var/www/senzapaura/current/despliegue/instalar.sh. Instala ambas unidades y el ejemplo Nginx. Configurar DNS y TLS de los dos dominios.
5. Las actualizaciones posteriores cambian current y reinician ambos servicios. Si falla el arranque o la comprobación HTTP, se restaura el enlace anterior. Las releases antiguas se conservan. La base no se revierte automáticamente.

Migrar una instalación anterior

Conservar la instalación y su copia de seguridad. Preparar los entornos y dejar que el primer despliegue cree current; después instalar las nuevas unidades. Los antiguos build y node_modules de la raíz no se borran. Si se usaba otro sistema de arranque, adaptar sus directorios de trabajo a current y sus rutas de medios a las compartidas antes de reiniciarlo.

La subida nunca reemplaza un audio existente con la misma clave. Para cambiar material ya publicado, preparar una operación editorial explícita. Las imágenes nuevas tienen nombres únicos y se pueden asignar desde el panel.

Las nuevas guardas no rellenan créditos ausentes. En el catálogo legado deben asignarse los intérpretes reales; a partir de la migración, las escrituras que rompen los requisitos de publicación se rechazan al confirmar la transacción. Las importaciones deben agrupar canción, créditos y audio en una transacción.

Proxy y recuperación

/escucha y /descargas siempre pasan a Node para autorizar la petición y resolver Range. No añadir aliases que publiquen media/audio o media/escucha. El webhook /api/stripe/webhook atraviesa el modo de espera y comprueba la firma.

La activación usa flock para impedir despliegues concurrentes. El cambio de enlace es atómico, pero el reinicio puede producir una breve interrupción del servicio. Antes de cambios destructivos de esquema debe diseñarse una migración compatible con la versión anterior o un procedimiento específico de recuperación.

npm run db:recuperar-audios informa de manifiestos de procesado. Con -- --limpiar elimina solo restos de más de 24 horas, comprobando primero sus referencias en PostgreSQL. Un final registrado nunca se elimina por esta vía.

Las pruebas locales verifican código y migraciones; no equivalen a un ensayo real de instalación, TLS y restauración del servidor de producción.