- [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.