Cloud IO Enabler Podcast
|
Más del 43% del sitios web en el mundo tienen como tecnología a WordPress, y en Ecuador más del 68% de sitios web son construidos con WordPress, por lo que es evidente que esta tecnología al día de hoy es la plataforma líder en CMS en el mundo, y es el porque debemos saber como implementar WordPress en AWS de forma correcta.
En este articulo vamos a presentar los aspectos más importantes a considerar al implementar WordPress en AWS, de forma que tengamos una instalación segura escalable y con tolerancia a fallos.
Contenido
Arquitectura WordPress
Lo primero a considerar es que WordPress es un sistema monolítico, por lo que el despliegue de nuevas versiones, su performance y la estrategia de alta disponibilidad debe ser concebida como un todo, y, no esta en un paradigma distribuido como es la propuesta de la Arquitectura de Microservicios.
El segundo aspecto es que hablamos de una arquitectura en tres capas: presentación, lógica y datos. La capa de presentación esta compuesta por archivos HTML, CSS, JS y PHP, la capa lógica esta compuesta por archivos PHP, y, la capa de datos esta administrada por el gestor de base de datos MySQL.
Explicado esto, dichos componentes están distribuidos en el sistema de archivos de la siguiente forma:
- wp-admin: Ejecutables de las herramientas de administración del sitio.
- wp-content: Todos los archivos que no son parte del CORE de WordPress y que son adicionados o eliminados de acuerdo a las decisiones del webmaster.
- wp-includes: Todos los archivos CORE para que el sitio web funcione, y ejecute funcionalidad como publicaciones, páginas, widgets y otras características.
- wp-config.php: Archivo maestro de credenciales de conexión y configuraciones principales de funcionamiento.
En esta lista faltan otros archivos, que han sido omitidos porque no son importantes para esta implementación de WordPress en AWS.
Plugins
Como es de dominio público, WordPress trae la funcionalidad básica de un CMS, pero al mismo tiempo es fácil extender su funcionalidad a través de plugins.
Los plugins añaden características al CMS como protecciones de seguridad, gestión avanzada de usuarios, integración con plataformas de terceros e incluso funcionalidad de tiendas en línea (e-commerce) o plataformas educativas online.
Adicionalmente, a través de plugins se puede incrementar plantillas gráficas o temas gráficos, que modifican la apariencia del sitio de acuerdo a lo deseado por el cliente.
Todos los archivos que forman parte de estas extensiones de funcionalidad son almacenados en la carpeta wp-content/plugins o wp-content/themes, y son gestionados por el administrador del CMS.
wp-content
Cabe señalar aparte este directorio, ya que como se explico en la arquitectura, allí se almacenan los archivos de la funcionalidad no estándar de WordPress.
Además en la carpeta wp-content/uploads, se almacenan los archivos multimedia del CMS (fotos, video y documentos).
Entonces, es de especial importancia entender que su contenido es dinámico, y que por lo tanto su contenido debería ser el mismo en caso de tener dos o más servidores que provean funcionalidad como un solo CMS.
Más adelante, veremos que es necesario externalizar esta carpeta, para permitir un escalamiento del CMS WordPress con más de un servidor.
Implementando WordPress en AWS en 5 minutos
Para implementar WordPress en AWS, inicialmente desde un punto de vista monolítico, vamos a utilizar el servicio de AWS llamado Amazon Lightsail (https://lightsail.aws.amazon.com/ls/webapp/home), porque nos da las herramientas más adecuadas para este primer paso.
Una vez dentro del servicio, creamos una instancia (https://lightsail.aws.amazon.com/ls/webapp/create/instance).
Luego seleccionamos el blueprint WordPress
Selecciona el plan mínimo (instance plan) para esta prueba y da finalizar.
En 5 minutos tendrás la instancia lista.
Deberías ver el servidor aprovisionado en la región Ohio Zone A.
Adicionalmente para los siguientes pasos, requieres saber que versión exacta de MySQL o MariaDB tienen instalado. Para esto puedes ir a la página http://<servidor-ip>/wp-admin/site-health.php?tab=debug y en la pestaña “Database” encontrarás esa información.
El usuario es “user” y el password lo puedes saber consultando el archivo “/home/bitnami/bitnami_credentials” mediante el terminal (icono siguiente).
Habilitando VPC Peering en Amazon Lightsail
En primer lugar debemos habilitar el VPC Peering entre Amazon Lightsail y los recursos aprovisionados fuera de este servicio, como es el caso de una base de datos Amazon RDS MySQL o unidad de red NFS gestionada con el servicioAmazon EFS.
Para esto ve a Amazon Lightsail (https://lightsail.aws.amazon.com/ls/webapp/home).
En la esquina superior derecha encontraras el menú “Account”, allí selecciona la opción también llamada “Account”.
En la pestaña “Advanced” vas a encontrar las opciones “VPC Peering” donde debes habilitarlo para los recursos aprovisionados fuera de Amazon Lightsail (en mi caso en Ohio).
Listo, ahora desde Amazon Lightsail podrás ver a nivel de red (exactamente de VPC) los recursos desplegados en la region de Ohio.
Conectando WordPress con Amazon RDS
El primer paso para poder aspirar a un esquema altamente disponible y resiliente es separar la base de datos.
En la implementación de WordPress en AWS usando un blueprint de Amazon Lightsail, el servidor resultante tiene tanto WordPress como la base de datos. Eso no es escalable dado que, a la base de datos, no podríamos ponerla en un esquema de alta disponibilidad sin afectar el todo.
Vamos a externalizar la base de datos con Amazon RDS, que nos permitirá en su modalidad Multi-AZ implementar este requerimiento.
Primero vamos a aprovisionar la base de datos en Amazon RDS (https://us-east-1.console.aws.amazon.com/rds/home).
En la parte superior derecha asegúrate que estas en la misma región donde creaste el servidor en Amazon Lightsail (en mi caso, si miras el gráfico es en Ohio Zona A)
Para la configuración elige las siguientes opciones:
- Creación estándar.
- Engine MariaDB con la versión 10.6.12 de acuerdo a lo identificado al crear el servidor en Amazon Lghtsail.
- Template Dev/Test para permitir Multi-AZ.
- Coloca una clave maestra (solo caracteres alfanuméricos).
- Tipo de instancia db.m6g.large por ser la menos costosa al día de esta publicación.
- Opción “Multi-AZ DB instance” para despliegue, creando una instancia standby.
- En configuraciones adicionales, crear una base de de datos inicial, como por ejemplo “wordpress”.
- Las demás opciones por defecto
La creación de una base de datos Multi-AZ va a tomar entre 10 a 20 minutos, por lo que deberás esperar antes de poder seguir al siguiente paso.
Aprovisionar una base de datos en Amazon RDS es fácil, pero configurarla apropiadamente de acuerdo a tu requerimiento real requiere conocer más este servicio. Esto tanto para no incurrir en gastos como para no subestimar o sobrestimar la instancia apropiada.
Si deseas conocer mas de este servicios te invito a visitar la Introducción a las bases de datos relacionales en Amazon RDS.
Por último obtén el endpoint de tu nueva base de datos, en el detalle de la base de datos creada.
Habilitación el Grupo de Seguridad
La habilitación del VPC Peering anterior permite la conexión entre la VPC de la región de Amazon Lightsail con la VPC por defecto de la región Ohio para nuestra cuenta.
Sin embargo, no existe una regla que permita el acceso al puerto de la base de datos Amazon RDS aprovisionada. Esto se debe hacer modificando el el grupo de seguridad al que pertenece la base de datos. En mi caso el sg-238da74a:
Así que dando click en el mismo, puedes ir al grupo y adicionar un “Inbound rule” con la IP interna del servidor WordPress en Lightsail, de forma que pueda acceder al puerto 3306 a cualquier instancia que este en ese grupo.
Usando Amazon RDS con WordPress
Bien, una vez que tenemos la base de datos creada, el grupo de seguridad configurado y habilitado el VPC Peering, podemos iniciar el proceso de conexión de nuestra instalación WordPress con esta base de datos.
Este es un tema más bien relacionado a DBAs, pero vamos a dejar las principales ideas de la migración y conexión:
En la consola de Amazon Lighsail identifica la instancia creada y da clic en el icono de linea de comandos “Terminal”.
mysqldump -u root -p bitnami_wordpress > /tmp/backup.sql
Para encontrar el password consulta el siguiente archivo:
cat bitnami_application_password
Restaura los datos en el endpoint de tu nueva base de datos Amazon RDS, por ejemplo con:
mysql -u dbmasteruser -p dbwordpress -h ls-cee65cedbb6cf04dde8adaebc6723f90c1471ab8.cygwzfiaau2b.us-east-2.rds.amazonaws.com < /tmp/backup.sql
Detén la base de datos local con:
sudo /opt/bitnami/ctlscript.sh stop mariadb
Modifica el archivo wp-config.php en la sección de conexión para que tu WordPress apunte a la instancia Amazon RDS.
Normalmente este archivo está en: “/home/bitnami/stack/wordpress” y debes editarlo como root.
Reinicia el servidor apache:
sudo /opt/bitnami/ctlscript.sh restart apache
Excelente, en este punto tu servidor WordPress ya esta trabajando en conjunto con Amazon RDS.
Externalizando el sistema de archivos WordPress en Amazon EFS
Para independizar los archivos que son dinámicos en WordPress, es necesario externalizar idealmente toda la carpeta wp-content.
Sin embargo, muchos archivos de plugins PHP son ejecutados en tiempo real cuando los usuarios del sitio Web acceden al contenido del CMS. Por esta razón se debe combinar esta estrategia con otras técnicas de memoria cache de dichos archivos, de forma que su ejecución sea en memoria o no acudiendo al fuente del sistema de archivos.
En este tutorial de WordPress en AWS no vamos a tomar en cuenta la configuración de cache, pero es un tema que debes considerar en una implementación de estas características.
El primer paso es crear una unidad de disco en el servicio Amazon EFS (https://us-east-1.console.aws.amazon.com/efs/home).
Asegúrate que estés el la misma región del servidor en Amazon Lightsail.
A continuación, selecciona la opción personalizada (Customize) al crearlo y configura los siguiente:
- Ubica un nombre para tu unidad
- Selecciona “Enhanced” en las opciones de Performance y deja la sub opción “Elastic”.
- Deja todas las demás opciones por defecto hasta finalizar la creación.
Verás la lista de unidades EFS una vez creada la unidad. Selecciona de la lista la unidad que acabas de crear y ingresa a la edición de la misma.
En el detalle selecciona la pestaña “Access points” y crea uno para que a través de este puedan conectarse tus servidores WordPress.
Deja todas las opciones por defecto y crea el Access point.
Una vez creado ingresa al Access point y a continuación da clic en “Attach” para ver las instrucciones de como montar esta unidad EFS en los servidores.
Toma nota de ese comando que lo necesitaremos más adelante.
Habilitación el Grupo de Seguridad
Del mismo modo que al aprovisionar la base de datos, al crear una unidad de almacenamiento en red Amazon RDS, vas a necesitar crear una regla “Inbound rule” para permitir que el servidor de Amazon Lightsail pueda ver dicho recurso.
El VPC Peering no va a ser suficiente ya que te garantiza que exista una camino para que las redes se vean, pero no para acceder al recurso específico.
Entonces, lo primero es identificar a que grupo de seguridad pertenece esta unidad, y eso se lo puede ver en la pestaña networking al visualizar la unidad Amazon EFS.
En mi caso es el mismo al que pertenece la base de datos, el sg-283da74a. Sobre este adicionamos la regla para permitir el acceso desde la IP privada del servidor Amazon Lightsail al puerto 2049 que es el usado por el servicio Amazon EFS.
Ve entonces a los grupos de seguridad (https://us-east-2.console.aws.amazon.com/ec2/home?region=us-east-2#SecurityGroups:) y ubica el mismo.
Adiciona la regla.
Listo, con esto tu servidor puede acceder a la unidad de red.
Conectar la unidad Amazon EFS con el servidor WordPress
La tarea aún no ha finalizado, pues debemos montar esta unidad en nuestro servidor Amazon Lightsail y redireccionar el contenido de wp-content en la instalación a esta unidad Amazon EFS.
A continuación , vamos a ingresar al servidor a través de la línea de comandos.
Una vez allí ejecutamos los siguientes comandos:
sudo apt-get install -y netcat
sudo apt-get install -y nfs-common
sudo apt-get install -y nfs-common
nc -zv <ip-access-point> 2049
sudo mkdir /mnt/efs
sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport <ip-access-point>:/ /mnt/efs
Ve al directorio de instalación de WordPress, normalmente en “/home/bitnami/stack/wordpress”.
Sincronizar directorio wp-content en /mnt/efs/wp-content/ (‘sudo rsync -a –progress wp-content/ /mnt/efs/wp-content/’)
Renombra los directorios: wp-content a wp-content_old (‘sudo mv wp-content wp-content_old’)
Elimina el directorio antiguo y crea un symlink al nuevo para wp-content
sudo rm -Rf ./wp-content
sudo ln -s /mnt/efs/wp-content/ ./wp-content
Desactiva y desinstala el plugin jetpack (por un tema de cache), y a continuación reinicia el servidor apache:
sudo wp plugin deactivate jetpack
sudo wp plugin uninstall jetpack
sudo /opt/bitnami/ctlscript.sh restart apache
Felicitaciones, has conectado exitosamente tu instalación de WordPress con Amazon EFS, y de esta forma has externalizado tus archivos dinámicos.
Habilitando WordPress con Amazon Elastic Load Balancer (ELB)
Para implementar WordPress en AWS en alta disponibilidad y con tolerancia a fallos necesitamos más de un servidor que atienda las peticiones de los clientes.
Para esto AWS nos proveer de balanceadores de carga, que direccionarán las peticiones a el servidor menos cargado y que este disponible.
El primer paso es ir a la consola de Amazon Lightsail en la pestaña de opciones “Networking” (https://lightsail.aws.amazon.com/ls/webapp/home/networking).
Creamos un balanceador con un nombre apropiado para nuestra instalación.
Al crear el balanceador, el siguiente paso es adicionar el servidor WordPress a este balanceador.
Ahora, ya tendrás publicado el balanceador y podrás acceder a tu sitio web a través de tu endpoint del mismo.
Implementando Alta Disponibilidad (HA) en WordPress
Finalmente vamos a crear un servidor adicional del mismo WordPress para adicionarlo a la configuración y obtener el beneficio de alta disponibilidad en caso de muchas peticiones y tolerancia a fallos en caso de que falle el original.
El primer paso es ingresar a la consola Amazon Lightsail (https://lightsail.aws.amazon.com/ls/webapp/home/instances) y ingresar a la edición del servidor actual de WordPress.
En la pestaña “Snapshots” creamos un snapshot del servidor.
Creado el snapshot vamos a lanzar un servidor con este como template.
Asegúrate que el servidor a aprovisionar este en la misma región (en mi caso Ohio) y sea el mismo tipo de instancia.
Deja las demás opciones por defecto y dar “Crear Instancia”.
Ingresa a este nuevo servidor, a la línea de comandos.
Identifica la IP privada del servidor.
ip addr
Añade la IP (en mi caso 172.26.14.214) con “Inbound Rule” al grupo de seguridad sg-238da74a, de la siguiente forma:
- Una regla para acceso al puerto donde se accede a la unidad Amazon EFS.
- Una regla para acceso al puerto donde se accede a la base de datos Amazon RDS.
Monta la unidad Amazon EFS en el nuevo servidor con el mismo comando inicial del servidor original.
sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport 172.31.3.222:/ /mnt/efs
Listo, tu servidor esta lito para adicional al stack de servidores gestionados por el balanceador.
A continuación ve a Amazon Lightsail en la pestaña “Networking” (https://lightsail.aws.amazon.com/ls/webapp/home/networking), e ingresa al balanceador.
Adiciona el nuevo servidor al stack.
¡FELICITACIONES! haz implementado WordPress en AWS en alta disponibilidad y tolerancia a fallos.
Resumen de la arquitectura WordPress en AWS.
Acabamos de implementar WordPress en AWS en una arquitectura de alta disponibilidad y tolerancia a fallos. Los punto a destacar son:
- Tenemos una base de datos redundante gracias a el aprovisionamiento en Amazon RDS Multi-AZ.
- Tenemos resiliencia en el sistema de archivos dinámico de WordPress gracias a la unidad aprovisionada en Amazon EFS.
- Tenemos alta disponibilidad y tolerancia a fallos, con dos servidores que entregan el servicio y un balanceador que gestiona las peticiones; esto gracias a Amazon Lightsail.
Video implementacion WordPress en AWS
Si deseas seguir este tutorial paso a paso en video puedes verlos aquí:
Recomendaciones
- Esta arquitectura es referencial, y por supuesto en una real hay muchas cosas que se pueden mejorar como el tema de cache, dimensionamiento de los tipos de instancias y adición de un CDN por ejemplo.
- Un tema delicado es Amazon EFS, puesto que la capacidad de I/O va a ser fundamental en el desempeño del todo. Por esto es importante optimizarla y monitorearla de forma contante.
- Hay que tomar en cuenta que la base de datos, en mi experiencia, es un 50% del desempeño del sitio. Al tener este recurso en Amazon RDS no obliga a pensar en las capacidades que tiene que tener, en red en I/O y el afinamiento de performance. Además al estar en un esquema Multi-AZ, cualquier cambio puede tardar más de 20 minutos, por lo tanto en importante seleccionar las opciones de este recurso con cuidado y a vista de un 50% adicional de rendimiento.
- Hay temas omitidos acá, como los certificados SSL, que son un no negociable en un esquema de producción.
- Adicionar un CDN es una fantástica idea, por dos motivo principales: uno el performance que se ba a ganar en la solicitud de recursos de imágenes y multimedia, y, la más importante es que nos va a ayudar a minimizar múltiples ataques de red previamente a la solicitud al servicio WordPress.
- Exite un whitepaper dedicado a las mejores prácticas de este caso de uso, lo puedes mirar en Mejores prácticas para WordPress en AWS.
Esperamos que sea útil esta tutoríal para implementar WordPress en AWS en HA y Failover y les animamos para que dejen sus comentarios y opiniones para aprender en comunidad.