• 작업 부하와 환경 고려
• Worker, executor 및 자동 확장 기능
  • 병행성과 제한
  • 기본 구성: 하나의 러너, 하나의 worker
  • 중간 구성: 하나의 러너, 여러 workers
  • 자동 확장 구성: 하나 이상의 러너 관리자, 여러 workers
    • Docker Machine executor
    • Kubernetes executor
    • 러너 구성 재사용
      • system_id 식별자 생성
      • 러너 및 러너 관리자 삭제
• 인스턴스 러너 구성
• 러너 모니터링
  • Grafana 대시보드 구성 팁
  • 쿠버네티스 상의 러너 모니터링 고려사항

인스턴스나 그룹 러너 편성 및 운영

이 안내서에는 공유 서비스 모델에서 러너 편성을 확장하는 데 도움이 되는 모범 사례가 포함되어 있습니다.

공유 러너 편성을 호스팅할 때, 다음 사항을 고려하는 잘 계획된 인프라가 필요합니다.

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

조직의 요구 사항에 따라 GitLab 러너 배포 전략을 개발하는 데 이 안내서를 활용하세요.

이 안내서에서는 사용해야 하는 인프라 유형에 대해 구체적인 권장 사항은 제공하지 않습니다. 그러나 매월 수백만 개의 CI/CD 작업을 처리하는 GitLab.com에서 운영하는 러너 편성 경험을 통해 통찰을 얻을 수 있습니다.

작업 부하와 환경 고려

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

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

다른 인프라 스택을 선택하여 다른 러너 편성을 호스팅할 수 있습니다. 예를 들어, 일부 러너를 퍼블릭 클라우드에, 나머지는 온프레미스에 배포해야 할 수 있습니다.

러너 편성의 성능은 편성 환경과 밀접한 관련이 있습니다. 많은 계산 자원을 필요로 하는 CI/CD 작업을 실행할 경우, 공유 컴퓨팅 플랫폼에서 러너를 호스팅하는 것은 권장되지 않습니다.

Worker, executor 및 자동 확장 기능

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

병행성과 제한

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

제한은 Docker Machine 및 Kubernetes와 같이 자동 확장 러너에 대해 다릅니다.

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

기본 구성: 하나의 러너, 하나의 worker

가장 기본적인 구성에서는 지원되는 컴퓨팅 아키텍처 및 운영 체제에 GitLab 러너 소프트웨어를 설치합니다. 예를 들어, Ubuntu Linux를 실행하는 x86-64 가상 머신(VM)이 있을 수 있습니다.

설치가 완료된 후, 한 번만 러너 등록 명령을 실행하고 shell executor를 선택합니다. 그런 다음 러너 config.toml 파일을 편집하여 병행성을 1로 설정합니다.

concurrent = 1

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

이 러너가 처리할 수 있는 GitLab CI/CD 작업은 러너가 설치된 호스트 시스템에서 직접 실행됩니다. 마치 터미널에서 CI/CD 작업 명령을 직접 실행하는 것과 같습니다. 이 경우 러너 config.toml 파일에는 하나의 [[runners]] 섹션이만 들어 있게 되며, 병행성 값을 1로 설정했다면, 이 시스템에서 러너 “worker”가 하나만 CI/CD 작업을 실행할 수 있습니다.

중간 구성: 하나의 러너, 여러 workers

한 대의 컴퓨터에 여러 러너 worker를 등록할 수도 있습니다. 이렇게 하면 러너의 config.toml 파일에 여러 개의 [[runners]] 섹션이 포함됩니다. 추가 러너 worker가 모두 shell executor를 사용하고, 전역 구성 옵션 병행성 값을 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"

하나의 컴퓨터에 많은 러너 worker를 등록할 수 있으며, 각각이 격리된 프로세스입니다. 각 worker의 CI/CD 작업 성능은 호스트 시스템의 계산 용량에 의존합니다.

자동 확장 구성: 하나 이상의 러너 관리자, 여러 workers

GitLab 러너를 자동 확장 설정으로 구성하면 러너를 다른 러너의 관리자로 설정할 수 있습니다. 이는 docker-machine 또는 kubernetes executor로 수행할 수 있습니다. 이 유형의 관리자 전용 구성에서 러너 에이전트 자체는 CI/CD 작업을 실행하지 않습니다.

Docker Machine executor

Docker Machine executor를 사용하면:

• 러너 관리자가 Docker로 온디맨드 가상 머신 인스턴스를 프로비저닝합니다.
• 이 VM에서 GitLab 러너는 .gitlab-ci.yml 파일에서 지정한 컨테이너 이미지를 사용하여 CI/CD 작업을 실행합니다.
• 여러 머신 유형에서 CI/CD 작업의 성능을 테스트해야 합니다.
• 속도 또는 비용에 따라 컴퓨트 호스트를 최적화하는 것을 고려해야 합니다.

Kubernetes executor

Kubernetes executor를 사용하면:

• 러너 관리자가 대상 Kubernetes 클러스터에 포드를 프로비저닝합니다.
• 각 포드에서 CI/CD 작업을 실행하며, 이 포드는 여러 컨테이너로 구성됩니다.
• 작업 실행에 사용되는 포드는 일반적으로 러너 관리자를 호스팅하는 포드보다 더 많은 컴퓨트 및 메모리 자원이 필요합니다.

러너 구성 재사용

