mundane

Jinja2 Templates for Network Automation

No matter how you feel about the meaning of DevOps, the impact of that culture and methodology is undeniable.  I my opinion, the single most important and transformative element of DevOps is “infrastructure as code”.

Although the phrase can be misleading to the uninitiated, the concept is beautifully simple: separate the “how” from the “what” by using templates.

Configurations of all types have these two basic tenants, the syntax or domain specific language (how) and the configuration values (what).

The configuration values are encapsulated by the DSL, and often this marriage of syntax and values creates a variety of undesirable consequences.

  • Even if the data is structured it generally does not follow a well-defined format. (Remember, we’re domain specific here).
  • It requires someone versed in the DSL to build and validate configurations.
  • External systems require custom implementations to deal with configuration programmatically.

How can we make this even more difficult?

This problem domain becomes increasingly more complex when applied to distributed systems like networking equipment.  The very nature of network services require that configurations be built and distributed across multiple systems.

As a long standing rule, these configurations are created and implemented manually by skilled network engineers.  While this practice has long been required and accepted, it comes with great cost.

  1. Network engineers are not cheap
    1. Like most technologists, they do not care for repetitive mundane tasks.
  2. This manual process has people continually re-inventing the wheel.
  3. The configurations are susceptible to human error
    1. Search for “network outage and human error”, the results may surprise you.
  4. The changelog and audit trail is difficult to gather
  5. Sharing configurations is difficult as the contain the “secret sauce”

So what are we going to do about it?

As stated at the onset, we’re going to use Python + Jinja2 Templates to create reusable templates and bits of structured data.

As a brief introduction I’ve included a training presentation I deliver.

To build further upon this, there are many great shoulders to stand on.  Jeremy Schulman aka ‘The Godfather’ has a great 5 part video series on using Jinja2.

http://packetpushers.net/python-jinja2-tutorial/

There are also various other networking advocates out there that have also created good material.

http://keepingitclassless.net/2014/03/network-config-templates-jinja2/

https://pynet.twb-tech.com/blog/ansible/ansible-cfg-template.html

http://www.jedelman.com/home/ansible-for-networking

The missing link

So what’s the missing link with all of this material?  It comes back around to the DevOps methodology.  Configurations should not only be created as templates, but their very existence should be version controlled and be the point of authority.  Having the data structured separately allows for all sorts of external systems to participate in the workflow.  From provisioning new systems to modifying existing ones, the data can be independently verified.

Keeping both the templates and data in source control also create unparalleled accountability.  The process of tracking changes over time becomes trivial – and the dreaded middle of the night troubleshooting session becomes that much easier.

How about an example

The most extensive starting point with network templates I’ve seen is produced by David Gethings of Juniper Networks.  His repository is a great representation of building templates for various devices and roles, while inheriting common templates and data.

https://github.com/dgjnpr/ansible-template-for-junos

Here is a base template for all Junos devices in the organization:

Global configuration data that has been separated out and stored as structured data (YAML).

Here is the site specific configuration data that has been separated out and stored as structured data (YAML).

So the power of this becomes apparent very quickly.  As you build out new sites the only place where data is modified is in this structured data file – it is more human readable, and straight to the point.  And because you are storing the templates and data in source control (Git), it’s very easy to track changes and have various types and versions of sites.

Rick Sherman

Automation tool builder. Integration nerd. Brilliant jerk.

5 comments on “Jinja2 Templates for Network Automation

  1. Do you know Salt from SaltStack? It use exactly the same mechanism with his “states”. It’s a complete Orchestration tools that covers a lot more but I used it to manage a distributed architechture and template all my services and network using jinja templated YAML and jinja templated conf files.
    Goog article!

Leave a Reply