You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org

GitLab/Gitlab Runner: Difference between revisions

From Wikitech-static
Jump to navigation Jump to search
imported>Dduvall
(→‎Setting up a new shared runner: Verified that running puppet agent twice at the end is not strictly necessary.)
imported>Jelto
No edit summary
 
(12 intermediate revisions by 2 users not shown)
Line 1: Line 1:
GitLab Runner is an application that works with GitLab CI/CD to run jobs in a pipeline.<ref>https://docs.gitlab.com/runner/</ref> For more information see the official [https://docs.gitlab.com/runner/ GitLab Runner documentation].
{{Sidebar
| style = background: white; padding:10px; padding-{{dir|{{pagelang}}|left|right}}:13px; margin:{{dir|{{pagelang}}|5px 12px 5px 0|5px 0 5px 12px}}; width: 350px;
| name = GitLab Runner
| title = GitLab Runner
| image = [[File:Gitlab-logo.svg.svg|center|250px]]
| headingstyle = font-size: 130%; padding: .5em;
| contentstyle = text-align: {{dir|{{pagelang}}|right|left}}; font-size: 14px; padding: .5em; line-height: 1.5;
| abovestyle = text-align: {{dir|{{pagelang}}|right|left}};
| content1 =
{{Special:PrefixIndex/{{FULLPAGENAME}}/ |hideredirects=1 |stripprefix=1}}
* External resources:
** [https://gitlab.wikimedia.org/admin/runners GitLab Runner Admin menu]
** [https://grafana.wikimedia.org/d/Chb-gC07k/gitlab-ci-overview?orgId=1 GitLab CI metrics]
}}


=== Current Gitlab Runner setup ([[phab:T287504|T287504]]) ===<!-- Additional information needed, feel free to edit -->
GitLab Runner is an application that works with GitLab CI/CD to run jobs in a pipeline.<ref>https://docs.gitlab.com/runner/</ref> For more information see the official [https://docs.gitlab.com/runner/ GitLab Runner documentation].


We're currently relying on WMCS VPSs for shared runner capacity. There is a project named <code>gitlab-runners</code> in which to provision new instances, and a profile to help provision Docker based runners on those instances. Note that a [[Help:Standalone_puppetmaster|standalone puppetmaster]] in the same project stores the [https://docs.gitlab.com/runner/register/ runner registration token] under <code>/etc/puppet/secret</code>, and Puppet autosigning is turned off to protect the token value.
===== GitLab Runner types =====
GitLab offers different types of CI Runners. [[GitLab/Gitlab Runner/Shared Runners|Shared GitLab Runners]] are general purpos CI workers. This Runners execute jobs for a wide range of projects inside the <code>[https://gitlab.wikimedia.org/repos /repos]</code> group in GitLab. If access to this kind of Runners is needed, consider moving to the <code>[https://gitlab.wikimedia.org/repos /repos]</code> group and make yourself familiar with the details under [[GitLab/Gitlab Runner/Shared Runners|Shared GitLab Runners]].


==== Setting up a new shared runner ====
[[GitLab/Gitlab Runner/Trusted Runners|Trusted GitLab Runners]] offer a platform for CI jobs with additional security needs (like building production artifacts). This Runners live inside WMF infrastructure and access to this Runners is gated and restricted. Access has to be requested on project basis, so please take a look on [[GitLab/Gitlab Runner/Trusted Runners|Trusted GitLab Runners]] on how to get access.


To set up a new shared runner, following these steps.
It is planned to add CI support for all projects using [[GitLab/Gitlab Runner/Cloud Runners|Cloud Runners]]. This Runners are in design phase and access to this Runners will be announced.


# Create a new WMCS VPS instance.
===== Evaluation and Design =====
## Log in to [https://horizon.wikimedia.org] and navigate to the <code>gitlab-runners</code> project.
Evaluation sub-pages on the right menu offer more insights into the design and security considerations.  
## Launch a new Debian <code>buster</code> instance, following the <code>runner-{nnnn}</code> naming convention.
## Add <code>profile::gitlab::runner</code> to the instance's Puppet Classes under the Puppet Configuration tab.
# Wait until the new instance has fully provisioned and you can successfully <code>ssh</code> to the running instance using your authorized key. (This typically takes a few minutes.)
# Do [[Help:Standalone_puppetmaster#Step_2:_Setup_a_puppet_client|the little SSL dance]] that is required of instances that use a standalone puppetmaster.
## On the new runner (<code>runner-{nnnn}.gitlab-runners.eqiad1.wikimedia.cloud</code>).
### Run <code>sudo rm -rf /var/lib/puppet/ssl</code> to remove the existing SSL certs used by the default puppetmaster.
### Run <code>sudo -i puppet agent --test --verbose</code> to have the puppet client generate a new SSL cert.
## On <code>gitlab-runners-puppetmaster-01.gitlab-runners.eqiad1.wikimedia.cloud</code> sign the new instance's SSL cert.
### Run <code>sudo -i puppet cert list</code> and find the new instance in the list.
### Run <code>sudo -i puppet cert sign runner-{nnnn}.gitlab-runners.eqiad1.wikimedia.cloud</code> to sign the client cert.
# Run <code>sudo -i puppet agent --test --verbose</code> on the runner to ensure it has fully provisioned the <code>profile::gitlab::runner</code> profile.
# Verify that the runner has successfully registered with our GitLab instance by viewing the [https://gitlab.wikimedia.org/admin/runners runner list].


=== Future Gitlab Runner setup ([[phab:T286958|T286958]]) ===
<references />
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 [https://docs.gitlab.com/runner/install/linux-repository.html official packages])
* in [https://docs.gitlab.com/runner/install/docker.html container]
* in Kubernetes (as [https://docs.gitlab.com/runner/install/kubernetes.html helm chart] or [https://docs.gitlab.com/runner/install/kubernetes-agent.html agent])
* in [https://docs.gitlab.com/runner/install/openshift.html OpenShift]
* in various other environments
The follow table tries to compare the most important GitLab Runner environments available:
{| class="wikitable"
|+
!Environment
!Advantages
!Disadvantages
!Additional considerations
|-
|Linux
|
* Easy to setup
* low maintenance
* Similar to current solution
|
* Low elasticity, difficult to scale
*
|
|-
|Container
|
* Easy to setup
* low maintenance
|
* difficult to scale
* auto scaling needs<code>docker-machine</code>
|
|-
|Kubernetes
|
* High elasticity/auto scaling
*
|
* Additional Kubernetes needed (for security)
* Additional cluster needs maintenance
* More difficult to setup
|
* Could be used to strengthen Kubernetes knowledge
* Auto scaling needs elastic compute plattform
*Maybe a general purpose non-production cluster can be build?
|-
|OpenShift
|
|
* not in use in WMF
|
|}
 
==== Compute Plattforms ====
{| class="wikitable"
|+
!Plattform
!Advantages
!Disadvantages
!Additional considerations
|-
|WMCS
|
|
|
|-
|Ganetti
|
|
|
|-
|Bare metal
|
|
|
|-
|Public Cloud (e.g. GCP)
|
|
|
|}
 
===== Elastic demand =====
https://docs.gitlab.com/runner/enterprise_guide/#autoscaling-configuration-one-or-more-runner-managers-multiple-workers
 
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 [https://docs.gitlab.com/runner/monitoring/ 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.
 
<ref>https://docs.gitlab.com/runner/monitoring/#configuration-of-the-metrics-http-server</ref>

Latest revision as of 14:37, 4 February 2022

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.

GitLab Runner types

GitLab offers different types of CI Runners. Shared GitLab Runners are general purpos CI workers. This Runners execute jobs for a wide range of projects inside the /repos group in GitLab. If access to this kind of Runners is needed, consider moving to the /repos group and make yourself familiar with the details under Shared GitLab Runners.

Trusted GitLab Runners offer a platform for CI jobs with additional security needs (like building production artifacts). This Runners live inside WMF infrastructure and access to this Runners is gated and restricted. Access has to be requested on project basis, so please take a look on Trusted GitLab Runners on how to get access.

It is planned to add CI support for all projects using Cloud Runners. This Runners are in design phase and access to this Runners will be announced.

Evaluation and Design

Evaluation sub-pages on the right menu offer more insights into the design and security considerations.