A NETWORK ENGINEER'S APPROACH TO AUTOMATION #NoCLI (not-only CLI) Jeremy Schulman @nwkautomaniac 2013 December
OFFICE OF THE CIO IT Automation is Top of Mind Business Business Velocity Agility Sweet Spot Business Value Business Lower Cost Continuity Reduce Risk Improve Service
APPLICATIONS DRIVE BUSINESS Server Automation Hit the "Sweet Spot" Evolution / Revolution • Server Virtualization and Cloud • History over +7 years • Open-Source Community physical, virtual, cloud orchestration infra.apps built on IT puppet, chef frameworks salt, ansible, (Hubot, Boxen) other IT ad-hoc bash frameworks perl scripting manually configured paradigm pivot-point!
COMMUNITY "TRIBES" Admins Users Non-Programmers IT Automation Engineers "DevOps" Quasi-Programmers IT Framework Companies Software Engineers Hardcore-Programmers
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
NETWORK AUTOMATION Not Only Configuration Plan & Model 1 Report 5 Configure 2 & Deploy 4 3 Visualize & Troubleshoot Monitor
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
NETWORK ENGINEER'S PUNCH LIST • Get started "day one" using Python interactive shel • 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
RIPPED FROM A NET.ENG BLOG Kurt Bales, Senior Network Engineer www.network-janitor.net
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, software-upgrade, secure file copy (scp), etc. Check out the blog series "Python for Non-Programmers": " J-Net Forum"
LAYERED APPROACH Charting a Path to the "Sweet Spot" IT Custom Python Shell Python script Frameworks Applications interactive simple → complex • Native Python data types (hash/list) • Junos specific not required • XML not required junos-pyez • Junos specific open-source, Juniper • Abstraction Layer • micro-framework ncclient • NETCONF transport only open-source, Community • Vendor Agnostic • No abstractions
CONFIGURATION CHANGES Unstructured Structured Junos config in "snippets" text, set, or XML format (no variables) Resources Structured abstractions "snippets" that contain variables "templates" defined by the junos-ez micro-framework Jinja2 is template (merge variables) Juniper + Community engine write-only read-write Junos Configuration
TROUBLESHOOTING, AUDIT, REPORTING Easily retrieve data and extract as Structured abstractions defined by native Python the Junos PyEZ micro-framework Conceptually like database tables No coding required to create and views that define the fields of abstractions data you want Juniper + Community Tables Views Junos Operational Configuration Data read-only