Chapter 3. Automation Management Providers

In Red Hat CloudForms, an automation management provider is a management tool that integrates with CloudForms to simplify automation operations for your resources. This chapter describes the automation management providers that you can use with Red Hat CloudForms, and how to work with them.

Red Hat CloudForms provides automation management features through the following:

Automate enables real-time, bi-directional process integration. This provides you with a method to implement adaptive automation for management events and administrative or operational activities.

Ansible integration delivers out-of-the-box support for backing service, alert and policy actions using Ansible playbooks. Sync your existing playbook repositories with CloudForms, add credentials to access providers, and create service catalog items for actions ranging from creating and retiring VMs, updating security software, or adding additional disks when space runs low.

Ansible Tower is a management tool integrated with CloudForms, designed to help automate infrastructure operations utilizing existing Ansible Tower providers in your inventory. CloudForms allows you to execute Ansible Tower jobs using service catalogs and Automate. Using Ansible Tower, you can schedule Ansible playbook runs and monitor current and historical results, allowing for troubleshooting or identification of issues before they occur.

3.1. Ansible

Ansible integrates with Red Hat CloudForms to provide automation solutions, using playbooks, for Service, Policy and Alert actions. Ansible playbooks consist of series of plays or tasks that define automation across a set of hosts, known as the inventory.

Ranging from simple to complex tasks, Ansible playbooks can support cloud management:

  • Services - allow a playbook to back a CloudForms service catalog item.
  • Control Actions - CloudForms policies can execute playbooks as actions based on events from providers.
  • Control Alerts - set a playbook to launch prompted by a CloudForms alert.

Ansible is built into CloudForms so there is nothing to install. The basic workflow when using Ansible in Red Hat CloudForms is as follows:

  1. Enable the Embedded Ansible server role.
  2. Add a source control repository that contains your playbooks.
  3. Establish credentials with your inventory.
  4. Back your services, alerts and policies using available playbooks.

3.1.1. Enabling the Embedded Ansible Server Role

In Red Hat CloudForms, the Embedded Ansible role is disabled by default. Enable this server role to utilize Ansible Automation Inside.

Note

Configure your CloudForms appliance network identity (hostname/IP address) before enabling the Embedded Ansible server role. Restart the evmserverd service on the appliance with the enabled Embedded Ansible server role after making any changes to the hostname or IP address.

  1. Navigate to the settings menu, then ConfigurationSettings.
  2. Select the desired server under Zones.
  3. Set the Server Role for Embedded Ansible to On.

3.1.2. Verifying the Embedded Ansible Worker State

Verify that the Embedded Ansible worker has started to utilize its features.

  1. Navigate to the settings menu, then ConfigurationDiagnostics and click on the desired server.
  2. Click on the Workers tab.

A table of all workers and current status will appear from which you can confirm the state of your embedded Ansible worker.

3.1.3. Adding a Playbook Repository

Add a repository so that Red Hat CloudForms can discover and make available your playbooks.

  1. Navigate to AutomationAnsibleRepositories.
  2. Click Add.
  3. Provide a Repository Name in the Name field.
  4. Add a description for the repository in the Description field.
  5. Select an SCM Type from the drop-down menu.
  6. Add a URL or IP Address for the repository.
  7. Select the appropriate SCM Credentials from the drop-down menu.
  8. Provide a branch name in the SCM Branch field.
  9. Check the appropriate box for any SCM Update Options.
  10. Click Add.

Once you have synced a repository, its playbooks will become available to CloudForms.

3.1.4. Refreshing Repositories

Red Hat CloudForms allows you to refresh a targeted playbook repository or all repositories in your inventory to ensure your playbooks are current.

Refresh a targeted repository:

  1. Navigate to AutomationAnsibleRepositories.
  2. Click on a repository.
  3. Click Configuration (Configuration), then Refresh this Repository (Refresh this Repository).

Alternately, you can refresh some or all repositories from the list view:

  1. Navigate to AutomationAnsibleRepositories.
  2. Check those repositories to refresh. Click Check All to select all repositories.
  3. Click Configuration (Configuration), then Refresh Selected Ansible Repositories (Refresh Selected Ansible Repositories).

