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.
Since Ansible Tower 3.1, we have active-active clustering and therefore all Ansible Towers in your cluster are always active and there is no distinction between them.
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.cpus = 1
end
# Tower/PgSQL machine
config.vm.define "tower" do |tower|
tower.vm.box = "centos/7"
end
# Ansible Tower configuration
config.vm.provision "ansible" do |ansible|
ansible.playbook = "playbook.yaml"
end
end
I basically create a 2Gb of RAM machine leveraging libvirt and run an Ansible Playbook on it.
The reason I created a 2Gb of RAM machine and I’ve not tried to shrink it further is because the Ansible Tower installation checks for 2Gb of RAM, and I wanted to create something easy.
I’m sure I could patch the installer to accept a 1Gb machine, but it’s not worth the effort to me. Also, in my usual usage of the computer I rarely go below 11Gb free memory, so I’m not too concerned in giving 2Gb to my VM.
Read More 
June 23, 2017 - London, UK
This year, I decided to go to AnsibleFest.
Since the day before AnsibleFest, an Ansible Contributor Conference was scheduled, I decided to partecipate to both.
On Wednesday morning I arrived to the location and I had the pleasure of speaking with few people before the begin of the Contributor Conference.
The Contributor Conference was very interesting and I had the occasion to speak with many other people over the course of the day.
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.
With Ansible Tower 3.1 this is no longer the case, since all Ansible Tower machines are active all the time.
Read More 
March 21, 2017
Sometimes I need to do some tests which are destructive and I need to perform them over and over until I figure out a process that reliably brings me to a desired state.
I usually create some kind of easy to provision environments and work on it.
In the last few weeks I found myself working on an etcd cluster, so I created an environment with Vagrant, and since I had to write the majority of this by myself, since I have not found anything on Google that suited my needs, I’m going to share this with you.
Read More 
March 1, 2017
I often receive questions about Ansible Inventories (far more often than any other Ansible component).
My guess is that Inventories are effectively among the most complex things in Ansible.
Ansible Inventories are complex in the following ways:
- After you have decided an Inventory model is hard to change it, in fact you would probably be required to touch all your Playbooks to make everything working again
- There is not a single way of doing Inventories
- Often Inventories are the glue to make a generic Playbook run properly on your specific architecture.
Grouping philosophies
The two main philosophies I saw in the many years I’ve worked with Ansible are:
Read More 
December 13, 2016
When I speak with people that are starting with Ansible from Puppet, the first thing they want to experiment is Ansible Galaxy.
This leaves me very sceptical, since I think the default mode in Ansible should be DIY.
Since I’ve found myself in this situation far to many times, I decided to write down all the reasons why you should avoid Ansible Galaxy in the majority of situations.
Using Ansible Galaxy often violates the Ansible way.
My interpretation of the Ansible Way, is do not do adopt overkill solution (also known as the classic “Keep It Simple Stupid” principle).
Many times the Ansible Roles you can find in Ansible Galaxy are completely overkill because are created by people coming from the Puppet world (that has a completely different approach).
Modules that install for you and configure NTP or Java for any possible distribution (and sometimes even different OS) means that you substitute a couple of Tasks with hundreds of lines of code.
Often the majority of the code can be stripped because is not applicable to the specific environment.
Read More
December 1, 2016
The single most frequent complain I hear about Ansible is about it’s slowness.
This is very common, but even more common among people that used to use Puppet.
There are many reasons why Ansible is slower than Puppet.
The three main reasons are:
- Linear execution: Ansible will execute each operation in order and will not run many steps at the same time as Puppet does.
- SSH Connection: all Ansible commands will be issued from the control system to the controlled system via SSH. On the other hand, in Puppet, all commands will be issued locally on the controlled host by the Puppet agent.
- Host limitation: since the Ansible Controller is involved with the process of applying changes to the controlled system, a limited number of systems can be changes at once.
Those limits come out from design decisions that preferred a simpler Playbook writing and a safer execution rather than speed.
There are some things that can be done to increase the performances of Ansible:
Read More 
Published on November 21, 2016
Authored by Fabio Alessandro Locati
Published by Packt Publishing Limited
Ansible is an open source automation platform that assists organizations with tasks such as configuration management, application deployment, orchestration, and task automation.
With Ansible, even complex tasks can be handled easier than before.
In this book, you will learn about the fundamentals and practical aspects of Ansible 2 by diving deeply into topics such as installation (Linux, BSD, and Windows Support), Playbooks, modules, various testing strategies, provisioning, deployment, and orchestration.
In this book, you will get accustomed with the new features of Ansible 2 such as cleaner architecture, task blocks, Playbook parsing, new execution strategy plugins, and modules.
You will also learn how to integrate Ansible with cloud platforms such as AWS.
The book ends with the enterprise versions of Ansible, Ansible Tower and Ansible Galaxy, where you will learn to interact Ansible with different OSes to speed up your work to previously unseen levels
Read More
Buy it on Packt
Buy it on Amazon 
October 30, 2016 - Milano, IT
From the 25th to the 27th of this month I’ve been at the SMAU in Milan (Italy).
The SMAU (Salone Macchine e Attrezzature per l’Ufficio, that would be Exposition of Machinery and Equipment for the Office) is an historical fair started in 1964 and that has had many changes over the years, for instance some years it has been opened to the general public, other times it was only for business visitors.
This year the event was targeted to business visitors.
Read More 
(Fabio Alessandro Locati|Fale)'s blog