With the release of the first beta of DevShop we completed the switch to using Ansible Galaxy Roles, which are open source, collaborative infrastructure. Up until the last alpha release, DevShop installed via it's own custom playbook.
Now, each component of DevShop is broken out into separate Ansible Galaxy Roles, extending Jeff Geerling's playbooks.
Ansible Galaxy roles are a bit like Drupal modules, but for infrastructure. Anyone can submit them, but the best ones rise to the top of the list. A large community is gathering around these shared roles.
Community DevOps
We have created four new roles for Aegir and devshop that we have submitted to Ansible Galaxy:
- The opendevshop.aegir-user role prepares the special "aegir" user and home directory. This role makes it easy to use for a remote server, as it has a variable for "authorized_keys".
- The opendevshop.aegir-apache role extends the geerlingguy.apache role by allowing Aegir user to write apache configs and reload.
- The opendevshop.aegir-nginx role does the same as apache but for NGINX.
- The opendevshop.devmaster role combines all of the above, and then installs the DevShop front-end, called DevMaster.
These roles are decoupled: we use the same roles to configure remote servers and the master server.
Our mix of roles is just a thin layer of configuration on top of a great stack of Ansible roles written and maintained by the programmer who literally wrote the book on Ansible for DevOps, Jeff Geerling.
We make use of the following roles, all of them are Jeff's!
- geerlingguy.apache
- geerlingguy.composer
- geerlingguy.drush
- geerlingguy.git
- geerlingguy.mysql
- geerlingguy.nginx
- geerlingguy.php
- geerlingguy.php-mysql
Offloading all of the configuration details for these products means we are freed up to focus on DevShop. The community is collaborating actively around these roles. New features and improved security are being added all the time.
In addition to less maintenance, we get more configurability. Every possible configuration value is available as an Ansible Variable. Check out the README on any of the projects above to get a list of variables.
For example, the MySQL playbook some variables allowing you to tweak memory configuration:
mysql_key_buffer_size: "256M"
mysql_max_allowed_packet: "64M"
mysql_table_open_cache: "256"
There are dozens of variables assigned to the multitude of configuration options in the entire stack. Look for the vars/meta.yml and defaults/meta.yml file to see what variables are available in any given Ansible role.
Configuring Variables for your DevShop Server
The install.sh script creates a default Ansible inventory file called "inventory" in the same folder it is run.
This file by default, simply has the hostname of your server.
You can create your own inventory file in the same folder as the install script instead of letting the script create it for you. You will want to do this if you want to override variables in your devshop server:
[group]
hostnamemysql_max_allowed_packet=128M
Then, when you run install.sh, it will kick off a call to ansible-playbook using this inventory file and these variables!
Ansible for All
Our Ansible work doesn't end at installing DevShop. The Aegir Ansible project turns Aegir into an Ansible Server Management System: You can use the web UI for adding any Galaxy or custom roles you have, then attach as many roles as you want to your server using simple checkboxes. The Ansible Variables submodule allows freeform customization of Ansible variables using a textarea.
We will cover this in more detail in an upcoming blog post.
We look forward to getting more involved in the Ansible Galaxy Community, and are aiming to make Aegir one of the easiest ways to use Ansible. Have any thoughts on how we could improve our Ansible use? Post an issue!