An Interview with Ansible Author Michael DeHaan

April 17th, 2012 | Posted by admin in Editorial

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.

Ansible Cloud Configuration Management

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/.

You can follow any responses to this entry through the RSS 2.0 You can skip to the end and leave a response. Pinging is currently not allowed.

6 Responses

  • Namtr0 says:

    Love the simple SSH.
    “infrastructure as data”, not “infrastructure as code” (hold for applause:)

  • Sterling says:

    Neat! Lots of attractive features in there. Should be interesting to see how this ambitious project continues to develop.

  • Jaime says:

    Ansible looks good, the KISS approach in terms of no agent/all SSH is definitively an attractive proposition in many cases. That said I’m currently testing Rundeck and it _seems_ superior at this point in time in particular in terms of collaboration/sharing (e.g. ACLs), and it ships with the same “no agent/all SSH” principles (which is one of the reason I picked it).
    A comparison of Rundeck and Ansible would be great =)

    • Jaime,

      Rundeck solves part ofthe puzzle, but not all of it. It lacks a configuration management system and is mostly about pushing scripts out, while Ansible has an idempotent resource model that is also good for ad hoc tasks. While you could use Rundeck to call a configuration management system, Ansible includes a configuration management system.

      • Jaime says:

        I see thanks for the clarification. So if I understand well Ansible is superior to Rundeck in the sense that it adds CM to command orchestration but _seems_ inferior in the features of the CO piece itself (at least at this point in time).
        I guess the next question would then be about the all-in-one-tool “graal” vs modular “tool chain” approach. The merging of Systems Automation “functions” into one tool is one path that I personally think needs to be questionned just like when, with quite _out of the devops box_ thinking, you propose “Infrastructure as Data as opposed to “infrastructure as Code”.
        Is it just the good old discussion about the multi tool vs the specialized one? Or is it that complex systems need a complex modular tool set to be built,maintained and operated? I’m more inclined to think the latter one is more appropriate i.e. the more complex the system the more complete the tool box need to be, something that I think can be seen in mechanical engineering.
        Ahhh…tools…Ahhh.. “one to rule them all”…



Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>