• 구성 유효성 검사
• 전역 섹션
  • log_format 예시 (축소)
    • runner
    • text
    • json
• [[runners]] 섹션
  • clone_url 동작 방식
  • unhealthy_requests_limit 및 unhealthy_interval 동작 방식
• 실행자
• 셸
  • POSIX 호환 셸 사용
• [runners.docker] 섹션
  • [[runners.docker.services]] 섹션
  • [runners.docker] 섹션의 볼륨
    • 예시 1: 데이터 볼륨 추가
    • 예시 2: 호스트 디렉터리를 데이터 볼륨으로 마운트
  • 개인 컨테이너 레지스트리 사용
    • GitLab 통합 레지스트리 지원
    • Docker 권한 확인 해결 우선 순위
• [runners.parallels] 섹션
• [runners.virtualbox] 섹션
• 기본 VM 이미지 재정의
• [runners.ssh] 섹션
• [runners.machine] 섹션
  • [[runners.machine.autoscaling]] 섹션
  • Periods 구문
• [runners.instance] 섹션
• [runners.autoscaler] 섹션
• [runners.autoscaler.plugin_config] 섹션
• [runners.autoscaler.scale_throttle] 섹션
• [runners.autoscaler.connector_config] 섹션
• [[runners.autoscaler.policy]] 섹션
  • 사용 기간 구문
• [runners.autoscaler.vm_isolation] 섹션
• [runners.autoscaler.vm_isolation.connector_config] 섹션
• [runners.custom] 섹션
• [runners.cache] 섹션
  • [runners.cache.s3] 섹션
    • S3 버킷에서 실행자 캐시에 KMS 키 암호화 사용
    • Kubernetes ServiceAccount 리소스용 IAM 역할 활성화
  • [runners.cache.gcs] 섹션
  • [runners.cache.azure] 섹션
• [runners.kubernetes] 섹션
• 지원 이미지
  • Arm용 Kubernetes를 위한 Helper 이미지 구성
  • 이전 버전의 Alpine Linux를 사용하는 Runner 이미지
  • Alpine pwsh 이미지
  • Helper 이미지 레지스트리
  • Helper 이미지 재정의
    • PowerShell Core 사용 시
• [runners.custom_build_dir] 섹션
  • 기본 빌드 디렉터리
• [runners.referees] 섹션
  • Metrics Runner referee 사용
  • GitLab Runner용 Metrics Runner Referee 구성

고급 구성

GitLab Runner 및 개별 등록 러너의 동작을 변경하려면 config.toml 파일을 수정하세요.

config.toml 파일은 다음 위치에 있습니다.

• /etc/gitlab-runner/ (루트로 실행되는 *nix 시스템에서 GitLab Runner가 실행될 때) 이 디렉터리는 서비스 구성을위한 경로로 사용됩니다.
• ~/.gitlab-runner/ (*nix 시스템에서 루트로 실행되지 않을 때)
• 다른 시스템에서는 ./입니다.

대부분의 옵션을 변경할 때 GitLab Runner는 다시 시작할 필요가 없습니다. 이에는 [[runners]] 섹션의 매개변수와 전역 섹션의 대부분의 매개변수가 포함됩니다. listen_address를 제외한 매개변수입니다. 러너가 이미 등록되어 있으면 다시 등록할 필요가 없습니다.

GitLab Runner는 구성 수정을 모니터링하고, 필요한 경우 3초마다 리로드합니다. SIGHUP 신호에 응답하여 구성을 다시 로드합니다.

구성 유효성 검사

• GitLab Runner 15.10에 도입됨

구성 유효성 검사는 config.toml 파일의 구조를 확인하는 프로세스입니다. 구성 유효성 검사기의 출력은 info 수준 메시지만 제공합니다.

구성 유효성 검사 프로세스는 정보 목적으로만 사용됩니다. 출력을 사용하여 러너 구성에 잠재적인 문제를 식별할 수 있습니다. 그러나 구성 유효성 검사는 모든 가능한 문제를 잡지 못할 수 있으며, 메시지의 부재가 config.toml 파일이 완벽하다는 것을 보장하지 않습니다.

전역 섹션

이러한 설정은 전역 설정입니다. 모든 러너에 적용됩니다.

구성 예시:

concurrent = 4
log_level = "warning"

log_format 예시 (축소)

runner

Runtime platform                                    arch=amd64 os=darwin pid=37300 revision=HEAD version=development version
Starting multi-runner from /etc/gitlab-runner/config.toml...  builds=0
WARNING: Running in user-mode.
WARNING: Use sudo for system-mode:
WARNING: $ sudo gitlab-runner...

Configuration loaded                                builds=0
listen_address not defined, metrics & debug endpoints disabled  builds=0
[session_server].listen_address not defined, session endpoints disabled  builds=0

text

INFO[0000] Runtime platform                              arch=amd64 os=darwin pid=37773 revision=HEAD version="development version"
INFO[0000] Starting multi-runner from /etc/gitlab-runner/config.toml...  builds=0
WARN[0000] Running in user-mode.
WARN[0000] Use sudo for system-mode:
WARN[0000] $ sudo gitlab-runner...
INFO[0000]
INFO[0000] Configuration loaded                          builds=0
INFO[0000] listen_address not defined, metrics & debug endpoints disabled  builds=0
INFO[0000] [session_server].listen_address not defined, session endpoints disabled  builds=0

json

{"arch":"amd64","level":"info","msg":"Runtime platform","os":"darwin","pid":38229,"revision":"HEAD","time":"2020-06-05T15:57:35+02:00","version":"development version"}
{"builds":0,"level":"info","msg":"Starting multi-runner from /etc/gitlab-runner/config.toml...","time":"2020-06-05T15:57:35+02:00"}
{"level":"warning","msg":"Running in user-mode.","time":"2020-06-05T15:57:35+02:00"}
{"level":"warning","msg":"Use sudo for system-mode:","time":"2020-06-05T15:57:35+02:00"}
{"level":"warning","msg":"$ sudo gitlab-runner...","time":"2020-06-05T15:57:35+02:00"}
{"level":"info","msg":"","time":"2020-06-05T15:57:35+02:00"}
{"builds":0,"level":"info","msg":"Configuration loaded","time":"2020-06-05T15:57:35+02:00"}
{"builds":0,"level":"info","msg":"listen_address not defined, metrics \u0026 debug endpoints disabled","time":"2020-06-05T15:57:35+02:00"}
{"builds":0,"level":"info","msg":"[session_server].listen_address not defined, session endpoints disabled","time":"2020-06-05T15:57:35+02:00"}

### `check_interval` 동작 방식

