A Network Engineer's Approach to Automation
•Download as PPTX, PDF•
9 likes•8,357 views
This document introduces Junos PyEZ, an open-source micro-framework for network automation using Python. It is designed for network engineers who want to automate tasks but may not have extensive programming experience. Junos PyEZ provides Python-based access to Juniper device configuration and operational data without requiring knowledge of XML or CLI screen-scraping. It presents a layered approach where users can start interactively in a Python shell and progressively build more complex scripts and applications using the Junos PyEZ abstraction layer or other open-source projects like ncclient. The project documentation is hosted on Juniper's TechWiki.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to A Network Engineer's Approach to Automation
Similar to A Network Engineer's Approach to Automation (20)
More from Jeremy Schulman
More from Jeremy Schulman (6)
Recently uploaded
Recently uploaded (20)
A Network Engineer's Approach to Automation
- 1. A NETWORK ENGINEER'S APPROACH TO AUTOMATION #NoCLI (not-only CLI) Jeremy Schulman @nwkautomaniac 2013 December
- 2. Why?
- 3. OFFICE OF THE CIO IT Automation is Top of Mind Business Agility Business Velocity Sweet Spot Business Continuity Business Value Lower Cost Reduce Risk Improve Service
- 4. APPLICATIONS DRIVE BUSINESS Server Automation Hit the "Sweet Spot" Evolution / Revolution • Server Virtualization and Cloud • History over +7 years • Open-Source Community manually configured ad-hoc bash perl scripting physical, virtual, cloud orchestration puppet, chef salt, ansible, other IT frameworks infra.apps built on IT frameworks (Hubot, Boxen) paradigm pivot-point!
- 5. COMMUNITY "TRIBES" Admins Users Non-Programmers IT Automation Engineers "DevOps" Quasi-Programmers IT Framework Companies Software Engineers Hardcore-Programmers
- 6. When?
- 7. TIME TO "LEVEL-UP" Networking must now find a way to the "Sweet Spot" Service Velocity Complexity of IT Up Time $ Tolerance for Human Error Resource Pools Budgets
- 8. NETWORK AUTOMATION Not Only Configuration Plan & Model ✔ 1 Report ✔ ✔ 5 2 ✔ 4 Troubleshoot Configure & Deploy ✔ 3 Visualize & Monitor
- 9. OFFICE OF THE NETWORK ENGINEER I am not a "Programmer" I think about the network & complex networking planning I spend a lot of my time fire-fighting the network I need automation tools to help me do my job I know I need to "level-up" with automation but I need something that helps me get started I'd like to use Python since it is shaping up as the standard
- 10. What?
- 11. NETWORK ENGINEER'S PUNCH LIST • Get started "day one" using Python interactive shell • Do it the way a network engineer thinks and interacts with the network, not like a Programmer/API • Do not require "programmy" knowledge of XML, Junos, NETCONF • Give me "CLI access" if I get stuck, but don't make me use CLI screen-scraping • Give me access to both config and operational data in standard Python types like dictionary (hash) and list • Make it Open-Source so I don't have to wait for "The Vendor" to add/fix things, enable Community
- 12. RIPPED FROM A NET.ENG BLOG Kurt Bales, Senior Network Engineer www.network-janitor.net
- 13. INTRODUCING "JUNOS PyEZ" Open and Extensible "micro-framework" • Remote device management and "fact" gathering • Troubleshooting, Audit and Reporting • Operational data • Configuration data • Configuration Management • Unstructured config snippets and templates • Structured abstractions • Generalized utilities for file-system, softwareupgrade, secure file copy (scp), etc. Check out the blog series "Python for Non-Programmers": "J-Net Forum"
- 14. How?
- 15. LAYERED APPROACH Charting a Path to the "Sweet Spot" Python Shell Python script interactive IT Frameworks Custom Applications simple → complex • Native Python data types (hash/list) • Junos specific not required • XML not required junos-pyez open-source, Juniper ncclient open-source, Community • Junos specific • Abstraction Layer • micro-framework • NETCONF transport only • Vendor Agnostic • No abstractions
- 16. CONFIGURATION CHANGES Unstructured Junos config in text, set, or XML format "snippets" that contain variables Jinja2 is template engine Structured "snippets" Resources (no variables) Structured abstractions defined by the junos-ez micro-framework Juniper + Community "templates" (merge variables) write-only read-write Junos Configuration
- 17. TROUBLESHOOTING, AUDIT, REPORTING Easily retrieve data and extract as native Python Structured abstractions defined by the Junos PyEZ micro-framework Conceptually like database tables and views that define the fields of data you want No coding required to create abstractions Juniper + Community Views Tables Junos Configuration Operational Data read-only
- 18. Where?
- 20. Follow on Twitter: @nwkautomaniac moving soon to github.com/Juniper in Jan 2014
Editor's Notes
- This is *not* a story of OpEx reduction. That story is tired and old.w/o IT automation, it's a "Pick Two" scenario: BV + BA = (-BC), too much risk to disrupt the business BV + BC = (-BA), lack of agility, cannot handle competitive pressures BC + BA = (-BV), too much churn to the business prevents growthw/IT automation, you get all three.
- "DevOps" is considered by some as the "evolution/revolution" of server admin.Networking has not reached our "Pivot Point". SDN, NFV, etc. is talked about as being this Pivot. We haven't made it thru the other side yet.Hubot: http://hubot.github.com/Boxen: http://boxen.github.com/
- Hard-core typically means classically trained (BSCS/EE)Quasi typically means may or may not be classically trained, but they have the mind to do it, and the mental environment to do itNon means they can't be in the headspace of a programmer, they just want to use tools to get things done.SometimesMr.Blue and Mr.Green are the same guy.
- the 'day one' using the shell is a real big deal. Asking a Net.Eng to "day one" write programs is hard/non-starter at times. They need to ease into it, and start interactively = CLI like experience. Also writing code requires a specific "headspace" of concentration that is generally not available to Net.Eng due to constant distractions/fire-fighting.
- http://www.network-janitor.net/2013/11/on-python-networks-and-the-py-junos-eznc-library/
- http://forums.juniper.net/t5/Network-Automaniac/Python-for-Non-Programmers-Part-1/ba-p/21644
- Need to cite URL for ncclient.
- The vast, vast, vast majority of initial users will use the 'unstructured' approach simply to kick-start device configurations (initial config). The Resources are used for lifecycle management of specific items, like adding/deleting VLANs, firewall rules, etc. The Resource map to IT framework tools that require these types of abstractions.At the time of this writing, creating new Resources requires quasi to hardcore programming skills. Work will be done in the framework to make this process easier.
- Creating Tables and View "widgets" does *NOT* require any programming. It does require someone to create YAML files (structured text) that defines what they want the abstractions to contain. This definition requires the YAML writer to understand the Junos XML structures; but it does not require them to code XML. The "understanding" part is very simple once explained (<command> | display xml rpc) and (<comand> | display xml) or (show configuration <...> | display xml).