Ansible — to orchestrate or not orchestrate! What’s the options?

My teams and I have been working with Ansible for quite some time. It’s an extremely powerful, lightweight tool to have in your toolkit if you are a DevOps engineer. For those who are not familiar with Ansible, here’s a brief overview — “Ansible is an open-source software provisioning, configuration management, and application-deployment tool enabling infrastructure as code. It runs on many Unix-like systems, and can configure both Unix-like systems as well as Microsoft Windows”. You can find out more about Ansible here.

Ansible is agentless, which means as long as you have Ansible running on your localhost or through your engineering laptop or orchestrator, you can start automating your infrastructure and software stack deployments immediately! Teams that want to leverage Ansible to automate their infrastructure and software stacks have two options available to them as shown below:

You can either run ansible locally on your host (by installing Ansible directly on your host), or you can deploy either Ansible Tower (or its community version — AWX). When using Ansible on an orchestrator such as Tower or AWX, the orchestrator runs the Ansible and executes commands locally via either OpenSSH and WinRM transports. Ansible relies on Python to execute commands on the localhost (hence in this model, there is no need for Ansible to be installed.

From v2.12 onwards, the orchestrator running Ansible detects the target OS platform, distribution, and version, then consults a table listing the correct Python interpreter and path for each platform/distribution/version. If an entry is found, uses the discovered interpreter. If no entry is found, or the listed Python is not present on the target host, searches a list of common Python interpreter paths and uses the first one found.

If you choose to run Ansible locally, then you need to install Ansible (and any pre-requisites) on the host first. I’ve worked with clients who have used both approaches to leveraging Ansible. Whilst DevOps engineers love working with Ansible, security teams are sometimes a little wary of using it locally. The reason is not that Ansible has vulnerabilities, more that it is so powerful, and enables users to automate tasks so quickly, you can do more damage more quickly with Ansible running on the localhost.

Security teams therefore tend to encourage us engineers to make use of Ansible Tower or AWX. Whilst both products are great (Tower adds enterprise scale and support over AWX), if you or your client has a particularly complex estate, having a centralised orchestrator run all jobs (for each stage) in parrallel can sometime become overwhelming (I’ll write another story on how to overcome centralised, multi-staged orchestration using AWX soon). It’s for these reasons that I saw an opportunity to provide a 3rd option for automating workloads using Ansible. This option would look to distribute the running of playbooks like in the localhost model where Ansible is installed locally, but without Ansible installed!

Want to know how we did it, you can find out more here.