Shared MariaDB

Sometimes you have multiple apps which require a MariaDB database. And they may implement their MariaDB instance in different ways - e.g. with different approaches to high availability and backups.

Or you may just want them to use the same MariaDB instance, but different databases in the same instance - e.g. to save on resources or to take advantage of central management of high availability, backups or whatnot.

This chart builds on top of mariadb-operator to set up a "shared" instance of MariaDB and sets up users, databases, grants and connection for your apps.

This chart will NOT install the mariadb-operator: It assumes that it is already installed on the cluster. If the mariadb-operator custom resources do not exist, then installation is doomed to fail.

By default, this chart will deploy a simple single-instance MariaDB (using the mariadb-operator CRDs) with sensible values.

You control which users/databases/grants are created through the values.yaml file (see e.g. sample-values.yaml for an example) where the users, databases entries dictate what is created.

All kubernetes resources will be named using the Helm Release name as a prefix, which allows for multiple shared MariaDB clusters in the same namespace. (I know. This somewhat defeats the purpose of having "one shared" MariaDB instance, but it is a Helm convention, and may prove to be useful for something.) The prefix can be overridden as usual with .Values.fullnameOverride

The MariaDB Instance

The (single) MariaDB instance will be created using the mariadb-operator CRD using a single replica.

If more replicas are desired, .Values.replicaCount should be increased to > 1. By default, replication will be set up between the instances.

If .Values.galera.enabled is set (it is not by default), and .Values.replicaCount > 1 then a Galera cluster will be created.

The MariaDB instance/cluster will get labels and annotations according to .Values.labels and .Values.annotations

Value	Description	Default
replicaCount	Number of instances in the MariaDB cluster	1
galera.enabled	Whether to create a Galera cluster	false
annotations	MariaDB cluster annotations	{}
labels	MariaDB cluster labels	{}
resources	Resource requests/limits for each instance	{}
storage.size	Amount of disk space for each instance	1Gi
storage.storageClassName	Storage class for the per-instance PVC
config.mariadb	MariaDB configuration - a dict	{}
timeZone	Default timezone for the instances
suspend	all operations performed by the operator are disabled	false
nodeSelector	Limit instances to nodes	{}
tolerations	Toleration of node taints	{}
affinity	Pod/node affinities	{}
priorityClassName	Pod scheduling priority class name	unset
userSecretAnnotations	extra annotations on user secrets	see below

Re: config.mariadb: This is a dict with the MariaDB server configuration (rather than quoted text, as this makes overrides easy). The defaults are pretty barebone (see values.yaml ). It is common to need to override some things in here - e.g.:

config:
  mariadb:
    max_connections: 500

Re: userSecretAnnotations: the defaults will ensure that any update to the Kubernetes Secret for a users password will result in a password change in the MariaDB instance. It also integrates nicely with stakater/reloader which can ensure that any deployments referencing the secret are restarted.

Service

A service will be created to allow access to the MariaDB instance(s):

Value	Description	Default
service.type		ClusterIP
service.loadBalancerIP		empty
service.externalTrafficPolicy		empty
service.sessionAffinity		empty
service.annotations		{}

Users

For user names: It is best to stick with names which also happen to valid strings for kubernetes resources:

• Avoid underscores (_)
• avoid asterisks (*)
• and other "weird" stuff.

(It may work, but is not really a focus for development...)

At the moment, the helm charts only supports authenticating users with a password; SSL authentication (and other authentication methods) is not yet supported (pull requests will be welcome)

By default, a secret will be created for each user with an automatically generated (random) password.

Value	Description	Default
users.X	Dict describing user X
users.X.labels	Extra k8s labels for the user	{}
users.X.annotations	Extra k8s annotations for the user	{}
users.X.maxUserConnections	Max concurrent connections for this user	unset
users.X.secretRef.name	Name of k8s Secret for user credentials	see below
users.X.secretRef.key	Key in above secret for storing the passsword	password
users.X.secretRef.create	Whether to create/manage the secret	true

By default, the name of the secret will be {.Release.Name}-{X) - where Release.Name can be overridden by .Values.fullnameOverride and the username is a "cleaned up" version of the username to allow for the most common special characters.

Any secrets created here will also inherit annotations as per .Values.userSecretAnnotations (see above)

It is safe (and expected) that the actual password changes outside helm upgrade runs: The chart will leave existing passwords unchanged and only generate a new password if it is missing.

If you want to supply (and manage) your own secret: set secretRef.create to false and specify secretRef.name (and optionally: secretRef.key).

Thus, a simple configuration for a user could be:

users:
  someuser:

which relies on mariadb-operator (or MariaDB's) defaults. For many apps: the default max number of connections is pretty low, so it is common to specify this at the user level:

users:
  someuser:
    maxUserConnections: 100

It is safe to create users using the normal MariaDB Operator custom resources - such users will not be interfered with by the chart. However: Note that username collissions will not be reliably detected.

Databases and Grants

Database (called "schema" in some other database products) are defined under the databases key.

Value	Description	Default
databases.X	Dict description the database X
databases.X.annotations	Annotations added to all resources related to this database	{}
databases.X.characterSet	Default character set for the database	unset
databases.X.collate	Default collation for the database	unset
databases.X.cleanupPolicy	MariaDB operator cleanup policy	unset
databases.X.grants	a dict describing which users get which access to the database
databases.X.grants.Y	Grants for user Y to database X
databases.X.grants.Y.Z	Grants for user Y to table Z ((use * for "all tables") on database X	[]

For each combination of database + user listed, a Connection resource (see the MariaDB-operator docs) is created, which is populated with the details an app would need to connect to the database. This will be named {Release.Name}-{username}-{dbname} (as usual, .Values.fullnameOverride can be used for overriding the helm release name). The secret will populated with username, password, host, port and database.

Note: Unlike the {Release.Name}-{username} secret, this secret cannot be used for changing the user's password.

Here is an example for a database named somedb with some privileges for users named admin, someapp and dev :

databases:
  somedb:
    grants:
      admin:
        '*':
          - ALL
      someapp:
        '*':
          - SELECT
          - INSERT
          - UPDATE
          - DELETE
	  dev:
	    '*':
		  - SELECT
	    # We deem it OK for developers to update this table in prod:
	    "logging_configuration":
		  - INSERT
		  - UPDATE
		  - DELETE

It is safe to create databases directly in MariaDB (or via MariaDB operator custom resources) - such databases will not be interfered with by the charts, but you will not be able to use values.yaml to control grants on such databases to users. Beware that database name collissions may not be reliably detected though.

Backups

This chart does not attempt to cover backups. The MariaDB Operator has facilities for this.