The integration of Red Hat Satellite with Ansible represents a critical convergence of lifecycle management and configuration orchestration. While Red Hat Satellite provides the foundational infrastructure for provisioning, patching, and auditing Red Hat Enterprise Linux (RHEL) assets, Ansible provides the procedural logic required to transform a "bare" provisioned system into a production-ready application server. This synergy allows administrators to move beyond simple image deployment into the realm of Infrastructure as Code (IaC), where the desired state of a data center is defined in version-controlled roles rather than manual checklists. By leveraging Ansible within the Satellite ecosystem, organizations can automate repetitive tasks, enforce consistent configurations across diverse host groups, and implement complex orchestration workflows that span from the initial Kickstart deployment to the final application layer configuration.
The Fundamental Architecture of Ansible in Red Hat Satellite
The deployment of Ansible within a Satellite environment is designed to scale across distributed architectures. In a standard deployment, the Satellite Server acts as the primary control plane, but the actual execution of Ansible roles can be offloaded to Capsules. This distributed execution model prevents the Satellite Server from becoming a bottleneck during large-scale configuration updates.
The technical mechanism for this integration relies on the presence of Ansible roles in specific filesystem locations across the infrastructure. For Ansible to function, roles must be present in the /etc/ansible/roles directory. This requirement extends to both the Satellite Server and any Capsule Server designated for remote execution.
Because manual copying of roles across multiple Capsules is inefficient and prone to error, the architecture necessitates the use of an external version control system (VCS). By synchronizing roles via Git or a similar mechanism, administrators ensure that the exact same version of a configuration role is present on all Capsules, maintaining environment parity.
On the Capsule side, the Ansible functionality is not active by default. It must be explicitly enabled via the satellite-installer. The specific command required to activate this capability is:
satellite-installer --scenario capsule --enable-foreman-proxy-plugin-ansible
This command configures the foreman-proxy to handle Ansible-related requests, effectively turning the Capsule into an execution node capable of pushing configurations to managed hosts.
The connectivity between the Capsule and the target host is governed by SSH. Satellite treats Ansible roles as remote execution jobs; therefore, the Capsule must possess the necessary SSH keys to authenticate with the target host without manual intervention. This requires a robust SSH key distribution strategy, as detailed in the Managing Hosts guide, to ensure that the Capsule can establish a secure tunnel to the host for the duration of the playbook execution.
Detailed Installation and Management of the Red Hat Satellite Ansible Collection
For administrators who need to interact with the Satellite API using Ansible from an external control node or an Ansible Automation Platform (AAP) instance, Red Hat provides a specialized collection: redhat.satellite. This collection acts as a bridge, providing modules that allow Ansible to query, modify, and manage Satellite resources programmatically.
The collection is a certified piece of Red Hat content, meaning it is tested against all currently maintained Ansible versions and compatible Python versions on the target nodes. It is derived from the community theforeman.foreman collection, ensuring a blend of enterprise stability and community-driven innovation.
Installation Methodologies
The collection can be deployed using several different methods depending on the environment's constraints.
The most common method is via the ansible-galaxy command-line tool. To install the latest version, the following command is used:
ansible-galaxy collection install redhat.satellite
For environments requiring strict version control to avoid breaking changes during updates, specific versions can be pinned. To install version 1.0.0, the syntax is:
ansible-galaxy collection install redhat.satellite:==1.0.0
In a DevOps pipeline, the preferred method is using a requirements.yml file. This allows the collection to be treated as a dependency. The file format is as follows:
yaml
collections:
- name: redhat.satellite
Once the requirements file is created, the installation is triggered with:
ansible-galaxy collection install -r requirements.yml
To update an existing installation to the most recent version, the --upgrade flag is utilized:
ansible-galaxy collection install redhat.satellite --upgrade
For those who prefer package-based management, the collection is available as an RPM package named ansible-collection-redhat-satellite within the official Satellite repository.
Collection Technical Specifications
The following table outlines the properties and support structures for the redhat.satellite collection.
| Attribute | Detail |
|---|---|
| Base Collection | theforeman.foreman |
| License | GNU GPL v3 |
| Distribution | Ansible Galaxy, RPM, Automation Hub |
| Support Tier | Red Hat Ansible Certified Content (via AAP) |
| Compatibility | All maintained Ansible and supported Python versions |
| Primary Function | Interaction with the Satellite API |
Leveraging RHEL System Roles within Satellite
Red Hat Enterprise Linux System Roles are pre-defined, tested, and supported Ansible roles that simplify common configuration tasks (such as configuring storage, networking, or time synchronization). Satellite can import these roles to accelerate the deployment of standard enterprise configurations.
The process begins with the preparation of the underlying operating system. On RHEL 7 systems, the rhel-7-server-extras-rpms repository must be enabled to access the necessary packages. This is achieved through the following command:
subscription-manager repos --enable=rhel-7-server-extras-rpms
Once the repository is active, the rhel-system-roles package is installed using the satellite-maintain tool:
satellite-maintain packages install rhel-system-roles
The installation process places the roles into the /usr/share/ansible/roles/ directory. This location is significant because it allows administrators to audit or modify the role files before they are officially imported into the Satellite management layer.
The import process is handled through the Satellite web UI. Users navigate to Configure > Roles, select the specific Capsule containing the roles, and check the roles they wish to import. Once updated, these roles become available for assignment to hosts or host groups. This integration allows these standardized roles to be embedded into Ansible Job Templates, ensuring that every server in the organization adheres to the same corporate standard for system configuration.
Advanced Variable Management and Precedence
A critical aspect of Ansible's power is the ability to parameterize configurations. Satellite provides a sophisticated mechanism to manage these variables, allowing administrators to define specific values for different hosts or groups without modifying the underlying Ansible role.
Creating and Managing Variables
To define a variable within the Satellite web UI, administrators navigate to Configure > Variables and select New Ansible Variable. This process requires the following inputs:
- Key: The name of the variable. Crucially, this name must reference the specific Ansible role name to ensure the variable is correctly mapped during execution.
- Description: A detailed explanation of the variable's purpose for future administrative audits.
- Role Association: Selecting the specific Ansible role from a dropdown list to associate the variable with the correct logic.
These variables can be used to override default values defined within the Ansible role itself. When a role is executed, Satellite injects these variables into the process.
Variable Precedence Logic
When managing complex environments, variables may be defined in multiple places (e.g., in the role defaults, in a host-specific parameter, or in a Satellite-defined variable). There is a strict order of precedence that determines which value "wins."
If a task is executed as a user other than the Effective User, the precedence rules are particularly rigid. To ensure the correct value is applied, administrators must refer to the "Variable precedence: Where should I put a variable?" section of the Ansible User Guide. Failure to adhere to this precedence can lead to "configuration drift," where the actual state of the server does not match the intended state defined in the Satellite UI.
Operational Execution of Ansible Roles
Once the infrastructure is configured and roles are imported, the execution phase begins. Satellite allows for the triggering of Ansible roles directly from the management console.
Execution Prerequisites
Before a role can be executed on a host, two conditions must be met:
1. The deployment must be fully configured to run Ansible roles (including the satellite-installer plugin on Capsules).
2. The specific Ansible roles must be assigned to the target host.
Execution Procedure
The operational flow for running a role is as follows:
- Navigate to
Hosts > All Hostsin the Satellite web UI. - Select the checkbox for the target host(s).
- From the
Select Actiondropdown menu, choosePlay Ansible roles.
After initiating the process, the status of the job can be monitored on the Run Ansible roles page. If a job fails due to a transient network issue, the Rerun button allows for an immediate retry of the operation. This functionality supports the remote management of RHEL versions 8, 7, and 6.9 or later.
Dynamic Inventory Integration with Ansible Tower
For organizations utilizing Ansible Tower (now part of the Ansible Automation Platform), Satellite can serve as a dynamic inventory source. This ensures that whenever a new host is provisioned in Satellite, it is automatically known to Ansible Tower, enabling the immediate execution of post-provisioning playbooks.
Networking and Performance Requirements
For this integration to function, the Satellite Server and Ansible Tower must reside on the same network or subnet. Furthermore, there are significant performance considerations regarding user permissions. In large-scale deployments (managing tens of thousands of hosts), using a non-admin user for the API connection can introduce significant time penalties due to the overhead of authorization checks. In such cases, an admin user is recommended to optimize performance.
For non-admin users, the Ansible Tower Inventory Reader role must be explicitly assigned to the Satellite Server user to grant the necessary permissions for inventory synchronization.
Integration Workflow
To establish the connection, the following steps are required within the Ansible Tower web UI:
- Create a credential specifically for the Satellite Server.
- Associate an Ansible Tower user with that credential.
- Configure an inventory source that points to the Satellite Server API.
This setup allows the provisioning callback function to trigger playbook runs immediately following the Kickstart deployment. The flow is as follows: Satellite provisions the host $\rightarrow$ Host is registered $\rightarrow$ Satellite triggers a callback to Ansible Tower $\rightarrow$ Ansible Tower executes the configuration playbook.
Conclusion
The integration of Ansible into Red Hat Satellite transforms the platform from a simple software repository and patching tool into a comprehensive orchestration engine. By deploying the redhat.satellite collection, enabling the foreman-proxy-plugin-ansible on Capsules, and implementing a strict version-controlled role directory at /etc/ansible/roles, organizations can achieve a high degree of operational maturity. The ability to utilize RHEL System Roles and manage complex variable precedence through the Satellite UI ensures that the infrastructure remains consistent, scalable, and reproducible. Whether through direct execution via the Satellite UI or dynamic inventory integration with Ansible Tower, this architecture provides the necessary tools to manage the entire lifecycle of a RHEL asset from the initial boot to its final decommission.