Configuration systems play an important role in cloud management and automation. We’ve compared Func, MCollective, Salt and RunDeck, and we’ve had a great interview with Salt’s author as well, a Black Duck 2011 rookie of the year.
Now we’re excited to showcase another open source configuration management system called Ansible, with an interview of its author, Michael DeHaan on April 17, 2012.
Q. What is your background and how did Ansible come about?
I’ve been writing systems management software for over ten years. When I was at Red Hat, I wrote Cobbler (http://cobbler.github.com) and a good part of Func (http://fedorahosted.org/func), which your readers may have heard of, in addition to some early cloud prototypes of theirs. After that I worked for Puppet Labs for a while, and I’m now working on rPath’s Cloud Engine.
Ansible’s the culmination of a lot of things. I started to observe that many Linux/Unix admins had to turn to different tools to automate their configurations (Puppet, Chef, etc), still different tools to deploy their software (Fabric, Capistrano, etc), and yet other tools to run one-off tasks (Func, mCollective, etc) on all of their different machines. Further, nobody really seemed to handle multi-node deployment very well, and in the age of cloud and large web infrastructures, that’s one of the most interesting problems to solve.
I also wanted to make the automation software that anybody could pick up and learn in minutes, but also that possessed some capabilities that nothing else really had. Many people had cloned Func or Puppet — but in my opinion hadn’t made signifigantly major departures towards making those tools easier to use. So that’s why I made Ansible (http://ansible.github.com).
Q. What makes Ansible so interesting?
There are several different things that make it unique. First off, Ansible just works over SSH. It doesn’t require any software to be installed on the machines you are managing with it, it is entirely self bootstrapping for remote machines. There are no databases, no backend services, and there’s only one configuration file on the control machine, which is just a list of managed hosts. You can point at some hosts that use SSH and immediately start managing them, because it will push modules out to them automatically. It’s really simple. Having no daemons should make it great for consultants and places where a new daemon with custom PKI infrastructure or crypto would require a major security audit… I ran into a lot of places that were resistant to management agents with root privileges and wanted to make something that was a better fit for those places. SSH is something everybody is already running, so you can just fire up Ansible and start ordering boxes around.
Also, while a lot of tools will talk about having a simple configuration management language, usually they end up looking like programming languages as they take on more features. With Chef, it’s *actually* a programming language. Ansible’s “Playbooks” language is about as simple as I could make things, every concept being more or less distilled to it’s bare essence, using experience taken from all of those tools. It’s declarative like Puppet, but ordered like Chef, but has signficantly less syntax than both. I also really wanted to talk about “infrastructure as data”, not “infrastructure as code”. I wanted a play books language you could read as English, and a syntax that, if you didn’t use Ansible in 6 months, and came right back to it, you wouldn’t have forgotten anything about how it worked.
Ansible also sidesteps the popular Ruby vs Python language debates by letting you write modules for it in any language you like — anything that can produce JSON via standard out is fair game. So if you’d like to extend Ansible in Perl or Bash, we’re fine with that.
If your favorite library for interfacing with a Retro Encabulator is only available in Lua or Haskell, it’s no problem. Modules can be idempotent (and are, for the ones that ship with Ansible), but you’re also free to write ones that aren’t, and are more specialized to very specific operations. We avoid lots of nesting in the language or programming like constructs, so it’s exceptionally easy to audit and see exactly what playbooks are going to do.
Finally, Ansible is designed from the ground up for multi-node deployment operations, where you are trying to orchestrate a rollout of software in a multi-tier environment. Playbooks can target different sets of hosts in each play, and a playbook can contain more than one play. Because Ansible is push-based, it can easily represent these things, and the Playbook language helps because it’s really easy to see what’s going on in a very small number of files.
Q. What are Ansible’s limitations?
Well, it’s pretty new. A lot of the limitations can end up being feature requests, but I think the biggest thing is that our module support is young and we’re still building that out.
The SSH based approach is bound to be controversial, of course… but we do offer a local mode suitable for crontab/kickstart usage and connection types are pluggable, so we’re reasonably future proof. Other options will come later but SSH will always be there out of the box.
Q. What are the next steps for Ansible?
A lot of that’s going to be feature request driven, but short term we’ve got some interesting playbook upgrades in the pipe.
Q. Where do you see Ansible in a year or two?
Lots more users for one. There’s a ton of admins out there that are looking for easier deployment solutions where the existing fleet of tools just don’t work for them, so it’s just a matter of getting the word out.
I suspect we’ll also see a more built-out library of core modules, and more examples to share with people of how to automate things.
Q. How can someone contribute to Ansible?
We’re on github, so the easiest thing is to fork the project at http://github.com/ansible/ansible, and then send a pull request. There’s also a mailing list you can join, there’s a link to that on http://ansible.github.com/.