만약 `config.toml`에 하나 이상의 `[[runners]]` 섹션이 있다면, GitLab Runner에는 GitLab Runner가 구성되어 있는 GitLab 인스턴스에 작업 요청을 계속 스케줄링하는 반복문이 포함되어 있습니다.

다음 예제는 `check_interval`이 10초이고 두 `[[runners]]` 섹션 (`runner-1` 및 `runner-2`)이있는 경우를 보여줍니다.
GitLab Runner는 10초마다 요청을 보내고 5초 동안 쉽니다.

1. `check_interval` 값 (`10s`) 가져 오기.
1. 러너 디렉터리 받기 (`runner-1`, `runner-2`).
1. 슬립 간격 계산 (`10s / 2 = 5s`).
1. 무한 루프 시작:
    1. "runner-1"에 대한 작업 요청.
    1. `5s` 동안 잠자기.
    1. "runner-2"에 대한 작업 요청.
    1. `5s` 동안 잠자기.
    1. 반복.

이 예에서 러너 프로세스의 작업 요청은 5초마다 발생합니다.
`runner-1` 및 `runner-2`에 대한 연속적인 요청 사이에 두 가지 슬립 기간이 있습니다.
각 기간은 5초이므로 `runner-1`에 대한 후속 요청 사이에 약 10초가 걸립니다.
`runner-2`에도 동일한 사항이 적용됩니다.

러너를 더 정의하면 슬립 간격이 더 작아집니다.
그러나 러너의 요청이 다른 러너의 요청 및 그들의 슬립 기간 이후에 반복됩니다.

## `[session_server]` 섹션