3.1.5. Credentials

Credentials are utilized by Red Hat CloudForms for authentication when running Ansible playbooks against machines, synchronizing with inventory sources, and importing project content from a version control system.

3.1.5.1. Adding Credentials

Red Hat CloudForms can store credentials used by playbooks. Credentials saved in CloudForms are matched and executed with a playbook when run.

  1. Navigate to AutomationAnsibleCredentials.
  2. Click Configuration (Configuration), then Add a New Credential (Add a New Credential).
  3. Provide a Name for the credential.
  4. Select the Credential Type. Additional fields will appear depending on the type chosen.
  5. Click Add.

3.1.5.2. Credential Types

Each credential type used by CloudForms is detailed in the following sections.

3.1.5.2.1. Machine

Machine credentials enable CloudForms to invoke Ansible on hosts under your management. Just like using Ansible on the command line, you can specify the SSH username, optionally provide a password, an SSH key, or a key password. They define SSH and user-level privilege escalation access for playbooks, and are used when running playbooks on a remote host.

  • Username: The username to be used for SSH authentication.
  • Password: The actual password to be used for SSH authentication.
  • SSH Private Key: Copy or drag-and-drop the SSH private key for the machine credential.
  • Private Key Passphrase: If the SSH Private Key used is protected by a password, you can configure a Key Password for the private key.
  • Privilege Escalation: Specifies the type of escalation privilege to assign to specific users. Options include sudo, su, pbrun, pfexec.
  • Privilege Escalation Username: Enter the username to use with escalation privileges on the remote system.
  • Privilege Escalation Password: Enter the actual password to be used to authenticate the user via the selected privilege escalation type on the remote system.
  • Vault Password: Ansible Vault credentials have only the Vault Password attribute that may be configured.
Note

For more information on Ansible Vault, see Using Vault in playbooks.

3.1.5.2.2. Network

Network credentials are used by Ansible networking modules to connect to and manage networking devices.

Network credentials have several attributes that may be configured:

  • Username: The username to use in conjunction with the network device.
  • Password: The password to use in conjunction with the network device.
  • Authorize: Select this from the Options field to add an Authorize password which signs the RSA key with a password.
  • Authorize password: If Authorize is checked, enter a password in the Authorize Password field.
  • SSH Key: Copy or drag-and-drop the actual SSH Private Key to be used to authenticate the user to the network via SSH.
  • Private key passphrase: The actual passphrase for the private key to be used to authenticate the user to the network via SSH.
3.1.5.2.3. SCM

SCM (source control) credentials are used with Projects to clone and update local source code repositories from a remote revision control system such as Git, Subversion, or Mercurial.

Source Control credentials have several attributes that may be configured:

  • Username: The username to use in conjunction with the source control system.
  • Password: The password to use in conjunction with the source control system.
  • Private key passphrase: If the SSH private key used is protected by a passphrase, you may configure a key passphrase for the private key.
  • Private Key: Copy or drag-and-drop the actual SSH Private Key to be used to authenticate the user to the source control system via SSH.
3.1.5.2.4. Amazon

Selecting this credential type enables synchronization of cloud inventory with Amazon Web Services.

  • Access Key: User credentials that allow for programmatic calls to Amazon Web Services.
  • Secret Key: The secret key that corresponds to the user access key.
  • STS Token: Token generated by Amazon Web Services Security Token Service.
3.1.5.2.5. Azure Classic (deprecated)

Selecting this credential type enables synchronization of cloud inventory with Microsoft Windows Azure Classic.

Microsoft Azure credentials have several attributes to configure:

  • Subscription ID: The Subscription UUID for the Microsoft Azure Classic account.
  • Management Certificate: The PEM file that corresponds to the certificate you uploaded in the Microsoft Azure Classic console.
3.1.5.2.6. Azure

Selecting this credential type enables synchronization of cloud inventory with Microsoft Azure.

Microsoft Azure credentials have several attributes to configure:

  • Username: The username to use to connect to the Microsoft Azure account.
  • Password: The password to use to connect to the Microsoft Azure account.
  • Subscription ID: The Subscription UUID for the Microsoft Azure account.
  • Tenant ID: The Tenant ID for the Microsoft Azure account.
  • Client Secret: The Client Secret for the Microsoft Azure account.
  • Client ID: The Client ID for the Microsoft Azure account.
