Migración de una aplicación activa de AWS EC2 a DigitalOcean: una guía completa sin tiempo de inactividad

¿Cómo migrar una aplicación activa de AWS EC2 a DigitalOcean? — Resumen de los pasos

En esta guía técnica y paso a paso te explicamos cómo Cómo migrar una aplicación en vivo de AWS EC2 a DigitalOcean Transferencia con un tiempo de inactividad mínimo y manteniendo las consideraciones de seguridad y red.

• Evaluación inicial e inventario de recursos (EC2, EBS, RDS, S3, ELB, Grupos de seguridad, IAM)
• Diseño de la arquitectura de destino en DigitalOcean (Droplet, VPC, Volúmenes, Espacios, Balanceador de carga, Base de datos administrada)
• Transferencia de datos (archivos, S3 → Espacios, BD → BD administrada o réplica)
• Implementación de aplicaciones (restauración, contenedorización o uso de App Platform/Kubernetes)
• Cambio con tiempo de inactividad mínimo (replicación, IP flotante, TTL de DNS)
• Limpieza y revisión final de AWS, y medidas de seguridad y monitoreo

1. Fase uno: evaluación y preparación

Catalogación de recursos

Haga una lista completa de todos los recursos relacionados: instancias EC2, volúmenes e instantáneas de EBS, grupos de seguridad, balanceadores de carga, roles/políticas de IAM y otros servicios dependientes como S3, RDS, ElastiCache y CloudFront.

Determinar el tipo de aplicación Obligatorio: ¿La aplicación tiene estado (por ejemplo, con una base de datos), no tiene estado (por ejemplo, interfaz), está en contenedores o requiere GPU/renderizado?

Determinación de necesidades funcionales y de ubicación

Especifique parámetros como latencia de red, requisitos de GPU, IOPS máximos y ancho de banda de salida.

Si necesita un ping bajo para operar o jugar, elija una ubicación cercana a sus usuarios finales. DigitalOcean también tiene diferentes regiones: consulte cuál es el centro de datos de DO más cercano.

2. Diseño de la arquitectura de destino en DigitalOcean

Componentes sugeridos

La propuesta arquitectónica incluye lo siguiente:

• Gotita Para aplicaciones y servicios (VPS)
• Bases de datos administradas (Postgres / MySQL) para eliminar la complejidad de la replicación y las copias de seguridad
• Espacios (Compatible con S3) para transferir objetos desde S3
• Volúmenes de almacenamiento en bloque Para big data y persistencia
• Balanceador de carga y IP flotante Para una transición sin tiempo de inactividad
• VPC Para aislamiento de red y firewall para control de acceso
• Utilice servidores GPU o servidores de cómputo dedicados si necesita GPU

Elección del tamaño y tipo de gota

Utilice droplets optimizados para CPU para aplicaciones que requieren mucha CPU y droplets con alto consumo de RAM o servicios administrados para aplicaciones que hacen un uso intensivo de la memoria.

Para comerciar o jugar, se recomienda un VPS dedicado con ping bajo y recursos de red dedicados en una ubicación adecuada.

3. Transferir archivos y objetos (S3 → Espacios / EBS → Volumen)

S3 → Transferencia de espacios

Para transferir objetos de S3 a Spaces, utilice herramientas compatibles con S3 como clon O s3cmd Usar.

rclone config
rclone sync s3:my-bucket spaces:my-space --progress

También puede exportar con aws cli y luego cargar con doctl o s3cmd.

Transferencia de archivos del servidor (EBS → Droplet)

Para grandes volúmenes y contenido estático de sincronización r Para sincronizar, utilice:

rsync -azP --delete -e "ssh -i /path/to/key.pem" ubuntu@ec2-ip:/var/www/ /home/ubuntu/www/

Si necesita una instantánea, primero tome una instantánea de EBS, comprima el contenido y luego transfiérala al Droplet.

4. Migración de bases de datos (RDS → BD administrada o autoalojada)

Opciones basadas en el tipo de base de datos

MySQL/MariaDB:

Para minimizar el tiempo de inactividad, configure una réplica en DigitalOcean y luego realice una conmutación. Si utiliza RDS:

1. Crear una base de datos administrada en DO.
2. Establezca una réplica externa desde RDS o utilice mysqldump.

mysqldump -u user -p --single-transaction --quick --lock-tables=false dbname > dump.sql
mysql -h do-managed-host -u user -p dbname < dump.sql

PostgreSQL: Se recomienda la replicación lógica (pg_dump/pg_restore) o la replicación de transmisión para una certeza cercana a cero.

pg_dump -Fc -h aws-rds-host -U user dbname > db.dump
pg_restore -d dbname -h do-host -U user db.dump

Solución sin tiempo de inactividad (ejemplo de MySQL)

Proceso general:

1. Habilitar el registro binario en AWS.
2. Cree un servidor de réplica MySQL en DigitalOcean y conéctelo como esclavo al maestro en AWS.
3. Después de la sincronización, envíe la aplicación a la réplica y promuévala.

5. Implementación de aplicaciones: opciones y comandos

