Now that we’ve covered how TextFSM work and how it can be used to record useful information from device outputs, it’s time to move our focus on how we use TextFSM templates in Ansible.
Using NTC-Ansible’s ntc_show_command module, we’re able to “get structured data from devices that don’t have an API”. As I’ve touched on in previous posts, it does this through the use of TextFSM templates which can be found here. I’ll cover how to write your own templates in a future post but for now I’ll focus on how to use the existing templates.
Recently I posted about how it can be easy to get lost in the sea of options when it comes to having Ansible control your network gear. The next challenge you may face is figuring out how to structure your playbooks.
For example, you can list your hosts, as well as your host and group variables in the /etc/ansible/hosts file, or you can create your own inventory, host and group files in your directory layout. Further to this, talking about variables alone for a moment, there are sixteen different places they can be specified.
Note that the hosts file is known as the inventory file.
As my collection of automation posts continues to grow, now is a good time to discuss why you should use automation.
The two automation related comments/questions and responses which I’ve found most interesting to date are:
- Why should I use automation, aren’t I just going to automate myself out of a job?
No! Automation helps you get things done quicker, and if done properly, is 100% repeatable and therefore completely removes the risk of human error. Further to this, automating laborious tasks frees up your time so it can be better spent doing the more fun and challenging parts of your role.
- I don’t have time to look into and set up automation.
Funnily enough the people who say this are the ones who need it the most. Looking into and setting up automation should be seen as an investment. It might take a little bit of time now but it will consistently pay massive dividends once it is done.
My collection of Ansible posts is steadily rising, so I thought it would be a good idea to write a post on how you can connect an Ansible VM into GNS3 so that you can practice your automation skills in a non-production environment. While I am using VMware Wrokstation for this post, the process is very similar for VMWare Player and VirtualBox.
In my previous post I covered how to to download, install and test TextFSM. In this post I’ll demonstrate how to write your own template files so that you can create (and hopefully contribute!) them if a suitable one does not already exist.
It is worth mention that the examples in this post are extremely basic. I’ve done it this way on purpose because I’m only trying to demonstrate how to use TextFSM, not how to write regex. I feel that trying to do both in a single post would cause unnecessary confusion for those who are not familiar with either.
As I mentioned in my previous post, NTC-Ansible uses TextFSM templates to allow you to convert your CLI outputs to JSON and then access the data in an API-like fashion.
In this post I’ll cover how to run TextFSM templates against CLI outputs.
To get started, download the latest version of TextFSM using the ‘git clone’ command:
will@ubuntu:/tmp$ git clone https://github.com/google/textfsm.git
Cloning into 'textfsm'...
remote: Counting objects: 105, done.
remote: Total 105 (delta 0), reused 0 (delta 0), pack-reused 105
Receiving objects: 100% (105/105), 65.15 KiB | 0 bytes/s, done.
Resolving deltas: 100% (45/45), done.
Checking connectivity... done.
In this series of posts I will cover how you can create your own API-like functionality for devices which do not have APIs built into them. Before I get started though, for those of you who don’t know what an API is, here’s Wikipedia’s description:
“Just as a graphical user interface makes it easier for people to use programs, application programming interfaces make it easier for developers to use certain technologies in building applications. By abstracting the underlying implementation and only exposing objects or actions the developer needs, an API reduces the cognitive load on a programmer.”
In my previous post, Getting started with Network Automation, I discussed why I chose Ansible as my configuration management and orchestration tool over the other options.
In this post I’m going to discuss the the hurdles I encountered after making this decision, and of course the solutions too.
I’ve been looking into network automation for quite some time now. Originally I started off looking into automating small tasks by writing Python scripts but then moved onto configuration management and orchestration tools.
While it might sound like a pretty straightforward path, it was actually quite an interesting experience. In this post I’m going to share my thoughts in the hope that it assists others who are looking to get started in the network automation space.
What better way to start the Zero to Hero Guide than learning how to build your own ONTAP lab for free? Thanks to Neil Anderson over at FlackBox, we can do just that!
Neil has written a book which covers the entire end to end process. The book contains easy to follow step by step instructions, screenshots and diagrams to ensure that nothing gets missed. Heck, he even provides the IP addresses! The beauty of this is that even if you have zero NetApp experience, you’ll still be able to get a fully operational lab up and running in no time at all.
Anyway, without further ado, here’s where you can find Neil’s guide.
If you run into any issues with your build, be sure to reach out to Neil and he will be more than happy to help you out.