🎨 Sysprovider Code
Sysprovider LogoWiki
🇪🇸Hosting español para ecommerce

WordPress Multisitio con Microservicios y Contenedores Docker en 2025

Actualizado el 5 de enero de 2026

Introducción: El nuevo paradigma de los sitios masivos con WordPress

En 2025, la arquitectura monolítica de WordPress ha quedado atrás para los proyectos que buscan escalar de verdad. La combinación de WordPress multisitio con microservicios desplegados en contenedores Docker y orquestados por Kubernetes se ha consolidado como el estándar de facto para gestionar decenas, cientos o incluso miles de sitios desde una única base de código, pero con la flexibilidad de un ecosistema distribuido.

Este artículo no es una guía para instalar un LAMP con wp-cli. Es una inmersión técnica profunda en cómo diseñar, desplegar y mantener una arquitectura escalable que aproveche al máximo la naturaleza de red de WordPress multisitio, rompiendo sus limitaciones históricas mediante la contenerización y la orquestación.

¿Por qué WordPress Multisitio con Docker y Microservicios en 2025?

La pregunta no es si debes hacerlo, sino cómo. Las ventajas son contundentes:

  • Aislamiento de recursos: Cada sitio (o grupo de sitios) puede tener sus propios límites de CPU, RAM y E/S, evitando el efecto "vecino ruidoso".
  • Escalado granular: No escalas todo el monstruo. Escalas el servicio de nginx, el de php-fpm, el de cron, o incluso el de la base de datos por separado.
  • Despliegue inmutable: Los contenedores son efímeros. Actualizar un plugin o la versión de PHP implica construir una nueva imagen y desplegarla sin tocar el estado.
  • Dev/Prod parity: El mismo docker-compose.yml o Helm chart funciona en tu máquina, en staging y en producción con Kubernetes.
  • Facilidad de mantenimiento: Un fallo en un contenedor de un sitio no derriba toda la red. Kubernetes lo reinicia automáticamente.

[INFO] Aunque WordPress multisitio comparte la tabla wp_users y wp_blogs, los microservicios nos permiten aislar las cargas de trabajo de plugins pesados (WooCommerce, LMS) en pods separados, manteniendo la red central ligera.

Componentes Clave de la Arquitectura

No se trata solo de meter WordPress en un contenedor. La arquitectura se descompone en varios servicios independientes que se comunican entre sí.

2.1 El Orquestador: Kubernetes (K8s)

Kubernetes es el cerebro. Gestiona el ciclo de vida de los contenedores, el balanceo de carga, el descubrimiento de servicios y el almacenamiento persistente. Para WordPress multisitio, necesitas al menos:

  • Deployments: Para wordpress-php, nginx, varnish (opcional), cron.
  • StatefulSets: Para bases de datos (MariaDB/Galera) o sistemas de archivos distribuidos (Longhorn, Ceph).
  • Services: Para exponer internamente cada microservicio (ej: service/wordpress-php:9000).
  • Ingress Controller: (Traefik, NGINX Ingress) para enrutar *.midominio.com al pod de nginx correcto.

2.2 El Corazón: WordPress PHP-FPM

Cada sitio o grupo de sitios puede ejecutar su propia instancia de PHP-FPM. La clave está en la configuración de wp-config.php para que sea consciente del multisitio:

