Wednesday, August 30, 2017

NetDevOps: important idempotence



----
NetDevOps: important idempotence
// Cumulus Networks Blog

As more and more network engineers dive into network automation, the word idempotence keeps coming up. What is it? Why is it important? Why should we care? Idempotence is often described as the ability to perform the same task repeatedly and produce the same result. I want to demonstrate a super simple example of what this means.

If I am logged into a Linux box and want to add an IP address to the loopback address, I could use something simple like a sed command.

root@leaf01:mgmt-vrf:~# sed -i '/loopback/ a address 1.1.1.1/32' /etc/network/interfaces

This produces exactly what I want!
auto lo
iface lo inet loopback
        address 1.1.1.1/32
        address 10.0.0.11/32

I have appended the address 1.1.1.1/32 to the loopback interface stanza of the /etc/network/interfaces file. Now what happens if I run that same exact command again?

Running the command again produces the following output:
auto lo
iface lo inet loopback
        address 1.1.1.1/32
        address 1.1.1.1/32
        address 10.0.0.11/32

😐 That is not what I wanted. I performed the same task but instead of just leaving the file alone, since the 1.1.1.1/32 was already configured, it just appended it again. Using sed in this fashion is not idempotent, and performs undesirable results. However, the Cumulus Linux NCLU (Network Command Line Utility) is idempotent and knows if that interface already has the state we desire.

root@leaf01:mgmt-vrf:~# net add loopback lo ip address 1.1.1.1/32
lo's configuration already has 'address 1.1.1.1/32'

Idempotence is also very important to DevOps tools like Ansible because we can check configuration state and only make changes when necessary. For example, here is a comparison between the Ansible command module, which is often not idempotent, versus the Ansible NCLU module.

Here is a very simple playbook where we add the IP address 172.16.1.1/24 with the Ansible command module:

---
- hosts: leaf01
become: yes
tasks:
   - command: net add interface swp30 ip address 172.16.1.1/24

Every single time we run it, Ansible thinks the file changes:

sean@utility ~ $ ansible-playbook test.yml

PLAY[leaf01]*******************************************************************************************

TASK [Gathering Facts]*******************************************************************************
ok: [leaf01]

TASK [command] *************************************************************************************
changed: [leaf01]

PLAY RECAP ******************************************************************************************
leaf01 : ok=2 changed=1 unreachable=0 failed=0

That means Ansible is unaware that the existing state is the same as the state command we are trying to run, so it runs it every time. As far as the user performing Ansible playbook runs knows, someone could keep removing his 172.16.1.1/24 between each play. He has no idea of what the current state is, just that he fired off commands and they successfully ran. Why does it keep coming up as changed? Yes, this is technically network automation, but if we use the NCLU module for Ansible we can have much more efficient playbooks that use idempotence and can alert us to if something actually changed or not.

Here is an example of the same playbook with the NCLU module:

---
- hosts: leaf01
become: yes
tasks:
   - nclu:
      commands: add int swp30 ip address 172.16.1.1/24
      commit: true

Now look what happens when this playbook is run:

sean@utility ~ $ ansible-playbook nclu_test.yml

PLAY [leaf01] ******************************************************************************************

TASK [Gathering Facts] ******************************************************************************
ok: [leaf01]

TASK [nclu] ********************************************************************************************
ok: [leaf01]

PLAY RECAP ******************************************************************************************
leaf01 : ok=2 changed=0 unreachable=0 failed=0

The IP address was already configured, so nothing changed. Everything returns green and lets us know the desired configuration was already in place. This is the true intention of DevOps tools, not only to perform commands, but actually act as one-stop shop for configuration management.

Want to start playing with Cumulus Linux and Ansible? Check out our Github page here and try out some demos including Ansible, Puppet and Chef. Got questions or comments? Post below.

The post NetDevOps: important idempotence appeared first on Cumulus Networks Blog.


----

Read in my feedly


Sent from my iPhone