Setting up a wordpress instance
Setting up a wordpress instance using the shared HA maraidb DB is easy with bitnami helm charts.
Bitnami charts can be enabled globally usign “Manage Catalogs” in rancher and then are availabel as “Apps”. Use “Add Catalog” and use https://charts.bitnami.com/bitnami. This URL serves “Helm v3” charts (“Helm v2” is EOL now).
We want to run this wordpress instance using the shared mariadb.
To access this web application we only need to correctly set up the ingress which with HTTPS and a “Let's Encrypt” certificate. As we have all the building blocks already in place we only need to set some Helm configuration variables to true.
We create a new wordpress user using the phpmyadmin interface for our shared mariadb server. We let phpmyadmin create a database with the same name as the user and grant all rights to this DB. The password can be automatically generated by phpmyadmin. We copy this value.
To pass credentials to to wordpress instance we use kubernetes secrests. To create these we need to create a wordpress namespace in the Default project first.
- So we go to the “Default” Project
- click
NamespaceAdd Namespaceand addwordpres. - We go to
ResourcesSecretsandAdd Secret. - We select
Available to a single namespaceand selectwordpress - We name the secret
wp-creds - We add two keys
- mariadb-password: We paste the password generated abov
- wordpress-password: We make up a reasonably save first (admin) user password and fill it in here.
We Launch a new “App”, search for “wordpress” and select that.
We can leave the name as wordpress.
We can leave the namespace as wordpress or select the existing namespace wordpress created above if a different name is suggested.
The wordpress helm chart has some more complicated names for the wordpress DB user and the wordpress DB. We just override these. By default Bitname helm charts try to create a separate IP based loadbalancer. We don't want that and don't have so many IP addresses to spare so we use ClusterIP (access only via ingress or within the cluster).
We customize the chart with the values below:
image.tag=5.7.2 service.type = ClusterIP persistence.size=1Gi persistence.accessModes=[ReadWriteOnce, ReadOnlyMany] wordpressFirstName=Omar wordpressLastName=Siam wordpressBlogName=Omar\'s cluster experience wordpressEmail=simar@gmx.net wordpressUsername=simar existingSecret=wp-creds mariadb.enabled=false externalDatabase.host=mariadb.shared-dbs externalDatabase.database=wordpress externalDatabase.user=wordpress externalDatabase.existingSecret=wp-creds ingress.enabled=true ingress.tls=true ingress.certManager=true ingress.hostname=wp.cluster.siam.homeunix.net
- If not set the
image.tagor the version of wordpress used will be set to rolling master. The documentation for the chart explicitly says to not use this for production. We try the oldest supported version of this chart for now. - wordpress needs a bit of persistent storage for plugins, themes, media files like pictures etc. We set the size of this persistent volume to
1Gi. We need to do a backup of this volume in addition to a DB dump regularly. - The chart is set up to just spawn a mariadb instance next to the wordpress service. Although convenient we want to us our shared maraidb here. So:
- We disable the creation of a mariadb pod
- We configure the host name and credentials for the shared mariadb
- We set up the credentials as one secret in
wp-credsso we just name this here.
- We set the ingress by just specifying some booleans and a hostname as described above
If the DB is empty the app will set up everything so wordpress can run. The only problem is: If that get's interupted somehow the error messages are next to non existant. The only noticable effect is that the wordpress pod keeps dying in wordress setup. On a hunch if wordpress was never used just delete all tables in the wordpressDB using phpmyadmin.
Debugging is a bit complicated and this may be a bug in the chart as of thsi writing. In theory a simple
image.debug=true
should be enough but it isn't. This sets an environment variable that should lead to good error messages but it does not.
What shows useful error messages is the environment variable
BITNAMI_DEBUG="true"
To set this extra environment variable the “Answers” need to be edited as YAML. Use the Edit as YAML button.
---- extraEnvVars: - name: BITNAMI_DEBUG value: "true" image: tag: "5.7.2" service: type: "ClusterIP" persistence: size: "1Gi" wordpressFirstName: "Omar" wordpressLastName: "Siam" wordpressBlogName: "Omar's cluster experience" wordpressEmail: "simar@gmx.net" wordpressUsername: "simar" existingSecret: "wp-creds" mariadb: enabled: false externalDatabase: host: "mariadb.shared-dbs" database: "wordpress" user: "wordpress" existingSecret: "wp-creds" ingress: enabled: true tls: true certManager: true hostname: "wp.cluster.siam.homeunix.net"
Apart from the environment variable all actual booleans need to be changed from "true"to true.