Migrar WordPress desde CPanel a instancia EC2 de AWS

Introducción

¿Utilizas WHM/CPanel para administrar tu servidor o hosting? ¿Tu sitio es muy lento y optimizar el servidor es una tarea imposible? ¿Estás considerando la idea de cambiar de hosting? Entonces este tutorial es para ti.

Te presentamos una mejor opción de hosting para tu sitio WordPress, es decir, Amazon Web Services (AWS). Además, enlistaremos los beneficios que ofrece este servicio de hosting en la Nube y, por último, cómo realizar la migración.

¿Por qué cambiar de CPanel a AWS EC2?

La mayoría de las personas comienzan utilizando CPanel porque brinda una manera muy fácil de configurar y acceder al servidor desde un panel intuitivo, al menos más intuitivo que una consola; pero todo tiene sus pros y sus contras, por ejemplo, la personalización del servidor se ve demasiado limitada ya que sólo se cuenta con las funciones que brinda CPanel y, en dado caso de que intente configurarlo desde la consola, CPanel ignorará dicha configuración y la reemplazará por defecto.

CPanel es un panel de control que tiene el propósito de administrar tu hosting y servidor, cuenta con un diseño medianamente intuitivo, éste se apodera del servidor e instala todo lo que es comúnmente necesario, como MySQL, FTP, Cron Jobs, etc., pero es difícil personalizar dicho servidor ya que WHM/CPanel toma el control total del mismo.

cpanel

Amazon Web Services (AWS) es un prestador de servicios en la nube que, entre muchos otras soluciones, ofrece todos los servicios necesarios para un hosting de alto rendimiento y ajustable a tus necesidades y presupuesto.

Entre los servicios que se mencionan en este blog podemos encontrar:

  • Elastic Compute Cloud (EC2): Servidores virtuales.
  • Relational Database Service (RDS): Servidores especializados para bases de datos.
  • Route53: Administrador de DNS.
Una instancia EC2 de AWS es un servidor virtual con las siguientes características:
  • Nivel de disponibilidad alto.
  • Nivel de estabilidad alto.
  • Escalable en espacio de memoria y tamaño de servidor.
  • El espacio en disco duro es independiente al tamaño de instancia, es decir, se puede establecer según la sus necesidades e incrementar si así se desea.
  • Brinda “doble” seguridad ya que, además del firewall default, se dispone de Security Groups de AWS los cuales restringen los puertos que prefiera

NGINX es un servidor web más veloz incluso que Apache, por esta razón nosotros preferimos la implementación de éste.

Como lenguaje de código utilizaremos PHP versión 7.0 ya que es la versión más reciente y estable de PHP; ten en cuenta que NGINX necesita PHP-FPM para interpretar dicho código.

¿Porqué es mejor AWS que CPanel?

Beneficios de AWS:

  • Control total de la instancia EC2.
  • Base de datos optimizada.
  • Mayor seguridad.
  • Capacidad de personalizar la instancia EC2.
  • Soporte de AWS.

Desventajas de CPanel:

  • A pesar que tiene una herramienta para subir archivos, el CPanel no es muy usado para esta función ya que para ello se usa un cliente FTP como el Filezilla.
  • No soporta NGINX
  • Una vulnerabilidad es que, teniendo acceso a la terminal y tecleando “mysql -v” se obtiene el acceso a todas las bases de datos

¿Cómo migrar el WordPress?

Para migrar un WordPress desde CPanel a AWS es necesario:

  • Una cuenta CPanel
  • El WordPress a migrar en la cuenta
  • Una cuenta de AWS

1. El primer paso es obtener el directorio comprimido y la base de datos. El directorio comprimido, donde encontrarás el WordPress, deberá estar como archivo “tar.gz”, y la base de datos estará en formato “sql.gz”. Para obtener el directorio comprimido del WordPress (document root) y la base de datos, puedes ir al apartado de CPanel llamado “Backup” y seleccionar la base de datos a exportar, al igual que el document root.