같은 러너 인증 토큰과 연관된 각 러너 관리자에는 system_id 식별자가 할당됩니다. system_id는 러너가 사용되는 기계를 식별합니다. 같은 인증 토큰으로 등록된 러너는 고유한 system_id에 의해 단일 러너 항목으로 그룹화됩니다.

동일한 러너를 단일 구성으로 그룹화하면 러너 편성 작업이 간단해집니다.

여기, 비슷한 러너를 단일 구성으로 그룹화할 수 있는 예시 시나리오가 있습니다:

플랫폼 관리자는 docker-builds-2vCPU-8GB 태그를 사용하여 동일한 기본 가상 머신 인스턴스 크기(2 vCPU, 8GB RAM)를 가진 여러 러너를 제공해야 할 필요가 있습니다. 이러한 러너를 높은 가용성 또는 확장성을 위해 최소한 두 개를 원합니다. 관리자는 UI에 두 개의 구분된 러너 항목을 만드는 대신, 동일한 컴퓨팅 인스턴스 크기를 가진 모든 러너에 대해 하나의 러너 구성을 만들 수 있습니다. 인증 토큰을 재사용하여 러너 구성에 여러 러너를 등록할 수 있습니다. 각 등록된 러너는 docker-builds-2vCPU-8GB 태그를 상속합니다. 단일 러너 구성의 모든 하위 러너에 대해 system_id가 고유 식별자로 작용합니다.

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

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

system_id 식별자 생성

system_id를 생성하기 위해 GitLab 러너는 하드웨어 식별자에서 고유한 시스템 식별자를 파생시키려고 시도합니다(예: 일부 Linux 배포판의 /etc/machine-id). 성공하지 못한 경우, GitLab 러너는 랜덤 식별자를 사용하여 system_id를 생성합니다.

system_id는 다음과 같은 접두사 중 하나를 가집니다:

• r_: GitLab 러너가 랜덤 식별자를 할당했습니다.
• s_: GitLab 러너가 하드웨어 식별자로부터 고유한 시스템 식별자를 할당했습니다.

예를 들어, system_id가 이미지에 하드코딩되지 않도록 하려면 이 점을 고려하는 것이 중요합니다. system_id가 하드코딩된 경우 특정 작업을 실행하는 호스트를 구별할 수 없습니다.

러너 및 러너 관리자 삭제

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

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

인스턴스 러너 구성

이미지 빌드, 테스트 및 배포, 정적 분석 및 컨테이너 가상화등과 같은 CI/CD 워크로드를 실행하는 효율적이고 효과적인 방법으로 서버리스 환경에 대한 인스턴스 러너를 사용할 수 있습니다.

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

• 워크로드 및 환경을 고려할 때 캡처한 요구 사항.
• 러너 편성에서 사용하는 기술 스택.

실행중인 CI/CD 워크로드와 시간 경과에 따른 성능 분석 후에 컴퓨팅 용량을 조정해야 할 가능성이 높습니다.

인스턴스 러너를 사용하는 구성에서는 최소한 두 개의 러너 관리자로 시작하는 것이 좋습니다.

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

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

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

러너 모니터링

대규모 러너 편성을 운영하기 위한 중요한 단계는 GitLab의 포함된 러너 모니터링 기능을 설정하고 사용하는 것입니다.

다음 표에는 GitLab 러너 지표에 대한 요약이 포함되어 있습니다. 이 목록에는 Go 특정 프로세스 지표가 포함되어 있지 않습니다. 러너에서 해당 지표를 보려면 여기에 나온 대로 명령을 실행하세요.

Grafana 대시보드 구성 팁

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

우리는 GitLab.com의 다양한 메트릭을 추적합니다. 클라우드 기반 CI/CD의 대규모 제공업체로써 문제를 해결하기 위해 시스템의 여러 다양한 관점이 필요합니다. 대다수의 경우, 자체 관리형 러너 플릿은 GitLab.com에서 추적하는 메트릭의 양이 필요하지 않습니다.

여기 몇 가지 핵심적인 대시보드가 있으며, 귀하의 러너 플릿을 모니터링하는 데 사용하도록 권장합니다.

러너에서 시작된 작업:

• 선택한 시간 간격에 대한 러너 플릿에서 실행된 총 작업의 개요를 확인합니다.
• 사용량의 추이를 확인합니다. 이 대시보드는 주당 최소 한 번씩 분석해야 합니다.

이 데이터를 작업 기간과 같은 다른 메트릭과 상관시켜 내부 CI/CD 작업 성능의 SLO를 제공하기 위해 구성 변경이나 용량 업그레이드가 필요한지 판단할 수 있습니다.

작업 기간:

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

러너 용량:

• 실행 중인 작업 수를 limit 또는 concurrent 값으로 나눈 수를 확인합니다.
• 추가적인 작업을 실행할 여유가 있는지 판단합니다.

쿠버네티스 상의 러너 모니터링 고려사항

러너 플릿을 호스팅하는 데 쿠버네티스 플랫폼을 사용하는 경우(예: OpenShift, EKS, 또는 GKE), Grafana 대시보드를 설정하는 데 다른 접근 방식이 필요합니다.

쿠버네티스에서는 러너 CI/CD 작업 실행 팟이 빈번하게 생성되고 삭제될 수 있습니다. 이러한 경우, 러너 관리자 팟을 모니터링하도록 계획하고 아마도 다음을 구현해야 할 수 있습니다:

• 게이지: 다른 원본에서 같은 메트릭의 집계를 표시합니다.
• 카운터: rate 또는 increase 함수를 적용할 때 카운터를 재설정합니다.