Where to start

Back in 2011 I was starting up a custom solutions team that build virtual server clusters on top or our XEN infrastructure. A lot of virtual clusters had the same core components, and we kept installing and manually configure them over and over. The need to make repeatable installations was high, and with a lot of work we automated it with Puppet. It was the automation standard at the time.

Over the course of 2 years we had build an entire Puppet Master empire and carefully crafted Puppet based images that let us spin up virtual Puppet clusters (A bunch of nodes with their own Puppet Master ) per customer within a short time. At the time my fellow colleagues didn't know much about Puppet and didn't like investing a lot of time in it. Mainly because they had to learn the Puppet DSL and never got their heads wrapped around the execution ordering.

The main problems we had with Puppet:

  1. It took more time to create, test and maintain a Puppet module then to just SSH in to the server and install it by hand. Of course there is a tipping point, but it didn't get easier fast enough.
  2. It took to much effort for my colleagues to get proficient in writing Puppet code.
  3. Explaining our Puppet code to a new colleague took it's time.
  4. Maintaining Puppet code for multiple Puppet Masters the right way is hard.
  5. Orchestration over multiple servers was difficult at the time.
  6. The model we used with a single Puppet Master per customer (We only build and not manage at the time) was not cutting it. We needed automation with the same level of control, but without the Puppet agent or Puppet Master node.

Love at first sight

I'd read some news about a new configuration management tool called Ansible hitting a 1.0 release and decided to test it. I was hooked almost immediately. This was exactly what I needed. After one month of testing and building proof of concepts we were ready to take the big jump.

We rewritten all our puppet code, that took us more then a year to write and test, to Ansible within 3 months. What a blast! We got the following things right out of the box:

  1. Playbooks are easy to create and fast to write.
  2. Execution is in order, no extra layer of dependencies.
  3. No more separate Hiera setup to manage variables.
  4. Modules are built-in Ansible, no reinventing the wheel.
  5. No server Agent. That meant fewer firewall rules, fewer processes to monitor, no master server to manage and less configuration.
  6. The kicker: Everybody understands Ansible playbooks. No more single point of knowledge in the team.

After the love

Ansible is flexible. I would even say it is too flexible to get the best out of it at the beginning. Ansible provides so many way's to do the same thing, that you might get lost and make the wrong decisions. The most of my Ansible time went to figuring out the best way to make it manageable for the long haul.

  1. You need rules to get the best out of your playbook setup or it gets messy real fast.
  2. Variables, you can set them all over the place. This bit us quite a few times.
  3. Roles, use 'm. But don't use 'm as playbooks.
  4. Ansible is moving fast, so don't let your roles and playbooks get to old.
  5. Check mode is not checking everything, so be careful in production.

Well oiled team

After a few years with Ansible, I still like it as much as in the beginning. It's not just a configuration management tool, but helps us with building new infrastructure, it runs tests for us, it deploys applications and gives us true automation over multiple clouds.

The list of modules keeps on growing and supporting more and more over time. It even does Windows and networking equipment now. Ansible is an essential tool for the system administrator.


While I chose Ansible as our main deploy tool, Puppet is still very useful when you are trying to keep a server in a certain state. They are both excellent tools, with both their strengths and weaknesses. Ansible just happens to fit our use case better.


Can't wait to start? Head over to the Ansible GitHub repository and get going!. In the coming weeks I will share some of the good and the bad design decisions we made with Ansible.

In the meanwhile, have fun with your Playbooks.


comments powered by Disqus