Tag Archives: Ansible

[project ]Ansible :is a radically simple model-driven configuration management, deployment, and command execution framework.


The Future Is Now

Ansible is a radically simple model-driven configuration management, deployment, and command execution framework. Other tools in this space have been too complicated for too long, require too much bootstrapping, and have too much learning curve. Ansible is dead simple and painless to extend. For comparison, Puppet and Chef have about 60k lines of code. Ansible’s core is a little over 1000 lines.

Ansible isn’t just for idempotent configuration – it’s also great for ad-hoc tasks, quickly firing off commands against nodes. See Command Line Examples.

Innovative Multi-node Control

Where Ansible excels though, is expressing complex multi-node deployment processes, executing ordered sequences on different sets of nodes throughPlaybooks. Playbooks contain one or more plays, each executed against a different batch of nodes. Think about webservers, database servers, and backend servers in a multi-node web environment. A play can address each set of machines in a cycle, ensuring the configurations of the machines were correct and also updating them to the specified version of software if required.

Multi-machine software deployment is poorly solved by most systems management tools – often due to architectural nature of being pull oriented and having complex ordering systems, they cover configuration but fail at deployment when updating tiers of machines in well defined steps. This results in using two (or more) logically distinct tools and having complex overlap between them.

Deployment and Configuration, Unified

Other deployment (compared to config) oriented frameworks similarly cover deployment well but lack a strongly defined resource model and devolve into glorified remote scripts. Ansible playbooks – having been designed with this problem in mind – are good at both deployment & idempotent configuration, meaning you don’t have to spread your infrastructure management out between different tools (Puppet+Capistrano, Chef+Fabric, etc), and performing ordered steps between different classes of machines is no problem, yet our modules affect system state only when required – while avoiding the problem of fragile scripting that assumes certain starting or ending states.

Ansible is also unique in other ways. Extending ansible does not require programming in any particular language – you can write Ansible Modules as idempotent scripts or programs that return simple JSON. Ansible is also pragmatic, so when you need to, it’s also trivially easy to just execute useful shell commands.

Why use Ansible versus other configuration management tools? (Puppet, Chef, etc?) Ansible will have far less code, it will be (by extension) more correct, and it will be the easiest thing to hack on and use you’ll ever see – regardless of your favorite language of choice. Versus other deployment tools? (Capistrano, Fabric?). Ansible playbooks are easier to use (not being code) and also allows intermixing of idempotent configuration management rules for a higher level of control. Further, it was designed for deploying multi-node applications from the beginning.

Simple & Secure By Default

Compared with most configuration managememnt tools, Ansible is also much more secure. While most configuration management tools use a daemon, running as root with full access to the system, with its own in-house developed PKI infrastructure, Ansible just uses SSH (and supports sudo as neccesssary). There is no additional attack surface and OpenSSH is one of the most peer reviewed security components out there. If a central server containing your playbooks are comprimised, your nodes are not – which is NOT the case of these other tools, which can, more or less, turn into a botnet. Our security approach is to avoid writing custom crypto code altogether, and rely on the most secure part of the Linux/Unix subsystem that your machines are already using. There is no PKI subsystem to maintain, which can be a frequent source of problems, particularly when reinstalling or migrating hosts.

Systems management doesn’t have to be complicated. Ansible’s docs will remain short & simple, and the source will be blindingly obvious. We’ve learned well from “Infrastructure is Code”. Infrastructure should be easy and powerful to command, but it should not look like code, lest it acquire the disadvantages of a software project – bugs, complexity, and overhead. Infrastructure configurations should be simple, easy to develop, and easy to audit.


"Architecture Diagram"


  • Dead simple setup
  • Super fast & parallel by default
  • No server or client daemons; use existing SSHd out of the box
  • No additional software required on client boxes
  • Can be easily run from a checkout, no installation required
  • Modules are idempotent, but you can also easily use shell commands
  • Modules can be written in ANY language
  • Awesome API for creating very powerful distributed scripts
  • Does not have to run remote steps as root
  • Pluggable transports (SSH is just the default)
  • Source host info & variables from files or external software
  • The easiest config management system to use, ever.


Your ideas and contributions are welcome. We’re also happy to help you with questions about Ansible.


Presented By…

Ansible was created and is run by Michael DeHaan (@laserllama), a Raleigh, NC based software developer and architect, who also created the popular DevOps install server Cobbler. Cobbler is used to deploy mission critical systems all over the planet, in industries ranging from massively multiplayer gaming, core internet infrastructure, finance, chip design, and more. Michael also helped co-author Func, a precursor to Ansible, which is used to orchestrate systems in lots of diverse places. He’s worked on systems software for IBM, Motorola, Red Hat’s Emerging Technologies Group, Puppet Labs, and rPath. Reach Michael by email here.

[repost ]Ansible – A Simple Model-Driven Configuration Management And Command Execution Framework


This is guest post by Michael DeHaan (@laserllama), a software developer and architect, on Ansible, a simple deployment, model-driven configuration management, and command execution framework.

I owe High Scalability a great deal of credit for the idea behind my latest software project. I was reading about how an older tool I helped create, Func, was used atTumblr, and it kicked some ideas into gear. This article is about what happened from that idea.

My observation, which the article reinforced, was that many shops end up using a configuration management tool (Puppet, Chef, cfengine), a separate deployment tool (Capistrano, Fabric) and yet another separate ad-hoc task execution tool (Func, pssh, etc) because one class of tool historically hasn’t been good at all three jobs.

