Ansible
A common problem with building multiple servers in the cloud is an intermittent failure in one build that can stop your entire deployment process. With the right retry logic you can avoid this problem with Ansible.
View the Ansible playbook gist on GitHub
I’m using until to check the output from the rax module. Using the length Jinja2 filter, I can check if the correct number of instances have been created. This should retry the task 3 times with a delay of 5 seconds between attempts.
There are many variations and combinations of AWS products and services that lend the platform to great flexibility and customization. We work hard to evaluate these combinations and put forth a collection of best practices for our customers to follow. One of these best practices is the use of CloudFormation templates. My team maintains a series of standard CloudFormation templates for our customers to use. Part of that maintenance includes updating those templates and testing them for functionality.
Today I was a guest on Rackspace Cloud Office Hours talking about my recent Ansible Certified Engineer certification. There is a great article on the Rackspace Blog with a Recap.
Here is the recording of the Hangout:
Deploying Ansible Tower isn’t hard, but automating a server build and triggering the installation lowers the barrier of entry for trying out Tower. This article will describe the HEAT Template I’ve created to automate this process.
Anatomy of a HEAT Template
Templates are broken into several main sections. I’m going to describe each one of them so you fully understand the process. Follow along here: Ansible Tower HEAT Template
Description and Version
It is important that the Version information you specify matches the HEAT version in use. The description should describe the overall goal of the template.