• 구성 유효성 검사
• 전역 섹션
  • log_format 예시(일부)
    • runner
    • text
    • json
  • check_interval 작동 방식
• [session_server] 섹션
• [[runners]] 섹션
  • clone_url 작동 방법
  • unhealthy_requests_limit 및 unhealthy_interval 작동 방법
• 실행자(executors)
• 셸(shell)
  • 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.connector_config] 섹션
• [[runners.autoscaler.policy]] 섹션
  • 기간 구문
• [runners.custom] 섹션
• [runners.cache] 섹션
  • [runners.cache.s3] 섹션
    • S3 버킷에 러너 캐시를 위한 KMS 키 암호화 사용
    • Kubernetes ServiceAccount 리소스에 대한 IAM 역할 활성화
  • [runners.cache.gcs] 섹션
  • [runners.cache.azure] 섹션
• [runners.kubernetes] 섹션
• 도우미 이미지
  • Kubernetes에서 Arm용 Helper 이미지 구성
  • 이전 버전의 Alpine Linux를 사용하는 Runner 이미지
  • Alpine pwsh 이미지
  • Helper 이미지 레지스트리
  • 헬퍼 이미지 재정의
    • PowerShell Core를 사용하는 경우
• [runners.custom_build_dir] 섹션
  • 기본 빌드 디렉터리
• [runners.referees] 섹션
  • Metrics Runner 리퍼리 사용
  • GitLab Runner용 Metrics Runner Referee 구성

고급 구성

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

config.toml 파일은 다음에서 찾을 수 있습니다.

• 루트로 실행되는 *nix 시스템에서 /etc/gitlab-runner/에 GitLab Runner를 실행할 때 이 디렉토리는 서비스 구성을 위한 경로입니다.
• 루트로 실행되지 않는 *nix 시스템에서 ~/.gitlab-runner/에 GitLab Runner를 실행할 때
• 다른 시스템에서는 ./ 입니다.

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

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

GitLab Runner는 구성 수정을 3초마다 확인하고 필요한 경우 다시로드합니다. GitLab Runner는 또한 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 값 가져오기 (10초).
2. 러너 목록 가져오기 (runner-1, runner-2).
3. 대기 간격 계산하기 (10초 / 2 = 5초).
4. 무한 루프 시작:
   1. runner-1의 작업 요청.
   2. 5초 동안 대기.
   3. runner-2의 작업 요청.
   4. 5초 동안 대기.
   5. 반복.

이 예에서 러너 프로세스에서의 작업 요청은 매 5초마다 이루어집니다. 만약 runner-1 및 runner-2가 동일한 GitLab 인스턴스에 연결된 경우, 해당 인스턴스도 이 러너의 새로운 요청을 매 5초마다 받습니다.

첫 번째와 두 번째 runner-1에 대한 요청 간에 두 가지 대기 기간이 발생합니다. 각 기간은 5초이므로, runner-1에 대한 연속적인 요청 사이에는 약 10초가 소요됩니다. runner-2에 대해서도 동일한 원리가 적용됩니다.

런너를 더 정의하면, 대기 간격은 더 짧아집니다. 그러나 러너에 대한 요청은 다른 러너의 모든 요청과 대기 기간이 끝난 후에 반복됩니다.

[session_server] 섹션

[session_server] 섹션을 사용하면 사용자가 대화형 웹 터미널과 같은 작업과 상호작용할 수 있습니다.

[session_server] 섹션은 러너당이 아니라 루트 레벨에서 지정해야 합니다.

[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] 섹션을 삭제하세요.

참고: 런너 인스턴스가 이미 실행 중인 경우 [session_server] 섹션의 변경 사항이 적용되려면 gitlab-runner restart를 실행해야 할 수 있습니다.

GitLab Runner 도커 이미지를 사용하는 경우, 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 작동 방법

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

예를 들어, 방화벽이 runner가 URL에 도달하는 것을 막을 수 있습니다. runner가 192.168.1.23 노드에 도달할 수 있는 경우, clone_url을 http://192.168.1.23으로 설정하세요.

