Teil 1: Anforderungen und Problem.. äh, Herausforderungen
Teil 2: Lösungsansätze – Dockerimages und Initialisierung
Teil 3: Lösungsansätze – Dockerimage mit WordPress
Teil 4: Lösungsansätze – Kubernetes
Teil 5: Installation automatisieren
Teil 6: Updates automatisieren
Teil 7: Feinschliff


Der Vorteil an Docker ist ja eigentlich, dass man ein fest definiertes Image hat, das sich – grob gesagt – überall gleich verhält. Das Problem dabei ist nur, dass die Applikation, die in dem Image läuft, das auch unterstützen muss.

Oder, muss sie das?

Fangen wir mal mit dem offensichtlichen an: WordPress ist „very stateful“, und eignet sich per se erst mal schlecht dafür, „dockerisiert“ zu werden (es sei denn, man behandelt/betreibt das Dockerimage wie eine VM).

Die Hauptursachen sind kurz gesagt:

  • Datenbank-Setup
  • Plugins
  • Themes
  • Useruploads
  • „Plugins“
  • Plugin-Runtime Data
  • Updates
  • Plugin-Updates

Jetzt mag der ein oder andere einwenden: da kommt aber ganz schön oft das Wort „Plugins“ vor!
Das ist korrekt und liegt daran, dass diese auf mehrere verschiedene Weisen für Probleme sorgen. Doch dazu später mehr.

Wo fangen wir an?

Zunächst müssen wir fest stellen, das wir nicht einfach das WordPress, so wie es ist, in einen Dockercontainer packen können. Und mit nur einem Dockercontainer werden wir auch nicht hinreichen – denn Setup und Updates sollen ja soweit wie möglich automatisch passieren, und nicht über die Weboberfläche!

Wir brauchen also grob:

  • einen parameterisierbaren Prozess der uns die Datenbank aufsetzt
  • ein Dockerimage, das Plugins und Themes schon mit bringt
  • ein shared Volume für Userdaten
  • ein Prozess für automatische Updates (sowohl für das Dockerimage als auch die Datenbank)

Darüber hinaus müssen die gewünschten Plugins einmal durchgesehen werden, um festzustellen, ob diese zusätzliche Maßnahmen erfordern.
Das ist bspw. bei Wordfence der Fall. Neben diversen Datenbanktabellen benötigt es Files in einem Ordner wp-content/wflogs, bzw. versucht diese anzulegen, falls nicht existent. Weiterhin sind Anpassungen an der .htaccess im Root-Folder erforderlich, und eine Datei wordfence-waf.php muss dort ebenfalls abgelegt werden.
Wie das ganze im Detail aussehen kann, wird in den folgenden Teilen genauer erörtert.

Ein Problem, dass in diesem Zusammenhang zumindest bei uns noch aufgetreten ist: Wordfence möchte nicht nur das wflogs-Verzeichnis anlegen, wenn es nicht vorhanden ist – es möchte auch ein chown darauf machen, wenn der Owner ein anderer ist (und ein chmod wenn der Filemode nicht passt, ggfs. auch).
Wenn das ganze auf AKS (Azure Kubernetes Service) läuft, dann ist das ein Problem. Dessen default Storage-System „AzureFile“ bindet Volumes so ein, dass Owner und File-Mode immer auf „root“ und „O777“ stehen und nicht geändert werden können!
Und das führt dann dazu, dass Wordfence das log mit Warnings zuspammt.

Die Problematik bzgl. AzureFile und mögliche Ausweichoptionen habe ich in einem anderen Artikel bereits im Detail beleuchtet: https://blog.hmg.dev/2020/11/27/ceph-vs-kubernetes-odyssee-zu-einem-dynamic-provisioner-fuer-externe-cluster/

Um unsere Anforderungsliste abzuschließen, sollten Benutzer im Admin-Interface gar nicht erst die Möglichkeit haben, Plugins und Themes hinzuzufügen, zu updaten oder zu entfernen – aktivieren und deaktivieren ist OK, das betrifft nur die Datenbank.

Nachdem wir jetzt grob umrissen haben, was wir haben wollen bzw. erwarten, widmen wir uns im nächsten Teil passenden Lösungsansätzen.


Weiter zu Teil 2: Lösungsansätze – Dockerimages und Initialisierung