By now, you’ve probably overheard IT admins say things like “I wrote an Ansible playbook to automate that thing,” or ask rhetorical questions like “Can Ansible do that thing for us?” And if you’re like me, a mostly Windows admin moving into environments where Linux servers also play a major role, you’re probably wondering what the heck Ansible is.
If so, you’re in luck, because Ansible can greatly simplify your management of everything – whether those things be Windows servers, Linux servers, or network devices like switches and firewalls. Essentially, Ansible provides a way to run ad-hoc commands or pre-configured scripts on the local machine or perhaps hundreds of other servers, with just a few keystrokes.
Ansible is agentless, meaning there is no software to deploy. It uses temporary remote connections like SSH and WinRM in order to do its work. Oh, and here’s the best part: You can use Ansible for the low, low price of $Free. Yes, it’s owned and maintained by Red Hat, but you don’t need to pay for it unless you want to use (and have them support) their fancy GUI tools, which are briefly described later in this post.
Components
You tell Ansible to do things by calling pre-built modules in a YML file. These YML files are called playbooks. You can think of a playbook like a shell script: It’s just a file that contains functions, which are really just cleverly grouped commands.
The functions are called plays in Ansible, and the individual commands are called tasks. A bunch of tasks make up a play, and a bunch of plays make up a playbook. Pretty simple!
The picture above illustrates how tasks and plays make up a playbook. You can imagine writing the script on the right – by the time you write all the functions, add the error-checking and logging, etc., you’ve got quite a few lines of code. Then you need to test it, find all of your typos, make sure it all works, and make it available to your team to use. But what if they just want to use part of it, or modify something? What if they’re not great at scripting?
You can see where this is going. In the Ansible playbook, you don’t have to worry about the details of HOW something gets done, you just call the Ansible module that does the thing, specify some parameters, and let it do all the work. What can be done in 4 lines in an Ansible playbook might take two dozen lines of code in a script.
But plays can be grouped further into what Ansible calls roles. Roles are like plays and/or tasks stored in separate files. This is great for sharing code and reducing duplicated efforts. For example, plays for common actions can be stored in a central location and called by multiple playbooks. This eliminates the need to write the same code over and over in multiple files.
And if you have some very specific needs, or just want to write a shell script anyways, you can just have Ansible deliver and run a script of your own. There are pre-built modules available for doing just that.
Architecture
Ansible is a Linux-based tool. The Ansible server that keeps and executes the playbooks is called the ‘control node,’ and this must be a Linux variant. By default, it reaches out to other computers and devices via SSH. But Ansible can also leverage Windows Remote Management (WinRM), using Kerberos for authentication and encryption, without joining the control node to an Active Directory domain. The next post in this series explains how you can set this up in your homelab or test environment.
And of course, you don’t have to run it from the command-line forever. There are GUIs you can use if you need to run playbooks on a schedule, integrate with a git repo like Gitlab, or add multiple users with different permissions. Ansible Tower is the original product for this, which has an open-source upstream fork called Ansible AWX. The new GUI tool is called Ansible Automation Platform.
Getting Started
I won’t go into the installation process. There are a number of free tutorials available online, and the Ansible docs do a pretty good job of explaining things. For paid training, this Udemy course is fantastic – if you watch it for a bit, you might be able to get it for $10-15 USD.
In learning Ansible, it’s helpful to have a working knowledge of Python. Not because you’ll ever need to write any, but because indentation matters in YML, and this won’t be a major hurdle for you if you’ve learned to deal with it writing Python code. You may also eventually have a need to separate Ansible execution environments, for example to use a specific version of Ansible, or a specific version of some necessary Python package. You can do this by using Python virtual environments.
And yes, Ansible is built with Python, and has a Python API. Because despite the hate it gets for being slow, from only the saltiest, most miserable of nerds who would have us all carving C into stone tablets if they were in charge, Python is awesome. So do yourself a favor and learn it if you haven’t already (but seriously, don’t throw out your chisels).
Good luck and have fun automating absolutely everything!