만약 clone_url이 설정되어 있다면, runner는 http://gitlab-ci-token:s3cr3tt0k3n@192.168.1.23/namespace/project.git 형식의 클론 URL을 생성합니다.

unhealthy_requests_limit 및 unhealthy_interval 작동 방법

GitLab 인스턴스가 장시간(예: 버전 업그레이드 중) 사용 불가 상태인 경우, 해당 인스턴스에 구성된 runner는 무효화 되어 GitLab 인스턴스가 다시 사용 가능해지고나서 30-60분 후에 작업 처리를 재개하지 않습니다.

runner가 무효화되는 시간을 증가 또는 감소시키려면 unhealthy_interval 설정을 변경하세요.

GitLab 서버에 연결을 시도하는 runner의 횟수를 변경하고 runner가 무효화되기 전에 비정상적인 대기 시간을 설정하려면 unhealthy_requests_limit 설정을 변경하세요. 자세한 내용은 How check_interval works를 참조하세요.

실행자(executors)

다음 실행자(executors)를 사용할 수 있습니다.

셸(shell)

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

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

POSIX 호환 셸 사용

GitLab Runner 14.9 이상에서는 기능 플래그를 활성화하여 FF_POSIXLY_CORRECT_ESCAPES라는 이름의 기능 플래그를 활성화하여 POSIX 호환 셸(예: dash)을 사용할 수 있습니다. 활성화된 경우, “Double Quotes”을 사용하여 POSIX 호환 셸 이스케이핑 메커니즘이 사용됩니다.

[runners.docker] 섹션

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

Docker-in-Docker를 서비스로 사용하거나 작업 내에서 구성된 컨테이너 실행환경은 이러한 매개변수를 상속받지 않습니다.

[[runners.docker.services]] 섹션

작업과 함께 실행할 추가 서비스를 지정합니다. 사용 가능한 이미지 목록은 도커 레지스트리를 확인하세요. 각 서비스는 별도의 컨테이너에서 실행되며 작업과 연결됩니다.

예시:

[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"
  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] 섹션의 볼륨

볼륨에 대한 자세한 정보는 도커 문서를 참조하세요.

