Today’s post is part of a series on how to develop an automation infrastructure in your environment. While there are a wealth of resources on how to setup an automation pipeline, to me it seems like there are missing pieces of the puzzle. This series will document how I build automation into my home network.

Goals

So what are the goals for this series? It comes down to a few major components:

• A Domain-Specific Language (DSL)
• A Configuration Generator
• A Configuration Validator
• A Continuous Integration and Continuous Deployment (CI/CD) Pipeline

By the end of this series, I aim to no longer have to login to a device to make a change. I will be experimenting with a bunch of different tools and services along the way, and seeing what works and what doesn’t work in my network. You’ll be able to see all the mistakes and pitfalls I make along the way, and hopefully you will be able to learn from them.

Network Environment

My network is a fairly simple one – one firewall, one switch, one wireless controller, and a development server. A diagram is shown below:

As you can see, the Administrators must manually login to the CLI, Web UI, or Development servers directly to create new services, add network configurations, or make changes to network security. Because this network is simple, I should be able to quickly set up needed components, and adapt them to my needs.

This is a well-known “gotcha” when first starting automation; you won’t be able to complete full blown automation on your entire network in one fell swoop. Iterative improvements over smaller network segments will help you in your automation deployment. In my case, I’ll be focusing on the deployment of configurations on the switch and gateway devices. If there is time, and code examples, I’ll add in automation components to the wireless controller and development servers as well.

Stay tuned to this blog – as our first topic will be about Capirca, Google’s open-source multi-platform configuration generation system.