인스턴스 또는 그룹 러너의 플랜 및 운영

이 가이드는 공유 서비스 모델에서 러너 플릿을 확장하는 모범 사례를 포함합니다.

공유 러너의 플릿을 호스팅할 때는 다음 사항을 고려한 잘 계획된 인프라가 필요합니다:

  • 컴퓨팅 용량.
  • 저장 용량.
  • 네트워크 대역폭 및 처리량.
  • 작업의 유형(프로그래밍 언어, OS 플랫폼 및 종속 라이브러리 포함).

이 가이드를 사용하여 조직의 요구 사항에 따른 GitLab Runner 배포 전략을 개발하세요.

이 가이드는 사용해야 할 인프라의 유형에 대한 구체적인 권장 사항을 제시하지 않습니다.

그러나 매달 수백만 개의 CI/CD 작업을 처리하는 GitLab.com에서 러너 플릿을 운영한 경험에 대한 통찰력을 제공합니다.

작업량 및 환경 고려

러너를 배포하기 전에 작업량 및 환경 요구 사항을 고려하세요.

  • GitLab에 온보드할 팀 목록을 작성하세요.
  • 조직에서 사용 중인 프로그래밍 언어, 웹 프레임워크 및 라이브러리를 나열하세요. 예: Go, C++, PHP, Java, Python, JavaScript, React, Node.js.
  • 각 팀이 시간당, 하루에 실행할 수 있는 CI/CD 작업의 수를 추정하세요.
  • 어떤 팀이 컨테이너를 사용하여 해결할 수 없는 빌드 환경 요구 사항이 있는지 확인하세요.
  • 어떤 팀이 그 팀 전용의 러너가 가장 적합한 빌드 환경 요구 사항이 있는지 확인하세요.
  • 예상 수요를 지원하기 위해 필요한 컴퓨팅 용량을 추정하세요.

러너 플릿을 호스팅하기 위해 서로 다른 인프라 스택을 선택할 수 있습니다.

예를 들어, 공용 클라우드에 일부 러너를 배포하고 온프레미스에 다른 러너를 배포할 수 있습니다.

러너 플릿에서 CI/CD 작업의 성능은 플릿의 환경과 직접적으로 관련이 있습니다.

리소스 집약적인 CI/CD 작업을 많이 실행하는 경우 공유 컴퓨팅 플랫폼에 플릿을 호스팅하는 것은 권장되지 않습니다.

워커, 실행기 및 자동 확장 기능

gitlab-runner 실행 파일이 CI/CD 작업을 실행합니다. 각 러너는 작업 실행 요청을 수집하고 미리 정의된 구성에 따라 처리하는 격리된 프로세스입니다.

격리된 프로세스로서 각 러너는 작업을 실행하기 위해 “하위 프로세스”(또는 “워커”)를 생성할 수 있습니다.

동시성 및 제한

  • 동시성: 호스트 시스템의 모든 구성된 러너를 사용할 때 동시에 실행할 수 있는 작업의 수를 설정합니다.

  • 제한: 러너가 동시에 작업을 실행하기 위해 생성할 수 있는 하위 프로세스의 수를 설정합니다.

자동 확장 러너(Docker Machine 및 Kubernetes와 같은)와 자동 확장하지 않는 러너의 제한은 다릅니다.

  • 자동 확장하지 않는 러너에서 limit은 호스트 시스템에서 러너의 용량을 정의합니다.

  • 자동 확장 러너에서 limit은 총 실행하고자 하는 러너의 수입니다.

기본 구성: 하나의 러너, 하나의 워커

가장 기본적인 구성에서는 지원되는 컴퓨팅 아키텍처와 운영 체제에 GitLab Runner 소프트웨어를 설치합니다.

예를 들어, Ubuntu Linux를 실행하는 x86-64 가상 머신(VM)이 있을 수 있습니다.

설치가 완료되면 한 번만 러너 등록 명령을 실행하고 shell 실행기를 선택합니다. 그런 다음 러너 config.toml 파일을 수정하여 동시성을 1로 설정합니다.

concurrent = 1

[[runners]]
  name = "instance-level-runner-001"
  url = ""
  token = ""
  executor = "shell"

이 러너가 처리할 수 있는 GitLab CI/CD 작업은 러너를 설치한 호스트 시스템에서 직접 실행됩니다.