1.1 Ir a tu cuenta en CPanel, ingresando en el navegador http://111.111.111.111:2083 (cambiar 111.111.111.111 por la IP del servidor o dominio). El número 2083 es el puerto por el que se accede al CPanel.

1.1

1.2 Ingresar al apartado “Backup”.

1.2

1.3 En el apartado “Account Backups”, dar click en el botón “Home directory” y en el nombre de la base de datos para iniciar su descarga.

1.3

Después de tener la base de datos y el document root comprimido en tu computadora, debes empezar la creación de la instancia EC2 y el RDS (servidor para la base de datos) en AWS.
Nota: La base de datos puede alojarse en el mismo servidor que el WordPress (instancia EC2) pero se recomienda usar un RDS ya que éste está optimizado.

2. A continuación, crearemos la instancia EC2:

2.1 Ingresar a la cuenta de AWS mediante el link https://xxxxxxx.signin.aws.amazon.com/console con usuario y contraseña.

2.1

2.2 Antes de comenzar a crear instancias, necesitamos asegurarnos de hacerlo en la región deseada, en este caso lo haremos en US East (N. Virginia) pues es la más utilizada y algunos servicios son más baratos.

2.2

2.3 En la pantalla siguiente buscar el servicio EC2.

2.3

2.4 Presionar “Instances” en el menú izquierdo.

2.4

2.5 Presionar botón “Launch instance” para iniciar la creación de la instancia EC2

2.5

2.6 Elegir el Sistema Operativo de la instancia, en este caso será “Ubuntu Server 16.04 LTS”.

2.6

2.7 Elija el tamaño de la instancia, esto con base a las necesidades de su sitio, en este caso demostrativo elegiremos una instancia tipo t2.micro. (Para más información respecto a los tipos de instancias visite “https://aws.amazon.com/ec2/instance-types” y costos en “https://aws.amazon.com/ec2/pricing

2.7

2.8 Configurar la red (VPC) y subred como se muestra a continuación.

2.8

2.9 Determinar el tamaño del disco de la instancia; para calcularlo se recomienda sumar el tamaño del document root y de la base de datos (en caso que desee alojarla en la misma instancia y no usar AWS RDS) y multiplicarlo por 3, así garantiza tener el 60% del disco libre; en este caso demostrativo se determinaron 8 Gb ya que es el mínimo requerido.

2.9

2.10 Opcional. Recomendamos asignar una etiqueta representativa a la instancia para identificarla fácilmente, como se muestra a continuación.

2.10
2.10a

2.11 Al crear el grupo de seguridad (Security Group o SG), se recomienda agregar tu IP a la regla de SSH, esto con el fin de que sólo tú te puedas conectar mediante SSH a la instancia; además agrega dos reglas para abrir los puertos 80 (HTTP) y 443 (HTTPS), como se muestra a continuación.

2.11

2.12 Verifica las configuraciones y lanza la instancia.

2.12

2.13 Antes de que AWS lance la instancia, debes crear o elegir una llave SSH ya que, por seguridad, AWS por default permite sólo conexiones por SSH con llave, no contraseña.

En este caso, creamos una llave nueva y le asignamos un nombre representativo, la descargamos y lanzamos la instancia.

2.13

2.14 Cuando la instancia se esté lanzando, revisa su estado haciendo click en el ID de la instancia.

2.14

2.15 Cuando el estado de la instancia sea “Running”, podrás conectarte a ella.

2.15

3. Ahora es necesario crear y configurar el RDS para la base de datos.

3.1 Buscar y navegar hasta el servicio RDS.

3.1

3.2 Dar click en “Instances” o “Get Started Now”.

3.2

3.3 Empezar la creación del RDS dando click en “Launch DB instance”.

3.3

3.4 En este caso seleccionaremos MySQL como motor de base de datos.

3.4a
3.4b

3.5 Elegir el caso en el que se usará la base de datos; en este caso será “Production – MySQL”.

3.5

3.6 Especificar los detalles de la instancia como se muestra a continuación:

  • DB engine version: Versión de MySQL.
  • DB instance class: Tipo de instancia (en este caso demostrativo, se seleccionó la más pequeña)
  • Multi-AZ deployment: Esta opción permite una réplica de la instancia en otra zona mientras se realizan los backups automáticos. Se recomienda habilitar esta opción si es un entorno de producción, en este caso se omitió ya que es demostrativo.
  • Storage type: Para un WordPress de recomienda el tipo de almacenamiento SSD ya que se escribe y lee frecuentemente de la base de datos y este almacenamiento está optimizado para I/O.
  • Allocated storage: Por razones demostrativas, se asignó el mínimo de espacio en disco a la instancia, se recomienda revisar el tamaño de la base de datos y decidir el tamaño respecto dicha cantidad.
  • DB instance identifier: Determinar el identificador/nombre de la instancia .
  • Master username: Establecer nombre del usuario administrador/root de la base de datos; no se recomienda “root” o “admin” por cuestiones de seguridad.
  • Master password y Confirm password: Determinar contraseña para el usuario administrador.

Nota: Las opciones restantes dejarlas por default.

3.6a
3.6b
3.6c

3.7 Configurar la red.

  • Virtual private cloud: En este caso se mantendrá la red por default.
  • Public accessibility: Por seguridad, el RDS no debe ser públicamente accesible.
  • Availability zone: Asignar zona de disponibilidad, no se recomienda dejar por default este valor.
  • VPC Security Groups: Crear un Security Group nuevo para especificar reglas de seguridad sólo para esta instancia.
  • Auto minor version upgrade: Ya que la instancia es para fines demostrativos, se ha deshabilitado las actualizaciones de versiones; en dado caso puede activarlo si lo desea

Nota: Dejar los valores restantes por default.

3.7a
3.7b
3.7c
migración-aws-checklist

DESCARGA GRATIS

Checklist de Migración de AWS

3.8 Ya que la instancia ha sido lanzada, revisar su estado.

3.8

3.9 Cuando el estado de la instancia sea “available” está lista para ser utilizada.

3.9

4. Lo siguiente es probar la conexión al RDS desde la instancia.

4.1 Establecer conexión con la instancia EC2.

ssh -i /ruta/llaveSSH/creada ubuntu@IP

Nota: La IP de la instancia se puede observar en los detalles de la misma al seleccionarla en el dashboard de AWS.

4.1

4.2 Instalar MySQL-client para establecer conexión con el RDS.

sudo apt install mysql-client-core-5.7

4.3 Asegurarse que el Security Group permite la conexión desde la instancia.

a) Navegar por Services > RDS > Instances > Seleccionar instancia > Seleccionar el Security Group

