En este artículo, echamos un vistazo a cómo migrar una instalación de WordPress desde una instalación normal a un contenedor. En caso de que te lo hayas perdido, en un artículo anterior dimos un resumen del proceso general que pretendemos usar.
Contenerizar WordPress parece tan engañosamente fácil. Es una pila LAMP estándar, pero hay algunas trampas que queremos evitar. Los contenedores son realmente dos cosas:imágenes de contenedores en reposo y procesos de Linux en tiempo de ejecución. Echemos un vistazo a ambas partes:construir y ejecutar.
Nota del editor:para los fines de este artículo, asumimos que construirá sus contenedores en Red Hat Enterprise Linux 8 usando la compilación podman. Es posible que pueda usar las instrucciones en otras distribuciones o con otras cadenas de herramientas; sin embargo, es posible que se requieran algunas modificaciones.
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 construir 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 uno con Red Hat Universal Base Image:
FROM registry.access.redhat.com/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 ejecutar systemd en el contenedor cuando se ejecuta. Esto facilita la ejecución de algunos comandos en la instalación y confía en la experiencia en la materia integrada en la distribución de Linux. Como he argumentado 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. Eso es porque confiamos en los empaquetadores para iniciar los servicios correctamente. Ver también:¿Siguen siendo importantes las distribuciones de Linux con los contenedores?
Es una compilación bastante simple, así que pasemos a las cosas complicadas en tiempo de ejecución.
[ También te puede interesar: Pasar de docker-compose a pods de Podman]
Corre
Al igual que los servicios tradicionales, en servidores tradicionales, ejecutando nuestros contenedores con systemd nos brinda una forma conveniente de iniciarlos cuando iniciamos nuestro host contenedor o cuando el contenedor se elimina (capacidad de recuperación en la tabla anterior). Analicemos nuestro archivo de unidad systemd para comprender mejor las decisiones de diseño y algunas de las ventajas 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 como de solo lectura y con –rm opción, haciéndola efímera. El contenedor se elimina cada vez que se detiene. Esto nos obliga a dividir nuestro código, configuración y datos y guardarlos en montajes externos, o se perderán. Esto también nos da la capacidad de eliminar el contenedor para recoger los cambios del archivo de configuración como un servicio normal (más sobre esto más adelante). Apache, PHP FPM y MariaDB se ejecutan uno al lado del otro en el contenedor, lo que les permite comunicarse convenientemente 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 dividirlos.
Tenga en cuenta que dividimos el código, la configuración y los datos en directorios separados y montamos enlaces. Los binarios principales de Apache, PHP y PHP FPM provienen de 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 más adelante). El directorio code/wordpress solo alberga el código PHP de WordPress descargado de wordpress.org. Ninguno de nuestros datos personales o personalizaciones se guardan en el directorio code/wordpress. Aún así, lo convertimos a propósito en un montaje de enlace grabable por separado 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 conveniente para un popular servicio web público que está bajo constante ataque y recibe actualizaciones de seguridad con frecuencia. Arquitectarlo 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 definitivamente útil.
Ahora, mira las líneas de configuración. Cada archivo de configuración personalizado se monta en enlace en el contenedor de solo lectura. Esta es una actualización de seguridad sólida de los servidores LAMP tradicionales (máquinas virtuales o bare metal). Esto evita el uso de algunos complementos de WordPress que intentan cambiar wp-config.php, pero la mayoría de los administradores de sistemas querrían deshabilitarlos de todos modos. Esto podría hacerse de lectura y escritura si algunos de nuestros usuarios realmente necesitan estos complementos.
A continuación, observe el directorio de datos. Vinculamos mount a tres subdirectorios diferentes. Todos ellos 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 se debe tener en cuenta que este es un sitio multiusuario (MU) de WordPress, por lo que varios sitios guardan sus datos aquí. Un administrador de WordPress podría iniciar sesión y crear nuevos sitios si fuera necesario.
- datos/registros:queremos que nuestros registros de Apache estén fuera del contenedor para que podamos rastrear accesos/errores o realizar análisis. También podríamos usarlos si alguien piratea y necesitamos reconstruir lo que sucedió. Una opción de montaje de solo escritura podría 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 a nivel de proceso equivalente en el contenedor, similar a un servidor LAMP normal. Hay una pequeña actualización de seguridad porque esta instancia de MariaDB solo tiene datos de WordPress. Los piratas informáticos no pueden ingresar a WordPress y acceder a nuestro Wiki ni a Request Tracker, que tienen sus propias instancias de MariaDB separadas.
A continuación, echemos un vistazo a –tempfs montajes Estos habilitan 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 todo lo que esté fuera de nuestros soportes de enlace sea completamente efímero. Se podrían realizar otras modificaciones para capturar /var/log/messages u otros registros si lo desea.
Para las copias de seguridad dentro de 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 la base de datos. Incluso puede enviar la copia de seguridad a un almacenamiento remoto como Dropbox o pCloud (a través de WebDav). Este es un patrón de diseño común con aplicaciones de alto nivel como WordPress. A menudo, las bases de datos, los CRM, etc. tendrán sus propias utilidades de copia de seguridad o ecosistemas de software de copia de seguridad de terceros. Confiar en este software existente sigue siendo útil en contenedores.
[ ¿Empezando con los contenedores? Consulta este curso gratuito. Implementación de aplicaciones en contenedores:una descripción técnica general. ]
Resumir
Me tomó mucho tiempo conseguir que estas aplicaciones finalmente se organizaran en contenedores, pero el esfuerzo valió la pena. Es bueno pensar en este tipo de proyecto en términos de calificaciones fáciles/moderadas/difíciles. También es útil al menos considerar levantar y cambiar, refactorizar y reescribir. Como puede ver, estas migraciones pueden requerir un gran esfuerzo. Esa es una gran parte de por qué la planificación es tan importante.
También hice hincapié en algunas buenas prácticas de seguridad y rendimiento. También me apegué 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 subir un poco la apuesta. El próximo artículo de esta serie analiza la contenedorización de MediaWiki. Una vez que haya tenido la oportunidad de digerir eso, le daremos un golpe en Request Tracker.
Esta serie se basa en "A Hacker's Guide to Move Linux Services into Containers" en CrunchTools.com y se vuelve a publicar con autorización.