Ansible First Impressions

When it comes to server provisioning, I’ve only had experience with Chef. The new place I work in uses ansible and I was tasked with writing a playbook for deploying and configuring some of our software there. The whole experience was overall good. My main gripe with ansible is that it uses yaml files for running actions.

I think that’s a huge drawback: instead of having the full python language at your disposal for writing playbooks, you’re limited a weird yaml file format that gets in your way the moment you want something more complex. On the other hand, I haven’t read enough ansible to come across someone complaining about this decision, so maybe the people using it don’t see this as a problem. Also, python, unlike ruby is not a good fit at all for DSL languages. So I imagine that the creators had no choice but to use a configuration file format like yaml instead.

One thing ansible gets right is ansible-galaxy. In Chef, if you want to use a cookbook, it has to be cloned in your Chef repository. This can lead to the temptation of editing the cookbook directly, as outlined here: and is somewhat of an anti-pattern. In ansible, you don’t have to worry about being tempted, you can list the external roles in a separate files and install them ansible-galaxy install -r external.yml` on-demand. Ansible being agentless also helps here, because only the deployment machine has to worry about having the right roles.

The other thing it gets right is ansible-lint, which is great for people like me using ansible for the first time, as it forces you to write clearer playbooks and stick to conventions.

For now, I still think Chef is the superior choice: you can’t beat the ruby DSL and I don’t trust agentless monitoring tools as much when it comes to making sure your servers are configured the way you want them to at all times.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.