590 - Mejorar WordPress en Docker

Algunas recomendaciones para mejorar el desempeño de #WordPress en #Docker junto a #Linux así como las novedades a #Traefik y #Navidrome

1:25

-3:15

0.8x 1.0x 1.2x 1.4x 1.6x 1.8x 2.0x

1.0x

Si bien, hasta la fecha estaba bastante satisfecho con los distintos WordPress que tengo levantados, lo cierto es que con las nuevas migraciones, he decidido o tenido que darles algo mas de cariño. Esto es así, porque parte de la configuración era manual, en el sentido que requería realizar algunos cambios de configuración. Por ejemplo, para configurar Redis, tenía que modificar el config.php. Sin embargo, esto no es ni mucho menos necesario, es posible definir los cambios necesarios en las variables de entorno del docker-compose.yml. Finalmente, he conseguido una combinación que me ha permitido acelerar considerablemente las nuevas instalaciones. Pero sobre todo, he conseguido hacerlas mas consistentes, y agnósticas, en el sentido que no necesito cambiar el docker-compose para levantar un nuevo sitio, solo las variables de entorno. Ahora solo me queda hacer un sencillo script que me permita generar automáticamente todas las variables de entorno y credenciales, pero esto para mas adelante. Así, te quiero hablar sobre como mejorar WordPress en Docker.

Mejorar WordPress en Docker

Actualizaciones

Antes de introducirme en el tema de hoy, quería mencionarte dos actualizaciones que me han llamado mucho la atención. Una por que es muy esperada y la segunda por inesperada.

La primera de las novedades es que se ha liberado la versión 3.0 de Traefik. Esto puede ser una conmoción en la fuerza como sucedió con el cambio de la versión 1.7 a la 2.0 o simplemente un paso hacia delante. Desde luego, por parte de los desarrolladores de Traefik, indican que simplemente se trata de un paso hacia delante. Además para evitar problemas han creado una herramienta que te permite migrar tu configuración de la versión 2.X a la 3.

Lo cierto es que todavía no he tenido la oportunidad de probar los cambios de esta nueva versión, pero no te preocupes, que en cuanto que lo haya probado subo la actualización al repositorio de GitHub para que veas cual ha sido mi configuración.

Por otro lado, ayer me llegó una nueva notificación de que WatchTower se había encargado de actualizar Navidrome. Si no conoces Navidrome te recomiendo este artículo, con vídeo incluido en el que te muestro las características y capacidades de este servidor de música
La cuestión, es que esta actualización me ha llamado mucho la atención básicamente porque hacía mucho tiempo. Al menos esa era la sensación que yo tenía, porque al revisar las actualizaciones de Navidrome, he comprobado que la anterior fue en febrero, y previa a esta la anterior se encuentra en enero. Así que no es para tanto.

Simplemente este servidor de música sigue siendo el mejor que he utilizado hasta el momento.

Mi configuración de WordPress

Estado actual

Hasta la fecha la configuración que tenía para levantar cada WordPress era la siguiente,

• WordPress
• Mariadb
• Backup
• Redis

Por supuesto, delante tenía Traefik como proxy inverso para distribuir el tráfico en función de los destinos. Esto lo tenía montado con dos redes. La red proxy que es la que permite conectarse desde el exterior a cada uno de los servicios, y una red internal para aquellos contenedores que no necesitan conexión con el exterior. De estas torma, solo WordPress está en ambas redes, mientras que el resto de contenedores solo se encuentran en la red internal.

Cambios en el docker-compose

Hasta ahora la configuración ha ido muy bien y no he tenido problema alguno. Sin embargo, con las nuevas páginas que he levantado, se me ha hecho muy pesado la configuración, dado que tenía que modificar el archivo wp-config.php, en cada una de ellas, y me parecía que esto no tenía sentido ninguno. Por esta razón, decidí implementar una nueva configuración. Esto básicamente era para cambiar la configuración de Redis. Ahora con la nueva configuración todo va por variables de entorno,

