Continuous Integration with GitLab

The network touches every part of the technology stack; in all the environments I have worked in, the network is always a Tier-Zero service. It is a foundation service that other services rely on for their services to work. In the minds of other engineers, business managers, operators, and support staff, the network should just work. It should always be accessible and function correctly—a good network is a network that nobody hears about.

Of course, as network engineers, we know the network is as complex as any other technology stack. Due to its complexity, the constructs that make up a running network can be fragile. Sometimes, I look at a network and wonder how it can work at all, let alone how it’s been running for months and years without any business impact.

Part of the reason we are interested in network automation is to find ways to repeat our network-change process reliably and consistently. By using Python scripts or...

The traditional change management process

Engineers who have worked in a large network environment know that the impact of a network change gone wrong can be big. We can make hundreds of changes without any issues, but all it takes is one bad change that can cause the network to harm the whole business.

There is no shortage of war stories about network outages causing business pain. One of the most visible and large-scale AWS EC2 outages in 2011 was caused by a network change that was part of the normal AWS scaling activities in the AWS US-East region. The change occurred at 00:47 PDT and caused a brown-out for various services for over 12 hours, losing millions of dollars for Amazon. More importantly, the reputation of the relatively young service took a serious hit. IT decision-makers pointed to the outage as a reason NOT to migrate to the young AWS cloud. It took many years to rebuild its reputation. You can read more about the incident report at https://aws.amazon.com...

Introduction to continuous integration

Continuous Integration (CI) in software development is a way to publish small changes to the code base quickly, with built-in code tests and validation. The key is to classify the changes to be CI-compatible, that is, not overly complex and small enough to be applied so that they can be backed out of easily. The tests and validation process are built in an automated way to gain a baseline of confidence that changes will be applied without breaking the whole system.

Before CI, changes to software were often made in large batches and often required a long validation process (does that sound familiar?). It could be months before developers saw their changes in production, received feedback loops, and corrected bugs. In short, the CI process aims to shorten the process from idea to change.

The general workflow typically involves the following steps:

1. The first engineer takes a current copy of the code base and works on the change...

Installing GitLab

GitLab is a powerful, all-in-one tool to handle the end-to-end DevOps collaboration tool. As we will see in a minute, it hosts the code repository and handles the code testing, deployment, and verification. It is one of the most popular DevOps tools used in the field today.

The company behind the technology, GitLab Inc., had its successful initial public offering on NASDAQ (ticket GTLB) in late 2021, https://techcrunch.com/2021/09/17/inside-gitlabs-ipo-filing/. The company’s success shows the strength of and sustainability of the technology.

We will only need a small set of its features to get up and running with a test lab. The objective is to familiarize ourselves with the overall flow of the steps. I encourage you to look at the GitLab documentation at https://docs.gitlab.com/ to get a sense of its features.

Figure 15.1: GitLab Documentation

For our network lab, we will use the same lab topology that we have been using...

Join our book community on Discord

https://packt.link/PyNetCommunity

We have worked on various aspects of network automation with Python, Ansible, and many other tools. If you have been following along with the examples, in the first thirteen chapters of this book, we have used over 150 files containing over 5,300 lines of code. That's pretty good for network engineers who may have been working primarily with the command line interface before reading this book! With our new scripts and tools, we are ready to go out and conquer our network tasks, right? Well, not so fast, my fellow network ninjas.

There are several things we need to consider before we get into the meat of the tasks. We'll run through these considerations and talk about how the version-control (or source-control) system Git can help us out.

We'll cover the following topics:

• Content management considerations and Git
• An introduction to Git
• Setting up Git
• Git usage examples
• Git with Python
• Automating configuration...

Content Management Considerations and Git

The first thing that we must consider when creating code files is how to keep them in a location where they can be retrieved and used by us and others. Ideally, this location would be the only central place where the file is kept but also have backup copies available if needed. After the initial release of the code, we might add features and fix bugs in the future, so we would like a way to track these changes and keep the latest ones available for download. If the new changes do not work, we would like ways to roll back the changes and reflect the differences in the history of the file. This would give us a good idea of the evolution of the code files.

The second question is the collaboration process between our team members. If we work with other network engineers, we will most likely need to work collectively on the files. The files can be the Python scripts, Ansible Playbook, Jinja2 templates, INI-style configuration files,...

Introduction to Git

Git was created by Linus Torvalds, the creator of the Linux kernel, in April 2005. With his dry wit, he has affectionately called the tool "the information manager from hell." In an interview with the Linux Foundation, Linus mentioned that he felt source-control management was just about the least interesting thing in the computing world (https://www.linuxfoundation.org/blog/2015/04/10-years-of-git-an-interview-with-git-creator-linus-torvalds/). Nevertheless, he created the tool after a disagreement between the Linux kernel developer community and BitKeeper, the proprietary system they were using at the time.

What does the name Git stand for? In British English slang, a git is an insult denoting an unpleasant, annoying, childish person. With his dry humor, Linus said he is an egotistical bastard and that he named all of his projects after himself. First Linux, now Git. However, some suggested that the name is short for Global Information...

Setting up Git

So far, we have been using Git just to download files from GitHub. In this section, we will go a bit further by setting up Git locally so we can start committing our files. I will use the same Ubuntu 22.04 LTS management host in the example. If you are using a different version of Linux or other operating systems, a quick search of the installation process should land you at the right set of instructions.

If you have not done so already, install Git via the apt package-management tool:

$ sudo apt update
$ sudo apt install -y git
$ git --version
git version 2.34.1 

Once git is installed, we need to configure a few things so our commit messages can contain the correct information:

$ git config --global user.name "Your Name"
$ git config --global user.email "[e-mail]"
$ git config --list 
user.name=Your Name
user.email=[e-mail]

Alternatively, you can modify the information in the ~/.gitconfig file:

...