Overview

Red Hat made Ansible Engine 2.6 generally available on July 17, 2018. The release focuses on three areas: deeper multicloud and hybrid cloud automation, expanded network automation with vendor-agnostic modules, and a major refresh of the Ansible Galaxy community content hub. Together these changes aim to reduce the manual overhead involved in managing infrastructure spread across on-premises data centers, AWS, Azure, and VMware-based clouds.

Red Hat acquired Ansible in October 2015 and has continued to ship regular Engine releases since then, progressively broadening the platform’s integration surface.

Multicloud and Hybrid Cloud Enhancements

A headline change in 2.6 is the ability to pull native facts directly from a wider set of AWS and Azure cloud services. Previous releases could interact with services such as AWS RDS or Azure generic resources, but doing so required users to write extra tasks to collect and normalise the returned data. Ansible Engine 2.6 surfaces this information through dedicated fact modules, reducing playbook complexity.

According to Justin Nemmers, General Manager of Ansible at Red Hat:

“One of the highlights is the ability to pull native facts from additional AWS and Azure cloud services.”

VMware Support

Ansible Engine 2.6 also deepens VMware integration. Between the 2.5 and 2.6 releases, Red Hat added 26 new VMware modules covering areas such as:

• Tag management and fact gathering for VMware objects
• Deployment and lifecycle management of virtual machines
• Network and configuration management within VMware-based infrastructure
• Seamless automation of VMware Cloud on AWS, allowing teams to manage both on-premises vSphere and cloud-hosted VMware infrastructure from a single set of playbooks

This is particularly relevant for organisations running hybrid environments where workloads span on-premises VMware clusters and public cloud services simultaneously.

Network Automation

Network automation has become a core pillar of the Ansible platform. Engine 2.6 ships supported integrations with the following vendors and operating systems:

• Arista – EOS
• Cisco – IOS, IOS XR, NX-OS
• Juniper – JunOS
• Open vSwitch
• VyOS

These integrations are delivered through vendor-agnostic modules that share a common declarative language. Rather than requiring engineers to learn device-specific CLI syntax for each vendor, teams can write playbooks that express the desired network state in consistent terms.

Red Hat has also introduced a Role-based distribution model for network automation content. An Ansible Role is a structured, portable Playbook that packages tasks, variables, handlers, and templates in a reusable format. By publishing vendor-specific network Roles, Red Hat and its partners can address common customer use cases without locking users into proprietary tooling.

The full Ansible Network Automation offering combines Ansible Engine with Ansible Tower. Engine performs the actual automation work against devices; Tower provides the scheduling, RBAC, audit logging, and API surface needed to scale that automation across an IT organisation.

Ansible Galaxy 3.0

Concurrent with the Engine 2.6 release, Red Hat shipped Ansible Galaxy 3.0. Galaxy is the public repository where the Ansible community and Red Hat partners publish reusable Roles. Key changes in version 3.0 include:

• Improved user interface – a modernised browsing and search experience for discovering community content
• Modernised code base – internal refactoring to improve performance and maintainability of the Galaxy service itself
• Containerised infrastructure – Galaxy 3.0 runs on Red Hat OpenShift Dedicated, replacing the previous hosting model
• OpenShift Ansible Broker support – Galaxy 3.0 can host and distribute Ansible Service Broker content, enabling teams to define and provision multi-container services on Red Hat OpenShift Dedicated using Ansible automation

Roles remain the preferred unit of sharing Ansible content between teams precisely because of their portability: a Role developed against one environment can be consumed in another with minimal modification.

Windows Environment Support

The original reporting notes that Red Hat also boosted support for Microsoft Windows environments in Engine 2.6, though specific module additions or WinRM improvements were not detailed in the source material. Windows has been a supported Ansible target since the 1.x era, with management performed over WinRM rather than SSH.

What This Means for DevOps Teams

Ansible Engine 2.6 consolidates several trends that were already visible in the 2.x series: broader cloud coverage, more out-of-the-box network vendor support, and a richer content-sharing ecosystem. Practically speaking, teams working across mixed AWS, Azure, and VMware environments should find fewer gaps that require custom scripting to fill, and network engineers gain a more consistent abstraction layer across major switch and router vendors.

For organisations evaluating whether to standardise on Ansible for infrastructure automation, the Galaxy 3.0 content ecosystem reduces the time needed to reach a working baseline configuration for common platforms, since community and partner Roles can be consumed directly rather than built from scratch.

Key Takeaways

• Ansible Engine 2.6 became generally available on 17 July 2018.
• Native fact gathering is now simpler for AWS and Azure services such as RDS and Azure generic resources.
• 26 new VMware modules were added between Engine 2.5 and 2.6, covering VMs, networks, tags, and facts.
• Network automation modules cover Arista EOS, Cisco IOS/IOS XR/NX-OS, Juniper JunOS, Open vSwitch, and VyOS.
• Ansible Galaxy 3.0 ships alongside Engine 2.6 with a new UI, modernised codebase, and OpenShift-hosted infrastructure.
• Galaxy 3.0 adds Ansible Service Broker content support for multi-container OpenShift service provisioning.

Source: eWeek reporting, July 2018.