Saltar al contenido principal

Guía de Despliegue

Configuración de Producción​

Requisitos de Infraestructura​

El sistema está diseñado para desplegarse en Vercel como plataforma principal, pero también soporta despliegue en Docker para entornos personalizados.

Requisitos mínimos:​

  • Node.js 18.x o superior
  • Memoria: 2GB RAM mínimo (recomendado 4GB)
  • Almacenamiento: 1GB para la aplicación
  • Conexiones a Internet estables para comunicación con APIs externas

Variables de Entorno para Producción​

Las siguientes variables deben estar configuradas en el entorno de producción:

# Configuración básica
NODE_ENV=production
STANDALONE=true (solo para Docker)
# Solicitar...

Proceso de Deployment​

Despliegue en Vercel (deprecated ☹️)​

El despliegue principal se realiza automáticamente a través de Vercel:

  1. Los cambios en la rama main desencadenan automáticamente un despliegue en producción
  2. Los Pull Requests generan despliegues de preview

Para desplegar manualmente:

# Instalar CLI de Vercel si no está instalada
npm install -g vercel

# Login (solo primera vez)
vercel login

# Despliegue en producción
vercel --prod

Despliegue con Docker​

Para entornos donde no se usa Vercel:

  1. Construir la imagen Docker:
docker build -f .docker/build.Dockerfile -t headless-ecommerce .
  1. Ejecutar el contenedor:
docker run -p 3000:3000 --env-file .env.production headless-ecommerce

Alternativamente, usar Docker Compose (en conjunto con CI/CD):

docker-compose -f docker-compose-deploy.yml up -d

CI/CD​

Proceso de Despliegue con Forgejo

Descripción general​

El proyecto utiliza un repositorio en forgejo configurado como mirror para realizar el CI/CD, a su vez utiliza Bitbucket Pipelines para CI/CD, con la configuración definida en bitbucket-pipelines.yml, que se encarga de notificarle a Forgejo que hay cambios en la rama main. (forgejo por defecto solo puede hacer sync cada 10 minutos como mínimo).

Este documento describe el flujo automatizado para construir y desplegar un contenedor headless utilizando Forgejo como registro de imágenes y un servidor Vultr como destino.

Componentes principales​

  • Forgejo: Utilizado como registro privado de Docker
  • Vultr: Servidor de destino para el despliegue
  • Forgejo Actions: Automatiza el proceso de CI/CD

Proceso simplificado​

  1. Activación: El flujo se inicia automáticamente al hacer push a la rama main
  2. Construcción: Se crea una imagen Docker con la aplicación headless
  3. Publicación: La imagen se sube al registro de Forgejo con etiquetas latest y versionada
  4. Despliegue: La imagen se descarga y ejecuta en el servidor Vultr

Requisitos​

Para implementar este flujo, es necesario:

  • Credenciales de acceso al registro de Forgejo
  • Acceso SSH al servidor Vultr
  • Variables de entorno configuradas en el repositorio

Configuración necesaria​

  • Secretos: Credenciales para Forgejo y clave SSH para Vultr
  • Variables: Configuración del entorno de producción y datos de conexión al servidor

Notas importantes​

  • El despliegue actualiza y reinicia el contenedor sin downtime
  • También reinicia un servicio de monitorización asociado
  • El proceso genera automáticamente versiones con marca temporal

Rollbacks​

Rollback en Vercel (deprecated 🥺)​

Para revertir a un despliegue anterior en Vercel:

  1. Ir al dashboard de Vercel
  2. Seleccionar el proyecto
  3. Ir a la pestaña "Deployments"
  4. Encontrar el despliegue deseado
  5. Hacer clic en los tres puntos y seleccionar "Promote to Production"

Rollback con Docker​

Para revertir a una versión anterior con Docker:

  1. Identificar la etiqueta o hash de la imagen anterior
  2. Detener el contenedor actual:
docker-compose -f docker-compose-deploy.yml down
  1. Modificar el docker-compose-deploy.yml para usar la imagen anterior
  2. Reiniciar:
docker-compose -f docker-compose-deploy.yml up -d

Configuraciones Avanzadas​

Cacheado​

La aplicación utiliza varias estrategias de cache:

  1. Build-time caching: Contenido estático de Directus cacheado durante build
  2. ISR (Incremental Static Regeneration): Para páginas semi-estáticas
  3. Browser caching: Headers configurados en next.config.js

SSL/TLS​

La aplicación debe servirse siempre a través de HTTPS:

  • En Vercel esto se configura automáticamente
  • En despliegues personalizados, configurar un proxy reverso como Nginx con SSL