Práctica 1.11

Implantación de Aplicaciones Web

Curso 2024/2025

1 Implantación de Wordpress en AWS utilizando una arquitectura de tres niveles

En esta práctica tendrá que realizar la instalación de un sitio WordPress haciendo uso de los servicios de Amazon Web Services (AWS).

1.1 Arquitectura

Deberá desplegar la última versión de Worpress utilizando la siguiente arquitectura de tres niveles.

La arquitectura estará formada por:

Necesitará crear las siguientes máquinas virtuales:

1.2 Fases de la práctica

Tendrá que resolver la práctica en diferentes fases, documentando en cada fase todos los pasos que ha ido realizando. El repositorio final tiene que contener un directorio para cada una de las fases donde se incluyan los scripts y archivos de configuración utilizados para su resolución.

práctica-wordpress-lamp
  .
  ├── fase00
  ├── fase01
  └── fase02

Las fases que tendrá que resolver son las siguientes:

Cada una de las fases debe incluir dos directorios:

A continuación se muestra un ejemplo del contenido final que debería tener el directorio fase-02.

└── fase-02
    ├── infraestructure
    │   ├── 00-terminate_all_instances.sh
    │   ├── 01-delete_all_security_groups.sh
    │   ├── 02-delete_all_elastic_ips.sh
    │   ├── 03-create_security_groups.sh
    │   ├── 04-create_instances.sh
    │   └── 05-create_elastic_ip.sh
    └── software
        ├── conf
        │   ├── 000-default-frontend.conf
        │   └── 000-default-loadbalancer.conf
        ├── config.sh
        ├── install_backend.sh
        ├── install_frontend.sh
        ├── install_loadbalancer.sh
        ├── install_nfs_client.sh
        ├── install_nfs_server.sh
        └── install_wordpress.sh

1.3 Tareas a realizar

A continuación se describen muy brevemente algunas de las tareas que tendrá que realizar sobre cada una de las máquinas.

1.3.1 Balanceador de carga

1.3.2 NFS Server (Capa de Frontend)

1.3.3 Servidores web (Capa de Frontend)

1.3.4 Servidor de base de datos (Capa de Backend)

1.4 Sincronización del contenido estático en la capa de Front-End

Al tener varias máquinas en la capa de Front-End tenemos que tener en cuenta que podemos tener algunos problemas a la hora de guardar contenido estático en el directorio uploads, instalar nuevos themes o instalar nuevos plugins, ya que estos contenidos se guardarán sobre el sistema de ficheros del frontal web que esté atendiendo nuestra petición. El contenido estático se almacena en el directorio wp-content.

Por ejemplo, puede ocurrir que hayamos instalado un nuevo plugin en uno de los frontales web y que el resto de frontales no tengan constancia de que este nuevo plugin ha sido instalado. También puede ocurrir que cuando uno de los frontales web esté fuera de servicio todo el contenido del directorio uploads estará inaccesible.

Para resolver este problema tenemos varias opciones:

  1. Utilizar almacenamiento compartido por NFS del directorio /var/www/html entre todos los servidores de la capa de front-end.
  2. Utilizar un sistema de almacenamiento distribuido seguro con GlusterFS.
  3. Utilizar un sistema de almacenamiento distribuido seguro con CephFS.

1.4.1 Opción 1: NFS (Network File System)

Inconveniente: La máquina que actúa como servidor NFS es un SPOF (Single Point of Failure).

Podemos utilizar NFS para que los servidores de la capa de front-end compartan el directorio /var/www/html. Si utilizamos esta opción podemos hacerlo de dos formas:

Ejemplo de configuración de un cliente/servidor NFS

Vamos a suponer que tenemos dos máquinas con la siguientes IPs:

1.4.1.1 Paso 1: Instalación de paquetes

Instalación de paquetes necesarios en el servidor NFS:

sudo apt update
sudo apt install nfs-kernel-server -y

Instalación de paquetes necesarios en el cliente NFS:

sudo apt update
sudo apt install nfs-common -y

1.4.1.2 Paso 2: Exportamos el directorio en el servidor NFS

Cambiamos los permisos al directorio que vamos a compartir:

sudo chown nobody:nogroup /var/www/html

Editamos el archivo /etc/exports:

sudo nano /etc/exports

Solución para compartir el directorio con una dirección IP

Añadimos la siguiente línea:

/var/www/html 192.168.33.12(rw,sync,no_root_squash,no_subtree_check)

Donde 192.168.33.12 es la IP del cliente NFS con el que queremos compartir el directorio.

Solución para compartir el directorio con un rango de IPs

Si quisiéramos compartir el directorio con todos los equipos de la subred 192.168.33.0/24 tendríamos que añadir la siguiente línea:

/var/www/html 192.168.33.0/24(rw,sync,no_root_squash,no_subtree_check)

En la documentación oficial podemos consultar una descripción detallada de cada uno de los parámetros utilizados en el archivo /etc/exports.

1.4.1.3 Paso 3: Reiniciamos el servicio NFS

sudo systemctl restart nfs-kernel-server

NOTA: Tenga en cuenta que para que el servicio de NFS pueda funcionar tendrá que abrir el puerto 2049 para poder aceptar conexiones TCP.

1.4.1.4 Paso 4: Creamos el punto de montaje en el cliente NFS

sudo mount 192.168.33.11:/var/www/html /var/www/html

Donde 192.168.33.11 es la IP del servidor NFS que está compartiendo el directorio.

Una vez hecho esto comprobamos con df -h que le punto de montaje aparece en el listado.

