GitLab 호스팅 러너
Offering: GitLab Dedicated
GitLab 호스팅 러너를 사용하여 GitLab.com과 GitLab Dedicated에서 CI/CD 잡을 실행합니다. 자체 러너를 생성하고 등록하려면 자체 관리 러너를 참조하세요. 이러한 러너는 GitLab.com과 완전히 통합되어 있으며 별도 구성 없이 모든 프로젝트에 기본적으로 활성화됩니다.
GitLab 호스팅 러너를 사용하여 GitLab.com과 GitLab Dedicated에서 CI/CD 잡을 실행합니다. 이러한 러너는 다양한 환경에서 애플리케이션을 빌드, 테스트, 배포할 수 있습니다.
자체 러너를 생성하고 등록하려면 자체 관리 러너를 참조하세요.
GitLab.com용 호스팅 러너#
이러한 러너는 GitLab.com과 완전히 통합되어 있으며 별도 구성 없이 모든 프로젝트에 기본적으로 활성화됩니다. 잡은 다음에서 실행할 수 있습니다:
GitLab.com 호스팅 러너 워크플로우#
호스팅 러너를 사용하는 경우:
- 각 잡은 특정 잡 전용으로 새로 프로비저닝된 VM에서 실행됩니다.
- 잡이 실행되는 가상 머신은 비밀번호 없이
sudo액세스가 있습니다. - 스토리지는 운영 체제, 사전 설치된 소프트웨어가 있는 컨테이너 이미지, 클론된 저장소의 복사본에 의해 공유됩니다. 따라서 잡이 사용할 수 있는 여유 디스크 공간이 줄어듭니다.
- 태그 없는 잡은
smallLinux x86-64 러너에서 실행됩니다.
GitLab.com의 호스팅 러너에서 처리되는 잡은 프로젝트에 구성된 타임아웃과 관계없이 3시간 후에 타임아웃됩니다.
GitLab.com의 호스팅 러너 보안#
다음 섹션에서는 GitLab Runner 빌드 환경의 보안을 강화하는 추가 내장 레이어에 대한 개요를 제공합니다.
GitLab.com의 호스팅 러너는 다음과 같이 구성됩니다:
- 방화벽 규칙은 임시 VM에서 공개 인터넷으로의 아웃바운드 통신만 허용합니다.
- 공개 인터넷에서 임시 VM으로의 인바운드 통신은 허용되지 않습니다.
- 방화벽 규칙은 VM 간 통신을 허용하지 않습니다.
- 임시 VM으로 허용되는 유일한 내부 통신은 러너 관리자로부터의 통신입니다.
- 임시 러너 VM은 단일 잡을 제공하며 잡 실행 후 즉시 삭제됩니다.
GitLab.com의 호스팅 러너 아키텍처 다이어그램#
다음 그래픽은 GitLab.com의 호스팅 러너 아키텍처 다이어그램을 보여줍니다.
러너가 인증하고 잡 페이로드를 실행하는 방법에 대한 자세한 내용은 러너 실행 흐름을 참조하세요.
GitLab.com의 호스팅 러너 잡 격리#
네트워크에서 러너를 격리하는 것 외에도 각 임시 러너 VM은 단일 잡만 제공하며 잡 실행 후 즉시 삭제됩니다. 다음 예에서 프로젝트 파이프라인에서 세 개의 잡이 실행됩니다. 이러한 각 잡은 전용 임시 VM에서 실행됩니다.
빌드 잡은 runner-ns46nmmj-project-43717858에서, 테스트 잡은 f131a6a2runner-new2m-od-project-43717858에서, 배포 잡은 runner-tmand5m-project-43717858에서 실행되었습니다.
GitLab은 CI 잡이 완료된 후 즉시 임시 러너 VM을 제거하는 명령을 Google Compute API에 전송합니다. Google Compute Engine 하이퍼바이저가 가상 머신과 관련 데이터를 안전하게 삭제하는 작업을 담당합니다.
GitLab.com의 호스팅 러너 보안에 대한 자세한 내용은 다음을 참조하세요:
- Google Cloud 인프라 보안 설계 개요 백서
- GitLab 트러스트 센터
- GitLab 보안 컴플라이언스 컨트롤
GitLab.com의 호스팅 러너 캐싱#
호스팅 러너는 Google Cloud Storage(GCS) 버킷에 저장된 분산 캐시를 공유합니다. 객체 수명 주기 관리 정책에 따라 최근 14일 동안 업데이트되지 않은 캐시 내용은 자동으로 제거됩니다. 캐시가 압축 아카이브가 된 후 업로드된 캐시 아티팩트의 최대 크기는 5 GB입니다.
캐싱 작동 방식에 대한 자세한 내용은 GitLab.com의 호스팅 러너 아키텍처 다이어그램과 GitLab CI/CD에서 캐싱을 참조하세요.
GitLab.com의 호스팅 러너 가격#
GitLab.com의 호스팅 러너에서 실행되는 잡은 네임스페이스에 할당된 컴퓨팅 분을 소비합니다. 이러한 러너에서 사용할 수 있는 분 수는 구독 플랜에 포함된 컴퓨팅 분 또는 추가로 구매한 컴퓨팅 분에 따라 다릅니다.
크기에 따른 머신 유형에 적용되는 비용 계수에 대한 자세한 내용은 비용 계수를 참조하세요.
GitLab.com의 호스팅 러너 SLO 및 릴리스 사이클#
SLO 목표는 CI/CD 잡의 90%가 120초 이내에 실행을 시작하도록 하는 것입니다. 오류율은 0.5% 미만이어야 합니다.
GitLab은 릴리스 후 1주일 이내에 GitLab Runner의 최신 버전으로 업데이트하는 것을 목표로 합니다. 지원 중단 및 제거에서 모든 GitLab Runner 주요 변경 사항을 찾을 수 있습니다.
GitLab 커뮤니티 기여용 호스팅 러너#
GitLab에 기여하고 싶은 경우 잡은 GitLab 프로젝트 및 관련 커뮤니티 포크 전용 gitlab-shared-runners-manager-X.gitlab.com 러너 집합에 의해 처리됩니다.
이러한 러너는 small Linux x86-64 러너와 동일한 머신 유형을 기반으로 합니다.
GitLab.com의 호스팅 러너와 달리 GitLab 커뮤니티 기여용 호스팅 러너는 최대 40번까지 재사용됩니다.
기여를 장려하기 때문에 이러한 러너는 무료입니다.
GitLab Dedicated용 호스팅 러너#
GitLab Dedicated용 호스팅 러너는 요청 시 생성되며 GitLab Dedicated 인스턴스와 완전히 통합됩니다. 자세한 내용은 GitLab Dedicated용 호스팅 러너를 참조하세요.
지원되는 이미지 수명 주기#
macOS 및 Windows의 호스팅 러너는 지원되는 이미지에서만 잡을 실행할 수 있습니다. 자체 이미지를 가져올 수 없습니다. 지원되는 이미지의 수명 주기는 다음과 같습니다:
베타#
새 이미지는 베타로 릴리스됩니다. 이를 통해 일반 가용성 전에 피드백을 수집하고 잠재적 문제를 해결할 수 있습니다. 베타 이미지에서 실행되는 잡은 서비스 수준 계약의 적용을 받지 않습니다. 베타 이미지를 사용하는 경우 이슈를 생성하여 피드백을 제공할 수 있습니다.
일반 가용성#
이미지는 베타 단계를 완료하고 안정적인 것으로 간주된 후 일반적으로 사용 가능해집니다. 일반적으로 사용 가능하게 되려면 이미지는 다음 요구 사항을 충족해야 합니다:
- 보고된 모든 중요 버그를 해결하여 베타 단계를 성공적으로 완료
- 기본 OS와 설치된 소프트웨어의 호환성
일반적으로 사용 가능한 이미지에서 실행되는 잡은 정의된 서비스 수준 계약의 적용을 받습니다.
지원 중단#
한 번에 최대 두 개의 일반적으로 사용 가능한 이미지가 지원됩니다. 새 일반적으로 사용 가능한 이미지가 릴리스된 후 가장 오래된 일반적으로 사용 가능한 이미지가 지원 중단됩니다. 지원 중단된 이미지는 더 이상 업데이트되지 않으며 3개월 후에 삭제됩니다.
사용 데이터#
GitLab Dedicated에서 GitLab 호스팅 러너의 컴퓨팅 분 사용 예상값을 볼 수 있습니다.