Wow, how time flies! Here we go with another Ansible Project release packed full of updates for automating network infrastructure. After spending the last year heavily focused on building much of the foundation for Ansible network integration, this release represents the beginning of the journey towards building more application-aware, declarative-based Ansible modules. This is an exciting time and on behalf of the entire Ansible community, including the Ansible network engineering team. I’m very pleased to share with you the enhancements and updates to network integration included with the forthcoming Ansible 2.4 open source release.
The initial introduction of network support was originally conceived to help operators focus on being able to execute configuration changes on network devices with a set of imperative-based configuration modules.
Today, the Ansible network modules are focused on pushing configuration statements to network devices. It was a small step, but an important one in the journey towards full configuration management of physical network devices.
Since then, we have turned our attention towards how to better help organizations become more agile in actively managing network configurations. Over the course of the Ansible 2.4 release, we have been phasing in a more intelligent approach to building and configuring network elements. This approach will combine elements of declarative configuration management with ephemeral state validation to handle updating network element’s active configuration.
Looking ahead to Ansible 2.4, the most notable additions include the following:
- Resource modules
- Aggregate resources
- Declarative intent
- Additional platform support and modules
Why are these features important?
These changes will enable network operations teams to focus on describing the desired configuration and operating state of the network infrastructure. The benefits of this approach help network operations teams to focus more on operating the network infrastructure and less on defining the low-level commands to achieve the desired result. This shift in focus is designed to streamline an organization’s ability to push configuration changes into the infrastructure, implementing a more agile and scalable operations environment.
Resource Modules
Beginning with the Ansible 2.4 release, Ansible modules will begin providing modules with a focus on building device configurations declaratively. Unlike modules that define a sequence of steps to achieve an end state, resource modules allow playbook designers to define the desired end configuration state. From there, the module will take the appropriate set of sequential steps, based on the current configuration, to arrive at the desired end state.
For instance, with the current set of modules in Ansible 2.3, configuring a virtual routing and forwarding (VRF) instance on a Cisco IOS platform could look something similar to the following:
- name: configure the “management” vrf
ios_config:
lines:
description oob mgmt vrf
parents: vrf definition management
Reimplementing the same logic using resource modules significantly simplifies the playbook readability, making the task intention much clearer to both network and non-network operators:
- name: configure the “management” vrf
ios_vrf:
name: management
description: oob mgmt vrf
state: present
The declarative nature of the module transforms the module as defined above into a set of calls to the device based on what the current device configuration is.
Aggregate Resources
There are many resources in a network configuration that contain multiple definitions. Items such as VLANS, VRFs, BGP neighbors, and loopback interfaces are all good examples of resources that could be managed as aggregates.
Expanding on the example above, it is not uncommon (in fact, it's quite common) to have many VRFs defined in the network device configuration. When designing playbooks, it's often the intention of the playbook designer to be able to reconcile the list of resources without prior knowledge of what has been previously configured on the device.
The declarative modules developed for Ansible 2.4 support this inherently. Assuming there is a finite set of VRFs that should be present on a given network element, the declarative modules can be used to declare this intent.
- name: configure the “management” vrf
ios_vrf:
aggregate:
- { name: management, description: management vrf }
- { name: services, description: services vrf }
- { name: operations }
description: oob mgmt vrf
purge: yes
state: present
This modified example focuses on the set of VRF resources that should be applied to a given network element. In this case, the module will be responsible for ensuring the final running configuration of the device includes three VRFs (management, services, operations) and removes all other VRF configurations.
In this way, playbook designers have a powerful means to push configuration changes to network devices. By providing modules that allow network operations teams to define the overall set of resources to be configured on the network element, teams can focus on pushing the desired final state to network elements instead of having to decipher how to reach the end state through a series of incremental steps.
Declarative Intent
One of the significant challenges to automating the configuration of network elements is based on the need to perform ephemeral state validation. Consider for a moment the overall goal of configuration automation is to automatically build (or tear down) parts of the whole to achieve a working end-to-end service or application.
In the case of network devices, the first step is to begin to transform from imperative configuration management (having to define each step of the process) to declarative configuration management (defining the end state and letting the platform figure out the steps to get there).
Ansible is taking this a step further to allow network operations teams to begin to move beyond simple declarative configuration of resources and resource collections to be able to define the intended operating state of those resources.
Consider the goal of automating the configuration of a network element interface configuration. The declarative module might look something like the following:
- name: configure an access IP interface
ios_interface:
name: Ethernet2/1
description: web access services
ipv4: 172.26.4.1/24
mtu: 9000
state: present
As discussed previously, the Ansible Playbook can easily accept the declarative configuration module and use it to build an appropriate configuration on the end device. In addition, the module operates idempotently so continued pushes will validate the configuration on the network element while making no changes if the current configuration is valid.
While this makes it easy to define the desired configuration state of the interface in this case, if the physical cable was never (or worse, wrongly) plugged into the port, the device will not have achieved an operational (ephemeral) state that was intended. When considering this task as part of a larger playbook that configures networks and applications and services, it becomes obvious the desired application or service will not fully function.
Further compounding this problem is that repeated attempts of running the playbook will not cause any further changes to the network element configuration since the current configuration is both valid and matches the desired configuration state. In short, the configuration did not match the intention of the playbook designer.
To address this situation, we are focusing on adding intent or behavior driven arguments to network modules for validating device ephemeral state. Here is the updated module:
- name: configure an access IP interface
ios_interface:
name: Ethernet2/1
description: web access services
ipv4: 172.26.4.1/24
state: connected
neighbors:
- host: websrv01
port: eth0
The updated module now allows network operations teams to define both configuration state and intended state. It will now first validate the active configuration and make appropriate changes to the network element as necessary to achieve the desired configuration state. Once the configuration state is consistent with the desired state, the module will then check the ephemeral state of the interface. In this example, the operational state of the interface must be up and the LLDP neighbor(s) must be connected to host websrv01 on port eth0.
Declarative intent modules begin to open a whole new approach to defining network configuration state for operations teams. Playbooks can be built to define both the desired configuration state and the desired operational state. This allows playbooks to define the intended operating behavior of the network infrastructure and provides operations teams with a higher degree of certainty that, at the conclusion of a playbook run, the infrastructure is operating as it was designed and intended.
Overall the transition to managing network configuration state using declarative modules should change the way organizations approach configuration management. Network operators can begin to focus on the collective network deployment without needing to address incompatibilities and/or incongruences between vendor implementations. In addition, declarative modules can bring the ancillary benefit of delivering a consistent, repeatable configuration pattern regardless of device operating system that can be delivered at scale.
These modules will be phased into Ansible releases over the next year starting with the Ansible 2.4 release. As these modules are being designed and developed, we encourage you to get involved to help drive the module definitions.
Additional platform support and modules
Finally, Ansible 2.4 is expected to add more modules to new and existing networking infrastructure platforms with 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.
The Ansible Networking team is excited for the forthcoming Ansible 2.4 release, and would like to extend a warm thank you to all networking partners and community members that helped make it possible. We love to hear your feedback, thoughts, ideas and welcome you to participate in the Ansible networking community.
