Esta semana movimos el blog desde una configuración local de Docker Compose a una VPS de producción.
El objetivo era sencillo: mantener los servicios reproducibles, conservar los datos y hacer que el despliegue se pudiera repetir sin tratar el servidor como una máquina de usar y tirar.
Qué se movió
La aplicación funciona como varios servicios de Compose: frontend, autenticación, API del blog, correo, registros, Postgres, MinIO y Caddy.
Los datos de Postgres y MinIO se transfirieron a la VPS en lugar de comenzar con volúmenes vacíos. Así conservamos los usuarios, artículos, archivos multimedia y datos de los servicios existentes. La contraseña de Postgres se rotó durante la migración, y el archivo de entorno de producción se mantiene en el servidor, no en el repositorio.
Caddy gestiona HTTPS para blog.bjornmagne.com. El sitio redirige a la página de inicio en el idioma correspondiente y las comprobaciones de salud facilitan la revisión de los servicios.
Despliegue
El primer despliegue de producción utilizó imágenes construidas localmente para poner el sitio en línea de forma segura. El repositorio ahora también incluye una capa de Compose para imágenes del registry y un trabajo de despliegue de GitLab. Las compilaciones de main reciben la etiqueta del SHA del commit y el trabajo espera la comprobación HTTPS pública antes de considerar correcto el despliegue.
Esto nos da una ruta clara para volver atrás: seleccionar la etiqueta de la imagen anterior, levantar de nuevo la pila y comprobar el mismo endpoint de salud.
Una lección sobre autenticación
La migración de datos mostró un detalle fácil de pasar por alto. Las claves de firma de autenticación se cifran con un secreto propio del despliegue. La base de datos y las claves cifradas pueden moverse juntas, pero el secreto de cifrado también debe acompañarlas.
El entorno inicial de la VPS utilizaba un secreto diferente. La comprobación de la contraseña seguía funcionando, pero auth no podía descifrar la clave de firma para emitir un token de acceso. Retiramos esa clave migrada inutilizable y generamos una nueva clave local de la VPS. Las sesiones existentes quedaron invalidadas, que es la decisión correcta después de cambiar la clave de firma.
Próximos pasos
Queda conectar GitLab Registry y las variables CI protegidas, y ejecutar el primer despliegue y rollback aprobados. El sitio ya está activo, pero el proceso no estará completo hasta probar tanto un nuevo despliegue como una recuperación.