4.3a

b) Seleccionar las reglas de entrada (Inbound).

4.3b

c) Editar las reglas.

4.3c

d) Agregar las reglas necesarias para permitir acceso a las IP pública y privada de la instancia.

4.3d

4.4 Conectarse al RDS con el usuario, contraseña y host/endpoint correspondientes.

mysql -h ENDPOINT -u USUARIO -p
Enter password: **********

Nota: El endpoint del RDS se puede observar en los detalles del mismo al seleccionarlo en el dashboard de AWS.

4.4

5. Es hora de transferir el document root y la base de datos comprimidos a la instancia EC2:

5.1 Enviar el archivo .tar.gz a la instancia.

Opción A:
Si estás utilizando Linux en tu computadora, desde consola ejecutar el siguiente comando:

scp -i /ruta/llaveSSH/creada /ruta/wordpress.tar.gz ubuntu@IP:/home/ubuntu/

scp -i /ruta/llaveSSH/creada /ruta/db_name.sql.gz ubuntu@IP:/home/ubuntu/

Opción B:
Si estás utilizando Windows en tu computadora, puedes utilizar la herramienta WinSCP siguiéndo este tutorial https://www.youtube.com/watch?v=58KmUBaEW34.

5.2 Crear el directorio donde se localizará el WordPress.

sudo mkdir -p /var/www/dominio.com/public_html/

5.3 Cambiar el propietario del directorio creado.

sudo chown -R ubuntu:www-data /var/www/dominio.com/

