End-to-End Terraform - Now Including Junos! | Official Juniper Networks Blogs

One bee working alone can accomplish a great deal of work. However, multiple bees working together can build an entire colony. This same principal applies to technology; configuring one switch at a time moves a project forward, but automation changes the scale of implementation with transformative effect.

Infrastructure-as-Code (IaC) provides a transformation catalyst, and it’s imperative that the tooling and methodologies are up to the job. Hashicorp’s Terraform enables organizations to drive automation through managing the network’s desired state, and Terraform takes care of the hard work of figuring out what to create, update and delete. In 2018, a small Juniper Networks team embarked on a journey to align against graph-driven automation because of the many benefits it brings, and that’s the Terraform’s spirit shined brightly. For technology-driven organizations that have aligned with Terraform, Juniper’s Terraform Automation Framework (JTAF) provides a means of extending the point of control to physical and virtual network elements that run Junos, enabling collaborative and seamless automation.

It’s our great pleasure to announce that Juniper and Hashicorp have signed an Alliances Partnership agreement. In this blog, we’ll outline the first wave of deliverables in support of this partnership, and for ease of use and an enhanced user experience, Juniper has created and uploaded a vSRX Terraform Provider to the Hashicorp Terraform Registry, with more to come in the future.

Terraform and Junos Deliver Top-to-Bottom Automation of the Entire Stack

Terraform provides organizations with a Day 0 through Day 2 tool that uses Hashicorp Configuration Language (HCL), which is a a simple runtime language, and a rich ecosystem of plugins, called providers. The Terraform tool itself is a statically compiled binary, meaning that users do not have to concern themselves with application dependencies, and it can run on any platform that has Go compiler support. HCL reduces inputs to essential key-value pairs with some basic processing logic. In short, users do not have to be programming language experts to make the best of Terraform, nor have the skill to build an automation system through dynamic languages such as Python.

Each Terraform provider offers a number of declarative resources it can manage. For example, a resource could be an EC2 instance on AWS, or in Juniper’s case, a BGP peer or firewall rule on Junos. Terraform users gain the use of the Terraform operational semantics to control the Junos configuration as they would to deploy cloud resources. This allows one tool not only to control infrastructure deployments, but also the configuration of the network that attaches to the underlying infrastructure as well as the applications. The power of Terraform is top-to-bottom automation of the entire stack.

Network automation tools have traditionally focused on independent actions such as create or update steps. Terraform comes with the full set of Create, Read, Update and Deletion (CRUD) verbs out of the box, and the result is that deleting a resource is as easy as creating one; it’s just an invocation of the Terraform tool with the correct verb. The workflow designer does not have to work with anything other than the resources they are interested in.

Terraform achieves idempotency and state management by storing the local state and comparing it with the remote state. If Terraform detects that the state of the remote resources does not match the desired state, then Terraform will propose a plan to make them match. With the importance of local state, it’s imperative that it’s handled appropriately and either backed-up or handed off to a back-end such as AWS S3, Consul or ETCD [1].

With tools focused on the order of workflow tasks, dependencies are implicitly managed, whether the consumer realizes it or not. For the purposes of exploring the following text, let’s assume Alice wants to create a BGP peering session over a physical link. From a traditional networking aspect, this could be one configuration commit, however it makes sense to isolate the BGP and interface configuration. In this example, the BGP resources are dependent on the interface resources. Furthermore, we can group these resources into modules, which are nothing more than logical containers. With Terraform, the user has the power to create explicit dependencies between resources in a flat file or across modules, which is a very powerful concept.

At runtime, Terraform will create an in-memory graph model of the desired set of resources, which already accounts for the dependencies. This in-memory graph will be traversed and Terraform actions, such as “plans” and “apply”, can be issued through the application.

Let’s Talk Multicloud

Because Terraform offers HCL, there’s a single set of semantics and constrained syntax. This means creating a resource in AWS, despite having a different name and different set of inputs that have the same style or feel as creating a resource in Azure. Some key names will differ along with the resource names, but the semantics remain the same. A good designer will determine what inputs are required and put them into a dataset for Terraform to consume, thus normalizing the experience for multicloud configuration.

Terraform is, however, still an Infrastructure-as-Code (IaC) tool and as such, offers no insight into what the intent of the user is. Terraform views the world through resource management lenses, and it’s the responsibility of the workflow designer to figure out what the workflow should be doing.

Robust automation is key to real progress, and it’s normal to see organizations insert management-plane and operational unit and integration tests after committing configuration changes. Terraform, right out of the box, supports change validation. It does this by reading back the remote state immediately after create or update steps. This means Terraform users do not have to use tools like Juniper’s jSnapy to validate the management-plane state. While Terraform doesn’t manage operational testing, there’s nothing stopping a designer from creating additional resources that trigger those tests on a Network Management System (NMS) system or telemetry system, such as Paragon Insights (formerly Healthbot).

The data center network operational experience improves dramatically as organizations pivot around fewer tools. As more network architects, engineers and operators become proficient in the reduced toolset, employee attrition goes down and reaction times go up. In addition, operational knowledge becomes embedded in easily readable HCL that any team member can understand and re-use. If staff decide to move on, tribal knowledge that would otherwise leave with them is now safe and easily understood.

Cloud-to-Network Control with Terraform

When provisioning a virtual machine (VM) or container onto a cluster, it’s important to ensure that the infrastructure can communicate with whatever has been provisioned. Juniper’s providers and those created by JTAF can provision required primitives like VLANs, access lists, firewall rules and more, while existing providers handle the provisioning of the infrastructure, e.g. spinning up a vSRX Virtual Firewall in the hosted environment.

Approaching the Variance Problem

Consistency reduces variability, which drives reliability and ultimately, speed. Due to the wide nature of Junos support across many platforms and a growing number of releases per platform, it wasn’t practical to create a single provider without introducing compatibility issues. As a result, Juniper established a framework that creates Terraform providers for the platform and a version of Junos that users are working with.

With Junos, there are thousands of configuration options, many of which are used by less than five percent of Junos consumers. In this case, it doesn’t make sense to take the ‘kitchen sink’ approach and include everything. Juniper’s logic is to provide inputs to JTAF as part of the normal creation steps, which tells JTAF what to include in the provider. For BGP and interface configuration, the user should include those resources. When it comes to the DevOps or SRE aspects of using such a tool, the input artifacts to JTAF can be version controlled, as well as the outputs of JTAF. This approach ensures that providers have just the right capabilities that are version matched to the platform and version of code that’s being worked with.

Conclusion

As of October 2021, Juniper Networks became Hashicorp Alliances Partner and is committed to delivering a system of right-sized customizations to Terraform providers. This partnership is a proofpoint of our joint mission to provide a harmonious experience and world class IaC solution.

JTAF gives operations teams the power of building providers that are version controlled and matched exactly to the Junos based network platform and Junos software version. The video below provides a walkthrough of building a provider with JTAF 1.5.