It’s Thursday evening of a particularly difficult week at work. Tomorrow is a public holiday, effectively making this – a Friday. My brain is blank and exhausted, so I can’t do anything productive. And I’m too tired to go out. But I can still learn a thing or two.
First things first – cancel the external noise. I want something loud, but not too intensive, and with no words in it. So this 2 hour blues instrumental collection comes in handy. Start the playback, put the headphones on, and push the volume up.
Now. Here’s something I wanted to look into for quite some time – Ansible configuration manager.
I’ve deployed Puppet to multiple environments, managing dozens of servers, and even a few desktops. I’ve used community modules and built my own. I’ve ran it on machines big and small, old and new. And I still love it.
But my requirements have gradually changed. Or maybe I’ve just learned more about configuration management, web hosting, and cloud computing. Puppet still works well for me, but I keep getting this feeling that there is a better, simpler way of doing things that I need doing.
I’ve read about Ansible since a while back. Then I’ve attended the session about it during the International PHP Conference 2014, back in Berlin, Germany. It was insightful, but not more than that. Last year, my Linux distribution vendor of choice – Red Hat acquired Ansible. Which obviously spiked my interest – it’s only logical to expect Fedora, CentOS and Red Hat distributions to do more with it and to push it forward. But I didn’t have time to look at it. And today I do.
I’ve read through the Ansible Documentation first. It is quite an easy read – short enough, but not to condensed, with lots of examples, covering all the important bits. I got immediately hooked. Here are a few things that appealed to me.
- YAML. Admittedly, I’m not the biggest fan of YAML, but the simplicity and readability of it is a definite advantage over Puppet language (subset of Ruby in a way). YAML is also easy to generate programmatically. Puppet can offload parts of the configuration into the YAML too (using Hiera), but it’s not the same.
- Push instead of pull. Originally, Puppet was supposed to be setup with the puppet master server and puppet agents running on individual hosts. But this approach seems to be too complex or fragile to support, so many people prefer master-less setups now. I’ve been using master-less Puppet setups in almost all of my environments and it runs well. A separate git repository is usually used for each network, containing all the configurations for the servers. But this now becomes complicated as well, both at server provisioning stage and during the lifetime of the environment, especially where flexible access control is needed (hosting of clients’ environments with limited access for staff on both ends). Ansible however uses push approach, which suits me way better – most of my environments have bastion hosts, which would be ideal for Ansible.
- SSH as a transport. Again, this suits my bastion-based environments nicely.
- Possibility to use Ansible for project deployments, not only server configurations. Puppet can be used for project deployments as well, but it’s much more complicated of a tool for things that we are doing.
- Sequential task execution. This seems super handy. It takes time to get used to Puppet’s unpredictable order of tasks executions. Sometimes it works well. Sometimes it causes issues and hair pulling out. Sequential tasks just feel more natural.
When I finished with the Ansible Documentation, I decided to look around and see what other people are saying about Ansible, especially in comparison of it to Puppet. Here are a few posts worth reading:
- Ansible vs Puppet by Dan Tehranian: An Overview of the Solutions (part 1) and Hands-On with Ansible (part 2).
- Moving away from Puppet: SaltStack or Ansible? by Ryan Lane.
- Lessons from using Ansible exclusively for 2 years by Corban Raun.
After reading all of that, it sounds like Ansible is a better match for what I need than Puppet. It’s too late and I’m too tired to try it today, but I will definitely be getting my feet wet in Ansible waters in the next few days. As always, sandbox/playground repositories and my dotfiles will come first…