Agent-Based Automation Tools

the benefits and operations of the various agent-based automation tools.

• This section covers a number of agent-based tools as well as some of the key concepts to help network operators decide which tool best suits their environment and business use cases.

Puppet

• Works with many different vendors and • A commonly used tools used for automation.
• Used during the entire lifecycle of a device, including initial deployment, configuration management, and repurposing and removing devices in a network.
• Puppet uses a puppet master (server) to communicate with devices that have the puppet agent (client) installed locally on the device.
• Changes and automation tasks executed within the puppet console and then shared between the puppet master and puppet agents.
• These changes or automation tasks stored in PuppetDB so that the tasks saved to be pushed out to the puppet agents at a later time
• Illustrates the communications path between the puppet master and the puppet agents, as well as the high-level architecture.
• The solid lines show the primary communications path, the dotted lines indicate optional high availability.

• Puppet agents communicate to the master by using different TCP connections. TCP ports uniquely represent a communications path from an agent running on a device or node.
• Puppet can periodically verify the configuration on devices. This can be set to any frequency that the network administrator deems necessary. If a configuration changed, it can be alerted on, and automatically put back to the previous configuration.
  siness’s needs.

   

  Other useful information:

  • Full ENCOR Course
  • CCNP Enterprise Certificate Information
  • 350-401 ENCOR Exam Questions and Solutions
  • 350-401 ENCOR Exam Topics

• In a very large scale environment, best practices are high availability and centralized management.
• Admins may need a master of masters (MoM) to manage the distributed puppet masters and their associated databases.
• Large deployments also need compile masters, which are load-balanced Puppet servers.

Puppet Modules

• Puppet modules contain these components:
  • Manifests
  • Templates
  • Files
• Manifests are the code that configures the clients or nodes running the puppet agent.
• Manifests pushed to the devices using SSL and require certificates to ensure the security of communications between the puppet master and the puppet agents.
• Manifests saved as individual files and have a file extension .pp.
• One module called cisco_ios, contains many manifests and leverages SSH to connect to devices.

Puppet Manifest

• This example shows that the NTP server IP address is configured as 1.2.3.4, and it uses VLAN 42 as the source interface. The line ensure => ‘present’ means that the NTP server configuration should be present in the running configuration of IOS device on which the manifest is running.

• An example of a manifest file, named NTP_Server.pp, that configures a NTP server on a Catalyst device.

Puppet Manifest

• Puppet leverages a domain-specific language (DSL) as its “programming language”, based on the Ruby.
• a manifest file called MOTD.pp that is used to configure a message-of-the-day (MOTD) banner.

Chef

• An open source configuration management tool.
• Written in Ruby and Erlang, using Ruby for writing code within Chef.
• Configuration management tools function in two different types of models: push and pull.
• Chef is similar to Puppet in several ways:
• Both have free open source versions available
• Both have paid enterprise versions available
• Both manage code that needs to be updated and stored
• Both manage devices or nodes to be configured
• Both leverage a pull model
• Both function as a client/server model

Chef’s Structure

• Chef’s structure, terminology, and core components are different from those of Puppet.

Chef Components

Although the core concepts of Puppet and Chef are similar, the terminology differs. Whereas Puppet has modules and manifests, Chef has cookbooks and recipes.

Chef Components

• Code created on the Chef workstation. This code is stored in a file called a recipe
• Once a recipe is created on the workstation, it must be uploaded to the Chef server in order to be used in the environment. knife is the name of the command-line tool used to upload cookbooks to the Chef server.
• The command to execute an upload is knife upload cookbookname.
• The Chef server can be hosted locally on the workstation, hosted remotely on a server, or hosted in the cloud.

There are four types of Chef server deployments:

• Chef Solo – The Chef server is hosted locally on the workstation.
• Chef Client and Server –This is a typical Chef deployment with distributed components.
• Hosted Chef – The Chef server is hosted in the cloud.
• Private Chef – All Chef components are within the same enterprise network.

Chef Server

• The Chef server sits in between the workstation and the nodes.
• All cookbooks stored on the Chef server which holds all the tools necessary to transfer the node configurations to the Chef clients.
• OHAI collects the current state of a node to send the information back to the Chef server through the Chef client service. The Chef server then checks to see if there is any new configuration that needs to be on the node by comparing the information from the OHAI service to the cookbook or recipe.
• When a node needs a recipe, the Chef client service handles the communication back to the Chef server to signify the node’s need for the updated configuration or recipe.

Recipe File

Example 29-8 shows a recipe file constructed in Ruby.    

SaltStack Overview

• SaltStack built on Python with a Python interface so a user can program directly to SaltStack by using Python code.
• However, most of the instructions or states that get sent out to the nodes are written in YAML or a DSL. These are called Salt formulas.
• Another key difference from Puppet and Chef is SaltStack’s overall architecture.
• SaltStack uses systems, which are divided into various categories.
• SaltStack has masters and minions.
• SaltStack uses a distributed messaging platform called 0MQ (ZeroMQ). SaltStack is an event-driven technology that has components called reactors and beacons. A reactor lives on the master and listens for any type of changes in the node or device that differ from the desired state or configuration.
• Beacons live on minions. If a configuration changes on a node, a beacon notifies the reactor on the master. This is the remote execution system and it helps determine whether the configuration is in the appropriate state on the minions. These actions are called jobs which when executed can be stored in an external database.

SaltStack Overview

• SaltStack uses pillars and grains to control state and send configuration changes.
• SaltStack grains run on the minions to gather system information to report back to the master.
• This information is typically gathered by the salt-minion daemon.
• Grains can provide specifics to the master about the host.
• Pillars store data that a minion can retrieve from the master. Minions can be assigned to pillars.
• Data can be stored for a specific node inside a pillar, keeping it separate from any other node that is not assigned to this particular pillar.
• Confidential data can be secured and only shared with assigned minions.

SaltStack Architecture

• SaltStack can scale to a very large number of devices.
• has an enterprise version and a GUI called SynDic.

SaltStack CLI

• SaltStack has its own DSL.
• Command structure contains targets, commands, and arguments.
• The target is the desired system that the command should run.
• The command structure uses the module.function syntax followed by the argument.
• An argument provides detail to the module and function that is being called on in the command.

Other useful information:

• Full ENCOR Course
• CCNP Enterprise Certificate Information
• 350-401 ENCOR Exam Questions and Solutions
• 350-401 ENCOR Exam Topics