(Fabio Alessandro Locati|Fale)'s blog
April 27, 2022
A couple of years back, I wrote a blogpost on obtaining the previous Job ID in Ansible Tower workflow. Now, let’s go further and create another module to obtain the output of such a job. Before moving further, I want to specify that I talk about Ansible Tower since this is the most known name for this software, but I could also be talking about AWX or Ansible Controller since those are the same codebase.
Read More 
November 15, 2020
Ansible Tower allows you to create Workflows, which enable you to create complex workflows by putting together multiple Ansible Playbooks. Ansible Tower Workflows can have some simple logics, such as run different Ansible Playbooks based on the outcome (success or failure) of a previous Ansible Playbook run. Sometimes, though, you need to have more information about a previous Ansible Playbook run than just the outcome. I recently found myself in a situation where I had an Ansible Tower Workflow with two Ansible Playbooks into it, where the first one was performing specific tasks.
Read More 
October 6, 2017
One of the big advantages that Ansible Tower and AWX (the open source and upstream version of Ansible Tower) bring to the table is the Role Base Access Control (RBAC). This will allow you to select which users (or teams) will be able to see which objects in Ansible Tower as well as which jobs they will be able to run. Obviously to leverage the RBAC, you will have to have personal accounts for every user of your platform.
Read More 
September 7, 2017
In October 2015, Red Hat bought Ansible Inc. As far as I know, in the acquisition, two close source components got acquired by Red Hat: Ansible Tower and Ansible Galaxy. Since the day of the acquisition, Red Hat has been very clear on the fact that those two components would have become open source at a certain point, even if there was not a public date or timeline yet. Making a codebase open source is not always easy and quick process.
Read More 
August 18, 2017
Around one year ago, I did a post around Ansible Tower High Availability maintenance, but in the mean time many things changed and that post is not up to date anymore, so I decided to create a new one that covers the same topic but for Ansible Tower 3.1. From Ansible Tower 3.1 we lost the distinction of Primary Ansible Tower and Secondary Ansible Tower. That concept was related to the fact that the Secondary Ansible Towers were in a hot-standby mode.
Read More 
July 26, 2017
A lot of times during my job I found myself with the need of Ansible Tower testing environments. In the last few weeks I created a Vagrant script to actually automate it. As this is a single host installation, which is usually more than enough for the majority of tests I do, the Vagrant file is very easy: Vagrant.configure(2) do |config| # Set machine size config.vm.provider :libvirt do |domain| domain.memory = 2048 domain.
Read More 
May 31, 2017
Ansible Tower 3.1 has recently been released, and it does implement real HA. In fact, up to version 3.0, Ansible Tower multi-node installation, only allowed a single machine to be primary and the switch was not possible in an automated fashion, so if the primary Ansible Tower would have collapsed, an operator should have promoted one of the secondary Ansible Tower to be primary to be able to carry on the work.
Read More 
September 28, 2016
IMPORTANT NOTICE: This article deals with Ansible Tower <= 3.0. If you are looking for information around Ansible Tower >= 3.1, please look my newer article on the topic. In the last few months I’ve setted up multiple times Ansible Tower, but I’ve noticed that there is not much documentation on how to perform basic maintenance on Ansible Tower High Availability setup, so I decided to write an article about it.
Read More