The landscape of IT automation underwent a seismic shift with the introduction of Ansible 5, marking a departure from the monolithic distribution models of the past. This transition was not merely a version increment but a fundamental reorganization of how the Ansible project releases and distributes its software. At the heart of this evolution is the decoupling of the execution engine from the content it manages, moving away from the legacy "ansible classic" or 2.9.x paradigms toward a streamlined, modular architecture. This strategic shift was necessitated by the inherent limitations of a monolithic package, where the sheer volume of code and the diversity of subject matter expertise required to maintain it created a bottleneck. In the previous model, small changes were forced to wait for major release cycles, and the lack of dedicated subject matter reviewers for specific modules slowed the velocity of innovation. By splitting the engine from the content, the project empowered community-driven collections to evolve at their own pace, ensuring that the tooling remains agile and responsive to the rapidly changing infrastructure landscape.
The Structural Decomposition of Ansible 5
The transition to Ansible 5 introduces a tiered installation strategy that separates the core runtime from the operational content. This architectural decision allows for greater flexibility and reduces the footprint of the installation for users who do not require the full suite of community collections.
The Role of ansible-core
The ansible-core package serves as the engine of the entire automation framework. It contains the essential programming language, the architectural framework, and the primary tooling required to execute playbooks. In the context of Fedora Linux, ansible-core was already introduced in version 35+, laying the groundwork for the full Ansible 5 transition.
The technical purpose of isolating the engine is to ensure that the core logic of the tool—how it connects to nodes, how it parses YAML, and how it manages task execution—can be updated independently of the thousands of modules used to interact with specific hardware or software. For the user, this means a more stable foundation where the core runtime is optimized for performance and security without being bogged down by the legacy requirements of a specific cloud provider's module.
The Unified ansible Package
To maintain a user experience consistent with the Python Package Index (PyPi) installation method, Fedora provides a comprehensive ansible package. This package does not contain the engine itself but instead acts as a dependency wrapper. When a user installs the ansible package, it triggers the installation of ansible-core and pulls in a curated set of collections that mirror the official upstream releases.
This creates a dual-track installation path for users based on their specific operational needs:
| Installation Path | Component Included | Target Use Case |
|---|---|---|
ansible package |
ansible-core + Curated Collections |
Users desiring a complete, "out-of-the-box" experience similar to PyPi. |
ansible-core only |
Engine only | Minimalist environments where no external collections are required. |
ansible-core + Manual |
Engine + Specific Collections | Advanced users who install targeted collections via Fedora packages or Ansible Galaxy. |
Integration and Deployment Dynamics
The migration to Ansible 5 involves significant changes in how the software is managed within the operating system, particularly concerning dependencies and versioning.
Versioning and Semantic Shifts
Ansible follows semantic versioning rules, which dictate that incompatible changes are only introduced between major versions. However, the jump from the 2.9.x "classic" era to Ansible 5 represents a gap of several major versions. This gap means that while the ansible-core runtime is effectively updated from version 2.9 to 2.12, the behavioral changes can be substantial.
The impact of this version jump is most visible in the execution of legacy playbooks. While the goal is for playbooks to continue running as before, the shift in the runtime engine means that certain behaviors may deviate. Users are required to utilize porting guides provided by the Ansible project to identify and remediate deprecated features or changed module behaviors.
Package Conflict and Management
Because Ansible 5 moves toward a modular collection model, there is a potential for conflicts between the curated collections shipped in the ansible package and collections installed independently. Users have the flexibility to remove the release collections entirely if they prefer to manage their own dependencies via ansible-galaxy or separate Fedora packages. This flexibility ensures that the system administrator has absolute control over the exact version of a module being used to manage a production environment.
The Ecosystem of Ansible Collections
The shift to Ansible 5 is defined by the rise of Collections. A collection is a distribution format that bundles Ansible modules, roles, plugins, and other related content. This allows specific communities to maintain their own codebases and release updates without waiting for the core engine's release cycle.
Specialized Functional Collections
The Ansible ecosystem provides highly specialized collections tailored to specific technology stacks. This allows the automation of complex environments with a level of precision that a monolithic package could not provide.
- kubernetes.core: This collection focuses on the automation of Kubernetes and OpenShift clusters. It enables the provisioning and maintenance of clusters as well as the sophisticated management of containerized applications.
- community.vmware: This is the primary toolset for managing VMware infrastructure. It provides the necessary modules to handle vSphere, Datacenters, Clusters, and individual Virtual Machines.
- middleware_automation: This collection is designed for multi-cloud application infrastructure at scale. It specifically targets the automation of Kafka, WildFly, Infinispan, and Keycloak.
The Role of Ansible Galaxy
Ansible Galaxy serves as the central hub for these collections. It allows users to jump-start their automation by downloading pre-packaged roles and collections created by the community or vendors. By integrating Galaxy with ansible-core, users can extend the functionality of their automation engine on demand, rather than relying on a static set of modules shipped with the OS.
Enterprise Application and Management
While the open-source project provides the engine and collections, the application of these tools in a corporate environment often requires additional layers of security, stability, and support.
Red Hat Ansible Automation Platform
The Red Hat Ansible Automation Platform is the enterprise-grade manifestation of the upstream projects. It combines more than a dozen upstream projects into a unified, security-hardened platform. This platform is designed for mission-critical automation, providing a bridge between the open-source flexibility of ansible-core and the requirements of a corporate IT department.
Key enhancements in the enterprise platform include: - Event-Driven Ansible: The ability to subscribe to event sources, allowing the system to react to infrastructure changes in real-time, thereby increasing operational efficiency. - Generative AI Integration: The use of AI to reduce manual effort in creating automation and managing IT processes. - Policy as Code: The implementation of automated compliance and policy enforcement across the entire operational lifecycle, ensuring that infrastructure remains consistent and compliant with legal or corporate standards.
SUSE Manager Integration
Ansible is also integrated into the SUSE ecosystem through SUSE Manager, which supports the management of Ansible control nodes. This integration allows system administrators to leverage SUSE Manager for the following operations: - Inspection of inventory files: Managing the sorted list of nodes that Ansible is tasked to control. - Discovery of playbooks: Identifying the YAML descriptions of the desired state of the inventory. - Execution of playbooks: Triggering the automation process to apply configurations to the managed nodes.
In the SUSE environment, the supported version of Ansible has historically been 2.9 (LTS), shipped via SUSE Linux Enterprise 15 Client Tools. The control node is supported on SUSE Linux Enterprise Server 15 SP3 or later, ensuring a stable environment for the execution of automation tasks.
Technical Transition and Contingency
The move to Ansible 5 within Fedora is a strategic alignment with the upstream project's distribution model. The transition involves replacing the ansible-2.9.x package with a combination of ansible-core and the relevant release collections.
Implementation Details
The transition is tracked via FESCo issue #2681 and tracker bug #2019517. The target for this implementation was Fedora Linux 36, with updates finalized around November 2021. Because this is not a "System Wide Change" in the traditional sense, it does not block the overall release of the operating system, but it does fundamentally alter the toolchain for developers and sysadmins.
Contingency Planning
The primary contingency plan for this transition was the continued shipping of "ansible classic." However, this was viewed as a temporary measure because the classic version would eventually reach End-of-Life (EOL), making security updates and bug fixes significantly harder to implement. The move to the ansible-core + collections model is the only sustainable path forward for the distribution.
Conclusion
The evolution of Ansible 5 represents a maturation of the automation philosophy. By decomposing the monolithic structure of Ansible 2.9, the project has solved the problem of "release velocity." The separation of the ansible-core engine from the collections allows for a symbiotic relationship where the engine can remain stable and lean, while the collections can evolve rapidly to keep pace with the newest cloud APIs and hardware specifications. For the user, this results in a more flexible installation process, the ability to use highly specialized modules via Ansible Galaxy, and a clear path toward enterprise-grade automation through the Red Hat Ansible Automation Platform. The shift emphasizes a move toward "Policy as Code" and event-driven operations, ensuring that modern IT infrastructure is not just automated, but intelligently orchestrated.