GitLab Dedicated의 호스팅 러너는 GitLab이 관리하고 GitLab Dedicated 인스턴스와 완전히 통합된 GitLab 호스팅 러너입니다. 호스팅 러너는 자동으로 확장되는 인스턴스 러너이며, 인스턴스와 같은 리전의 AWS EC2에서 실행됩니다.

주요 이점은 다음과 같습니다.

• 프로비저닝, 패치, 확장, 모니터링을 GitLab이 담당합니다
• 단일 테넌트 러너로 GitLab Dedicated 인스턴스와 데이터 레지던시가 동일합니다
• 각 job이 끝나면 폐기되는 임시 러너이며, 아웃바운드 PrivateLink로 안전한 네트워크 연결을 사용합니다
• 자동 확장으로 사용량이 몰리는 시간에도 일정한 성능을 유지합니다
• 고가용성 러너 아키텍처를 기반으로 하는 99.9% 가동률 SLA
• GitLab Credits 대시보드에서 추적되는 GitLab Credits 소비량
• GitLab Credits로 사용한 만큼만 지불

개요는 데모: GitLab Dedicated의 호스팅 러너를 참고합니다.

호스팅 러너를 사용하면 다음과 같습니다.

• 각 job은 해당 job 전용으로 새로 프로비저닝된 가상 머신(VM)에서 실행됩니다.
• job이 실행되는 VM은 비밀번호 없이 sudo 접근이 가능합니다.
• 스토리지는 운영 체제, 소프트웨어가 미리 설치된 이미지, 복제된 리포지터리 사본이 함께 사용합니다. 따라서 job에서 사용할 수 있는 여유 디스크 공간은 그만큼 줄어듭니다.
• 기본적으로 태그가 없는 job은 small Linux x86-64 러너에서 실행됩니다. GitLab 관리자는 GitLab에서 태그 없는 job 실행 옵션을 변경할 수 있습니다.

Linux의 호스팅 러너#

GitLab Dedicated의 Linux 호스팅 러너는 Docker Autoscaler executor를 사용합니다. 각 job은 완전히 격리된 임시 가상 머신(VM)에서 Docker 환경을 할당받고, 최신 버전의 Docker Engine에서 실행됩니다.

Linux x86-64 머신 유형#

Linux x86-64 호스팅 러너에서 사용할 수 있는 머신 유형은 다음과 같습니다.

Linux Arm64 머신 유형#

Linux Arm64 호스팅 러너에서 사용할 수 있는 머신 유형은 다음과 같습니다.

기본 러너 태그는 생성 시점에 할당됩니다. 이후 관리자가 인스턴스 러너의 태그 설정을 변경할 수 있습니다.

컨테이너 이미지#

Linux 러너는 Docker Autoscaler executor를 사용하므로, .gitlab-ci.yml 파일에 이미지를 정의해 원하는 컨테이너 이미지를 선택할 수 있습니다. 선택한 Docker 이미지가 기반 프로세서 아키텍처와 호환되는지 확인합니다. .gitlab-ci.yml 파일 예시를 참고합니다.

이미지를 설정하지 않으면 기본값은 ruby:3.1입니다.

Docker Hub 컨테이너 레지스트리의 이미지를 사용하면 속도 제한에 걸릴 수 있습니다. GitLab Dedicated가 단일 네트워크 주소 변환(NAT) IP 주소를 사용하기 때문입니다.

속도 제한을 피하려면 다음을 대신 사용합니다.

• GitLab 컨테이너 레지스트리에 저장된 이미지
• 속도 제한이 없는 다른 공개 레지스트리에 저장된 이미지
• 풀스루 캐시 역할을 하는 의존성 프록시

Docker in Docker 지원#

러너는 privileged 모드로 실행되도록 구성되어 있어, Docker in Docker로 Docker 이미지를 네이티브로 빌드하거나 격리된 job 안에서 여러 컨테이너를 실행할 수 있습니다.

러너 스택 동시 실행 계획#

각 프로덕션 러너 스택은 최대 1,000개의 job을 동시에 실행할 수 있습니다. 이 제한은 제출된 job이 아니라 실행 중인 job에 적용됩니다. 스택이 제한에 도달하면 추가 job은 용량이 확보될 때까지 대기열에 머무릅니다.

특정 스택으로 job을 보내려면 해당 스택의 러너 태그를 사용합니다. 1,000개가 넘는 job이 동시에 실행될 것으로 예상된다면 러너 태그로 여러 스택에 job을 분산합니다.

서비스 수준 계약(SLA) 산정에서는, job이 대기 상태로 들어간 시점에 스택이 이미 1,000개의 job을 실행 중이었다면 시작까지 5분 넘게 걸린 job이라도 지연된 job으로 계산하지 않습니다.

