Network Automation: Configuration Management Isn’t Just for Compute Servers

At Puppet Labs, our mission is to help our customers lower the cost of technology change, while making changes faster. We’ve been doing this since 2005, originally focusing on helping system administrators manage servers running a wide range of operating systems and applications.

One of the key concepts we rely on to help reduce the complexity of systems management is resource abstraction. This simply means that it doesn’t matter how different operating systems handle a given task — we’re going to make our configuration management software work the same way for the administrator across all servers, regardless of which OS they are running. That means admins can spend less time on learning the specific implementation details of each different technology in their data center, and more time on thinking about how to design infrastructure and processes that will enable their organizations’ growth and ability to compete in the marketplace.

While Puppet Labs started with servers and operating systems, we understand that administrators want that same level of consistency across the entire data center. Organizations have to deploy applications faster to satisfy their customers and stay ahead of competitors, but provisioning and managing compute servers to run applications is just one element of that. Applications also require services, networking and storage to do what they’re supposed to do. That’s why Puppet Labs supports network and storage devices from a range of different vendors: These are also part of the infrastructure our customers rely on to deliver applications.

Before we get into the details of how Puppet Labs supports networking, let’s look at a simple use case to get an understanding of how the Puppet language works. (If you’d like to read a quick discussion of why the Puppet language was designed as it was, check out this blog post.)

Here’s how you’d add a new user with Puppet:

user { 'mike':
  ensure     => present,
  shell      => '/bin/bash',
  home       => '/home/mike'
}

If the user “Mike” doesn’t exist, the code above will create it, then set the shell and home directory. If the user does exist, this code will ensure the shell and home directory matches what’s been specified by the administrator. It will do this regardless of the operating system on which it is executed, because Puppet abstracts out the different ways users are added on any given operating system.

Notice that the Puppet code that does this work actually tells you what it’s doing, in very simple and easy-to-read language. You really don’t need to be trained on Puppet to understand what’s going on here. Two key components of Puppet’s domain specific language that make this simple code work are types and providers. A type is simply a resource that an admin wants to manage. So in our example above, “users” is the type. Providers do the actual work of implementing the procedures to manage a resource. Because resources may be managed differently on different operating systems, Puppet requires a provider for each supported OS.

So what does all this have to do with networking automation? We are extending the same concept of resource abstraction to management of network and storage devices, so that engineers can manage the full spectrum of their technology. Sure, large companies sometimes have separate teams running operations, networking and storage, but in many companies, it’s just one team managing all of that. Even in large companies, teams need to be able to work together easily and efficiently to deploy, modify and manage applications that serve the business. Having one configuration management tool that everyone can use is an important part of improving that collaboration.

To enable use of one configuration management tool across the data center, Puppet Labs is developing a standard type library, NetDev, which extends the Puppet system of types and providers to the resources network admins need to manage — for example, network interfaces, VLANs, SNMP and more.

We also announced the Puppet Supported program in June 2014. This program extends Puppet Enterprise support to storage and network devices. Vendors in the Puppet Supported program will have the option of writing Puppet providers to enable NetDev on their gear. This means that if your networking vendor has supplied a NetDev provider, you can use the same Puppet code to manage all supported resources.

Just to show you an example, the code below will configure two network interfaces on supported hardware from any vendor, using the NetDev interface type:

network_interface { 'Ethernet1':
  duplex => 'full',
  enable => 'false',
  mtu    => '9214',
  speed  => '10g',
}
network_interface { 'Ethernet2':
  duplex => 'full',
  enable => 'true',
  mtu    => '9214',
  speed  => '10g',
}

In some cases, vendors will have key functionality that’s not exposed via the NetDev type. Fortunately, this isn’t a problem, due to one of Puppet’s core strengths: extensibility.

Vendors are free to implement their own types and providers. In some cases, these vendor-supplied types may duplicate functionality found in NetDev, but more often we’d expect this functionality to be additive. Several vendors are developing specific types and providers for their network gear. These vendors want to ensure that their customers can derive maximum value from their investments in their hardware and Puppet Labs software.

As an example, the code below is an vendor-specific implementation for configuring multi-chassis link aggregation on an Arista switch:

eos_mlag { 'MLAG_Domain':
  ensure          => 'present',
  enable          => 'true',
  local_interface => 'Vlan4094',
  peer_address    => '172.16.10.2',
  peer_link       => 'Port-Channel100',
}

In the end, the real power of Puppet as a platform is that it’s extensible. NetDev provides a standard type that lets admins perform a core set of actions across multiple vendors’ hardware. But network admins can also use vendor-specific types and providers to address their particular needs. For example, if a network engineer has a lot of heterogeneous equipment to support, NetDev might be a better fit. If a network engineer needs advanced capabilities provided only by a networking vendor, the engineer would utilize the vendor-specific types and providers.

All this flexibility is on the near horizon. We expect to see supported implementations from Arista and Cumulus soon, with support from additional vendors in the first few months of this year.

Our work with network equipment companies demonstrates Puppet Labs' belief — borne out by experience with customers and community members — that all admins, regardless of what they manage, need a platform that's both highly functional and highly flexible. It's all part of the movement toward abstracting more and more of data center management away from admins, so everyone can think more clearly about business strategy, and how IT can be improved to better serve and enable that strategy.

Mike Coleman is a senior product manager at Puppet Labs.

Learn more

Puppet sites use proprietary and third-party cookies. By using our sites, you agree to our cookie policy.