3 Challenges for Network Engineers Adopting Ansible

Ansible, ansible, ansible seems to be all we hear these days. There are lots of resources out there all trying to convince us this is the new way get stuff done. The reality is quite different – adoption of tools like this is slow in the networking world, and making the move is hard for command-line devotees.

Here are the three main problems I encountered in my adoption of Ansible as a modern way to manage devices:

1. Most network devices don’t support Python

Ansible is derived from the systems world, and is only latterly coming to be used for managing network devices. It is often said that Ansible is agentless, but when managing a Linux host (for example) the control machine pushes the Ansible playbook to that host and executes it there. In effect, *Python* is the agent.

Most network devices don’t have on-box Python, so when using Ansible against a router or a switch you have to have ‘connection: local’ in your playbook:

---
 name: Get info 
 hosts: all
 roles:
 Juniper.junos          # Invokes the Junos Ansible module
 connection: local        # Tells it to run locally
 gather_facts: no 

What this does is run the playbook using the local Python on the control host, and then pushes the result to the target Junos device (in this case) over Netconf.

---

2. Credentials Storage – Many Options!

Doing things securely is very important in a production environment, but the internet is littered with lab-based examples where credentials are stored in cleartext.

There are a number of different ways that authentication can be performed with Ansible:

• Public key authentication
• Storing username/password in Ansible Vault – a secure storage area
• Interactively at the command-line
• Within the playbook (insecure and to be deprecated after Ansible 2.9)
• As variables in the hosts file (insecure)
• Probably others

Example of using command-line authentication:

---

3. Ansible Module Confusion

Two main hurdles present themselves to the network engineer:

Module documentation is quite often incorrect. You write a playbook but get messages about having used deprecated commands. However the module documentation still says that the commands you’ve used are mandatory. All very confusing.

Worse than that, in the case of Juniper, there are two different sets of modules to manage the Junos device.

• The core modules ship with Ansible engine and are documented on the Ansible site – see the documentation for junos_facts here.
• Juniper’s own modules are similarly-named but different, and documented on the Juniper site. See the documentation for juniper_junos_facts here.
  

Conclusion

For a network engineer, CLI commands are deprecated quite rarely, so this changing of things comes as something of a surprise. Someone who configured OSPF on IOS 15 years ago can probably still still do so. But that’s not the world we’re in any more when it comes to open-source software. That means version control and testing become all the more paramount.

Getting over the first two hurdles is easy enough though, so keep persevering!