WordPress is a highly popular content management system, with some estimates suggesting it powers over 40% of all websites. However, its popularity also comes with a significant list of vulnerabilities. Hosting an outdated wordpress instance is practically an open invitation to potential attackers.

Because my wordpress instance is containerized, and how wordpress manages database schema upgrades, this procedure is little complicated. Here are the steps for testing it using another instance.

• backup the database
• spawn new instance
• restore from backup
• manual upgrade from the UI
• upgrade using helm. This step is crucial, without it upgrade would be reverted after next pod restart

If that is working, I will repeat those steps on “production” instance.

BackuP

There a few different options for the backup:

• All-in-One WP Migration – done from the UI
• wp db export – CLI from container
• mysqldump – CLI, can be executed from anywhere, best for the automation

creating new instance

Now install the old version, in my case

helm install dev-wordpress oci://registry-1.docker.io/bitnamicharts/wordpress --version=23.1.15 --set wordpressPassword=dupa,service.type=NodePort

password does not matter, as it will be just an internal instance

now check the http nodeport

kubectl get svc dev-wordpress -n dev-wordpress -o json | jq -r '.spec.ports[] | select(.name == "http") | .nodePort'

and connect to the instance using url:{{nodeIP}}:{{port}}/wp-admin/

Restore

Restore the database using any method mentioned before

Manual upgrade from the ui

Because wordpress is not using database migrations like Django, we need to trigger it manually. Easiest would be manual upgrade from the UI.

Upgrade helm release

Assuming the previous steps have been successful, we can now upgrade the Helm release. Begin by preparing the values for the Helm chart:

mariadb:
  auth:
    rootPassword: vNjjzlEAuY
wordpressUsername: {{user}}
wordpressPassword: "{{password}}"

You can get current db password using echo $(kubectl get secret --namespace "dev-wordpress" dev-wordpress-mariadb -o jsonpath="{.data.mariadb-root-password}"
| base64 -d)

check if everything is working with

helm upgrade dev-wordpress oci://registry-1.docker.io/bitnamicharts/wordpress -f dev-values.yaml --dry-run 

If so, execute without --dry-run.

In my case, it __almost__ worked

helm upgrade dev-wordpress oci://registry-1.docker.io/bitnamicharts/wordpress -f dev-values.yaml                                          
WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /home/orest/.kube/config
WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /home/orest/.kube/config
Pulled: registry-1.docker.io/bitnamicharts/wordpress:24.0.4
Digest: sha256:ee46617e6025d94ec2686dc909224ebe300275e76bf4cf2e3268925d7040077b
Error: UPGRADE FAILED: cannot patch "dev-wordpress-mariadb" with kind StatefulSet: StatefulSet.apps "dev-wordpress-mariadb" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'ordinals', 'template', 'updateStrategy', 'persistentVolumeClaimRetentionPolicy' and 'minReadySeconds' are forbidden

stateful set was not upgraded. I will leave it now, hopefully it will not backlash later. I will probably create external DB later.

Now switch off dev instance:

kubectl scale deployment dev-wordpress --replicas=0 
kubectl scale statefulset dev-wordpress-mariadb --replicas=0

and patch the “production”.