3.1.5.2.7. Google Compute Engine

Selecting this credential type enables synchronization of cloud inventory with Google Compute Engine.

Google Compute Engine credentials have several attributes that may be configured:

  • Service Account Email Address: The email address assigned to the Google Compute Engine service account.
  • RSA Private Key: The PEM file associated with the service account email.
  • Project: The GCE assigned identification. It is constructed as two words followed by a three digit number, such as: squeamish-ossifrage-123.
3.1.5.2.8. OpenStack

Selecting this credential type enables synchronization of cloud inventory with Red Hat OpenStack Platform.

OpenStack credentials have several attributes that may be configured:

  • Username: The username to use to connect to OpenStack.
  • Password (API Key): The password or API key to use to connect to OpenStack.
  • Host (Authentication URL): The host to be used for authentication.
  • Project (Tenant Name): The Tenant name or Tenant ID used for OpenStack. This value is usually the same as the username.
  • Domain name: The FQDN to be used to connect to OpenStack.
3.1.5.2.9. Rackspace

Selecting this credential type enables synchronization of cloud inventory with Rackspace.

Rackspace credentials have the following attributes that may be configured:

  • Username: The username to use to connect to vCenter.
  • API Key: The public key related to the administrator ID.
3.1.5.2.10. Red Hat Virtualization

Selecting this credential type enables synchronization of cloud inventory with Red Hat Virtualization.

Red Hat Virtualization credentials have several attributes that may be configured:

  • Username: The username to use to connect to Red Hat Virtualization.
  • Password: The password to use to connect to Red Hat Virtualization.
  • Host (Authentication URL): The host to be used for authentication.

    Important
3.1.5.2.11. Satellite 6

Selecting this credential type enables synchronization of cloud inventory with Red Hat Satellite 6.

Satellite credentials have several attributes that may be configured:

  • Username: The username to use to connect to Satellite 6.
  • Password: The password to use to connect to Satellite 6.
  • Satellite 6 Host: The Satellite 6 URL or IP address to connect to.
3.1.5.2.12. VMware

Selecting this credential type enables synchronization of inventory with VMware vCenter.

Important

If both CloudForms and a VMware provider are located in the same IPv6-only network, use a DNS-resolvable hostname for the VMware provider in the vCenter Host field when adding credentials.

VMware credentials have several attributes that may be configured:

  • Username: The username to use to connect to vCenter.
  • Password: The password to use to connect to vCenter.
  • vCenter Host: The vCenter hostname or IP address to connect to.
Note

If the VMware guest tools are not running on the instance, VMware inventory sync may not return an IP address for that instance.

3.1.6. Tagging Ansible Playbooks, Repositories, and Credentials

Apply tags to Ansible playbooks, repositories, and credentials to categorize them. Tagging enables administrators to limit users to view those Ansible elements that have been enabled for that set of user permissions.

3.1.6.1. Adding Tags to Ansible Playbooks

  1. Navigate to AutomateAnsiblePlaybooks.
  2. Select the checkboxes for the Ansible playbooks to tag.
  3. Click Policy (Policy), and then Edit Tags (Edit Tags).
  4. Select a customer tag to assign from the first list.

    2219

  5. Select a value to assign from the second list.
  6. Click Save.

3.1.6.2. Adding Tags to Ansible Repositories

  1. Navigate to AutomateAnsibleRepositories.
  2. Select the checkboxes for the Ansible repositories to tag.
  3. Click Policy (Policy), and then Edit Tags (Edit Tags).
  4. Select a customer tag to assign from the first list.

    2219

  5. Select a value to assign from the second list.
  6. Click Save.

3.1.6.3. Adding Tags to Ansible Credentials

  1. Navigate to AutomateAnsiblecredentials.
  2. Select the checkboxes for the Ansible credentials to tag.
  3. Click Policy (Policy), and then Edit Tags (Edit Tags).
  4. Select a customer tag to assign from the first list.

    2219

  5. Select a value to assign from the second list.
  6. Click Save.

