Operations Guide

Referenced documentation

Introduction

The GitLab Runner component is part of Software Factory as a Package (SWaaP).

GitLab Runner is an application that works with GitLab CI/CD to run jobs in a pipeline.

Learn more about it in LLD-Runner and in TASD .

Billing and onboarding

This section aims at describing how billing related to the component is managed and at specifying offers including access to the component.

Billing & onboarding on TDP

On TDP C2:

• Managed Instance runners are available to all users. They are billed through the infrastructure costs. This component can be used to deploy this runner type.
• Self-managed runners can be installed by users in their subscription. They are billed directly to projects. This component can’t be used be end-users.
• Linux Managed Dedicated Runners can be subscribed with a request . They are billed to projects according to the chargeback model. This component can be used to deploy this runner type.
• Windows Managed Dedicated Runners can be subscribed with a request . They are billed to projects according to the chargeback model. This component can’s be used for Windows runners.

On TDP C3-CA:

• Managed Instance runners are not available due to security constraints.
• Self-managed runners can be installed by users in their subscription. They are billed directly to projects. This component can’t be used be end-users.
• Linux Managed Dedicated Runners can be subscribed with a request . They are billed to projects according to the chargeback model. This component can be used to deploy this runner type.
• Windows Managed Dedicated Runners can be subscribed with a request . They are billed to projects according to the chargeback model. This component can’s be used for Windows runners.

Billing & onboarding on RTDP

• Managed Instance runners are not available due to security constraints.
• Self-managed runners can be installed by users in their subscription. They are billed directly to projects. This component can’t be used be end-users.
• Linux Managed Dedicated Runners are not available due incompatiblity between platform services and product requirements.
• Windows Managed Dedicated Runners are not available due incompatiblity between platform services and product requirements.

Billing & onboarding on CASTLE

• Managed Instance runners are not available due to security constraints.
• Self-managed runners can be installed by users in their subscription. They are billed directly to projects. This component can’t be used be end-users.
• Linux Managed Dedicated Runners are not available due incompatiblity between platform design and product requirements.
• Windows Managed Dedicated Runners are not available due incompatiblity between platform design and product requirements.

Component deployment and configuration

Requirements & Pre-requisite

See LLD-Runner §4.2 prerequisites

Configuration

Setting Helm values

Mandatory GitLab Runner values are described in the SWaaP Readme - Helm values .

There’s also a list of required and optional ConfigMaps that are needed. These are described in the GitLab Runner package readme document

Configuring Kubernetes secrets

The required GitLab Runner secrets and how they are created is described in the SWaaP Readme - GitLab Runner secrets .

Deployment & update procedure

The deployment and update procedures are described in the SWaaP Readme - Quick start section .

Settings

This section is optional. list here other settings to be applied after deplyement (as SAML, license …)

Functional Configuration

Self-signed certificates and custom Certification Authorities

For using self-signed certificates and custom Certification Authorities, see the GitLab documentation .

Security and recommendations

CI/CD Masked Variables Recommendations

A penetration test conducted on GitLab Runners revealed that using masked variables can enable the impersonation of certain actions.

**🌟 Recommendation: Raise awareness among developers and DevOps teams about this issue, and provide guidance to avoid using masked variables for storing sensitive data such as passwords

Monitoring

GitLab Runner can be monitored using Prometheus .

Embedded Prometheus metrics

GitLab Runner is instrumented with native Prometheus metrics, which can be exposed via an embedded HTTP server on the /metrics path. The server - if enabled - can be scraped by the Prometheus monitoring system or accessed with any other HTTP client.

The exposed information includes:

• Runner business logic metrics (e.g., the number of currently running jobs)
• Go-specific process metrics (garbage collection stats, goroutines, memstats, etc.)
• General process metrics (memory usage, CPU usage, file descriptor usage, etc.)
• Build version information

Metrics for supervising health of components

To find a full list of all available metrics, curl the metrics endpoint after it is configured and enabled. For example, for a local runner configured with listening port 9252:

$ curl -s "http://localhost:9252/metrics" | grep -E "# HELP"

# HELP gitlab_runner_api_request_statuses_total The total number of api requests, partitioned by runner, endpoint and status.
# HELP gitlab_runner_autoscaling_machine_creation_duration_seconds Histogram of machine creation time.
# HELP gitlab_runner_autoscaling_machine_states The current number of machines per state in this provider.
# HELP gitlab_runner_concurrent The current value of concurrent setting
# HELP gitlab_runner_errors_total The number of caught errors.
# HELP gitlab_runner_limit The current value of limit setting
# HELP gitlab_runner_request_concurrency The current number of concurrent requests for a new job
# HELP gitlab_runner_request_concurrency_exceeded_total Count of excess requests above the configured request_concurrency limit
# HELP gitlab_runner_version_info A metric with a constant '1' value labeled by different build stats fields.

More information on Runner metrics and how to configure the metrics HTTP server can be found in the official documentation .