The convergence of Red Hat Satellite and Ansible represents a paradigm shift in infrastructure management, moving from static asset tracking to dynamic, desired-state configuration. Red Hat Satellite, serving as the central hub for content management and patch orchestration, integrates with Ansible to provide a powerful, agentless automation framework. Unlike traditional configuration management tools such as Puppet—which requires the installation of a client-side agent and registration with a Puppet master running on the Satellite or Capsule—Ansible operates on a remote execution model. This fundamental architectural difference eliminates the overhead of agent maintenance, relying instead on secure shell (SSH) connectivity to push configurations to target nodes.
In a modern enterprise environment, the integration of these two technologies allows administrators to leverage the Satellite API for inventory management while utilizing Ansible for the actual execution of system changes. This synergy enables a "single pane of glass" approach where the Satellite Server 6 (and its upstream project, Katello) manages the lifecycle of registered client hosts, and Ansible ensures those hosts adhere to specific security baselines and application requirements. The result is a streamlined pipeline where a host is registered, categorized into a host group within Satellite, and subsequently managed via Ansible roles and playbooks without the need for manual intervention on the target system.
The Architectural Foundation of Agentless Execution
The primary distinction between Ansible's integration with Red Hat Satellite and other orchestration tools is the reliance on remote execution via SSH. In the context of Red Hat Network Satellite 6, this means the Satellite server or a designated Capsule server acts as the control node.
The technical requirement for this operation is the enablement and configuration of the Ansible plugin and remote execution settings on the Satellite and any utilized Capsules. Because Ansible does not require a resident agent on the client side, the attack surface is reduced, and the deployment complexity is lowered. The only prerequisite for a client host to be manageable via this method is that it must already be registered to the Red Hat Network Satellite Server 6 or Katello.
From a technical layer, the remote execution process involves the control node establishing a secure connection to the client, transferring small modules (code) to the target, and executing them via the Python interpreter. The impact for the user is a significant reduction in "bootstrapping" time; as soon as a host is registered to Satellite, it is immediately available for Ansible automation, provided SSH access is configured. This creates a seamless transition from the provisioning phase to the configuration management phase of the server lifecycle.
Comprehensive Installation of the Red Hat Satellite Ansible Collection
To interact with the Satellite API and manage the environment programmatically, administrators must utilize the redhat.satellite Ansible collection. This collection provides the necessary modules to translate Ansible tasks into API calls that the Satellite server understands.
The collection is developed as Red Hat Ansible Certified Content and is based on the theforeman.foreman community collection for Foreman and Katello. This lineage ensures that the modules are robust and tested against a wide array of community use cases before being hardened for enterprise support via the Ansible Automation Platform (AAP).
Installation Methodologies
Depending on the environment's constraints, the collection can be installed through several vectors.
- Using the Ansible Galaxy CLI
The most common method for installation is via the Galaxy command-line tool. To install the latest version, the following command is used:
ansible-galaxy collection install redhat.satellite
- Version-Specific Installation
In environments where stability is prioritized over new features, installing a specific version (such as 1.0.0) is critical to prevent unexpected breaking changes. The syntax for this is:
ansible-galaxy collection install redhat.satellite:==1.0.0
- Requirements File Integration
For DevOps pipelines and Infrastructure as Code (IaC) setups, the collection should be defined in a requirements.yml file to ensure environment parity. The file format is:
yaml
collections:
- name: redhat.satellite
This file is then processed using the following command:
ansible-galaxy collection install -r requirements.yml
- Upgrade Procedures
To move to the most recent version of the collection, the upgrade flag is utilized:
ansible-galaxy collection install redhat.satellite --upgrade
- RPM and Repository Distribution
For air-gapped environments or those preferring native package management, the collection is available as ansible-collection-redhat-satellite within the official Satellite repository.
The technical impact of these installation methods is that the control node gains the ability to query the Satellite API for host lists, organizational units, and content views, which can then be used as dynamic inputs for Ansible playbooks.
Configuring the Ansible Automation Platform (AAP) with Satellite
Integrating the Ansible Automation Platform with Red Hat Satellite involves setting up a control node—typically a RHEL 9 system—that can orchestrate tasks across the fleet of managed hosts.
System Requirements and Prerequisites
Before execution begins, the following technical requirements must be met:
- A RHEL 9 system to serve as the Ansible control node.
- Verified SSH access to all managed hosts.
- Python 3 installed on all managed hosts (which is provided by default in RHEL 9).
Step-by-Step Configuration Sequence
The process of establishing the automation pipeline follows a logical progression from tool installation to verification.
- Installing the Core Engine
The installation begins with the deployment of the core Ansible package:
sudo dnf install -y ansible-core
Verification of the installation is performed using:
ansible --version
- Inventory Management
The control node requires a map of the infrastructure. This is achieved by creating a hosts file, such as /etc/ansible/hosts or a local inventory.ini. An example structure is:
```ini
[webservers]
web1.example.com
web2.example.com
[dbservers]
db1.example.com
```
- Connectivity Testing
Before deploying complex playbooks, the connectivity must be validated using the ping module:
ansible all -i inventory.ini -m ping
- Playbook Development
The administration of RHEL hosts is performed through YAML playbooks. A standard administration playbook might look as follows:
```yaml
- name: Example RHEL Administration Playbook
hosts: all
become: true
tasks:- name: Ensure packages are installed
ansible.builtin.dnf:
name:
- vim
- tmux
- htop
state: present - name: Ensure services are running
ansible.builtin.systemd:
name: sshd
state: started
enabled: true
```
- name: Ensure packages are installed
- Execution and Validation
The playbook is executed via the command line:
ansible-playbook -i inventory.ini playbook.yml
To prevent accidental changes, a dry run can be performed using the --check flag:
ansible-playbook -i inventory.ini playbook.yml --check
Finally, the results are verified using a direct command module:
ansible all -i inventory.ini -m command -a "rpm -q htop"
Managing Red Hat Satellite via the Web User Interface
While the command line provides power and flexibility, the Red Hat Satellite web UI allows for the intuitive assignment and execution of Ansible roles. This is particularly useful for administrators who want to associate specific configurations with logical groups of servers.
Assigning Ansible Roles to Host Groups
The Satellite UI allows for the mapping of roles to host groups, ensuring that any host added to a specific group automatically inherits the required configuration.
- Navigation: Navigate to Configure > Host Groups.
- Selection: Click on the specific host group name.
- Role Assignment: Select the Ansible Roles tab. In the All items list, search for the desired roles.
- Finalization: Move the selected roles to the Selected items list using the arrow icon and click Submit.
Executing Roles via the UI
Once roles are assigned, they can be triggered directly from the management console.
- Execution Path: In the Host Groups list, locate the Actions column for the desired group.
- Action: Select Run all Ansible roles.
- Monitoring: The status and logs of the job can be monitored on the Run Ansible roles page. If a job fails or requires a retry, the Rerun button is available to restart the process.
The technical layer here is the Satellite server initiating a call to the Ansible engine, which then targets the hosts associated with that group. The impact is a significant reduction in manual labor, as configuration updates can be pushed to hundreds of servers with a few clicks in the UI.
Technical Specifications and Compatibility Matrix
The redhat.satellite collection is engineered for broad compatibility across the Red Hat ecosystem. It is tested against all currently maintained Ansible versions and all supported Python versions on the target nodes.
| Feature | Specification |
|---|---|
| Licensing | GNU GPL v3 |
| Base Collection | theforeman.foreman |
| Target OS Support | RHEL 6.9, 7, 8, and 9 |
| Control Node OS | RHEL 9 (Recommended) |
| Support Channel | Ansible Automation Platform (AAP) |
| Distribution Channel | Automation Hub, RPMs, Galaxy |
Conclusion: Analysis of the Integrated Automation Ecosystem
The integration of Red Hat Satellite and Ansible transforms the Satellite server from a mere repository of software and a record of host statuses into a proactive orchestration engine. The shift from an agent-based model (Puppet) to an agentless model (Ansible) is the critical evolution in this ecosystem. By removing the need for client-side agent installation, Red Hat has eliminated the "chicken and egg" problem where an agent must be installed before a system can be managed.
The technical synergy is most evident in the use of the redhat.satellite collection. By utilizing the Satellite API, Ansible can dynamically discover targets, meaning the inventory is always an accurate reflection of the actual state of the data center. The ability to trigger these roles through the Satellite Web UI further democratizes the automation process, allowing operators who may not be fluent in YAML to still leverage the power of Ansible playbooks.
Ultimately, the combination of RHEL 9 as a control node, the redhat.satellite collection for API interaction, and the Satellite UI for organizational management creates a robust, enterprise-grade framework. This setup ensures that the desired state of the infrastructure is not only documented in the Satellite database but is actively enforced across the network, resulting in higher security compliance and operational efficiency.