The intersection of Foreman and Ansible represents a powerful convergence of lifecycle management and configuration automation. By integrating these two systems, organizations can transition from simple server provisioning to a state of continuous infrastructure orchestration. Foreman provides the authoritative source of truth for assets, while Ansible provides the execution engine to maintain the desired state of those assets. This integration is facilitated primarily through the Foreman Ansible plugin, a suite of dedicated Ansible modules, and specialized roles that allow for the programmatic deployment and management of the Foreman ecosystem itself.
The synergy between these tools is designed to solve the "last mile" problem of infrastructure deployment. While Foreman can provision a virtual machine or a bare-metal server, the subsequent configuration—installing packages, managing users, and hardening the OS—is where Ansible excels. By leveraging the Foreman Ansible plugin, administrators can import hosts, synchronize facts, and execute playbooks directly from the Foreman console, effectively treating Ansible as a native remote execution engine. This creates a closed-loop system where the state of the hardware is reported back to the management console, allowing for auditing and compliance reporting in real-time.
The Foreman Ansible Plugin Architecture and Functionality
The Foreman Ansible plugin serves as the connective tissue between the Foreman management server and the Ansible execution framework. It allows for the ingestion of host data, the execution of playbooks, and the reporting of results back into the Foreman database.
Core Capabilities and Host Integration
The plugin allows administrators to import hosts via Ansible. This process is not merely about adding a name to a database; it involves the transmission of comprehensive facts about the hosts and detailed reports regarding the outcome of playbook runs. This ensures that the Foreman inventory remains an accurate reflection of the actual state of the infrastructure.
The plugin 2.x series maintains a broad compatibility range, supporting any version of Foreman above 1.17, including version 1.17 itself. This ensures that organizations running older, stable versions of the management platform can still leverage modern Ansible automation.
Data Ingestion and the Callback Mechanism
To facilitate the movement of data from the managed nodes back to the central server, Foreman utilizes a callback mechanism. When a playbook is executed on a host, the callback ensures that facts and reports are sent to Foreman.
The technical implementation of this data flow depends on where the execution originates:
- Execution from Foreman: When a playbook is triggered directly from the Foreman interface, the output of the run is automatically captured and saved within the Foreman database.
- Execution from External Hosts: To send data from a host that is running Ansible independently, a specific callback must be configured on that host.
Trusted Hosts and Security Constraints
Security in the Foreman-Ansible ecosystem is managed through a "trusted hosts" configuration. This is critical for preventing unauthorized data injection into the Foreman server.
- Smart Proxy Authentication: Smart proxies are typically authenticated via certificates located in
/etc/foreman-proxy/. Because of this certificate-based trust, it is not necessary to add Smart Proxies to thetrusted_hostssetting. - External Execution Hosts: If an administrator is running Ansible from a specific host (Host A) to manage another host (Host B), Host A must be added to the
trusted_hostslist. This configuration is managed under Administer > Settings in the Auth tab.
Automated Host Creation and Fact Synchronization
The integration supports the automatic growth of the infrastructure inventory through two key settings:
- create_new_host_when_facts_are_uploaded: When this setting (found in the Puppet tab) is enabled, Foreman will automatically create a new host entry if the $HOSTNAME provided by the Ansible callback does not already exist in the system. If the host does exist, Foreman simply updates the existing facts.
- ignore_puppet_facts_for_provisioning: When this is set to false (found in the Provisioning tab), facts related to network interfaces will automatically update the corresponding interface data for the $HOSTNAME within Foreman.
Deployment and Configuration of the Ansible Plugin
Configuring a Foreman deployment to utilize Ansible requires a coordinated setup across the main Foreman server and the associated Smart Proxies. This ensures that the execution environment is consistent regardless of which proxy is handling the request.
Installation Procedures
The installation is performed using the foreman-installer tool. To enable the necessary plugins on the main server, the following command is executed:
# foreman-installer --enable-foreman-plugin-ansible --enable-foreman-proxy-plugin-ansible
For the system to function as a complete automation hub, Remote Execution must also be enabled to allow the server to communicate with the hosts:
# foreman-installer --enable-foreman-plugin-remote-execution --enable-foreman-proxy-plugin-remote-execution-ssh
Smart Proxy Configuration
Since Foreman utilizes a distributed architecture, the Ansible plugin must be enabled on every Smart Proxy intended to run Ansible roles. This is achieved by disabling the main Foreman server components on the proxy while enabling the proxy-specific plugin:
# foreman-installer --no-enable-foreman --enable-foreman-proxy-plugin-ansible
Role Distribution and Management
Ansible roles are the primary building blocks for automation in this ecosystem. They must be placed in the /etc/ansible/roles directory on both the Foreman server and all relevant Smart Proxies.
To maintain consistency across a large-scale deployment, administrators are advised to use an external version control system (such as Git) to synchronize these roles. This prevents "configuration drift" where different Smart Proxies might be using different versions of the same role.
Connectivity and Execution
Remote execution relies on SSH connectivity. Smart Proxies must have their SSH keys distributed to the target hosts to ensure non-interactive access. Once the keys are in place and the roles are imported into Foreman, they can be managed via the Configure menu in the main interface.
Foreman Ansible Modules and API Interaction
Beyond using Ansible to configure servers, there are dedicated Ansible modules designed to configure and manage the Foreman server itself. These modules interact with the Foreman API and associated plugin APIs, such as Katello.
Module Support and Compatibility
The modules are designed to support any currently stable release of Foreman and its matching plugins. Because different plugins add different API endpoints, some modules contain specific arguments that only function when the corresponding plugin is installed.
The technical requirements for these modules are as follows:
- Ansible Versions: Support is aligned with Ansible versions 2.8 and higher, which support the Collections architecture.
- Python Versions: Starting with Ansible 2.7, the modules are developed and tested against Python 2.7 and Python 3.5 (and higher).
Installation Methods
The modules are distributed as part of a collection, which can be installed via two primary methods:
- Ansible Galaxy: The standard method for installing community collections.
- RPM Installation: For environments requiring binary packages, the collection is available as ansible-collection-theforeman-foreman via the yum.theforeman.org client repository.
Performance Considerations and Known Issues
Certain modules, specifically repository_sync and content_view_version, trigger processes on the server side that can take a significant amount of time to complete. By default, these modules wait unconditionally for the task to finish. To avoid playbook timeouts or bottlenecks, it is recommended to use Ansible's asynchronous facilities to put these tasks in the background.
Programmatic Installation of Foreman via Ansible
For those seeking to deploy a fresh instance of Foreman using Ansible, specialized roles exist to automate the entire installation process.
OS and Database Compatibility
The installation roles have been tested across a variety of environments, including:
- Red Hat Enterprise Linux 7 and CentOS 7.
- Ubuntu 16.04 (Xenial) and 18.04 (Bionic).
- Debian 9.
Regarding database support, both PostgreSQL and MySQL are supported for all the aforementioned operating systems, with the exception of Debian, which has specific constraints.
Critical Installation Requirements
A fundamental requirement for a successful Foreman installation is the hostname configuration. Foreman requires the hostname to be a Fully Qualified Domain Name (FQDN). This can be managed in two ways:
- Using the Ansible hostname module to set the FQDN.
- Using the role variable foreman_hostname (e.g., foreman_hostname: foreman.vagrantup.com).
Configuration Variables and Defaults
The installation role provides several variables to customize the deployment. These are typically defined in defaults/main.yml.
| Variable | Default Value | Description |
|---|---|---|
| disable_puppet | true | Disables the Puppet master that is included in the all-in-one installation |
| foremanserverurl | (Env Var) | The URL of the server; defaults to FOREMAN_SERVER_URL environment variable |
| foreman_username | (Env Var) | The API user; defaults to FOREMAN_USERNAME environment variable |
| foreman_password | (Env Var) | The API password; defaults to FOREMAN_PASSWORD environment variable |
| foremanvalidatecerts | (Env Var) | Controls TLS verification; defaults to FOREMAN_VALIDATE_CERTS environment variable |
| foreman_organization | (Custom) | The specific organization where the configuration will be applied |
Upon successful installation, the server is accessible via https://foreman_fqdn using the default credentials:
- User: admin
- Password: password
Advanced Configuration and Parameter Management
The flexibility of the Foreman-Ansible integration is most evident in how it handles parameters and variables across different levels of the infrastructure.
Hierarchical Parameterization
Foreman allows administrators to define Ansible configuration options (such as ansible_user and ansible_become) through a tiered approach. This allows for global standards while permitting specific overrides for certain groups of hosts.
- Global Parameters: These apply to all hosts across the entire infrastructure.
- Host Group Parameters: These apply to specific logical groupings of hosts (e.g., "Web Servers" or "Database Servers").
- Host Parameters: These are specific to an individual single machine, overriding both group and global settings.
Integration with Dynamic Inventories
To avoid the manual maintenance of static inventory files, users can employ Ansible's dynamic inventory feature. By configuring the inventory to point to Foreman, Ansible can query the Foreman API in real-time to retrieve a list of hosts. This ensures that any host property or parameter defined within Foreman is available as an Ansible variable during the playbook execution, enabling highly dynamic and scalable automation workflows.
Comparison of Installation and Execution Paths
The following table delineates the different ways Ansible interacts with Foreman based on the intended goal.
| Goal | Method | Component Required | Key Command/Config |
|---|---|---|---|
| Install Foreman | Ansible Role | ansible-role-foreman |
foreman_hostname variable |
| Install Plugin | foreman-installer |
Foreman Server/Proxy | --enable-foreman-plugin-ansible |
| Run Playbooks | Job Templates | Remote Execution | --enable-foreman-plugin-remote-execution |
| Manage Foreman | Ansible Modules | theforeman.foreman collection |
foreman_server_url |
| Report Facts | Callback Plugin | Ansible Host | trusted_hosts setting |
Conclusion
The integration of Ansible into the Foreman ecosystem transforms a static asset management tool into a dynamic orchestration platform. By implementing the Foreman Ansible plugin, administrators gain the ability to not only track their hardware and software but to actively enforce the desired state of their entire environment. The use of the foreman-installer ensures that the plugin and remote execution capabilities are properly deployed across both the central server and the distributed Smart Proxies.
From a technical perspective, the reliance on the callback mechanism and the trusted_hosts configuration ensures that the flow of data is both automated and secure. The ability to utilize dynamic inventories means that the "source of truth" remains centralized in Foreman, while the "execution of intent" is handled by Ansible. Furthermore, the availability of dedicated Ansible modules and roles allows for the lifecycle of the Foreman server itself to be managed as code, reducing the risk of manual configuration errors during deployment.
For the enterprise, this architecture provides a scalable path toward Infrastructure as Code (IaC). By combining the hierarchical parameterization of Foreman with the idempotent nature of Ansible, organizations can achieve a level of consistency where the difference between the documented state and the actual state of the server is virtually zero. The system's compatibility with a wide range of Linux distributions and Python versions ensures that it can be integrated into most existing data center environments, provided the strict FQDN and SSH key requirements are met.