Onboarding and Ansible Galaxy.
When you start working on a new project, there are usually a couple of steps you'll need to follow to get up and running. This process is called on-boarding. One of the steps in this process is getting your local development environment setup.
On every team I've worked we've used Vagrant. Any provisioning is done using Ansible, a simple configuration based provisioner. Ansible Galaxy is to Ansible what Composer is to PHP; A tools to make it easy to re-use code or, in Ansible's case, roles.
If you don't know what Ansible is, I highly recommend you check out the blogs from Erika Heidi. She's got enough blog posts to get you up and running.
While I had been publishing all my code on packagist to enable re-use of my efforts across projects, I found myself still copying over Ansible roles. I was even googling roles I had previously used, downloading zip files and copying over the required roles into my project. This, of course, is super silly. If you're doing that still now: STAHP. There is a better way. Let's stop doing things the old-school way and hop on the Ansible Galaxy train, or spaceship.
Ansible Galaxy is divided into two things; A role repository (and discovery) tool, and an installer. The installer can be compared to composer, while the role repository (the website) is like Packagist.
On the Ansible Galaxy website it's pretty easy to find roles for commonly required dependencies like node.js or something like ElasticSearch. Installing roles is super easy. For example, the following command installs the node.js role.
ansible-galaxy install nodesource.node
Using the role is as easy as adding it to your playbook.
--- - hosts: all roles: - nodesource.node
By default roles are installed globally. The install path depends on which platform you are on, but what's more important to know is; all roles installed globally are available for every project. While this is nice, this is not always desired.
Global dependencies are on-boarding hurdles.
In order to onboard new people on your project as quickly as possible, we want to eliminate every hurdle a new developer on our team can encounter. Having a vagrant box and Ansible provisioning is already a step in the right direction. Things get a little more tricky when a project is dependant on globally installed roles. It's much easier if they could just
vagrant up without needing to go through a 10 step process to get up and running. Luckily there is a way to set the install path to determine where the required roles are installed.
Installing roles locally.
In order to install Ansible roles locally we need to alter some configurations. Project configuration for Ansible settings can be done in the
ansible.cfg file which you can create in your project root. This ini-like file allows you to alter the behaviour of Ansible on a per-project basis. One of the configuration options is the
roles_path option, which allows you to specify where roles are installed when executing the
ansible-galaxy install command.
As an example, here's a config file which specifies the roles to be installed in the
[defaults] roles_path = ./ansible/roles
Now, when we run the
ansible-galaxy install [role] command from the project root, the desired role will be installed inside the project. This allows you to check the role into source controle, and share them amongst your team members.
During on-boarding you want there to be as little friction as possible. Getting people started with a simple
vagrant up is immensely powerful. Removing steps, shortening the process, benefits the experience and lets people be productive faster.
For me, knowing how to remove the dependency on globally installed roles made the on-boarding process smoother and less error-prone. Using freely available roles also removed the need for me to invest into creating my own. Have you got projects depends depending on globally installed roles? Perhaps convert them to local roles instead and improve your on-boarding experience.