GitLab 호스티드 러너

러너를 직접 설치하고 관리할 필요 없이, GitLab.com이나 GitLab Dedicated에서 CI/CD 잡을 바로 돌리고 싶다면 GitLab이 관리해 주는 호스티드 러너를 쓰면 돼요. 이 러너는 다양한 환경에서 애플리케이션을 빌드하고, 테스트하고, 배포할 수 있도록 준비되어 있어요.

출처: 문서

본문

GitLab 호스티드 러너를 사용해 GitLab.com과 GitLab Dedicated에서 CI/CD 잡을 실행하세요. 이 러너는 여러 환경에서 애플리케이션을 빌드·테스트·배포할 수 있습니다.

자체 러너를 만들고 등록하려면 self-managed 러너 문서를 참고하세요.

GitLab.com용 호스티드 러너

이 러너들은 GitLab.com과 완전히 통합되어 있으며, 모든 프로젝트에서 기본으로 활성화되어 있어 설정이 필요 없어요. 잡은 다음에서 실행할 수 있습니다.

GitLab.com 호스티드 러너 워크플로

호스티드 러너를 사용하면:

각각의 잡은 해당 잡 전용으로 새로 프로비저닝된 VM에서 실행돼요.
잡이 실행되는 가상 머신은 비밀번호 없이 sudo 접근 권한이 있습니다.
스토리지는 운영체제, 소프트웨어가 미리 설치된 컨테이너 이미지, 그리고 클론된 저장소 사본이 함께 공유합니다. 그래서 잡이 실제로 쓸 수 있는 여유 디스크 공간은 줄어들어요.
태그가 없는 잡은 small Linux x86-64 러너에서 실행됩니다.

GitLab.com의 호스티드 러너가 처리하는 잡은 프로젝트에 설정된 타임아웃과 관계없이 3시간 후에 타임아웃됩니다.

GitLab.com 호스티드 러너의 보안

아래는 GitLab Runner 빌드 환경의 보안을 강화하는 추가 내장 계층에 대한 개요예요.

GitLab.com 호스티드 러너는 다음과 같이 구성됩니다.

방화벽 규칙은 임시 VM에서 공용 인터넷으로 나가는 아웃바운드 통신만 허용합니다.
공용 인터넷에서 임시 VM으로 들어오는 인바운드 통신은 허용되지 않아요.
방화벽 규칙은 VM 간 통신을 허용하지 않습니다.
임시 VM에 허용되는 유일한 내부 통신은 러너 매니저로부터의 통신뿐이에요.
임시 러너 VM은 단일 잡만 처리하며, 잡 실행 직후 삭제됩니다.

GitLab.com 호스티드 러너 아키텍처 다이어그램

아래 그림은 GitLab.com 호스티드 러너의 아키텍처 다이어그램입니다.

러너가 어떻게 인증하고 잡 페이로드를 실행하는지 더 알고 싶으면 Runner 실행 흐름 문서를 참고하세요.

GitLab.com 호스티드 러너의 잡 격리

네트워크에서 러너를 격리하는 것에 더해, 각 임시 러너 VM은 단일 잡만 처리하고 잡 실행 직후 바로 삭제됩니다. 아래 예시에서는 프로젝트 파이프라인에서 잡 3개가 실행돼요. 각 잡은 전용 임시 VM에서 실행됩니다.

build 잡은 runner-ns46nmmj-project-43717858, test 잡은 f131a6a2runner-new2m-od-project-43717858, deploy 잡은 runner-tmand5m-project-43717858에서 실행됐어요.

GitLab은 CI 잡이 끝나는 즉시 Google Compute API에 임시 러너 VM 제거 명령을 보냅니다. Google Compute Engine 하이퍼바이저가 가상 머신과 관련 데이터를 안전하게 삭제하는 작업을 맡아요.

GitLab.com 호스티드 러너의 보안에 대한 자세한 내용은 다음을 참고하세요.

Google Cloud 인프라 보안 설계 개요 백서
GitLab Trust Center
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은 GitLab Runner의 최신 버전으로 릴리스 후 일주일 이내에 업데이트하는 것을 목표로 합니다. 모든 GitLab Runner의 breaking change는 Deprecations and removals에서 확인할 수 있어요.

GitLab 커뮤니티 기여용 호스티드 러너

GitLab에 기여하고 싶다면, GitLab 프로젝트와 관련 커뮤니티 포크 전용인 gitlab-shared-runners-manager-X.gitlab.com 러너 플릿이 잡을 처리해요. 이 러너들은 small Linux x86-64 러너와 같은 머신 타입을 사용합니다. GitLab.com 호스티드 러너와 달리, 커뮤니티 기여용 호스티드 러너는 최대 40번 재사용됩니다.

누구나 기여하도록 권장되기 때문에 이 러너는 무료입니다.

GitLab Dedicated용 호스티드 러너

GitLab Dedicated용 호스티드 러너는 온디맨드로 생성되며 GitLab Dedicated 인스턴스와 완전히 통합됩니다. 자세한 내용은 GitLab Dedicated 호스티드 러너 문서를 참고하세요.

지원되는 이미지 수명 주기

macOS와 Windows 호스티드 러너는 지원되는 이미지에서만 잡을 실행할 수 있어요. 직접 만든 이미지는 사용할 수 없습니다. 지원되는 이미지에는 다음과 같은 수명 주기가 있습니다.

Beta

새 이미지는 beta로 릴리스됩니다. 이렇게 하면 일반 공개 전에 피드백을 모으고 잠재적 문제를 해결할 수 있어요. beta 이미지에서 실행되는 잡은 서비스 수준 계약(SLA) 대상이 아닙니다. beta 이미지를 사용한다면 이슈를 만들어 피드백을 줄 수 있어요.

일반 공개 (General availability)

이미지는 beta 단계를 마치고 안정적이라고 판단되면 일반 공개가 됩니다. 일반 공개가 되려면 다음 요구 사항을 충족해야 합니다.

보고된 중요한 버그를 모두 해결하여 beta 단계를 성공적으로 완료
설치된 소프트웨어가 기본 OS와 호환

일반 공개 이미지에서 실행되는 잡은 정의된 서비스 수준 계약의 적용을 받습니다.

Deprecated

동시에 최대 두 개의 일반 공개 이미지가 지원됩니다. 새 일반 공개 이미지가 릴리스되면 가장 오래된 일반 공개 이미지가 deprecated가 돼요. deprecated 이미지는 더 이상 업데이트되지 않으며 3개월 후 삭제됩니다.

사용 데이터

GitLab Dedicated에서 GitLab 호스티드 러너가 사용하는 컴퓨트 분 사용량의 추정치를 볼 수 있습니다.

더 알아보기

호스티드 러너는 잡마다 새 임시 VM이 할당되고 잡 실행 직후 삭제되는 구조라, 보안과 격리 측면이 핵심이에요. 또한 잡 실행 시간이 3시간으로 제한되고 캐시 정리 정책이 있다는 점을 기억하면 배치 전략을 세울 때 도움이 됩니다. 다음으로는 Linux·Windows·macOS 각 플랫폼별 호스티드 러너 상세 문서와 컴퓨트 분(Pricing) 관련 문서를 같이 보는 걸 추천해요.