By Piotr Gaczkowski, IOD Expert
Are you using Ansible for deployments? Perhaps you started recently using it after reading this article on it? Even though it’s a powerful tool, Ansible comes with some quirks. Knowing how to deal with its peculiarities can improve your experience and lower the time, and therefore costs, of debugging.
Testing with Molecule
Unless you are a lucky owner of an electric car, in order to drive you need to periodically check the level of various fluids, air pressure, and lights in your vehicle. This way, you make sure the car will be ready when you hit the road.
Same goes with code. If you want it ready to be used any time of day, you need to make sure it is well tested. To make things testable, it is best to split them into smaller pieces and test each of those pieces in isolation. In the case of Ansible, these pieces are “roles” mentioned in our previous article.
Ansible Galaxy, which is used to develop roles, comes with some testing support. The problem is, it still requires a significant amount of manual work. A better approach, then, is to use Molecule for the hard part and only focus on testing logic. Molecule provides you with some of the most common means of creating a testing environment (the drivers) and verifying results match expectations (the verifiers). Included are the drivers for cloud providers such as AWS, Azure, and GCE, as well as local solutions, like Docker, LXC, LXD, or Vagrant. Verifiers include Testinfra and Goss, but sadly Serverspec support is to missing.
Semi-Automatic Role Installation
I find it quite ironic that the software designed to make automation easier does not provide an easy automated way of installing roles locally. Of course, Ansible Galaxy can read the contents of requirements.yml and install them in system’s /etc directory, but I like my Ansible running only with regular user privileges. I therefore install all the roles the project depends on in one of the subdirectories to keep things clean and separated.
This requires a hack, apparently. I modify the local ansible.cfg to search for roles in the additional directory and I prepare a simple playbook to install roles to that directory. Each time I check out a fresh project, I need to install the roles first as Ansible won’t work if it can’t find the used roles even before their actual execution. It looks like this:
ansible.cfg [defaults] roles_path = galaxy_roles:roles install-roles.yml - hosts: localhost tasks: - file: path: galaxy_roles state: absent - local_action: command ansible-galaxy install -r requirements.yml --roles-path galaxy_roles
And requirements.yml to try for yourself:
- src: git+https://github.com/openstack/ansible-hardening
Roles of Renown
Each time you think of writing a new role required for your project visualize the desired state of your servers and stop for a moment. Take a deep breath and check whether your visualization can be fulfilled with an existing Galaxy role. Most common deployment scenarios are already handled by the existing roles and writing your own may not be the best use of your time. Examples?
- The already mentioned ansible-hardening
- Elasticsearch
- Let’s Encrypt
- Jenkins
- Logrotate
Semi-Automatic Vault Integration
The battle between security and convenience is an age-old high-tech conflict that still manifests itself. It is convenient to store the required keys or passwords in a Git repository, but it is definitely not secure. Ansible tries to resolve the conflict by introducing Ansible Vault. However, do not confuse it with Hashicorp Vault which, although similar in scope, is a totally different tool.
Ansible Vault lets us store our secrets in files encrypted by a password. Each time we use Ansible it then either asks us for a password or reads it from the file. To save some typing we can tell ansible.cfg to always read from the file:
[defaults] vault_password_file = vault_password.txt
But what should we do with the password file itself? It can be stored in a repository encrypted by either git-crypt or blackbox. With such setup, only those authorized to access the secrets can use them with convenience.
Depending on your requirements and obligations this setup may turn out to still be too loose. Consult a qualified security professional before implementing it.
IOD is a content creation and research company working with some of the top names in IT. Our philosophy is experts are not writers and writers are not experts, so we pair tech experts with experienced editors to produce high quality, deeply technical content. The author of this post is one of our top experts. You can be too! JOIN US.
More Tricks?
These are just a few simple tricks that can make our everyday lives with Ansible easier. Some of them may seem obvious, but I know I needed a lot of trials and errors until I arrived at the best solution. If any of these tips saves you some time or effort I’ll be happy! And let me know if they did by leaving some feedback in the comments below. Do you have some interesting tricks of your own that you want to share? Go ahead and post those in comments, too!
