We’ll create some simple host groups in Satellite 6 (see Satellite 6.2 host groups).

​

Although the host groups will define default values for architecture, operating system, media, partition table, domain and root password, these will have no effect in the newly registered virtual machine as they are parameters used during kickstart. The host groups will however define the Puppet environment that the newly attached Satellite client will use for configuration. The Generic_RHEL7_Servers hostgroup will install the motd and ntp Puppet modules.

To register a newly provisioned system with Satellite as a content host, we can include an activation key name as an argument to subscription-manager or the bootstrap.py script. The activation key determines the lifecycle environment, content view, Red Hat subscriptions, and repository content sets to which the newly registered server has visibility. It can be useful to create activation keys for different types of server that require specific combinations of product repositories.

We’ll create a small selection of activation keys in Satellite 6 (see Satellite 6.2 activation keys).

​

The RHEL7-Generic activation key will be used for this example. The Satellite client will:

We’ll use the same inventory credential and inventory that we created in Running an Ansible Tower Job From a Button.

We’ll make a slight change to the SSH Key (ansible-remote) machine credential. We’ll add the vault password for the vault file in which we’ll store the Satellite 6 Admin user’s password. When decrypted this will be used for the the playbook variable vault_admin_pass.

From the project that we created in Running an Ansible Tower Job From a Button, we’ll create a job template called Satellite 6 Client. It will be a Run job type; use the CloudForms VMs inventory and SSH Key (ansible-remote) machine credential that we defined previously, and will execute the satellite_client.yaml project playbook (see Job template).

​

We’ll define some defaults for the extra variables that will be passed to the playbook:

We must also ensure that Prompt on Launch is checked, to allow the variables to be overridden from CloudForms/ManageIQ if we wish (see Default extra variables).

​

This playbook uses an additional variable called admin_pass. The value for this should be stored as an encrypted string, and so we defined it in a vault file as the encrypted variable vault_admin_pass. We can create this using the following commands on the Tower server:

We then add the vault password to the machine credential that we created earlier.

We need our newly provisioned virtual machine to be configured as an Ansible manageable host, so we’ll use the cloud-init template described in Automation Using Ansible. We’ll specify this template in the provisioning dialog when we provision our VM.

Before we integrate the new playbook into our virtual machine provisioning workflow, it is useful to be able to test its functionality from a button on a VM object as we did in Running an Ansible Tower Job From a Button. This will allow us to troubleshoot its operation, and will also add useful functionality to our VM-related button group.

Once again we’ll create a service dialog from the Ansible job template. We’ll give the new service dialog the name "Satellite 6 Client" so that we can identify it as coming from the job template. We can delete the Options box and its Limit element as before, and this time we’ll also edit the hostgroup element to change 't' to 'true' and untick the 'Read only' checkbox. Similarly we’ll edit the updatehost element to change 'f' to 'false'.

Having created the dialog, we can add a button to our VM button group. Our button will use the new "Satellite 6 Client" dialog, and will call the ansible_tower_job instance.

Once defined we can use this button to test the integration with Ansible Tower.

​

We’ll clone the /ConfigurationManagement/AnsibleTower/Operations/JobTemplate class into our domain, and add a new instance of this class called satellite_6_client. We’ll add the value "Satellite 6 Client" as the job template name, and for our first test we’ll leave all of the param fields blank. By not passing any of these parameters to Tower, we ensure that the default job template extra variables that we’ve defined within Ansible Tower are used for the running job.

​

We only want to register a new virtual machine with our Satellite 6 server if it’s running the Red Hat Enterprise Linux (RHEL) operating system. Fortunately we can use a template property called operating_system.distribution to determine whether our template is true RHEL, a clone (such as CentOS), or another distribution or operating system entirely.

We’ll create a new class /Integration/Satellite/AnsibleMethods in our domain, and a new instance of this class called register_satellite. We can put an assertion in our register_satellite instance to evaluate the operating_system.distribution property and compare it with the string "redhat". The execution of the Ansible job template will only proceed if this assertion evaluates to true.

The schema of register_satellite is shown in Fields of the register_satellite instance.

​

We must add an additional state to the VMProvision_VM state machine schema at some point after the VM has been provisioned, called RegisterSatellite. We’ll edit a cloned copy of the template instance of this state machine in our domain, to add our /Integration/Satellite/AnsibleMethods/register_satellite instance to the RegisterSatellite state (see Fields of the VMProvision_VM/template state machine instance).

​

Our first test is to provision a new RHEL 7 VM called "ralsrv001", and have it register with Satellite 6 purely for package content management. We’ll use a fully provisioned 'fat' RHEL 7.2 template called 'rhel72-generic' as our source to provision from, and we’ll select a Provision Type of 'Native Clone'. The template has the cloud-init package installed and configured.

To ensure that the new server is automatically provisioned as an Ansible managed host, we’ll select the Setup for Ansible Tower Management cloud-init script in the Customize tab of the provisioning dialog (see Selecting the cloud-init template).

​

We’ll also complete the Root Password and Host Name fields as these values are passed to the cloud-init script (see Customize tab of the provisioning dialog).

​

The absence of any overridden parameters in our initial satellite_6_client instance means that the default value of 'false' for the hostgroup extra variable will be used. When this value is passed to the Ansible playbook, the server is registered with Satellite 6 as a content host using subscription-manager.

If we examine automation.log while the server is provisioning, we see our assertion being evaluated to true and the Ansible job template being called:

On the Tower server we can see the progress of the job:

We see that the playbook completed successfully, and that the bootstrap-related tasks were skipped. The new server is registered to Satellite 6 as a content host.

For this test we’ll provision another RHEL 7.2 VM (called "ralsrv002"), also from the 'rhel72-generic' template. We’ll use the same provisioning dialog settings as before.

Before we start the provisioning process however, we’ll edit the satellite_6_client instance to add a value for param1. We’re going to override the default 'hostgroup' extra variable, and pass the value "Generic_RHEL7-Servers" (see Content host in Satellite 6).

​

If we follow the provisioning process in automation.log we once again we see our assertion evaluate to true, and the Ansible job template being called. On the Tower server we can follow the progress of the job:

This time we see that the bootstrap.py script was copied to the newly provisioned server and used to register the host as both content host and Puppet client.

In Satellite we can see the two new hosts added. We can verify that the second host, ralsrv02 was added to the host group "Generic_RHEL7_Servers", and has the "KT_Bit63_Production_RHEL_7_2_Q4_2016_9" Puppet environment assigned (see New hosts added to Satellite inventory).

​

To confirm the operation of our assertion in the register_satellite instance when provisioning a non-RHEL server, we’ll provision a CentOS 7.2 server from 'fat' template.

If we follow the provisioning progress in automation.log we see that the assertion evaluates to false, and our Ansible job template is not called.