3.1.7. Optimizing Ansible Playbooks for Red Hat CloudForms

Ansible is a simple model-driven configuration management, multi-node deployment, and remote-task execution system. When designing playbooks for use with CloudForms it is helpful to utilize solutions within the playbook itself to ensure optimal implementation of playbook-backed services or automated processes.

This section is intended to complement the existing documentation on Ansible playbooks and guide administrators through optimizing playbooks for use with CloudForms.

3.1.7.1. Installing Roles on an Embedded Ansible Appliance

Roles are ways of automatically loading certain variable files, tasks, and handlers based on a known file structure. Grouping content by roles also allows easy sharing of roles with other users. Install roles on a Red Hat CloudForms appliance with the Embedded Ansible server role activated to optimize playbooks.

When using this role in a playbook on a CloudForms appliance, add an empty roles directory at the root of the playbook. In the roles directory, include a requirements.yml file with the following contents:

---
- src: <ansible-galaxy-role>

CloudForms will automatically install the role once it sees the requirements.yml file in the playbook.

3.1.7.2. Ansible Service Linking

Red Hat CloudForms provides a module allowing inventoried resources such as virtual machines created using Ansible playbooks to link back to the services used to generate them. During service ordering of a playbook the add_provider_vms module will allow the playbook to connect back to the worker appliance and identify the provider resources it was responsible for generating. Once linked, the newly generated resources are available to CloudForms’s life cycle management features.

Linking VMs back to the service that created it requires implementing the following tasks in the playbook used for provisioning:

  1. Create a resource and register it.
  2. Link the service using the add_provider_vms method to the newly created resource.
3.1.7.2.1. Example: Linking a virtual machine to a service

In the following playbook task examples, a virtual machine is deployed to Amazon EC2 and linked back to the service. Examples are provided for linking the resource to its service by both an href slug and as an object.

Note
  1. Create and register the resource.

    - name: Create Ec2 Instance
      ec2:
        key_name: "{{ key }}"
        instance_tags: {Name: "{{ name }}"}
        group_id: "{{ security_group }}"
        instance_type: "{{ instance_type }}"
        region: "{{ region }}"
        image: "{{ image }}"
        wait: yes
        count: 1
        vpc_subnet_id: "{{ subnet }}"
        assign_public_ip: yes
      register: ec2
  2. Call the add_provider_vms method as an action to link to the service via an href slug or an object.

    - name: Service Linking via an href slug
      manageiq_vmdb:
        href: "href_slug::services/80"
        action: add_provider_vms
        data:
          uid_ems:
            - "{{ ec2.instances[0].id }}"
          provider:
            id: 24
    
    - name: Service Linking via an object
      manageiq_vmdb:
        vmdb: "{{ vmdb_object }}"
        action: add_provider_vms
        data:
          uid_ems:
            - "{{ ec2.instances[0].id }}"
          provider:
            id: 24

3.1.7.3. Modifying the Automate Workspace Using the manageiq-automate Role.

The manageiq-automate role allows users of Red Hat CloudForms Automate to modify and add to the automate workspace via an Ansible playbook.

Note

When using this role in a playbook on a Red Hat CloudForms appliance with Embedded Ansible activated, add an empty roles directory at the root of the playbook. In the roles directory, include a requirements.yml file with the following contents:

---
- src: syncrou.manageiq-automate

CloudForms will automatically install the role once it sees the requirements.yml file in the playbook.

3.1.7.3.1. Role Variables

The manageiq_automate role employs the following variables when implemented in a playbook run on a CloudForms appliance. Variables are defined in defaults/main.yml and vars/main.yml.

auto_commit: By default is set to True. If set to False it will not auto commit back to CloudForms each call to a set_ method in the manageiq_automate module.

manageiq_validate_certs: By default is set to True. If passed in via extra_vars or assigned in the playbook variables then the lookup will allow self-signed certificates to be used when using SSL REST API connection URLs.

3.1.7.3.2. Example Playbook

The example below utilizes the manageiq-automate role. Using variable substitution, playbook tasks retrieve method parameters which are then used to modify object attributes. A final task uses the set_retry module to update the retry interval.

