Projekte

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
# Setting up a wordpress instance

Setting up a wordpress instance using the shared HA maraidb DB is easy with [bitnami helm charts](https://bitnami.com/stack/mariadb-galera/helm).
![wordpress](https://wp.cluster.siam.homeunix.net/wp-content/uploads/2021/06/wordpress.png)

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:
```bash
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 `wordpress`DB using phpmyadmin.

Debugging is a bit complicated and this may be a bug in the chart as of thsi writing.
In theory a simple
```bash
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
```bash
BITNAMI_DEBUG="true"
```

To set this extra environment variable the "Answers" need to be edited as YAML. Use the `Edit as YAML` button.
```yaml
----
  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`.