How Smart Tools Are Changing Us
There comes a time in every System Administrator’s career, when using a configuration management (CM) tool is mandatory. It can be because manual tasks are too complex, or because too many systems need to be configured/updated/patched as fast as possible, and many other reasons.
When I had to do this, I started looking at products like Puppet, Chef and SaltStack, but I felt overwhelmed by the choices and wasn’t sure which tool to choose.
The goal was to find something that worked, worked well, and didn’t have a steep learning curve. Each tool seemed to approach the tasks differently, with many varying pros and cons, and each required different (sometimes complex) setups. During this time, Mihai, a colleague of mine, suggested I look into Ansible.
And there was no looking back!
I started using Ansible just as a comparison between other existing technologies, and I got “stuck” with it pretty fast.
While using it, for both my career and personal projects, and creating many ‘playbooks’ (as they are called in Ansible) for various small jobs, it didn’t take long to realize that with a minimum of effort and some planning ahead, I could create something truly amazing: full deployment automation with reusable resources (playbooks, keys, configuration templates etc.), that will guarantee to work each and every time.
So why exactly Ansible?
There are many arguments out there as to why a certain configuration management tool is better than others, and I’m not going to bore you with information you can easily find online.
I will however share my personal opinion on the matter.
The reasons why I stuck with Ansible might not be considered good criteria by most of best practices handbooks, but have more of a practical angle:
- No steep learning curve. You can get something functional in less than 15 minutes.
- No infrastructure required. All you need is your PC, and the target hosts, with easy SSH access.
- No client needed (on *nix machines). All you need is SSH access, no other dependencies, no preinstalled clients or settings. This is very useful especially for cloud-based systems, where you just need to setup SSH keys (best practice) and you’re ready to go.
- High granularity when running playbooks. You can be very specific with what tags to apply, on which hosts. This helps a lot when creating playbooks, because you can just retry certain sections of your playbooks.
- Speed. Although it is not the fastest CM out there, you can get good speeds when you need to re-run only certain tags or on certain hosts only, instead of re-running the entire playbooks over the entire inventory.
- Inline commands. You can easily run full bash commands via Ansible, while still using the inventory file, its vars and secret vars, credentials, etc.
- Documentation. This is more of a personal criteria, but it feels like Ansible’s docs are much easier to read and are better structured than other CM tools.
- Full control over your code. Top-down execution makes it far easier to read the playbooks than a model-driven approach.
Time to take it all out for a spin!
My first “proper” project was when I was asked to help out with a Jenkins CI setup, from scratch.
The goal (which I am proud to say we achieved in a fairly short time) was to build a fully redundant CI environment, with automatic failover, with a very low RPO (Recovery Point Objective) – under 5 minutes – and a very low RTO (Recovery Time Objective) – again, under 5 minutes, with all its bells and whistles (synced configurations, synced projects, synced plugins, synced slave workers).
So why a configuration manager (Ansible) for this job?
You might argue that you could just do the entire setup manually once, faster than scripting playbooks.
You’d be absolutely right!
However, the goal is to end up with a highly available CI environment with automatic failover that will spread across two distinct data centers. This means you need to replicate the setup in both data centers. What if you want to extend it to a third? Or forth?
We also want to have the ability to make the same changes (updates, patches etc.) to all our instances. In a traditional setup, you’d have to issue the same set of commands in each instance, one by one, until you’re done. Not with Ansible!
But what if you need to change back to a specific version, for a short period of time? You can easily version your playbooks using any SCM tool available (git, svn etc.), and simply apply the version you want. Jumping back and forth has never been easier.
Lastly, one of the most frequent source for errors is the user itself. Human error is not as uncommon as you’d like to think. Automating the entire process with well-written playbooks ensures that our setup is consistent across all sites, and no matter how many times we deploy it, it’ll always have the same result.
So there you have it! A truly smart tool can make our lives and work much easier. A big ‘Thank you!’ to my colleague Mihai for introducing me to Ansible, for sticking with me throughout the Jenkins CI setup and also for helping me craft this article.
What about you? Have you used any configuration tools? Do share your experiences in the comments section below: