A dozen automations and DevOps practices I replaced with Ansible

Ansible is an automation tool that can you run from your laptop or a server to automate tasks across many servers. It's simple enough to use for personal tasks, flexible enough to introduce incrementally, and powerful enough to scale.

As I learned to "think an Ansible", I found it replaced a range of tools and practices I used before. Ansible has simplified a lot. While introducing some new tools can be divisive for teams, it's been easy to sell the benefits of Ansible.

Here a dozen different things that have been simplified and standardized by using Ansible.

1. Wildcard Nginx entries

With Ansible, a template can be used, creating a clear, explicit record for each domain on the server.

Making exceptions for a single domain is straightforward by using an Ansible inventory variable.

2 and 3. Nginx 'map' and files

To add some variables into a group of Nginx domains, I had written out a mapping of names to port numbers, loaded into a Nginx "map" structure using a Nginx include file.

With Ansible, just use templates and variables.

4. Multiple .env files

For a collection of services that shared some environment variables but also needed some unique per-cluster values, a shared ".env" file could be loaded into systemd and then an override per-cluster env file could be loaded.

With Ansible, a simpler, single .env file can be put into production using inventory variables to write out the combination of shared and unique values that each host needs.

5. Systemd template units and drop-in units

Systemd supports "template units" so that a group of similar services can be launched with a single config file. "Drop-in units" can be used to further override a specific service.

With Ansible, templates and inventory variables can be used.

6. Shell scripts

A certain amount of shell scripting will likely always have a place in DevOps and automation work, but Ansible has a large "standard library" to handle the most common tasks like copying files, creating directories, symlinks and rsync'ing.

The difference is Ansible roles often support a "--check" mode, so you could check what /would/ happen if you really ran the script.

If you've scripted code that copies files to a remote server, then SSHs to the remote server and automates some further commands there... that is likely more naturally done with Ansible.

7. CI pipelines

Continuous integration pipelines have their place to deploy new app builds, but they can be a poor choice to deploy new configurations, especially ones owned by root that rarely change. Why? CI servers are common entry points for exploiting networks, and the last thing I want to do is give them root access on remote servers.

Ansible can run locally and prompt for a sudo or ssh password, so there are critical credentials stored in a CI server that would rarely be needed.

8. Backups

Get rid of backups? Yep. For simple servers that don't store any critical data, they can be completely defined in Ansible, possibly with an off-the-shelf playbook from the Ansible Galaxy.

The restore plan is simply to re-run the Ansible playbook for the server, possibly against a brand-new, empty server

9. Testing

Ansible makes several levels of QA checks easy, reducing the amount of further testing you need to do.

• Ansible's --check mode provides a "dry run" of what a playbook would do.
• --diff extends --check mode further by showing the actual differences that would be made in text files, rather than just whether they would check or not.
• Molecule is a testing framework for Ansible. Because the "tests" you write with it are just more Ansible playbooks, there is little to learn. In the simplest form, you can spin up a Linux container on your laptop and see if your Ansible code runs against it without errors.

10. Logging into servers

There are a few problems with "just logging to servers and doing stuff".
Things that are supposed to be consistent between servers tend to drift apart.
Often time, confidence can be lost that anyone remembers exactly what all the customizations have been made to servers.

Finally, junior team members can remain in the dark about the changes being on server.

Because Ansible playbooks are a form of code, they can be drafted "offline" and submitted for peer-review before they are run on real servers. This creates shared knowledge and documentation.

A new team member who might be trusted with root access on a server can safely draft some Ansible code for peer-review.

11. Tmux and Xpanes for parallel SSH

xpanes is a slick little utility built the Tmux terminal multiplexer. Together, they form a powerful tool for interactive, parallel SSH. It's also a dangerous tool, allowing you remotely break any number of servers at the same time.

Ansible supports deploying changes against as few or as many servers as you like. All the safety nets described above make it a much safer alternative than interactive, parallel, SSH.

12. Write less documentation by using Ansible

I used to maintain a Google Docs with a list of all the changes that we had baked into "Base Image" that we used to harden all our servers with a more secure baseline. This included stuff like setting up email, logging and monitoring in a standardized way as well. The result was saved as disk image (Amazon AMI) that we could re-use for new servers.

Ansible serves as a form of "executable documentation". After we converted or "Base Image" to an Ansible Base Role, we no longer needed the disk images or the documentation of what the changes were. Just read our Ansible Base Role and execute it against a "bare" Linux servers.

Wrap up. No Examples?!

I haven't included example Ansible syntax here because I'm not talking about using Ansible "tricks" that are especially hard to figure out.

You'll see a theme in what I'm describing above: The basic features of Ansible inventory variables, templating and the built-in modules cover a lot of cases.

Indeed, the beauty the Ansible is that it replaces a lot of tricks and specialized knowledge across a range of other technologies with a standard way to deploy and configure things.

It's rare that adding "one more tool" to a toolbox seems like a simplification, but Ansible is that rare gem of a tool that just might make you look forward to managing your tech stack a bit more.