- name: Siphon Method Parameters into an object
  hosts: localhost
  connection: local
  vars:
  - auto_commit: True
  - object: root
  - interval: 600

  gather_facts: False
  roles:
  - syncrou.manageiq-automate

  tasks:
    - name: "Get the list of Method Parameters"
      manageiq_automate:
        workspace: "{{ workspace }}"
        get_method_parameters: yes
      register: method_params

    - name: "Set attributes"
      manageiq_automate:
        workspace: "{{ workspace }}"
        set_attributes:
          object: "{{ object }}"
          attributes: "{{ method_params.value }}"

    - name: Set Retry
      manageiq_automate:
        workspace: "{{ workspace }}"
        set_retry:
          interval: "{{ interval }}"

3.1.7.4. Callbacks in Multiple Appliance Environments

In a Red Hat CloudForms multiple appliance environment, enable the Embedded Ansible server role on a dedicated CloudForms appliance. Add store_session:sql to Ansible playbooks to ensure successful callbacks to CloudForms appliances in a multiple appliance environment.

See Deploying CloudForms at Scale for more information on mutiple appliance environments.

3.2. Ansible Tower

Ansible Tower is a management tool integrated with Red Hat CloudForms, designed to help automate infrastructure operations. Red Hat CloudForms allows you to execute Ansible Tower jobs or workflows using service catalogs and Automate. No custom configuration or Ruby scripting is needed in CloudForms, as configuration is done in Ansible Tower using playbooks.

You can use the large library of existing Ansible playbooks as CloudForms state machines to automate tasks such as deployments, backups, package updates, and maintenance in your Red Hat CloudForms environment. This can be particularly useful for quickly applying changes across large environments with many virtual machines or instances.

Using Ansible Tower, you can schedule Ansible playbook runs and monitor current and historical results, allowing for troubleshooting or identification of issues before they occur.

3.2.1. Working with an Ansible Tower Provider

The basic workflow when using Red Hat CloudForms with an Ansible Tower provider is as follows:

  1. Create an Ansible playbook which performs a specific task.
  2. A new Ansible Tower job template is created from the playbook (or workflow template created from disparate jobs), which is then retrieved by CloudForms.
  3. From the Ansible Tower job or workflow template, create a new catalog item in CloudForms, optionally with a service dialog that allows the user to enter parameters if needed.
  4. The user orders the service from the CloudForms user interface, and fills out any additional arguments (for example, limiting the task to run on a specific set of virtual machines).
  5. The job or workflow executes.
Note

3.2.2. Adding an Ansible Tower Provider

To access your Ansible Tower inventory from Red Hat CloudForms, you must add Ansible Tower as a provider.

Note
  • Ensure ENABLE HTTP BASIC AUTH is set to On in the Ansible Tower configuration settings before adding the provider. See Tower Configuration in the Ansible Tower Administration Guide.
  • A trailing slash is required at the end of the Ansible Tower provider URL. Adding the trailing slash to the provider URL assures successful provider refreshes.
  1. Navigate to AutomationAnsible TowerExplorer and click on the Providers accordion tab.
  2. Under Configuration Configuration, click Add a new Provider Add a new Provider.
  3. In the Add a new Provider area:

    Add_Ansible_Provider

    1. Enter a Name for the new provider.
    2. Add a Zone for the provider.
    3. Enter the URL location or IP address to the Ansible Tower server. Add a trailing slash to the end of the Ansible Tower provider URL.
  4. Select the Verify Peer Certificate checkbox if desired.
  5. In the Credentials area, provide the Username and Password, and Confirm Password.
  6. Click Validate to verify credentials.
  7. Click Add.

After adding the Ansible Tower provider, refresh its relationships and power states in order to view the current inventory.

3.2.3. Refreshing an Ansible Tower Provider

Refresh relationships of all items related to an existing Ansible Tower configuration management provider including inventory, hosts, virtual machines, and clusters.

You can refresh inventory from Red Hat CloudForms, or by enabling the Update on Launch option for inventory groups in Ansible Tower. The Update on Launch option allows Ansible Tower to automatically update inventory using a dynamic inventory script before launching an Ansible Tower job from a playbook. See the Ansible Tower documentation for more information.

