GitLab이 호스팅하는 러너에서 CI/CD 작업을 실행할 수 있습니다. 이러한 러너는 GitLab에서 관리하며 GitLab Dedicated 인스턴스와 완전히 통합됩니다. Dedicated용 GitLab 호스팅 러너는 자동 확장 인스턴스 러너로, GitLab Dedicated 인스턴스와 동일한 리전의 AWS EC2에서 실행됩니다.

호스팅 러너를 사용하는 경우:

• 각 작업은 특정 작업에 전용으로 새로 프로비저닝된 가상 머신(VM)에서 실행됩니다.
• 작업이 실행되는 VM에는 비밀번호 없이 sudo 액세스가 있습니다.
• 스토리지는 운영 체제, 사전 설치된 소프트웨어가 있는 이미지, 복제된 저장소의 복사본이 공유합니다. 즉, 작업에 사용 가능한 여유 디스크 공간이 줄어듭니다.
• 기본적으로 태그 없는 작업은 소형 Linux x86-64 러너에서 실행됩니다. GitLab 관리자는 GitLab에서 태그 없는 작업 실행 옵션을 변경할 수 있습니다.

Linux의 호스팅 러너#

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

Linux x86-64 머신 유형#

다음 머신 유형은 Linux x86-64의 호스팅 러너에서 사용 가능합니다.

Linux Arm64 머신 유형#

다음 머신 유형은 Linux Arm64의 호스팅 러너에서 사용 가능합니다.

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

컨테이너 이미지#

Linux의 러너는 Docker Autoscaler 실행기를 사용하므로 .gitlab-ci.yml 파일에서 이미지를 정의하여 모든 컨테이너 이미지를 선택할 수 있습니다. 선택한 Docker 이미지가 기본 프로세서 아키텍처와 호환되는지 확인합니다. 예시 .gitlab-ci.yml 파일을 참조하세요.

이미지가 설정되지 않은 경우 기본값은 ruby:3.1입니다.

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

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

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

Docker in Docker 지원#

러너는 Docker 이미지를 기본적으로 빌드하거나 격리된 작업 내에서 여러 컨테이너를 실행하는 Docker in Docker를 지원하기 위해 privileged 모드에서 실행되도록 구성됩니다.

호스팅 러너 관리#

Switchboard에서 호스팅 러너 관리#

Switchboard를 사용하여 GitLab Dedicated 인스턴스에 대한 호스팅 러너를 만들고 볼 수 있습니다.

필수 조건:

• 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 인스턴스에 대한 호스팅 러너를 볼 수 있습니다.

필수 조건:

• 관리자여야 합니다.

GitLab에서 호스팅 러너를 보려면:

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

GitLab에서 호스팅 러너 구성#

필수 조건:

• 관리자여야 합니다.

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

사용 가능한 구성 옵션은 다음과 같습니다:

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

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

기본적으로 호스팅 러너는 GitLab Dedicated 인스턴스의 모든 프로젝트 및 그룹에서 사용 가능합니다. GitLab 유지 관리자는 프로젝트 또는 그룹에 대해 호스팅 러너를 비활성화할 수 있습니다.

보안 및 네트워크#

GitLab Dedicated용 호스팅 러너에는 GitLab Runner 빌드 환경의 보안을 강화하는 기본 레이어가 있습니다.

GitLab Dedicated용 호스팅 러너에는 다음 구성이 있습니다:

• 방화벽 규칙은 임시 VM에서 공개 인터넷으로의 아웃바운드 통신만 허용합니다.
• 방화벽 규칙은 공개 인터넷에서 임시 VM으로의 인바운드 통신을 허용하지 않습니다.
• 방화벽 규칙은 VM 간 통신을 허용하지 않습니다.
• 러너 관리자만 임시 VM과 통신할 수 있습니다.
• 임시 러너 VM은 단일 작업만 처리하고 작업 실행 후 삭제됩니다.

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

자세한 내용은 GitLab Dedicated의 호스팅 러너에 대한 아키텍처 다이어그램을 참조하세요.

아웃바운드 PrivateLink 연결#

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

• 사용자 정의 시크릿 관리자와 같은 개인 서비스에 액세스합니다.
• 인프라에 저장된 아티팩트 또는 작업 이미지를 검색합니다.
• 인프라에 배포합니다.

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

• GitLab 인스턴스에 대한 연결
• GitLab 제어 Prometheus 인스턴스에 대한 연결

이러한 연결은 사전 구성되어 있으며 수정할 수 없습니다. 테넌트의 Prometheus 인스턴스는 GitLab에서 관리하며 사용자는 액세스할 수 없습니다.

호스팅 러너에 대한 다른 VPC 서비스와 함께 아웃바운드 PrivateLink 연결을 사용하려면 지원 요청으로 수동 구성이 필요합니다. 자세한 내용은 아웃바운드 PrivateLink 연결을 참조하세요.

IP 범위#

GitLab Dedicated용 호스팅 러너의 IP 범위는 요청 시 사용 가능합니다. IP 범위는 최선의 노력으로 유지되며 인프라 변경으로 인해 언제든지 변경될 수 있습니다. 자세한 내용은 고객 성공 관리자 또는 계정 담당자에게 문의하세요.

호스팅 러너 사용#

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

러너를 사용하려면 .gitlab-ci.yml 파일의 작업 구성에서 태그를 사용하려는 호스팅 러너와 일치하도록 조정합니다.

Linux 중형 x86-64 러너의 경우 작업을 다음과 같이 구성합니다:

job_name:
  tags:
    - linux-medium-amd64  # 중형 Linux 러너 사용

기본적으로 태그 없는 작업은 소형 Linux x86-64 러너에 의해 수행됩니다. GitLab 관리자는 GitLab에서 인스턴스 러너를 구성하여 태그 없는 작업을 실행하지 않도록 할 수 있습니다.

작업 구성을 변경하지 않고 작업을 마이그레이션하려면 호스팅 러너 태그를 수정하여 기존 작업 구성에 사용된 태그와 일치시킵니다.

no runners that match all of the job's tags 오류 메시지와 함께 작업이 중단되는 경우:

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

업그레이드#

러너 버전 업그레이드는 짧은 다운타임이 필요합니다. 러너는 GitLab Dedicated 테넌트의 예정된 유지보수 창 동안 업그레이드됩니다. 무중단 업그레이드를 구현하는 이슈가 있습니다.

가격#

가격 세부 정보는 계정 담당자에게 문의하세요.

GitLab Dedicated 고객에게 30일 무료 평가판을 제공합니다. 평가판에는 다음이 포함됩니다:

• Small, Medium, Large Linux x86-64 러너
• Small 및 Medium Linux Arm 러너
• 최대 100개의 동시 작업을 지원하는 제한된 자동 확장 구성