A container based on dansdans/docker-confd with MariaDB.
This container provides an etcd-aware MariaDB server with replication support.
Not a huge fan of MariaDB/MySQL, but some of the applications I want to use require it, so there you are.
- Create a unit in CoreOS that uses the docker image.
- Pass ETCD_SRV_RECORD, ETCD_SRV_DOMAIN, or ETCD_NODE as an env variable.
- Pass ETCD_PREFIX pointing to the branch in your etcd tree where this container is to be configured.
- Inside the ETCD_PREFIX branch, configure the desired etcd key-value pairs (see below for more information).
Etcd configuration values
This container supports configuration of users, passwords and creating databases via etcd.
The etcd key-value pairs are under the 'users' branch within ETCD_PREFIX (the container environment variable).
The structure of the key-value pairs is as follows:
/<prefix> /users /<username> /password=<encrypted password> /databases=["<dbname>", ... ]
- It is not possible to set the host component of the username yet.
- Note that 'databases' is a JSON array, and must be formatted correctly including using double talking marks.
- Also note that at this time users, databases, and access rights are NOT revoked when removed from etcd.
To use this as a database server, link it from another container the same as you usually would.
Improvements to be made
This area is to some extent a dumping ground for my own ideas on improving this image.
- Add support for hosts in user account setup.
- Add better handling of users/rights/databases; in particular remove/revoke where the data has been removed from etcd.
- Add more etcd configuration capabilties.
- Replication settings for master/slave setup (or clustered multi-master?)
- Isn't there a better way to do persistent data e.g. /var/lib/mysql? Investigate.
- Logging to central location (see dansdans/docker-confd)
- Alerts and instrumentation to central location (see dansdans/docker-confd)
- Ponder on better method for mariadbsystem user password. Tricky because we don't want anything persistent locally and we don't want to store it in etcd. The actual risk is relatively low since the user is local-only, but nevertheless, a non-hardcoded password would be preferable.