Important

It can take a long time to retrieve information from providers containing many virtual machines or instances. The Ansible Tower dynamic inventory script can be modified to limit updates to specific items and reduce refresh time.

To refresh an Ansible Tower provider’s inventory in Red Hat CloudForms:

  1. Navigate to AutomationAnsible TowerExplorer and click the Providers accordion tab.
  2. Select the checkboxes for the Ansible Tower providers to refresh under All Ansible Tower Providers.
  3. Click Configuration (Configuration), and then Refresh Relationships and Power States (Refresh Relationships and Power States).
  4. Click OK.

Red Hat CloudForms then queries the Ansible Tower API and obtains an inventory of all available hosts, job and workflow templates.

3.2.4. Viewing Ansible Tower Providers and Inventory

Red Hat CloudForms automatically updates its inventory from Ansible Tower. This includes system groups (known as Inventories in Ansible Tower), basic information about individual systems, and available Ansible Tower job or workflow templates to be executed from the service catalog or Automate.

Note

To view and access Ansible Tower inventories and job or workflow templates in Red Hat CloudForms, you must first create them in Ansible Tower.

To view a list of Ansible Tower providers and inventory:

  1. Navigate to AutomationAnsible TowerExplorer.
  2. select the Providers accordion menu to display a list of All Ansible Tower Providers.
  3. Select your Ansible Tower provider to expand and list the inventory groups on that Ansible Tower system. The inventory groups can be expanded to view the systems contained within each group, as well as configuration details for these systems.

Similarly, all discovered job and workflow templates are accessed under the provider by expanding the AutomationAnsible TowerExplorerTemplates accordion menu.

3.2.5. Viewing Ansible Tower Configured Systems

To view the systems in your Ansible Tower inventory:

  1. Navigate to AutomationAnsible TowerExplorerConfigured Systems.
  2. Under All Ansible Tower Configured Systems, select Ansible Tower Configured Systems to display a list.

3.2.6. Executing an Ansible Tower Job or Workflow Template from a Service Catalog

You can execute an Ansible Tower playbook from Red Hat CloudForms by creating a service catalog item from an Ansible Tower job or workflow template.

Important

You must first create the job or workflow template in Ansible Tower. The job or workflow templates are automatically discovered by Red Hat CloudForms when refreshing your Ansible Tower provider’s inventory.

First, create a catalog:

  1. Navigate to ServicesCatalogs.
  2. Click Configuration (Configuration), then Add a New Catalog (Add a New Catalog)
  3. Enter a Name and Description for the catalog.
  4. Click Add.

Then, create an Ansible Tower service catalog item:

  1. Navigate to AutomationAnsible TowerExplorer, then click on the Templates according menu.
  2. Click Ansible Tower Templates and select an Ansible Tower job or workflow template.
  3. Click Configuration (Configuration), then Create Service Dialog from Template (Create Service Dialog from this Template).
  4. Enter a Service Dialog Name (for example, ansible_tower_job)and click Save.
  5. Navigate to ServicesCatalogs. Click Catalog Items.
  6. Click Configuration (Configuration), then Add a New Catalog Item (Add a New Catalog Item) to create a new catalog item with the following details, at minimum:

    • For Catalog Item type, select Ansible Tower.
    • Enter a Name for the service catalog item.
    • Select Display in Catalog.
    • In Catalog, select the catalog you created previously.
    • In Dialog, select the service dialog you created previously (in this example, ansible_tower_job). To ask the user to enter extra information when running the task, Service Dialog must be selected. A dialog is required if Display in Catalog is chosen.
    • In Provider, select your Ansible Tower provider. This brings up the Ansible Tower Template option and configures the Provisioning Entry Point State Machine automatically.
    • Add configuration information for Reconfigure Entry Point and Retirement Entry Point as applicable.
    • Select your desired Ansible Tower Template from the list. Generally, this is the Ansible Tower job or workflow template previously used to create the service dialog.
  7. Click Add. The catalog item you created will appear in the All Service Catalog Items list.

