User Tools

Site Tools


k8s:services:setting_up_a_wordpress_instance

Setting up a wordpress instance

Setting up a wordpress instance using the shared HA maraidb DB is easy with bitnami helm charts. wordpress

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 Namespace Add Namespace and add wordpres.
  • We go to Resources Secrets and Add Secret.
  • We select Available to a single namespace and select wordpress
  • 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.tag or 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-creds so 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.

k8s/services/setting_up_a_wordpress_instance.txt · Last modified: by 127.0.0.1