Ansible As Scripting Language
Ansible is billed as a configuration manager similar to Puppet or cfengine. But it occurred to me recently that it’s really (at least) two things:
- A configuration manager.
- A scripting language for the machine room.
Mode 1 is the normal, expected one: here’s a description; now make the machine(s) look like the description. Same as Puppet.
Mode 2 is, I think, far more difficult to achieve in Puppet than it is in Ansible. This is where you make things happen in a particular order, not just on one machine (you’d use /bin/sh for that), but on multiple hosts.
For instance, adding a new user might involve:
- Generate a random password on
localhost. - Add a user on the Active Directory server.
- Create and populate a home directory on the home directory server.
- Add a stub web page on the web server.
This is something I’d rather write as an ansible play, than as a Puppet manifest or module.
Which brings me to my next point: it seems that for Mode 1, you want to think mainly in terms of roles, while for Mode 2, you’ll want to focus on playbooks. A role is designed to encapsulate the notion of “here’s a description of what a machine should look like, and the steps to take, if any, to make it match that description”, while a playbook is naturally organized as “step 1; step 2; step 3; …”.
These are, of course, just guidelines. And Mode 2 suffers from the fact that YAML is not a good way to express programming concepts. But I find this to be a useful way of thinking about what I’m doing in Ansible.