5.4 Descomprimir el archivo .tar.gz en /home/ubuntu/.

cd /home/ubuntu/
tar -xzvf /home/ubuntu/wordpress.tar.gz

5.5 Mover el contenido al directorio antes creado.

mv /home/ubuntu/wordpress/* /var/www/dominio.com/public_html/

5.6 Cambiar permisos y propietario a todo el WordPress.

Cambiar el usuario dueño a “ubuntu” y el grupo a “www-data”

sudo chown -R ubuntu:www-data /var/www/dominio.com/

Cambiar permisos a los directorios para permitirle lectura, escritura y ejecución a propietario y grupo, pero sólo lectura y ejecución a “todos los demás”:

find /var/www/dominio.com/public_html/ -type d -exec chmod 775 {} \;

Cambiar permisos a los archivos para permitirle lectura y escritura a propietario y grupo, pero sólo lectura a “todos los demás”:

find /var/www/dominio.com/public_html/ -type f -exec chmod 664 {} \;

5.7 Editar el archivo wp-config.php cambiando el host al endpoint del RDS.

vim /var/www/dominio.com/public_html/wp-config.php
...
define('DB_HOST', 'ENDPOINT');
...

5.8 Salir guardando cambios.

6. A continuación, importaremos la base de datos al RDS.

6.1 Lo primero es descomprimir el archivo “.sql.gz” para dejarlo en formato “.sql” y facilitar su importación.

cd /home/ubuntu/
tar -xzvf db_name.sql.gz

6.2 Conéctate al RDS con el usuario y la contraseña del administrador, y el host/punto final correspondiente.

mysql -h ENDPOINT -u USUARIO -p
Enter password: **********

6.3 Toma nota de los datos en el archivo WordPress wp-config.php.

vim /var/www/domain.com/public_html/wp-config.php
…
define('DB_NAME', 'db_name’);
define('DB_USER', 'db_user');
define('DB_PASSWORD', 'password');
...

6.4 Crea la base de datos de WordPress.

CREATE DATABASE db_name;

6.5 Crear el usuario en la base de datos.

CREATE USER 'db_user'@'IP_EC2_instance' IDENTIFIED BY 'password';

Nota: Es necesario reemplazar “IP_EC2_instance” con la IP de la instancia EC2 (recomiendo la privada para que el tráfico sea mínimo y no sea necesario abandonar la red interna), y así aumentar la seguridad en la conexión con el RDS .

Por lo tanto, solo será posible la conexión entre la instancia EC2 y el RDS a través de ese usuario, de ninguna otra IP será posible esta conexión.

6.6 Dar privilegios de usuario en la base de datos.

GRANT ALL PRIVILEGES ON db_name.* TO 'db_user'@'IP_EC2_instance';
FLUSH PRIVILEGES;

6.7 Usa la base de datos recién creada.

use db_name;

6.8 Importar base de datos.

source /home/ubuntu/db_name.sql;

7. Ahora, será necesario instalar algunos servicios y hacer algunas configuraciones en la instancia:

7.1 Actualiza los paquetes.

sudo apt update

7.2 Instala NGINX, PHP y PHP-FPM.

sudo apt install nginx php7.0 php7.0-common php7.0-curl php7.0-mysql php7.0-mcrypt php7.0-fpm

7.3 Configura el host virtual o VHOST en “/etc/nginx/sites-available/domain.com”.

Antes de continuar, quiero explicar qué es VHOST; es un archivo en la configuración del servidor web, en este caso NGINX, para poder alojar varios sitios en el mismo servidor; Su función principal es enrutar cada dominio a su directorio raíz respectivo.
Su configuración más básica y funcional es la siguiente:

server {
        listen 80;
        server_name dominio.com www.dominio.com;

        root /var/www/dominio.com/public_html/;
        index index.php index.html;

        access_log /var/log/nginx/dominio-access.log;
        error_log /var/log/nginx/dominio-error.log;

        location / {
                try_files $uri $uri/ /index.php?$args;
                index index.php index.html;
        }

        location ~* \.(jpg|jpeg|gif|css|png|js|ico|html)$ {
                access_log off;
                expires max;
        }

        location ~ \.php$ {
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass unix:/run/php/php7.0-fpm.sock;
                fastcgi_index index.php;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        }
}

Explicamos cada directiva de manera general:

listen 80: El puerto a través del cual NGINX “escuchará”, si utiliza el certificado SSL, lo escuchará por 443.

server_name domain.com www.dominio.com: El nombre o dominio del sitio al que responderá.

root /var/www/domain.com/public_html/;: Se especifica la ruta al directorio donde se encuentra WordPress.

index index.php index.html: El orden en que buscará/leerá los archivos de índice.

access_log and error_log: Rutas para archivos de registro.

location /: Las configuraciones que están dentro de “{}” se aplican a todo el sitio (/).

location ~* \.(jpg|jpeg|gif|css|png|js|ico|html)$: Las configuraciones que están dentro de “{}” se aplican a todos los archivos con jpg, jpeg, gif, css, png, js, ico y html.

location ~ \.php$: Las configuraciones que están dentro de “{}” son necesarias para que el servidor interprete el código PHP.

fastcgi_pass unix:/run/php/php7.0-fpm.sock: Puerto o socket a través de los cuales PHP-FPM escucha.

7.4 Habilita el VHOST.

sudo ln -s /etc/nginx/sites-available/dominio.com /etc/nginx/sites-enabled/

7.5 Verifique la sintaxis de NGINX.

sudo nginx -t

7.6 Reiniciar NGINX.

sudo service nginx restart

7.7 Emular el sitio.

7.8 Opcionalmente, puedes instalar la extensión para Google Chrome llamada “IP del sitio web” para verificar la IP del servidor donde está cargando un sitio.

6.8

Y la IP aparecerá en las esquinas inferiores del navegador.

6.8b

7.9 Pruebe el sitio ingresando el dominio en el navegador (ejemplo).

80

8. Finalmente, una vez que se ha verificado la funcionalidad correcta del sitio migrado, se debe cambiar el DNS apuntando al nuevo servidor.

En este caso, demostrativamente, se realizará en AWS Route53.

8.1 En la consola de AWS, navega hasta el servicio Route53.

7.1
7.2

8.3 Selecciona el dominio para modificar.

7.3

8.4 Selecciona el registro A del sitio principal y cambia la IP para el nuevo servidor. Guardar cambios.

7.4

9 Espera a que se extienda el cambio, esto puede demorar varios minutos, puedes verificar el progreso de este margen en la página https://www.whatsmydns.net/.

8

Conclusión

Como resultado, el sitio migrado o el WordPress, en este caso, podrá configurarse de una manera optimizada para las necesidades del mismo, pero la más importante, con Nginx como Web Server lo cual hace al WordPress más rápido; además, en una instancia EC2, tiene el control total de dicha instancia, ya que no es compartida y tampoco tiene instalado algún panel de control invasivo.

Los siguientes pasos son la optimización de la instancia EC2 y WordPress, hardening de la misma, mejorar el pagespeed de Google, automatizar respaldos de seguridad (backups); esto lo puede encontrar en blogs o tutoriales en este sitio.

En Clickittech, estamos familiarizados con todas estas herramientas y capacitados para realizar estos servicios de la manera más completa y rápida, buscando siempre su completa satisfacción.

Olvídate de tiempos muertos y haz una migración exitosa a AWS.

Consulta con nuestros expertos

1 Comment

  • Pedro Herrera Responder

    Hola Guillermo. tenemos unos sitios menos de 3MB cada uno WP/Woocommerce compartidos en A2 Hosting. Son Ecommerce B2C para vender productos principalmente de USA para hispanos residentes en America del Norte y Latinoamerica principalmente. Nos gustaria migrar a AWS, pero quisieramos tener una idea de cuanto seria los costos asociados, actualmente $100/mes entre Hosting, Cloud y SSL. Tienes idea del presupuesto que necesitariamos y cuanto nos costaria tu ayuda para migrar?

Leave a Reply

Your email address will not be published.

Google Analytics Alternative