Configuración de Docker Swarm con Alta Disponibilidad para WordPress

Configuración de Docker Swarm con Alta Disponibilidad para WordPress

Autor: Mariano Ismael García Guzmán Fecha: 04 de diciembre de 2024 Categoría: DevOps

¡Bienvenidos a esta guía donde aprenderemos a configurar un clúster Docker Swarm con alta disponibilidad (HA) para desplegar un servicio de CMS (WordPress) con tres réplicas! Esta práctica está diseñada para ayudarte a entender cómo implementar y gestionar servicios en un entorno de clúster.

Tabla de Contenidos

  1. Instalación de los Docker Hosts
  2. Despliegue del CMS con Réplicas
  3. Habilitación de Alta Disponibilidad (HA)
  4. Diagrama de Red del Clúster
  5. Funcionamiento del Clúster
  6. Respaldo y Recuperación del Servicio
  7. Ventajas y Desventajas Observadas

1. Instalación de los Docker Hosts

Requisitos Previos

  • Tres servidores con sistema operativo Linux (Ubuntu 20.04 recomendado).
  • Acceso con privilegios de sudo en cada nodo.
  • Conectividad de red entre los nodos.

Pasos de Instalación

a. Actualizar los Paquetes en Cada Nodo

sudo apt update
sudo apt upgrade -y

b. Instalar Docker en Cada Nodo

Ejecuta en cada nodo:

sudo apt install -y apt-transport-https ca-certificates curl gnupg-agent software-properties-common

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io

c. Verificar la Instalación de Docker

sudo docker version

d. Configurar Docker Swarm

i. Inicializar el Nodo Manager

En el nodo1, inicializa el swarm:

sudo docker swarm init --advertise-addr <IP_DEL_NODO1>

Anota el comando docker swarm join que se muestra; lo necesitarás para agregar los otros nodos.

Comando Swarm Join

ii. Agregar Nodos Workers al Swarm

En nodo2 y nodo3, ejecuta:

sudo docker swarm join --token <TOKEN_DEL_SWARM> <IP_DEL_NODO1>:2377

Nodos Workers Agregados

e. Verificar el Estado del Swarm

En el nodo1, ejecuta:

sudo docker node ls

Deberías ver algo como esto:

Estado del Swarm


2. Despliegue del CMS con Réplicas

a. Crear una Red Overlay

sudo docker network create -d overlay --attachable my-overlay

b. Desplegar el Servicio de Base de Datos (MySQL)

sudo docker service create \
  --name mysql \
  --network my-overlay \
  --env MYSQL_ROOT_PASSWORD=<TU_CONTRASEÑA> \
  --env MYSQL_DATABASE=wordpress \
  --env MYSQL_USER=wordpress_user \
  --env MYSQL_PASSWORD=<TU_CONTRASEÑA> \
  --replicas 1 \
  mysql:5.7

c. Desplegar el Servicio de WordPress con 3 Réplicas

sudo docker service create \
  --name wordpress \
  --network my-overlay \
  --publish 80:80 \
  --replicas 3 \
  --env WORDPRESS_DB_HOST=mysql \
  --env WORDPRESS_DB_USER=wordpress_user \
  --env WORDPRESS_DB_PASSWORD=<TU_CONTRASEÑA> \
  --env WORDPRESS_DB_NAME=wordpress \
  wordpress:latest

d. Verificar los Servicios

Comprueba que los servicios están en ejecución:

sudo docker service ls

Para ver detalles de un servicio específico:

sudo docker service ps wordpress

3. Habilitación de Alta Disponibilidad (HA)

Docker Swarm ofrece HA de forma nativa al gestionar las réplicas y distribuirlas entre los nodos.

a. Configurar Almacenamiento Persistente

Para asegurar la persistencia de datos, es recomendable utilizar volúmenes.

i. Servicio MySQL con Volumen

Elimina el servicio MySQL existente:

sudo docker service rm mysql

Crea el servicio MySQL con volumen:

sudo docker service create \
  --name mysql \
  --network my-overlay \
  --env MYSQL_ROOT_PASSWORD=<TU_CONTRASEÑA> \
  --env MYSQL_DATABASE=wordpress \
  --env MYSQL_USER=wordpress_user \
  --env MYSQL_PASSWORD=<TU_CONTRASEÑA> \
  --mount type=volume,source=mysql-data,target=/var/lib/mysql \
  --replicas 1 \
  mysql:5.7

ii. Servicio WordPress con Volumen

Elimina el servicio WordPress existente:

sudo docker service rm wordpress

Crea el servicio WordPress con volumen:

sudo docker service create \
  --name wordpress \
  --network my-overlay \
  --publish 80:80 \
  --replicas 3 \
  --env WORDPRESS_DB_HOST=mysql \
  --env WORDPRESS_DB_USER=wordpress_user \
  --env WORDPRESS_DB_PASSWORD=<TU_CONTRASEÑA> \
  --env WORDPRESS_DB_NAME=wordpress \
  --mount type=volume,source=wp-data,target=/var/www/html \
  wordpress:latest

4. Diagrama de Red del Clúster

A continuación, se presenta un diagrama simplificado de la arquitectura del clúster:

  • Nodos: Nodo1 (Manager), Nodo2 y Nodo3 (Workers).
  • Red Overlay: my-overlay que conecta todos los servicios.
  • Servicios: MySQL y WordPress distribuidos en los nodos.
  • Acceso de Usuarios: A través del puerto 80, balanceado entre las réplicas de WordPress.

Respaldos


5. Funcionamiento del Clúster

a. Acceder a WordPress

Desde un navegador web, visita:

http://<IP_DE_CUALQUIER_NODO>

Deberías ver algo como esto:

Página de WordPress

b. Verificar la Distribución de las Réplicas

En el nodo manager:

sudo docker service ps wordpress

Distribución de Réplicas

c. Simular un Fallo

Para probar la HA, detén Docker en uno de los nodos:

sudo systemctl stop docker

Verifica que las réplicas se redistribuyen:

Fallo en Nodo3

Los otros nodos siguen operativos:

Nodo1

Nodo2


6. Respaldo y Recuperación del Servicio

a. Respaldar Volúmenes

Para MySQL:

sudo docker run --rm \
  -v mysql-data:/data \
  -v $(pwd):/backup \
  ubuntu tar cvf /backup/mysql-data-backup.tar /data

Para WordPress:

sudo docker run --rm \
  -v wp-data:/data \
  -v $(pwd):/backup \
  ubuntu tar cvf /backup/wp-data-backup.tar /data

Respaldos

b. Restaurar Volúmenes

Para MySQL:

sudo docker run --rm \
  -v mysql-data:/data \
  -v $(pwd):/backup \
  ubuntu tar xvf /backup/mysql-data-backup.tar -C /

Para WordPress:

sudo docker run --rm \
  -v wp-data:/data \
  -v $(pwd):/backup \
  ubuntu tar x
vf /backup/wp-data-backup.tar -C /

7. Ventajas y Desventajas Observadas

Ventajas

  • Alta disponibilidad (HA).
  • Escalabilidad sencilla.
  • Balanceo de carga integrado.
  • Gestión centralizada.

Desventajas

  • Configuración inicial compleja.
  • Dependencia del nodo manager.
  • Persistencia de datos limitada sin almacenamiento distribuido.
  • Configuraciones adicionales necesarias para redes avanzadas.