WordPress in Kubernetes: cloud native voordelen voor een monoliete applicatie

WordPress is een van de meest populaire content management systemen wereldwijd, waarbij het CMS zowel kleine websites als complexe websites ondersteunt. WordPress op Kubernetes deployen is een goede manier om horizontaal schalen mogelijk te maken en pieken in verkeer op te vangen.

Het containerorkestratie-platform Kubernetes zorgt voor de volledige omgeving van containers waarin WordPress staat. Denk aan computing, netwerk, opslag en allerlei type workloads.

“Net als bij andere applicaties op containers, heb je het voordeel dat je geen server met software hoeft in te richten. Je hebt containers nodig en een omgeving waar je je container deployt”, zegt Rick. “En of die omgeving nu een laptop van een developer is, een stage server of een live server; en op welke OS het dan ook draait, de container images met WordPress werken overal hetzelfde.”

De architectuur van WordPress op Kubernetes geeft je ook de voordelen van Continuous Integration (CI), waarmee je sneller tests, code reviews en log errors kunt verwerken. Daarnaast vermindert het de tijd die je kwijt bent om een nieuwe update te releasen.

“Tot slot, als je gebruik maakt van andere cloud native applicaties, of deze ontwikkelt, zit WordPress op Kubernetes op dezelfde lijn voor development en hosting. Daardoor is het makkelijker switchen tussen de applicaties”, zegt Rick.

Voor een goede deployment van WordPress op Kubernetes zijn andere manieren nodig dan je gewend bent. Manieren die aansluiten bij cloud native ontwikkeling. “Denk bijvoorbeeld aan het installeren van plugins. Wil je het echt cloud native doen, dan is dat voor WordPress op Kubernetes niet te doen via de interface van WordPress zelf. Je zult ze in de container image moeten zetten”, geeft Rick als voorbeeld aan. “Daarnaast wil je wp-config.php veilig houden. Deze kun je als secret mounten in een container. En zo zijn er meer omwegen nodig om WordPress meer compatible te maken met cloud native ontwikkeling en Kubernetes.”

Er komt meer bij kijken dan je voor het eerst kunt bedenken als je met WordPress op Kubernetes aan de slag gaat, geeft Rick mee. “Het kan ook nog eens op meerdere manieren. Je kunt bijvoorbeeld Helm charts gebruiken die online beschikbaar zijn. Die maken vaak gebruik van een persistent volume. Naarmate je aan het experimenteren bent met WordPress op Kubernetes, zul je merken dat iets dergelijks minder bijdraagt aan een goede performance”, zegt Rick.

“Voor PHP applicaties, zoals WordPress, op Kubernetes raden we aan om NGINX en PHP-FPM in twee losse containers te draaien. Per container draait er zo één proces en de combinatie NGINX + PHP-FPM geeft een heel goede performance”, zegt Rick. “Vervolgens bouw je een init container met je wordpress installaties, inclusief gewenste plugins en thema’s. Die wordt gebruikt om de hele installatie naar een emptydir volume te kopiëren, die gedeeld wordt tussen de NGINX en PHP-FPM containers.”

Door de manier waarop Kubernetes werkt, is er geen permanente opslag van data of bestanden in containers en pods. Crasht een container of herstart je ‘m zelf, dan verliest de container alle variabele data. Als containerorkestratie-platform herstart Kubernetes regelmatig containers of zet ze op een andere node. “Je zult dus oplossingen nodig hebben voor de database en voor wp-upload”, zegt Rick. “Het is mogelijk om persistent volumes toe te voegen aan pods, waardoor je wel permanente opslag toe kunt voegen. Een andere methode is gebruik te maken van S3-storage voor opslag van statische content. Via een S3-plugin kun je daar met WordPress gebruik van maken. Dit laatste komt de performance ten goede.”

Rick: “Ook voor de database heb je een oplossing nodig. Het is mogelijk om databases in Kubernetes te draaien. Dit is echter ingewikkelder dan een oplossing waarbij je een database los van WordPress draait.”

Wil je echt cloud native werken, en stateless omgaan met containers, dan werkt de self-update functie in de WordPress interface niet meer. Updates en code-wijzigingen zullen op een andere manier moeten gaan. “Je wijzigt je code, bijvoorbeeld in je git repo. In je CI proces wordt er dan een container image gebouwd, die je vervolgens naar je container registry (bijvoorbeeld Harbor) pusht. Een update gebeurt ook alleen maar via deze manier. Is er iets mis met de nieuwe versie, en werkt je website of applicatie niet meer naar behoren? Dan zijn eerdere versies via de container registry, of Git als je ook GitOps gebruikt, snel beschikbaar om deze versie van de container image weer te gebruiken”, zegt Rick.