Ansible is a multi-purpose automation tool and can configure everything from on-premises servers and networks to cloud infrastructure. Ansible has an active community and is easily extended if you have basic python knowledge. It is therefore a popular tool for organizations looking to automate infrastructure. You can run ansible-playbooks from the command line of management servers, but this does not scale well. As more and more people adopt ansible across your organization you might want to share playbooks and configurations in a centralized hub with proper access control. Ansible Automation Platform provides an enterprise framework for building and operating IT automation at scale.
Getting started
At first glance ansible automation platform might seem quite complex with a lot of features. It is not perfectly clear what you should do first. To keep things simple we will have a clear intention on what we want to achieve. Automation developers will write ansible playbooks and make their work available in Ansible Automation Platform. The playbooks are run later on by automation consumers who wish to perform the automated task.
An example may be infrastructure experts automating the provisioning and initial configuration of a Linux server. Infrastructure experts write automation to ensure the server is correctly configured and matches the standards of the organization. Once a developer needs a server for one of his projects he runs the playbook in Ansible Automation Platform and gets the server without having to consult the infrastructure experts.
How is this achieved?
Firstly automation developers must keep in mind that their automation will be run by other teams across the organization. Providing well documented automation that is simple to use is essential to enable teams to use automation they did not build themselves. While automation developers are experts within the domain they automate, they have to keep in mind that the users of their automation are likely not.
Secondly, enabling self-service requires strict access policies to ensure that only authorized users may perform a given action. In Ansible Automation Platform organizations, teams and roles provide the granularity you need to control who can run a playbook in a given project.
While having access to run playbooks is great, it is also important that playbook runs fit in with other tasks and processes. Ansible Automation Platform enables integration by providing a powerful and well documented REST API. Automation consumers can use this API to integrate playbooks in their pipelines.
Running your first playbook
For this demonstration I will use an AWX instance hosted in AWS by solvedevops. AWX comes with an interface similar to Ansible Automation Platform, but does not come with support from RedHat, access to RedHat certified automation content or Ansible Automation Hub. For production deployments RedHat recommends using Ansible Automation Hub over AWX.
In this example I will create two users, automation-consumer and automation-developer. As the automation-developer user I will create a simple playbook, and then I will run that playbook from the automation-consumer user. To follow along you must have admin access to an AWX or Ansible Automation Platform instance. We start off by logging into our automation platform as the admin user.
Creating users
First, we create an organization in AWX. We do that by navigating to Access/Organizations in the menu to the left. Add an organization by simply clicking “Add” and filling out the organization name. For this example I will call my organization Automation and leave all other fields untouched.
We then proceed to adding two users, automation-consumer and automation-developer in our newly created organization. Navigate to Access/Users and clicking “Add”. Fill in username and password. The user type should be “Normal User”. In the organization field, select our newly created Automation organization. Repeat the process for the automation-consumer user. In a production scenario you will want to join AWX with your identity provider. A range of identity providers are available under “Authentication” in the settings menu.
Configuring access control
The last thing we will do as the admin user is to configure roles for our newly created users. AWX supports fine-grained access control, but for our demonstration we will delegate roles on the organization level. We start by defining the role for automation-consumer. This user will need execute access in the Automation organization. Navigate to Access/users and click the automation-consumer user. Select “Roles” and you will see that the user has the “Member” role in the Automation organization. Click “Add” and select “Organizations”. Then you click next and select the Automation organization. Once more click next and select the “Execute” role and save. You should now see two roles for the automation-consumer user. Repeat the process for automation-developer, but select the Project Admin and Inventory admin roles. Sign out of the admin account and log back in as the ansible-developer user.
Building the automation
The first thing we do as the automation-developer user is to create a project. For this demonstration I have created a simple repository containing an example playbook and an inventory file. Navigate to Resources/Projects and add a new project. I will call my project Automationproject. For the organization field choose Automation and for Source Control Type select Git. Fill in “https://github.com/EirikOpheim/awx” in the URL field and save.
Creating an inventory
We now have to create an inventory. We will be using a traditional hosts file from the github repository. First navigate to Resources/inventories and create a new inventory named “hosts” in the Automation organization. In the variables field select yaml and add the line “ansible_connection: local” as seen below. This setting is relevant for our test case as we will run our playbook on localhost.
Once you have created the inventory select “Sources” and add a source, as seen in the screenshot below. Name your source “hosts”. For the “Source” field select “Sourced from a project”. In the “Source details” menu set the project field to Automationproject and inventory file field to hosts. At this point click the “Start sync process” button under “Actions” in the sources menu to sync hosts from the inventory file into AWX. Once the process finishes you can find “localhost” under Resources/Hosts in the AWX navigation menu.
Building a job template
We are now ready to build our first job template. Navigate to Resources/Templates and add a job template. I will call my template “Automationtemplate”. For the inventory field select hosts, and for job type choose Run. The project is Automationproject and the playbook is “hello.yaml” from the git repository. Leave all other options untouched and save your template. The template is now available to the automation-consumer user.
Running the playbook
Log into awx as the automation-consumer user. You will notice that your options are way more limited than they were for the admin and automation-consumer users. Navigate to Resources/Templates to find the automation created by automation-developer. Click the rocket icon under “Actions” to launch the job template. Wait for the playbook to complete. It should take only a couple of seconds. The playbook will simply print “Hello world!” using the ansible debug module. Congratulations, you have run your first playbook in AWX!
Conclusion
We have now discussed some of the benefits of Ansible Automation Platform for scaling automation across your organization. While Ansible Automation Platform has many capabilities, we have focused mainly on access control and enabling self-service consumption of automated tasks. We have seen an example where an automation developer publishes a job template that other members of his organization may trigger at will. This is a useful pattern to follow in organizations that want to reduce the amount of tickets sent between teams.
In our demonstration we have configured Ansible Automation platform through the Graphical User Interface, and triggered templates from the GUI. In my next post I will configure AWX with an Infrastructure as Code approach, where all configuration is done with ansible and github actions. I find this approach to be superior to manual configuration as changes are stored in a version control system and can be easily tracked and reverted. Until next time!