One of the goals of Red Hat Services is to bring a standardized and collaboratively created toolkit and approach to customers to speed up and improve automation practices. Red Hat’s Automation Community of Practice--a part of Red Hat Services--has created a new collection that acts as a wrapper for the ansible.tower collection, creating a powerful toolkit to help speed up the automation of an Ansible Tower environment. This post will provide an overview of what’s in the collection and show you how to install and use the tower_configuration.
Why a wrapper collection was needed
With the most recent releases of Ansible and its transition to using collections last year, a whole wave of community collections have been developed to expand the Ansible ecosystem. One such collection is the “ansible.tower” (based on the upstream “awx.awx”) collection, which creates replacements for the outdated Ansible Tower web modules.
The common use case of automating the configuration of Ansible Tower had previously led to us creating a vast array of similar solutions to enable the transition from configuration as code into actual Ansible Tower objects. The convergence of a single, standardised solution has led to the creation of the “tower_configuration” collection, which provides a set of easy-to-use roles for the single purpose for configuring Ansible Tower objects.
Although the Ansible Tower collection provides a comprehensive set of plugins and modules, there is no overall build configuration approach using roles and playbooks. At present, there is also a lack of a standardized model to drive such automation. Let’s see how Red Hat Services is helping with a standardized model.
What is inside the collection?
The collection contains wrapper roles for each of the Ansible Tower collection modules and in turn, many of the API endpoints for Ansible Tower. We have also put together a standardized data model to be able to use predictable variables to define Tower objects (such as
tower_inventories, etc.) along with detailed example playbooks which provide a demo configuration for Ansible Tower. Finally, the collection makes heavy use of CI practices using code reviews, automated linting (ansible-lint and yaml-lint), and automated integration tests upon new contributions and releases.
First things first, we need to install the collection before we can make use of it. To do that, use the following command.
$ ansible-galaxy collection install redhat_cop.tower_configuration
$ ansible-galaxy collection install ansible.tower
In the below example, two organizations will be created: Satellite and Default, as well as a
Demo Project inside of the Default Organization created from the tower-examples git repository. The following playbook defines all of this.
$ vim tower_config.yml --- - name: Playbook to configure ansible tower organizations hosts: localhost collections: - redhat_cop.tower_configuration - ansible.tower vars: tower_hostname: https://tower.example.com tower_username: admin tower_password: password tower_organizations: - name: Satellite - name: Default tower_projects: - name: Demo project organization: Default scm_branch: master scm_type: git scm_update_on_launch: true scm_url: https://github.com/ansible/tower-example.git roles: - organization - projects
Now we can run the ansible-playbook command to create.
$ ansible-playbook tower_config.yml
Where to go next?
The previous example gives a short introduction for creating a Tower configuration. But we can’t do much with just an Organization and a Project. Next, we want to create objects such as job templates, credentials, inventories, and many more. Fortunately, these can be created in much the same way.
For the full details of what options you can apply to each Tower object type, visit the git repository, which contains detailed examples on how to shape your Tower configuration playbook.
We also invite you to learn more about how Red Hat Services can help with furthering your automation journey.