Automating the automation — Ansible Tower configuration as code

Ansible Tower is a powerful system for managing and running Ansible tasks. But the process of configuring projects, jobs, and inventories can often be an arduous and manual process. Using some simple tools, we can automate the automation and begin to embrace GitOps fully.

What is GitOps?

GitOps, in the simplest terms, is when the entire configuration of an estate is stored as code in git repositories. One of the tools often used to achieve a GitOps state is Ansible. This is the tool that I recommend using to configure Ansible Tower.

Getting Started

I have written an Ansible role which can be found here on Ansible Galaxy. This role will form the basis for the automation of configuration, and additional tools can be built up around it to get to the ‘Nirvana’ state of full automation, more about that later.

The first stage of automating some content into Tower would be to write a playbook which utilises the role. I have written an example of this on GitHub. Along with the playbook, we need to create a vars file which will define what gets automated into Tower. The example below shows creating a redhat organisation along with a project and a job template. It assumes credentials and inventories already exist, though for details on how to automate this you can refer to my repository on GitHub.

tower_objects:

 organisations:

   - name: redhat

     description: The main Red Hat organisation

     projects:

       - name: ansible-app-tower

         description: "Project for deploying Tower"

         scm_url: "https://github.com/Tompage1994/ansible-app-tower.git"

         scm_type: git

         scm_update_on_launch: "yes"

     job_templates:

       - name: "Sample Playbook"

         job_type: run

         playbook: "playbooks/sample_playbook.yml"

         project: "ansible-app-tower"

         inventory: "example"

         credential: "server-key"

Below, you can see the output of running the playbook into Tower.

By providing an inventory to the playbook and running seed_tower.yml, you should find that you can quickly automate most Tower artifacts. The full list of what can be automated is below:

• Virtual Environments
• Credentials
• Credential Types
• Groups and Hosts
• Inventories
• Inventory Sources
• Job Templates
• Organisations
• Projects
• Teams (and managing RBAC for the team per job template)
• Workflows

When automating the configuration of Ansible Tower, the role will also manage the installation of Tower, apply an Ansible Tower license, and configure LDAP. See the Readme for more details.

Next Steps

The next step towards scaling up this process across an entire estate is to begin automating all of your Ansible projects into Tower using a specific pattern. The pattern which we have used and felt most comfortable with is to specify a variable file in each repository, which contains Ansible code where we may want to put it into Tower. The method we have used is to create a .tower directory that contains a tower_vars.yml file along with any necessary supporting files.

The tower_vars.yml file is in a predictable location. This will become important later when we create full automation

At this point, we can run our seed_tower.yml playbook (or a close approximation) to seed Tower with the configuration defined in each repository individually.

Nirvana

It’s reasonably clear where the next step would come: add additional automation to tie all of this together. This could come in the form of a Jenkins pipeline, which would wait for a git hook that can be set up on every repository to start the job. The job would run the automation playbook and include the tower_vars.yml file from the well-defined location.

Using this method, we will have achieved continuous integration as we can automate directly into Tower. Commonly, an organisation would have multiple instances of Ansible Tower in different environments. In a simple scenario, we may use this method to directly and instantly deploy the Tower config into a development/testing environment to verify what has been delivered. This can help in a QA cycle for testing playbooks as a whole. This could be further developed to include automated testing using tools such as Molecule to lint, test, and verify playbooks and roles before they are even moved into Tower.

With a little additional work, continuous delivery could be achieved by running integration tests against Tower, verifying the configuration which has been entered against the test environment. A mature organisation may even write tests that could, for example, run jobs, check inventories, and test credentials. Using this to provide confidence, it would then be possible to promote configuration into production using the same method and, in doing so, bring us closer to the ‘Nirvana’ state.

Connect with Red Hat Services
Learn more about Red Hat Consulting
Learn more about Red Hat Training
Join the Red Hat Learning Community
Learn more about Red Hat Certification
Subscribe to the Training Newsletter
Follow Red Hat Services on Twitter
Follow Red Hat Open Innovation Labs on Twitter
Like Red Hat Services on Facebook
Watch Red Hat Training videos on YouTube
Understand the value of Red Hat Certified Professionals