Why Should I Care About Ansible?
It’s a valid question. There are a lot of techniques and tools to manage your infrastructure, including nothing at all.
So why should you consider Ansible?
The Manual Way – CLI
You could configure everything about your machines by typing it out.
This is a great way to learn, but after a while it can get tedious.
It’s very difficult to remember all of the commands, in the right order, expecially months or years down the road.
And, the more machines you have, the more frustrating it becomes.
Not to mention, there might be variations in the setup that lead to hard to find bugs.
The Semi-Automatic Way – Shell Scripts
Most of the commands you typed can be captured and put into a shell script.
This is great since you don’t have to remember all 100 or so commands it takes to configure a machine.
But, what happens if one of the 100 commands fails halfway through? Can your script recover?
And how do you deal with constantly changing information like IP addresses, passwords, and more?
Shell scripts do help, but create other problems too.
Ansible Can Help
Ansible captures the same information as your shell scripts and even has a shell option that can help you transition.
All of this comes with additional “smarts” that help with recovery, environment changes (IP addresses), and idempotence.
What is idempotency? It’s the concept of something having a singular result, no matter how many times it is run.
Unlike shell scripts, where all commands run in order whether they are needed or not, Ansible intelligently skips pieces that don’t need to run.
Ansible is focused on idempotency, or the results… not the actions.
It’s one of my favorite features, and you might appreciate it as well after continuing through these lessons.
Push vs Pull
There are other tools out there like Chef, Puppet, Salt(Stack), and others.
The main differentiator is Ansible operates as a standalone piece of software, and pushes into machines by connecting over SSH.
The rest operate on a pull structure*, where all the machines dial a master and configure themselves accordingly.
To be fair, it’s still a bit unclear which method is the better way for most use cases.
But with companies like Twitter switching from Puppet to Ansible, push is far superior, especially because you don’t have to (manually) install an agent on each machine.
*Note: There are plugins that can change the connection mechanisms of Chef, Puppet, Salt, or even Ansible. I’m making a generalization based on what I think are the most common and community-recommended methods.