Git For Network Engineers
Devops is a buzz word that means a lot of things today. In my pursuit to find out what all the excitement is about, I came across something called "version control". There are multiple version control systems out there, but the one I've been using the most personally is git.
Version Control Explained
Version control is a system to track changes to a file or multiple files at a time. Git tracks changes to a file in the form of something called a "commit". Once the file has been "committed" it will start being tracked by the git version control system. With the file being tracked by git you can start establishing a history of all your changes. Think of every commit like a "snapshot" in time, when the file was changed. Git will track the line additions or subtractions to your file and also store a log of messages along with that snapshot. Programmers use version control to track the history of their code. Version control is a very powerful tool for programmers in particular because it allows them to identify the point in time when a bug was introduced into their code or allow them to work on their program without impacting the "master" code. However! Version control isn't just for programmers. Anyone can benefit if they have a need of tracking changes, establishing a history of a living documentation, and tracking a particular procedure or process.
Git. Not Just For Programmers.
If you've been in network engineering for a long time you may be what is considered a "wealth of knowledge" or a "benevolent configuration overlord" at your company. Someone who other engineers seek out to understand the history of a particular environment. How nice would it be if you could track your entire thought process of establishing and maintaining that environment. It would empower yourself and your peers to figure out why things are in the production network configuration or why a particular technology was introduced, and the way in which is was introduced. On the flip side, how nice would it be if you're a new hire at a company or a junior engineer and you want to learn about your environment and history behind it all. A well maintained version control system can enable your team to accomplish these things. The senior engineers can share their historical knowledge. The new engineers can learn the history and "the why". The junior engineers can feel engaged and not in the dark when it comes to configuration and "configlets".
"How is this any different from establishing a good knowledge base?"
I asked myself this same question when I heard about version control systems. I wondered, "What could be beneficial about this, if I keep well maintained pdfs or word documents?". After learning about git and git collaboration tools ( such as GitHub ), I discovered sharing and tracking knowledge with git is an entirely different way of thinking. I was basically asking the wrong question. Git isn't designed to replace your local file share where you may keep topology diagrams, software images, or other miscellaneous objects. It is designed for source controlling your code. Code can mean different things to different professions. To an author, "code" could be a book. Keeping track of the history and changes of their body of work. To a mathematician, "code" could be a series of formulas or an algorithm they're developing. To a network engineer "code" could be a device's configuration or a snippet of configuration.
Git In Action
For this example, let's pretend we need to keep track of a quality of service configuration for a particular network element. We'll start with the initial configuration and initialize a git repository. First create a repository.
ong$ mkdir Git_Repo ong$ cd Git_Repo ong$ git init Initialized empty Git repository in /Users/ong/Git_Repo/.git/ ong$ git status On branch master Initial commit nothing to commit (create/copy files and use "git add" to track) ong$
We created an empty directory and initialized the directory as a git repository with the command "git init". After we initialized the repo we checked the status of any files inside that directory using "git status". We can see that there is nothing to commit, basically nothing is being tracked yet. So let's create our initial configuration and start tracking it! We're going to create a file called branch_qos.txt and save it into our git repository.
#branch_qos.txt class-map match-all VOIP match ip dscp ef policy-map WAN_SHAPER class VOIP priority percent 20 class class-default
Let's check the status of our git repo:
ong$ git status On branch master Initial commit Untracked files: (use "git add <file>..." to include in what will be committed) branch_qos.txt nothing added to commit but untracked files present (use "git add" to track) ong$
We can see that our git repo noticed branch_qos.txt as a new, untracked file. Currently, git is not tracking this file yet. To do so we will need to use the "git add file" command.
ong$ git add branch_qos.txt ong$ git status On branch master Initial commit Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: branch_qos.txt ong$
Now git is tracking branch_qos.txt. Let's commit the file to the "master branch" using the command "git commit -m 'commmit message'".
ong$ git commit -m "Initial commit of branch QoS config" [master (root-commit) 6a4d25e] Initial commit of branch QoS config 1 file changed, 7 insertions(+) create mode 100644 branch_qos.txt ong$ git status On branch master nothing to commit, working directory clean
Now our QoS configuration has been committed to our master branch and both the file, branch_qos.txt, and our repo are synced up. Let's say some time has passed and your voice group has informed you they want to change the VOIP codec being used and they need more bandwidth in their priority queue. So we modify the QoS configuration as follows:
#branch_qos.txt policy-map WAN_SHAPER class VOIP priority percent 30
We save the file and check the status of our git repo.
ong$ git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: branch_qos.txt no changes added to commit (use "git add" and/or "git commit -a")
Git noticed our configuration has changed. Let's commit the change and add a log message explaining why we changed the size of the priority queue.
ong$ git add branch_qos.txt ong$ git commit -m "Modified priority queue to account for new VOIP codec" [master 9cf98c9] Modified priority queue to account for new VOIP codec 1 file changed, 1 insertion(+), 1 deletion(-) ong$ git status On branch master nothing to commit, working directory clean ong$
Now we can start viewing the history we've established using the git log command with the -p flag.
ong$ git log -p commit 9cf98c9733a168aa47bd69f9eb6cb9b52567ebc8 Author: onenetworkguy Date: Tue May 17 22:00:15 2016 -0500 Modified priority queue to account for new VOIP codec diff --git a/branch_qos.txt b/branch_qos.txt index 04acb4d..8885400 100644 --- a/branch_qos.txt +++ b/branch_qos.txt @@ -3,5 +3,5 @@ match ip dscp ef policy-map WAN_SHAPER class VOIP -priority percent 20 +priority percent 30 class class-default commit 6a4d25e3f0d2f77fd8f016e382730fc6d86d971b Author: onenetworkguy Date: Tue May 17 21:51:50 2016 -0500 Initial commit of branch QoS config diff --git a/branch_qos.txt b/branch_qos.txt new file mode 100644 index 0000000..04acb4d --- /dev/null +++ b/branch_qos.txt @@ -0,0 +1,7 @@ +class-map match-all VOIP +match ip dscp ef + +policy-map WAN_SHAPER +class VOIP +priority percent 20 +class class-default ong$
We can see the initial commit when our priority queue was configured for 20 percent and we also see our latest commit where the "priority percent 20" line was deleted and "priority percent 30" was added. We also see our commit message explaining the reason for the change.
Hopefully, with this simple example, the benefits of version control are becoming a little more clear. When working with configuration with hundreds to thousands of lines of syntax having a good version control system in place will aide in remembering why something was removed or put in place. In our example we were using git locally on our machine. However, this isn't ideal for team collaboration. There are multiple git tools available for teams collaborate on the same code, you may have heard of an extremely popular tool in GitHub.