`[session_server]` 섹션을 사용하면 사용자가 [대화형 웹 터미널](https://docs.gitlab.com/ee/ci/interactive_web_terminal/index.html)에서 작업을 상호 작용할 수 있습니다.

`[session_server]` 섹션은 실행기별이 아닌 루트 수준에서 지정되어야 합니다. `[[runners]]` 섹션 바깥에 정의되어야 합니다.

```toml
[session_server]
  listen_address = "[::]:8093" # 8093포트에서 모든 사용 가능한 인터페이스에서 수신 대기
  advertise_address = "runner-host-name.tld:8093"
  session_timeout = 1800

[session_server] 섹션을 구성할 때:

• listen_address 및 advertise_address에는 host:port 형식을 사용하며, 여기서 host는 IP 주소(127.0.0.1:8093) 또는 도메인(my-runner.example.com:8093)이어야 합니다. 실행기는 안전한 연결을 위해 TLS 인증서를 생성하는 데 이 정보를 사용합니다.
• 웹 브라우저가 advertise_address에 연결할 수 있는지 확인하세요. 라이브 세션은 웹 브라우저에서 시작됩니다.
• advertise_address가 공용 IP 주소인지 확인하세요. 그렇지 않으면 allow_local_requests_from_web_hooks_and_services 애플리케이션 설정을 활성화했는지 확인하세요.

세션 서버와 터미널 지원을 비활성화하려면 [session_server] 섹션을 삭제하세요.

GitLab Runner Docker 이미지를 사용하는 경우 docker run 명령에 -p 8093:8093을 추가하여 포트 8093을 노출해야 합니다.

[[runners]] 섹션

각 [[runners]] 섹션은 실행기를 정의합니다.

예:

[[runners]]
  name = "ruby-2.7-docker"
  url = "https://CI/"
  token = "TOKEN"
  limit = 0
  executor = "docker"
  builds_dir = ""
  shell = ""
  environment = ["ENV=value", "LC_ALL=en_US.UTF-8"]
  clone_url = "http://gitlab.example.local"

clone_url 동작 방식

실행기가 사용할 수 없는 URL에 GitLab 인스턴스가 있는 경우 clone_url을 구성할 수 있습니다.

예를 들어, 방화벽이 실행기가 URL에 도달하는 것을 방지할 수 있습니다. 실행기가 192.168.1.23 노드에 연결 가능한 경우, clone_url을 http://192.168.1.23로 설정하세요.

clone_url을 설정하면 실행기는 http://gitlab-ci-token:s3cr3tt0k3n@192.168.1.23/namespace/project.git 형식의 클론 URL을 작성합니다.

unhealthy_requests_limit 및 unhealthy_interval 동작 방식

GitLab 인스턴스가 장기간(예: 버전 업그레이드 중) 사용할 수 없는 경우, 해당 인스턴스에 구성된 실행기가 유휴 상태가 되어 GitLab 인스턴스가 다시 사용 가능해지면 30~60분 후에 작업 처리를 재개하지 않습니다.

실행기가 유휴 상태로 유지되는 기간을 늘리거나 줄이려면 unhealthy_interval 설정을 변경하세요.

실행기가 GitLab 서버에 연결을 시도하고 유효하지 않은 대기를 받은 횟수를 변경하여 실행기가 유휴 상태로 전환되기 전에 설정한 횟수를 변경하세요. 자세한 내용은 check_interval 동작 방식을 참조하세요.

실행자

다음 실행자들이 이용 가능합니다.

셸

이용 가능한 셸은 다른 플랫폼에서 실행할 수 있습니다.

shell 옵션이 bash 또는 sh로 설정된 경우 Bash의 ANSI-C quoting을 사용하여 작업 스크립트를 셸 이스케이프합니다.

POSIX 호환 셸 사용

GitLab Runner 14.9 이상에서 옵션 플래그로 FF_POSIXLY_CORRECT_ESCAPES를 활성화하여 dash와 같은 POSIX 호환 셸을 사용할 수 있습니다. 활성화되면 POSIX 호환 셸 이스케이핑 메커니즘인 “Double Quotes”을 사용합니다.

[runners.docker] 섹션

다음 설정은 Docker 컨테이너 매개변수를 정의합니다.

Docker-in-Docker 서비스 또는 작업 안에 구성된 모든 컨테이너 런타임은 이러한 매개변수를 상속하지 않습니다.

(이하 생략)

[[runners.docker.services]] 섹션

작업과 함께 실행할 추가 서비스를 지정합니다. 사용 가능한 이미지 디렉터리은 Docker Registry를 참조하세요. 각 서비스는 별도의 컨테이너에서 실행되며 작업에 연결됩니다.

예시:

[runners.docker]
  host = ""
  hostname = ""
  tls_cert_path = "/Users/ayufan/.boot2docker/certs"
  image = "ruby:2.7"
  memory = "128m"
  memory_swap = "256m"
  memory_reservation = "64m"
  oom_kill_disable = false
  cpuset_cpus = "0,1"
  cpuset_mems = "0,1"
  cpus = "2"
  dns = ["8.8.8.8"]
  dns_search = [""]
  service_memory = "128m"
  service_memory_swap = "256m"
  service_memory_reservation = "64m"
  service_cpuset_cpus = "0,1"
  service_cpus = "2"
  services_limit = 5
  privileged = false
  group_add = ["docker"]
  userns_mode = "host"
  cap_add = ["NET_ADMIN"]
  cap_drop = ["DAC_OVERRIDE"]
  devices = ["/dev/net/tun"]
  disable_cache = false
  wait_for_services_timeout = 30
  cache_dir = ""
  volumes = ["/data", "/home/project/cache"]
  extra_hosts = ["other-host:127.0.0.1"]
  shm_size = 300000
  volumes_from = ["storage_container:ro"]
  links = ["mysql_container:mysql"]
  allowed_images = ["ruby:*", "python:*", "php:*"]
  allowed_services = ["postgres:9", "redis:*", "mysql:*"]
  [runners.docker.ulimit]
    "rtprio" = "99"
  [[runners.docker.services]]
    name = "registry.example.com/svc1"
    alias = "svc1"
    entrypoint = ["entrypoint.sh"]
    command = ["executable","param1","param2"]
    environment = ["ENV1=value1", "ENV2=value2"]
  [[runners.docker.services]]
    name = "redis:2.8"
    alias = "cache"
  [[runners.docker.services]]
    name = "postgres:9"
    alias = "postgres-db"
  [runners.docker.sysctls]
    "net.ipv4.ip_forward" = "1"

[runners.docker] 섹션의 볼륨

볼륨에 대한 자세한 정보는 Docker documentation을 참조하세요.

다음 예시에서는 [runners.docker] 섹션에서 볼륨을 지정하는 방법을 보여줍니다.

예시 1: 데이터 볼륨 추가

데이터 볼륨은 유니온 파일 시스템을 우회하는 하나 이상의 컨테이너에서 특별히 지정된 디렉터리입니다. 데이터 볼륨은 컨테이너 수명과 독립적으로 데이터를 유지하도록 설계되었습니다.

[runners.docker]
  host = ""
  hostname = ""
  tls_cert_path = "/Users/ayufan/.boot2docker/certs"
  image = "ruby:2.7"
  privileged = false
  disable_cache = true
  volumes = ["/path/to/volume/in/container"]

이 예시는 컨테이너 내 /path/to/volume/in/container에 새 볼륨을 생성합니다.

예시 2: 호스트 디렉터리를 데이터 볼륨으로 마운트

컨테이너 외부에 디렉터리를 저장하려는 경우 Docker 데몬의 호스트에서 디렉터리를 컨테이너에 마운트할 수 있습니다.

[runners.docker]
  host = ""
  hostname = ""
  tls_cert_path = "/Users/ayufan/.boot2docker/certs"
  image = "ruby:2.7"
  privileged = false
  disable_cache = true
  volumes = ["/path/to/bind/from/host:/path/to/bind/in/container:rw"]

이 예시는 호스트의 CI/CD 디렉터리 /path/to/bind/from/host를 컨테이너 내 /path/to/bind/in/container에 사용합니다.

GitLab Runner 11.11 이상부터 정의된 [services](https://docs.gitlab.com/ee/ci/services/)의 호스트 디렉터리를 마운트합니다.

개인 컨테이너 레지스트리 사용

작업에 대한 이미지의 소스로 개인 레지스트리를 사용하려면 CI/CD variable DOCKER_AUTH_CONFIG를 구성하세요. 다음 중 하나에서 변수를 설정할 수 있습니다.

• 프로젝트의 CI/CD 설정에서 file 타입
• config.toml 파일

if-not-present 풀(pull) 정책을 사용하여 개인 레지스트리를 사용하는 경우 보안 취약점이 발생할 수 있습니다. 풀(pull) 정책이 작동하는 방법에 대한 자세한 정보는 러너(runner)가 이미지를 풀(pull)하는 방법 구성을 참조하세요.

개인 컨테이너 레지스트리 사용에 대한 자세한 정보는 다음을 참조하세요.

• 개인 컨테이너 레지스트리에서 이미지에 액세스
• .gitlab-ci.yml 키워드 참조

러너(runner)에 의해 수행되는 단계는 다음과 같습니다:

1. 이미지 이름에서 레지스트리 이름을 찾습니다.
2. 값이 비어 있지 않으면, 실행기는 이 레지스트리에 대한 인증 구성을 검색합니다.
3. 마지막으로, 지정된 레지스트리에 해당하는 인증이 발견되면, 후속 풀(pull)에서 이를 사용합니다.

GitLab 통합 레지스트리 지원

GitLab은 작업 데이터와 함께 통합된 레지스트리에 대한 자격 증명을 전송합니다. 이러한 자격 증명은 자동으로 레지스트리의 인증 매개변수 디렉터리에 추가됩니다.

이 단계 이후, 레지스트리에 대한 인증은 DOCKER_AUTH_CONFIG 변수로 추가된 구성과 유사하게 진행됩니다.

작업에서 GitLab 통합된 레지스트리에서 호스트 디렉터리를 사용할 수 있으며, 해당 이미지가 개인 또는 보호된 경우에도 사용할 수 있습니다. 작업이 액세스하는 이미지에 대한 정보는 CI/CD job token documentation 문서를 읽어보세요.

Docker 권한 확인 해결 우선 순위

이전에 설명한 대로, GitLab Runner는 다른 방식으로 보낸 자격 증명을 사용하여 레지스트리에 대한 Docker를 인가할 수 있습니다. 적절한 레지스트리를 찾기 위해 다음과 같은 우선 순위가 고려됩니다:

1. DOCKER_AUTH_CONFIG로 구성된 자격 증명.
2. ~/.docker/config.json 또는 ~/.dockercfg 파일로 지역적으로 구성된 GitLab Runner 호스트의 자격 증명(예: 호스트에서 docker login 실행).
3. 작업 페이로드와 함께 기본으로 보내진 자격 증명(예: 이전에 설명한 통합 레지스트리의 자격 증명).

레지스트리에 대한 첫 번째 발견된 자격 증명이 사용됩니다. 따라서 예를 들어, 통합 레지스트리에 대한 자격 증명을 DOCKER_AUTH_CONFIG 변수로 추가하면 기본 자격 증명이 재정의됩니다.

[runners.parallels] 섹션

다음 매개변수는 Parallels를 위한 것입니다.

예:

[runners.parallels]
  base_name = "my-parallels-image"
  template_name = ""
  disable_snapshots = false

[runners.virtualbox] 섹션

다음 매개변수는 VirtualBox를 위한 것입니다. 이 실행기는 VirtualBox 머신을 제어하기 위해 vboxmanage 실행 파일을 의존하므로 Windows 호스트에서는 PATH 환경 변수를 조정해야 합니다: PATH=%PATH%;C:\Program Files\Oracle\VirtualBox.

예:

[runners.virtualbox]
  base_name = "my-virtualbox-image"
  base_snapshot = "my-image-snapshot"
  disable_snapshots = false
  start_type = "headless"

start_type 매개변수는 가상 이미지를 시작할 때 사용되는 그래픽 프론트 엔드를 결정합니다. 유효한 값은 호스트 및 게스트 조합에서 지원되는 headless(기본 설정), gui, 또는 separate입니다.

기본 VM 이미지 재정의

• GitLab Runner 14.2에서 도입되었습니다.

Parallels 및 VirtualBox 실행기 모두 base_name으로 지정된 기본 VM 이름을 재정의할 수 있습니다. 이를 위해 .gitlab-ci.yml 파일에 있는 image 매개변수를 사용하세요.

백워드 호환성을 위해 기본값으로는 이 값을 재정의할 수 없습니다. base_name으로 지정된 이미지만 허용됩니다.

.gitlab-ci.yml image 매개변수를 사용하여 사용자가 VM 이미지를 선택하도록 허용하려면:

[runners.virtualbox]
  ...
  allowed_images = [".*"]

이 예에서 기존 VM 이미지를 사용할 수 있습니다.

allowed_images 매개변수는 정규 표현식 디렉터리입니다. 구성은 필요에 따라 구체적일 수 있습니다. 예를 들어 특정 VM 이미지만 허용하려면 다음과 같이 정규식을 사용할 수 있습니다:

[runners.virtualbox]
  ...
  allowed_images = ["^allowed_vm[1-2]$"]

이 예에서는 allowed_vm1 및 allowed_vm2만 허용됩니다. 다른 시도는 오류가 발생합니다.

[runners.ssh] 섹션

다음 매개변수는 SSH 연결을 정의합니다.

예:

[runners.ssh]
  host = "my-production-server"
  port = "22"
  user = "root"
  password = "production-server-password"
  identity_file = ""

[runners.machine] 섹션

다음 매개변수는 Docker Machine 기반의 자동 확장 기능을 정의합니다. 자세한 정보는 Docker Machine Executor autoscale configuration을 참조하세요.

[[runners.machine.autoscaling]] 섹션

예시:

[runners.machine]
  IdleCount = 5
  IdleTime = 600
  MaxBuilds = 100
  MachineName = "auto-scale-%s"
  MachineDriver = "google" # Docker Machine 문서를 참조하여 인증하는 방법: https://docs.docker.com/machine/drivers/gce/#credentials
  MachineOptions = [
      # Google Compute Engine 드라이버를 사용하여 추가 머신 옵션을 추가할 수 있습니다.
      # 호스트에 연결할 수 없음(예: "SSH 대기 중"과 같은 문제가 발생)하면
      # 디버깅을 돕기 위해 선택적 매개변수를 제거해야 합니다.
      # https://docs.docker.com/machine/drivers/gce/
      "google-project=GOOGLE-PROJECT-ID",
      "google-zone=GOOGLE-ZONE", # 예: 'us-central1-a', 전체 디렉터리은 https://cloud.google.com/compute/docs/regions-zones/에서 확인할 수 있음
  ]
  [[runners.machine.autoscaling]]
    Periods = ["* * 9-17 * * mon-fri *"]
    IdleCount = 50
    IdleCountMin = 5
    IdleScaleFactor = 1.5 # 현재 _Idle_ 머신 수가 1.5*사용 중인 머신 수가 되며, 이 값은 50(IdleCount 값)을 초과하지 않고 5(IdleCountMin 값) 미만으로 됨
    IdleTime = 3600
    Timezone = "UTC"
  [[runners.machine.autoscaling]]
    Periods = ["* * * * * sat,sun *"]
    IdleCount = 5
    IdleTime = 60
    Timezone = "UTC"

Periods 구문

Periods 설정은 cron 스타일 형식으로 표현된 시간대의 문자열 패턴 배열을 포함합니다. 이 줄에는 다음과 같은 필드가 포함됩니다.

[초] [분] [시] [월의 일] [월] [주의 일] [년]

표준 cron 구성 파일과 마찬가지로 필드에는 단일 값, 범위, 디렉터리, 별표(*)가 포함될 수 있습니다. 구문에 대한 자세한 설명은 문법에 대한 상세한 설명을 참조하세요.

[runners.instance] 섹션

다음 매개변수들은 인스턴스 실행기의 구성을 정의합니다. 인스턴스 실행기는 베타 상태입니다.

[runners.autoscaler] 섹션

• GitLab Runner v15.10.0에서 소개되었습니다.

다음 매개변수들은 자동 스케일러 기능을 구성합니다. 이러한 매개변수는 인스턴스 및 도커 자동 스케일러 실행기와 함께만 사용할 수 있습니다. 이러한 실행기들은 베타 상태입니다.

[runners.autoscaler.plugin_config] 섹션

이 해시 테이블은 JSON으로 다시 인코딩되어 구성된 플러그인으로 직접 전달됩니다.

fleeting 플러그인은 일반적으로 지원되는 구성에 대한 도움말이 있습니다.

[runners.autoscaler.scale_throttle] 섹션

• GitLab Runner v17.0.0에서 소개되었습니다.

[runners.autoscaler.connector_config] 섹션

fleeting 플러그인은 일반적으로 지원되는 연결 옵션에 대한 동반 설명서가 있습니다.

플러그인은 자동으로 커넥터 구성을 업데이트합니다. [runners.autoscaler.connector_config]를 사용하여 커넥터 구성의 자동 업데이트를 무시하거나, 플러그인이 결정할 수 없는 빈 값으로 채울 수 있습니다.

[[runners.autoscaler.policy]] 섹션

참고 - 이 문맥에서의 idle_count는 레거시 자동 스케일링 방법과 달리 작업의 수를 나타냅니다.

scale_factor를 설정하면 idle_count가 최소 idle 용량이 되고, scaler_factor_limit가 최대 idle 용량이 됩니다.

여러 정책을 정의할 수 있습니다. 가장 나중에 매칭되는 정책이 사용됩니다.

다음 예제에서는 월요일부터 금요일까지 08:00부터 15:59까지 1의 idle count가 사용됩니다. 그 외에는 idle count가 0입니다.

[[runners.autoscaler.policy]]
  idle_count        = 1
  idle_time         = "30m0s"
  periods           = ["* 8-15 * * mon-fri"]

[[runners.autoscaler.policy]]
  idle_count        = 0
  idle_time         = "0s"
  periods           = ["* * * * *"]

사용 기간 구문

periods 설정에는 정책이 활성화된 기간을 나타내는 unix-cron 형식 문자열 배열이 포함됩니다. cron 형식은 5개의 필드로 구성됩니다:

 ┌────────── 분 (0 - 59)
 │ ┌──────── 시간 (0 - 23)
 │ │ ┌────── 월 일 (1 - 31)
 │ │ │ ┌──── 월 (1 - 12)
 │ │ │ │ ┌── 요일 (1 - 7 또는 MON-SUN, 0 은 일요일의 별칭)
 * * * * *

• -는 두 숫자 사이에 사용되어 범위를 지정하는 데 사용될 수 있습니다.
• *는 해당 필드에 대한 유효한 값의 전체 범위를 나타내는 데 사용될 수 있습니다.
• / 뒤에 숫자가 올 수 있으며, 범위 뒤에 숫자가 오면 해당 숫자를 범위 동안 건너뛰는 데 사용될 수 있습니다. 예를 들어, 시간 필드에 0-12/2를 사용하면 00:00부터 00:12까지 2시간마다 기간이 활성화됩니다.
• ,는 필드의 유효한 숫자나 범위 디렉터리을 구분하는 데 사용될 수 있습니다. 예를 들어, 1,2,6-9입니다.

이 cron job은 시간 범위를 나타내므로 주의해야 합니다. 예를 들어:

[runners.autoscaler.vm_isolation] 섹션

VM 격리는 현재 MacOS에서만 지원되는 nesting을 사용합니다.

[runners.autoscaler.vm_isolation.connector_config] 섹션

[runners.autoscaler.vm_isolation.connector_config] 섹션의 매개변수는 [runners.autoscaler.connector_config] 섹션과 동일하지만, 자동 스케일링된 인스턴스가 아닌 nesting 프로비저닝된 가상 머신에 연결하는 데 사용됩니다.

[runners.custom] 섹션

다음 매개변수는 커스텀 실행기 구성을 정의합니다.

[runners.cache] 섹션

분산 캐시 기능을 정의하는 다음 매개변수를 보여줍니다. 자세한 내용은 러너(runner) 오토스케일 문서를 확인하십시오.

캐시 메커니즘은 미리 서명된 URL을 사용하여 캐시를 업로드하고 다운로드합니다. URL은 GitLab Runner에 의해 자체 인스턴스에서 서명됩니다. 작업 스크립트(캐시 업로드/다운로드 스크립트 포함)가 로컬 또는 외부 머신에서 실행되는지 여부는 중요하지 않습니다. 예를 들어, shell 또는 docker 실행기는 GitLab Runner 프로세스가 실행되는 기계에서 스크립트를 실행합니다. 동시에 virtualbox 또는 docker+machine은 별도의 VM에 연결하여 스크립트를 실행합니다. 이 프로세스는 보안상의 이유로 캐시 어댑터 자격 증명이 누출되는 가능성을 최소화하기 위한 것입니다.

S3 캐시 어댑터가 IAM 인스턴스 프로필을 사용하도록 구성된 경우 어댑터는 GitLab Runner 머신에 연결된 프로필을 사용합니다. 마찬가지로 GCS 캐시 어댑터도 CredentialsFile을 사용하도록 구성된 경우 파일은 GitLab Runner 머신에 있어야 합니다.

이 테이블은 register를 위한 config.toml, CLI 옵션 및 ENV 변수를 나열합니다.

[runners.cache.s3] 섹션

다음 매개변수는 캐시용 S3 스토리지를 정의합니다.

예시:

[runners.cache]
  Type = "s3"
  Path = "path/to/prefix"
  Shared = false
  [runners.cache.s3]
    ServerAddress = "s3.amazonaws.com"
    AccessKey = "AWS_S3_ACCESS_KEY"
    SecretKey = "AWS_S3_SECRET_KEY"
    BucketName = "runners-cache"
    BucketLocation = "eu-west-1"
    Insecure = false
    ServerSideEncryption = "KMS"
    ServerSideEncryptionKeyID = "alias/my-key"

ServerAddress, AccessKey, 또는 SecretKey 중 하나라도 지정되지 않았거나 AuthenticationType이 제공되지 않은 경우 S3 클라이언트는 gitlab-runner 인스턴스에 사용 가능한 IAM 인스턴스 프로필을 사용합니다. 오토스케일 구성에서는 이 작업이 실행되는 요청에 단말 기계가 아닙니다. ServerAddress, AccessKey, 및 SecretKey가 모두 제공되지만 AuthenticationType이 제공되지 않은 경우 인증 유형으로 access-key가 사용됩니다.

GitLab Runner를 설치할 때 Helm 차트를 사용하고 values.yaml 파일에서 rbac.create가 true로 설정된 경우 ServiceAccount가 생성됩니다. 이 ServiceAccount의 주석은 rbac.serviceAccountAnnotations 섹션에서 검색됩니다.

Amazon EKS에서 러너를 사용하는 경우 서비스 계정에 할당할 IAM 역할을 지정할 수 있습니다. 필요한 구체적인 주석은 다음과 같습니다. eks.amazonaws.com/role-arn: arn:aws:iam::<ACCOUNT_ID>:role/<IAM_ROLE_NAME>.

이 역할에 대한 IAM 정책은 지정된 버킷에 대해 다음 작업을 수행할 수 있는 권한이 있어야 합니다:

• s3:PutObject
• s3:GetObjectVersion
• s3:GetObject
• s3:DeleteObject

KMS 유형의 ServerSideEncryption를 사용하는 경우이 역할은 지정된 AWS KMS 키에 대해 다음 작업을 수행할 수 있는 권한이 있어야 합니다.

• kms:Encrypt
• kms:Decrypt
• kms:ReEncrypt*
• kms:GenerateDataKey*
• kms:DescribeKey

SSE-C 유형의 ServerSideEncryption은 지원되지 않습니다. SSE-C는 암호화 키가 전달되는 헤더가 추가로 제공되는 경우에도 다운로드 요청을 위해 사용자 제공 키가 제공되어야 합니다. 이는 작업에 키 자료를 전달하게되어 키를 안전하게 보관할 수 없음을 의미합니다. 이는 해독 키가 누출될 가능성이 있는 잠재적인 위험성을 가지게 됩니다. 이 문제에 대한 논의는 이 머지 요청에서 확인할 수 있습니다.

S3 버킷에서 실행자 캐시에 KMS 키 암호화 사용

GenerateDataKey API는 클라이언트 측 암호화를 위해 KMS 대칭 키를 사용하여 데이터 키를 생성합니다 (https://docs.aws.amazon.com/kms/latest/APIReference/API_GenerateDataKey.html). KMS 키 구성은 다음과 같아야 합니다:

rbac.serviceAccountName에 정의된 ServiceAccount에 할당된 역할의 IAM 정책은 KMS 키에 대해 다음 작업을 수행할 수 있는 권한을 가지고 있어야 합니다:

• kms:GetPublicKey
• kms:Decrypt
• kms:Encrypt
• kms:DescribeKey
• kms:GenerateDataKey

Kubernetes ServiceAccount 리소스용 IAM 역할 활성화

서비스 계정에 IAM 역할을 사용하려면 클러스터에 IAM OIDC 공급자가 있어야합니다. IAM OIDC 공급자가 클러스터와 연관된 후에 실행자의 서비스 계정에 연결할 IAM 역할을 생성할 수 있습니다.

1. 역할 생성 창에서 신뢰할 수있는 엔터티 유형 선택 아래에서 웹 ID를 선택합니다.
2. 역할의 신뢰할 수 있는 관계 탭에서:
   • 신뢰할 수 있는 엔터티 섹션은 다음 형식이어야 합니다: arn:aws:iam::<ACCOUNT_ID>:oidc-provider/oidc.eks.<AWS_REGION>.amazonaws.com/id/<OIDC_ID>입니다. OIDC ID는 EKS 클러스터의 구성 탭에서 찾을 수 있습니다.
   • 조건 섹션은 rbac.serviceAccountName에 정의된 GitLab 실행자 서비스 계정 또는 rbac.create가 true로 설정된 경우 생성된 기본 서비스 계정이 있어야 합니다:

[runners.cache.gcs] 섹션

아래 매개변수는 Google Cloud Storage의 네이티브 지원을 정의합니다. 이러한 값을에 대한 자세한 정보는 Google Cloud Storage (GCS) 인증 설명서를 참조하십시오.

예시:

config.toml 파일에서 직접 구성된 자격 증명:

[runners.cache]
  Type = "gcs"
  Path = "경로/접두어"
  Shared = false
  [runners.cache.gcs]
    AccessID = "cache-access-account@test-project-123456.iam.gserviceaccount.com"
    PrivateKey = "-----BEGIN PRIVATE KEY-----\nXXXXXX\n-----END PRIVATE KEY-----\n"
    BucketName = "runners-cache"

GCP에서 다운로드한 JSON 파일의 자격 증명:

[runners.cache]
  Type = "gcs"
  Path = "경로/접두어"
  Shared = false
  [runners.cache.gcs]
    CredentialsFile = "/etc/gitlab-runner/service-account.json"
    BucketName = "runners-cache"

GCP의 메타데이터 서버에서의 애플리케이션 기본 자격 증명 (ADC):

Google Cloud ADC를 사용할 때 보통 기본 서비스 계정을 사용합니다. 그런 다음 인스턴스의 자격 증명을 제공할 필요가 없습니다:

[runners.cache]
  Type = "gcs"
  Path = "경로/접두어"
  Shared = false
  [runners.cache.gcs]
    BucketName = "runners-cache"

ADC를 사용하는 경우 사용하는 서비스 계정에 iam.serviceAccounts.signBlob 권한이 있는지 확인하십시오. 일반적으로 이 작업은 서비스 계정에 서비스 계정 토큰 생성 권한을 부여하여 수행됩니다.

[runners.cache.azure] 섹션

• GitLab Runner 13.4.0에서 도입되었습니다.

아래 매개변수는 Azure Blob Storage의 네이티브 지원을 정의합니다. 자세한 정보는 Azure Blob Storage 설명서를 참조하십시오. S3 및 GCS는 객체 컬렉션을 위해 버킷이라는 용어를 사용하는 반면, Azure는 컨테이너라는 용어를 사용하여 블롭 컬렉션을 나타냅니다.

예시:

[runners.cache]
  Type = "azure"
  Path = "경로/접두어"
  Shared = false
  [runners.cache.azure]
    AccountName = "<AZURE STORAGE ACCOUNT NAME>"
    AccountKey = "<AZURE STORAGE ACCOUNT KEY>"
    ContainerName = "runners-cache"
    StorageDomain = "blob.core.windows.net"

[runners.kubernetes] 섹션

• GitLab Runner v1.6.0에서 도임되었습니다.

다음 매개변수는 Kubernetes 동작을 정의합니다. 추가 매개변수에 대한 자세한 내용은 Kubernetes executor 설명서를 참조하십시오.

예시:

[runners.kubernetes]
  host = "https://45.67.34.123:4892"
  cert_file = "/etc/ssl/kubernetes/api.crt"
  key_file = "/etc/ssl/kubernetes/api.key"
  ca_file = "/etc/ssl/kubernetes/ca.crt"
  image = "golang:1.8"
  privileged = true
  allow_privilege_escalation = true
  image_pull_secrets = ["docker-registry-credentials", "optional-additional-credentials"]
  allowed_images = ["ruby:*", "python:*", "php:*"]
  allowed_services = ["postgres:9.4", "postgres:latest"]
  [runners.kubernetes.node_selector]
    gitlab = "true"

지원 이미지

docker, docker+machine, 또는 kubernetes 실행기를 사용할 때 GitLab Runner는 특정 컨테이너를 사용하여 Git, artifact 및 캐시 작업을 처리합니다. 이 컨테이너는 helper image라는 이름의 이미지에서 생성됩니다.

지원되는 아키텍처로는 amd64, arm, arm64, s390x, 및 ppc64le이 있습니다. 이 이미지에는 GitLab Runner 이진 파일의 특수 컴파일인 gitlab-runner-helper가 포함되어 있습니다. 해당 이미지에는 이용 가능한 명령어 중 일부만이 포함되어 있으며, Git, Git LFS 및 SSL 인증서 리포지터리가 있습니다.

helper image에는 몇 가지 변형이 있습니다: alpine, alpine3.16, alpine3.17, alpine3.18, alpine3.19, alpine-latest, ubi-fips, ubuntu. alpine 이미지가 현재 기본값이지만 일부 환경에서 DNS 문제가 발생할 수 있습니다. helper_image_flavor = "ubuntu"를 사용하면 ubuntu 변형의 helper image를 선택합니다.

GitLab Runner 16.1부터 alpine 변형은 alpine3.18의 별칭입니다.

alpine-latest 변형은 기본 이미지로 alpine:latest를 기본 이미지로 사용하며, 이는 더 불안정할 수 있다는 것을 의미할 수 있습니다.

DEB/RPM 패키지에서 GitLab Runner를 설치하는 경우, 지원되는 아키텍처용 이미지가 호스트에 설치됩니다. 실행기가 작업을 실행준비할 때 지정한 버전의 이미지(실행기의 Git 리비전에 기반함)가 Docker Engine에 없는 경우 자동으로 로드됩니다. docker 및 docker+machine 실행기는 이런 방식으로 작동합니다.

alpine 변형의 경우, 패키지에는 기본 alpine 변형 이미지만 포함되어 있습니다. 다른 변형은 레지스트리에서 다운로드해야 합니다.

kubernetes 실행기 및 GitLab Runner의 매뉴얼 설치의 경우 다르게 작동합니다.

• 매뉴얼 설치의 경우, gitlab-runner-helper 이진 파일이 포함되지 않습니다.
• kubernetes 실행기의 경우 Kubernetes API에서 gitlab-runner-helper 이미지를 로컬 아카이브에서 로드할 수 없습니다.

두 경우 모두 GitLab Runner는 helper image를 다운로드합니다. GitLab Runner의 리비전과 아키텍처가 다운로드할 태그를 정의합니다.

Arm용 Kubernetes를 위한 Helper 이미지 구성

arm64 Kubernetes 클러스터에서 arm64 helper 이미지를 사용하려면 구성 파일에서 다음 값을 설정하세요.

[runners.kubernetes]
        helper_image = "gitlab/gitlab-runner-helper:arm64-latest"

이전 버전의 Alpine Linux를 사용하는 Runner 이미지

• GitLab Runner 14.5에서 도입.

여러 버전의 Alpine Linux로 빌드된 이미지를 사용하여 최신 버전의 Alpine을 사용하거나 동시에 이전 버전을 사용할 수 있습니다.

helper 이미지의 경우, helper_image_flavor를 변경하거나 Helper 이미지 섹션을 참조하세요.

GitLab Runner 이미지의 경우, 동일한 로직을 따르며, 이미지 버전 이전에 alpine, alpine3.16, alpine3.17, alpine3.18, alpine3.19 또는 alpine-latest가 이미지의 접두사로 사용됩니다:

docker pull gitlab/gitlab-runner:alpine3.18-v16.1.0

Alpine pwsh 이미지

GitLab Runner 16.1부터 alpine helper 이미지는 모두 pwsh 변형이 있습니다. alpine-latest를 제외한 경우입니다. 이는 pwsh Docker 이미지가 지원하지 않기 때문입니다.

예시:

docker pull gitlab/gitlab-runner-helper:alpine3.18-x86_64-v16.1.0-pwsh

Helper 이미지 레지스트리

GitLab 15.0 이상에서 helper 이미지는 GitLab Container Registry에서 가져옵니다.

GitLab 15.0 이하에서는 helper 이미지 사용을 Docker Hub 이미지로 구성합니다. GitLab 레지스트리에서 기본 gitlab-runner-helper 이미지를 검색하려면 helper-image 값으로 registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper:x86_64-v${CI_RUNNER_VERSION}를 사용하세요.

Self-Managed 인스턴스는 GitLab.com의 GitLab Container Registry에서도 helper 이미지를 가져옵니다. GitLab Container Registry의 상태를 확인하려면 GitLab 시스템 상태를 참조하세요.

Helper 이미지 재정의

경우에 따라 helper 이미지를 재정의할 필요가 있을 수 있습니다:

1. 작업 실행 속도를 높이기 위함: 더 느린 인터넷 연결 환경에서는 동일한 이미지를 여러 번 다운로드하는 것이 작업 실행에 걸리는 시간을 늘릴 수 있습니다. gitlab/gitlab-runner-helper:XYZ의 정확한 사본이 저장된 로컬 레지스트리에서 helper 이미지를 다운로드하면 성능을 향상시킬 수 있습니다.

2. 보안 문제: 사전 확인되지 않은 외부 의존성을 다운로드하고 싶지 않을 수 있습니다. 검토되고 로컬 리포지터리에 저장된 의존성만 사용하도록 하는 비즈니스 규칙이 있을 수 있습니다.

3. 인터넷 액세스 없는 빌드 환경: 일부 경우에는 전용 폐쇄 네트워크 환경에서 작업을 실행합니다. 이는 Kubernetes 클러스터에 사용 가능한 외부 레지스트리에서 이미지를 여전히 다운로드해야 하는 kubernetes 실행기에는 해당하지 않습니다.

4. 추가 소프트웨어: git+http 대신 git+ssh로 액세스 가능한 서브모듈을 지원하기 위해 openssh와 같은 추가 소프트웨어를 helper 이미지에 설치하고자 할 수 있습니다.

이러한 경우에는 docker, docker+machine, 및 kubernetes 실행기에 사용할 수 있는 helper_image 구성 필드를 사용하여 사용자 정의 이미지를 구성할 수 있습니다:

[[runners]]
  (...)
  executor = "docker"
  [runners.docker]
    (...)
    helper_image = "my.registry.local/gitlab/gitlab-runner-helper:tag"

helper 이미지의 버전은 GitLab Runner의 버전과 엄격하게 결합되어야 합니다. 이러한 이미지를 제공하는 주요 이유 중 하나는 GitLab Runner가 gitlab-runner-helper 이진 파일을 사용하기 때문입니다. 이 이진 파일은 GitLab Runner 소스의 일부에서 컴파일됩니다. 이 이진 파일은 두 이진 파일 모두에서 동일한 것으로 예상되는 내부 API를 사용합니다.

기본적으로 GitLab Runner는 GitLab Runner 아키텍처와 Git 리비전을 기반으로 하는 gitlab/gitlab-runner-helper:XYZ 이미지를 참조하며, GitLab Runner 11.3부터는 이러한 버전 변수 중 하나를 사용하여 이미지 버전을 정의할 수 있습니다:

[[runners]]
  (...)
  executor = "docker"
  [runners.docker]
    (...)
    helper_image = "my.registry.local/gitlab/gitlab-runner-helper:x86_64-v${CI_RUNNER_VERSION}"

이 구성으로 GitLab Runner는 실행기에게 컴파일 데이터를 기반으로 한 버전 x86_64-v${CI_RUNNER_VERSION}의 이미지를 사용하도록 지시합니다. GitLab Runner를 새 버전으로 업데이트한 후에는 작업을 시작하기 전에 이미지를 레지스트리에 업로드해야 합니다. 그렇지 않으면 작업은 “No such image” 오류로 실패합니다.

GitLab Runner 13.2부터 helper 이미지는 $CI_RUNNER_REVISION에 추가로 $CI_RUNNER_VERSION을 태그합니다. 두 태그 모두 유효하며 동일한 이미지를 가리킵니다.

[[runners]]
  (...)
  executor = "docker"
  [runners.docker]
    (...)
    helper_image = "my.registry.local/gitlab/gitlab-runner-helper:x86_64-v${CI_RUNNER_VERSION}"

PowerShell Core 사용 시

gitlab/gitlab-runner-helper:XYZ-pwsh 태그를 가진 Linux용 도우미 이미지의 추가 버전이 퍼블리시됩니다.

[runners.custom_build_dir] 섹션

• GitLab Runner 11.10에서 소개되었습니다.

이 섹션은 사용자 정의 빌드 디렉터리 매개변수를 정의합니다.

이 기능은 명시적으로 구성되지 않는 경우, kubernetes, docker, docker+machine executors에 대해 기본적으로 활성화됩니다. 다른 executors에 대해서는 기본적으로 비활성화됩니다.

이 기능을 사용하려면 GIT_CLONE_PATH가 runners.builds_dir에서 정의된 경로에 있어야 합니다. builds_dir을 사용하려면 $CI_BUILDS_DIR 변수를 사용하세요.

기본적으로, 이 기능은 docker 및 kubernetes executors에 대해서만 활성화되어 있으며, 리소스를 분리하는 좋은 방법을 제공하기 때문입니다. 하지만 이 기능은 명시적으로 어떤 executor에 대해서도 활성화될 수 있으나, builds_dir를 공유하고 concurrent > 1을 사용하는 executor와 함께 사용할 때 주의해야 합니다.

예시:

[runners.custom_build_dir]
  enabled = true

기본 빌드 디렉터리

GitLab Runner는 _빌드 디렉터리_라고 알려진 베이스 경로 아래에 있는 경로로 리포지터리를 복제합니다. 이 기본 디렉터리의 기본 위치는 executor에 따라 다릅니다. 예를 들어:

• Kubernetes, Docker 및 Docker Machine executors의 경우, 컨테이너 내부의 /builds입니다.
• Shell executor의 경우, $PWD/builds입니다.
• SSH, VirtualBox 및 Parallels executors의 경우, 대상 머신에 대한 SSH 연결을 처리하는 사용자의 홈 디렉터리에 있는 ~/builds입니다.
• Custom executors의 경우, 기본값이 제공되지 않으며 명시적으로 구성되어야 합니다. 그렇지 않은 경우 작업이 실패합니다.

사용된 _빌드 디렉터리_는 사용자에 의해 명시적으로 builds_dir 설정으로 정의될 수 있습니다.

GitLab Runner는 실행하는 모든 작업에 대해 _빌드 디렉터리_를 사용하지만, 특정 패턴을 사용하여 해당 디렉터리에 중첩시킵니다. 예시: /builds/2mn-ncv-/0/user/playground.

GitLab Runner는 빌드 디렉터리 내에 저장하는 것을 멈추지 않습니다. 예를 들어 /builds/tools에 도구를 저장할 수 있지만 이는 강력히 권장하지 않습니다. _빌드 디렉터리_에 아무 것도 저장하지 않아야 합니다. GitLab Runner가 완전한 제어를 가져야 하며 이러한 경우에 안정성을 보장하지 않습니다. CI에 필요한 의존성이 있는 경우, 다른 곳에 설치하기를 권장합니다.

[runners.referees] 섹션

추가 작업 모니터링 데이터를 GitLab에 전달하기 위해 GitLab Runner referees를 사용하세요. Referees는 작업과 관련된 추가 데이터를 쿼리하고 수집하는 runner 관리자의 워커들입니다. 결과는 작업 artifact로 GitLab에 업로드됩니다.

Metrics Runner referee 사용

작업을 실행하는 머신이나 컨테이너가 Prometheus 메트릭을 노출하는 경우, GitLab Runner는 작업의 전체 기간 동안 Prometheus 서버에 쿼리할 수 있습니다. 메트릭을 받으면 나중에 분석에 사용할 수 있는 작업 artifact로 업로드됩니다.

docker-machine executor만 referee를 지원합니다.

GitLab Runner용 Metrics Runner Referee 구성

config.toml 파일의 [[runner]] 섹션 내에서 [runner.referees] 및 [runner.referees.metrics]를 정의하고 다음 필드를 추가하세요.

다음은 node_exporter 메트릭에 대한 완전한 구성 예시입니다:

[[runners]]
  [runners.referees]
    [runners.referees.metrics]
      prometheus_address = "http://localhost:9090"
      query_interval = 10
      metric_queries = [
        "arp_entries:rate(node_arp_entries{{selector}}[{interval}])",
        "context_switches:rate(node_context_switches_total{{selector}}[{interval}])",
        "cpu_seconds:rate(node_cpu_seconds_total{{selector}}[{interval}])",
        "disk_read_bytes:rate(node_disk_read_bytes_total{{selector}}[{interval}])",
        "disk_written_bytes:rate(node_disk_written_bytes_total{{selector}}[{interval}])",
        "memory_bytes:rate(node_memory_MemTotal_bytes{{selector}}[{interval}])",
        "memory_swap_bytes:rate(node_memory_SwapTotal_bytes{{selector}}[{interval}])",
        "network_tcp_active_opens:rate(node_netstat_Tcp_ActiveOpens{{selector}}[{interval}])",
        "network_tcp_passive_opens:rate(node_netstat_Tcp_PassiveOpens{{selector}}[{interval}])",
        "network_receive_bytes:rate(node_network_receive_bytes_total{{selector}}[{interval}])",
        "network_receive_drops:rate(node_network_receive_drop_total{{selector}}[{interval}])",
        "network_receive_errors:rate(node_network_receive_errs_total{{selector}}[{interval}])",
        "network_receive_packets:rate(node_network_receive_packets_total{{selector}}[{interval}])",
        "network_transmit_bytes:rate(node_network_transmit_bytes_total{{selector}}[{interval}])",
        "network_transmit_drops:rate(node_network_transmit_drop_total{{selector}}[{interval}])",
        "network_transmit_errors:rate(node_network_transmit_errs_total{{selector}}[{interval}])",
        "network_transmit_packets:rate(node_network_transmit_packets_total{{selector}}[{interval}])"
      ]

메트릭 쿼리는 canonical_name:query_string 형식입니다. 쿼리 문자열은 실행 중에 대체되는 두 개의 변수를 지원합니다:

예를 들어, docker-machine executor를 사용하는 공유 GitLab Runner 환경은 {selector}가 node=shared-runner-123와 유사합니다.