My other observation (not from the article) was that the whole “infrastructure as code” movement, while revolutionary, and definitely great for many, was probably secretly grating on a good number of systems administrators. As a software developer, I myself can emphasize — the software design/development/testing process is frequently painful, and I would rather think of infrastructure as being data-driven. Data is supposed to be simple, programs are often not. This is why I made Ansible.

Ansible: How Is It Different?

Ansible is a configuration management tool, deployment tool, and ad-hoc task execution tool all in one.

It requires no daemons or any other software to start managing remote machines — it works using SSHd (using paramiko, to make it smoother), which is something nearly everyone is running already. Because it’s using SSH, it should easily pass a security audit and be usable in places that would be resistant to running a root-level daemon with a custom PKI infrastructure. Best of all, you should probably be able to completely understand most of Ansible in about 20-30 minutes. Hopefully less.

I also wanted to make Ansible maximally extensible. Ansible modules can be written in any language — not just Ruby or Python, but any language capable of returning JSON or key=value text pairs. Bash or Perl is fine! In this way, Ansible manages to sidestep most of the popular Python vs Ruby language wars entirely, and should be of interest to people who like both — or neither.

Initial Setup

As Ansible is pretty new, it is probably best to grab Ansible from a git checkout. Packages for distributions are coming soon. See the instructions here to get started.

The key concept is that there’s really not much of anything to setup. There are no configuration files, daemons, or databases. Ansible does have a host file, which defines what hosts are in what “groups”, and you target hosts either by globs “*.example.com” or by groups. If you want to store this inventory list in LDAP, Cobbler, or something else instead, we have a facility for that, but I won’t cover it here. If a host isn’t listed in the host file, ansible won’t manage it.

A host file, which defaults to /etc/ansible/hosts, looks like this:



What’s perhaps more interesting is that no software needs to be installed on the remote machines. This means that if you have a clean image of your favorite OS running somewhere, Ansible can start managing that system immediately.

This lack of needing installed software on the remote machines makes it very useful for places where you have a large number of (perhaps legacy) nodes, but no good way to bootstrap them. So, if you have a lot of machines now, but no automated way to manage them, you don’t have to visit each node and get it ready for management. This should also make it great for consultants who have to get something done, but have to get in, get out, and leave no trace.

Using Playbooks For Configuration

Ansible has a powerful but simple configuration management and multinode orchestration format called a “Playbook”. One of the main goals for Playbooks is to keep them free of programming-like syntax and nesting, so they are easy to review and audit. Again, the motive behind Ansible is “infrastructure is data”, not “infrastructure is code”.

Rather than reproduce everything here, see github.com/mpdehaan/ansible-examples for a simplified example of setting up Ganglia. I’ve used CentOS-6 as the basis for this example, so users using other operating systems can at least get the idea of what a playbook looks like.

Here’s a full play (below). A playbook can contain more than one play and each play can select a different group of hosts to work with. Hosts are typically defined in /etc/ansible/hosts, but can also be defined by external software.

- hosts: nodes;ganglia.example.com
  user: root
     # what roles to apply?
     - include: tasks/common.yml
     - include: tasks/monitored_server.yml
     - include: handlers/handlers.yml

In the playbook above, we target all nodes in the group “nodes” and in addition to that, explicitly, also add the server named “ganglia.example.com“.

Various steps to perform on each host can be stored in the play, or, like I’ve done here, in separate files to encourage readability. “Handlers” are just like “tasks”, but are event-driven, and only get triggered when “change events” occur. If you’re familiar with notify/subscribe in Puppet, it’s exactly the same concept.

Just to show a bit more, here’s what the monitored_server.yml file looks like:

# file: monitored_server.yml
# this file defines behavior for the 'monitored_server' class of nodes

- name: install gmond
  action: yum pkg=ganglia-gmond state=installed

- name: configure gmond
  action: template src=templates/etc/ganglia/gmond.conf dest=/etc/ganglia/gmond.conf owner=root group=root
      - restart gmond

- name: ensure ganglia is running
  action: service name=gmond state=running

As you can see, playbooks are relatively free of programming-language like syntax. They are just a list of steps to perform for each group of hosts. While this looks like a script, it’s not. Each step is “idempotent” (as you will may remember from Puppet or Chef), meaning that only changes that need to be made actually get made.

Deployment And Orchestration

So, that’s clearly an ops-side configuration example. Why is this system good for app-side deployment and orchestration?

Well, playbooks are ordered and push-based, so you can address one group of hosts and then another. If you need to update your database server and then upgrade your app servers, it’s no problem to do very explicit ordering where you jump back and forth between addressing different groups of hosts, just like lines on a football team. Just include multiple plays in the same playbook file, all in order.

You don’t just have to work in terms of packages either. Ansible also ships with an example ‘git’ resource for checking out dynamic language apps straight from source.

Ad Hoc Tasks

A need that comes up frequently when managing a large number of systems is that of running ad-hoc tasks or making things happen via scripts on several machines at once.

Suppose you need to shutdown a service right now (in an emergency) or reboot several nodes. Configuration management and deployment tools are obviously the wrong tools to address this because you don’t want to describe the desired steady state of the system, or even a process, you just want to run some commands. But you don’t want to have to install a special purpose tool just for this either.

Ansible allows these kinds of steps to be done using the same management path from which playbooks are applied using the /usr/bin/ansible command line. You can also use the exact same resources that you use in playbooks, making things easy to remember.

ansible cluster01 -m service -a "name=memcached state=restarted"
ansible cluster01 -m shell -a "/sbin/reboot"
# etc

Learning More

Rather than trying to fully document the application here, if you are interested in learning more, or have ideas about the project, see the Ansible web site, follow the project on github, or join theGoogle Group. If ansible isn’t right for your environment, I at least hope it provides some interesting insight into ways of managing software systems.