호스팅 러너 관리#

Switchboard에서 호스팅 러너를 생성하고 확인할 수 있으며, GitLab에서 확인하고 구성할 수 있습니다. 특정 프로젝트나 그룹에 대해 호스팅 러너를 비활성화할 수도 있습니다.

Switchboard에서 호스팅 러너 관리#

Switchboard로 GitLab Dedicated 인스턴스의 호스팅 러너를 생성하고 확인할 수 있습니다.

사전 요구 사항:

• 고객 성공 매니저나 계정 담당자가 해당 인스턴스에 호스팅 러너를 활성화해 두어야 합니다.

Switchboard에서 호스팅 러너 만들기#

인스턴스마다 유형과 크기 조합별로 러너를 하나씩 만들 수 있습니다. Switchboard에 사용할 수 있는 러너 옵션이 표시됩니다.

호스팅 러너를 만드는 방법은 다음과 같습니다.

1. Switchboard에 로그인합니다.
2. 왼쪽 사이드바에서 Hosted runners를 선택합니다.
3. New hosted runner를 선택합니다.
4. 러너 크기를 고른 다음 Create hosted runner를 선택합니다.

호스팅 러너를 사용할 준비가 되면 이메일 알림을 받습니다.

기존 러너에 구성한 아웃바운드 PrivateLink 연결은 새 러너에 적용되지 않습니다. 새 러너마다 별도의 요청이 필요합니다.

Switchboard에서 호스팅 러너 보기#

호스팅 러너를 확인하는 방법은 다음과 같습니다.

1. Switchboard에 로그인합니다.
2. 왼쪽 사이드바에서 Hosted runners를 선택합니다.
3. 선택 사항. 호스팅 러너 목록에서 GitLab에서 접근할 러너의 Runner ID를 복사합니다.

GitLab에서 호스팅 러너 보기 및 구성#

GitLab 관리자는 Admin 영역에서 GitLab Dedicated 인스턴스의 호스팅 러너를 관리할 수 있습니다.

GitLab에서 호스팅 러너 보기#

GitLab Dedicated 인스턴스의 호스팅 러너는 Runners 페이지와 Fleet 대시보드에서 확인할 수 있습니다.

사전 요구 사항:

• 관리자여야 합니다.

GitLab에서 호스팅 러너를 확인하는 방법은 다음과 같습니다.

1. 오른쪽 위에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 CI/CD > Runners를 선택합니다.
3. 선택 사항. Fleet dashboard를 선택합니다.

GitLab에서 호스팅 러너 구성#

사전 요구 사항:

• 관리자여야 합니다.

러너 태그의 기본값 변경을 포함해 GitLab Dedicated 인스턴스의 호스팅 러너를 구성할 수 있습니다.

사용할 수 있는 구성 옵션은 다음과 같습니다.

• 최대 job 타임아웃 변경
• 태그가 있는 job 또는 태그가 없는 job을 실행하도록 러너 설정

GitLab에서 그룹 또는 프로젝트에 대해 호스팅 러너 비활성화#

기본적으로 호스팅 러너는 GitLab Dedicated 인스턴스의 모든 프로젝트와 그룹에서 사용할 수 있습니다. GitLab Maintainer는 프로젝트나 그룹에 대해 호스팅 러너를 비활성화할 수 있습니다.

보안 및 네트워크#

GitLab Dedicated의 호스팅 러너에는 GitLab Runner 빌드 환경의 보안을 강화하는 계층이 내장되어 있습니다.

• 방화벽 규칙은 임시 VM에서 공용 인터넷으로 나가는 아웃바운드 통신만 허용합니다.
• 방화벽 규칙은 공용 인터넷에서 임시 VM으로 들어오는 인바운드 통신을 허용하지 않습니다.
• 방화벽 규칙은 VM 간 통신을 허용하지 않습니다.
• 러너 매니저만 임시 VM과 통신할 수 있습니다.
• 임시 러너 VM은 job 하나만 처리하고 job 실행 후 삭제됩니다.
• 러너는 단일 테넌트이며 다른 GitLab Dedicated 인스턴스와 공유되지 않습니다.

호스팅 러너에서 AWS 계정으로 PrivateLink 연결을 활성화할 수도 있습니다.

자세한 내용은 GitLab Dedicated의 호스팅 러너 아키텍처 다이어그램을 참고합니다.

아웃바운드 PrivateLink 연결#

아웃바운드 PrivateLink 연결은 GitLab Dedicated의 호스팅 러너와 AWS VPC의 서비스 사이에 안전한 연결을 만듭니다. 이 연결은 트래픽을 공용 인터넷에 노출하지 않으며, 호스팅 러너가 다음을 수행할 수 있게 합니다.

