Cómo mover MediaWiki a un contenedor de Linux

Sabía que quería incluir en contenedores algunos de mis servicios personales de Linux desde hace mucho tiempo. A pesar de que tengo una gran experiencia en la creación de contenedores, parece que nunca pude trabajar en mis propias aplicaciones. ¡Finalmente lo hice, y me alegro!

El primer artículo de esta serie presentó los servicios en contenedores. También discutió algunas de las trampas. Consideré las opciones de levantar y cambiar, refactorizar y reescribir. También califiqué las aplicaciones como fáciles/moderadas/difíciles. Luego cubrí en la segunda parte mi experiencia con la creación de contenedores de WordPress.

Aquí, abordamos MediaWiki, que será similar ya que también es un servicio Apache, PHP FPM, basado en PHP.

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.

Mover MediaWiki

Construir

MediaWiki se ejecuta en una imagen de contenedor creada a partir del mismo Containerfile. Observe una pequeña cosa que no se menciona en la sección de WordPress:instalamos crontabs y Cronie . A diferencia de WordPress, que tiene una utilidad de copia de seguridad avanzada, con MediaWiki, debemos volcar la base de datos de MariaDB para obtener copias de seguridad, por lo que necesitamos cron .

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"]

Aparte de la utilización de cron , Mediawiki no se basa en nada especial en httpd-php imagen del contenedor.

[ A los lectores también les gustó: Contenedores sin raíz con Podman ]

Corre

Ahora, echemos un vistazo a cómo ejecutamos MediaWiki ligeramente diferente a WordPress:

[Unit]
Description=Podman container - learn.fatherlinux.com

[Service]
Type=simple
ExecStart=/usr/bin/podman run -i --read-only --rm -p 8080:80 --name learn.fatherlinux.com \
-v /srv/learn.fatherlinux.com/code/mediawiki:/var/www/html/learn.fatherlinux.com:ro \
-v /srv/learn.fatherlinux.com/config/LocalSettings.php:/var/www/html/learn.fatherlinux.com/LocalSettings.php:ro \
-v /srv/learn.fatherlinux.com/config/learn.fatherlinux.com.conf:/etc/httpd/conf.d/learn.fatherlinux.com.conf:ro \
-v /srv/learn.fatherlinux.com/config/htpasswd:/etc/httpd/conf.d/htpasswd:ro \
-v /srv/learn.fatherlinux.com/config/root-crontab:/var/spool/cron/root:ro \
-v /srv/learn.fatherlinux.com/data/mariadb/:/var/lib/mysql:Z \
-v /srv/learn.fatherlinux.com/data/images/:/var/www/html/learn.fatherlinux.com/images:Z \
-v /srv/learn.fatherlinux.com/data/skins/:/var/www/html/learn.fatherlinux.com/skins:Z \
-v /srv/learn.fatherlinux.com/data/logs/httpd:/var/log/httpd:Z \
-v /srv/learn.fatherlinux.com/data/backups/:/root/.backups:Z \
--tmpfs /etc \
--tmpfs /var/log/ \
--tmpfs /var/tmp \
localhost/httpd-php
ExecStop=/usr/bin/podman stop -t 3 learn.fatherlinux.com
ExecStopPost=/usr/bin/podman rm -f learn.fatherlinux.com
Restart=always

[Install]
WantedBy=multi-user.target

Ejecutamos el contenedor con –read-only y –rm , al igual que WordPress, haciéndolo efímero. Tenga en cuenta que también vinculamos el código de montaje/mediawiki de solo lectura. Podríamos haber creado otra imagen en capas e incrustado el código de MediaWiki en esa capa, pero decidimos unirla y montarla en su lugar. Muchas aplicaciones de PHP usan un patrón como WordPress, donde se espera que el directorio de código se pueda escribir en tiempo de ejecución. Esta decisión de diseño nos da a propósito la opción de hacer que el directorio de código sea de solo lectura o de escritura según la aplicación web PHP que estemos colocando en un contenedor. El mismo httpd-php image se puede utilizar para todos ellos, reduciendo así el tamaño de nuestra cadena de suministro de software. Si actualizamos Glibc, OpenSSL, Apache, PHP FPM o PHP para solucionar problemas de seguridad, todas nuestras aplicaciones PHP heredan la nueva configuración cuando se reinician. En un mundo perfecto, reconstruiríamos continuamente este httpd-php imagen en un sistema CI/CD con un buen arnés de prueba para actualizaciones continuas.

Los archivos de configuración, como WordPress, se montan en enlace en el contenedor de solo lectura en tiempo de ejecución. Una vez más, esta es una gran actualización de seguridad de un servidor LAMP estándar.

Hay más directorios de datos enlazados en MediaWiki. He aquí por qué:

• data/mariadb:esto es sencillo. Las razones son idénticas a las de WordPress.
• datos/imágenes:almacena imágenes, archivos PDF y otros archivos cargados en el wiki.
• datos/máscaras:al igual que WordPress, MediaWiki se diseñó antes que los contenedores. Nunca podrían conocer las necesidades de tecnologías futuras como los contenedores. A diferencia de WordPress, MediaWiki viene con máscaras rellenadas previamente en este directorio, que se encuentra en el directorio code/mediawiki/skins. Esta es una copia de esos datos combinados con nuestras máscaras personalizadas. Está montado en enlace de lectura/escritura para que podamos agregar nuevas máscaras si lo deseamos. En el futuro, es probable que esto se resuelva con una opción de superposición "-v skins:skins:o" para Podman. Esto nos permitirá "superponer" nuestros datos personalizados sobre los datos de código/mediawiki/máscaras existentes que vienen con la descarga del código inicial.
• datos/registros:al igual que WordPress, queremos acceder a nuestros registros fuera del contenedor.
• datos/copias de seguridad:a diferencia de WordPress, debemos usar un cron trabajo para volcar la base de datos MariaDB en un horario. Esas copias de seguridad se colocan en este directorio y luego el host del contenedor las copia fuera del sitio.

[ Guía gratuita:Cómo explicar DevOps en un lenguaje sencillo ] 

​Resumir

Entonces, ese es el segundo servicio:¡MediaWiki! Quizás un poco más desafiante que WordPress, pero nada que no puedas manejar. En este caso, agregué cronie configuraciones También es evidente la importancia de systemd la configuración es.

No te olvides de revisar la contenedorización de WordPress si aún no lo has hecho. A continuación, cubriremos la creación de contenedores del rastreador de solicitudes.

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.