Puppet, Chef, and Ansible

Selecting transcript lines in this section will navigate to timestamp in the video
- [Instructor] I'll start by covering some of the issues that automation tools like
Puppet, Chef and Ansible solve. First is configuration drift. Many networks use
templates to build their configurations from. Once these devices are live and in
production, they would generally follow a standard configuration change process.
Where changes are built and checked before application. Once a change is made,
documentation is updated and all network engineers have a good idea of what
happened and why. That can all go out the window during break fix conditions. When
I get a call at 3 am and make changes to fix an issue, I generally wait until the
next day to update documentation. Often, after a change like that one, I return to
the office the next day I hit the ground running and I may not communicate
everything that happened with my fellow engineers. The real problem happens when
these configuration drifts occur, and they are not communicated. I've run into
plenty of routers where I find a piece of config that makes absolutely no sense, or
if it does make sense, I have no idea why it's there. Systems may be in place to
backup configurations or even the log individual changes and who made them. What
these systems don't document, is why the changes were made. Often enough to
configurations on devices are the main source of truth, with backups being made
regularly by a server. The source of truth is a concept used with automation
products. The source of truth is a variety of information like configurations, IP
addresses, and device state metrics. It's a repository for how equipment should be
configured, more and more enterprises are moving to keep the source of truth on a
server. Letting automation tools reach out to network devices and making their
configurations match that source of truth. Keeping the source of truth centralized
is good for version control, as it's easier to track what changes have been made
and why. When using a central repository, changes are made and saved there. The
automation tools, then automatically or when directed to, will apply the changes to
the corresponding devices. Something else interesting is what happens when changes
are made directly to a device that is managed by an automation tool. Monitoring can
be done by the tool to recognize and alert on these conditions, or the tool can
adjust the device to match the source of truth. When the centralized configuration
has been changed, apply these changes to the device. Devices should be broken into
group, which allow administrators to pick and choose which devices are updated and
when. Use logic to determine if changes were successful or not. If not all changes
were successful, revert back to an original configuration state. An automation tool
should be able to test changes without actually applying them. Templates should be
able to be used that allow for variables to be replaced. And last, the ability to
schedule changes is also fairly standard with automation tools. Puppet, Chef and
Ansible are all different products that have open source or free versions, as well
as paid options. Each tool is generally installed on a dedicated virtual machine.
It's most common to load these tools on a dedicated Linux install, as Windows
support can be a bit spotty. Ansible is my favorite tool of the three. Ansible by
default uses a series of files for configuration. Playbooks contain a series of
logic and actions that should be performed. These files are in YAML format, which
are actually quite easy to read. YAML is an acronym that stands for, YAML Ain't
Markup Language. Inventory files list a series of devices and groups of devices
along with attributes for each. Templates are facilitated via the Jinja2 language.
Ansible reaches out to devices to make changes, where the other two by default
prefer to use clients in most instances. Ansible connects and makes changes via SSH
and NETCONF. This makes virtually any device with SSH access a candidate for
automation. After the files are configured by an engineer, a playbook is then run.
The playbook then pushes these changes to the requisite devices. Puppet is
installed on a Linux server known as a Puppet Master. Puppet 2 configures text
files. First is a manifest, which defines the desired configuration of a device.
Next, the manifest are made of modules, which contain classes that have resources.
Templates are comprised of a Puppet specific language, that allows for variable
substitutions. Puppet requires an agent and some Cisco kit actually does have a
supported agent. For all others, Puppet uses a proxy agent. The proxy will accept
commands from Puppet, then SSH to the required device and make the required
adjustments. A Puppet engineer starts by editing configuration files. A proxy agent
or an on device agent must then be configured. A Puppet agent then pulls rather
than push like Ansible, what its configuration should be. If the agent requires
updates, it will pull them otherwise it won't. Chef is another software package
that is most often installed on a server, though it can be run in standalone mode
known as Chef Zero. Once installed, Chef 2 has a series of configuration files.
Resources are part of the configuration and their desired state. A recipe is the
logic applied to know when and how to act against the resources. A cookbook is a
group of recipes. A run list is a list of recipes in a specific order, to be run
against a specific device. Chef requires a client running on the end device to be
controlled. There's very little support in Cisco kit, thus it's much more likely an
engineer will use Ansible or Puppet. Automation should be part of your network. If
it's not now than it will be in the future. Automation should be part of your
network. If it's not now than it will be in the future. It's best to spend time on
it now, rather than trying to play catch up later.