Do you use Red Hat Satellite and Red Hat Ansible Automation Platform? As far back as Satellite version 6.3, these products can be integrated together. Once integrated, Ansible Tower will be able to pull a dynamic inventory of hosts from Satellite. In addition, once a Red Hat Enterprise Linux (RHEL) host is provisioned by Satellite, it can be configured to automatically make a callback to Ansible Tower to run a playbook to configure the new host.

This post, which is part one of a two-part series, will show how to set up a dynamic inventory in Ansible Tower that pulls a list of hosts from Satellite, and cover examples of how to use this dynamic inventory. The second post in the series will cover how to automatically make a callback to Ansible Tower after newly provisioned hosts are built from Satellite. 

Configuring Satellite as a Dynamic Inventory in Ansible Tower

Ansible Tower will need an account to authenticate to Satellite in order to pull a list of hosts, host groups, and host facts. This account needs minimal permissions in Satellite, so we will create a new Satellite role with just the permissions required by Ansible Tower, then create a new account that is assigned the new role. 

On Satellite 6.6 and later, a Ansible Tower Inventory Reader role is included and does not need to be manually created, thus the following steps to create a new role can be skipped. 

For Satellite 6.3 to 6.5, we need to manually create a new role. To do so, login to the Satellite web interface, go to the Administer menu, select Roles, and click Create Role. 

We’ll name the role ansible_tower_integration_role. Select the Locations and Organizations that should be assigned to the role:


Assigning roles to Locations and Organizations in Satellite

Next, we’ll click the Submit button to create the role. After this, we’ll click on the role name, and click on the Filters tab. We’ll then click the green New Filter button and add the following filters, one at a time:

Resource Type: Host,  Permission: view_hosts
Resource Type: Host Group, Permission: view_hostgroups
Resource Type: Fact value, Permission: view_facts

Once done, the role should have these filters:


Filters for the ansible_tower_integration_role

Now that the role has been created, we’ll add a new Satellite user account by going to the Administer menu, selecting Users, and clicking Create User. In this example, we’ll name the account ansible_integration, change the Authorized by setting to INTERNAL, and set a password for the account. We’ll then go to the Locations and Organizations tabs and select the Locations/Organizations the account should be configured with. Finally, we’ll go to the Roles tab and configure the account to use the newly created ansible_tower_integration_role if you are on Satellite 6.3 - 6.5, or the included Ansible Tower Inventory Reader role if you are Satellite 6.6. We’ll then click Submit to create the account. 

Ansible Tower Configuration

Next, we’ll login to the Ansible Tower web interface and click on the Credentials item in the menu. We’ll click the green + (Add) button to create a new credential. In this example, we’ll name the new credential satellite_integration and set the Credential Type to Red Hat Satellite 6. Following this, we’ll complete the Satellite 6 URL, username, and password fields, using the ansible_integration account and password we just created on the Satellite server: 


Credentials dialog in Satellite

After that is complete, we will click the Save button. 

Next, we’ll go to the Inventories menu item, click the green + (Add), and select Inventory. For the name, we’ll specify satellite_inventory and click Save to create the inventory. Our next step is to go to the Sources tab of the newly created inventory and click the green + (Add). The source name in this example will be set to satellite and the source type will be set to Red Hat Satellite 6. The Credential will be set to satellite_integration which we defined in a previous step. We’ll also check the boxes for the Overwrite, Overwrite Variables, and Update on Launch update options (for more information on these options and what they do, click the question mark next to each of them). In addition, we’ll set the Cache Timeout (Seconds) to 90 and, finally, click Save


Sources tab in Sattelite

Then, still on the Sources tab, we’ll click the Start sync process icon:


Sources tab showing the Start sync process icon

Watch for the cloud icon to turn green, which indicates that the inventory sync was successful. 

We can now look at the Hosts tab to see the information populated from Satellite:


Hosts tab showing information populated by Satellite

We can also view the Groups tab:


Groups tab in Satellite

Not only were the lists of hosts from Satellite synchronized, but they were also broken down into groups based on their respective Satellite content views, host groups, lifecycle environments, locations, and organizations. These groupings can be used to target Ansible playbook runs on particular hosts, which is a very powerful feature. 

If we pull up one of the individual hosts from the Hosts tab, we can see that numerous facts regarding the hosts were also synchronized from Satellite to Ansible Tower. These variables are also usable within playbooks:


Client variables

Putting the Satellite Dynamic Inventory to Use

Now that we have synchronized the Satellite inventory into Ansible Tower, we’ll go over a few examples of how this can be put to use. 

In the simplest form, we can just use the satellite_inventory as the Inventory source in an Ansible Tower Template. If the playbook is configured with hosts: all, it will be run on every Satellite host. 

If we want to utilize the inventory groups automatically created (which are based on Satellite content views, hostgroups, lifecycles, locations, and organizations), we could create a playbook that specifies the host group (with the hosts: line), such as this playbook which installs screen:

- name: Install screen package
  hosts: "foreman_hostgroup_rhel6"
  - yum:
      name: screen
      state: installed

In this example, we set hosts to foreman_hostgroup_rhel6, which contains a list of hosts in the rhel6 Satellite host group. Since we specified this group in the playbook, it will only be run on these hosts. 

It’s also possible to set the hosts parameter in the playbook to be a variable, then pass that variable in from Ansible Tower. For example, we could update the playbook to this:

- name: Install screen package
  hosts: "{{ hosts_var }}"
  - yum:
      name: screen
      state: installed

From Ansible Tower, we can then update the job template to specify one of the inventory groups as an extra variable:


Inventory groups

In this example, the job template will only run on the hosts in the rhel7 Satellite host group.

We could even configure the job template to prompt the user to set the hosts_var extra variable when the template is run (and specify the possible inventory group names as comments so they are shown to the user when the template is run):


Configuring the job template

In this example, when the template is run, the user is prompted and the playbook will run on whichever Satellite inventory group the user specifies. 

Additionally, it’s possible to use the host variables from Satellite that were pulled in during the inventory synchronization. Here is an example playbook that shows how to reference these variables:

- name: Show Satellite variables
  hosts: all
  - name: Show subscription_status
      msg: >
        Subscription Status: {{ foreman.subscription_status_label }}
  - name: Show Errata Counts
      msg: >
        Bug fixes: {{ foreman.content_facet_attributes.errata_counts.bugfix }},
        Security: {{ }},
        Enhancement: {{ foreman.content_facet_attributes.errata_counts.enhancement }},
        Total: {{ }}

When we run this playbook through Ansible Tower, it shows the values of the variables:


Showing values of the playbook variables in Ansible Tower

Of course, we can also use these variables with a conditional when statement so tasks only run under certain conditions. For example, you could use a when conditional to have a task that only runs when security errata needs to be installed, or a task that only runs if the subscription status of the host is not valid. 

Summary and Closing

Red Hat Satellite and Red Hat Ansible are both very powerful tools. By integrating these tools, they become even more powerful together. In this post, we covered how to integrate Satellite as a dynamic inventory source for Ansible, and how to use this dynamic inventory once it is setup. In the next post, we’ll cover how to make a provisioning callback to Ansible Tower after a host is provisioned with Satellite.

About the author

Brian Smith is a Product Manager at Red Hat focused on RHEL automation and management.  He has been at Red Hat since 2018, previously working with Public Sector customers as a Technical Account Manager (TAM).  

Read full bio