So verschieben Sie MediaWiki in einen Linux-Container

Ich wusste schon lange, dass ich einige meiner persönlichen Linux-Dienste containerisieren wollte. Obwohl ich viel Containerisierungserfahrung habe, kam ich einfach nie dazu, an meinen eigenen Anwendungen zu arbeiten. Endlich habe ich es geschafft, und ich bin froh!

Der erste Artikel dieser Serie stellte die Dienste vor, die ich containerisiert habe. Es wurden auch einige der Fallstricke besprochen. Ich zog Lift-and-Shift-, Refactoring- und Rewriting-Optionen in Betracht. Ich habe die Anwendungen auch mit leicht/mittel/schwer bewertet. Dann habe ich in Teil 2 meine Erfahrungen mit der Containerisierung von WordPress behandelt.

Hier behandeln wir MediaWiki, das ähnlich sein wird, da es auch ein Apache, PHP FPM, PHP-basierter Dienst ist.

Anmerkung des Herausgebers:Für die Zwecke dieses Artikels gehen wir davon aus, dass Sie Ihre Container auf Red Hat Enterprise Linux 8 mit podman build erstellen werden. Möglicherweise können Sie die Anweisungen für andere Distributionen oder mit anderen Toolchains verwenden, es können jedoch einige Änderungen erforderlich sein.

Umzug MediaWiki

Bauen

MediaWiki wird in einem Container-Image ausgeführt, das aus genau derselben Containerdatei erstellt wurde. Beachten Sie eine kleine Sache, die im WordPress-Abschnitt nicht erwähnt wird – wir installieren crontabs und Cronie . Im Gegensatz zu WordPress, das über ein erweitertes Backup-Dienstprogramm verfügt, müssen wir bei MediaWiki die MariaDB-Datenbank sichern, um Backups zu erhalten, also brauchen wir 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"]

Abgesehen von der Verwendung von cron , Mediawiki verlässt sich auf nichts Besonderes im httpd-php Container-Image.

[ Leser mochten auch: Rootless-Container mit Podman ]

Laufen

Schauen wir uns nun an, wie wir MediaWiki etwas anders als WordPress betreiben:

[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

Wir führen den Container mit –read-only aus und –rm , genau wie WordPress, wodurch es vergänglich ist. Beachten Sie, dass wir Mount-Code/Mediawiki auch schreibgeschützt binden. Wir hätten ein anderes mehrschichtiges Bild erstellen und den MediaWiki-Code in diese Schicht einbetten können, aber wir haben uns entschieden, es stattdessen zu binden. Viele PHP-Apps verwenden ein Muster wie WordPress, bei dem erwartet wird, dass das Codeverzeichnis zur Laufzeit beschreibbar ist. Diese Designentscheidung gibt uns absichtlich die Möglichkeit, das Codeverzeichnis abhängig von der PHP-Webanwendung, die wir in einen Container stellen, schreibgeschützt oder schreibgeschützt zu machen. Dasselbe httpd-php image kann für alle verwendet werden, wodurch die Größe unserer Softwarelieferkette reduziert wird. Wenn wir Glibc, OpenSSL, Apache, PHP FPM oder PHP aktualisieren, um Sicherheitsprobleme zu beheben, erben alle unsere PHP-Anwendungen die neue Konfiguration, wenn sie neu gestartet werden. In einer perfekten Welt würden wir dieses httpd-php ständig neu erstellen Bild in einem CI/CD-System mit guter Testumgebung für kontinuierliche Updates.

Die Konfigurationsdateien werden wie WordPress zur Laufzeit schreibgeschützt in den Container eingebunden. Auch dies ist ein großartiges Sicherheits-Upgrade von einem Standard-LAMP-Server.

Es gibt weitere Datenverzeichnisse, die in MediaWiki eingebunden sind. Hier ist der Grund:

• data/mariadb – Das ist einfach. Die Gründe sind identisch mit WordPress.
• Daten/Bilder – Speichert Bilder, PDFs und andere Dateien, die in das Wiki hochgeladen wurden.
• data/skins – Wie WordPress wurde MediaWiki vor Containern entworfen. Sie könnten die Bedürfnisse zukünftiger Technologien wie Container nie kennen. Im Gegensatz zu WordPress enthält MediaWiki vorbelegte Skins in diesem Verzeichnis, das sich im Verzeichnis code/mediawiki/skins befindet. Dies ist eine Kopie dieser Daten in Kombination mit unseren benutzerdefinierten Skins. Es ist schreib-/lesbar, sodass wir neue Skins hinzufügen können, wenn wir möchten. In Zukunft wird dies wahrscheinlich mit einer „-v skins:skins:o“-Überlagerungsoption für Podman gelöst. Dadurch können wir unsere benutzerdefinierten Daten über die vorhandenen Code-/Mediawiki-/Skins-Daten „überlagern“, die mit dem anfänglichen Code-Download geliefert werden.
• Daten/Protokolle – Wie WordPress möchten wir Zugriff auf unsere Protokolle außerhalb des Containers.
• Daten/Backups – Im Gegensatz zu WordPress müssen wir einen cron verwenden Job, um die MariaDB-Datenbank nach einem Zeitplan zu sichern. Diese Backups werden in dieses Verzeichnis gestellt und dann vom Container-Host extern kopiert.

[Kostenloser Leitfaden:Wie man DevOps in einfachem Englisch erklärt] 

​Abschluss

Das ist also der zweite Dienst – MediaWiki! Vielleicht etwas anspruchsvoller als WordPress, aber nichts, was Sie nicht bewältigen können. In diesem Fall habe ich cronie hinzugefügt Konfigurationen. Es ist auch offensichtlich, wie wichtig systemd ist Einstellungen sind.

Vergessen Sie nicht, sich die Containerisierung von WordPress noch einmal anzusehen, falls Sie dies noch nicht getan haben. Als Nächstes behandeln wir die Containerisierung von Request Tracker.

Diese Serie basiert auf "A Hacker's Guide to Moving Linux Services into Containers" auf CrunchTools.com und wird mit Genehmigung neu veröffentlicht.