인스턴스 또는 그룹 러너 플릿 계획 및 운영

공유 서비스 모델에서 러너 플릿을 스케일링할 때 적용할 모범 사례와 권장 사항을 설명합니다.

공유 서비스 모델에서 러너 플릿을 스케일링할 때 이러한 모범 사례와 권장 사항을 적용하세요. 인스턴스 러너 플릿을 호스팅할 때는 다음을 고려한 잘 계획된 인프라가 필요합니다: 컴퓨팅 용량 스토리지 용량 네트워크 대역폭 및 처리량 작업 유형(프로그래밍 언어, OS 플랫폼, 종속 라이브러리 포함) 이러한 권장 사항을 사용하여 조직의 요구 사항에 기반한 GitLab Runner 배포 전략을 개발하세요. 워크로드 및 환경 고려 # 러너를 배포하기 전에 워크로드 및 환경 요구 사항을 고려하세요. GitLab에 온보딩할 계획인 팀 목록을 만드세요. 조직에서 사용하는 프로그래밍 언어, 웹 프레임워크, 라이브러리를 카탈로그화하세요. 예를 들어 Go, C++, PHP, Java, Python, JavaScript, React, Node.js. 각 팀이 시간당, 일당 실행할 수 있는 CI/CD 작업 수를 추정하세요. 컨테이너를 사용하여 해결할 수 없는 빌드 환경 요구 사항이 있는 팀이 있는지 확인하세요. 해당 팀에 전용된 러너를 보유하는 것이 가장 적합한 빌드 환경 요구 사항이 있는 팀이 있는지 확인하세요. 예상 수요를 지원하는 데 필요할 수 있는 컴퓨팅 용량을 추정하세요. 서로 다른 러너 플릿을 호스팅하기 위해 다른 인프라 스택을 선택할 수 있습니다. 예를 들어 일부 러너를 퍼블릭 클라우드에, 일부는 온프레미스에 배포해야 할 수 있습니다. 러너 플릿의 CI/CD 작업 성능은 플릿 환경과 직접 관련이 있습니다. 많은 수의 리소스 집약적인 CI/CD 작업을 실행하는 경우 공유 컴퓨팅 플랫폼에서 플릿을 호스팅하는 것은 권장되지 않습니다. 러너, 실행기, 자동 스케일링 기능 # gitlab-runner 실행 파일은 CI/CD 작업을 실행합니다. 각 러너는 작업 실행 요청을 받아 사전 정의된 구성에 따라 처리하는 격리된 프로세스입니다. 격리된 프로세스로서 각 러너는 작업을 실행하기 위해 "서브프로세스"(또는 "워커")를 만들 수 있습니다. 동시성 및 제한 # 동시성(Concurrency) : 호스트 시스템에서 구성된 모든 러너를 사용할 때 동시에 실행할 수 있는 작업 수를 설정합니다. 제한(Limit) : 러너가 동시에 작업을 실행하기 위해 만들 수 있는 서브프로세스 수를 설정합니다. 제한은 자동 스케일링 러너(Docker Machine 및 Kubernetes 등)와 자동 스케일링하지 않는 러너에서 다릅니다. 자동 스케일링하지 않는 러너에서 limit 은 호스트 시스템에서 러너의 용량을 정의합니다. 자동 스케일링 러너에서 limit 은 총 실행할 러너 수입니다. concurrency , limit , request_concurrency 가 작업 흐름을 제어하기 위해 상호 작용하는 방법에 대한 자세한 내용은 GitLab Runner 동시성 조정에 관한 KB 문서 를 참조하세요. 기본 구성: 하나의 러너 관리자, 하나의 러너 # 가장 기본적인 구성의 경우 지원되는 컴퓨팅 아키텍처와 운영 체제에 GitLab Runner 소프트웨어를 설치합니다. 예를 들어 Ubuntu