In diesem Artikel werfen wir einen Blick darauf, wie man eine WordPress-Installation von einer normalen Installation in einen Container migriert. Falls Sie es verpasst haben, haben wir in einem früheren Artikel einen Überblick über den allgemeinen Prozess gegeben, den wir verwenden möchten.
Die Containerisierung von WordPress scheint so täuschend einfach zu sein. Es ist ein Standard-LAMP-Stack, aber es gibt ein paar Fallstricke, die wir vermeiden möchten. Container sind eigentlich zwei Dinge:Container-Images im Ruhezustand und Linux-Prozesse zur Laufzeit. Werfen wir einen Blick auf beide Teile – Erstellen und Ausführen.
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.
Bauen
WordPress benötigt PHP und einen Webserver. Die häufigste Konfiguration ist die Verwendung von Apache (oder Nginx) mit PHP FastCGI Process Manager (php-fpm) und einem PHP-Interpreter. Tatsächlich kann ein Allzweck-Container-Image für fast jede PHP-basierte Anwendung erstellt werden, einschließlich WordPress und MediaWiki. Hier ist ein Beispiel, wie man eines mit Red Hat Universal Base Image erstellt:
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"]
Die ubi-init image ist standardmäßig so konfiguriert, dass es systemd ausführt in den Container, wenn er ausgeführt wird. Dies macht es einfach, ein paar Befehle bei der Installation auszuführen und sich auf das in die Linux-Distribution eingebettete Fachwissen zu verlassen. Wie ich seit Jahren argumentiere, sind die Qualität des Containerbildes und die Hygiene der Lieferkette wichtiger als die absolut kleinsten Einzelbilder, die wir produzieren können (Container Tidbits:Can Good Supply Chain Hygiene Mitigate Base Image Sizes?). Wir müssen die Gesamtgröße Ihrer Lieferkette berücksichtigen, nicht die einzelnen Bilder, daher habe ich mich für ubi-init entschieden Bild.
Beachten Sie, wie einfach die Containerdatei ist. Das liegt daran, dass wir uns darauf verlassen, dass die Paketierer die Dienste korrekt starten. Siehe auch:Spielen Linux-Distributionen mit Containern noch eine Rolle?
Es ist ein ziemlich einfacher Build, also lasst uns zu den kniffligen Dingen zur Laufzeit übergehen.
[Das könnte Ihnen auch gefallen: Wechsel von docker-compose zu Podman-Pods ]
Laufen
Wie herkömmliche Dienste auf herkömmlichen Servern, die unsere Container mit systemd ausführen gibt uns eine bequeme Möglichkeit, sie zu starten, wenn wir unseren Container-Host booten oder wenn der Container beendet wird (Wiederherstellungsfähigkeit in der obigen Tabelle). Lassen Sie uns unsere systemd-Unit-Datei analysieren, um die Entwurfsentscheidungen und einige der Vorteile der Ausführung von Diensten in Containern besser zu verstehen:
[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
Beachten Sie zunächst, dass wir diesen gesamten Container schreibgeschützt und mit –rm ausführen Option, wodurch es vergänglich ist. Der Container wird bei jedem Stopp gelöscht. Dies zwingt uns, unseren Code, unsere Konfiguration und unsere Daten aufzuteilen und auf externen Mounts zu speichern, oder sie gehen verloren. Dies gibt uns auch die Möglichkeit, den Container zu beenden, um Änderungen an der Konfigurationsdatei wie ein normaler Dienst aufzunehmen (dazu später mehr). Apache, PHP FPM und MariaDB laufen nebeneinander im Container, sodass sie bequem über private Sockets kommunizieren können. Für einen so einfachen Dienst ist es nicht erforderlich, MariaDB und Apache separat zu skalieren, sodass sie nicht getrennt werden müssen.
Beachten Sie, dass wir den Code, die Konfiguration und die Daten in separate Verzeichnisse und Bind-Mounts aufgeteilt haben. Die wichtigsten Apache-, PHP- und PHP-FPM-Binärdateien stammen aus httpd-php Container-Image, das auf Red Hat Universal Base Image aufgebaut ist, während der WordPress-Code aus dem Code/Wordpress-Bind-Mount stammt. In vielen Containern stammt der gesamte Code aus dem Container-Image (siehe Request Tracker später). Das Verzeichnis code/wordpress enthält nur WordPress-PHP-Code, der von wordpress.org heruntergeladen wurde. Keine unserer persönlichen Daten oder Anpassungen werden im code/wordpress-Verzeichnis gespeichert. Dennoch haben wir es absichtlich zu einem separaten, beschreibbaren Bind-Mount gemacht, damit sich WordPress zur Laufzeit automatisch aktualisieren kann. Dies steht im Gegensatz zu typischen Best Practices bei Containern, ist aber eine sehr praktische Funktion für einen beliebten öffentlich zugänglichen Webdienst, der ständig angegriffen wird und häufig Sicherheitsupdates erhält. Durch diese Architektur erhalten wir Over-the-Air-Updates, ohne das Container-Image neu erstellen zu müssen. Dienste so fahrerlos wie möglich zu gestalten, ist definitiv nützlich.
Sehen Sie sich nun die Konfigurationszeilen an. Jede angepasste Konfigurationsdatei wird schreibgeschützt in den Container eingebunden. Dies ist ein solides Sicherheitsupgrade von herkömmlichen LAMP-Servern (virtuelle Maschinen oder Bare Metal). Dies verhindert die Verwendung einiger WordPress-Plugins, die versuchen, wp-config.php zu ändern, aber die meisten Systemadministratoren würden diese sowieso deaktivieren wollen. Das könnte Lese-/Schreibzugriff erhalten, wenn einige unserer Benutzer diese Plugins wirklich benötigen.
Beachten Sie als Nächstes das Datenverzeichnis. Wir binden drei verschiedene Unterverzeichnisse ein. Alle sind beschreibbar:
- data/wp-content – Dieses Verzeichnis enthält unsere persönlichen Daten und Anpassungen. Dazu gehören Dinge wie WordPress-Themes, Plugins und hochgeladene Dateien (Bilder, Videos, MP3s usw.). Es sollte auch beachtet werden, dass dies eine WordPress Multi-User (MU)-Site ist, also speichern mehrere Sites ihre Daten hier. Ein WordPress-Administrator könnte sich anmelden und bei Bedarf neue Seiten erstellen.
- Daten/Protokolle – Wir wollen unsere Apache-Protokolle außerhalb des Containers, damit wir Zugriffe/Fehler verfolgen oder Analysen durchführen können. Wir könnten diese auch verwenden, falls sich jemand einhackt und wir rekonstruieren müssen, was passiert ist. Eine schreibgeschützte Mount-Option könnte hier nützlich sein.
- data/mariadb – Dies ist unser beschreibbares Verzeichnis für MariaDB. Die meisten unserer Geheimnisse werden in der Datenbank gespeichert, und dieses Verzeichnis hat die Berechtigungen, die für den mysql-Benutzer/die mysql-Gruppe richtig eingestellt sind. Dies gibt uns eine gleichwertige Isolierung auf Prozessebene im Container, ähnlich wie bei einem normalen LAMP-Server. Es gibt ein kleines Sicherheits-Upgrade, da diese MariaDB-Instanz nur WordPress-Daten enthält. Hacker können nicht in WordPress einbrechen und zu unserem Wiki oder Request Tracker gelangen, die ihre eigenen separaten MariaDB-Instanzen haben.
Als nächstes werfen wir einen Blick auf die –tempfs Anschlüsse. Diese aktivieren systemd ordnungsgemäß in einem schreibgeschützten Container ausgeführt werden. Alle Daten, die in diese Mounts geschrieben werden, werden automatisch gelöscht, wenn der Container beendet wird. Dies macht alles außerhalb unserer Bindungshalterungen völlig vergänglich. Andere Änderungen könnten vorgenommen werden, um /var/log/messages zu erfassen oder andere Protokolle, falls gewünscht.
Für Backups innerhalb von WordPress setzen wir auf UpdraftPlus. UpdraftPlus bietet den Vorteil, alles von einer WordPress-MU-Site zu sichern, einschließlich Designs, Plugins, Dateien und der Datenbank. Es kann sogar das Backup auf einen Remote-Speicher wie Dropbox oder pCloud (über WebDav) verschieben. Dies ist ein gängiges Designmuster bei übergeordneten Anwendungen wie WordPress. Häufig verfügen Datenbanken, CRMs usw. über eigene Backup-Dienstprogramme oder Ökosysteme von Backup-Software von Drittanbietern. In Containern ist es immer noch sinnvoll, sich auf diese vorhandene Software zu verlassen.
[ Erste Schritte mit Containern? Schauen Sie sich diesen kostenlosen Kurs an. Containerisierte Anwendungen bereitstellen:Eine technische Übersicht. ]
Abschluss
Ich habe sehr lange gebraucht, um diese Anwendungen endlich containerisiert zu bekommen, aber der Aufwand hat sich gelohnt. Es ist gut, diese Art von Projekt in Bezug auf die Bewertungen leicht/mittel/schwierig zu betrachten. Es ist auch nützlich, zumindest Lift-and-Shift, Refactoring und Rewriting in Betracht zu ziehen. Wie Sie sehen, können diese Migrationen sehr aufwendig sein. Das ist ein großer Teil dessen, warum Planung so wichtig ist.
Ich habe auch einige gute Sicherheits- und Leistungspraktiken hervorgehoben. Ich habe mich auch an die Unix-Grundsätze der Modularität mit der Trennung von Code, Konfiguration und Daten gehalten.
Jetzt, da wir WordPress umgezogen haben, ist es an der Zeit, den Einsatz ein wenig zu erhöhen. Der nächste Artikel in dieser Serie befasst sich mit der Containerisierung von MediaWiki. Sobald Sie die Gelegenheit hatten, das zu verdauen, werfen wir einen Blick auf 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.