How to Create Your Own Gitlab Runner!
If you decide to make your own gitlab runner for whatever reason, the process isn’t complicated at all!
This article was written as a submission of CS UI’s software development course’s article task.
Creating your own gitlab runner gives you some advantages. You can turn one of your powerful computers/cloud instances into one if you feel like the default gitlab runners aren’t powerful or fast enough. You can assign special runners to do certain jobs easier. And, most importantly, you can configure your runner extensively. That last advantage came to a head when I had to use my university’s version of gitlab, gitlab.cs.ui.ac.id, for a project, which came with runners who had proxies that caused a lot of problems.
So, without further ado, I will now attempt to tell you how to install and configure your very own gitlab runner as concisely as possible!
Assumption : I’m assuming you’re using a version of Linux (because that’s what most cloud instances run on, and custom gitlab-runners are mostly cloud instances, as far as I can tell.)
Installing gitlab-runner
To install gitlab-runner on your machine, you simply have to download the appropriate package.
To download the appropriate package for your system:
- Find the latest file name and options at https://gitlab-runner-downloads.s3.amazonaws.com/latest/index.html.
- Choose a version and download a binary, as described in the documentation for downloading any other tagged releases for bleeding edge GitLab Runner releases.
Examples:
#For debian or ubuntu
curl -LJO "https://gitlab-runner-downloads.s3.amazonaws.com/latest/deb/gitlab-runner_${arch}.deb"#For CentOS or Red Hat Enterprise Linux
curl -LJO "https://gitlab-runner-downloads.s3.amazonaws.com/latest/rpm/gitlab-runner_${arch}.rpm"
Next, once you’ve downloaded the package, you install it like any other package.
#For debian or ubuntu
dpkg -i gitlab-runner_<arch>.deb#For CentOS or Red Hat Enterprise Linux
rpm -i gitlab-runner_<arch>.deb
Registering your Runner
Once you’ve installed gitlab-runner on your system, you now have to register it as a runner. To do so, follow these steps:
On gitlab, go to settings,CI/CD, and expand the “runners” option. You should see something like this:
On the left hand side, you will get a token that you have to use to register your custom runner for this project.
Now, on your would-be runner machine, do:
- run “sudo gitlab-runner register”.
2. Then, enter your GitLab instance URL. If you’re using normal gitlab, then just input https://gitlab.com/. In my case, I’m using https://gitlab.cs.ui.ac.id/.
3. Then, enter your registration token that you can find on the gitlab settings that I mentioned earlier.
4. Enter a description for your runner. It will basically be a name for your runner.
5. Enter tags for your runner. This is useful when you want to specify certain jobs in the pipeline for certain runners, as you can choose which runners to use by using their tags. Since I don’t have plans for this particular runner to do that, I’m going to leave it blank (you can always customize tags later on through gitlab too).
6. Enter an executor. For most use cases, docker should suffice.
7. If you picked docker, you need to pick what default docker image that will be used if you don’t specify any on your gitlab-ci. In my case, I will use alpine.
Ta-da! Your machine is now a gitlab runner for your project! If you refresh the settings page that we mentioned earlier, you should see your new runner registered!
If you don’t see it, try running “sudo gitlab-runner start” on your machine. To actually use your runners exclusively, you need to disable shared runners for your project.
Advantages
Because you have your own machine is now a gitlab-runner, you can configure it. On Ubuntu, the configuration file should be located at /etc/gitlab-runner/config.toml.
Inside it, you can configure a bunch of stuff.
Because this machine in particular is registered as two different runners (I genuinely made another runner for the example in the previous section), there are two [[runners]] in this file. Inside it, you can configure a lot of stuff, but for my use case, I simply need to change the “privileged” variable from “false” to “true”, so that my runner can go through the pesky proxies that I mentioned earlier (although I don’t recommend doing this depending on your use case, as it can be dangerous). For the full list of things that you can configure, I recommend referring over here.
Another advantage to using custom runners is that you can explicitly tell gitlab to use your custom runners for certain jobs. Remember those tags? they come in handy.
In this gitlab-ci example, I set the “Staging” job to exclusively run on runner-1, which corresponds to “RestuIbu-Runner-UbuntuAWS(Kyo)”.
As such, that particular job will always, always, be executed by that runner.
This way, I can be sure that the “Staging” job, which requires a lot of resources, will be run solely on the most powerful runner that I have, and thus be more efficient.
Keep in mind that this means you have to maintain your runners by yourself, as gitlab won’t maintain it for you. For example, we found that over time, our runners run out of space because the images that they pull filled up what little space they had. To solve this, I created a script that runs “docker prune” every hour on each of my runners, to get rid of unused images.
Conclusion
And that’s it! That’s all there is to it. Although it might seem intimidating and complicated at first, gitlab has really made it easy to set up your own runner, and we should commend them for that! It gives us more freedom in how we deploy our apps. Although it comes with a few caveats (namely maintenance), with a little know-how and effort, you can overcome them all because you have full of your machine.
Thanks for reading!