인스턴스 또는 그룹 러너의 계획 및 운영

이 가이드에는 공유 서비스 모델에서 러너 편대를 확장하는 최상의 실천 사례가 포함되어 있습니다.

공유 러너 편대를 호스팅할 때는 다음을 고려하여 보다 잘 계획된 인프라를 필요로 합니다.

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

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

이 가이드에서는 사용해야 할 인프라의 유형에 대해 구체적인 권장 사항은 하지 않습니다. 그러나 매달 수백만 개의 CI/CD 작업을 처리하는 GitLab.com에서 러너 편대를 운영하는 경험으로부터 통찰을 제공합니다.

작업 부하 및 환경 고려

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

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

서로 다른 인프라 스택을 선택하여 서로 다른 러너 편대를 호스팅할 수 있습니다. 예를 들어, 공용 클라우드와 온프레미스에 각각 러너를 배포해야 할 수도 있습니다.

러너 편대의 성능은 편대의 환경과 직접적으로 관련이 있습니다. 고자원 소모형 CI/CD 작업을 대량으로 실행하는 경우, 공유 컴퓨팅 플랫폼에 편대를 호스팅하는 것은 권장되지 않습니다.

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

gitlab-runner 실행 파일은 CI/CD 작업을 처리합니다. 각 러너는 작업 실행 요청을 수신하고 사전 정의된 구성에 따라 처리하는 격리된 프로세스입니다. 각 러너는 “하위 프로세스”(또는 “워커”로 불림)를 생성하여 작업을 실행할 수 있습니다.

동시성 및 제한

  • 동시성: 호스트 시스템의 모든 구성된 러너를 사용하여 동시에 실행할 수 있는 작업 수를 설정합니다.
  • 제한: 러너가 동시에 실행할 수 있는 하위 프로세스 수를 설정합니다.

제한은 Docker Machine 및 Kubernetes와 같은 자동 확장 러너에 대해 다르게 적용됩니다.

  • 자동 확장되지 않는 러너에서는 제한이 호스트 시스템의 러너 용량을 정의합니다.
  • 자동 확장 러너에서는 제한이 실행할 러너 수를 의미합니다.

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

가장 기본적인 구성에서는 지원되는 컴퓨팅 아키텍처와 운영 체제에 GitLab 러너 소프트웨어를 설치합니다. 예를 들어, 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]] 섹션이 포함됩니다. 추가된 모든 러너 워커가 shell 실행기를 사용하도록 등록되고 전역 구성 옵션 concurrent 값을 3으로 업데이트한다면, 이 호스트에서 동시에 실행할 수 있는 작업 상한선은 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 클러스터에서 파드를 생성합니다.
  • 각 파드에서 CI/CD 작업이 실행되며, 여러 컨테이너로 구성됩니다.
  • 작업 실행용으로 사용되는 파드들은 일반적으로 러너 관리자를 호스팅하는 파드보다 더 많은 컴퓨팅 및 메모리 리소스를 요구합니다.

러너 구성 재사용

같은 러너 인증 토큰과 관련된 각 러너 관리자에는 system_id 식별자가 할당됩니다. system_id는 러너를 사용하는 기계를 식별합니다. 동일한 인증 토큰으로 등록된 러너 및 서로 다른 system_id 값은 하나의 러너 그룹으로 묶입니다. 그룹화된 러너는 여러 러너 관리자에 의해 여러 작업에 대해 재사용될 수 있습니다.

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

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가 하드코딩되어 있으면 특정 작업을 실행하는 호스트를 구별할 수 없습니다.

러너 및 러너 관리자 삭제

러너 등록 토큰(deprecated)으로 등록된 러너 및 러너 관리자를 삭제하려면 gitlab-runner unregister 명령을 사용하세요.

러너 인증 토큰으로 생성된 러너 및 러너 관리자를 삭제하려면 UI 또는 API를 사용하세요. 러너 인증 토큰으로 생성된 러너는 여러 기계에서 재사용할 수 있는 구성입니다. gitlab-runner unregister 명령을 사용하면 러너 관리자만 삭제되고 러너는 삭제되지 않습니다.

인스턴스 러너 구성

인스턴스 러너를 오토스케일링 구성(러너(runner)가 “러너 매니저”로 작동하는 경우)으로 사용하는 것은 시작하는 효율적이고 효과적인 방법입니다.

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

  • 워크로드 및 환경을 고려할 때 캡처한 요구 사항
  • 사용하는 기술 스택을 러너 플릿을 호스팅하는 데 사용하는 경우

CI/CD 워크로드를 실행하고 성능을 분석한 후에는 컴퓨팅 용량을 조정해야 할 것입니다.

오토스케일링 실행자를 사용하는 구성의 경우, 최소한 두 개의 러너 매니저로 시작하는 것이 좋습니다.

시간이 지남에 따라 필요한 러너 매니저의 총 수는 다음에 따라 달라질 것입니다:

  • 러너 매니저를 호스팅하는 스택의 컴퓨팅 리소스
  • 각 러너 매니저에 대해 구성할 동시성
  • 각 매니저가 시간당, 일일 및 월별로 실행하는 CI/CD 작업으로 생성된 부하

예를 들어, GitLab.com에서는 현재 Docker Machine 실행자를 사용하여 일곱 개의 러너 매니저를 실행 중입니다. 각 CI/CD 작업은 Google Cloud Platform (GCP) n1-standard-1 VM에서 실행됩니다. 이 구성으로 매월 수백만 개의 작업을 처리합니다.

러너 모니터링

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

다음 표에는 GitLab 러너 메트릭의 요약이 포함되어 있습니다. 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에서 러너 모니터링을 고려할 사항

러너 플릿을 호스팅하기 위해 Kubernetes 플랫폼(예: OpenShift, EKS, 또는 GKE)을 사용하는 경우, Grafana 대시보드 설정에 대해 다른 방법을 고려해야 합니다.

Kubernetes에서는 runner CI/CD 작업 실행용의 pod가 자주 생성되고 삭제됩니다. 이러한 경우에는 러너 매니저 pod를 모니터링하고 아래와 같은 사항을 구현할 필요가 있을 수 있습니다:

  • 게이지: 동일한 메트릭의 집계를 표시합니다.
  • 카운터: rate 또는 increase 함수를 적용할 때 카운터를 재설정합니다.