To execute the Ansible Tower job:

  1. Navigate to Service CatalogsAnsible Tower catalog.

    Order AT Catalog Item

  2. Click Order for the catalog item.
  3. Enter any variables requested and click Submit.

Red Hat CloudForms takes you to the Requests queue page and show the status of the job.

The service item’s details can be viewed in ServicesMy Services in Red Hat CloudForms.

Note

Instead of running a single job at a time, multiple service catalog items can also be grouped together as a catalog bundle to create one deployment with multiple job templates. See Catalogs and Services in Provisioning Virtual Machines and Hosts for more information.

3.2.7. Executing an Ansible Tower Job Using a Custom Automate Button

Red Hat CloudForms can execute Ansible Tower jobs on virtual machines or instances using custom buttons in Automate.

Ansible Tower jobs can either be non-customizable, which do not require any extra configuration from the user, or alternatively, they can allow the user to specify a parameter (for example, a package name to install). In Ansible Tower jobs containing a dialog, Red Hat CloudForms accepts additional information from the user and adds it to the appropriate API call in Automate, and then sends it into Ansible Tower.

Prerequisites

Before creating an Automate button to execute an Ansible Tower job, the following must be configured:

  • An Ansible playbook in Ansible Tower. See the Ansible Tower documentation for instructions.
  • Ansible Tower must be able to reach virtual machines or instances deployed by Red Hat CloudForms at the IP level.
  • The virtual machine template must have the Ansible Tower environment’s public SSH key injected. For cloud instances, cloud-init can be used and the public SSH key can be passed without rebuilding the image.
  • Any dynamic inventory scripts used must be configured to return the virtual machine names exactly as they are stored in Red Hat CloudForms, without the UUID appended.

Executing an Ansible Tower Job using a Custom Automate Button

To configure a custom button to execute an Ansible Tower job on a virtual machine or instance, first create the button:

  1. Navigate to AutomationAutomateCustomization.
  2. Click the Buttons accordion menu.
  3. Click VM and InstanceUnassigned Buttons. This configures the button to run on virtual machines or instances.
  4. Click 1847 (Configuration), then click 1862 (Add a new Button).

    • In the Adding a new Button screen, configure the Action parameters as desired. Dialog can be left blank if the playbook does not require extra variables. To ask the user to enter extra information when running the task, Service Dialog must be selected.
    • Configure Object Details fields with the following request details:

      • For System/Process, select Request.
      • For Message, enter create.
      • For Request, enter Ansible_Tower_Job.
    • Configure Attribute/Value Pairs with the following parameters:

      • job_template_name is the Ansible Tower job template name to associate with the button. The job_template_name field is mandatory; other parameters are provided by the Tower job dialog.
    • Configure Visibility to all users, or limit visibility by role as desired.

      Add button

    • Click Add.

If you do not have an existing button group to assign the new button to, create a new button group:

  1. From AutomationAutomateCustomization, navigate to ButtonsVM and InstanceAdd a new Button Group, and configure the following:

    • Configure Basic Info as desired. For example, name the button group VM Actions.
    • In Assign Buttons, select the button you just created from the Unassigned list and click 1876 to assign it to Selected.

      Create button group

    • Click Add.

To assign the button to an existing button group:

  1. Navigate to ButtonsVM and InstanceVM ActionsEdit this Button Group.
  2. In Assign Buttons, select the button you just created from the Unassigned list and click 1876 to assign it to Selected.
  3. Click Add.

To use the button to run an Ansible Tower job on a virtual machine:

  1. Navigate to ComputeInfrastructureVirtual Machines.
  2. Select the virtual machine to run the Ansible Tower job template on.
  3. Click the VM Actions button to show the button you created, and click the button from the list to run the Ansible Tower job template.

    Run Update Button

  4. Click Submit to execute the job.

Red Hat CloudForms then confirms the job has been executed.

If you selected a service dialog to run when creating the button, Red Hat CloudForms will then prompt you to enter variables to complete the task. After entering your desired parameters, Red Hat CloudForms takes you to the Requests page.

The service item’s details can be viewed in ServicesMy Services in Red Hat CloudForms.