In a previous post we discussed some network automation approaches that can provide significant infrastructure improvements with little to no upfront investments. In this blog, we’ll review two of the approaches that can help move your infrastructure from the Iron Age to the cloud era.
The diagram below depicts a Datacenter (DC) infrastructure consisting of a pair of Juniper border routers, End of Rows (EORs) or spine switches and Top of Rows(TORs) or leaf switches. Although there are several other elements that makes up a typical DC infrastructure. To keep things simple for now, we will limit our discussion to the TORs and EORs network elements. In subsequent blogs, i’ll tie all elements together and even extend the setup to include NSX and AWS.
So how do we represent our infrastructure in a programmatic manner also known as Infrastructure-as-Code (IAC), as well how do we automate configuration management and device provisioning ?
Using Ansible, we can translate our network topology into blueprints using a language called YAML. Unlike colorful Visio diagrams that are only human readable, the blueprints are both human and machine readable.But thats not the only thing !
The other thing that makes Ansible powerful is its ability to separate code from the actual data. Codes are the static or generic software placeholders.They are constants that can be reused and even shared outside of an organization .
If codes are generic constant or placeholders, then Data are those unique variable that plugs into a code to complete the representation of your infrastructure. Data is unique to your environment and they change based on your company policies, business requirements etc.
By decoupling Code from Data, we enable a level of abstraction that simplifies the definition of services that utilizes your infrastructure, reduce provisioning errors and the cost associated with managing the infrastructure.
So back to our example using a pair of TOR and EOR. We will develop a methodology to represent our code for deploying TORs and EORs in a Jinja2 template. The accompanying Data is defined in YAML files. (You can also have your data defined in a CMDB or even an excel spreadsheet).
In part 2, We’ll review what the infrastructure code and data looks like. We will then execute what Ansible calls playbook against our network infrastructure to generate appropriate configuration for each functional sub-blocks (TORs,EORs etc). Afterwards, we will push those configurations to our network devices without any human intervention.