Cómo mover WordPress a un contenedor de Linux

En este artículo, analizamos cómo migrar una instalación de WordPress de una instalación normal a un contenedor. En caso de que te lo hayas perdido, en un artículo anterior dimos una descripción general del proceso general que pretendemos utilizar.

Contenerizar WordPress parece tan engañosamente fácil. es un estándar batería de la lámpara, pero hay algunas trampas que queremos evitar. Los contenedores son en realidad dos cosas: imágenes de contenedores inactivos y procesos Linux en tiempo de ejecución. Echemos un vistazo a las dos partes: construir y ejecutar.

Para construir

WordPress necesita PHP y un servidor web. La configuración más común es usar Apache (o Nginx) con PHP FastCGI Process Manager (php-fpm) y un intérprete de PHP. De hecho, se puede crear una imagen de contenedor de propósito general para casi cualquier aplicación basada en PHP, incluidos WordPress y MediaWiki. Este es un ejemplo de cómo crear una imagen con Red Hat Universal Base Image:

FROM registry.access.tipstecnologicos.es/ubi8/ubi-init
MAINTAINER fatherlinux <[email protected]>
RUN yum install -y mariadb-server mariadb php php-apcu php-intl php-mbstring php-xml php-json php-mysqlnd crontabs cronie iputils net-tools;yum clean all
RUN systemctl enable mariadb
RUN systemctl enable httpd
RUN systemctl disable systemd-update-utmp.service
ENTRYPOINT ["/sbin/init"]
CMD ["/sbin/init"]

el ubi-init la imagen está configurada de fábrica para ejecutarse systemd el contenedor en tiempo de ejecución. Esto facilita la ejecución de algunos comandos durante la instalación y se basa en la experiencia en la materia integrada en la distribución de Linux. Como he dicho durante años, la calidad de la imagen del contenedor y la higiene de la cadena de suministro son más importantes que las imágenes individuales más pequeñas que podamos producir (Container Tidbits: Can Good Supply Chain Hygiene Mitigate Base Image Sizes?). Necesitamos considerar el tamaño total de su cadena de suministro, no las imágenes individuales, así que elegí el ubi-init imagen.

Observe lo simple que es el Containerfile. Esto se debe a que dependemos de los acondicionadores para iniciar los servicios correctamente. Ver también: ¿Siguen siendo importantes las distribuciones de Linux con los contenedores?

Es una compilación bastante sencilla, así que pasemos a las cosas difíciles con la ejecución.

Correr

Al igual que los servicios tradicionales, en servidores tradicionales, la ejecución de nuestros contenedores con systemd nos brinda una forma conveniente de iniciarlos cuando iniciamos nuestro host de contenedor o cuando se elimina el contenedor (recuperación en la tabla anterior). Analicemos nuestro archivo de unidad systemd para comprender mejor las decisiones de diseño y algunos de los beneficios de ejecutar servicios en contenedores:

[Unit]
Description=Podman container - wordpress.crunchtools.com

[Service]
Type=simple
ExecStart=/usr/bin/podman run -i --read-only --rm -p 80:80 --name wordpress.crunchtools.com 
-v /srv/wordpress.crunchtools.com/code/wordpress:/var/www/html/wordpress.crunchtools.com:Z 
-v /srv/wordpress.crunchtools.com/config/wp-config.php:/var/www/html/wordpress.crunchtools.com/wp-config.php:ro 
-v /srv/wordpress.crunchtools.com/config/wordpress.crunchtools.com.conf:/etc/httpd/conf.d/wordpress.crunchtools.com.conf:ro 
-v /srv/wordpress.crunchtools.com/data/wp-content:/var/www/html/wordpress.crunchtools.com/wp-content:Z 
-v /srv/wordpress.crunchtools.com/data/logs/httpd:/var/log/httpd:Z 
-v /srv/wordpress.crunchtools.com/data/mariadb/:/var/lib/mysql:Z 
--tmpfs /etc 
--tmpfs /var/log/ 
--tmpfs /var/tmp 
localhost/httpd-php
ExecStop=/usr/bin/podman stop -t 3 wordpress.crunchtools.com
ExecStopAfter=/usr/bin/podman rm -f wordpress.crunchtools.com
Restart=always

[Install] WantedBy=multi-user.target
                                                                                                                                                                                                                                          

Primero, observe que estamos ejecutando todo este contenedor en modo de solo lectura y con el –rm opción, lo que la hace efímera. El contenedor se elimina en cada parada. Esto requiere que dividamos nuestro código, configuración y datos y los guardemos en montajes externos; de lo contrario, se perderá. También nos da la opción de eliminar el contenedor para recoger los cambios del archivo de configuración como un servicio normal (hablaremos de eso más adelante). Apache, PHP FPM y MariaDB se ejecutan en paralelo en el contenedor, lo que les permite comunicarse fácilmente a través de sockets privados. Para un servicio tan simple, no es necesario escalar MariaDB y Apache por separado, por lo que no es necesario separarlos.

