Ansible Tips and Tricks: –list-hosts and/or Forcing People to Use –limit

As much as I would like to think that I am careful when running Ansible playbooks, I am still a flawed human being, despite my best efforts.

And as I am sure you can imagine or have experienced, some playbooks can be dangerous if run across the wrong hosts, or too many hosts: Tasks that reboot machines or tasks that reconfigure hosts that don’t fit a certain criteria come to mind.

So, here, I would like to show you a couple of safeguards when running an ansible playbook. One of which, after 6 years of using Ansible, I just learned about earlier this week, thanks to a colleague.

The Usual “This is Not the Only Way” Disclaimer for the “Well, acshually . . .” Douchebags

There are a myriad of ways to accomplish what I am talking about here. when conditionals come to mind. Or, if you are using AWX/Tower (more on this later), you can use vars_prompt or surveys to force people to use certain parameters.

My point is that I am fully aware that there are multiple ways to accomplish error checking or guardrails in one’s ansible code. Here, I am focusing on only two of them.

I will be more than happy to read your blog post about the others!

Recommendation: In-House Demos

I can’t stress enough how important it is to have team members do demos. The more the better.

With my previous employer and my current, there was/is a huge emphasis on demonstrating the results of one’s labor. In my last job we had a weekly meeting dedicated to demos alone that came to be called affectionately “show and tell,” where everyone was required to do demos, particularly how we had solved a problem. It was one of the most productive meetings all week, or at least I thought so.

It isn’t just about, “hey, we have this new thing, let me show you.”

More often than not, something great and unexpected comes out of it: A better way to do things; ideas for leveraging what one demonstrates elsewhere, and so on.

In a recent demo, I showed everyone how to run a certain playbook that is dangerous to run without specifying an inventory limit, and I was asked the very important and relevant question: “What if we make a mistake and forget to put the limit?”

As it turns out, a fellow Ansible engineer had a recommendation: use ansible.builtin.fail. More on this later.

First, let’s take a look at another trick: --list-hosts:

Trick #1: --list-hosts

When I run Ansible from the command line, I am very careful. To date, I have always and every time used the --list-hosts option before actually running the playbook. It’s a nice in-line safeguard and I have used this since day 1. It does not run the playbook, but will output the hosts pulled from the specified inventory. I always have the --list-hosts appended at the end of the ansible-playbook command. Then, once I verify, I hit up arrow to back off the --list-hosts and press enter.

The problem is that not everyone knows about this trick, so it won’t help you if others will be running the playbooks you create. Furthermore it won’t help you when running this through Ansible AWX/Tower.

Trick #2: ansible.builtin.fail

To date, I have used failed_when before, but I had never heard of using the Ansible ansible.builtin.fail module.

It’s very simple. As your first task, you would insert this:

  tasks:
    - fail:
        msg: "You must specify a Limit! Please try again with proper Inventory group or host(s)."
      when: ansible_limit is not defined
      run_once: true

That’s it!

This works both through the Command line as well as in Ansible AWX/Tower. Here’s what it looks like in the CLI:

And here’s what it looks like in Ansible AWX/Tower (be sure to enable the Limit field as a “Prompt on launch”!):

Neat, huh?

And, as long as someone has plugged in at least one inventory group or host in the Limit field, it runs just fine.

Hopefully this leads to a safer run for your playbooks!

Hit me up on twitter @RussianLitGuy or email me at bryansullins@thinkingoutcloud.org. I would love to hear from you.