Previous articles have discussed the underlying principles, and implementation of a Standard Operating Environment. While most previous implementations have been accomplished using Red Hat Satellite and Puppet, Ansible is now seen as the simplest way of performing server configuration and orchestration.
This article demonstrates how to get started with calling Ansible playbooks, hosted on Ansible Tower, from Red Hat Satellite’s deployment mechanism.
We start by considering the concept of profiles within an SOE. Each server profile maps to a primary server function, for example:
- Basic RHEL server
- PostgreSQL server
- Apache server
Within Red Hat Satellite, a profile maps one-to-one with a Hostgroup. Within Ansible, a profile maps one-to-one with a playbook.
Therefore, for each profile we need, we will create a single Hostgroup in Satellite, and a single Ansible playbook. Deploying a server from the Hostgroup will ensure that the correct Ansible playbook is executed in the kickstart to configure the server.
Configuring Ansible Tower
Configuring the Inventory
Ansible Tower is configured to use Red Hat Satellite as an inventory. This allows us to consume Foreman (Satellite) parameters within our playbooks. Configure the inventory as follows:
- Create a credential of type ‘Red Hat Satellite 6’ with satellite username and password.
- Create a new inventory.
- On the ‘sources’ tab of the new inventory, add a new source of type ‘Red Hat Satellite 6’
- Add the credentials you previous created to the inventory.
- Tick the ‘Update on launch’ tickbox.
- Set a suitable cache timeout, for example 120 seconds.
- Perform an initial sync of the inventory source
You should now be able to select the ‘hosts’ tab and see a list of all the hosts on your satellite, as shown here:
Drilling down into a host, should show you all the host’s Foreman parameters, now converted to Ansible variables, as shown here:
You can experiment by setting host parameters within Satellite and then refreshing the inventory – your newly created host parameter will show up under the ‘foreman_params’ dictionary in the host entry in the inventory in Tower.
Configuring the SOE Project
A new project is created in Ansible Tower, pointing to the example repository here. This is a simple Ansible repository containing the following playbooks:
- base-profile.yml Configures an MOTD and sets a default firewall zone
- postgres-profile.yml Configures a PostgreSQL server
- apache-profile.yml Configures an Apache server
Configuring per-profile Job Templates
As you can see from the screencap above, provisioning callbacks are enabled for this job template – this is what will permit us to execute the playbook from within the deployment task in Red Hat Satellite.
Configuring Red Hat Satellite
Customising the Kickstart Template
Red Hat Satellite 6.3 comes with several template snippets that can be used for enabling Ansible-based provisioning. These are:
- ansible_provisioning_callback This snippet checks the parameter ‘ansible_tower_provisioning’ and if it is True, creates a one-shot provisioning service that will execute post-installation.
- ansible_tower_callback_service This is the service enabled by the ansible_provisioning_callback snippet.
- ansible_tower_callback_script This is only used on systems that do not have systemd (RHEL6 and earlier)
The ansible_provisioning_callback snippet is included in the default kickstart template (Satellite Kickstart Default) however, no ssh key distribution method is provided so we will need to modify the default kickstart template to create an Ansible user and authorise a key for it.
Clone the default kickstart template (Satellite Kickstart Default) and replace the stanza:
<%= snippet('ansible_provisioning_callback') %>
<% if @host.info['parameters']['ansible_ssh_key'] -%> <%= snippet "ansible_user_config" %> <%= snippet('ansible_provisioning_callback') %> <% end -%>
Then create the ansible_user_config template as follows:
<%# kind: snippet name: ansible_user_config oses: - RedHat 6 - RedHat 7 %> useradd ansible echo "ansible ALL=(root) NOPASSWD:ALL" | tee -a /etc/sudoers.d/ansible echo 'Defaults:ansible !requiretty' | tee -a /etc/sudoers.d/ansible chmod 440 /etc/sudoers.d/ansible <% unless @host.params['ansible_ssh_key'].blank? %> <% ssh_path = "~ansible/.ssh" %> mkdir -p <%= ssh_path %> cat << EOF >> <%= ssh_path %>/authorized_keys <%= @host.params['ansible_ssh_key'] %> EOF chmod 700 <%= ssh_path %> chmod 600 <%= ssh_path %>/authorized_keys chown -R ansible.ansible <%= ssh_path %> # Restore SELinux context with restorecon, if it's available: command -v restorecon && restorecon -RvF <%= ssh_path %> || true <% end %>
This snippet will create a user called ‘ansible’ and add the public key stored in the Satellite host parameter ansible_ssh_key to the users list of authorised keys. It will also add the ansible user to the sudoers list.
Configuring Global Parameters
In Satellite, configure the following global parameters:
- ansible_ssh_key The public key of the machine credential you will be using in Ansible Tower to execute your playbooks.
- ansible_tower_fqdn The FQDN of your Ansible Tower service
Configuring the per-profile Hostgroups
Create a Hostgroup in Satellite for each server profile you want to deploy. These hostgroups should be correctly configured to entitle the server and correctly register it to a Content View and Lifecycle Environment – information on how to do this can be found in the Satellite documentation available here. Ensure that the hostgroup will use the modified kickstart template that you created earlier – this can be done by setting associations correctly. Do NOT set a Puppetmaster for the hostgroup, unless you intend to use Puppet in addition to Ansible.
Set the following hostgroup parameters:
- ansible_tower_provisioning Set this to true
- ansible_job_template_id set this to the numeric ID of the job template that matches this profile, this is shown in the provisioning callback URL in the job template view in Tower
- ansible_host_config_key set this to the host config key shown in the matching job template screen in Ansible Tower
And that’s it – when you deploy a host from this hostgroup, the one-shot Ansible callback service will be configured to run after reboot, will execute and configure the server into its designated role.