You are browsing a read-only backup copy of Wikitech. The primary site can be found at wikitech.wikimedia.org
GitLab/Gitlab Runner
GitLab Runner is an application that works with GitLab CI/CD to run jobs in a pipeline.[1] For more information see the official GitLab Runner documentation.
Current Gitlab Runner setup (T287504)
We're currently relying on WMCS VPSs for shared runner capacity. There is a project named gitlab-runners
in which to provision new instances, and a profile to help provision Docker based runners on those instances. Note that a standalone puppetmaster in the same project stores the runner registration token under /etc/puppet/secret
, and Puppet autosigning is turned off to protect the token value.
To set up a new shared runner, following these steps.
- Create a new WMCS VPS instance.
- Log in to [1] and navigate to the
gitlab-runners
project. - Launch a new Debian
buster
instance, following therunner-{nnnn}
naming convention. - Add
profile::gitlab::runner
to the instance's Puppet Classes under the Puppet Configuration tab.
- Log in to [1] and navigate to the
- Wait until the new instance has fully provisioned and you can successfully
ssh
to the running instance using your authorized key. (This typically takes a few minutes.) - Do the little SSL dance that is required of instances that use a standalone puppetmaster.
- On the new runner (
runner-{nnnn}.gitlab-runners.eqiad1.wikimedia.cloud
).- Run
sudo rm -rf /var/lib/puppet/ssl
to remove the existing SSL certs used by the default puppetmaster. - Run
sudo -i puppet agent --test --verbose
to have the puppet client generate a new SSL cert.
- Run
- On
gitlab-runners-puppetmaster-01.gitlab-runners.eqiad1.wikimedia.cloud
sign the new instance's SSL cert.- Run
sudo -i puppet cert list
and find the new instance in the list. - Run
sudo -i puppet cert sign runner-{nnnn}.gitlab-runners.eqiad1.wikimedia.cloud
to sign the client cert.
- Run
- On the new runner (
- Run
sudo -i puppet agent --test --verbose
on the runner to ensure it has fully provisioned theprofile::gitlab::runner
profile. - Verify that the runner has successfully registered with our GitLab instance by viewing the runner list.
Future Gitlab Runner setup (T286958)
This section contains the requirements and plan for a future Gitlab-Runner setup. The goal is to find a secure, scalable and easy to build and maintain setup for the GitLab Runner infrastructure. GitLab Runner support various environments, such as Kubernetes, Docker, OpenShift or just Linux VMs. Furthermore a wide range of compute platforms can be leveraged, such as WMCS, Ganetti, bare metal hosts or public clouds. So this section tries to compare the different options and collect advantages and disadvantages. Privacy considerations can be found in the next section.
GitLab Runner environments
GitLab Runner can be installed:
- in Linux (using official packages)
- in container
- in Kubernetes (as helm chart or agent)
- in OpenShift
- in various other environments
The follow table tries to compare the most important GitLab Runner environments available:
Environment | Advantages | Disadvantages | Additional considerations |
---|---|---|---|
Linux |
|
|
|
Container |
|
|
|
Kubernetes |
|
|
|
OpenShift |
|
Compute Plattforms
Plattform | Advantages | Disadvantages | Additional considerations |
---|---|---|---|
WMCS | |||
Ganetti | |||
Bare metal | |||
Public Cloud (e.g. GCP) |
Elastic demand
https://docs.gitlab.com/runner/executors/kubernetes.html
https://docs.gitlab.com/runner/configuration/autoscale.html
Privacy considerations
Whether these can safely run on a third-party platform
Monitoring of performance and usage
Gitlab-Runner export Prometheus metrics. This metrics should give insights in performance and usage. See Monitoring Gitlab Runner documentation.
However the Gitlab Runner exporter does not support authorization or https. So depending on where the Runners are hosted, a https proxy with authorization is required.