Intro to Automation Part 3 – Your New Best Friend—Git!

For the third iteration of the Intro to Automation blog series, I want to discuss what I believe to be one of the more important tools a Network Engineer can learn to use early in their network automation journey. Even before writing a single script or a single piece of automation, Git can be extremely helpful.

Just like in the previous posts, I intend to focus more on the high-level benefits of Git, why it is useful, and different ways of looking at it from a Network Engineer’s perspective, or for someone new to Git in general.

What Exactly Is Git?

Before I can explain Git, I want to explain the underlying technology of what exactly Git is. See, Git is the name of a program of the type called Version Control Software, or VCS for short. VCS is essentially software used to manage configuration changes to one or more files and tracking any changes made to them. A good VCS system will let you see what changes were made to different files, who made them, and when they were made, and will allow you to roll back one or more changes at a time.

There are many different types of VCS programs available. Some are open-source, while others are proprietary with commercial support. Each has its own benefits and drawbacks and different models for how they work. This Wikipedia article explains the models well, and also lists different software available that use each model:

  • Local data model – Everyone uses the same file system
  • Client-server model – Everyone uses a shared single repository
  • Distributed model – Everyone works directly with their own local repository, and changes are shared between repositories later

Defining Terms

Before I go further, there are some terms used in Git that I want to explain, as I’ll be using them throughout the rest of the article.

  • Repository – This is a directory, like a folder on your computer, that contains all of the files in the project that are managed (tracked) by Git, as well as a full revision (change) history.
  • Revision history – A list of every change made to one or more files, with details on exactly what was changed.
  • Commit – To save the state of one or more files in your repository. All changes in the file(s) can then be viewed from any previous commits made to the same file.
  • Merge – To apply a specific set of commits (one or more changes to files) into the primary version of existing files, so that the primary version has the new changes applied.
  • Trigger – To activate a process or service in a system.
  • Deploy – To apply a set of changes to another system or network device. This term is usually used when referencing automation making the changes, but also works when referring to manual changes.
  • Webhook – Having one software or service trigger or be triggered by another service over HTTP/S. These can be manually triggered or triggered automatically when a certain condition is met (someone makes a commit, a specific file is changed, etc.).

There are many other terms associated with learning and using Git, but these are the specific ones used in this article.

Git as a VCS

Git is the most popular VCS available, and is used by many developers and engineers around the world. It follows the “Distributed model” architecture listed above. Some of the benefits that make it so popular are:

  • It is very fast.
  • It is distributed. This means that even without an internet connection, if you have Git already set up and configured on your computer, you will have a full history of all changes made to a repository available to you.
  • It is open-source. This makes it free to start using.
  • It is very popular, which makes finding additional resources for using Git, or articles about learning Git, easy to find.
  • It has great commercial products available for using it. There are popular online resources available that use Git, such as GitHub, that I’ll explain later.

Git for Network Engineers

While it’s true Git is mostly used by software developers or Network Automation Engineers, it can also be useful to a Network Engineer without using any initial automation. In fact, a lot of automation can be built around using Git, which I’ll explain later.

There are many non-automation related use cases, which I mentioned briefly in my previous post. Let’s discuss them in more detail.

Learning to Write Scripts

Before I got into more advanced automation as a Network Engineer, I was still writing small, basic scripts that accomplished various tasks I would perform throughout the day. If you recall, in part 1 of this series I gave an example of the first script I wrote. It was a Python script to generate a unique running configuration file for multiple devices using dynamic settings for each device.

This script took a few months to figure out, fully test, and fix any bugs I encountered. I also thought of new features or things I wanted to add as I progressed in writing it.

I was able to use Git locally, just on my computer, and track all changes to just this individual file. This came in handy a few times when I would commit (save) my changes to Git, then write some new part of the script, only to have it crash every time I ran it. By using Git, I was able to backtrack and see what I had changed specifically, and either revert back certain parts of my script, or if it was causing me too many issues, roll back the entire script to the last time it was working successfully (my latest commit).

Config Backups

There are many different configuration backup systems available, with many different features built in specifically for this purpose. However Git can work for this as well, and can be used later on with more advanced automation workflows.

One example is every time you make a change to a device, as part of the implementation process, you can take a backup of the config and commit it into a Git repository, which will track all changes made to the device. Later on in your automation journey, this process can be fully automated (both the implementation step as well as the config backup step).

Change Control / Auditing

