Loading databases on virtual systems is not as straight forward as it should be. Last time the foundation for using Ansible was set down on our quest to be able to have fully functional database servers on virtual servers automatically. But that prompted a few of you to remind me that you do not always need Ansible.

Without Ansible
You can have Vagrant do the work. Modify the vagrant file to run a script to run a script when provisioned, such as
config.vm.provision :shell,path: "setup.sh"
and create the setup.sh shell script.

#!/bin/bash
#
# example setup script for LAMP stack on Vagant box
sudo apt-get -y update
sudo apt-get -y install apache2 php5 libapache2-mod-php5
## Set …

Over on the codecentric blog I just published a new post on True KVM Live Migration with OpenStack Icehouse and Ceph based VM storage, outlining the process it took me to get this actually working. There were several issues to work around, some of them bugs in OpenStack, some of them home-grown issues.

I provide a few patches to OpenStack classes as well as a description of what is actually going wrong and how to circumvent the problems. So head right over and have fun reading :)

Another post on Ansible over on the codecentric blog: Jinja2 for better Ansible playbooks and templates linked here for your convenience :)

Yesterday I’ve put some new features into the ansible’s mysql_replication module, because we are planning to move to GTID based replication from the good old binlog position based one, and the module wasn’t aware of.

gtid_replication

This parameter can be either 0 or 1, defaults to 0. If set to 1 the replication will be threaded as GTID based replication.

warnings_filtered

This parameter threats the warnings, because MySQL 5.6 complaints a lot more than the previous versions. (For example, if the replication is not encrypted with SSL/TLS.) This could break our playbooks, so you can set it to all, warnings, none (defaults none). Speaks for itself, all means all warnings/errors will be shown, if warnings set, then only the errors will be shown, and the warnings supressed, and if none then that means, every message will be show …

I’ve create and another module for this besides the mysql_replication, named mysql_variables.

The purpose of this module to get/set variables from running MySQL servers, and avoid to use shell module for this, because that is a bit frustrating, and there are long commands to run.

For example, when you wanna to set read_only mode via shell, you can do that like this:

ansible db-secondary.bfc.kinja-ops.com -m shell -a "mysql -e 'select @@read_only'"
db-secondary.bfc.kinja-ops.com | success | rc=0 >>

[root@admin banyek]# ansible db-secondary.bfc.kinja-ops.com -m shell -a "mysql -e 'set global read_only=1'"
db-secondary.bfc.kinja-ops.com | success | rc=0 >>

Not so neat, isn’t it, eh? And I have not speak about the —user and —password variables, to this could be real annoying.

That’s why I made this module, because it is a bit easier to use (and I like to use own toolset with the …

We maintain a lot of servers under Kinja, so we have to use some orchestrator software to perform some tasks on a lot of servers. The Ansbile software is used by us, because it is cool.

We have also a lot of MySQL servers (and counting!) under Kinja, so we have some tasks to perform on them, such as managing replication. Of course there are some ways to do this, for example using multiplexed terminals, or run ansibile shell commands what performs mysql queries (e.g. ansible mysql-master1 -m shell -a “mysql -e “SOME SQL QUERY HERE”) but it is not too comfy, and needs a lot of manual work.

So, there is a way to make it easier for us, and that’s why I made a mysql_replication module for ansible. (And I made a pull request for that on GitHub, so I hope it will be merged soon to ‘official’ branch)

The mysql_replication module helps you to

…