2. Deploy Gitlab Agent + Runner on MicroK8S
Notes#
NOTE: This Notes section contains old info, it is safe to skip. Leaving it as is for now.
This guide is based on the following resources:
- Deploy custom PrestaShop Helm chart (internal repos)
- How to Build and Deploy an app Helm Chart on Kubernetes Cluster with GitLab CI/CD
It is recommended to go through those guides beforehand!
Next steps: commands for getting floating IP address and domain name in .gitlab-ci.yml instead of adding them as static variables.
Introduction#
Introduction here
Prerequisites#
- Rocky Linux 10 virtual machine in cPouta, with MicroK8s installed and ready to go
- NOTE: This has been tested with Rocky Linux 9.6 as well
Adding Kubernetes Agent#
1. Connect a cluster#
Create a new GitLab project. You can name it anything you want, for example simple-service-agent-runner. You can use this same project in the following Setting Up a Service guide as well.
Inside your GitLab project, from the left side panel, choose Operate -> Kubernetes clusters. After that, click Connect a cluster.
2. Create an agent#
Create a new agent with Option 2: Create and register agent with the UI. Give a name for your agent, and click Create and register.
You'll get an agent access token, which is something like "glagent-abcxyz123". GitLab also generates commands that are used to install the Agent to your virtual machine. Run these commands in your virtual machine one by one.
If the installation was successful, you should see following message:
Go back to your GitLab project and check the Kubernetes tab. Your agent should be connected.
Adding a Gitlab Runner to the project#
Runners are responsible for running CI/CD tasks in Gitlab. You get some by default with Jamk Gitlab, but those are shared by everyone at Jamk, you may have to get in really long queues waiting for your tasks to run.. To avoid that, you can install your own custom runner which will run on the Kubernetes setup
1. Create a runner#
From the side panel in GitLab, choose Settings -> CI/CD -> Runners, then click New project runner.
While creating new runner, select Run untagged jobs under Tags. Then, click Create runner.
You should be now on a tab called Register runner.
You are given a runner authentication token on this page, under Step 1 section. It is something like "glrt-abcdxyz123". Save the runner authentication token somewhere, you will need it soon.
Choose Linux for operating system.
Before you can register the runner, you have to install gitlab-runner on your virtual machine. You can find the commands for that by clicking How do I install GitLab Runner? However, change the output destination /usr/local/bin/gitlab-runner to /usr/bin/gitlab-runner so sudo can easily find it. Remember to also change the architecture to match your setup. Installation commands for amd64 architecture:
Download binary:
sudo curl -L --output /usr/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
Give permissions to execute:
Create a "GitLab Runner" user:
Install:
Start as a service:
Now, continue with the two steps shown on the GitLab Register runner page.
If registering process asks for an URL, use https://gitlab.labranet.jamk.fi.
For an executor, choose Kubernetes.
2. Installing the runner with Helm#
Go to your virtual machine, and create a values.yaml file in your users home folder. Add following values and paste your runner token to the runnerRegistrationToken.
gitlabUrl: https://gitlab.labranet.jamk.fi/
runnerRegistrationToken: <YOUR REGISTRATION TOKEN>
concurrent: 10
checkInterval: 30
rbac:
create: true
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["list", "get", "watch", "create", "delete"]
- apiGroups: [""]
resources: ["pods/exec"]
verbs: ["create"]
- apiGroups: [""]
resources: ["pods/log"]
verbs: ["get"]
- apiGroups: [""]
resources: ["pods/attach"]
verbs: ["list", "get", "create", "delete", "update"]
- apiGroups: [""]
resources: ["secrets"]
verbs: ["list", "get", "create", "delete", "update"]
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["list", "get", "create", "delete", "update"]
runners:
privileged: true
config: |
[[runners]]
[runners.kubernetes]
namespace = "gitlab"
tls_verify = false
image = "docker:19"
privileged = true
3. Runner Helm chart#
Next, we install the runner with Helm. Make sure that Helm repository is added and updated.
Create a dedicated namespace for GitLab runner.
And finally install a Helm chart:
A Helm chart is a structured bundle of files that describe a Kubernetes application, including how to install, configure, and manage it.
--namespace gitlab flag tells Helm which Kubernetes namespace to install the resources into. All pods, deployments, etc. created by this Helm release will live in the namespace called gitlab.
gitlab-runner is the release name, a name chosen for this specific installation of the chart.
gitlab/gitlab-runner is the chart reference, which tells Helm which chart to install and from where. In this case, gitlab refers to the Helm repository we added earlier, and gitlab-runner is the chart name inside that repository.
If the installation was successful, you should see following output:
You can check the installed runner "release" with the following command, which makes Helm list all releases that are deployed in the "gitlab" namespace.
NOTE: You can disable the gitlab-runner because it is not needed since we are also installing the runner with helm. Kubernetes agent only needs one runner active at a time