The buzzword in the industry of late is DevOps. It is one that I hope isn’t tarnished by the marketing machine where buzzwords go to die. DevOps is the shift in the paradigm of network and infrastructure management. Centralized infrastructure that is transparent to the administrator and end-user, IaaS, cloud – whatever you want to label it – has been the catalyst in DevOps automation. This push has made us step back and look at not what we do per se, but how we do it.
The Venn diagram above shows what DevOps is and can assist with. The framework can ensure quality assurance of code and change. It can improve development of software engineering by opening APIs to be leveraged all while technology operations automates and actually engineers solutions.
Now, I am far from someone who works on a scale that requires DevOps, but this is a framework that can scale. Network engineering no longer should be mundane tasks like conf, set interfaces fe-0/0/0 unit o family inet address 10.1.1.1/24. How does mindless CLI work translate to efficiently spent time? What if you need to change 300 devices? What if you are writing it by hand? An error-prone waste of time.
Puppet by PuppetLabs allows system engineers to automate tasks across their environment. By collecting facts, a Puppet server can learn, and automated manifests can be enabled to perform tasks. Deploy a VM there, set interface & port channel settings and descriptions in a workflow. One click accomplishes many tasks, and it’s possible across many platforms or devices. This beats jumping around and spending time in a screen you’ve been in 4,000 times before.
Juniper today announced Puppet support for their 12.2R3,5 JUNOS code. This is compatible with EX4200, EX4550, and QFX3500 switches. These are top end switches, but this start is directly aimed at their DC and enterprise devices. Initially, the manifest interactions offered are interface, layer 2 interface, vlan, port aggregation groups, and device names. This definitely shows the direction of what Derick Winkworth (Cloudtoad) and his team showed at NFD4. More importantly, it shows the ground that has been made.
What follows in an example of an interface manifest that is sent from the Puppet server to the Puppet NetDev module through JUNOS to the netconf.
node "ex.ciscoinferno.net" {
netdev_device { $hostname: }
netdev_interface { "ge-0/0/19":
description => "connected to old hub",
speed => 100m,
duplex => full
}
}
The configuration generated from the above example pushed to a device would look like this:
[email protected]> show configuration interfaces ge-0/0/19 description "connected to old device"; ether-options { link-mode full-duplex; speed { 100m; } }
Getting the point? It’s much easier to send a task than sit and type those commands manually. Add this to a workflow – say for a VM deployment or new server rack – and you are no longer a monkey typing commands, but an engineer who is optimizing and scaling.
At this stage, Puppet commands exist for interface, L2 interface,VLAN, LAG groups, and device names. Albeit a small family of devices and limited functionality at this stage, Juniper has taken a great step into a larger world. This is one of the first announcements where I got rather excited. Kurt Bales skyped me the same time I opened the link, and we both agreed “Nerd Boner”. Now I don’t profess to be a DevOps programming god, nor can I lead you out of the broccoli forest of despair, but I do believe that in time, with steps forward such as Juniper’s announcement, together as an industry we can step towards the light. Heck, one day we might get to the top of the hill and see the valley of IT utopia below. Until then, we must fight our way through the broccoli.
Read more
Automate Network Configuration with Puppet for Junos OS
Puppet for JUNOS Administration Guide