We use WordPress to take advantage of it’s user friendly admin panel. To write articles on the go, upload images, install plugins and so on.
Running WordPress though inside a pod in Kubernetes means that all file changes like new uploads, plugins etc will be lost once the pod restarts for any reason. Those changes are also not version controlled and in a catastrophy scenario we would end up having a very old version of our site.
Being supporters of GitOps and more specifically Flux, we integrated WordPress in this process. The idea is that with every couple of changes, the user could make commit the changes back to the repo throguh a plugin, initiating as a result the pipeline.
In a matter of minutes the website would be run from a newly created image automatically. Also, in a catastrophy scenario, Flux would be able to recreate your whole cluster including any WordPress sites automatically.
Below is an illustration of that sequence:
We used the Gitium wordpress plugin. It gives you two options to connect with your repository. HTTPS and SSH. SSH access would require that the pod’s public key is allowed to access the repository something that is not easily doable with docker containers.
To do that, we would need an extra step in our pipeline of injecting the ssh config to the docker image upon building. Another solution would be that the kubernetes deployment could supply a persistent volume to the pods.
We concluded on using the HTTPS method. That way we connect to our git repo using the command
git remote add origin https://<username>:<token>@gitlab.com/<username>/<repo-name>.git.
We had to change some code in Gitium plugin to prompt the user for that origin url before they commit. That way we could avoid the extra step in the pipeline and be sure that no passwords were leaked. We also edited some code to avoid merging and pushing everytime it reconnects to the repo since that would mean an infinite loop of pod deploying and git pushing.