Ansible Tower and Satellite: End to End Automation for the Enterprise
Overview
In this article we will look at how Ansible Tower and Red Hat Satellite 6 integrate with one another, providing end-to-end automation for the enterprise. Satellite is a systems management tool that combines several popular opensource projects: Foreman (provisioning), Katello (content repository), Pulp (database), Candlepin (subscription management) and Puppet (configuration management). While puppet is directly integrated into Satellite, many organizations would rather use Ansible because of its power, simplicity and ease-of-use.
Ansible Tower integrates with Satellite, allowing organizations to run playbooks against the hierarchy and groups of servers defined in Satellite. Additionally, Ansible Tower can dynamically update its inventories with hosts and their updated facts from Satellite at anytime. Hosts show up in Ansible Tower under the groups defined by Satellite. This allows organizations to use Satellite to define their infrastructure, provision hosts, provide patch management while leveraging Ansible to deploy and manage software configuration. It also allows other teams the ability to run playbooks and automation against the infrastructure defined by Satellite. Personally I am a huge fan of this loose coupling and find this solution much more advantageous than a direct coupling of Ansible in Satellite.
Prerequisites
In order to get up and running, Satellite and Ansible Tower are required. Below are guide to get you going in case you don't have environments.
For those that are just using foreman and not Satellite, I haven't tried it but let me know if it works. If not there is a Foreman Ansible dynamic inventory that can be added into Ansible Tower.
Satellite Configuration
In Satellite we need to provision a host or bootstrap an existing host. In this example I have simply setup a host with RHEL 7.3 and then connected it to Satellite environment via bootstrapping.
[On RHEL Host]
Install Katello package from Satellite server.
# rpm -Uvh http://sat6.lab.com/pub/katello-ca-consumer-latest.noarch.rpm
Subscribe using activation key.
# subscription-manager register --org="Default_Organization" --activationkey="DEV_CORE"Enable Satellite tools repository and install katello agent.
# yum -y install --enablerepo rhel-7-server-satellite-tools-6.2-rpms katello-agent
Once bootstrapping is complete, the host should show up under Hosts->All Hosts in Satellite. In this case the host in question is called 'soetest.lab'. Note the list of hosts as when we do an inventory in Ansible we will automagically see them, their groups and facts, all from Satellite.
Ansible Tower Configuration
Now that we have a few hosts configured in Satellite and our example host 'soetest.lab', we can setup Ansible Tower. Again the idea is to use Satellite for provisioning and patch management, then Ansible for everything else while taking advantage of the hierarchy as well as host facts from Satellite.
[Ansible Tower]
Create a new project
A project in tower points to source code management (in this case Git) and provides various options. In this case we checked "Update on Launch". This means if a playbook is launched from project (Git repository), Ansible Tower will do SCM update and get latest version of playbook (git pull). Also note a branch can be provided, it is left blank which for Git defaults to the main branch.
Once project is added we can see last update and also the revision.
Add Credentials
Ansible Tower allows for securely storing credentials. There are three different types of credentials: machine, cloud and network. In this case we need machine credentials to connect to our host 'soetest.lab' in order to run playbooks. In addition to dynamically get inventory of hosts from Satellite, including host facts such as IP (which is required), cloud credentials are needed to connect to Satellite. For those of you used to defining static inventories with IPs, the light should now being going on.
Add Machine Credential
Ansible Tower can store either user/password or ssh private key. Most likely you would want to use private key but here I chose to use user/password.
Add Cloud Credential
In order to communicate with Satellite and dynamically inventory hosts from Satellite, cloud credentials for Satellite are required. Ansible Tower supports many cloud platforms out-of-box (VMware, AWS, GCE, Azure, OpenStack, CloudForms and Rackspace).
Once credentials have been defined we can create inventories.
Create Inventory
An inventory is a hierarchy and you can have groups that have sub-groups, it is really flexibly. In this example we create an inventory called Datacenter. Under Datacenter a group is created for all hosts that are part of Satellite environment. Windows systems could be inventoried in a separate group from Satellite servers under Datacenter for example.
Create Datacenter Inventory
Create Satellite Inventory Group under Datacenter
When adding Satellite inventory we would select source "Red Hat Satellite 6" and our cloud credential for Satellite. In addition we select "Update on Launch". This ensures when a playbook is run against Satellite inventory that the hosts are dynamically updated prior to execution of playbook. Let's say hosts are using DHCP and IPs of our hosts changed. Normally this would be an issue but with dynamic inventory, host IP is updated and Ansible playbook runs without issues.
Once Satellite inventory is added we can click the sync button next to "Satellite Hosts". Doing so will manually sync hosts. On the right we then see the hosts, the same hosts we saw under "All Hosts" in Satellite.
In addition if we click on host, the facts provided by Satellite are also displayed in YAML or JSON. Any host facts in Satellite can be used directly in our playbooks or as limit rules as we will see. Limit rules allow you to limit hosts within an inventory. In this example we limit the playbook to the Satellite hostgroup "RHEL_7_Dev_Servers" which is a parameter provided by the host facts.
If we look under Satellite group we see the groups and hierarchy imported from Satellite. Not just hostgroups but lifecycle environments are also imported.
If we click on "foreman_hostgroup_rhel_7_dev_servers" (hostgroup), we see just the one host soetest.lab that is associated to that hostgroup in Satellite. Again these relationships are all defined in Satellite and automatically imported into Ansible Tower.
Create Job Template
In Ansible Tower a job template brings together a playbook located within a project with an inventory and credentials. Here we have selected the playbook http_simple. This playbook will setup a webserver and use information from satellite to setup website (more on this later). In this example we have also set a limit rule to limit the run of the playbook to hosts that are part of the Satellite hostgroup "RHEL 7 Dev Servers".
Create Survey
Survey's in Ansible Tower are optional but provide opportunity to ask the user for input. In this example we ask for a username. The username will then be displayed in the website dynamically to show how to use survey parameters inside playbooks.
Run Job Template
By clicking on the rocket, a job template can be manually started. Job templates can also be scheduled and Ansible Tower offers an integrated scheduler that can even balance jobs across multiple Tower servers in HA setup.
After launching job we are prompted for limit. The default is our satellite hostgroup. You can decide if you want to prompt and allow users to change limits.
Once we accept limit we are prompted with our survey. Here we need to enter username. The username has a variable associated "survey_username" and we can use this to display or use the input in our playbook.
Once job is started we are brought to the job status. On the left we can see our limit and survey username as extra variables. On the right we see the tasks that were executed in our playbook. We also see summary of tasks where something changed, failed or was unreachable. We see the hosts where the playbook was run, we had just one host since our hostgroup (limit rule) only defined one host. The reports are available for all jobs and we can trace them back to user who ran them. Users running jobs don't need to have access to systems or even have credentials. This is a huge advantage for compliance and auditing.
If we look at jobs, we will see three jobs. Our SCM (Git) was updated, then our host inventory (Satellite) was dynamically updated and finally the playbook ran.
After playbook run completes we can view our website. Here we see the hostname and IP. These are coming from the foreman facts in Satellite. In addition we see our username from the survey.
The implementation for this dynamic web page can be found here or below.
<html>
<head>
<title>Ansible Application</title>
</head>
<body>
</br>
<a href=http:///index.html>Homepage</a>
</br>
<?php
Print "Hello, World! I am a web server configured using Ansible and I am : ";
echo exec('hostname');
Print "</BR>";
Print "My ip address imported from foreman facts is : ";
echo "''";
Print "</BR>";
Print "My username from survey is : ";
echo "''";
Print "</BR>";
?>
</body>
</html>
Summary
In this article we have discussed the value for integrating Satellite and Ansible Tower. We have seen how to configure a basic host in Satellite for patch management. Using Ansible Tower we were able to dynamically get not only hosts and their associated groups from Satellite but also the host facts. We were able to run a playbook against a group of hosts in Satellite using a limit rule. Finally using survey and facts we observed how to easily reuse external parameters withing our playbooks.
Happy Automating with Ansible Tower and Satellite!
(c) 2017 Keith Tenzer