Skip to main content

6 Ways Ansible Tower Makes Life Easier for Systems Admins

Learn how this tool can simplify AIX and Linux administration.

line illustration of a cityscape with blue tones.

The Red Hat® Ansible® Tower dashboard provides a web-based interface for everything going on in your Ansible environment.  Ansible® Tower allows your organization to centralize and manage all your IT infrastructure including Power Systems, Unix/Linux and Window with a web-based dashboard, role-based access control (RBAC) for access to the dashboard, secured credentials, job scheduling, integrated notifications and graphical inventory management. You can also easily embed Ansible Tower into existing tools and processes with its REST API and CLI. In this article, we discuss six ways which Ansible Tower can enhance your day-to-day administration of your Power systems and IT resources.
 

1. Managing AIX Patching 

With Ansible you typically automate your IBM Power Systems™patching and configuration settings using Playbooks, which are executed via command line with specific parameters, credentials and hosts list. With Ansible Tower, a Playbook is run from a job template, which specifies all the parameters, credentials and hosts environment details of how to run the Playbook. There is no concern that the user will mistype an option or parameter to Ansible, potentially deploying to the wrong environment or with the wrong arguments since the template is triggered via the push of a button (or via the API.)
You can easily configure your patching and configuration playbooks in a Job template within Tower and store all parameters you would normally pass to the ansible playbook on the command line. Easier deployments drive consistency, by running your playbooks the same way each time, and also allow you to delegate responsibilities even to users who aren’t Ansible experts. Combining jobs with Tower's basic job scheduling features allows you to consistently maintain your Power Systems environment. For example, you may have a maintenance window when you apply changes. You only apply updates during your update window at 5 am on Sundays. For any job in Tower, it is easy to configure a schedule. Now this job will apply updates automatically on a schedule you define. You can pause or stop the schedule too.
 

2. Using Tower UI to Identify Systems out of Compliance

There are three methods you can use to manage compliance. In the Ansible UI, all job runs are recorded. After the patching/configuration job is run, you can view the status of this job in the Tower's UI. In this view, you can see the individual tasks. Any of these that applied a change will be noted as ‘changed’ in yellow. If no change was made, then it will be noted “ok” in green. If you click on the tasks, you can see the individual hosts on which changes were made and clicking on the host where there are changes (noted in yellow), you can see the individual event and what was changed.
You can also use Tower's REST API to get this information as well, in even more detail. Using REST API is simple. First, we'll need to know the job template we're using for our remediation. In this example, the configuration job is job template 457 in the Tower instance. You can then query Tower's API to get the last successful configuration run.
  
You can also query the API for all tasks that have 'changed' and filter by the 'runner_on_ok' event that denotes the task. Finally, Tower supports multiple ways of alerting and notifications via email, slack, etc. each time a job is run. Notifications can even be configured to make an HTTP POST request to a URL of your choice using a webhook.
 

3. Automatically Patch/Configure New Virtual Server Created on PowerVC using Ansible Tower Call-Back Feature

How can you ensure that your patches and/or configuration settings are applied automatically whenever someone provisions a new machine on your PowerVC? You can automate this with Tower's provisioning callbacks. Provisioning callbacks are a mechanism where any Jobs in Tower can be triggered by a remote managed host. This ensures that each newly provisioned instance will have the latest patches and configuration settings prior to going live.

To set up a provisioning callback, first you will enable them in the job template in Tower for your specific provisioning job. Callbacks also require a Host Key, to ensure that foreign hosts with the URL cannot request configuration. You can easily create a unique host key in the Tower UI. Host keys can be used to manage callback for many hosts.

Frequently the callback should be accessed via a “first boot” type script, or from cronjob on the new host. Callback can also be initiated manually via REST API. Here is an example using curl to initiate a callback job from a managed node (all on a single line):
curl -k -f -i -H 'Content-Type:application/json' -XPOST -d '{"host_config_key": "cfbaae23-81c0-47f8-9a40-44493b82f06a"}' \
 https://<TOWER_SERVER_NAME>/api/v2/job_templates/<job number>/callback/
 