마치 CI/CD 작업 명령을 터미널에서 직접 실행하는 것과 같습니다.

이 경우 등록 명령을 한 번만 실행했으므로 config.toml 파일에는 하나의 [[runners]] 섹션만 포함됩니다.

동시성 값을 1로 설정했다고 가정하면, 한 개의 러너 “워커”만 이 시스템의 러너 프로세스에 대한 CI/CD 작업을 실행할 수 있습니다.

중간 설정: 하나의 러너, 다수의 작업자

같은 머신에 여러 러너 작업자를 등록할 수도 있습니다.

이렇게 할 경우, 러너의 config.toml 파일에는 여러 [[runners]] 섹션이 있습니다.

추가된 모든 러너 작업자가 셸 실행자를 사용하도록 등록되고, 전역 구성 옵션인 concurrent 값을 3으로 업데이트하면, 이 호스트에서 동시에 실행할 수 있는 작업의 상한선은 세 개입니다.

concurrent = 3

[[runners]]
  name = "instance_level_shell_001"
  url = ""
  token = ""
  executor = "shell"

[[runners]]
  name = "instance_level_shell_002"
  url = ""
  token = ""
  executor = "shell"

[[runners]]
  name = "instance_level_shell_003"
  url = ""
  token = ""
  executor = "shell"

같은 머신에 여러 러너 작업자를 등록할 수 있으며, 각 작업자는 독립적인 프로세스입니다.

각 작업자의 CI/CD 작업 성능은 호스트 시스템의 컴퓨팅 용량에 따라 다릅니다.

자동 확장 구성: 하나 이상의 러너 관리자, 다수의 작업자

GitLab Runner가 자동 확장을 위해 설정되면, 다른 러너의 관리자로 작동하도록 러너를 구성할 수 있습니다.

이는 docker-machine 또는 kubernetes 실행자를 사용하여 수행할 수 있습니다. 이러한 관리자 전용 구성에서는 러너 에이전트가 CI/CD 작업을 실행하지 않습니다.

Docker Machine 실행자

도커 머신 실행자와 함께:

  • 러너 관리자는 요청에 따라 Docker로 가상 머신 인스턴스를 프로비저닝합니다.

  • 이러한 VM에서 GitLab Runner는 .gitlab-ci.yml 파일에 지정한 컨테이너 이미지를 사용하여 CI/CD 작업을 실행합니다.

  • 다양한 머신 유형에서 CI/CD 작업의 성능을 테스트해야 합니다.

  • 속도나 비용에 따라 컴퓨팅 호스트를 최적화하는 것을 고려해야 합니다.

Kubernetes 실행자

Kubernetes 실행자와 함께:

  • 러너 관리자는 대상 Kubernetes 클러스터에서 포드를 프로비저닝합니다.

  • CI/CD 작업은 여러 컨테이너로 구성된 각 포드에서 실행됩니다.

  • 작업 실행에 사용되는 포드는 일반적으로 러너 관리자를 호스팅하는 포드보다 더 많은 컴퓨팅 및 메모리 리소스를 필요로 합니다.

러너 구성 재사용

같은 러너 인증 토큰과 연결된 각 러너 관리자는 system_id 식별자를 할당받습니다.

system_id는 러너가 사용되는 머신을 식별합니다. 같은 인증 토큰으로 등록된 러너는 고유한 system_id에 따라 단일 러너 항목으로 그룹화됩니다.

비슷한 러너를 단일 구성으로 그룹화하면 러너 함대 운영이 간소화됩니다.

다음은 비슷한 러너를 단일 구성으로 그룹화할 수 있는 시나리오의 예입니다:

플랫폼 관리자는 태그 docker-builds-2vCPU-8GB를 사용하여 동일한 기본 가상 머신 인스턴스 크기(2 vCPU, 8GB RAM)를 가진 여러 러너를 제공해야 합니다. 최소 두 개의 그런 러너가 필요하며, 이는 고가용성 또는 확장을 위해서입니다.

사용자 인터페이스에 두 개의 별도 러너 항목을 생성하는 대신, 관리자는 동일한 컴퓨팅 인스턴스 크기를 가진 모든 러너를 위한 하나의 러너 구성을 만들 수 있습니다. 관리자는 러너 구성을 위한 인증 토큰을 재사용하여 여러 러너를 등록할 수 있습니다.

각 등록된 러너는 docker-builds-2vCPU-8GB 태그를 상속받습니다.

