Running Ansible from your Computer: Why AWX/Tower is Better

This blog series focuses on presenting complex DevOps projects as simple and approachable via plain language and lots of pictures. You can…

This blog series focuses on presenting complex DevOps projects as simple and approachable via plain language and lots of pictures. You can do it!

Ansible is a flexible and powerful tool that permits tasks to be written in plain YAML language and can do some amazing things.

You can run Ansible from any Unix-like computer, including macOS, but not Windows (sorry Windows users). However, there are some major limitations to running on your own computer compared with running from a central platform attached to a CI/CD.

Let’s spend some time talking about the problems you’ll need to tackle with Ansible on your local computer, and how AWX/Tower can do better.

Host Inventories: Targeting

Ansible takes an input of YAML tasks and roles, and translates this into SSH (Linux-like) or WinRM (windows) commands. It reaches out to the hosts you’ve specified and runs the idempotent (repeatable, stateful) jobs and then reports status.

Aside from all the Ansible cool things, there is a task for you — what hosts do you target? If you have only a few (or even a few dozen) hosts, you can work with a static list of inventory — you have their names and IPs listed, and you go from there.

Static inventories look like this:

[DataCenterHosts]
Host1 ansible_host=10.10.10.1
Host2 ansible_host=10.10.10.2
Host3 ansible_host=10.10.10.3

And that works great for a legacy infrastructure — where your hosts are pets — static, named, mutable, and long-lived.

But what about this new world we’re running into? Micro-services, immutable hosts that are rebuilt constantly, cloud environments that spin up and down based on dynamic jobs, or schedules? Well, then this static host list starts to look less appealing and more like a heck of a lot of work to keep even mildly up to date.

However, there is a better way! Dynamic Inventories (really just Inventories with dynamic Data Sources) are updated automatically when a job targets them. They talk to the metadata provider of a cloud to select hosts that:

• Exist

• Are powered on

• Meet any other criteria you’d like to target that the cloud provider knows about

These dynamic inventories use native Ansible functionality, but the credentials and selections can be hard to manage on your local computer, but can be configured and automated easily on an AWX/Tower server.

Credentials: How Do We Get In?

Once the target hosts are identified, we need to select which authentication we’ll use to get into the host. Remember, Ansible, whether run locally on your workstation or from an AWX/Tower server, authenticates directly to the host.

If you’re running this Ansible job locally you’ll need to either point at an authentication file or type passwords in, both of which easily permit you to know and see the password used to authenticate. This means that administrative rights are likely exposed to whoever runs these tools.

That’s okay, but it’d be better if we could expose the use of automation to users who maybe aren’t qualified to be full engineers with admin rights on these systems, right?

In that, AWX has a better solution. Credentials can be created and exposed to the user without being shared in plain-text, something very powerful when used correctly.

Imagine building a workflow or job that a Security Operations Center (SOC) can run that blocks an IP on several firewalls, or runs updates across hosts in waves, all without the SOC/NOC team being able to log in and make manual changes to your hosts.

Very powerful indeed.

Running Ansible: Available and On Schedule

Lastly, we need to actually run ansible. As we’ve covered above, Ansible can only be run from a Unix-like host. Windows hosts are (currently) unable to run Ansible. Engineers can of course build a virtual machine and run Ansible from there, but there’s already significant complexity maintaining one workstation per employee, and now engineers are expected to maintain two and keep the versions in sync with other DevOps engineers?

It’s a recipe for failure.

There is, however, a better way with AWX. It spins up its own runner host, a small-ish Linux-based host in a container. This host is always available on the server-side to run Ansible. This has a few benefits.

Benefit 1: Always available

Jobs can be scheduled to run every minute for years, or overnight when everyone’s asleep. Since this runner is always available, server-side cron schedules can reliably run jobs regardless of where employee machines are, powered on or off.

Benefit 2: Can Run Ansible

This can’t be overstated — Windows hosts can’t run Ansible. Your engineers will need to either be in Mac or Linux-based hosts or run a VM.

Having an always-available Linux runner that has the right software and operating system brings down the amount of expertise an engineer needs to benefit from DevOps tooling and automation efficiencies.

Benefit 3: Network Access

Depending on the complexity of your network requirements, some employees might not be able to get to all the hosts on the ports they require to make Ansible work. Rather than permitting individual employees or teams to have this access, you can instead permit only the AWX “task” container that runs these jobs.

This can help standardize and limit network access, a further security boon.

Sold? Let’s Build It

Hopefully, I’ve made it clear how powerful AWX can be and why it’s useful. So now, of course, let’s go build it!

I’m currently writing articles that go over how to deploy and maintain AWX, how to build dynamic inventories, and how to build modular, scalable credentials.

Let’s get to it. Good luck out there! 
kyler