Ansible Automation Platform

The Ansible Automation Platform configuration manager connects Cloud Management Platform (CMP) to an Ansible Automation Platform or AWX instance and runs its job templates against the servers CMP builds

Import projects, inventories, groups, job templates, and workflows from the platform, then pair an inventory or group with a job template to form a configuration. CMP applies a configuration by adding the server to the appropriate inventory or group and launching the job against it, either while the server is being provisioned or on demand.

Turn the connector on or off

A feature flag controls whether this connector can be added and is enabled by default. To hide it, run the following on the appliance:

sudo su -
/opt/cloudbolt/manage.py features -d "connectors::ansibleautomation"

To reenable:

sudo su -
/opt/cloudbolt/manage.py features -e "connectors::ansibleautomation"

Connect to the platform

  1. Go to Admin > Configuration Managers, then select Add.

  2. Select the Ansible Automation Platform tile.

  3. Complete the form:

    Field Description
    Name Required. Label for the configuration.
    Environments The environments this manager serves. Set this now or later from the configuration manager or the environment.
    Extra Vars Prefix An optional prefix added to every extra variable CMP sends. For example, cloudbolt_ sends the hostname as cloudbolt_hostname.
    AAP Version ≥ 2.5 Select this when the instance runs Ansible Automation Platform 2.5 or later, which changes the API paths CMP calls.
    Connection URL for Ansible Automation Platform Required. With the scheme and port, such as https://awx.example.com:8043. Without a port specified, CMP uses port 443 for HTTPS and port 80 for HTTP.
    Username for Ansible Automation Platform server and Password for Ansible Automation Platform server Required.
  4. Select Create. CMP verifies the connection before saving; the Overview tab’s Verify Connection button rechecks it later.

Import objects from the platform

Each object CMP works with has its own tab on the configuration manager:

  • Projects: select Import All Projects. Each project row has an Import Job Templates icon that imports that project’s job templates, which appear on the Job Templates tab.
  • Inventories: select Import All inventories. Each inventory row has an Import Groups icon for that inventory’s groups, which appear on the Groups tab.
  • Workflows: select Import All Workflows.

Import again after adding objects to the platform.

Build configurations

A configuration is the unit CMP applies to a server: an inventory or group to add the server to, plus a job to run against it. On the Configurations tab, select Add Ansible Automation Configuration and work through the dialog:

  1. Choose whether the server joins an Inventory or a Group.
  2. Choose one from the list. The list shows what you have imported, so an empty list means the import has not run.
  3. Choose Job Template. The dialog also offers Workflow Job Template, not yet supported.
  4. Choose the job template. Only templates that suit the inventory or group you picked are listed.
  5. Name the configuration and select Create Configuration.

Repeat for each required pairing. Applying a configuration takes two steps: the server is added as a host to the inventory or group, and then the job runs against it. The first step is skipped when the host is already in that inventory.

The built-in parameters

Two parameters arrive with the first configuration manager of this type:

  • Required Ansible Automation Configurations
  • Additional Ansible Automation Configurations

Both accept multiple values and populate their options from the configurations a user can see in their ordering context, such as those set in the configuration manager for the environment. Use them as you would any other parameter: set a global default, limit an environment to a subset of the options, or preset a value for a server tier on a blueprint.

Neither name is a rule CMP enforces: a global default on the required parameter applies the same configurations everywhere, while the additional parameter is the one to expose on the order form.

Apply configurations while provisioning

Two routes exist, and they can be combined.

The built-in orchestration action

A built-in action at the Ansible Automation Configuration trigger point reads the values the server picked up for either parameter and applies those configurations. It runs as part of the provisioning job, after the operating system is installed and the network is verified. Use this route unless you need to control the order in which configurations are applied.

To keep the action from applying anything, leave the parameters off your environments and set no default values, so a server never acquires a value for either one.

A blueprint build action

Adding the action to a blueprint applies configurations in the order you place them:

  1. On the Build tab of a blueprint, select Action.
  2. Select the CloudBolt Plug-in type.
  3. Select Ansible Automation Configuration. The build item appears with an action input listing valid configurations.
  4. Set a default value for the action input by editing the build item, or leave it for the requester to choose on the order form.
  5. Add the action again for each group of configurations you want applied at a distinct point in the build.

This is the same plugin as the server action below, so a change to it affects both.

Apply configurations to an existing server

A server in an environment served by this configuration manager carries an Ansible Automation Configuration button on its detail page. Its action input offers the configurations valid for that server’s environment, honoring any limits set there, and applies the ones you select.

The action runs in bulk from the server list. Check the offered options before running it, since a selection made once is applied to every selected server.

  • Ansible: Connecting to a plain Ansible management server, which runs playbooks by path.
  • Parameters: Setting defaults and constraining options for the two built-in parameters.
  • Orchestration actions: How trigger points and actions fit into a provisioning job.