$ df -h

udev                                    490M     0  490M   0% /dev
tmpfs                                   100M  3.1M   97M   4% /run
/dev/sda1                               9.7G  1.1G  8.6G  12% /
tmpfs                                   497M     0  497M   0% /dev/shm
tmpfs                                   5.0M     0  5.0M   0% /run/lock
tmpfs                                   497M     0  497M   0% /sys/fs/cgroup
192.168.33.11:/var/www/html             9.7G  1.1G  8.6G  12% /var/www/html
tmpfs                                   100M     0  100M   0% /run/user/1000

1.4.1.5 Paso 5: Editamos el archivo /etc/fstab en el cliente NFS

Editamos el archivo /etc/fstab para que al iniciar la máquina se monte automáticamente el directorio compartido por NFS.

sudo nano /etc/fstab

Añadimos la siguiente línea:

192.168.33.11:/var/www/html /var/www/html  nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0

Donde 192.168.33.11 es la IP del servidor NFS que está compartiendo el directorio.

En la documentación oficial podemos consultar una descripción detallada de cada uno de los parámetros utilizados en el archivo /etc/fstabs.

1.4.2 Opción 2: GlusterFS

Otra opción es hacer uso de GlusterFS, que es un sistema de archivos multiescalable para NAS.

Puede encontrar más información sobre cómo crear un grupo de almacenamiento redundante con GlusterFS en la guía de Mark Drake publicada en DigitalOcean.

Fuente de la imagen: DigitalOcean.

1.4.3 Opción 3: CephFS

Ceph es un sistema de almacenamiento distribuido de código abierto.

Puede encontrar más información en la documentación oficial.

Fuente de la imagen: Ceph storage on Ubuntu: An overview.

1.5 Instalación de WordPress sobre un directorio que no es el raíz

Si hemos realizado la instalación de WordPress sobre un directorio que no es el raíz tendremos que realizar dos pasos adicionales.

Por ejemplo, si tenemos los archivos de WordPress en el directorio /var/www/html/wordpress en lugar de tenerlos en el directorio /var/www/html tendremos que configurar la dirección de WordPress (WP_SITEURL) y la dirección del sitio (WP_HOME).

1.5.1 Dirección de WordPress (WP_SITEURL) y Dirección del sitio (WP_HOME)

Las variables de Dirección de WordPress (WP_SITEURL) y Dirección del sitio (WP_HOME) se pueden configurar:

Si hemos realizado la instalación de WordPress sobre el directorio wordpress tendremos que asignarles los siguientes valores:

Donde NOMBRE_DEL_DOMINIO será el nombre de dominio que ha reservado para su sitio web. Observe que hemos utilizado https, porque su sitio web tendrá que utilizar un certificado HTTPS.

Si quiere realizar pruebas sin tener un nombre de dominio, puede hacerlas utilizando en su lugar la dirección IP púbica del balanceador de carga.

1.5.2 Configuración de WordPress en un directorio que no es el raíz

Realiza las siguientes acciones en cada uno de los frontales web:

/** Loads the WordPress Environment and Template */
require( dirname( __FILE__ ) . '/wp-blog-header.php' );

Por esta línea de código:

/** Loads the WordPress Environment and Template */
require( dirname( __FILE__ ) . '/wordpress/wp-blog-header.php' );

Donde wordpress es el directorio donde se encuentra el código fuente de WordPress que hemos descomprimido en pasos anteriores.

1.6 Configurar los enlaces permanentes

Compruebe que existe un archivo .htaccess en el directorio /var/www/html/ con un contenido similar a este:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Para que el contenido de los archivos .htaccess sea interpretado por el servidor web Apache tendrá que incluir la directiva AllowOverride All en el archivo de configuración de Apache.

También deberá habilitar el módulo rewrite en cada uno de los servidores web de la capa de FrontEnd. Puede hacerlo ejecutando el siguiente comando.

sudo a2enmod rewrite

Después de habilitar el módulo deberá reiniciar el servicio de Apache.

sudo systemctl restart apache2

1.7 Configuración de la variable $_SERVER['HTTPS']

Como el certificado HTTPS solo se ha instalado en el servidor Apache que está haciendo de proxy inverso, vamos a tener algunos problemas con las respuestas que le devuelven los servidores de la capa de Frontend al proxy inverso (balanceador de carga). Puede ocurrir que la respuesta incluya referencias al contenido del sitio web con el protocolo http y https. Para forzar que las referencias de los servidores web de la capa de Frontend siempre sean para el protocolo https tenemos que incluir la variable $_SERVER['HTTPS'] en el archivo wp-config.php y configurarla como on.

$_SERVER['HTTPS'] = 'on';

Referencia:

1.8 Configuración de las Security Keys

Podemos mejorar la seguridad de WordPress configurando las security keys que aparecen en el archivo wp-config.php.

En la documentación oficial podemos encontrar el motivo por el que nos recomiendan configurar estas security keys y cómo podemos hacerlo.

1.9 Tutorial de referencia

1.10 Entregables

En esta práctica habrá que entregar un documento técnico con la descripción de los pasos que se han llevado a cabo durante todo el proceso.

El documento debe incluir como mínimo lo siguientes contenidos:

2 Referencias

3 Licencia

Licencia de Creative Commons
Esta página forma parte del curso Implantación de Aplicaciones Web de José Juan Sánchez Hernández y su contenido se distribuye bajo una licencia Creative Commons Reconocimiento-NoComercial-CompartirIgual 4.0 Internacional.