No Scripting Required to Start Your Automation Journey
The “everyone should be a programmer” crowd did a really good job of scaring network engineers (congratulations, just what we need!). Here’s a typical question I’m getting:
Do I need to be good in scripting to attend your automation course.
TL&DR: Absolutely not.
I know that many networking engineers have no prior programming experience, so we start from scratch, use the simplest tool possible (Ansible), and you can go through the whole course without ever touching Python… although you’ll pretty quickly hit limits of what you can do with Ansible without custom Python filters or modules.
When you hit those limits you have two options:
- Learn some programming or
- Find someone else to do that part of the job.
As I usually explain during the course introduction, you probably invested years into understanding networking and becoming a good networking engineer. Use that knowledge in a new domain (because after all, we’re talking about network automation) instead of trying to compete with high school kids.
After all, unless you want to be a lone consultant, you probably work in a team - and as our ancestors discovered when they first formed hunting teams, division of work and competences (while at the same time keeping in touch with what other people are doing) usually gets you better results than if everyone tries to be jack-of-all-trades (and master of none).
When we add new feature to the network/system both sub-teams agree on the data model and the work is split - app guys work on the app whereas the network guys spend substantial amount of time on PoC. This involves building lab, testing and submitting issues to the vendor, etc. Once they are done they prepare configuration templates and those templates are integrated with the app.
What I want to say:
1. In this project the automation is seems as regular (nothing-fancy) work
2. The network engineers do the same work as they did in the past - the vendor sw is buggy - do not expect miracles through the automation. You still need to do PoC and try to reproduce issues. The only new skills required for the network engineer is to understand the data model + basic template scripting.
4. The deployment of configuration files is handled by the GUI app. The GUI app also visualizes the system, and allows to select system option, collects the Customer specific data and crunches all the data with configuration templates according to the data model. So in this particular case there is nothing wrong to have GUI app.
6. The huge part of the work is related to testing of what the app is supposed to generate (the actual configuration files). Again, testing consumes huge amount resources.
We started doing automation before the automation religion started - we weren't religious - it's a 'must have' since the product beginning because thanks to the automation we can reduce the *perceived* system complexity.
The user does not see boxes - it sees the sub-systems (and select one of the gazillion system options including legacy stuff) at least one level higher than what the network engineer sees.
The whole product is rather big - up to thousands configuration files are produced in the consistent way.
I have never worked in the pure IT dep. so I do not understand what REAL issues are solved by the automations in such places.
Maybe someone having real life experience could describe the benefits, especially when "standardize phase" was NOT achieved.
So it is interesting (to re-phrase my last question) how does the automation work in real life IT dep where "to simplify" task might be challenging (many exceptions, legacy support, etc).
> how does the automation work in real life IT dep where "to simplify" task might be challenging (many exceptions, legacy support, etc).
One small step at a time. :-)
First, if you have 100 switches, do you really have 100 different brands and models, or do you perhaps just have five brands and ten models?
Start then with the brand/model that you think will be the most common/important for you going forward. Identify fragments of commonality. E.g, all switches should do syslogging to $LOGSERVER, fetch time using SNTP from $NTPSERVER, and have SNMP set up to allow read using community "public", and no write access over SNMP.
Then write automation modules to make sure those things are what they are supposed to be. Even just having scripts to *check* that things are correct (and just complain if they are not) can be a big help.
You also need to nudge, cajole, bully and/or force commonality going forward. This is a multi-year project... Make sure that your users and management knows the costs of not being unique.
Identify unnecessary differences. Do you have the same linecards in the same slots in your core routers/switches, or is a certain card in slot 1 in one router and in slot 3 in the other? Is distribution switch X connected to port 17 in one core router and port 23 in the other? Do you have the same VLANs/VRFs on all the uplinks from switch Y?
Ao I know how difficult is achieve this level of automation.
This consumes huge budget. And needs good Business Case -at least be ready to answer the question "what IF we do not automate the network";)
As for the struggle - I never said automation would be easy (contrary to what some evangelists would love you to believe), but it's definitely reachable, as proven by hundreds of your peers. It just takes a lot of effort to do anything worth doing (or everyone else would already be doing it).
- Start from scratch, assuming a typical Windows user, installing a Linux/Ubuntu VM (via Virtual Box or VMware Player) to get started
- Stick to the same version of Ansible for all the demos and examples
- Stick to JUST Ansible - no GitHub, Vagrant, Docker or even Python - all of which come with their own significant learning curves
- Have separate dedicated advanced chapters much later in the course for "Ansible with GitHub" and "Ansible with Vagrant" and "Ansible with Napalm", etc.
- Encourage and assume that the audience is going through the same examples as you with you - so "Let's do this script together and see what happens"...
If you can make something like David Bombal's "Ansible for Network Engineers: Quick Start GNS3 & Ansible" course, but also go through all the same advanced stuff you go through with same kind of examples, that would be my ideal Ansible course.
You courses still did a million things right - like doing an amazing job of explaining the theories and having lots of examples. They were still very much worth the time and money in investment and I still to recommend them to others. Above are recommendations to take your Ansible offering to the next level :)
Thanks for the feedback. Most of the things you mentioned have been solved for a long long time:
* There's an "official" install script I recommend everyone not familiar with Linux uses to set up Ansible environment. The script is also on Github, and has been recently updated to Ubuntu 18.04.
* There's a separate "Ansible for Networking Engineers" course that focuses just on Ansible, and it's part of the network automation course... so there's nothing stopping you from focusing on Ansible first. It's just that I believe network automation is much more than just Ansible, and that people serious about doing network automation should realize that from day one. It's way too easy to hack together a few scripts in Ansible, call it a day, and become Expert Beginner.
* "Ansible with NAPALM" is a separate section, as is "network state validation with NAPALM"
* There's no "Ansible with Git" ;) You either use Git or you don't. However, we do have a "Getting started with Git" and even a chapter on GitOps for people who'd like to do that with Ansible.
So I guess we're almost there.
Finally, while I'd love to have "everything on a single version of Ansible" experience, that will become possible when the developers calm down and stabilize the feature set. However, they do a great job keeping the older stuff working, so (as I replied to our grumpy Anonymous friend) most everything I ever created still works.
As for "doesn't work anymore" - I was digging through the network_cli and network modules code this week updating the "Executing commands on network devices" material, and was pleasantly surprised to see all networking modules still support LOCAL connection and PROVIDER parameter (which is even abstracted into common library) - Ansible networking team did a great job maintaining a stable interface. Having said that, while most of the examples should still work, there might be things that got broken, so please feel free to submit a GitHub issue.
Finally, there's a reason I put all my examples on GitHub instead of making them part of paid course material - it's called "community". I wanted them to be useful to networking engineers who won't or can't join the course, and you're most welcome to submit a Pull Request any time you find something you think should be fixed. Not only would that move you out of disgruntled anonymity, I love to write blog posts about people who do great stuff.
Can you post the link of github where i can import to my directory. Do u have document which enlists the steps that is required to do it.