Why is it called Ansible?

One of Michael's favorite books is Orson Scott Card’s “Ender’s Game”. In the book, the Ansible is a method of instantaneous long distance “hyperspace” communication with a large number of space ships. You should read it!

What are some of the design philosophies of Ansible?

Several things, but we'll detail some of them. Perhaps first and foremost, Ansible is open source software. We believe the best tools are made not by small numbers of people, but large numbers.

Ansible is designed foremost for transparency and ease of use. Ansible takes great care in naming things and being free of technical idioms or jargon, such that ansible playbooks can often be handed to people unfamiliar with the tool and largely understood at first glance. This makes them easy to audit and maintain many months down the road.

Similarly, Ansible's code is designed to be very easy to understand and dive into. We believe all of our users, should they want to, should be able to contribute to the project without a lot of difficulty. For this reason, we keep things straightforward wherever possible and have a strong focus around pluggability so that lots of additions can be made even without modifying the core program. Application code is heavily reviewed not just for correctness, but also to make sure it is easily understandable. We believe that the greatest thing about open source is creating a place for people to collaborate and there is something to learn from everyone.

Ansible is very serious about computer security. It does not use any root level daemons of any kind, and relies on SSH as the primary mode of transport, avoiding custom security layers. It only serves files to systems that are absolutely needed and does not expose additional variables or data to any of them. Thus it is very import for high-security environments when working with sensitive data or with limitations on network access.

Ansible follows a 'batteries included' philosophy to modules. We believe in shipping with a very strong "standard library" of reusable cross-platform modules, that can be used to quickly assemble and automate complex infrastructure needs, so users don't have to search to find the best possible implementation. While user developed modules don't have to be added to the core product, we encourage and welcome this for widely used management tasks, adding a large number of new core modules with each release.

Ansible is daemonless, and can manage systems without having to install any extra software on them. This means it can rapidly assimilate existing infrastructure, is highly reliable (the management channel will never go down), and it consumes a bare minimum of resources.

Finally, Ansible is very focused around backwards compatibility. We try very very hard to not remove language features (and add them conservatively), so when changing between versions of Ansible you don't have to worry about porting all of your configuration management content and seeing what doesn't work. Because there are no agents, you never have to worry about server/agent version compatibility or complicated upgrade cycles.

Is support, training, or consulting, or other implementation assistance available?

Yes on all counts! Ansible is open source software, but you don't have to go at it alone. Hop over to AnsibleWorks.com for all of these things, as well as a schedule of upcoming events. You may also want to keep up with the blog at blog.ansibleworks.com or @AnsibleWorks on twitter. AnsibleWorks sponsors several developers on the project and Michael DeHaan, creator of Ansible, is CTO.

What inspired Ansible?

Back when I worked for Red Hat and working on Cobbler, several of us identified a gap between provisioning (Cobbler) and configuration management solutions (cfengine, Puppet, etc). There was a need for a way to do ad-hoc tasks efficiently, and various parallel SSH scripts were not API based enough for us. So we (Adrian Likins, Seth Vidal, and I) created Func – a secure distributed command framework.

I always wanted to have a configuration management system built on Func, but never built it due to needing to spend time on Cobbler and other projects. In the meantime, a John Eckersberg developed Taboot, a deployment framework of sorts that sat on top of Func, using a YAML syntax very much like what Ansible now has in Playbooks. After trying to get Func running again recently, I got tired of some SSL and DNS issues and decided to create something a bit simpler, taking all of the good ideas from Func, and merging them with experience I learned from working at Puppet Labs. I wanted something that was easy to pick up and was installable without any bootstrapping, and didn’t suffer from the “I don’t want to learn X” mentality that often impacted adoption of tools like Puppet and Chef among certain ops teams.

I also spent some time working with a couple of sites that needed to do large webapp deployments, and noticed how complex various configuration management and deployment tools were to these companies, compared with what they actually needed. Release processes were too complex and needed something simple to straighten them out – but I really didn’t want to train all the dev(ops) on Puppet or Chef, and they really didn’t want to learn them either. Further, there were many things these tools just couldn't do -- which is why I was observing so many IT shops glueing so many different solutions together.