• 사용자 정의 시크릿 매니저 같은 프라이빗 서비스에 접근합니다.
• 인프라에 저장된 아티팩트나 job 이미지를 가져옵니다.
• 인프라에 배포합니다.

GitLab이 관리하는 러너 계정의 모든 러너에는 기본적으로 두 개의 아웃바운드 PrivateLink 연결이 있습니다.

• GitLab 인스턴스로의 연결
• GitLab이 통제하는 Prometheus 인스턴스로의 연결

이 연결은 미리 구성되어 있으며 변경할 수 없습니다. 테넌트의 Prometheus 인스턴스는 GitLab이 관리하며 사용자는 접근할 수 없습니다.

호스팅 러너에서 다른 VPC 서비스와 아웃바운드 PrivateLink 연결을 사용하려면 지원 요청을 통한 수동 구성이 필요합니다.

인바운드 및 아웃바운드 연결#

공용 인터넷이나 신뢰할 수 없는 출처에서 GitLab Dedicated의 호스팅 러너로 들어오는 인바운드 연결은 차단됩니다. 러너 매니저만 예외이며, 임시 VM과 통신할 수 있습니다.

아웃바운드 연결은 기본적으로 열려 있습니다. 특정 IP 주소나 범위를 차단하려면 차단할 범위를 명시해 지원 티켓을 제출합니다. GitLab은 이 차단 목록을 최선의 노력으로 유지합니다. 자세한 내용은 고객 성공 매니저나 계정 담당자에게 문의합니다.

호스팅 러너 사용#

Switchboard에서 호스팅 러너를 만들고 러너가 준비되면 사용할 수 있습니다.

러너를 사용하려면 .gitlab-ci.yml 파일의 job 구성에서 태그를 사용하려는 호스팅 러너에 맞게 조정합니다.

Linux medium x86-64 러너라면 job을 다음과 같이 구성합니다.

job_name:
  tags:
    - linux-medium-amd64  # Use the medium-sized Linux runner

기본적으로 태그가 없는 job은 small Linux x86-64 러너가 가져갑니다. GitLab 관리자는 태그가 없는 job을 실행하지 않도록 GitLab에서 인스턴스 러너를 구성할 수 있습니다.

job 구성을 바꾸지 않고 job을 이전하려면 기존 job 구성에 사용된 태그와 일치하도록 호스팅 러너 태그를 변경합니다.

no runners that match all of the job's tags 오류 메시지와 함께 job이 멈춰 있다면 다음을 확인합니다.

1. 올바른 태그를 선택했는지 확인합니다
2. 프로젝트나 그룹에서 인스턴스 러너가 활성화되어 있는지 확인합니다.

서비스 수준 계약#

GitLab Dedicated의 호스팅 러너는 고가용성(HA) 러너 아키텍처를 기반으로 99.9% 가동률 SLA를 보장합니다. GitLab은 호스팅 러너 SLA를 GitLab Dedicated 인스턴스 SLA와 별도로 산정하므로, 호스팅 러너의 다운타임은 GitLab Dedicated 인스턴스의 다운타임으로 계산되지 않습니다. 가용성 측정 방식, 유효 job 모집단, 제외 시간, 서비스 크레딧을 포함한 전체 정의는 GitLab Dedicated의 호스팅 러너 SLA 정의를 참고합니다.

사용량 및 모니터링#

초과 사용이 우려된다면 GitLab Credits 대시보드에서 사용량을 모니터링하고 다음 중 하나를 선택합니다.

• 월간 크레딧 약정 규모를 늘립니다.
• 초과분을 수용하고 온디맨드 크레딧으로 job을 계속 실행합니다.
• CI/CD job을 다른 자체 호스팅 러너로 보냅니다.

호스팅 러너의 GitLab Credits 소비량을 추적하려면 GitLab Credits 대시보드를 참고합니다. 컴퓨팅 사용량은 GitLab Dedicated의 GitLab 호스팅 러너 컴퓨팅 사용량을 참고합니다.

사용량 상한 예외#

GitLab Dedicated의 호스팅 러너는 사용량 상한에서 제외됩니다. 중단되면 워크플로의 핵심 부분이 멈추기 때문입니다. 구독 상한이나 사용자별 상한이 있어도 CI/CD job 실행은 멈추지 않습니다. 월간 약정 풀을 모두 소진한 뒤에도 job은 계속 실행되며, 평소 순서대로 온디맨드 크레딧을 사용합니다. 상한이 적용되지 않으므로 상한 기반 통제로 이 지출을 제한할 수 없습니다. 대신 GitLab Credits 대시보드에서 소비량을 모니터링합니다.

가격#

가격 정보는 계정 담당자에게 문의합니다.