Método 1: Contenerización y registro

La contenedorización con Docker/Kubernetes es la mejor manera de migrar sin depender de AMI. Cree la imagen en CI y envíela a Docker Hub o al Registro de GitLab.

En DO, puedes usar Kubernetes administrado o droplets con docker-compose.

docker-compose pull
docker-compose up -d --remove-orphans

Método 2: Restauración tradicional

De la forma tradicional, instalas los paquetes, transfieres el código con rsync y ejecutas el servicio con systemd o un administrador de procesos como PM2.

npm install --production
pm2 start app.js --name myapp

Uso de la plataforma de aplicaciones y servicios administrados

La plataforma de aplicaciones DigitalOcean puede proporcionar CI/CD, escalamiento automático y SSL automático, y es adecuada para aplicaciones web si no desea administrar un servidor de bajo nivel.

6. Red, seguridad y transición sin tiempo de inactividad

IP flotante y balanceador de carga

Para una transición sin tiempo de inactividad, puede configurar un balanceador de carga en DO y utilizar IP flotante O utilice un grupo objetivo diferente.

Estrategia azul-verde Generalmente incluye estos pasos:

1. Configuración de un entorno verde en DO y publicación completa de la aplicación
2. Controles de salud
3. Cambiar la IP flotante o cambiar el grupo de destino en el balanceador de carga

Reducción del TTL del DNS No olvides realizar un corte previo (por ejemplo, TTL=300 s o menos) para que la propagación sea más rápida.

Cortafuegos y seguridad

Agregue una clave SSH a su cuenta DO y deshabilite el inicio de sesión con contraseña:

Edit /etc/ssh/sshd_config: PermitRootLogin no, PasswordAuthentication no

Utilice UFW para la gestión de acceso básica:

sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp
sudo ufw enable

Utilice el firewall en la nube en DO e implemente reglas similares a las de los grupos de seguridad en AWS. Instalación falla2ban También se recomienda utilizar SSL con Certbot o un certificado administrado por Load Balancer.

7. Consejos y guiones operativos

Ejemplos de doctl

Instalación y autenticación de DO CLI:

doctl auth init --access-token <TOKEN>

Ejemplo de creación de un Droplet:

doctl compute droplet create my-droplet --size s-2vcpu-4gb --image ubuntu-22-04-x64 --region nyc3 --ssh-keys <KEY_ID> --vpc-uuid <VPC_ID> --wait

doctl compute cdn create --origin my-space.nyc3.digitaloceanspaces.com ...

rsync para sincronización incremental

rsync -azP --delete -e "ssh -i ~/.ssh/do_key" /var/www/ user@do-ip:/var/www/

8. Post-migración: Pruebas y optimización

Revisión y seguimiento del desempeño

Inspeccione los registros, la latencia y el rendimiento con herramientas como Prometheus/Grafana o New Relic. Las pruebas de carga con herramientas como ab o siege, así como la comprobación de IOPS y el ancho de banda de la red, son esenciales.

Copia de seguridad y recuperación ante desastres

Habilite instantáneas y copias de seguridad automatizadas para Droplets y bases de datos administradas y pruebe el plan de restauración.

9. Consejos para la gestión de costes y recursos

Compare los costos entre AWS (EC2 + EBS + RDS + S3) y la combinación DO (Droplets + Volúmenes + Base de datos administrada + Espacios).

Si su aplicación requiere una red amplia, el uso de una CDN y BGP/Anycast puede reducir la latencia global.

10. Problemas y soluciones comunes

• Diferencia de versión de la base de datos → Pruebas de compatibilidad y migración en staging, utilizando volcados lógicos.
• Archivos grandes y transferencias lentas → Compresión tar+gzip, reanudación con rsync y uso de Spaces para entregar contenido.
• Errores de SSL y CORS después de la transición → Verifique la cadena de certificados y la configuración de Nginx/Load Balancer.

11. Ejemplo de configuración de Nginx para Load Balancer y Droplets ascendentes

upstream app {
    server 10.0.0.5:3000;
    server 10.0.0.6:3000;
}
server {
    listen 80;
    server_name example.com;
    location / {
        proxy_pass http://app;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

12. Consejos de seguridad y cumplimiento de las mejores prácticas

• Uso de Claves SSH y activación 2FA Cuentas en la nube
• Restricción del acceso a IAM y claves API
• Realización de análisis de vulnerabilidades y gestión de parches
• Habilite la protección DDoS y WAF si es necesario

Conclusión

Migrar una aplicación en vivo de AWS EC2 a DigitalOcean es un desafío, pero con una planificación adecuada (que incluya un inventario cuidadoso, replicación para la base de datos y uso de IP flotante o equilibrador de carga para la transición) puede minimizar el tiempo de inactividad y aprovechar los droplets, los espacios y las bases de datos administradas.

El equipo está listo para ayudar en el diseño e implementación de infraestructura, especialmente para escenarios que requieren GPU, VPS dedicados para juegos o comercio, CDN y soluciones de redes complejas.

Preguntas frecuentes