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

Nachdem ihr nun mit dem Wissen aus den vorherigen Artikeln bestimmt ein halbes Dutzend WordPress-Instanzen in Kubernetes aufgesetzt habt, steht plötzlich ein Update ins Haus.
Und nicht nur bei WordPress selbst. Auch einige der Plugins geben sich updatebedürftig.

Da wir aber alle von Natur aus faul sind, werden wir das definitiv nicht von Hand anpassen. Faulheit ist schließlich eine Tugend, die uns genau davon abhalten soll. Sie soll uns vielmehr dazu bringen, das Problem einmal richtig zu lösen, damit wir uns in Zukunft nicht mehr damit herum schlagen müssen. Indem wir zum Beispiel ein passendes Tool schreiben. Oder in eurem Fall noch besser: indem ihr einfach das Tool nutzt, das jemand anders bereits geschrieben hat.

Dennoch kommen wir nicht umhin, zumindest die Funktionsweise zu verstehen.

Welche Aufgaben hat das Tool?

  • Feststellen, welche Version derzeit im Einsatz ist (in der Pipeline im Repo konfiguriert)
  • Herausfinden, welche Version die aktuellste ist
  • Die Pipeline updaten und die neueste Version setzen
  • Alle Plugins durchgehen und die Versionen abgleichen
  • Die Pluginversionen anpassen, sofern nötig
  • Das ganze committen und pushen
  • Warten, dass die Pipeline die Images gebaut hat
  • Bei Erfolg die Release-Pipeline anstoßen, welche die Datenbank updated
  • Und dann die Release-Pipeline, die das ganze im Cluster ausrollt

bekannte Details

Ich hatte oben ja bereits die Tugend der Faulheit erwähnt. Diese mache natürlich auch ich mir zunutze. Man muss das Rad ja nicht immer neu erfinden. Für die Interaktion mit Azure greife ich also an der Stelle auf die Implementierung zurück, die bereits im DockerUpdateScanner zum Einsatz kommt.

Da das offizielle WordPress Dockerimage bei Dockerhub gehostet wird, können wir auch dafür auf den bereits vorhandenen Code aufbauen. Allerdings sind dabei schon einige Anpassungen notwendig, da uns diesmal die konkreten Versionen respektive Tags interessieren. Zudem galt es, sich mit weiteren Eigenheiten der Dockerhub-API herum zu schlagen – insbesondere, was das Thema Paginierung angeht. Dass das page_size-Limit bei 100 liegt, war nur durch try-and-error heraus zu finden.

neue Details

In einem der vorherigen Beiträge, hatte ich ja schon angedeutet, dass eines der Attribute in der plugin-list.json für den Update-Mechanismus benötigt wird. Denn die Plugins-Updates müssen wir uns aus der WordPress-Infrastruktur ziehen – und zwar so, wie WordPress selbst das auch tun würde. …was leider nicht sonderlich gut dokumentiert ist. Der try-and-error-Prozess war hierfür deutlich langwieriger und frustrierender. Was die Details angeht, habe ich dazu bereits einen eigenen Artikel verfasst.
Die Kurzform ist, dass wir für das Abfragen der API einen Key für jedes Plugin benötigen, der es hinreichend eindeutig identifiziert. Details dazu stehen im verlinkten Artikel.

Mit diesen Keys bewaffnet, bauen wir uns nun ein JSON zusammen, das wir gegen die WordPress-API werfen. Von der bekommen wir ein JSON zurück, dem wir entnehmen können, ob eine neuere Version vorliegt (und wenn ja, welche). In unserer plugin-list.json müssen wir dann nur ggfs. die Version anpassen.

und ein paar Anpassungen

Was dieses Tool, im Gegensatz zum DockerUpdateScanner noch anders macht, ist die Tatsache, dass es wartet, bis die Build-Pipeline für die Dockerimages fertig ist.

Vorher bringt es ja nichts, die Release-Pipelines anzustoßen, welche die Datenbank updaten und das Image ausrollen. Was das Tool auch direkt im Anschluss tut – sofern der Build erfolgreich war, versteht sich.
Da die Pipelines alle anhand des Namens identifiziert werden, sollten diese nicht unbedacht geändert werden. Es wäre zwar auch möglich, die Pipelines anhand der ID anzusprechen, aber die ist halt sehr nichtssagend und Azure Devops zeigt die IDs im WebUI nicht an – entsprechend wäre es überaus umständlich und müssig, heraus zu finden, welche Pipeline dahinter steckt.

Da für jedes Projekt in der Config erst einmal auf die zugehörige Build-Pipeline gewartet wird, läuft das Tool je nach Anzahl der Einträge recht lange.
Das ist derzeit auch aus gutem Grund nicht parallelisiert. Denn die Anzahl der bei Azure Devops zur Verfügung stehenden Build-Agents ist begrenzt. Es können zwar weitere hinzugebucht werden, aber das kostet halt ordentlich! Und allein mit dem Tool werden ja bereits zwei Agents geblockt: einer für der Tool selbst und einer für die Build-Pipeline auf die er wartet. Eigentlich sogar drei, wenn man die asynchron angestoßenen Release-Pipelines mitrechnet, auf die nicht extra gewartet wird. Und da wir noch jede Menge anderer Pipelines haben, wäre es nicht so der Hit alle Agents zu blockieren.
Da WordPress jetzt auch nicht gerade täglich neue Updates raus haut, reicht es auch vollkommen, wenn das Tool einmal pro Woche läuft – dann kann es auch ruhig etwas länger brauchen.

Das ist ja alles sehr schön, aber wo bekomme ich das Tool denn nun her?

Wie auch unsere anderen Projekte, ist dieses Tool auf unserer github-Seite zu finden.
Verbesserungsvorschläge, Bugreports und PullRequests sind immer gerne gesehen.

Im letzten Teil der Reihe gehen wir dann darauf ein, wie bereits bestehende WordPress-Instanzen am einfachsten migriert werden können und wie wir dem WordPress-Image beibringen können Mails zu versenden.