I kept thinking, is there a reason for these programs to be so large and complicated? Well, systems management is a little complicated, but no. Not really.

Can I build something that a sysadmin can figure out in 15 minutes and get going, and then extend in any language he knows? That’s how Ansible was born. It sheds rigid infrastructure for ‘you know your infrastructure best’, and distills all of the ideas behind all of these other tools to the core. Not only is Ansible very simple and easy to learn/extend, it’s configuration management, deployment, multi-tier process orchestration, and ad-hoc tasks all in one app. And I think that makes it pretty powerful. It hasn’t really been done before.

I’d like to know what you think of it. Hop by the mailing list and say hi.

How Is Ansible Different From Func?

Ansible uses SSH by default instead of SSL and custom daemons, and requires no extra software to run on managed machines. You can also write modules in any language as long as they return JSON. Ansible’s API, of course, is heavily inspired by Func. Ansible also adds a configuration management and multinode orchestration layer (Playbooks) that Func didn’t have.

How Is Ansible Diferent From Puppet?

First off, Ansible wouldn’t have happened without Puppet. Puppet took configuration management ideas from cfengine and made them more sane. However, I still think they can be much simpler. Ansible playbooks ARE a complete configuration management system. Unlike Puppet, playbooks are implicitly ordered (more like Chef), but still retain the ability to signal notification events (like Puppet). This is kind of a ‘best of both worlds’ thing.

There is no central server subject to thundering herd problems, and Ansible is also designed with multi-node deployment in mind from day-one – something that is difficult for Puppet because of the pull architecture. Ansible is push based, so you can do things in an ordered fashion, addressing batches of servers at one time, and you do not have to contend with the dependency graph. It’s also extensible in any language and the source is designed so that you don’t have to be an expert programmer to submit a patch.

Ansible’s resources are heavily inspired by Puppet, with the “state” keyword being a more or less direct port of “ensure” from Puppet. Unlike Puppet, Ansible can be extended in any language, even bash ... just return some output in JSON format. You don’t need to know Ruby.

Unlike Puppet, hosts are taken out of playbooks when they have a failure. It encourages ‘fail first’, so you can correct the error, instead of configuring as much of the system as it can. A system shouldn’t be half correct, especially if we’re planning on configuring other systems that depend on that system.

Ansible also has a VERY short learning curve – but it also has less language constructs and does not create its own programming language. What constructs Ansible does have should be enough to cover nearly all Puppet use cases. There's also several features (particulary around orchestration) that are unique to Ansible. It should scale equally well since not having a server is almost like cheating.

Ansible does support gathering variables from ‘facter’, if installed, and Ansible templates in jinja2 in a way just like Puppet does with erb. Ansible also has its own facts though, so usage of facter is not required to get variables about the system.

Further, no root-level management daemons are required. If you do not already need a Ruby stack, you do not need to install one, and no resources are consumed when Ansible is not managing your systems. Ansible can log into remote systems using SSH, using whatever OS credentials you use, and is compatible with sudo and systems like Kerberos.

How is Ansible Different Than Chef?

Much in the ways Ansible is different from Puppet. Chef is notoriously hard to set up on the server, and requires that you know how to program in Ruby to use the language. As such, it seems to have a pretty good following among Rails coders and those that like Ruby. By contrast, Ansible does not require any server setup and you can write your configurations in plain text.

Generally speaking, Ansible has multi-node orchestration and ad-hoc task execution features not found in Chef. Rather than trying to supplement Chef with a focused deployment tool, you can do your configuration, deployment, and task execution all from one package.

Like Chef (and unlike Puppet), Ansible executes configuration tasks in the order given, rather than having to manually specify a dependency graph. Unlike Chef, Ansible’s playbooks are not a programming language. This means that you can parse Ansible’s playbooks and treat the instructions as data. It also means working on your infrastructure is not a development task and testing is easier.

