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.
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.
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.
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.
Lately I have been programming quite a bit and - for the first time - I have used Golang doing so. Go is a very nice language and really helped me with the development. One of the reasons why I have enjoyed this much Go is the standard library, which is amazing. I would like to share today the easiness of creating a basic Certificate Authority and signed certificates in Go.
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.
After many years of using Hetzner as a server provider, and having rented from them multiple servers for many reasons, I decided to rent a server with 128Gb of RAM to do some tests with many (virtualized) machines on top of CentOS.
As it often happens, hosting providers put in place a lot of security measurements that sometimes make doing simple stuff more complex. The first approach I tried was using the (only) Ethernet interface as a bridged interface, but that did not brought me very far.
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.
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.
FOSDEM is a must for all open source enthusiast in Europe and close by. I think that the reasons to go to FOSDEM are different from the reasons of many other conferences, but equally valid. The comparison with DevConf is obvious, due to the temporal closeness of the two events.
I think that DevConf is more about enterprise grade software (or close to be), while FOSDEM is more about experimentations and community.