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.
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.
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.
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.
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
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.
You want to reuse excellent bits of your code in multiple projects
and package them as ready-to-use libraries, right? Let’s dig
into playbook- and play-level includes, looping over included
modules (which is the closest you can get to subroutine calls in
Ansible), and Ansible roles.
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.
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.