UNDERSTANDING NETDEVOPS TOOLCHAIN AND INTEGRATION
- June 29, 2018
- Posted by: Muhammad Afaq Khan, CCIE #9070
- Category: Full Stack Networking
In this article, I am going to walk you through an end to end NetDevOps pipeline and the function that each tool performs within the pipeline. First let me revisit our NetDevOps toolchain which if you recall consists of four main stages of Config Creation, Building, Testing and Deploying.
NetDevOps Pipeline Stage #1: Creating Configuration-as-Code
During this stage, you as NetDevOps are creating a configuration change, let’s say you’re adding an access-list or a static route. Now, in order to accomplish this task, you will utilize a Software Control Management (or SCM) tool such as GitHub or Gogs or Gitea or another similar tool of your choice.
NetDevOps Pipeline Stage #2: Building Configuration-as-Code
There are two set of tools that are utilized during this stage. You have a build server that runs through your CICD pipeline as defined in the pipeline file i.e. .drone.yml. There are many open source options for build and integration tooling, you can use Drone or Jenkins or even TravisCI which is now free for open source and private projects. However, Drone is a popular continuous integration and delivery platform built in Go. It integrates with many version control services such as GitHub, GitLab, and obviously Gitea and Gogs. Drone agent watches for code changes and will automatically build and test changes as soon as they are committed. Drone is primarily distributed as a Docker image, so you will need to use Docker Compose to manage the CI server containers by creating the “docker-compose.yml” file. In order to monitor code changes to trigger build and test stages, Drone will need access to your source code repository inside Gitea or Gogs. The Drone Docker image is a unified container that can be run in a few different ways. Now, it is recommended to run one container that operates as the Drone server, which coordinates repository access, hosts the web UI, and serves the API. In addition to that, you can run another container as a Drone agent with pretty much the same settings, which is responsible for building and testing software from the configured repositories. The “drone-server” service starts the main Drone server container listening on default port 8000 and likewise the “drone-agent” service uses the same image but started with the “agent” command.
You will also need to set up server and agent environments using the respective .env files as well as Systemd unit using a service file before you can fire up Drone. Both Gitea and Gogs don’t support OAUTH2 so you will be prompted for user id and password each time you kick off CICD pipeline, little bit annoying but not too bad. You can also additionally configure ngnix or apache as reverse proxy server to have Drone send request through the proxy server and use SSL to secure communication between Drone and your version control system.
NetDevOps Pipeline Stage #3: Testing Configuration-as-Code
Broadly speaking, there are three types of tests involved during the NetDevOps pipeline execution, i.e. Unit, Integration and Production testing. Unit testing is simply done using a single node which can be a router, switch or a firewall, whereas integration and production testing include a more realistic simulation network topology with multiple nodes that closely mimic the real network.
In order to create test networks, you can either use Cisco VIRL or GNS3. I prefer GNS3 since it’s open source, multi-vendor and available free of cost whereas Cisco VIRL is well Cisco only and is sold as a subscription service priced at $199 a year for 20 nodes. If you only plan to use Cisco devices, prefer access to latest IOSv images and don’t mind paying for it, then Cisco VIRL is for you! Cisco VIRL integration with Drone is simple as Cisco provides a plugin that you can tap into. Anyhow, as said, I will be using GNS3 for my NetDevOps pipeline examples.
NetDevOps Pipeline Stage #4: Deploying Configuration-as-Code
There are multiple ways to deploy your configuration, however the mostly used and preferred tool is Ansible. Ansible consists of YAML data files as well as Jinja template which contains variables that can be replaced with your YAML data file. Ansible playbooks can declare configurations and launch tasks synchronously or asynchronously. For each “play” in a playbook, you get to choose which devices in your infrastructure to target and what remote user to complete the steps (or tasks) as.
Now, in order to use GNS3 with Drone, you can simply integrate GNS3 using the GNS3 server RESTful APIs directly into Drone CICD .drone.yml pipeline file along with the project information to start and stop your simulated network topologies. You can use Ansible playbooks to deploy your configurations into simulated networks.
Now, last but not least, I invite you to come and join me on Full Stack Networker Blog. I will soon be discussing NetDevOps delivery pipeline and network automation in more detail.
How useful was this post?
Author:Muhammad Afaq Khan, CCIE #9070
How useful was this post?