// wp-config.php para multisitio en Kubernetes
define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true); // O false si usas subdirectorios
define('DOMAIN_CURRENT_SITE', $_SERVER['HTTP_HOST'] ?? 'default.midominio.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

// Cache de objetos con Redis (microservicio aparte)
define('WP_REDIS_HOST', 'redis-service');
define('WP_REDIS_PORT', 6379);

2.3 El Proxy y el Balanceo: NGINX + Varnish

NGINX actúa como proxy inverso y terminación SSL. Varnish (o similar) como caché HTTP de página completa. La configuración debe ser dinámica para cada subdominio.

# Fragmento de nginx.conf para multisitio con microservicios
upstream php-upstream {
    server wordpress-php-service:9000;
}

server {
    listen 443 ssl http2;
    server_name ~^(?<subdomain>.+)\.midominio\.com$;

    root /var/www/html;
    index index.php;

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

    location ~ \.php$ {
        fastcgi_pass php-upstream;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
        # Pasar el subdominio a WordPress
        fastcgi_param HTTP_HOST $subdomain.midominio.com;
    }
}

[TIP] Para redes con miles de sitios, evita el try_files genérico. Usa un mapa de $uri a $blog_id en NGINX para redirigir directamente al wp-content/blogs.dir/{id}/ sin tocar PHP.

2.4 Almacenamiento Persistente: El Talón de Aquiles

WordPress multisitio asume que los archivos (uploads, plugins, themes) están en un sistema de archivos compartido. En Kubernetes, esto se soluciona con:

  • NFS / GlusterFS / CephFS: Clásico, pero con limitaciones de rendimiento.
  • Longhorn (recomendado): Almacenamiento de bloque distribuido para Kubernetes. Cada pod monta su propio volumen.
  • S3 y Object Storage: Para los uploads, con un plugin como WP Offload Media. Los plugins y themes se empaquetan en la imagen Docker.
# PersistentVolumeClaim para uploads de un sitio específico
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: uploads-site-123
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi
  storageClassName: longhorn

Diseñando la Red Multisitio con Microservicios

Aquí es donde la teoría se encuentra con la práctica. No todos los sitios de la red son iguales.

3.1 Estrategia de Agrupación de Sitios

Divide los sitios en "pools" según su perfil de carga:

  • Pool Gold (Alto tráfico, WooCommerce): Pods dedicados con 4 vCPU, 8GB RAM, Redis dedicado, y caché de página completa.
  • Pool Silver (Blogs medianos): Comparten pods de PHP, pero con límites de recursos estrictos.
  • Pool Bronze (Sites estáticos o de poco tráfico): Servidos directamente por NGINX con páginas cacheadas en Varnish, sin tocar PHP.

Cada pool se despliega como un Deployment independiente en Kubernetes, con su propio HorizontalPodAutoscaler.

# Ejemplo de HPA para el pool Gold
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: wordpress-gold-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: wordpress-gold
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

3.2 Microservicios Auxiliares

No todo es PHP. Cada funcionalidad se convierte en un microservicio:

  • Servicio de Colas (RabbitMQ / Redis): Para procesar notificaciones, emails, importaciones CSV.
  • Servicio de Búsqueda (Elasticsearch / Meilisearch): Indexa el contenido de todos los sitios de la red.
  • Servicio de Imágenes (Thumbor / Imaginary): Redimensiona y optimiza imágenes bajo demanda.
  • Servicio de Cron (Kuberentes CronJob): Ejecuta wp cron event run para cada sitio sin depender del tráfico web.

Despliegue con Docker Compose (Desarrollo) y Helm (Producción)

4.1 Entorno de Desarrollo con Docker Compose

Para que el equipo pueda replicar la arquitectura localmente:

# docker-compose.yml para multisitio + microservicios
version: '3.8'
services:
  nginx:
    image: nginx:alpine
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
      - wordpress-data:/var/www/html
    ports:
      - "80:80"
    depends_on:
      - wordpress-php

  wordpress-php:
    build: ./images/php
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: secret
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - wordpress-data:/var/www/html
      - ./plugins:/var/www/html/wp-content/plugins
      - ./themes:/var/www/html/wp-content/themes

  db:
    image: mariadb:10.11
    environment:
      MYSQL_ROOT_PASSWORD: rootsecret
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: secret
    volumes:
      - db-data:/var/lib/mysql

  redis:
    image: redis:7-alpine

  elasticsearch:
    image: elasticsearch:8.12
    environment:
      - discovery.type=single-node

volumes:
  wordpress-data:
  db-data:

4.2 Producción con Helm Charts

Para Kubernetes, usa Helm. Existen charts públicos para WordPress, pero para multisitio con microservicios es mejor construir uno propio. Un values.yaml típico incluiría:

# values.yaml para Helm chart personalizado
global:
  domain: midominio.com
  multisite:
    enabled: true
    type: subdomain
    sites:
      - id: 1
        domain: tienda.midominio.com
        pool: gold
      - id: 2
        domain: blog.midominio.com
        pool: silver

wordpress:
  image: registry.midominio.com/wordpress-php:2025.1
  pools:
    gold:
      replicas: 3
      resources:
        requests:
          cpu: 2
          memory: 4Gi
        limits:
          cpu: 4
          memory: 8Gi
      autoscaling:
        enabled: true
        minReplicas: 2
        maxReplicas: 20
        targetCPUUtilizationPercentage: 70
    silver:
      replicas: 2
      resources:
        requests:
          cpu: 500m
          memory: 1Gi

database:
  provider: galera
  replicas: 3
  storage: 200Gi

cache:
  type: redis
  replicas: 3
  persistence:
    size: 10Gi

search:
  enabled: true
  type: elasticsearch
  replicas: 3

[WARNING] No uses el chart oficial de WordPress para multisitio en producción sin modificarlo. Asume una sola instancia. Necesitarás personalizar los Deployments, Services y la lógica de Ingress.

Gestión de Plugins y Themes en un Entorno Contenerizado

Este es uno de los mayores desafíos. En un entorno inmutable, no puedes instalar plugins a través del panel de administración.

Estrategias:

  1. Imagen Docker personalizada: Construye la imagen con todos los plugins y themes necesarios para la red. Cada actualización implica un nuevo build y despliegue.
  2. Volumen compartido de solo lectura: Monta un volumen NFS con los plugins, pero esto rompe el principio de inmutabilidad.
  3. GitOps con ArgoCD: Los plugins se definen como archivos en un repositorio Git. Un pipeline de CI/CD construye la imagen y ArgoCD la despliega.
# Dockerfile para imagen de WordPress con plugins preinstalados
FROM wordpress:6.7-php8.3-fpm-alpine

# Instalar wp-cli
RUN curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar \
    && chmod +x wp-cli.phar \
    && mv wp-cli.phar /usr/local/bin/wp

# Copiar plugins y themes desde el contexto de build
COPY plugins/ /var/www/html/wp-content/plugins/
COPY themes/ /var/www/html/wp-content/themes/

# Script de entrada para configurar multisitio dinámicamente
COPY entrypoint.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/entrypoint.sh
ENTRYPOINT ["entrypoint.sh"]

Monitoreo y Observabilidad

No puedes escalar lo que no mides. En 2025, el stack de observabilidad para WordPress multisitio incluye:

  • Prometheus + Grafana: Métricas de cada pod (PHP-FPM, NGINX, MySQL), colas de Redis, y métricas de negocio como número de visitas por sitio.
  • Loki + Promtail: Logs centralizados de todos los contenedores. Busca errores de PHP, 404s, o lentitud en consultas.
  • Jaeger / Tempo: Trazado distribuido para seguir una petición HTTP desde el Ingress hasta la base de datos, pasando por Redis y Elasticsearch.
# Ejemplo de ServiceMonitor para Prometheus Operator
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: wordpress-php-monitor
spec:
  selector:
    matchLabels:
      app: wordpress-php
  endpoints:
  - port: metrics
    interval: 15s

Casos de Uso Reales en 2025

  • Universidades: Una red de 500+ sitios para departamentos, cada uno con sus propios plugins y temas, pero gestionados centralmente. Los sitios de alto tráfico (admisiones) escalan automáticamente.
  • SaaS de membresía: Cada cliente tiene un subdominio en la red multisitio. La facturación se maneja como un microservicio aparte, y los pods de WordPress se escalan según el plan del cliente.
  • Redes de medios: Decenas de sitios de noticias regionales. La búsqueda unificada con Elasticsearch permite a los periodistas buscar contenido en toda la red.

Conclusión

La arquitectura de WordPress multisitio con microservicios y contenedores Docker en 2025 no es una moda, es una necesidad para proyectos que aspiran a crecer sin límites artificiales. La clave está en:

  1. Descomponer el monolito en servicios pequeños y especializados.
  2. Orquestar con Kubernetes para garantizar alta disponibilidad y escalado automático.
  3. Automatizar todo el ciclo de vida de los plugins y temas mediante CI/CD y GitOps.
  4. Observar cada componente con métricas, logs y trazas.

El camino no es sencillo. Requiere un equipo con habilidades en DevOps, Docker y Kubernetes. Pero el resultado es una plataforma que puede gestionar desde 10 hasta 10,000 sitios con la misma solidez y eficiencia.

[INFO] Si estás empezando, no intentes abarcar todo de golpe. Comienza con un docker-compose.yml para tu red de desarrollo, migra un sitio de prueba a un pod en Kubernetes, y luego escala gradualmente. El futuro del CMS más usado del mundo es distribuido, y ya está aquí.

¿Necesitas ayuda?Son dos de nuestros técnicos, Agustín y Mikel, y están disponibles para resolver cualquier problema.

Hablar con ellos ahora
Agustín y Mikel