단일 러너 구성의 모든 자식 러너에 대해, system_id는 고유 식별자로 작용합니다.

그룹화된 러너는 여러 러너 관리자를 통해 다양한 작업을 실행하는 데 재사용될 수 있습니다.

GitLab Runner는 시작 시 또는 구성이 저장될 때 system_id를 생성합니다. system_id는
.runner_system_id 파일에 저장되며, 이는
config.toml과 동일한 디렉토리에 위치하고, 작업 로그 및 러너 관리 페이지에 표시됩니다.

system_id 식별자 생성

system_id를 생성하기 위해, GitLab Runner는 하드웨어 식별자에서 고유한 시스템 식별자를 도출하려고 합니다
(예: 일부 Linux 배포판의 /etc/machine-id).

성공하지 못할 경우, GitLab Runner는 무작위 식별자를 사용하여 system_id를 생성합니다.

system_id는 다음 접두어 중 하나를 가집니다:

  • r_: GitLab Runner가 무작위 식별자를 할당했습니다.
  • s_: GitLab Runner가 하드웨어 식별자에서 고유한 시스템 식별자를 할당했습니다.

컨테이너 이미지를 생성할 때, system_id가 이미지에 하드코딩되지 않도록 유의하는 것이 중요합니다.
system_id가 하드코딩되면, 특정 작업을 실행하는 호스트를 구별할 수 없습니다.

러너 및 러너 관리자 삭제

러너 등록 토큰(더 이상 사용되지 않음)으로 등록된 러너 및 러너 관리자를 삭제하려면,
gitlab-runner unregister 명령어를 사용하세요.

러너 인증 토큰으로 생성된 러너 및 러너 관리자를 삭제하려면,
UI 또는
API를 사용하세요.
러너 인증 토큰으로 생성된 러너는 여러 머신에서 재사용할 수 있는 구성이 가능합니다.
gitlab-runner unregister 명령어를 사용하면,
오직 러너 관리자만 삭제되고, 러너는 삭제되지 않습니다.

인스턴스 러너 구성

오토스케일링 구성에서 인스턴스 러너를 사용하는 것은
“러너 관리자”로 작동하는 러너를 시작하는 효율적이고 효과적인 방법입니다.

VM 또는 포드를 호스팅하는 인프라스트럭처 스택의 컴퓨팅 용량은 다음에 따라 달라집니다:

  • 작업 부하 및 환경을 고려할 때 수집한 요구 사항.
  • 러너 플릿을 호스팅하는 데 사용하는 기술 스택.

CI/CD 작업을 실행하고 시간이 지남에 따라 성능을 분석한 후 컴퓨팅 용량을 조정해야 할 수도 있습니다.

오토스케일링 실행기가 있는 인스턴스 러너를 사용하는 구성에 대해,
최소 두 개의 러너 관리자부터 시작할 것을 권장합니다.

시간이 지남에 따라 필요한 러너 관리자의 총 수는 다음에 따라 달라집니다:

  • 러너 관리자를 호스팅하는 스택의 컴퓨팅 리소스.
  • 각 러너 관리자에 대해 구성하기로 선택한 동시성.
  • 각 관리자가 매시간, 매일 및 매월 실행하는 CI/CD 작업에서 생성되는 부하.

예를 들어, GitLab.com에서는 현재 Docker Machine 실행기로 7개의 러너 관리자를 운영하고 있습니다.
각 CI/CD 작업은 Google Cloud Platform(GCP) n1-standard-1 VM에서 실행됩니다.
이 구성으로, 우리는 매달 수백만 개의 작업을 처리합니다.

러너 모니터링

대규모로 러너 플릿을 운영하는 데 있어 필수적인 단계는,
GitLab에 포함된 러너 모니터링 기능을 설정하고 사용하는 것입니다.

다음 표에는 GitLab Runner 메트릭의 요약이 포함되어 있습니다.
목록에는 Go 전용 프로세스 메트릭이 포함되어 있지 않습니다.
러너에서 해당 메트릭을 보려면, 여기에 언급된 명령어를 실행하세요.

