In the upcoming release of Red Hat Ansible Engine 2.9, you'll find impressive enhancements, some of which are outlined in this article. As usual, we've developed improvements to Ansible Network in an open manner, with community support. Join us — take a look at and explore the development roadmap for on the wiki page for .
As we recently announced, now includes Ansible Tower, Ansible Engine, and all Ansible Network content. Currently, most popular networking platforms are implemented through Ansible modules. For example:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
A complete list of platforms that are fully supported by Red Hat through Ansible Automation subscription .
What We've Learned
Over the past four years, we've learned a lot about developing a network automation platform. We've also learned about how as platform artifacts are applied in playbooks and roles in Ansible from the end-users' perspective. Here’s what we found out:
- Organizations are automating devices from not just one, but many vendors.
- Automation is not only a technical phenomenon but also a cultural one.
- Large-scale network automation is more complex than it seems due to fundamental architectural design principles of automation.
When we discussed our long-term development plans over a year ago, our enterprise customers requested the following:
- Fact gathering needs to be better standardized and aligned with automation workflows for any devices.
- Configuration updates on devices also need to be standardized and aligned so that Ansible modules handle the second half of the cycle after fact gathering.
- We need strict and maintainable methods for converting device configurations into structured data. Based on this, the source of truth can be moved away from the network device.
Fact Improvements
Fact gathering from network devices with Ansible often happens haphazardly. Network platforms are equipped to different extents with fact-gathering capabilities, but they have little to no functionality for parsing and standardizing data representation in key-value pairs. Read on Ken Celenza discusses how challenging and tedious it can be to analyze and standardize data facts.
You may have noticed our efforts on the Ansible Network Engine role. Naturally, after 24,000 downloads, the Network Engine role quickly became one of the most popular roles in Ansible Galaxy for network automation scripts. Before we moved much of this into Ansible 2.8 to prepare for what will be needed in Ansible 2.9, this Ansible role provided the first set of tools to aid in command parsing, team management, and data collection for network devices.
If you are familiar with using the Network Engine, it's a very efficient way to collect, parse, and standardize data facts for use in Ansible. The downside of this role is that you need to create a whole bunch of parsers for each platform and for all network activity. To understand how difficult it is to create, deliver, and maintain parsers, take a look at from the folks at Cisco.
In short, for large-scale automation, it is crucial to gather facts from devices and normalize them into key-value pairs, but achieving this is challenging when you have many vendors and network platforms.
Each network fact module in Ansible 2.9 can now analyze the configuration of a network device and return structured data — without additional libraries, Ansible roles, or custom parsers.
Starting with Ansible 2.9, with each release of the updated network module, the fact module is improved to provide data about this section of the configuration. This means that the development of facts and modules now occurs at the same pace, and they will always share a common data structure.
Configuration resources on a network device can be extracted and transformed into structured data in two ways. Both ways allow you to collect and transform a specific list of resources using the new keyword gather_network_resources. Resource names correspond to module names, which is very convenient.
During fact gathering:
Using the keyword gather_facts , you can extract the current configuration of the device at the beginning of the playbook, and then use it throughout the entire playbook. Specify individual resources to extract from the device.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueYou may have noticed something new in these examples, namely — gather_facts: true now available for native fact gathering for network devices.
Using the network facts module directly:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesThe playbook returns the following facts about the interface:
ansible_facts:
ansible_network_resources:
interfaces:
- enabled: true
name: Ethernet1
mtu: '1476'
- enabled: true
name: Loopback0
- enabled: true
name: Loopback1
- enabled: true
mtu: '1476'
name: Tunnel0
- enabled: true
name: Ethernet1
- enabled: true
name: Tunnel1
- enabled: true
name: Ethernet1Note how Ansible extracts the native configuration from the Arista device and transforms it into structured data to be used as standard key-value pairs for subsequent tasks and operations.
Interface facts can be added to stored Ansible variables and used right away or later as input for the resource module eos_interfaces without any additional processing or transformation.
Resource modules
So, we have extracted the facts, normalized the data, fitted it into a standardized internal data structure, and obtained a ready source of truth. Hooray! This is great, but we still need to somehow convert the key-value pairs back into the specific configuration that the device platform expects. Now we need modules for specific platforms to meet these new fact-gathering and normalization requirements.
What is a resource module? Device configuration sections can be thought of as resources provided by that device. Network resource modules are intentionally limited to a single resource, and they can be stacked like building blocks to configure sophisticated network services. Consequently, the requirements and specifications for the resource module naturally simplify, as the resource module can read and configure a specific network service on the network device.
To explain what the resource module does, let’s look at an example playbook that demonstrates idempotent operations using the new network resource facts and the module eos_l3_interface.
- name: example of facts being pushed right back to device.
hosts: arista
gather_facts: false
tasks:
- name: grab arista eos facts
eos_facts:
gather_subset: min
gather_network_resources: l3_interfaces
- name: ensure that the IP address information is accurate
eos_l3_interfaces:
config: "{{ ansible_network_resources['l3_interfaces'] }}"
register: result
- name: ensure config did not change
assert:
that: not result.changedAs you can see, the data collected from the device is sent directly to the corresponding resource module without any transformation. When the playbook is run, it extracts values from the device and compares them with the expected ones. In this example, the retrieved values match the expectations (meaning the configuration deviation check is passing), and it issues a message indicating whether the configuration has changed.
The ideal way to detect configuration deviation is to store facts in Ansible's saved variables and periodically use them alongside the resource module in check mode. This is a simple method to see if anyone has manually changed values. In most cases, organizations allow manual changes and configuration, although many operations are performed through Ansible Automation.
How do the new resource modules differ from the previous ones?
For a network automation engineer, there are 3 main differences in the resource modules in Ansible 2.9 compared to earlier versions.
1) For a specific network resource (which can also be thought of as a configuration section), modules and facts will be developed across all supported network operating systems simultaneously. We believe that if Ansible supports a resource configuration on one network platform, we should support it everywhere. This simplifies the use of resource modules because a network automation engineer can now configure a resource (such as LLDP) across all network operating systems with native and supported modules.
2) Resource modules now include a state value.
merged: the configuration is merged with the provided configuration (default);replaced: the resource configuration will be replaced with the provided configuration;overridden: the resource configuration will be replaced with the provided configuration; extra resource instances will be removed;deleted: the resource configuration will be deleted/restored by default.
3) Resource modules now include stable return values. When a network resource module makes (or suggests) the necessary changes to the network device, it returns the same key-value pairs in the playbook.
before: the configuration on the device in the form of structured data before the task;after: if the device has changed (or may change if in check mode), the resulting configuration will be returned as structured data;commands: any configuration commands issued on the device to bring it to the desired state.
What does all this mean? Why is it important?
This post describes many complex concepts, but we hope that in the end, you will better understand what corporate clients are asking for in terms of fact gathering, data normalization, and configuration cycles for the automation platform. But why do they need these enhancements? Many organizations are currently undergoing digital transformation to make their IT environments more agile and competitive. Whether good or bad, many network engineers are becoming network developers — out of personal interest or at the behest of management.
Organizations recognize that automating individual network templates does not solve the problem of fragmentation and only improves efficiency up to a certain point. The Red Hat Ansible Automation Platform provides robust and normalized resource data models to programmatically manage foundational data on the network device. In other words, users are gradually abandoning individual approaches to configuration in favor of more modern methods that focus on technologies (such as IP addresses, VLANs, LLDP, etc.) rather than specific vendor implementations.
Does this mean that the days of reliable and proven command modules and configurations are numbered? Absolutely not. The expected resource modules will not apply in all cases and not for every vendor, so command modules and configurations will still be necessary for certain implementations. The purpose of resource modules is to simplify large Jinja templates and normalize unstructured device configurations into a structured JSON format. With resource modules, existing networks will find it easier to convert their configurations into structured key-value pairs, which will serve as a human-readable source of truth. By using structured key-value pairs, one can move from running configurations on each device to working with independent structured data, bringing networks to the forefront in the 'infrastructure as code' approach.
What resource modules will be available in Ansible Engine 2.9?
Before diving into what will be in Ansible 2.9, let's recall how we categorized the entire workload.
We identified 7 categories and assigned specific network resources to each:
Note: resources highlighted in bold were planned and implemented in Ansible 2.9.
Based on feedback from enterprise customers and the community, it made sense to first tackle the modules related to network topology protocols, virtualization, and interfaces.
The following resource modules have been developed by the Ansible Network team and correspond to platforms supported by Red Hat:
The following modules have been developed by the Ansible community:
exos_lldp_global— from Extreme Networks.nxos_bfd_interfaces— from Cisconxos_telemetry— from Cisco
As you can see, the concept of resource modules fits into our platform-centric strategy. This means we are incorporating necessary capabilities and functionalities into Ansible itself to support standardization in the development of network modules and to simplify user experiences at the level of Ansible roles and playbooks. To further advance the development of resource modules, the Ansible team has released the Module Builder tool.
Plans for Ansible 2.10 and beyond
After the release of Ansible 2.9, we will focus on the next set of resource modules for Ansible 2.10, which can be used to further configure network topology and policies, such as The development plan can still be adjusted, so if you have any comments, please let us know in the .
Resources and Getting Started
Source: habr.com
