A Gitlab runner is a kind of
build machine. Each time you trigger a pipeline on Gitlab with
Gitlab-ci, your actions describe into
.gitlab-ci.yaml will be processed onto a
When you start a project, by default, those runners are
shared (for free!) with other Gitlab users. You do not have to configure anything, just write your
ci file and push on your repo.
It is correct when you work on a personal project and you do not need to have a 100% uptime. But if you want to have your own runner, you have to create one and plug it to your project repository.
We are going to see one method for runner creation. It is the basic method, but if you want to go faster you can use
helm a Kubernetes “package manager”, with a few commands you can create your pods. In fact,
Helm does what we are going to see together. But first, we need to create our cluster !
gcloud container clusters create demo-gitlab-runner --zone us-east1-c --num-nodes 3
We are going to create a custom namespace
kubectl create namespace gitlab-runner-ns
Now, we set this new namespace as default, we can avoid to write
--namespace gitlab-runner-ns after each command !
kubectl config set-context $(kubectl config current-context) --namespace=gitlab-runner-ns
Ok, let’$ go !
For deploy our runner, we need a couple of things: a
Docker gitlab-runner image, a
deployment file, a
config map file and a
secret. In fact, runner does not need a bunch of thing, just a
config.toml into our
config map, an url and a token.
We can start with
Now you can create your config map and check his content with
kubectl create -f config-map.yaml
Now, we need a token but we do not want to see this token in clear in our
deployment file. So we need to create a
secret volume with those two data. Do not forget to hash your
token with a base64 !
echo -n "my_token" | base64
And create your
kubectl create --validate -f secret.yaml
Now, we can pass to the “main” file, the
As you can see, we pass two data as
env variable : one from
secret volume and one like a simple env variable.
The only specificity is the two mounted volumes: one for our configmap (
config.toml) and the other for our SSL certificates.
Now , we create our deployment:
kubectl create --validate -f deployment.yaml
I suppose you should have this kind of error:
kubectl get pods
Because Google security mount your “/“ as a file system (file system on Google Cloud). So you do what you want to do but for this demo, I am going to simply move my certs into
Now, you are suppose to see your pod running:
kubectl get pods
Go on your CI/CD settings on Gitlab, I suppose you should see your specific runner as active with same id as GKE id. You can now start your CI/CD pipelines as usual ! If you build some docker images during your CI/CD, you have to add a parameter to your
deployment.yaml and mount a volume pointing to
Docker daemon. If not, you will have this error while building an image.
docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
This is the two parameters:
And into your
.gitlab-ci.yaml, you have to add this variable
You are now ready to manage your own specific runners with Kubernetes and Gitlab !