Come spostare MediaWiki in un container Linux

Sapevo che volevo containerizzare alcuni dei miei servizi Linux personali da molto tempo. Anche se ho una grande esperienza di containerizzazione, non mi è mai sembrato di riuscire a lavorare sulle mie applicazioni. Alla fine ce l'ho fatta e ne sono felice!

Il primo articolo di questa serie ha introdotto i servizi che ho containerizzato. Ha anche discusso alcune delle insidie. Ho considerato le opzioni lift-and-shift, refactoring e riscrittura. Ho anche dato alle applicazioni valutazioni facili/moderate/difficili. Nella seconda parte ho quindi trattato la mia esperienza con la containerizzazione di WordPress.

Qui affrontiamo MediaWiki, che sarà simile poiché è anche un servizio basato su Apache, PHP FPM e PHP.

Nota dell'editore:ai fini di questo articolo, presumiamo che creerai i tuoi container su Red Hat Enterprise Linux 8 usando podman build. Potresti essere in grado di utilizzare le istruzioni su altre distribuzioni o con altre toolchain, tuttavia potrebbero essere necessarie alcune modifiche.

Spostare MediaWiki

Costruisci

MediaWiki viene eseguito in un'immagine contenitore creata dallo stesso identico file contenitore. Nota una piccola cosa non menzionata nella sezione WordPress:installiamo crontabs e Cronie . A differenza di WordPress, che ha un'utilità di backup avanzata, con MediaWiki dobbiamo scaricare il database MariaDB per ottenere i backup, quindi abbiamo bisogno di 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"]

Oltre all'utilizzo di cron , Mediawiki non fa affidamento su nulla di speciale nel httpd-php immagine contenitore.

[ Ai lettori è piaciuto anche: Contenitori rootless con Podman ]

Corri

Ora, diamo un'occhiata a come eseguiamo MediaWiki in modo leggermente diverso da 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

Eseguiamo il contenitore con –read-only e –rm , proprio come WordPress, rendendolo effimero. Si noti che associamo anche il codice di montaggio/mediawiki in sola lettura. Avremmo potuto creare un'altra immagine a più livelli e incorporare il codice MediaWiki in quel livello, ma abbiamo deciso di associarlo al montaggio. Molte app PHP utilizzano un modello come WordPress, in cui la directory del codice dovrebbe essere scrivibile in fase di esecuzione. Questa decisione di progettazione ci dà intenzionalmente la possibilità di rendere la directory del codice di sola lettura o scrivibile a seconda dell'applicazione Web PHP che stiamo inserendo in un contenitore. Lo stesso httpd-php image può essere utilizzato per tutti loro, riducendo così le dimensioni della nostra catena di fornitura del software. Se aggiorniamo Glibc, OpenSSL, Apache, PHP FPM o PHP per risolvere i problemi di sicurezza, tutte le nostre applicazioni PHP ereditano la nuova configurazione quando vengono riavviate. In un mondo perfetto, ricostruiremmo continuamente questo httpd-php immagine in un sistema CI/CD con un buon cablaggio di prova per aggiornamenti continui.

I file di configurazione, come WordPress, sono montati in binding nel contenitore in sola lettura in fase di esecuzione. Ancora una volta, questo è un ottimo aggiornamento della sicurezza da un server LAMP standard.

Ci sono più directory di dati montate su MediaWiki. Ecco perché:

• data/mariadb – Questo è semplice. I motivi sono identici a WordPress.
• dati/immagini:memorizza immagini, PDF e altri file caricati nel wiki.
• data/skin – Come WordPress, MediaWiki è stato progettato prima dei container. Non potrebbero mai conoscere le esigenze delle tecnologie future come i container. A differenza di WordPress, MediaWiki viene fornito con skin precompilate in questa directory, che si trova nella directory code/mediawiki/skins. Questa è una copia di quei dati combinati con le nostre skin personalizzate. È legato in lettura/scrittura montata in modo da poter aggiungere nuove skin se lo desideriamo. In futuro, questo sarà probabilmente risolto con un'opzione di sovrapposizione "-v skins:skin:o" su Podman. Questo ci consentirà di "sovrapporre" i nostri dati personalizzati sopra i dati di code/mediawiki/skins esistenti forniti con il download del codice iniziale.
• dati/registri:come WordPress, vogliamo accedere ai nostri registri al di fuori del contenitore.
• dati/backup – A differenza di WordPress, dobbiamo usare un cron job per eseguire il dump del database MariaDB in base a una pianificazione. Tali backup vengono inseriti in questa directory, quindi copiati fuori sede dall'host del contenitore.

[ Guida gratuita:come spiegare DevOps in un inglese semplice ] 

​Concludi

Quindi, questo è il secondo servizio:MediaWiki! Forse un po' più impegnativo di WordPress, ma niente che non puoi gestire. In questo caso, ho aggiunto cronie configurazioni. È anche evidente quanto sia importante systemd le impostazioni sono.

Non dimenticare di guardare indietro al contenitore di WordPress se non l'hai già fatto. Successivamente, tratteremo la containerizzazione di Request Tracker.

Questa serie è basata su "A Hacker's Guide to Moving Linux Services into Containers" su CrunchTools.com ed è stata ripubblicata con il permesso.