Career in Network Automation: 100% Open-Source Cisco NetDevOps CICD Pipeline Walkthrough and Demo

In the last several articles, I made a case that as a network engineer, when you look back at 2020 say in three years, you will realize that it was the year that kicked the network automation into high gear. It is super critical to note that network automation isn’t about using network programmability or Python.

It is not even about SDN or NFV or another new shiny object. It is not even about the networking coming to the DevOps. Wait a minute. So, what it is about? My friends, it is about applying the DevOps principles and practices to the network like what happened to the system administration 10 years ago. Technically speaking, it is about applying the version control and the CICD pipeline tools to the network creation, testing, monitoring, and deployments. It is as real as it can get this time around and as far as I can tell, the whole COVID situation, i.e., employees working from home thus deploying and maintaining network stacks and services remotely, will only accelerate this trend. What am I talking about? Sure, there is a learning curve but there is no time like this moment to get started.

In this article, I want to walk you through my 100% open source NetDevOps CICD pipeline that you can use to deploy your network infrastructure as code, and by learning this, really transform your career from network engineering to Network DevOps. There is also a demo and a giveaway at the end of the video where you can see the whole pipeline in action. If you’re a network engineer and have been on the fence about learning network automation, this will be transformational. Guaranteed!

SO, here are the building blocks that I used to put together my 100% open source NetDevOps CICD pipeline. Let’s go through this together in a bottom-up fashion.

NetDevOps CICD Pipeline Overview

At the very bottom of the stack, I have my Intel-based Mac running macOS Big Sur. I am running VirtualBox as the VMM with one VM that contains my entire software stack including the Linux OS. I am running Docker for container creation and management. I am using Gitea as the Git server for the configuration version control. Git is the central repository for all my network configurations, and it is what kicks off my build server and the entire CICD pipeline. I am using Drone as the build server. I am using Ansible for network configuration deployment, whether that’s for the unit or integration testing or final deployment to the production network. Since NetDevOps CICD pipeline is not about building and deploying application software but for building and deploying the network configurations and part of that requires creating mostly virtual network topologies. I am using open-source GNS3 for network simulation. My network topologies are all Cisco switches, so I am using a Cisco IOS image. GNS3 is what also allows me to create and save network topologies for both testing and production networks. Finally, when my CICD runs to completion, my build server sends out a notification, whether it is a pass or fail, for each build cycle. I am using Slack for that purpose.

Let’s now deep dive into each of the layers in the stack starting with the VMM.

VirtualBox as the Virtual Machine Manager (VMM)

VIRTUAL Machine Manager or VMM is practically a hypervisor that allows a virtual machine to run on top of either a bare-metal or a host OS. The former is known as the type 1 hypervisor whereas the latter is known as the type 2 hypervisor. The VMware vSphere, VirtualBox from Oracle, and the KVM are the most popular examples of hypervisors. I am using the latest version of VirtualBox as the type 2 hypervisor running on top of my macOS Big Sur x86 variant. None of the major hypervisor vendors have ported their hypervisors to Apple’s ARM-based Silicon in December 2020, however, they all have plans to do so in the future.

Ubuntu Linux OS

NEXT up in my stack is Ubuntu Linux. I am using pretty much a stock Ubuntu Linux along with the VirtualBox Guest Additions for Ubuntu that allows access to better video resolutions, time synchronization, shared clipboard, and folders between the Linux and the host macOS. I have a Firefox browser that comes preinstalled with Ubuntu and is necessary for monitoring Gitea and Drone servers via their respective web portals. I am running miniconda3 and GNS3 for python 3 support and network simulation. Miniconda is a minimal installer for conda and helps deal with python dependencies as opposed to using the pip package manager.

Docker Containers

