INFRA-AS-CODE: WHAT IS REQUIRED?

In the previous post we discussed on ways to get started down the Infra-As-Code journey. However, one thing that was pointed out from others was that I missed the backup process of devices. So I wanted to go ahead and address that here in the beginning of this post to get that area covered. And I very much appreciate those who brought that to my attention.

So how do you currently cover backups on network devices? Do you not back them up? Do you back them up to a TFTP/FTP server? Well in order to accomplish backup tasks for Infra-As-Code we need to do our backups a little differently. We need to ensure that our backups are created as the same filename on our destination on every backup occurrence. So you are thinking to yourself this seems rather un-useful correct? Well actually it is very useful and this is what we want. And the reason behind this is that we want to store our backups in our version control system and in order to benefit from this the backup filename needs to be the same every time that it is committed to our version control system. Doing so allows for us to see a configuration diff between backups. Meaning that if any configuration change occurs our version control system will show the diff of the previous backup and the current backup allowing for us to track exact changes over time. This allows for easy identification of any changes that may have possibly caused an issue or maybe even identify an unauthorized change that was not properly implemented using our change methodologies that hopefully are in place. One last thing in regards to backups is that we do indeed need to ensure that our backup strategy is followed as part of our previous post in the implementation phase at the very least. Ensuring that our backups are running and validated prior to the actual implementation of a change. Now with this section on backups being covered let’s continue on where this post was meant to be and that is what is required for Infra-As-Code.

What do I mean by what is required for Infra-As-Code? I mean what tools are required to be in place to get us started on this new journey. I will only be covering a very small subset of tools that will allow us to get started as there are way too many to cover. And the tools that I will be mentioning here are the same ones that I use so I may be a bit partial but in no-way are they to be considered the best.

Let’s start with a version control system first because we need a repository to store all of our configurations, variables and automation tooling. Now I am sure you have heard of GitHub as a git repository for users to share their code and/or contribute to other user’s repositories. Well we are not going to be using GitHub as this is a public repository and we want a repository on-site. You could however use GitHub as a private repository if you so choose to but be very careful on what you are committing and ensuring that the repository is private. There are others such as BitBucket that allow the creation of free private repositories whereas GitHub is a pay for private repositories. So what do I use for an on-site git repository for version control? I use GitLab-CE (GitLab Community Edition) which is a free and open-source git repository system which has a very good WebUI and other nice features. GitLab also offers a paid for enterprise version which adds additional functionalities such as HA. Having a good version control system is absolutely crucial because it will allow us to create git branches within our repos to designate which are Master (Golden) and maybe some others such as a staging, test, dev and etc. Having these different branches is what will allow us to do different levels of automation testing as we work through our workflows of changes.

Let’s now touch on code-review. Remember our code-review is the system that will allow sign-off on code/configuration changes to be applied on our network devices. Code-review also enforces accountability for changes. The ideal recommended method is that whomever signs-off on code changes has a complete understanding of the underlying network devices as well as what the configuration/code changes are. Taking this method ensures that everyone is in the know on what is actually changing and can take the proper measures prior to a production change which brings down your entire network. And luckily if that was to happen you did have a proper backup of each configuration right? So what do I use for code-review? I use Gerrit which is developed by Google. Gerrit is a very well-known and used code-review system throughout the developer ecosystem. One thing to note on Gerrit is that it can ALSO be used as a git repository in addition to code-review. This works well for those who want only one single system for their git repositories and code-review. The integration is very tight but the WebUI is not so pretty to say the least. So when deciding on whether to use a single system or to use Gerrit for only code-review and GitLab for git repositories is a matter of choice. If you do choose to not use a single system, it takes additional steps in your methodologies.

Now we will touch on automation tooling. There are MANY different automation tools to leverage and each one is more of a personal preference and/or cost. Some of the different automation tools include Chef, Puppet, Salt, Ansible and many others. My preferred automation tool is Ansible. Why Ansible? I spent a good bit of time with many of the others and when I finally discovered Ansible I was sold on it’s relatively easy learning curve and power. Ansible relies on Python which is a very rich and powerful programming language and is also easy to learn. Using Ansible you can program network devices via an API (if it exists), raw commands (via SSH), SNMPv3 and other methods. There are other tools that leverage Ansible such as NAPALM as well. I highly recommend checking out NAPALM. so definitely checkout the different automation tools and find the one that works the best for you.

And for the final tool to discuss in this post covers our CI/CD (Continuous Integration/Continuous Delivery) automation of workflows and changes. There again are so many different tools to choose from. Some of these tools include Go-CD, Rundeck, Travis-CI, Bamboo, Jenkins and many many more. My tool of choice is Jenkins for the most part but also leverage several of the others listed above for one-off type deployments. Jenkins is a widely adopted CI platform with a massive number of plugins developed for tying other tooling into your workflows, such as Ansible playbooks and ad-hoc Ansible tasks. Jenkins allows for us to stitch together our complete workflow from top to bottom if desired. Meaning we could leverage Jenkins to kick off a backup, pull a specific branch from our git repository with configuration changes, run an Ansible playbook against a set of network devices, report back on the status and continue throughout our workflow pipelines. Jenkins is the tool that takes many manual processes and automates those tasks for us. So think of Jenkins as the brains to our Infra-As-Code.

Now I know this is a lot to learn and digest on many new tools and methodologies but hopefully I can help you with getting your head around these tools. And with that I have created a Vagrant lab that you can spin up and begin learning each of these tools. I will be leveraging this lab going forward with the additional follow-up posts in the next few weeks. But I wanted to share this here now so you can also start getting your head around these tools. So if you head over to here you can begin your journey too.

And with that this ends this post and up next we will discuss some examples of our new methodologies.