Authors: Luke Rawlins
A few months ago I attended a one day Ansible workshop in Columbus Ohio with a colleague. The workshop was sponsored by Red Hat and contained several labs, which is well worth your time if you have the opportunity. I wasn’t sure what to expect, generally you don’t walk away with much working knowledge from these short events, but I had some experience with Puppet (most of it frustrating) and I was curious to see what Ansible could do for my organization.
Honestly, my expectations were pretty low. In general I haven’t been impressed by the devops trend and as you know from my previous posts I’m fairly skeptical of containers. That said, my organization has a need to automate a lot of the everyday tasks that take time away from improvement projects, and everything I had read about Ansible lead me to believe that it would add value to our operations. I was not disappointed. Ansible has the perfect balance of power and ease of use, it has become my go-to tool for any repeatable task. Ansible is so easy to learn that we started putting together some playbooks for testing the day after the workshop.
So why am I so impressed with this tool? Here are a few of the reasons that I think Ansible is worth a serious look, if you are trying to automate more of your infrastructure.
This alone is a great reason to at least give Ansible a trial run. Ansible performs all of its operations via ssh and python (python 2.6 at the time of writing, and no you don’t have to know python to use Ansible). If you have Linux or Unix operating systems on your network that were released in the last 10 years or so, it is very likely that Ansible will be able to manage them right out of the box. Nothing to install, configure, or patch on the target hosts. This means that you can get started with testing right away. Less work makes me a happy Sysadmin and Ansible accommodates that laziness efficiency mindset very well.
Or any control server whatsoever. If you have a Mac or Linux based laptop you can install Ansible right now and start using it from your workstation. I guess there is also a Microsoft Windows component but I haven’t used it yet, so I’m only mentioning it for completeness YMMV. The fact that you can get started without buying any additional equipment or taking time to spec out and build a new server is hands down one of the best reasons to try Ansible. If, eventually, you become brainwashed convinced like me (one of us, one of us….) that Ansible is the greatest thing to happen to you since barbecue sauce on pizza, then you might want to build out a server to share playbooks with your team, or to use as a controller for scheduled tasks and what not. Or don’t share and just let everyone wonder how you suddenly became so amazing…. But seriously don’t be jerk, share your playbooks.
Most IT departments should be able to get Ansible up and doing real work in a matter of weeks. Remember how I said my group started using Ansible in testing just a day after attending the workshop? That was the truth, Ansible playbooks are built from flat text files that are structured using yaml markup which is very easy to learn. If you haven’t used yaml I’ll have a few examples up in a week or two, with playbooks that can help you get started. Ansible comes with modules for most common tasks built right into it. Need to patch a bunch of servers? Ansible can do that. Need to update a hundred thousand million files? Ansible can do that. Need to edit a configuration file and reload a service to meet new security compliance standards, on every server in your network? Ansible can do that…. And I’m only mentioning the low hanging fruit here…. those kinds of god awful tasks that used to take days or weeks now take just minutes. I’m not the smartest person you will ever meet (or not meet…. don’t be weird about it), but I was able to get Ansible to do real work like this on production servers within just a couple of weeks. If you mange more than a half dozen servers learning the basics will be well worth the effort and will save you time and energy in the long run.
In an upcoming post I’ll explain how I got started using Ansible from an operations perspective. I’m less dev and more ops on the devops scale so don’t expect a deep dive into the inner workings of ansible. I will, however, show you a few strategies that I used to get started. As well as share a couple quick and easy playbooks to give you some practical use case examples.
https://www.ansible.com/overview/how-ansible-works (overview of how it works)
http://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html#managed-node-requirements (requirements for your target nodes)