NOW, let’s talk about Docker. Docker is a tool that allows developers, sysadmins, etc. to easily deploy their applications in a sandbox (called containers) to run on the host operating system i.e., Linux. The key benefit of Docker is that it allows users to package an application with all its dependencies into a standardized unit for software development. Unlike virtual machines, containers do not have high overhead and hence enable more efficient usage of the underlying system and resources. In short, with Docker, you can manage your infrastructure in the same ways you manage your applications. Docker consists of a daemon a scary name for a background process and a Client which provides the Docker CLIs so you can interact with the daemon. You may hear about, yet another Docker infra known as the Docker Engine. Docker Engine is just the combination of Docker Daemon, Client, and APIs. Docker uses specific jargon that may be confusing so let me explain. A Docker image is a read-only template that contains a set of instructions for creating a container that can run on the Docker platform. It provides a convenient way to package up applications and preconfigured server environments, which you can use for your private use or share publicly with other Docker users. Containers are created from the Docker images and run the actual application. You can create a container using the docker run command. You can view a list of running containers using the docker ps command. Lastly, a Dockerfile is a simple text file that contains a list of commands that the Docker client calls while creating an image. It’s a simple way to automate the image creation process. The best part is that the commands you write in a Dockerfile are almost identical to their equivalent Linux commands. This means you don’t have to learn new syntax to create your Dockerfile. There are three containers within my Docker infra, and those are Gitea, Drone, and Ansible.

Gitea as the Git server

GITEA is the Git open-source version control server. I prefer Gitea over Gogs since it brings everything together in a single binary managed by a strong community. It is also more feature-rich in the areas of code management, issue tracking, pulling, or merging requests, and even third-party integrations. I am running Gitea inside a container and using TCP port 3000.

Drone as the Build server

NOW, let’s about the piece of software that brings it all together, my build server Drone. As soon as I check in a change via a git push command, it kicks off my build server, and then it runs through my build pipeline which orchestrates my NetDevOps CICD pipeline. Just like Gitea, I am using an open-source build server Drone, you can Jenkins or another build server of your choice. Drone comprises three components, Drone server, agent, and plugins. Drone agents are simply runners that poll the server for pending pipelines to execute. The drone can integrate with GitHub, GitLab, Gitea, Gogs, Bitbucket server, and cloud out of the box. In my setup, Drone TCP 80 and 443 ports are forwarded to TCP 8000. I am running two Drone plugins, one for Gitea and the other for integration with the Slack for CICD pipeline notifications. Gitea is authenticated as an app using OAuth to Drone. You can see my last Git commit that first validated my changes within the dev branch, merge and then verify the master branch before deploying the configuration changes to production.

Ansible for network configuration and deployment

NOW, Ansible needs no introduction. It is yet another open-source tool, a configuration management tool that I am using for the deployment of the network configurations. Configuration management tools use IaC or Infrastructure as Code to define and maintain configuration. Ansible uses playbooks are written in YAML format and that’s where you define how your routers, switches, or for that matter servers are configured.

Virtual Network simulation with GNS3 and CML

UNLIKE code, for Network DevOps, you need a way to create virtual networks so you can run test your configurations before deploying them into production. To create those virtual topologies, you can use an open-source network simulation software such as GNS3 or you can use Cisco Modeling Labs or CML. CML is a paid software and would cost you $199 a year. GNS3 doesn’t come with an IOS image but CML does so you get what you pay for. In my setup, I am running GNS3 outside the Docker on top of the Linux itself.

I am using GNS3 to create and maintain three different topologies. The first one is just one Cisco switch, you can call it unit testing, the second one is for integration testing in a more realistic network. The final variant is the topology that I use as a production mockup and it uses even more nodes.

Cisco CML Editions

NOW, before we move on, CML comes in Personal and Personal Plus flavors, the difference is the number of nodes that you can create in your network topology. CML Personal Plus costs $349 but comes with a license for 40 nodes as opposed to 20 in the case of Personal edition. Another upside for paying for CML is that you get access to the latest Cisco images that include IOS, IOS XE, IOS-XR, NX-OS, and even ASAv.

If you’re interested in getting started with the NetDevOps or network automation, be sure to checkout my CICD Pipeline VM.

Feel free to drop your questions or comments below.