I’m pretty sure most of you familiar with Gitlab. It has a lot of features and nowadays it looks a bit bloated but one thing I really love in this tool. It’s Gitlab CI. One of the coolest thing there is it can run jobs on many platforms including virtual machines, Docker containers and Kubernetes.
Let’s look in detail how Gitlab CI works and configured.
Gitlab runner is an agent which communicates with Gitlab server, receives tasks from it and executes them on a selected executor. You can install the runner on any linux host or put it into a container.
Executor is an environment where the code will be ran. Here is a list of available executors: SSH, Shell, VirtualBox, Parallels, Docker, Kubernetes and Custom.
I would like to pay more attention to Kubernetes executor. When Gitlab runner is configured to use this executor it spawns pods in a Kubernetes cluster and jobs from pipelines are executed inside the pods. You can install a runner to your cluster via Gitlab web UI just clicking one button. But it assumes that you have cluster admin privileges. Moreover if you have an Openshift cluster you should take in account some its “features”.
Now let’s talk about Openshift. It’s a Kubernetes distribution which is developed by Red Hat. It has more advanced security policies and provides some custom objects such as DeploymentConfigs, BuildConfigs, ImageStreams and others. Openshift has also Templates API. It’s something similar to Helm charts but less flexible and only Openshift specific. Nevertheless Openshift templates are a convenient way to pack all objects which are related to one service in one YAML file.
Gitlab runner template
So I decided to create such template for Gitlab runner. Let me explain what objects are created and a deployment workflow.
- The following objects are created:
- When image is changed in
gitlab-runnerDeploymentConfig is started.
- Two init containers are spawned:
gitlab-runner-config-mapConfigMap to a shared volume named
gitlab-runner-initcontainer registers a runner for a given Gitlab instance and changes
config.tomlin the shared volume
- Finally a pod with
gitlab-runnercontainer starts with
config.tomlwhich is mounted from the shared volume
After that you will see a new entry in the UI under
CI / CD/
There are two ways how you can apply this template: via web UI or CLI. In the UI you just need to
copy and paste the content of
Import YAML dialog. Then
instantiate the template in order to create the objects. For command line interface you should use
$ oc process -f ocp-gitlab-runner-template.yaml \ -p NAME="gitlab-runner" \ -p CI_SERVER_URL="URL of a Gitlab REST API" \ -p REGISTRATION_TOKEN="Runner's registration token" \ -p CONCURRENT="The maximum number of concurrent CI pods" \ | oc create -f -
That’s it. I hope someone find it useful and feel free to use it.