It’s been a year since the first networking modules were developed and included in Ansible 2.0. Since then, there have been two additional Ansible releases and more than 175 modules added, with 24 networking vendor platforms enabled. With the fantastic efforts from the community and our networking partners, Ansible has been able to add more and more features for networking use cases. In the forthcoming Ansible 2.3 release, the focus on networking enablement now turns to increasing performance and adding connection methods that provide compatibility and flexibility.
Looking ahead to Ansible 2.3, the most notable additions planned are:
- Persistent connections framework
- The network_cli connection plugin
- The netconf connection plugin
Why are these features important?
Since Ansible 2.0, the primary focus for networking enablement has been to help increase the number of third-party devices that have modules included by default. As this list grows (we expect to have even more platforms and modules in Ansible 2.3), Ansible and Ansible Tower continue to be trusted components of critical networking production deployments.
The development of these plugins further demonstrates the value and investment Ansible and the community have made into networking infrastructure enablement. As we approach the Ansible 2.3 release date, stay tuned for deeper-dive blog posts on the following:
In order to better understand why including persistent connections support is a substantial benefit in Ansible 2.3, it’s important to understand how tasks are currently executed on networking devices using the local connection plugin in Ansible 2.2 and earlier. A connection plugin defines how Ansible communicates with inventory hosts. A list of all currently available connection plugins can be found on the Ansible GitHub repository.
In most cases, each time an Ansible play is run, the following occurs in the background:
- An SSH connection is established between the control node (the system that runs the Ansible Playbooks) and the managed node (the networking device)
- The task is executed via the vendor module on the control node via the local connection plugin and sent to the networking device using the vendor-specific command line interface (CLI) commands, configs, or templates
- The networking device returns data via the module back to the control node
- The SSH connection is closed
Playbooks with multiple tasks require SSH connections to be established and destroyed each time, resulting in extremely high overhead for completion.
Adding persistent connection support allows one SSH connection to stay active across multiple Ansible tasks, therefore reducing the total time for completion.
In order for Playbooks to take advantage of the persistent connections framework, new connection plugins must to be created, specifically for certain use cases. The two such connection plugins to be created are the network_cli connection plugin and the netconf connection plugin. Although these first plugins are primarily for networking infrastructure use cases, other plugins utilizing persistent connections are in plan for future Ansible releases.
New Connection Plugins
Ansible 2.3 expects to introduce two new connection plugins that are designed to enhance networking infrastructure integration. The new plugins are now natively integrated into Ansible core and allow Playbook designers to enjoy a more seamless approach to automating network devices. By moving to a plugin approach for configuring connectivity to network devices, tasks and modules can take advantage of new plugins while utilizing the local connection plugin. This means that device connectivity is now handled by Ansible across compute and network devices in a uniform fashion.
In order to leverage the new connection plugins, new and existing modules must be modified. When new and existing modules are modified, the local connection method stays unchanged, and therefore all Playbooks themselves. We are working closely with both our technology partners and the Ansible community to update as many of the current network modules are possible.
Again, to use a new connection plugin, the Playbook and/or the runtime environment does not need to be changed in any way. Under the covers, there are two connection methods that can be used, including the following:
Network_cli connection plugin
The network_cli connection plugin replaces the local connection plugin for network device modules that support programmability over the device CLI. In Ansible 2.3, a connection plugin dedicated for third-party networking modules that utilizes persistent connections is now included. It is designed to work with traditional network devices that require connectivity to a device CLI in order to configure resources.
Netconf connection plugin
In addition to the network_cli plugin, Ansible 2.3 also includes a new connection plugin designed to work primarily with network devices using the netconf protocol. The netconf connection plugin provides module developers with the opportunity to develop modules that interface with remote devices using the NETCONF standard.
The Network Configuration Protocol (NETCONF) is an XML-based solution for providing “mechanisms to install, manipulate, and delete the configuration of network devices” and is managed by the IETF, via RFC 6241. NETCONF is an alternative, agnostic approach to vendor-specific Ansible modules using standards-based schemas for implementation. That is, instead of having Playbooks that are vendor-specific, you could have a single Playbook using the NETCONF plugin, assuming the networking infrastructure supports the NETCONF standard.
Finally, Ansible 2.3 is expected to add more modules to new and existing networking infrastructure platforms with the help from corporate and community partnerships. This means additional built-in support for more devices and more features and functionality exposed for use in Ansible across your data center.
Additional platform support and modules
The Ansible Networking team is excited for the forthcoming Ansible 2.3 release, and would like to extend a warm thank you to all networking partners and community members that helped make it possible.