Our Cloud & Infrastructure team is often involved with designing, building, and deploying new networks, which includes writing configuration text files for network devices for QA purposes before they are deployed to the device. While that method was sufficient for projects that only required 2-3 site configurations be written, projects in the last few years have involved development of 15-50 uniform site configurations. Writing configuration files by hand using a text file template and having someone review them by eye presents accuracy and efficiency challenges, so we began searching for a better method in the hope of streamlining the process by improving accuracy and decreasing time spent on writing configurations or performing QA on them.
Network automation has exploded in recent years, especially with the rise in DevOps principles and cloud technologies built around it, so we were confident that there had to be a tool out there that could help us automate our network configuration building, it was just a matter of finding the right one. This blog describes a simple use case of the journey we took using Ansible.
Ansible is a system automation tool that was originally focused on agentless administration of Linux servers. The project has grown significantly since its inception, and now enables orchestration of nearly anything that has SSH, WinRM, or PowerShell capabilities. Leveraging programming concepts such as variables, arrays, for loops, and if statements, Ansible can pair template files with variables to make dynamic and logic-driven changes to systems. Ansible also has the ability, through modules, to output to a flat text file instead of a live host, which was exactly what we needed to achieve our goal of automating device configuration builds
We reviewed Ansible, learned the directory structure with playbooks, hosts, roles, tasks, and determined a list of required files that the tool needed produce to comprise a full device configuration. Referencing the network design document that we had produced for our client, we developed variables files for each site configuration, and wrote from scratch the jinja2 template file to which these variables would be applied. It took some trial and error to refine the template programmatic logic, but once we had a working template, it only took about 20 seconds for the engine to make us our 15+ site configurations, something that previously would have taken us days to complete and hours of QA to correct errors; this represented a significant improvement in efficiency in our process.
Our team now has a tool that can be used to create site configurations for new sites using a template engine, reducing misconfiguration errors that can lead to failed deployments or additional required troubleshooting efforts. This was a simple yet meaningful start to become more familiar with network automation tools. As the team becomes more comfortable with Ansible, we look to develop operational use cases for common device and service changes to help our clients streamline their operations as well as make bulk configuration changes, but for now, the tool has proven to be an efficient and repeatable method for building device configurations for new deployments.
If you’re interested in learning more contact us.