Network operators must begin to leverage automation tools to assist with workload on-boarding. One such automation tool is Puppet, which can be leveraged with Open NX-OS to enable:

• Intent-based configuration, dramatically decreasing configuration steps and deployment times
• The application of common tooling and skillsets across both server and network teams, decreasing operation costs
• Visibility into configuration change management history that aids in compliance monitoring

Although Puppet-based automation can be applied to many workload on-boarding problems, the example below focuses on a specific and particularly troublesome problem of access-port provisioning.

Historically, access-port provisioning has been a manual, labor-intensive, and error-prone process. With Puppet intent-based automation and Open NX-OS, processes that previously took hours or days can be completed in minutes, and with little potential for errors.

At the core of this use-case is the extensibility of open NX-OS Linux which allows for the integration of third-party software agents using RPMs. This use-case involves using a Puppet Agent to enable intent-based automation of the switching infrastructure.

The solution architecture, illustrated below, consists of the following component pieces:

• A Puppet Master server
• A Cisco Puppet module
• A Puppet Agent / service which utilizes the NX-API CLI utility to configure the switch

Open NX-OS Agent-based Configuration Management (such as Puppet) Architecture

Puppet Domain-Specific Language

Puppet uses its own domain-specific language (DSL) to describe machine configurations and model resources. The declaration of resources is key to the Puppet DSL. When one resource depends on another, you should explicitly state the relationship to ensure that they are applied in the proper order.

The Puppet Resource Model Consists of two layers – Types (or Resources) and Providers. Types/Resources specify the interfaces used to describe resources in Puppet. Providers encapsulate the procedures used to manage resources on a specific platform.

Types and Providers Supported Out-of-the-Box by the Cisco Puppet Module

Puppet Manifests

The configurations for each node under management are written using the DSL language mentioned above. Code in this language is saved in files called manifests.

For complete information about the Puppet language see https://docs.puppetlabs.com/puppet/4.2/reference/lang_summary.html.

Manifests are files containing Puppet code on the puppet master server. They are standard text files saved with the .pp extension. Manifests should be arranged into modules that specify the configurations that should be applied to the node.

See https://docs.puppetlabs.com/pe/latest/puppet_modules_manifests.html#puppet-modules for more information on Puppet manifest modules.