I spend a fair amount of time building labs and then breaking them.
Unfortunately my constant tinkering can bite me in the ass when I’m trying to remember how I got something working a while ago.
After numerous lab rebuilds (of both hypervisors, virtual networking, storage etc) I got really irritated with how much time I was spending on keeping up and fixing the infrastructure when the whole goal was actually to be labbing something up!
So I took some baby steps.
- I organized my scripts
- I put my scripts on Dropbox (yay for consistency!)
- I also started pushing my scripts to GitHub (yay versioning!)
- I started to try automating as much of my homelab build as possible
- I created powershell scripts for building/rebuilding my vswitch environment
- I created/updated a script that I found for finding and re-importing old .vmx files into vcenter
- I created several templates for deploying VMs
- (Need to do), start using scripts for deployment of VMs
- I set up Oxidized to grab all of my network configs and store them and diff them
So we’re making progress here, right? Starting to feel like a 21st Century Network Engineer. Well, since we’re always out to improve ourselves, lets keep at it.
Having all of my configs in a central spot is great, but I have to be at home (or VPN’d in) and it makes it difficult to easily share them.
Oxidized was already using Git, so my thought was, “gee, it would be nice if I could just shove these things into GitHub somehow…”.
So I wandered over to https://github.com/ytti/oxidized and started perusing the documentation again.
I found a great mention of Hooks, otherwise known as event driven integrations, or integrations that we can kick off if certain criteria are met.
**Disclaimer** While, at some point in the future, I may go over a more detailed install of Oxidized, here I am just going to cover the GitHub integration. This walk-through assumes that you already have Oxidized running and working in a local-only fashion.
The Config File:
First, we need to do a few things to make this integration a bit more manageable. By default the git output section of the Oxidized config will try to give you a seperate repo for each group. The result of this, is that when you start pushing to GitHub, you’ll end up with a flat file structure and no organization. This may work for you, but for my organizational tastes, I’d rather have each of my groups simply represented as a folder with the relevant configs inside of it. This is accomplished by using the ‘single_repo: true’ flag in the output section as captured below.
Now we need to update the config file to push to GitHub. This is accomplished by creating a ‘Hooks’ section, as follows (in the config file).
Now what will happen is whenever a post_store event occurs, we will to a git-commit to the remote repo.
But how do we auth to GitHub?
Okay, no sneaking that one past you. Allegedly you are supposed to be able to use HTTPS auth with a username/password (defined as params in the hooks block), however I was never able to get them working. When you don’t specify them Oxidized will call git as the currently running user and try to post them over SSH. In order to get this to work, you need SSH keys. There are about a billionty examples on the internet for how to setup SSH key auth, but here’s a helpful link that shows how to create the keys as well as how to add them to the ssh-agent:
Once you’ve created the keys and added them to your ssh agent, now you just need to update GitHub with your new Keys- again a lovely writeup by Github:
You created a repo on GitHub right?
Create a repo on GitHub with the same name as the once you specified in the ‘Hooks’ section.
Cloudy Configs for all!
Once that is all set up you can kick of your oxidized service, and your configs should start popping up in there. If they aren’t I suggest running the oxidized agent in debug mode to find out what is going on.
Be smart kids-
Its worth noting that by default GitHub only allows public repos (unless you have a paid account). If you’re going to post configs to GitHub on a public repo, make sure there isn’t an sensitive data on there (passwords/keys/etc), or just spend the $7/month and set up a private repo.
Now you have configs that are backed up, and easy to share- not to mention whenever you’re updating your lab your GitHub account is registering commits, so you kind of look like a rockstar.