Cómo migrar un stack Docker a otro VPS sin downtime

Migrar un stack Docker de un VPS a otro sin causar downtime es uno de esos problemas que parecen complejos, pero que con una estrategia clara se resuelven de forma predecible. Un movimiento mal planificado puede dejar tu aplicación inaccesible durante horas, o peor, con datos inconsistentes.

Mi regla es simple: si no puedes revertir la migración en minutos, no la ejecutes. Esto implica tener siempre el VPS antiguo como fallback hasta que la nueva configuración esté más que probada.

Preparando el nuevo VPS para el stack Docker

Antes de mover cualquier dato, el nuevo VPS debe estar listo para alojar tu stack Docker. Esto significa instalar el sistema operativo, Docker Engine y Docker Compose. Asegúrate de que las versiones de Docker sean compatibles con las que usas actualmente, o al menos que no haya cambios importantes que puedan romper tus contenedores.

Configura el firewall, las claves SSH y cualquier otra herramienta de monitorización que uses. Siempre instalo rsync y fail2ban como parte de la configuración base del servidor.

Transferencia de datos: volúmenes y bases de datos

El mayor reto en una migración de un stack Docker es la persistencia de los datos. Tus volúmenes Docker y bases de datos deben copiarse de forma eficiente para minimizar la ventana de inconsistencia. No basta con copiar los archivos; la copia debe ser atómica y reciente.

La estrategia que uso implica un rsync inicial en caliente, con el stack funcionando en el origen. Luego, justo antes del corte, detengo los servicios en el VPS antiguo y ejecuto un rsync diferencial para copiar solo los cambios. Para manejar esto, tengo una guía específica sobre cómo mover volúmenes Docker entre servidores que detalla los comandos exactos.

# Sincronización inicial (con el stack en marcha en el origen)
rsync -avz --progress /ruta/a/tus/volumenes_docker/ usuario@ip_destino:/ruta/a/los/volumenes_docker/

# Detener servicios en el origen (justo antes del cambio)
ssh usuario@ip_origen "docker-compose down"

# Sincronización final diferencial
rsync -avz --progress /ruta/a/tus/volumenes_docker/ usuario@ip_destino:/ruta/a/los/volumenes_docker/

Para saber qué necesitas copiar exactamente y cómo, entiende la diferencia entre volúmenes Docker y bind mounts.

Configuración de Docker Compose y variables de entorno

Copia tu archivo docker-compose.yml y cualquier archivo .env o variables de entorno relevantes al nuevo servidor. Revisa las rutas de los volúmenes, los puertos y las variables específicas del entorno. Es común que las rutas absolutas de los volúmenes o los nombres de red difieran ligeramente entre entornos.

Asegúrate de que no haya dependencias de IPs internas del VPS antiguo. Si usas un reverse proxy como Traefik, su configuración también debe ser revisada.

Estrategia de DNS para evitar downtime

El downtime más visible en una migración se produce en el cambio de DNS. Mi estrategia es la siguiente:

1. Baja el TTL: 48 horas antes de la migración, cambia el TTL (Time To Live) de tus registros DNS a un valor bajo, como 300 segundos (5 minutos). Esto asegura que los cambios se propaguen rápidamente.
2. Prueba con /etc/hosts: Antes de cambiar el DNS global, edita tu archivo /etc/hosts localmente para que tu dominio apunte a la IP del nuevo VPS. Esto te permite probar el stack completo en el nuevo servidor como si ya estuviera en producción.
3. Cambio de DNS: Una vez verificado que todo funciona en el nuevo VPS, actualiza los registros A/CNAME en tu proveedor de DNS para que apunten a la IP del nuevo servidor.
4. Mantén el antiguo online: No apagues el VPS antiguo inmediatamente. Mantenlo en marcha al menos 24-48 horas más, por si necesitas revertir la migración o tienes alguna caché DNS que aún no se ha actualizado.

Si tu stack Docker incluye Traefik para gestionar certificados SSL, recuerda que la configuración de Let’s Encrypt y Traefik puede necesitar ajustes en el nuevo entorno, especialmente si cambian las IPs o los dominios.

Consideraciones de la estrategia de migración

Lo que ganas:

• Downtime minimizado: Con una buena planificación, el servicio puede estar caído solo unos pocos minutos durante la sincronización final de datos y el cambio de DNS.
• Control total: Tienes el control sobre cada paso, lo que permite una mayor personalización y resolución de problemas.
• Rollback sencillo: Al mantener el VPS antiguo en línea, la capacidad de volver atrás es casi inmediata.

Lo que complicas:

• Requiere conocimiento técnico: No es un proceso para principiantes; exige entender Docker, redes, DNS y rsync.
• Coordinación: Si hay múltiples servicios o bases de datos, la coordinación de la detención y el rsync es más compleja.
• Riesgo de inconsistencia: Si la sincronización de datos no es perfecta, puedes acabar con información desactualizada o corrupta.

Si necesitas una visión más amplia sobre cómo gestionar cualquier migración web para evitar caídas, revisa mi artículo sobre cómo migrar un sitio web a otro servidor sin downtime. Y, por supuesto, antes de cualquier movimiento importante en tu infraestructura, asegúrate de tener una estrategia de backups automáticos en un VPS que funcione y esté verificada.