The integration of Red Hat Satellite and Ansible represents a paradigm shift in infrastructure management, transitioning from static image deployment to dynamic, policy-driven configuration management. At its core, Red Hat Satellite serves as the centralized hub for patch management, provisioning, and asset tracking, while Ansible provides the execution engine capable of translating high-level business requirements into granular system states. By embedding Ansible directly into the Satellite ecosystem, administrators can automate repetitive tasks, ensure configuration consistency across thousands of nodes, and bridge the gap between initial provisioning and long-term lifecycle management. This synergy allows for the orchestration of complex workflows, such as the application of RHEL System Roles, the management of remote execution jobs via Capsules, and the seamless integration with Ansible Automation Platform (formerly Tower) for advanced orchestration.
The Infrastructure of Satellite-Ansible Integration
To operationalize Ansible within a Red Hat Satellite environment, a specific architectural configuration must be established. Ansible is enabled by default on the Satellite server, but for distributed environments utilizing Capsules, additional configuration is required to ensure that automation commands can be propagated from the central server to the remote edge.
The primary mechanism for role distribution involves the /etc/ansible/roles directory. This directory acts as the local repository for all Ansible roles that the Satellite server or its associated Capsules intend to execute. When scaling an environment, the synchronization of these roles across multiple Capsules becomes critical. To maintain consistency, administrators must configure an external version control system (VCS), such as Git, to synchronize roles between the primary Satellite server and the Capsules. This ensures that a role update pushed to the central repository is reflected across all execution points in the infrastructure.
For Capsules to actively run Ansible roles on managed hosts, the specific Ansible plug-in must be enabled. This is achieved through the satellite-installer command. The specific execution string required is:
# satellite-installer --scenario capsule \ --enable-foreman-proxy-plugin-ansible
This command modifies the Capsule's behavior, allowing it to act as an Ansible execution proxy. Without this plug-in, the Capsule cannot facilitate the communication between the Satellite server's orchestration logic and the target host's SSH daemon.
Furthermore, the connectivity layer relies on the distribution of SSH keys. Because Ansible is agentless and relies on SSH for transport, the Capsules must possess the necessary credentials to authenticate with the target hosts. This process is integrated into the "Managing Hosts" workflow, where SSH keys are distributed to enable remote execution. Once the keys are in place and the plug-in is enabled, Satellite treats Ansible roles as remote execution jobs, utilizing the same scheduling and reporting frameworks as standard remote scripts.
Importing and Managing Ansible Roles
The ability to import roles is what transforms Satellite from a simple patch manager into a powerful configuration orchestrator. Roles can be imported from the /etc/ansible/roles directory on either the Satellite server or an enabled Capsule.
Leveraging RHEL System Roles
Red Hat provides a set of standardized, tested, and supported roles known as RHEL System Roles. These roles simplify the configuration of common system services, such as networking, storage, and time synchronization. To utilize these roles within Satellite, the following technical workflow must be followed:
First, the appropriate repository must be enabled to provide the roles. For RHEL 7, the rhel-7-server-extras-rpms repository is required. This is enabled via the subscription manager:
# subscription-manager repos --enable=rhel-7-server-extras-rpms
Once the repository is active, the rhel-system-roles package must be installed using the satellite-maintain tool:
# satellite-maintain packages install rhel-system-roles
The installation process places the roles in the /usr/share/ansible/roles/ directory. This location allows administrators to inspect or modify the roles before they are imported into the Satellite web UI. The import process is then completed through the following steps:
- Navigate to Configure > Roles in the Satellite web UI.
- Select the specific Capsule that contains the roles.
- Check the boxes for the desired roles.
- Click Update.
Once imported, these roles are available for assignment to hosts or host groups, enabling rapid deployment of standardized configurations across the fleet.
Variable Management and Precedence in Satellite
A critical component of Ansible's flexibility is the use of variables. Satellite allows administrators to define and override these variables through its web interface, providing a layer of abstraction that allows the same role to behave differently on different hosts.
Creating Ansible Variables
To define a variable within Satellite, the administrator follows a specific path in the UI:
- Navigate to Configure > Variables.
- Select New Ansible Variable.
- Enter a name in the Key field that references the specific Ansible role name.
- Provide a description for administrative clarity.
- Select the associated Ansible role from the list.
- Submit the configuration.
This process allows the creation of "Host Parameters," which are essential when using Ansible job templates. Without a corresponding Host Parameter, the parameter variables required by the playbook cannot be correctly associated with the host.
The Logic of Variable Precedence
When a task is executed as a user other than the Effective User, a strict order of precedence applies to how variables are resolved. Satellite allows for the overriding of Ansible variables, but this override must align with the standard Ansible variable precedence hierarchy. This ensures that the most specific variable (e.g., a host-specific override) takes priority over a general group variable or a role default. Users must refer to the Ansible User Guide's section on "Variable precedence: Where should I put a variable?" to ensure that the overrides configured in Satellite achieve the intended effect.
Executing Ansible Roles and Remote Management
Once the infrastructure is configured, roles are imported, and variables are set, the actual execution of automation occurs through the Satellite web UI. This capability is compatible with Red Hat Enterprise Linux versions 8, 7, and 6.9 or later.
The execution workflow is as follows:
- Navigate to Hosts > All Hosts.
- Select the target host(s) that have been assigned the required Ansible roles.
- Select Play Ansible roles from the Select Action menu.
Upon execution, the "Run Ansible roles" page provides real-time status updates. If a job fails or requires a repeat, the Rerun button is available. This provides a centralized auditing mechanism, where the success or failure of a configuration change is logged and visible to the administrator.
Integration with Ansible Automation Platform (Tower)
For organizations requiring advanced orchestration, Satellite can be integrated with Ansible Tower (now part of the Ansible Automation Platform). This is particularly useful during the provisioning phase. Using the provisioning callback function, Satellite can trigger a playbook run in Tower immediately following a Kickstart deployment.
Configuring Dynamic Inventory
To enable this, Satellite must be added to Ansible Tower as a dynamic inventory item. This requires a specific security and network configuration:
- Network Requirements: Satellite Server and Ansible Tower must reside on the same network or subnet to ensure low-latency communication and firewall traversal.
- Credential Management: A credential for a Satellite Server user must be created within the Tower UI.
- Role Assignment: For non-admin users, the
Ansible Tower Inventory Readerrole must be assigned to the Satellite user to grant the necessary permissions for inventory synchronization. - Performance Optimization: In large-scale deployments (tens of thousands of hosts), it is recommended to use an admin user. Non-admin users may introduce performance bottlenecks due to the time penalties associated with repeated authorization checks during large inventory polls.
The redhat.satellite Ansible Collection
Beyond the built-in role execution in the Satellite UI, Red Hat provides the redhat.satellite collection. This collection consists of Ansible modules designed specifically for interacting with the Satellite API, allowing users to manage Satellite itself using Ansible playbooks.
Installation and Versioning
The collection is distributed through the Ansible Galaxy CLI and the Satellite repository. It is critical to note that the GitHub repository is for source tracking and should not be used for direct installation.
To install the collection:
ansible-galaxy collection install redhat.satellite
To install a specific version, such as version 1.0.0:
ansible-galaxy collection install redhat.satellite:==1.0.0
To upgrade to the latest version:
ansible-galaxy collection install redhat.satellite --upgrade
Alternatively, the collection can be managed via a requirements.yml file:
yaml
collections:
- name: redhat.satellite
This is then installed using:
ansible-galaxy collection install -r requirements.yml
The collection is also provided as an RPM package named ansible-collection-redhat-satellite within the Satellite repository.
Technical Specifications and Support
The redhat.satellite collection is a downstream derivative of the theforeman.foreman community collection. It is engineered to be compatible with all currently maintained Ansible versions and all Python versions supported by Ansible on the target node.
| Feature | Detail |
|---|---|
| Base Collection | theforeman.foreman |
| License | GNU GPL v3 |
| Support Path | Ansible Automation Platform (AAP) / Red Hat Support |
| Community Path | Ansible Forum |
| Supported Products | 2.4, 2.5, 2.6 |
As Red Hat Ansible Certified Content, users who obtain the collection through official channels are entitled to professional support via the AAP "Create issue" mechanism.
Conclusion
The integration of Ansible within Red Hat Satellite transforms the management of the data center from a manual, error-prone process into a scalable, code-driven operation. By utilizing the satellite-installer to enable Capsule plug-ins, leveraging the rhel-system-roles for standardized configurations, and employing the redhat.satellite collection for API-driven management, organizations can achieve a high degree of operational maturity. The ability to manage variables through the Satellite UI while respecting Ansible's precedence rules allows for a flexible yet controlled environment. When combined with Ansible Tower's dynamic inventory and provisioning callbacks, the result is a seamless pipeline from the first boot of a server to its final, fully configured state in the production environment.