A bit about DevOps and Network Operations (NetOps)
For now I will assume we have all heard about DevOps. In a nutshell, DevOps is a software or systems development methodology that stresses communication, collaboration, and integration between software or systems developers and operators such as IT administrators.
For me, the key to a embracing DevOps is truly referenced by the notion of CAMS - which stands for Culture, Automation, Measurement, and Sharing. This notion transcends all domains whether it’s the physical or virtual device management and whether it’s a server or a network switch.
However, the transformation of DevOps practices into network operations (NetOps) is not as straightforward as the adoption of these practices in the virtualized server environment. The rigid operational environments and resource limitations on network devices make it much harder to carve out a test network from a production network than it is to spin up test virtual machines (VMs) on a production compute server. Despite these types of challenges, network operaters have embraced DevOps methodologies. An IT environment that can automate and orchestrate everything but the network would not be quite as efficient as an environment that could orchestrate the entire infrastructure. There is a way to test network configuration changes or produce reliable network configuration changes without risking a production environment. Automation is being done using some of the same tools that are already being used by the DevOps folks. There are four leading configuration management solutions being used by the Devops community and how they can be leveraged for NetOps – they include Puppet, Chef, Ansible, and Salt.
We still have a long journey ahead for network operational nirvana through automation, but we have a good start.
Puppet for Junos
Puppet is a configuration management (CM) system that provides a way to define the state of your IT infrastructure, and enables automatic enforcement of the correct state. It was initially released in 2005, and developed by Puppet Labs in Ruby. Puppet provides an efficient and scalable software solution for managing the configurations of large numbers of devices. System administrators use Puppet to manage compute resources such as physical and virtual servers and network devices. Puppet is deployed using a client/server arrangement, where the server—or Puppet master— manages one or more client nodes. The client daemon—or Puppet agent—runs on each of the managed resources.
Juniper switches and routers (QFX, EX, MX) running Junos OS now support Puppet software for configuration management. The Juniper “netdev” Puppet module provides network resource types for configuring:
L2 switch ports
Link aggregation groups
Specific to Junos operations, when using Puppet to manage Junos OS-based devices, the Puppet agent ensure that configuration changes occur under exclusive lock. It logs all commit operations with a Puppet catalog version for audit tracking purposes. The Puppet report logs include a Junos OS source indicator for log entries specific to Junos OS processing and tags associated with the operation or error to enable easy report extraction.
Chef for Junos
Chef was originally released in 2009 by Opscode, and is very similar to Puppet. Chef is also written in Ruby, and its CLI also uses a Ruby-based DSL. Chef utilizes a master-agent model, and in addition to a master server, a Chef installation also requires a workstation to control the master. The agents can be installed from the workstation using the ‘knife’ tool, easing the installation burden. Continuing with the kitchen metaphor (see ‘knife’ above), Chef configs are packaged into JSON files called ‘recipes’. Also, the software can run in either a client-server or in a standalone mode called ‘Chef-solo’. DevOps professionals bundle multiple recipes into Chef cookbooks to make orchestrated configuration changes across multiple types of devices.
The Chef agent is supported on the same Junos OS based devices as Puppet. The Juniper Chef module provides options for configuring (same as Puppet) - Physical interfaces, L2 switch ports, VLANs, Link aggregation groups. Similar to Puppet, for Junos operations, the Chef agent makes configuration changes under exclusive lock, and logs all commit operations.
Ansible for Junos
Ansible is quite different from Chef and Puppet. It was developed by AnsibleWorks and initially released in 2012. It is written in Python and only requires the Python libraries to be present on the servers to be configured. Ansible does away with the need for agents (agent-less); all master-agent communication is handled either via standard SSH commands, or the Paramiko module which provides a Python interface to SSH2. It is thus more light weight, and has relative ease of use and speed of deployment compared to other CM tools. Ansible packages all commands into YAML modules called playbooks.
The Juniper Networks Ansible library, which is hosted on the Ansible Galaxy website, enables you to use Ansible to perform specific operational and configuration tasks on devices running Junos OS, including installing and upgrading Junos OS, deploying specific devices in the network, loading configuration changes, retrieving information, and resetting, rebooting, or shutting down managed devices.
Although Ansible normally requires Python on the managed nodes, it is not required when
managing devices running Junos OS.
There are five Python modules that have been developed for Ansible for Junos OS support. These include: