When I started working with Ansible networking modules they had a distinct science fair feel: everything was in flux, every new version of Ansible would break my playbooks, modules would disappear from one release to next, documentation was sketchy and describing the latest development code not a shipped release.
In the meantime, code, documentation, and release/deprecation management improved dramatically:
A long while ago I published my solution for automated L3VPN provisioning… and I’m really glad I can point you to a much better one ;)
Håkon Rørvik Aune decided to tackle the same challenge as his hands-on assignment in the Building Network Automation Solutions course and created a nicely-structured and well-documented solution (after creating a playbook that creates network diagrams from OSPF neighbor information).
Want to be able to do something similar? You missed the Spring 2019 online course, but you can get the mentored self-paced version with Expert Subscription.
This is one of the “thinking out loud” blog posts as I’m preparing my presentation for the Building Network Automation Solutions online course. I’m probably missing a gazillion details - your feedback would be highly appreciated
One of the toughest challenges you’ll face when building a network automation solution is “where is my source of truth” (or: what data should I trust). As someone way smarter than me said once: “You could either have a single source of truth of many sources of lies”, and knowing how your devices should be configured and what mistakes have to be fixed becomes crucial as soon as you move from gathering data and creating reports to provisioning new devices or services.
Remember how earlier releases of Nexus-OS started dropping configuration commands if you were typing them too quickly (and how it was declared a feature ;)?
Mark Fergusson had a similar experience on Cisco IOS. All he wanted to do was to use Ansible to configure a VRF, an interface in the VRF, and OSPF routing process on Cisco CSR 1000v running software release 15.5(3).
Here’s what he was trying to deploy. Looks like a configuration straight out of an MPLS book, right?
The crazy pace of webinar sessions continued last week. Howard Marks continued his deep dive into Hyper-Converged Infrastructure, this time focusing on go-to-market strategies, failure resiliency with replicas and local RAID, and the eternal debate (if you happen to be working for a certain $vendor) whether it’s better to run your HCI code in a VM and not in hypervisor kernel like your competitor does. He concluded with the description of what major players (VMware VSAN, Nutanix and HPE Simplivity) do.
On Thursday I started my Ansible 2.7 Updates saga, describing how network_cli plugin works, how they implemented generic CLI modules, how to use SSH keys or usernames and passwords for authentication (and how to make them secure), and how to execute commands on network devices (including an introduction into the gory details of parsing text outputs, JSON or XML).
The last thing I managed to cover was the cli_command module and how you can use it to execute any command on a network device… and then I ran out of time. We’ll continue with sample playbooks and network device configurations on February 12th.
You can get access to both webinars with Standard ipSpace.net subscription.
One of the attendees of my Building Network Automation Solutions online course sent me this suggestion:
Stick to JUST Ansible - no GitHub, Vagrant, Docker or even Python - all of which come with their own significant learning curves.
While I understand how overwhelming the full-blown network automation landscape is to someone who never touched programming, you have to make a hard choice when you decide to start the learning process: do you want to master a single tool, or understand a whole new technology area and be able to select the best tool for the job on as-needed basis.
One of my subscribers sent me a nice email describing his struggles to master Ansible:
Some time ago I started to hear about Ansible as the new power tool for network engineer, my first reaction was “What the hell is this?” I searched the web and found many blah blahs about it… until I landed on your pages.
He found Ansible for Networking Engineers material sufficient to start an automation project:
Last year’s experiment generated so much interest that I decided to repeat it this year: if you’re an undergraduate or Master's student and manage to persuade us that you’re motivated enough to automate the **** out of everything, you’ll get a free seat in Ansible for Networking Engineers online course.
Interested? Check out the details, and apply before October 1st.
Too old? Please spread the word ;)
An engineer attending Ansible for Networking Engineers online course sent me this feedback:
This is a great place to learn Ansible and Network Automation from scratch. Starting with an emphasis on the fundamentals (YAML, JSON, Jinja2, how to group your network devices for automation, etc.) you progressively build up towards useful network automation.
He particularly liked the additional features that are part of any ipSpace.net online course:
You probably know that fantastic feeling when you think your newly-discovered tool is a Hammer of Thor, capable of solving every problem (or at least crashing through it). I guess you’re also familiar with that sinking feeling when you’re trying to use your beloved hammer to whitewash a bikeshed.
Not surprisingly, the cruder the tool is, the quicker you’ll hit its limits, like when you try to do data processing in Jinja2 (hint: don’t).
The network automation evangelists love to tell you that automation is more than just device configuration management. They’re absolutely right… but it’s nonetheless amazing how much good you could do with simple tools solving simple problems.
Here’s what I got from Nicky Davey:
One of the biggest challenges of network automation is getting usable information from network devices… or as asked by a student in my Building Network Automation Solutions online course in the course Slack team:
How do I get specific information from a specific command from a device without an Ansible Network Module? Is Python the only suggested approach?
I described how hard it is to get structured information from network devices in great details in this section of the Ansible for Networking Engineers webinar and online course. Here are a few more thoughts on the topic:
One of the first things I did when I started my deep-dive into network automation topics was to figure what tools people use to automate stuff and (on a pretty high level) what each one of these tools do.
You often hear about Ansible, Chef and Puppet when talking about network automation tools, with Salt becoming more popular, and CFEngine being occasionally mentioned. However, most network automation engineers prefer Ansible. Here are a few reasons.
A while ago I created an Ansible playbook that creates network diagrams from LLDP information. Ben Roberts, a student in my Building Network Automation Solutions online course used those ideas to create an awesome solution: he’s graphing multicast trees.
Here’s how he described his solution:
Here’s a quote from one of my friends who spent years working with Ansible playbooks:
Debugging Ansible is one of the most terrible experiences one can endure…
Please note that the Building Network Automation Solutions online course includes all material from the Ansible online course.