Tenga en cuenta que hemos dividido el código, la configuración y los datos en directorios separados y hemos vinculado los montajes. Los principales binarios de Apache, PHP y PHP FPM provienen del httpd-php imagen de contenedor creada en Red Hat Universal Base Image, mientras que el código de WordPress proviene del montaje de enlace de código/wordpress. En muchos contenedores, todo el código provendrá de la imagen del contenedor (consulte Rastreador de solicitudes a continuación). El directorio code/wordpress solo contiene Código PHP de WordPress descargado de wordpress.org. Ninguno de nuestros datos personales o personalizaciones se guarda en el directorio code/wordpress. No obstante, deliberadamente hemos hecho de esto una edición de enlace separada y escribible para permitir que WordPress se actualice automáticamente en tiempo de ejecución. Esto es contrario a las mejores prácticas típicas con contenedores, pero es una característica muy útil para un servicio web público popular que está constantemente bajo ataque y recibe actualizaciones de seguridad con frecuencia. La arquitectura de esta manera nos brinda actualizaciones inalámbricas sin tener que reconstruir la imagen del contenedor. Hacer que los servicios sean lo más autónomos posible es ciertamente útil.

Ahora mira las líneas de configuración. Cada archivo de configuración personalizado está vinculado en el contenedor de solo lectura. Esta es una actualización de seguridad sólida sobre los servidores LAMP tradicionales (máquinas virtuales o bare metal). Esto evita el uso de algunos complementos de WordPress que intentan modificar wp-config.php, pero a la mayoría de los administradores de sistemas les gustaría deshabilitarlos de todos modos. Esto se puede hacer en modo de lectura y escritura si algunos de nuestros usuarios realmente necesitan estos complementos.

A continuación, tenga en cuenta el directorio de datos. Vinculamos mount a tres subdirectorios diferentes. Todos son escribibles:

  • data/wp-content - Este directorio contiene nuestros datos personales y personalizaciones. Esto incluye cosas como temas de WordPress, complementos y archivos cargados (imágenes, videos, mp3, etc.). También vale la pena señalar que este es un sitio de WordPress multiusuario (MU), por lo que hay varios sitios que registran sus datos aquí. Un administrador de WordPress puede iniciar sesión y crear nuevos sitios según sea necesario.
  • datos/registros: queremos que nuestros registros de Apache estén fuera del contenedor para que podamos rastrear aciertos/errores o hacer algún análisis. También podríamos usarlos si alguien hackeara, y tenemos que reconstruir lo que pasó. Una opción de montaje de solo escritura puede ser útil aquí.
  • data / mariadb: este es nuestro directorio de escritura para MariaDB. La mayoría de nuestros secretos se almacenan en la base de datos, y este directorio tiene los permisos configurados correctamente para el usuario/grupo mysql. Esto nos brinda un aislamiento de nivel de proceso equivalente en el contenedor, similar a un servidor LAMP normal. Hay una pequeña actualización de seguridad ya que esta instancia de MariaDB solo contiene datos de WordPress. Los piratas informáticos no pueden ingresar a WordPress y acceder a nuestro Wiki o Request Tracker, que tienen sus propias instancias separadas de MariaDB.

A continuación, echemos un vistazo a la –tempfs montado. Estos permiten systemd para ejecutarse correctamente en un contenedor de solo lectura. Cualquier dato escrito en estos montajes se eliminará automáticamente cuando el contenedor se detenga. Esto hace que cualquier cosa fuera de nuestros montajes de enlaces sea completamente efímera. Se pueden hacer otras modificaciones para capturar /var/log/messages u otros periódicos si lo desea.

Para las copias de seguridad en WordPress, confiamos en UpdraftPlus. UpdraftPlus ofrece la ventaja de realizar una copia de seguridad de todo, desde un sitio de WordPress MU, incluidos temas, complementos, archivos y bases de datos. Incluso puede enviar la copia de seguridad a un almacenamiento remoto como Dropbox o pCloud (a través de WebDav). Esta es una plantilla de diseño común con aplicaciones de alto nivel como WordPress. A menudo, las bases de datos, los CRM, etc. tendrá sus propias utilidades de copia de seguridad o ecosistemas de software de copia de seguridad de terceros. Construir sobre este software existente sigue siendo útil en contenedores.

Índice

    Envoltura

    Me llevó mucho tiempo colocar estas aplicaciones en contenedores, pero el esfuerzo valió la pena. Es bueno pensar en este tipo de proyecto en términos de calificaciones fáciles, moderadas o difíciles. También vale la pena considerar al menos levantar y cambiar, refactorizar y reescribir. Como puede ver, estas migraciones pueden requerir mucho esfuerzo. Esto es en gran parte por qué la planificación es tan importante.

    También me centré en algunas buenas prácticas de seguridad y rendimiento. También me mantuve fiel a los principios de modularidad de Unix con la separación de código, configuración y datos.

    Ahora que hemos movido WordPress, es hora de aumentar un poco la apuesta. El próximo artículo de esta serie trata sobre la contenedorización de MediaWiki. Una vez que haya tenido la oportunidad de digerir este, pasaremos al Rastreador de solicitudes.

    Artículos de interés

    Subir