In today’s fast paced environment, system administrators don’t have time to manually make configuration changes across servers in their environment. Instead, they need tools that can help automate configuration management. Ansible is a powerful automation tool, and in Satellite 6.4 Red Hat introduced the ability to use Ansible for basic host configuration management.
There are two main ways that Ansible can be used within Satellite. The first is using the Red Hat Enterprise Linux (RHEL) System Roles within Satellite, which help automate configuration of several common RHEL subsystems. Using RHEL System Roles in Satellite does not require an Ansible subscription.
The second way to use Ansible within Satellite is by using custom and 3rd party Ansible roles from within Satellite, which is what this post will be covering. This requires that you have a valid Ansible subscription. For more information on Ansible support in Satellite, please see the Scope of Support for Ansible Components included with Red Hat Satellite 6.
In this post, we will go through an example of setting up Satellite to run a custom Ansible role to manage the message of the day file (/etc/motd) on several Satellite hosts.
Setting Up Remote Execution
The first thing to check when getting started with Ansible is what version of Satellite you have in your environment. Ansible functionality for configuration management was introduced in Satellite version 6.4. If you are on a prior version of Satellite, first upgrade to at least Satellite 6.4, or Satellite 6.5 if possible (which is currently the latest release, and is the recommended version).
Satellite uses the existing remote execution functionality to run Ansible roles on remote hosts, therefore, you must have remote execution working in the environment.
To test if remote execution is working, login to the Satellite web interface, go to the Hosts menu, and select All Hosts. Next, select all of the hosts you would like to use Ansible with, go to the Select Action drop down menu, and select Schedule Remote Job. We can leave the Job category set to Ansible Commands and the Job template set to Run Command – Ansible Default. For the command, we will specify hostname as a simple test command to run, as shown:
If the results for the remote job are successful on all of your hosts, then remote execution is working in your environment. If some or all of your hosts failed, you need to setup remote execution. There could be a number of issues causing a failure, but the most frequent is the SSH keys not being distributed to your hosts. See the documentation for information on how to distribute the SSH keys. Other issues that can cause remote execution failures are hostname resolution issues, remote servers inaccessible or down, firewalls blocking SSH traffic, etc.
Creating the Message of the Day (MOTD) Ansible Role
Once we have remote execution working, the next step is to create a new Ansible role that will configure the /etc/motd file.
A directory structure needs to be created on the Satellite server for the new role (and also on any Capsule servers with clients that will use the role), which we can create with the following commands:
# mkdir -p /etc/ansible/roles/motd/tasks # mkdir -p /etc/ansible/roles/motd/templates
Next, we will create the /etc/ansible/roles/motd/tasks/main.yaml with the following contents:
This specifies that the /etc/motd file should be created from the motd.j2 Jinja2 template, and should be set up with the specified mode, owner, and group.
Finally, we will create the Jinja2 template at /etc/ansible/roles/motd/templates/motd.j2 which defines what the /etc/motd file will look like with the following contents:
In the Jinja2 template, we referred to a variable named test_var, which we will later define in Satellite.
Importing the MOTD Ansible Role
Now that we have created our Ansible MOTD role, we need to import it into Satellite. To do this, first login to the Satellite web interface, then go to the Configure menu, and under the Ansible header, select Roles. From here, click on the blue From Satellite FQDN button, then check the box for the motd role, and click the Update button:
In this demo environment, there are no Capsule servers. If you are using Capsule servers in your Satellite environment, refer to the documentation regarding importing and managing Ansible roles on Capsule servers.
Configuring Hosts for the Ansible Role
We now have the motd Ansible role created and imported into Satellite. At this point, we could edit an individual host and assign it to the Ansible role, or we can use a Satellite Host Group and assign the Ansible role and the Satellite hosts to this Host Group.
In this example, we will use a Host Group, since it is usually more efficient than managing Ansible roles at the individual host level.
We will create a new Host Group by going to the Configure menu and selecting Host Groups. Then, we will click the blue Create Host Group button in the upper right side of the page. In this example, we will give the Host Group a name of Test, as shown in this screenshot:
Then, we will click on the Ansible Roles tab, and add the motd role by selecting it under Available roles, which moves it to Selected Items:
In our motd.j2 Jinja2 template, we referred to a test_var variable, which is going to be passed from Satellite. From Satellite, this variable can be defined at the global level, the Host Group level, or at the individual host level. In this example, we will define it at the Host Group level by clicking on the Parameters tab and clicking the + Add Parameter button. For the variable name, we will specify test_var, and for the value, “Hello from Satellite!”, as shown in the next screenshot:
Then, we’ll click the blue Submit button at the bottom of the screen to create the Host Group.
Next, we will add some hosts to the Host Group by going to the Hosts menu, and selecting All Hosts. We’ll click the checkbox for the hosts that we would like to run the motd Ansible role on, click Select Action, and select Change Group, as shown:
On the next screen, we will specify the Test Host Group, and click the blue Submit button:
Running the Ansible Role
At this point, we have created a new Ansible role, imported it into Satellite, defined a Host Group with the Ansible role, and added our hosts to the Host Group. The next step is to actually run the Ansible role on the hosts.
To run the Ansible role on all the hosts in the Host Group, we can go back to the Configure menu, and select Host Groups. We can then press the down arrow under Actions for the Test Host Group, and select Play Roles:
The Ansible roles in the Host Group will be run on each of the hosts within the Host Group. In this example, we only have the motd role. The results of the operation are shown and if you would like more details, you can click on one of the host names, as shown:
If you click on a host name, you will see additional details about the playbook run:
And if we check on one of the servers, we can validate that the /etc/motd file was updated:
Scheduling Automatic Runs of Ansible Roles
We can optionally configure Satellite to periodically run Ansible roles in an automated manner. This helps ensure our desired configuration stays applied to the hosts. For example, let’s consider the motd Ansible role we created and the /etc/motd file that it is managing. If someone went on the hosts and changed the /etc/motd file, if we did not re-run our Ansible role, the/etc/motd file would not match what the motd Ansible role specified. However, if we configure Satellite to periodically run the motd Ansible role, when run, it would detect if the /etc/motd file did not match what was specified in the motd Ansible role, and update the file to what the motd role specified.
By default, Satellite expects that hosts have Ansible roles run every 30 minutes, or the host status (under All Hosts) will report that Configuration is Out of sync, as shown:
This behavior is configurable under the Administer menu by selecting Settings, then going to the Ansible tab. From there, the Ansible out of sync disabled, and Ansible report timeout settings can be adjusted to change this behavior:
In our example, we will configure the Ansible roles to be run on our hosts in the Test Host Group every 20 minutes. To do this, we will go to the Monitor menu, and select Jobs. Then, we’ll click the blue Run Job button in the upper right. For the new job, we will specify the following:
Job Category: Ansible Playbook
Job Template: Ansible Roles – Ansible Default
Search Query: hostgroup_fullname = “Test”
Schedule: Set up recurring execution.
Repeats: cronline
Cron line: */20 * * * *
Ends: Never
We’ve included a screenshot of this:
We will then press Submit to create the recurring job. At this point, our motd Ansible role will run every 20 minutes on our hosts within the Test Host Group.
Ansible Tower
Satellite provides basic Ansible functionality, however, a number of customers have a need for more advanced Ansible functionality, such as orchestration, role based access control, etc.
In this situation, Ansible Tower is the recommended tool to use, and it is possible to integrate Satellite and Ansible Tower together. For example, Ansible Tower can use Satellite as a dynamic inventory source. In addition, it is possible to use an Ansible Tower provisioning callback to configure hosts provisioned by Satellite. For more information, see the documentation.
