GitLab Runner
GitLab Runner는 GitLab CI/CD와 함께 파이프라인에서 작업을 실행하는 응용 프로그램입니다.
GitLab.com SaaS 러너 사용
만약 GitLab.com을 사용한다면, SaaS 러너에서 CI/CD 작업을 실행할 수 있습니다. 이러한 러너들은 GitLab에 의해 관리되며 GitLab.com과 완벽하게 통합되어 있습니다. 기본적으로 이러한 러너들은 모든 프로젝트에서 활성화되어 있습니다. 프로젝트의 소유자 권한이 있다면 러너들을 비활성화할 수 있습니다.
Self-managed 러너 사용
또는 GitLab Runner를 설치하고 GitLab.com 또는 자체 인스턴스에 고유한 러너를 등록할 수 있습니다. Self-managed 러너를 사용하려면 GitLab Runner를 자체 소유 또는 관리하는 인프라에 설치해야 합니다.
러너 플릿 확장
조직이 러너 플릿을 갖는 규모로 확장될 때, 이러한 러너들의 성능을 모니터링하고 조정하는 방법을 계획해야 합니다.
GitLab Runner 버전
호환성을 유지하기 위해, GitLab Runner 주.부 버전은 GitLab 주요 및 부 버전과 동기화되어야 합니다. 오래된 러너들은 최신 GitLab 버전과 호환될 수 있고, 그 반대도 마찬가지입니다. 그러나 버전 간의 차이가 있는 경우 기능이 제대로 작동하지 않을 수 있습니다.
역호환성은 부 버전 업데이트 사이에서 보장됩니다. 그러나 때로는 GitLab의 부 버전 업데이트가 GitLab Runner가 동일한 부 버전에 있어야 하는 새로운 기능을 도입할 수 있습니다.
자체 러너를 호스트하지만 리포지터리를 GitLab.com에 호스팅하는 경우, GitLab Runner를 최신 버전으로 유지해야 합니다. GitLab.com은 지속적으로 업데이트됩니다.
러너 등록
응용프로그램을 설치한 후, 개별 러너를 등록합니다. 러너는 GitLab에서 나온 CI/CD 작업을 실행하는 에이전트입니다.
러너를 등록하면 GitLab Runner가 설치된 기기와 GitLab 인스턴스 간의 통신을 설정하는 것입니다.
러너는 보통 GitLab Runner를 설치한 동일한 기기에서 작업을 처리합니다. 그러나 컨테이너, Kubernetes 클러스터 또는 클라우드의 자동으로 조정된 인스턴스에서 작업을 처리하는 러너도 사용할 수 있습니다.
Executors
러너를 등록하면 executor를 선택해야 합니다.
Executor는 각 작업이 실행되는 환경을 결정합니다.
예를 들어:
- CI/CD 작업이 PowerShell 명령을 실행하도록 하려면 GitLab Runner를 Windows 서버에 설치한 다음, 쉘 executor를 사용하는 러너를 등록하면 됩니다.
- 사용자 정의 Docker 컨테이너에서 명령을 실행하려면 GitLab Runner를 Linux 서버에 설치하고, Docker executor를 사용하는 러너를 등록하면 됩니다.
이러한 것들은 가능한 설정의 일부에 불과합니다. 가상 머신에 GitLab Runner를 설치하고, 다른 가상 머신을 executor로 사용할 수도 있습니다.
Docker 컨테이너에 GitLab Runner를 설치하고 작업을 실행하는데 Docker executor를 선택하는 경우, 이는 때로 “Docker-in-Docker” 구성으로 언급됩니다.
누가 GitLab UI에서 러너에 액세스할 수 있는가
러너를 등록하기 전에, GitLab의 모든 사용자가 액세스할 것인지, 특정 GitLab 그룹 또는 프로젝트로 제한할 것인지를 결정해야 합니다.
액세스를 할 수 있는 사용자에 따라 세 가지 유형의 러너가 있습니다:
러너의 범위는 등록 중에 정의됩니다. 이것은 러너가 어떤 프로젝트에서 사용 가능한지를 알게 하는 방법입니다.
태그
러너를 등록할 때, 태그를 추가할 수 있습니다.
CI/CD 작업이 실행될 때, 지정된 태그를 확인하여 어떤 러너를 사용해야 하는지를 알 수 있습니다. 태그는 작업을 위한 사용 가능한 러너 디렉터리을 필터링하는 유일한 방법입니다.
예를 들어, 러너에 ruby 태그가 있는 경우, 프로젝트의 .gitlab-ci.yml 파일에 다음 코드를 추가하면 됩니다:
job:
tags:
- ruby
작업이 실행될 때, ruby 태그가 있는 러너가 사용됩니다.
러너 구성
config.toml 파일을 편집하여 러너를 구성할 수 있습니다. 이 파일은 러너 설치 과정 중에 설치됩니다.
이 파일에서 특정 러너 또는 모든 러너에 대한 설정을 편집할 수 있습니다.
로깅, 캐시 등과 같은 설정을 지정할 수 있습니다. 동시성, 메모리, CPU 한도 등도 설정할 수 있습니다.
러너 모니터링
러너를 모니터링하기 위해 Prometheus를 사용할 수 있습니다. 현재 실행 중인 작업 수 및 러너의 CPU 사용량 등을 볼 수 있습니다.
러너를 사용하여 작업 실행
러너가 구성되어 프로젝트에서 사용 가능한 경우, CI/CD 작업에서 러너를 사용할 수 있습니다.
기능
GitLab Runner에는 다음과 같은 기능이 있습니다.
- 병렬로 여러 작업 실행
- 여러 서버에서 여러 토큰 사용 (프로젝트별로도 가능)
- 토큰 당 병렬 작업 수 제한
- 작업은 다음에서 실행할 수 있습니다:
- 로컬로
- Docker 컨테이너 사용
- Docker 컨테이너 사용 및 SSH로 작업 실행
- 다양한 클라우드 및 가상화 하이퍼바이저에서 자동 스케일링된 Docker 컨테이너 사용
- 원격 SSH 서버에 연결
- Go로 작성되어 다른 요구사항 없이 독립된 하나의 이진 파일로 배포됨
- Bash, PowerShell Core, Windows PowerShell 지원
- GNU/Linux, macOS, Windows에서 작동 (도커를 실행할 수 있는 곳이라면 거의 어디서든 작동)
- 작업 실행 환경을 사용자 정의할 수 있음
- 재시작 없이 자동 구성 다시로드
- Docker, Docker-SSH, Parallels 또는 SSH 실행 환경을 지원하는 쉬운 설치
- Docker 컨테이너 캐싱 지원
- GNU/Linux, macOS, Windows용 서비스로 쉬운 설치
- 내장된 Prometheus 메트릭 HTTP 서버
- 프로메테우스 메트릭 및 다른 작업별 데이터를 GitLab으로 모니터링 및 전송하기 위한 Referee worker
Runner 실행 흐름
이 다이어그램은 러너가 등록되고 작업이 요청되고 처리되는 방식을 보여줍니다. 또한 어떤 조치가 등록, 인증 및 작업 토큰을 사용하는지 보여줍니다.
용어 해설
이 용어 해설은 GitLab Runner와 관련된 용어의 정의를 제공합니다.
- GitLab Runner: 대상 컴퓨팅 플랫폼에서 GitLab CI 작업을 실행하는 응용 프로그램을 설치하는 것
-
러너 구성:
config.toml의 단일[[runner]]항목으로 UI에서 러너로 표시됨 -
러너 관리자:
config.toml을 읽고 모든 러너 구성을 병렬로 실행하는 프로세스 -
러너: 선택된 기계에서 작업을 실행하는 프로세스
실행기의 유형에 따라 이 기계는 러너 관리자에 로컬일 수도 있음 (
shell또는docker실행기) 또는 자동 스케일러에 의해 만들어진 원격 기계일 수도 있음 (docker-autoscaler또는kubernetes) - 기계: 러너가 작동하는 가상 머신 (VM) 또는 pod GitLab Runner는 여러 기계에 동일한 러너 구성이 제공되더라도 작업을 별도로 라우팅할 수 있도록 고유하고 지속적인 기계 ID를 자동으로 생성함 이를 통해 UI에서 러너 구성을 그룹화하면서 작업을 별도로 라우팅할 수 있음
공식 GitLab 용어집 및 GitLab Runner의 아키텍처 항목도 참조하세요.
문제 해결
일반적인 문제 해결 방법을 알아보세요. 문제 해결
기여
기여를 환영합니다. 세부 내역은 CONTRIBUTING.md 및 개발 문서를 참조하세요.
GitLab Runner 프로젝트의 리뷰어라면 GitLab Runner 리뷰하기 문서를 읽어보세요.
또한 GitLab Runner 프로젝트의 릴리스 프로세스를 확인할 수 있습니다.
변경 로그
최신 변경 사항을 보려면 CHANGELOG를 참조하세요.
라이선스
이 코드는 MIT 라이선스에 따라 배포됩니다. LICENSE 파일을 확인하세요.
도움말