While many people are familiar with the concepts of dev-ops (and if you aren't, Amazon has a pretty good definition), we often think of dev-ops in an enterprise context. For a home lab, there are quite a few applications for utilizing dev-ops concepts at home. For general dev-ops concepts I highly recommend taking a look at Techno Tim's content. Tim's content covers quite a few home lab topics and puts out almost weekly Youtube videos. For our purposes we are going to be utilizing Gitlab.com repos to orchestrate code and systems in our home lab!
For this project we are going to be setting up a Gitlab runner in our home lab. What is a runner you ask? A runner is a bit of compute that can be used to run code in Git repos, it can be a virtual machine, a Raspberry Pi, just about anything you have laying around. Both Gitlab and Github have the concept of runners, when running code via CI/CD in Gitlab.com repos you can use the default pool of shared runners that Gitlab.com manages. We are going to be using our own runner.
To get started you will need a Gitlab.com account. Everything that we are going to be doing is utilizing a free tier account. I highly suggest that you enable multi factor access (MFA) for your Gitlab.com account. Using a Gitlab.com account you will want to set up a Gitlab group. Why a Gitlab group you may ask? Well, we want to utilize Gitlab group runners, which require a Gitlab group. From the Gitlab Groups Page, click the New Group button in the top right part of the page. I would highly suggest that you set the visibility of the project to Private, this will ensure that only you have have access to your project.
Once we have our group created we can register a runner and create our first project.
Creating a Runner
To create a runner we need some kind of compute, in my home lab I use a Ubuntu 22.04 virtual machine running in Proxmox. Gitlab has fairly straightforward instructions for installing the runner software. Once you install the runner you will need to configure it. Gitlab also has some fairly straightforward instructions for configuring the runner. While configuring the runner you will need to do three important things:
Get a runner token, which can be found on the runner page.
Choose the runner executor you need.
Choose unique tags that match the type of executor that you used.
- I use
dockerandshellfor my tags
I would suggest using both a docker and shell executor. You will need to simply run the registration task twice, selecting docker one time, and shell the other. Once you are finished configuring each executor you should be able to see the runner, and both executors, on the group runner page.
Great! Now you have your runner configured! For the most part, Gitlab's documentation is pretty good at directing us in what we need to get configured.
Using a Runner
Runners can be used via Gitlab .gitlab-ci.yml file configs, I tend to turn off shared runners for my projects, but since we are going to specify runners via tags, we don't have to disable the shared runners. Detailing everything about a .gitlab-ci.yml file is outside the scope of this post, but for our testing we will use the following .gitlab-ci.ymlfile.
image: python:3.9
stages:
- python-version
testing-stage:
stage: python-version
script:
- python -V
tags:
- mktbs
- dockerIn this case the tags for my project runner are mktbs and docker because we will be using the docker executor we set up earlier. Committing this file to your repo, as long as that repo is part of the group you set up earlier, should kick off a CI/CD job using docker, specifically a Python 3.9 docker image and runs a simple python -V command.
But Why?
So this is neat, but why do all of this? A great example is coming soon!