메트릭 이름 설명
gitlab_runner_api_request_statuses_total 러너, 엔드포인트 및 상태별로 구분된 API 요청의 총 수입니다.
gitlab_runner_autoscaling_machine_creation_duration_seconds 머신 생성 시간의 히스토그램입니다.
gitlab_runner_autoscaling_machine_states 이 공급자에서 상태별 머신 수입니다.
gitlab_runner_concurrent 동시 설정의 값입니다.
gitlab_runner_errors_total 포착된 오류의 수입니다. 이 메트릭은 로그 라인을 추적하는 카운터입니다. 메트릭에는 level 레이블이 포함됩니다. 가능한 값은 warning 및 error입니다. 이 메트릭을 포함할 계획이라면, 관찰할 때 rate() 또는 increase()를 사용하세요.
즉, 경고나 오류의 비율이 증가하고 있다면, 이는 추가 조사가 필요한 문제를 나타낼 수 있습니다.  
gitlab_runner_jobs 현재 실행 중인 작업 수를 보여줍니다(라벨의 다른 범위에서).
gitlab_runner_job_duration_seconds 작업 지속 시간의 히스토그램입니다.
gitlab_runner_jobs_total 실행된 총 작업을 표시합니다.
gitlab_runner_limit 현재 한계 설정의 값입니다.
gitlab_runner_request_concurrency 새 작업에 대한 현재 동시 요청 수입니다.
gitlab_runner_request_concurrency_exceeded_total 구성된 request_concurrency 한계를 초과한 요청 수입니다.
gitlab_runner_version_info 서로 다른 빌드 통계 필드로 레이블이 지정된 상수 1 값의 메트릭입니다.
process_cpu_seconds_total 사용된 총 사용자 및 시스템 CPU 시간(초)입니다.
process_max_fds 최대 열린 파일 설명자 수입니다.
process_open_fds 열린 파일 설명자 수입니다.
process_resident_memory_bytes 바이트 단위의 상주 메모리 크기입니다.
process_start_time_seconds 유닉스 에포크 이후 프로세스 시작 시간(초)입니다.
process_virtual_memory_bytes 바이트 단위의 가상 메모리 크기입니다.
process_virtual_memory_max_bytes 바이트 단위의 사용 가능한 최대 가상 메모리 양입니다.

Grafana 대시보드 구성 팁

이 공식 저장소에서 GitLab.com에서 러너 플릿을 운영하기 위해 사용하는 Grafana 대시보드의 소스 코드를 찾을 수 있습니다.

우리는 GitLab.com에 대한 많은 메트릭을 추적합니다. 대규모 클라우드 기반 CI/CD 제공자로서 시스템에 대한 다양한 뷰가 필요하여 문제를 디버깅할 수 있습니다. 대부분의 경우, 자체 관리형 러너 플릿은 GitLab.com와 함께 추적하는 메트릭의 양을 추적할 필요가 없습니다.

여기에서 여러분의 러너 플릿을 모니터링하기 위해 사용하기를 권장하는 몇 가지 필수 대시보드가 있습니다.

러너에서 시작된 작업:

  • 선택한 시간 간격 동안 러너 플릿에서 실행된 총 작업에 대한 개요를 봅니다.

  • 사용 추세를 확인합니다. 이 대시보드는 최소한 매주 분석해야 합니다.

이 데이터를 작업 기간과 같은 다른 메트릭과 연관 지어, CI/CD 작업 성능에 대한 내부 SLO를 계속 충족하기 위해 구성 변경이나 용량 업그레이드가 필요한지 여부를 판단할 수 있습니다.

작업 기간:

  • 러너 플릿의 성능 및 확장성을 분석합니다.

러너 용량:

  • 실행 중인 작업 수를 제한 값 또는 동시 실행 수로 나눈 값을 봅니다.

  • 추가 작업을 실행할 수 있는 용량이 여전히 있는지 확인합니다.

Kubernetes에서 러너 모니터링에 대한 고려사항

OpenShift, EKS 또는 GKE와 같은 Kubernetes 플랫폼을 사용하여 러너 플릿을 호스팅하는 경우 Grafana 대시보드를 설정하기 위해 다른 접근 방식이 필요합니다.

Kubernetes에서는 러너 CI/CD 작업 실행 포드가 자주 생성되고 삭제될 수 있습니다.

이 경우 러너 관리 포드를 모니터링하고 다음을 구현할 수 있도록 계획해야 합니다:

  • 게이지: 서로 다른 출처의 동일한 메트릭의 합계를 표시합니다.

  • 카운터: rate 또는 increase 기능을 적용할 때 카운터를 재설정합니다.