Git can also assist with change control and auditing for certain changes, though there are some limitations. With Git, every time you create a new commit, you’re able to tag it with a comment that briefly describes what exactly the commit is for. For example: “Fix broken feature x” or “Update to support IOS-XE devices”.

For change control purposes, if you are using Git for network device config backups, you could put the ticket number for the change being made as the commit comment. Then if you ever need to go back and see exactly what was done for a change, you can simply search Git for the ticket number.

As for limitations, some more advanced features of Git allow you to go back and fix incorrect commits, their comments, or even delete them from the full revision history. With a basic setup, this may cause issues for certain auditing environments as the integrity of the Git history is not guaranteed.

Adding authentication and logging to Git changes will help improve revision history integrity, which brings us to our next topic.

When first hearing of Git, a lot of people first assume that Git and GitHub are the same thing. This is not the case, though GitHub has become incredibly popular with Git users. Git is the underlying version control software, whereas GitHub is an online platform used to upload, share, and collaborate on Git projects.

GitHub is available online for free, where anyone can create an account and start uploading their Git repositories, or create new ones from scratch. One of the main benefits of GitHub is it allows for collaboration between users. For repositories that are configured as public (anyone can see), people can make a copy of anything you upload, offer to make changes, or make their own changes without sharing. GitHub also offers enterprise options for companies needing to keep what they upload private.

A good analogy would be Git is to GitHub as movies are to YouTube.

This includes sharing ideas or changes with people you work with regularly, or people you’ve never seen. That’s what makes up the broader open-source community!

GitHub Alternatives

I listed GitHub because it’s the most popular service available today. There are other services similar to GitHub that work quite well, with their own strengths and weaknesses. Some of the more popular examples are Bitbucket and GitLab. They all support using Git for version control, support collaboration among other users, and will work just as well as GitHub. The nuances between these and other services are more technical and outside of the scope of this article.

Git and Automation

So how does Git fit into an overall picture of network automation? As you begin your journey into network automation, you’ll end up writing code in Python or another programming language, writing Ansible playbooks, configuration settings, etc. Git fits in well here, not just for tracking file changes, but working directly with automation.

When using a service like GitHub, you can set up certain webhooks that trigger other automation when something in a repository is modified.

For example, I can set up a workflow where, when I create a change to a network device configuration (saved in a repository), GitHub can send a webhook to another service, like Jenkins, Ansible Tower, etc. These other services can then automatically deploy the change to one or more devices, take configuration snapshots automatically, and save them to another “backup” repository.

This can be further expanded when you introduce the concept of Infrastructure as Code. At a high level, this means you don’t configure one device at a time. You save different parts of network device configurations in separate files, then only make relevant changes to the files. For example, you would have one file for SNMP configurations, one for AAA configurations, one for NTP configurations, etc.

When updating a setting in one of these files, and saving the changes in GitHub, it can then be used alongside other automation tools to deploy those changes to any number of devices.

Another great use of Git and GitHub is using their Peer Review process for any changes you intend to make. Before making a change, then committing and merging it into the primary file, you can have someone else double-check your changes and validate them. This adds and extra layer of protection for mistakes stemming from human error. This also lines up well if your company follows some kind of change control process, such as ITIL.

Granted, these ideas involve multiple tools outside of Git and GitHub, but they show some of the possible uses of Git and GitHub to a Network Automation Engineer.

Git Clients

I mentioned this briefly in my previous post, but thought it important enough to bring up again. While Git is natively used with CLI commands, there are various GUI applications that can make learning and using Git easier when getting started. A brief list of some popular ones are:

For me, the ability to visualize some of the changes, along with having important information (like commit comments) more readily available, make using some of these programs my preference. I’d encourage you to learn the CLI, then try some of the above clients and see which way works best for you.


Conclusion

I hope I was able to highlight some of the benefits of learning Git early in your network automation journey. It really is an important tool you can learn to use that will be very beneficial throughout your entire journey. While there are many resources available online for learning Git, I hope to have highlighted some of the benefits of learning Git early for Network Engineers and Network Automation Engineers alike.

 

Thanks for reading, and happy automating!

-Matt

Intro to Automation Series

Part 1 – Rethink How You Think

Part 2 – New Tools for a New Network

Part 3 – Your New Best Friend—Git



ntc img
ntc img

Contact Us to Learn More

Share details about yourself & someone from our team will reach out to you ASAP!

Author