This webinar focuses on Ansible, the configuration management tool most
commonly used by network automation professionals. It also describes
YAML, the text file format used by Ansible, and Jinja2 templating language.
When facing a long study process, it makes sense to start with
“what are we doing”, “why are we doing it” and “how is the
material structured”. This section will give you these answers,
and a procedure you can use to set up a simple Ansible test environment.
18:58
Case Study: DMVPN Router Configuration Generation and Deployment
One of the simplest network automation use cases is the automated
network generation using unified device templates. We’ll
illustrate this concept with a DMVPN deployment case study
that runs throughout this webinar and includes data model
generation, sample device templates, and configuration
deployment with Ansible.
YAML is the data presentation language used extensively by
Ansible playbooks and variable files. JSON is the presentation
language used between Ansible and external components.
It obviously makes sense to be familiar with both,
and you’ll have to understand the basics of YAML to
write your playbooks.
26:15
Case Study: Building the Data Model with YAML
The second step in any automated service (or infrastructure) deployment should be a
well thought-out data model (the first one should be a service definition). This
section describes how you can generate a typical data model, or extract it from
sample router configurations, and write it as a series of YAML files that can
be used by Ansible playbooks.
1:20:47Free items
Jinja2 - the Templating Tool Used by Ansible
You might think you’d need a templating tool only when generating device (or service
or software) configuration from templates. Not true - Ansible uses Jinja2
extensively, from evaluating expressions to specifying conditions, and finally
generating text files from templates. Without understanding Jinja2 you’ll
have a hard time understanding even moderately complex Ansible playbooks.
14:18
Case Study: Creating Device Configurations with Jinja2 Templates
Next step in our case study: after building a data model describing our
DMVPN deployment, we’ll create Jinja2 templates that will be used to
create device configurations.
Finally it’s time to get our hands dirty and do some real automation work.
You’ll learn about Ansible inventory, authentication mechanisms, Ansible
modules, and the basics of Ansible playbooks - just enough to generate
device configurations from templates or execute simple commands on
network devices.
Ready for some headier Ansible stuff? Let’s explore the details of Ansible
facts and variables, play and task execution (including error handling),
implementing loops, working with files, and using exotic Jinja2 filters.
It’s time to work with real network devices. You’ll learn how to log
into network devices, execute commands on them, and get device facts
and operational data.
1:19:21
Ansible Networking Modules - Getting Operational Data
Most network automation projects include gathering of operational data from network devices,
be it to check device state before deploying new services, validate service deployment,
or generate network maps or reports.
Some network devices can return data in machine-readable formats like XML or JSON, in many
cases we still have to dismantle printouts returned by various show commands into
data structures. This section describes Ansible fact gathering, working with devices
that return data in JSON or XML, and parsing text printouts with TextFSM, Cisco's Genie, and TTP.
Ansible is a powerful tool, but it shouldn’t be used as a generic-purpose
programming language, so don’t try to use it as a Swiss Army Chainsaw -
complex tasks should be implemented with a real programming language
using Ansible callbacks, modules, external components,
or (simplest possible option) Jinja2 filters and tests.
Debugging Ansible playbooks and Jinja2 templates and expressions
could turn into an excruciating experience. The guidelines and
hints you'll get in this section will make your debugging process
easier and faster.
Ansible includes low-level network device modules - you have to
use a different module for every vendor or operating system.
NAPALM provides an abstraction library that gives you a uniform
interface to device configurations, operational data, and even
fully-automated device state validation… with an
easy-to-use set of Ansible modules.
NAPALM includes state validation functionality that compares
the actual state of a network device (as retrieved with NAPALM
getters) with the desired state defined in a YAML file and
reports the discrepancies. The same functionaliy can be
used independently or from within an Ansible playbook.
After building the network-centric data model, we'll use it to validate fabric
connectivity using information gathered with LLDP. You'll also learn how to
translate data models on-the-fly within an Ansible playbook.
In the final part of the case study, we'll build OSPF configurations, figure out
what changes they would cause on the fabric devices, deploy them, and finally
verify that OSPF routing process sees the expected neighbors on fabric links.
This section contains links to various documents describing how you can build your own
network automation lab using either physical or virtual devices.
This document should help you get started - it discusses numerous lab setup options,
including sample lab setups created by attendees of our network automation course.
Vagrant uses poorly-documented internal virtual networks. This document describes the various
ways of establishing connectivity between Ansible running in a Vagrant-controlled virtual
machine and other virtual machines controlled by the Vagrant instance.
This simple tool creates Ansible inventory files from Vagrant port forwarding printouts
and supports running Ansible on the host or in a Vagrant-controlled VM. Highly recommended
when running Vagrant with VirtualBox.