environment:
  WORDPRESS_DB_HOST: ${WORDPRESS_DB_HOST}
  WORDPRESS_DB_USER: ${WORDPRESS_DB_USER}
  WORDPRESS_DB_PASSWORD: ${WORDPRESS_DB_PASSWORD}
  WORDPRESS_DB_NAME: ${WORDPRESS_DB_NAME}
  WORDPRESS_TABLE_PREFIX: ${WORDPRESS_TABLE_PREFIX}
  WORDPRESS_CONFIG_EXTRA: |
    define( 'WP_REDIS_HOST', '${WP_REDIS_HOST}' );
    define( 'WP_REDIS_PORT', ${WP_REDIS_PORT} );
    define( 'WP_REDIS_PREFIX', '${FQDN}' );
    define( 'WP_REDIS_DATABASE', ${WP_REDIS_DATABASE} ); // 0-15
    define( 'WP_REDIS_TIMEOUT', ${WP_REDIS_TIMEOUT} );
    define( 'WP_REDIS_READ_TIMEOUT', ${WP_REDIS_READ_TIMEOUT} );

Por supuesto, todos estos parámetros los he definido en un archivo de configuración .env, de forma que no tengo que modificar el docker-compose.yml en cada instalación.

Otro de los cambios que he introducido, viene definido básicamente por Traefik. Todo con el objetivo de reducir las etiquetas que utilizo con cada contenedor. En este caso, por ejemplo, para el caso particular de WordPress queda de la siguiente forma,

labels:
  - traefik.enable: true
  - traefik.http.services.${ROUTER}-wordpress.loadbalancer.server.port: 80
  - traefik.http.routers.${ROUTER}-wordpress.rule: Host(`${FQDN}`)

Incluso podía definir exposedByDefault: true en la configuración de Traefik y me evitaría la primera línea.

Un detalle interesante es que he definido el $ROUTER también en el archivo de configuración, de esta forma tampoco necesito modificar este parámetro en el archivo docker-compose.yml. Es decir, para cualquier instalación

Otros cambios se refieren a los nombres de contenedores y volúmenes que los he normalizado en función también de la variable $ROUTER, todo para que después mediante scripts, pueda continuar trabajando de forma sencilla.

Nuevas imágenes

Aquí he introducido algunos cambios y he añadido un par de contenedores adicionales para intentar mejorar el desempeño de WordPress.

El primero de los cambios es utilizar wordpress:fpm-alpine en lugar del que venía utilizando hasta la fecha.

FPM o FastCGI Process Manager es una implementación de FastCGI con características enfocadas en la mejora del comportamiento de un sitio web. Algunas de las ventajas que ofrece FPM, son las siguientes,

• Buen rendimiento.
• Consumo de recursos moderado.
• Todas las ventajas de FastCGI.
• Más opciones de configuración que FastCGI.

Por otro lado, esto me obliga a intercalar una pieza intermedia entre WordPress y Traefik, que no es ni mas ni menos que Nginx. Sobre Nginx, todavía tengo pendiente añadir configuración adicional para mejorar el cacheo de las imágenes y demás archivos estáticos. Aunque por el momento lo que he dejado es lo siguiente,

server {
    listen 80;

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

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

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

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass wordpress:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }

    location ~* \.(?:jpg|jpeg|gif|png|ico|cur|gz|svg|svgz|mp4|ogg|ogv|webm|htc)$ {
        expires 7d;
        access_log off;
        add_header Cache-Control "public";
    }

    location ~* \.(?:svgz?|ttf|ttc|otf|eot|woff|woff2)$ {
        add_header Access-Control-Allow-Origin "*";
        expires 7d;
        access_log off;
    }

    location ~ /\. {
        access_log off;
        log_not_found off;
        deny all;
    }
}

Tengo que seguir trabajando sobre esto, pero esta primera aproximación quiero ver exactamente como funciona y las posibilidades y tiempos que maneja.

Además he añadido una nueva imagen que es phpmyadmin, mientras realizo configuraciones y otras pruebas

Respecto a la configuración de las redes, ahora queda como indico a continuación,

Red interna wordpress, mariadb, backup, redis, phpmyadmin, nginx
Red proxy: phpmyadmin, nginx

Más información,

• GitHub