Launching our First Ansible Job Template on a VM in CloudForms

This is part 3 of our series on Ansible Tower Integration in Red Hat CloudForms.

In this article, we will explore how to use the Ansible Tower integration in CloudForms by configuring the launch of an Ansible Template Job on a click of a button from a VM.

In this example, we use an Ansible Job Template created based on a role found on the Ansible Galaxy role library. In particular, we installed on our Ansible Tower the sfromm.postgresql role dedicated to managing PostgreSQL. Our associated Ansible Playbook is available on GitHub.

As seen in our previous article, an inventory of all Job Templates is available in CloudForms under ‘Configuration > Configuration Management > Ansible Tower Job Templates’. For each of them, CloudForms provides the ability to auto-generate a Service Dialog which can be used to prompt users to validate or provide Job Template inputs. The dialog  generation can be triggered by invoking ‘Configuration > Create Service Dialog from this Job Template’ on a Job Template and filling the service dialog name field.

 

image07

 

image35

 

Once saved, the generated service dialog can be found under ‘Automate > Customization > Service Dialogs > All Dialogs > PostgreSQL Deployment Dialog’.

 

image27
This dialog contains all of the fields required to launch the Job Template. The first element on the dialog is a ‘Limit’ field. This is used in Ansible Tower to filter the hosts and specify on which particular host the job must run. CloudForms populates this field automatically with the VM name when used on a VM button. The other elements correspond to the extra variables required by our Job Template, as previously seen from the Ansible Tower Job Templates inventory.

At this point, we can edit the dialog and modify the elements. One of the common task is to uncheck the ‘read only’ option on the elements and/or add additional logic behind others (e.g. Dynamic Dropdown Lists, etc). For example, we rename the labels to make them more user friendly, and we remove the ‘Limit’ element which will be populated behind the scene by CloudForms.

On the Ansible Tower side, all you need is to configure an inventory corresponding to your CloudForms infrastructure or cloud providers.

If used following a CloudForms VM provisioning, you must trigger an update of the Ansible Tower inventory prior to launching a Job Template. In order to perform this update, simply enable the option ‘Update on Launch’ on the required inventory group source in Ansible Tower.

 

image12
This is required to ensure the new host is present in the Ansible Tower inventory before trying to launch a Job Template on it.

CloudForms populates the limit parameter on the Job Template in order to target on which host the template should be executed. Additional extra parameters can also be set in CloudForms using a Service Dialog or programmatically (an example is provided under
Datastore / ManageIQ / ConfigurationManagement / AnsibleTower / Operations / StateMachines / Job / launch_ansible_job).

Service Dialogs are automatically generated from CloudForms by clicking on the ‘Create Service Dialog from this Job Template’ button presented for each Job Template.

 

image07
The resulting Service Dialog contains all elements required as input in the Ansible Job Template. This includes the limit as well as all extra parameters in separate elements. It is of course possible to edit the generated Service Dialog to amend or modify any of the fields.

In our case, we simply want to deploy PostgreSQL and a database keeping the default values entered within the Job Templates parameters. We will keep the dialog as generated.

The next step is to create a new button on VMs for our Job Template. Navigate to ‘Automate > Buttons’ and expand the ‘VM and Instance’ object type. Add a new Button Group if required and create a new button by selecting ‘Configuration > Add a new Button’.

Under dialog, make sure you select the previously generated dialog (‘PostgreSQL Deployment Dialog’ in our case). System/Progress is set to ‘Request’, Message to ‘create’ and Request to ‘Ansible_Tower_Job’. The Job Template name is specified as an attribute/value pair under ‘job_template_name’ (in this case, set to the corresponding Ansible Job Template name ‘PostgreSQL Deployment’). Additional values such as dialog_param_postgresql_databases or dialog_param_postgresql_users can be specified to override our default values on the Job Template if required.

 

image19
Save the Button and voila. We have a new Button for our VM allowing us to run our Ansible Job Template to deploy PostgreSQL on the VM using Ansible Tower.

 

image41
These steps can be followed to add additional buttons on the VMs with associated Job Templates.

In this article, we looked at how to configure the launch of an Ansible Template Job on a click of a button from a VM. In the next article, we will explore how to use Ansible Job Templates as Service Items and publish them in the Service Catalog.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s