Ansible bridges traditional networking teams and DevOps

bridge
Credit: Jeremy/Flickr

Red Hat has added agentless networking automation capabilities to Ansible

In the everything is software-defined, everything is a service world, network virtualization is joining compute and storage virtualization to give DevOps even more control over the underlay networking. And now Red Hat has added the capabilities to control networking infrastructure to Ansible, its infrastructure automation software.

Networking support in Ansible is available immediately for Arista EOS, Cisco Application Centric Infrastructure (ACI), Cisco IOS-XE, Cisco IOS-XR, Cisco NX-OS, Cumulus Linux, OpenSwitch and Juniper’s Junos OS.

With Ansible, DevOps get the capability to automate network infrastructure using SSH and APIs. They don’t have to worry about installing or loading vendor specific, closed software onto their devices, something that could be an unwanted clog in the infrastructure.

In addition, DevOps don’t have to worry about a specific data model or abstraction in their infrastructure. “This separation of data model from execution allows network operations teams to manage their configuration data models in a way that most effectively fits their organization be it CMDB, OpenConfig or custom enterprise data model,” Peter Sprygada, senior principal software engineer for Red Hat explained in an email interview.

But automating the networking stack through software and open technologies is nothing new -- Software Defined Networking (SDN) is now commonplace in IT infrastructure. Customers can already orchestrate and automate their networking resources through software, so what value is Red Hat bringing to these customers? The answer lies in overlay and underlay of the network.

Sprygada explained the difference between the two: “With the plethora of definitions around SDN (software defined networking) today, it would be more appropriate to address the value Ansible brings to network infrastructure as it relates to underlay and overlay networks. We have built integration with network devices to initially focus on the more underserved area of underlay networks. One of the prerequisites for overlay infrastructures in an SDN environment to succeed is based on the premise that the underlay network is properly configured and operational.”

The underlay is still being managed by what Sprygada calls manual, error-prone processes that focus on typing out configuration and validating state through human run sessions.

Red Hat is developing Ansible as a foundation to automate these manual processes. But they are doing it in a way that improves the network operational model instead of trying to redefine it.

Ansible is not trying to build a new set of tools to cater to the traditional systems teams. They have built networking support in a way that can work as a common language between the traditional networking teams and DevOps teams, allowing organizations to benefit from the knowledge base of both teams. And that’s the idea behind the DevOps movement.

Sprygada said, “While extending Ansible to include network devices was a relatively natural evolution, it was really the Ansible community and users that really pushed for this direction due to the simple and agentless approach.”

This article is published as part of the IDG Contributor Network. Want to Join?

Download the State of the CIO 2016 report
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies