Wednesday, February 19, 2020

VLANS resource modules for Ansible Network Automation

As to follow rule #3 for r/networking I won't just link to an external site without any content for Reddit

For Ansible a "resource module" is a module that specifically configures a single resource (think config section in Cisco speak) such as L3 interface information with os_l3_interfaces (IPv4, IPv6, etc), or os_vlans module that configure VLANs (name, vlan-id, state). The goal of resource modules is to make Ansible easier and more modular (excuse my pun :) . Historically Ansible was super easy for novices to get started...... but then Ansible Network Automation could get really complicated unless you really understood Jinja2 templating with the config modules. This made network automation difficult to adopt for many network engineers that didn't want to spend time troubleshooting a 1000 line Jinja2 template with a hundred if statements for every scenario.

Lets look an an example:

--- - name: add vlans hosts: arista gather_facts: false tasks: - name: add VLAN configuration eos_vlans: config: - name: desktops vlan_id: 20 - name: servers vlan_id: 30 - name: printers vlan_id: 40 - name: DMZ vlan_id: 50 

As you can see in the example, each resource module has a very simple associated data-model. Instead of creating a super complex all-encompassing data model (think of my Jinja2 comment above) we can create a per-resource data model. This allows you to not approach automation as a "all or nothing" but adopt it on a per-resource basis.

What this means is that you can get some quick ROI for learning Ansible. You don't have to necessarily automate an entire configuration for your Cisco IOS router or Juniper Junos switch before you get some benefit for spending time automating. You can automate just standardizing your VLANs and enforcing configuration policy and then keep adding resource modules as you adopt network automation across your infrastructure.

There are three state parameters for resource modules that are standard across all new resource modules (e.g. ios_l2_interfaces, ios_l3_interfaces, ios_interfaces, etc). They are merged, replaced and overridden.

Merge just makes sure that the configuration you are providing will exist on the network device. It just merges the configuration into whatever is already configured on the switch.

replaced will remove what you don't configure for a given resource. Each resource module is fully aware of the data model it provides. For example, if the vlan configured on an Arista EOS switch looked like this->

vlan 200 state suspend ! 

But you sent this->

- name: desktops vlan_id: 200 

It is going to remove state suspend because you didn't send it. In other words it knows what "shouldn't" be there.

Overridden takes this concept a step further and is aware of all resources holistically, for the vlans example this means all vlans. So if you don't have vlan 100 in your data model, it will remove vlan 100 entirely and enforce configuration state.

I hope this helps illustrate the concept of resource modules, I know this concept is new to a lot of folks and I am working on content to help make this super easy! I will try to make my next blog post about return parameters for each of these resource modules and how to use them in your Ansible Playbooks, and how to read in brownfield networks and turn them into data models (structured data!). Hopefully I have not bored you to death at this point!

Link to blog post with more information



No comments:

Post a Comment