On tuesday the 19th of March we attended a Red Hat workshop that gave us an introduction to Ansible Tower. At the time we were all working with or had worked with Ansible and we were curious to find out what Ansible Tower had to offer. Most of all, we were eager to learn how we could implement this as a team in Devoteam.
Ansible for everyone
First we would like to introduce you to the building blocks of Ansible Tower. It is a web-based solution that makes Ansible easier to use for all sorts of IT teams. It has a very straightforward interface, so new users will find their way quickly. Ansible Tower includes real-time output of playbook runs, an all-new dashboard and expanded out-of-the-box cloud support.
Here is a list of the most important features that Ansible Tower has to offer:
Role-based access control
You can set up teams and users in various roles. These can integrate with your existing LDAP or AD environment.
Job scheduling
You can schedule different kinds of jobs in Ansible Tower. For example: run the playbook or update the cloud inventory.
Fully documented REST API
Allows you to integrate Asible into your existing toolset and environment Tower Dashboard: use this to quickly view a summary of your entire environment. Simplifies things for sysadmins while sipping their coffee.
Cloud integration
Ansible Tower is compatible with major cloud environments: Amazon EC2, Rackspace, Azure.
Dashboard
In Ansible Tower you can also monitor who ran the tasks and the exact moment it was executed:
How to use Ansible Tower?
If you already know how to use Ansible, provisioning an environment with Ansible Tower is very easy. As you may already know, the basic components of Ansible are inventories, modules, variables, facts, plays, playbooks and configuration files (if you don’t know the function of each component, please check the end of the blog). It is the same in Ansible Tower. Below an example workflow for deploying an environment in Ansible Tower.
First of all, you can put your repository, containing all the components, in a cloud SCM. Then you can manage users and their access rights. For example, which user has what access rights to which particular repositories. After that, you can run templates which do the real jobs for you, such as spinning up a server in the cloud or on premise. Now that you have new servers, you need to manage machine credentials for logging into the server and run Ansible playbooks in the newly provisioned machines. Except for managing machine credentials, you can also create inventories for these machines or simply add sources to existing inventories.
When all is set, you can go ahead and play with job Templates to deploy your desired stack. Simply log in as the right user, go to Templates and add “Job Template”. Specify the name of the job template, the inventory file, the playbook, and the correct credential(s).
Building on the top of the job Template, you can finally create workflow templates.
“A workflow is a set of job templates (and thus playbooks) that are linked together in a certain specific way such that multiple job templates are executed in a predictable order. Each job template in a workflow is called a node.”
Execute the workflow template in Ansible Tower
The last step, as you can probably guess, is to execute the workflow template. The workflow might look like this:
In conclusion, Ansible Tower serves as a great add-on to Ansible, with almost all of the capabilities of normal command line. It will take a complementary role in automation and visualization of the normal Ansible process. On top of that it makes the otherwise somewhat intimidating workflow of Ansible a bit more accessible. But if you want to be more creative with your playbooks, Ansible’s CLI is still a better option.
Basic Terms you might encounter
Inventories
Ansible works against multiple systems in your infrastructure at the same time. It does this by selecting portions of the systems listed in Ansible’s inventory, which defaults to being saved in the location /etc/ansible/hosts.
Modules
Ansible ships with a number of modules (called the ‘module library’) that can be executed directly on remote hosts or through Playbooks. Modules are essentially tools for particular tasks
Modules can take parameters.
Variables
Can be scoped by a group, host, or even in a playbook. Typically used for configuration values and various parameters.
Facts
Facts provide certain information about a given target host. Facts are discovered by Ansible automatically, when it reaches out to a host. Facts may be cached between playbook executions, but this is not default behavior.
Plays and Playbooks
The goal of the play is to map a group of hosts to some well-defined roles. A play may use one or more modules to achieve desired and state on a group of hosts. A playbook is a series of plays.
Join our open & innovative culture
Open, accessible and ambitious are the keywords of our organizational culture. We encourage making mistakes, we strive to do better every day and love to have fun. Doing work you love with brilliant people is what it’s all about.