The requesting host must be defined in your Tower inventory for the callback to succeed. Most likely you will need to use callbacks with dynamic inventory in Tower for PowerVC which uses the Tower supported Openstack cloud dynamic inventory feature.
 
While the callback can be accessed via REST as show above, the preferred method of using the callback is to use one of the example scripts that ships with Tower and include it in your init scripts: 
 
/usr/share/awx/request_tower_configuration.sh (Linux/UNIX)
 
In this case, the callbacks are enabled in a base image. To do so, running at the “first boot” is best practice. “First boot” scripts are just simple init scripts that typically self-delete, so you would set up an init script that calls a copy of the request_tower_configuration.sh script to start the callback.
 

4. Tower Allows Novice Ansible Users to Deploy Complex Playbooks

 
Users do not require any knowledge of Ansible or the Playbook.  When combined with the role-based access control capabilities of Ansible Tower, Playbooks can be deployed at the push of a button, but in a controlled and easily auditable way. This allows an organization to spread the power of Ansible to any of its users. Even users unfamiliar with Ansible can run Playbooks that others have written. These features are commonly used to enable self-service provisioning of development environments by the developers themselves. 
Role-based access control (RBAC) allows you to limit access to Jobs and other resources for each user. Then when a user logs into Tower UI, the user will only see resources they are allowed to use in the Tower UI. Additionally, Tower encrypts all credentials, so you do not have to expose any passwords to these users.
You can also prompt users for information prior to running the job. Ansible Tower’s Surveys feature allows you to set extra variables for the playbook similar to ‘Prompt for Extra Variables’, but in a user-friendly question and answer way. Surveys also validates the user input. Use cases for surveys are numerous. Many types of questions can be asked, including multiple-choice questions.
 

5. Create Continuous Remediation to Manage Configuration Drift

Of course, applying a configuration only at machine boot is not sufficient in many cases. Changes can come later, whether via operating system updates, application changes, or even sysadmins logging in locally and making changes. This is a phenomenon known as configuration drift.
Hence, the idea of continuous remediation, i.e., applying your configuration on a regular basis to ensure you don't have configuration drift.  Ansible makes continuous remediation efficient.  Tower's job scheduling makes it easy. You can schedule this remediation to run as often as is convenient. Ansible's basic feature is that it only makes a change if it has to; else the task is reported as OK. This is often referred to as desired state configuration or idempotency. Combine this with Tower's auditing and logging of all Ansible runs, and this makes finding these cases of configuration drift simple.
Another of Tower's basic features is the ability to schedule jobs. For example, you may have a maintenance window when you apply changes. You only apply updates during your update window at 5 a.m. on Sundays. For any job in Tower, it is easy to configure a schedule. When editing a job template, you can add them under the Schedules. You can also just go to the list of job templates, click the schedule icon, and then add a new schedule.
Now this job will apply updates automatically on a schedule and can be paused or stopped if needed.

6. Creating CI/CD Pipeline Using Ansible Tower Workflow

In addition to running playbook templates individually, ansible Tower Workflows allow you to easily model complex processes with Ansible Tower's GUI workflow editor. Ansible Tower workflows chain any number of Jobs, updates, and other workflows, regardless of whether they use different inventories, run as different users, run at once or utilize different credentials. Essentially, Workflows provide a CI/CD pipeline for your projects.
For example, you can build a provisioning workflow that provisions machine (in the cloud or containers), applies a base system configuration, and deploys an application, all with different playbooks maintained by different teams. You can build a CI/CD testing workflow that builds an application, deploys it to a test environment, runs tests, and automatically promotes the application based on test results. Workflows also allows you to create branches to set up different playbooks to run in case of success or failure of a prior workflow playbook. 

Tower is now part of IBM Cloud Pak for Multicloud Management, a key part of Power Systems hybrid cloud strategy. In IBM Systems Lab Services, we stand ready to partner with you to help you overcome the practical challenges of embracing Ansible Automation and Ansible Tower and show the resulting business value. Contact us today.
 
 
IBM Systems Webinar Icon

View upcoming and on-demand (IBM Z, IBM i, AIX, Power Systems) webinars.
Register now →