다음 예제는 [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: 호스트 디렉토리를 데이터 볼륨으로 마운트

컨테이너 외부에 디렉토리를 저장하려면 도커 데몬 호스트의 디렉토리를 컨테이너로 마운트할 수 있습니다.

[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"]

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

GitLab Runner 11.11 및 이후의 버전에서는 서비스의 정의된 서비스에 대해 호스트 디렉토리를 마운트합니다.

사설 컨테이너 레지스트리 사용

작업의 이미지 원본으로 사설 레지스트리를 사용하려면 CI/CD 변수 DOCKER_AUTH_CONFIG를 구성하여 권한을 부여하십시오. 다음 중 하나의 방법으로 이 변수를 설정할 수 있습니다:

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

if-not-present 풀 정책과 함께 사설 레지스트리를 사용하는 것은 보안 문제를 유발할 수 있습니다. 풀 정책 작동 방법에 대한 자세한 내용은 런너가 이미지를 가져오는 방식 구성을 참조하십시오.

사설 컨테이너 레지스트리 사용에 대한 자세한 내용은 다음을 참조하십시오:

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

런너에 의해 수행되는 단계는 다음과 같습니다:

1. 이미지 이름에서 레지스트리 이름을 찾습니다.
2. 값이 비어 있지 않으면, 실행기는 해당 레지스트리의 인증 구성을 찾습니다.
3. 마지막으로 지정된 레지스트리에 해당하는 인증이 발견되면, 후속 풀 작업에 사용됩니다.

GitLab 통합 레지스트리 지원

GitLab은 작업 데이터와 함께 자체 통합 레지스트리에 대한 자격 증명을 보냅니다. 이러한 자격 증명은 레지스트리의 권한 부여 매개변수 목록에 자동으로 추가됩니다.

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

작업에서 GitLab 통합 레지스트리의 이미지를 비공개 또는 보호된 이미지라도 사용할 수 있습니다. 작업이 액세스할 수 있는 이미지에 대한 정보는 CI/CD 작업 토큰 문서를 참조하십시오.

Docker 인증 해결 우선 순위

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

1. DOCKER_AUTH_CONFIG로 구성된 자격 증명.
2. ~/.docker/config.json 또는 ~/.dockercfg 파일과 함께 지역적으로 구성된 러너 호스트의 자격 증명(예: 호스트에서 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 이미지 매개변수를 사용하여 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 드라이버를 사용하여 추가적인 머신 옵션을 추가할 수 있습니다.
      # 호스트에 연결할 수 없는 문제가 발생하면(ex. "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 # 현재 대기 중인 머신 수가 1.5*사용 중인 머신 수를 의미하며,
                          # IdleCount 값(50)을 넘지 않고 IdleCountMin 값(5)보다 작아지지 않음
    IdleTime = 3600
    Timezone = "UTC"
  [[runners.machine.autoscaling]]
    Periods = ["* * * * * sat,sun *"]
    IdleCount = 5
    IdleTime = 60
    Timezone = "UTC"

Periods 구문법

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

[초] [분] [시] [월의 날짜] [월] [주의 날] [년]

표준 cron 구성 파일과 마찬가지로 이 필드에는 단일 값, 범위, 목록, 별표가 포함될 수 있습니다. 구문에 대한 상세한 설명은 구문 설명를 참조하십시오.

[runners.instance] 섹션

세부 정보: 상태: 베타

다음 매개변수는 instance executor의 구성을 정의합니다. 인스턴스 executor는 베타 상태입니다.

[runners.autoscaler] 섹션

• GitLab Runner v15.10.0에서 소개됨.

다음 매개변수는 autoscaler 기능을 구성합니다. 이러한 매개변수는 Instance와 Docker Autoscaler executor와 함께만 사용할 수 있습니다. 이러한 executor는 베타 상태입니다.

[runners.autoscaler.plugin_config] 섹션

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

fleeting 플러그인에는 일반적으로 지원되는 구성에 대한 수반 문서가 있습니다.

[runners.autoscaler.connector_config] 섹션

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

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

[[runners.autoscaler.policy]] 섹션

참고 - 이 문맥에서 idle_count는 레거시 오토 스케일링 방법과는 다르게 작업의 수를 의미합니다.

scale_factor을 설정하면 idle_count는 최소 idle 용량이 되고 scaler_factor_limit은 최대 idle 용량이 됩니다.

기간 구문

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.

이 크론 작업이 시간 범위를 나타낸다는 점을 명심하는 것이 중요합니다. 예를 들어:

[runners.custom] 섹션

다음 매개변수는 사용자 정의 실행자의 구성을 정의합니다.

[runners.cache] 섹션

다음 매개변수는 분산 캐시 기능을 정의합니다. 자세한 내용은 런너 자동 확장 문서를 참조하십시오.

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

S3 캐시 어댑터가 IAM 인스턴스 프로파일을 사용하도록 구성된 경우, 어댑터는 GitLab Runner 기계에 첨부된 프로필을 사용합니다. 비슷한 방식으로 GCS 캐시 어댑터는 CredentialsFile을 사용하도록 구성된 경우 GitLab Runner 기계에 파일이 있어야 합니다.

이 표는 config.toml, CLI 옵션 및 register를 위한 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에서 실행 중인 Runner의 경우, 서비스 계정에 할당할 IAM 역할을 지정할 수 있습니다. 필요한 주석은 다음과 같습니다: eks.amazonaws.com/role-arn: arn:aws:iam::<ACCOUNT_ID>:role/<IAM_ROLE_NAME>.

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

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

ServerSideEncryption의 유형이 KMS인 경우, 이 역할은 지정된 AWS KMS 키에 대해 다음 작업을 수행할 수 있는 권한을 가져야합니다.

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

SSE-C 유형의 ServerSideEncryption은 지원되지 않습니다. SSE-C는 사용자가 제공한 키를 포함하는 헤더가 사전 서명된 URL과 함께 다운로드 요청에 제공되어야 합니다. 작업에 키 자료를 전달해야하며 이로써 키를 안전하게 보관할 수 없게됩니다. 이로 인해 복호화 키가 노출될 가능성이 있습니다. 이 문제에 대한 논의는 이 병합 요청에서 확인할 수 있습니다.

참고: AWS S3 캐시에 업로드할 수 있는 단일 파일의 최대 크기는 5GB입니다. 이 동작에 대한 잠재적인 해결책에 대한 논의는 이 이슈에서 확인할 수 있습니다.

S3 버킷에 러너 캐시를 위한 KMS 키 암호화 사용

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

rbac.serviceAccountName에 정의된 ServiceAccount에 할당된 역할의 IAM 정책은 다음 작업을 수행할 수 있는 권한이 있어야 합니다:

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

Kubernetes ServiceAccount 리소스에 대한 IAM 역할 활성화

서비스 어카운트에 대한 IAM 역할을 사용하려면 클러스터에 IAM OIDC 프로바이더가 있어야 합니다. IAM OIDC 프로바이더가 클러스터에 연결된 후, 러너의 서비스 어카운트에 연결할 IAM 역할을 생성할 수 있습니다.

1. 역할 생성 창에서 신뢰하는 엔터티 유형 선택을 선택합니다.

2. 역할의 신뢰 관계 탭에서:

   • 신뢰하는 엔터티 섹션은 다음 형식이어야 합니다: arn:aws:iam::<ACCOUNT_ID>:oidc-provider/oidc.eks.<AWS_REGION>.amazonaws.com/id/<OIDC_ID>. OIDC ID는 EKS 클러스터의 구성 탭에서 찾을 수 있습니다.

   • 조건 섹션은 rbac.create가 true로 설정된 경우 rbac.serviceAccountName으로 정의된 GitLab Runner 서비스 어카운트를 가져야 합니다:

     조건	키	값
     StringEquals	oidc.eks.<AWS_REGION>.amazonaws.com/id/<OIDC_ID>:sub	system:serviceaccount:<GITLAB_RUNNER_NAMESPACE>:<GITLAB_RUNNER_SERVICE_ACCOUNT>

[runners.cache.gcs] 섹션

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

예시:

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

[runners.cache]
  Type = "gcs"
  Path = "path/to/prefix"
  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 = "path/to/prefix"
  Shared = false
  [runners.cache.gcs]
    CredentialsFile = "/etc/gitlab-runner/service-account.json"
    BucketName = "runners-cache"

GCP 메타데이터 서버의 메타데이터 기본 자격 증명 (ADC):

Google Cloud ADC를 사용하여 GitLab 러너를 사용하는 경우 일반적으로 기본 서비스 어카운트를 사용합니다. 그럼 인스턴스에 자격 증명을 제공할 필요가 없습니다.

[runners.cache]
  Type = "gcs"
  Path = "path/to/prefix"
  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 = "path/to/prefix"
  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 executor를 사용할 때, GitLab Runner는 Git, 아티팩트 및 캐시 작업을 처리하기 위해 특정 컨테이너를 사용합니다. 이 컨테이너는 도우미 이미지라는 이미지에서 생성됩니다.

도우미 이미지는 amd64, arm, arm64, s390x 및 ppc64le 아키텍처용으로 제공됩니다. 여기에는 특별한 컴파일링된 gitlab-runner-helper 바이너리가 포함되어 있으며 사용 가능한 명령어의 하위 집합, 그리고 Git, Git LFS 및 SSL 인증서 저장소가 포함되어 있습니다.

도우미 이미지에는 몇 가지 플레이버가 있습니다: alpine, alpine3.16, alpine3.17, alpine3.18, alpine3.19, alpine-latest, ubi-fips 및 ubuntu. 현재 작은 크기 때문에 alpine 이미지가 기본값입니다만 일부 환경에서의 DNS 문제가 발생할 수 있습니다. helper_image_flavor = "ubuntu"를 사용하면 ubuntu 플레이버의 도우미 이미지가 선택됩니다.

GitLab Runner 16.1 이후로 alpine 플레이버는 alpine3.18에 대한 별칭입니다.

alpine-latest 플레이버는 alpine:latest를 기본 이미지로 사용하며, 더 불안정할 수 있습니다.

GitLab Runner가 DEB/RPM 패키지에서 설치된 경우, 지원되는 아키텍처용 이미지가 호스트에 설치됩니다. 작업을 실행하기 위해 러너가 지정된 버전의 이미지를 Docker Engine에서 찾지 못한 경우, 자동으로 로드됩니다. docker 및 docker+machine executor는 이런 방식으로 작동합니다.

alpine 플레이버의 경우 기본 alpine 플레이버 이미지만 패키지에 포함되어 있습니다. 다른 모든 플레이버는 레지스트리에서 다운로드됩니다.

kubernetes executor 및 수동으로 GitLab Runner를 설치하는 경우 다르게 동작합니다.

• 수동으로 설치할 경우, gitlab-runner-helper 바이너리가 포함되어 있지 않습니다.
• kubernetes executor의 경우, Kubernetes API는 로컬 아카이브에서 gitlab-runner-helper 이미지를 로드할 수 없습니다.

이 두 경우에 GitLab Runner는 도우미 이미지를 다운로드합니다. GitLab Runner의 리비전 및 아키텍처가 다운로드할 태그를 정의합니다.

Kubernetes에서 Arm용 Helper 이미지 구성

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

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

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

• GitLab Runner 14.5에서 도입됨.

이미지는 여러 버전의 Alpine Linux로 빌드되므로 더 새로운 Alpine 버전을 사용할 수 있을 뿐만 아니라 이전 버전도 사용할 수 있습니다.

헬퍼 이미지의 경우 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 헬퍼 이미지에는 pwsh 변형이 있습니다. alpine-latest를 제외한 모든 경우, pwsh Docker 이미지는 alpine:latest를 지원하지 않기 때문에 해당 변형이 없습니다.

예:

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

Helper 이미지 레지스트리

GitLab 15.0 이상에서는 헬퍼 이미지가 GitLab 컨테이너 레지스트리에서 가져옵니다.

GitLab 15.0 이하에서는 헬퍼 이미지를 Docker Hub에서 가져오도록 구성합니다. GitLab 레지스트리에서 기본 gitlab-runner-helper 이미지를 검색하려면 helper-image 값을 사용하십시오: registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper:x86_64-v${CI_RUNNER_VERSION}.

GitLab.com에서도 온프레미스 인스턴스에서도 헬퍼 이미지를 GitLab 컨테이너 레지스트리에서 가져옵니다. GitLab 컨테이너 레지스트리의 상태를 확인하려면 GitLab 시스템 상태를 참조하십시오.

헬퍼 이미지 재정의

어떤 경우에는 헬퍼 이미지를 재정의해야 할 수 있습니다. 이에 대한 몇 가지 이유는 다음과 같습니다:

1. 작업 실행 속도 향상: 인터넷 속도가 느린 환경에서 동일한 이미지를 여러 번 다운로드하면 작업 실행에 걸리는 시간이 증가할 수 있습니다. gitlab/gitlab-runner-helper:XYZ의 정확한 사본이 저장된 로컬 레지스트리에서 헬퍼 이미지를 다운로드하여 속도를 높일 수 있습니다.

2. 보안 문제: 확인되지 않은 외부 종속성을 다운로드하고 싶지 않을 수 있습니다. 사용되기 전에 검토되고 로컬 저장소에 저장된 종속성만 사용하도록 하는 사업 규칙이 있을 수 있습니다.

3. 인터넷 액세스 없는 빌드 환경: 어떤 경우에는 작업이 전용 및 폐쇄 네트워크 환경에서 실행됩니다. 이는 kubernetes 실행기에는 적용되지 않으며, 이미지는 여전히 쿠버네티스 클러스터에 사용 가능한 외부 레지스트리에서 다운로드해야 합니다.

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

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

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

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

기본적으로 GitLab Runner는 $CI_RUNNER_VERSION을 기반으로 하는 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는 실행기에게 해당 버전의 이미지를 사용하도록 지시합니다. GitLab Runner를 새 버전으로 업데이트한 후에는 해당 이미지를 레지스트리에 업로드해야 합니다. 그렇지 않으면 작업이 “해당 이미지가 없음” 오류로 실패합니다.

GitLab Runner 13.2 이상에서 헬퍼 이미지는 $CI_RUNNER_VERSION 외에도 $CI_RUNNER_REVISION으로 태그되었습니다. 두 태그 모두 유효하며 동일한 이미지를 가리킵니다.

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

PowerShell Core를 사용하는 경우

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

Linux용 헬퍼 이미지의 추가 버전인, PowerShell Core를 포함하는 이미지가 gitlab/gitlab-runner-helper:XYZ-pwsh 태그와 함께 게시됩니다.

[runners.custom_build_dir] 섹션

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

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

이 기능은 명시적으로 구성되지 않으면 기본적으로 kubernetes, docker 및 docker+machine 실행기에 대해 기본적으로 활성화됩니다. 다른 모든 실행기에 대해서는 기본적으로 비활성화됩니다.

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

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

예시:

[runners.custom_build_dir]
  enabled = true

기본 빌드 디렉터리

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

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

사용자는 사용자가 설정한 곳에 따라 사용자 정의로 _빌드 디렉터리_를 정의할 수 있습니다. builds_dir 설정을 통해.

참고: GIT_CLONE_PATH 를 지정하여 사용자 정의 디렉터리에 복제하려는 경우, 아래 지침은 적용되지 않습니다.

GitLab Runner는 실행하는 모든 작업에 대해 _빌드 디렉토리_를 사용하지만, 특정 패턴을 사용하여 중첩합니다. {builds_dir}/$RUNNER_TOKEN_KEY/$CONCURRENT_ID/$NAMESPACE/$PROJECT_NAME. 예: /builds/2mn-ncv-/0/user/playground.

GitLab Runner는 빌드 디렉토리 내부에 저장하는 것을 금지하지 않습니다. 예를 들어, CI 실행 중에 사용할 수 있는 도구를 /builds/tools에 저장할 수 있습니다. 그러나 이것을 강력히 권장하지 않으며, 빌드 디렉토리 내부에 어떤 것이든 저장해서는 안 됩니다. GitLab Runner가 제어권을 가지고 있어야 하며 이러한 경우의 안정성을 보장하지 않습니다. CI에 필요한 종속성이 있을 경우, 다른 곳에 설치하는 것을 권장합니다.

[runners.referees] 섹션

• GitLab Runner 12.7에서 소개되었습니다.
• GitLab v12.6 이상이 필요합니다.

GitLab Runner의 리퍼리를 사용하여 추가 작업 모니터링 데이터를 GitLab에 전달합니다. 리퍼리는 작업과 관련된 추가 데이터를 쿼리하고 수집하는 러너 관리자의 작업자입니다. 결과는 작업 아티팩트로서 GitLab에 업로드됩니다.

Metrics Runner 리퍼리 사용

작업을 실행하는 머신 또는 컨테이너가 Prometheus 메트릭을 노출하는 경우, GitLab Runner는 작업 기간 전체에 대해 Prometheus 서버를 쿼리할 수 있습니다. 메트릭을 수신한 후, 나중에 분석에 사용할 수 있도록 작업 아티팩트로 업로드됩니다.

리퍼리는 docker-machine 실행기만 지원합니다.

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과 유사합니다.