Ansible can be used regardless of your programming language experience. Both Chef and Puppet are around 60k+ lines of code, while Ansible is a much simpler program. I believe this strongly leads to more reliable software and a richer open source community – the code is kept simple so it is easy for anyone to submit a patch or module.

Ansible does support gathering variables from ‘ohai’, if installed. Ansible also has it’s own facts so you do not need to use ohai unless you want to.

How is Ansible Different from Capistrano or Fabric?

These tools aren’t really well suited to doing idempotent configuration and are typically about pushing software out for web deployment and automating steps

Meanwhile Ansible is designed for other types of configuration management, and contains some advanced scaling features.

The ansible playbook syntax is documented within one HTML page and also has a MUCH lower learning curve. And because Ansible is designed for more than pushing webapps, it’s more generally useful for sysadmins (not just web developers), and can also be used for firing off ad-hoc tasks.

What is Ansible’s approach to security?

Ansible aims to not rely on custom daemon or PKI code but rely heavily on OpenSSH, which is extremely well peer reviewed and the most widely used security subsystem in the industry. As a result, Ansible has a lower attack surface than any configuration management tool featuring daemons that run as root, and you do not have to worry about network security vulnerabilities in the tool itself.

If your central server is taken over (or even logged into by a malicious employee), provided you were using SSH-agent and encrypted keys (and/or sudo with a password), your keys are still locked and no one can take control of your nodes.

Compared with something like Chef/Puppet/other, compromised manifests would lead to a loss of the whole network, with your network turning into an easily controllable botnet. Further by not running daemon infrastructure, you have more free RAM and compute resources, which should be relevant to users wanting to maximize their computing investments.

How does Ansible scale?

Whether in single-execution mode or using ansible playbooks, ansible can run multiple commands in seperate parallel forks, thanks to the magic behind Python’s multiprocessing module.

No matter how large your pool of hosts, you can decide if you want to try to manage 5 hosts at a time, or 50 at a time. It’s up to you and how much power you can throw at it and how fast you want to go. Ansible is often used in 'rolling update' mode, to upgrade your infrastructure with zero downtime.

Capacity planning is simple. When you are aren’t using Ansible, it is not consuming any resources, and you don’t have to contend with a herd of machines all knocking at the door of your management server all at once.

The SSH connection type (paramiko is the default, binary openssh is an option) can also make use of “ControlMaster” features in SSH, which reuses network connections. For those that want even more speed, 'fireball' mode can bootstrap a ephemeral 0mq daemon over SSH, which is nearly an order of magnitude faster than standard SSH. The fireball daemon will disable itself after a configurable number of minutes to not leave a daemon running on your machines, and while running the fireball is protected by AES keys that were distributed using your secure SSH channel. Entirely new keys will be used the next time fireball mode is engaged.

If you have 10,000 systems, running a single ansible playbook against all of them probably isn’t appropriate, which is why ansible-pull exists. This tool is designed for running out of git and cron, and can scale to any number of hosts. Ansible-pull uses local connections versus SSH, but can be easily bootstrapped or reconfigured just using SSH. There is more information available about this in the Advanced Playbooks section. The self-bootstrapping and ease of use are ansible are still retained, even when switching to the pull model.

If you’d like to discuss your deployment further, please hop on the mailing list.

Are transports other than SSH supported?

Currently SSH (you can choose between paramiko or the openssh binaries) and local connections are supported, as well as the aforementioned 'fireball' mode. The transport interface is also pluggable so more can be added at any time.

Stop by the mailing list if you have ideas. The connection-specific parts of Ansible are all abstracted away from the core implementation so it is very easy to extend.

What are some ideal uses for Ansible?

One of the best use cases? Complex multi-node cloud deployments using playbooks. Another good example is for configuration management where you are starting from a clean OS with no extra software installed, adopting systems that are already deployed.

Ansible is also great for running ad-hoc tasks across a wide variety of Linux, Unix, and BSDs. Because it just uses the basic tools available on the system, it is exceptionally cross platform without needing to install management packages on each node.

It also excels for writing distributed scripts and ad-hoc applications that need to gather data or perform arbitrary tasks – whether for a QA sytem, build system, or anything you can think of.