Skip to content

DPL - Despliegue de aplicaciones web

Organizacion del despliegue

Ademas del desarrollo funcional, hemos preparado la estructura necesaria para ejecutar el proyecto de forma reproducible. Para ello hemos usado Docker, variables de entorno, servicios separados y una configuracion especifica para desarrollo y despliegue.

Evidencias directas

  • Dockerfile
  • docker-compose.yml
  • .env.example
  • deploy/entrypoint.sh
  • deploy/nginx/seo-growth-engine.conf
  • gunicorn.conf.py
  • Procfile
  • docs/docker.md
  • docs/deployment.md
  • docs/deployment-evidence.md

Cumplimiento de los requisitos de DPL

Requisito Como lo hemos resuelto Evidencia real
Instalar y configurar NGINX La configuracion del proxy esta versionada y la arquitectura de publicacion que defendemos contempla NGINX en la VPS deploy/nginx/seo-growth-engine.conf
Instalar y configurar Docker Hemos preparado y validado un stack local completo con servicios separados Dockerfile, docker-compose.yml
Instalar y configurar Django La aplicacion se sirve con Gunicorn, variables de entorno y entrypoint propio gunicorn.conf.py, deploy/entrypoint.sh
Instalar y configurar Vue El frontend se compila en una etapa Node y se integra en la imagen final Dockerfile
Dockerizar la aplicacion Tenemos contenedores para web, worker, db y redis docker-compose.yml
Maquina de desarrollo y produccion Desarrollo reproducible con Docker local y arquitectura de produccion con NGINX delante de nuestra aplicacion docker-compose.yml, deploy/nginx/seo-growth-engine.conf
Control de versiones La configuracion de despliegue y los archivos del stack estan dentro del repo repo Git, Dockerfile, compose, docs
Documentacion tecnica Hemos dejado guias, evidencias y una narrativa clara de despliegue docs/docker.md, docs/deployment.md, esta presentacion

Lo que hemos hecho realmente en este bloque

Dockerizacion del sistema

El Dockerfile no es un borrador. Es un flujo completo:

  • usa node:20-alpine para compilar el frontend;
  • ejecuta npm ci, npm run build y npm run build:tailwind;
  • monta una imagen final con python:3.12-slim;
  • instala dependencias Python;
  • copia los estaticos compilados;
  • normaliza deploy/entrypoint.sh;
  • arranca Gunicorn como proceso de aplicacion.

Con esto convertimos el repo en algo ejecutable y transportable.

Servicios del stack

En docker-compose.yml hemos separado responsabilidades:

  • web: sirve nuestra aplicacion principal.
  • worker: ejecuta tareas largas con python manage.py runworker.
  • db: persiste el dominio de la aplicacion en PostgreSQL.
  • redis: sostiene las colas RQ.

Ademas, la configuracion fija dentro del stack DJANGO_TASK_QUEUE_BACKEND="rq" y REDIS_URL, con lo que el worker arranca en el modo correcto para entorno Docker.

Variables de entorno y seguridad operativa

.env.example y la configuracion del stack muestran que hemos pensado el despliegue con separacion de configuracion:

  • DJANGO_SECRET_KEY
  • DJANGO_ALLOWED_HOSTS
  • DJANGO_CSRF_TRUSTED_ORIGINS
  • DATABASE_URL
  • REDIS_URL
  • OPENAI_API_KEY
  • ajustes de correo y notificaciones

Con esto demostramos que nuestro proyecto no depende de secretos hardcodeados ni de una maquina unica.

NGINX en la VPS

Aqui hemos corregido un punto importante respecto a versiones anteriores: la arquitectura de publicacion que presentamos ya contempla NGINX en la VPS.

El archivo deploy/nginx/seo-growth-engine.conf deja claro el papel de NGINX:

  • recibe el trafico HTTP;
  • sirve estaticos desde /static/;
  • hace de proxy hacia la aplicacion en 127.0.0.1:8000;
  • reenvia cabeceras como Host, X-Real-IP y X-Forwarded-Proto.

Por tanto, cuando hablemos de despliegue, nosotros debemos explicarlo asi:

  • en desarrollo hemos validado el stack con Docker;
  • en produccion la arquitectura se apoya en NGINX delante de la aplicacion.

Desarrollo y produccion

La diferencia entre ambos entornos queda separada de forma clara:

  • Desarrollo: Docker nos facilita levantar la aplicacion completa con una sola configuracion reproducible.
  • Produccion: la VPS anade la capa de publicacion con NGINX, hosts reales y configuracion orientada a exponer nuestra aplicacion.

Esta separacion evita mezclar configuracion local, publicacion en VPS y variables sensibles.

Resultado del despliegue

Con este bloque hemos preparado el proyecto para:

  • arrancar siempre de forma consistente;
  • separar procesos y responsabilidades;
  • versionar el despliegue;
  • publicar la aplicacion con una arquitectura basada en NGINX + Gunicorn.

Evolucion de despliegue

Si siguieramos evolucionando el despliegue, reforzariamos:

  • una automatizacion mas completa del despliegue;
  • certificados, dominio final y observabilidad mas cerrada;
  • una pipeline CI/CD si nuestro proyecto siguiera creciendo.

La base de despliegue actual cubre el alcance del proyecto y deja identificadas las mejoras que podrian automatizarse despues.