This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
ongoing @grzesiek @tmaczukin @josephburnett @ayufan @grzesiek @DarrenEastman devops verify 2022-01-19

다음 러너 자동 스케일링 아키텍처

요약

GitLab Runner는 GitLab CI/CD의 핵심 구성 요소입니다. 신뢰할 수 있고 병행적인 환경에서 CI/CD 작업을 실행할 수 있게 합니다. 2015년 초에 Kamil Trzciński에 의해 처음으로 소개되었으며, 동일한 서비스의 루비 버전을 대체하기 위해 고안되었습니다. Go로 작성된 GitLab Runner는 넓은 커뮤니티에 의해 사용하기 쉬우며, 이전의 루비 기반 버전보다 효율적이고 신뢰할 수 있음을 입증했습니다.

2016년 2월, Kamil Trzciński는 자동 스케일링 기능을 구현하여 클라우드 인프라를 활용하여 병렬로 많은 CI/CD 작업을 실행할 수 있도록 했습니다. 이 기능은 몇 년 동안 GitLab.com에서의 CI/CD 채택을 지원하는 기반이 되었으며, 현재 최대 1일 4 백만 회의 빌드를 실행합니다.

초기 구현 단계에서는 Docker Machine을 사용하기로 결정되었습니다.

사용하기 쉽다. 문서화가 잘 되어 있다. 잘 지원되며 지속적으로 확장되고 있습니다. 거의 모든 클라우드 제공자 또는 가상화 인프라를 지원합니다. Docker Machine을 지원하기 위해 최소한의 변경이 필요합니다: 기계 열거 및 검사. “클라우드 특정” 기능을 구현할 필요가 없습니다.

이러한 설계 선택은 GitLab Runner의 성공에 매우 중요했습니다. 그 이후로 자동 스케일링 기능은 많은 사용자 및 고객들에 의해 사용되어 왔으며, GitLab.com에서의 CI/CD 채택을 신속히 성장시키는 데 기여했습니다.

그러나 Docker Machine을 계속 사용할 수는 없습니다. 해당 프로젝트에 대한 작업은 2018년 7월에 중단되었으며, 그 이후로는 개발이 이루어지지 않았습니다(중요한 보안 업데이트 이외에). 2018년, Docker Machine이 “유지 보수 모드”로 전환된 후에, 사용 사례에 필요한 수정 및 업데이트를 제공하고 계속 사용하기 위해 우리만의 포크를 생성하기로 결정했습니다. 2021년 9월 26일에 해당 프로젝트가 아카이브되었으며, 해당 문서가 공식 페이지에서 삭제되었습니다. 이는 Docker Machine을 사용하는 초기 목적도 더는 유효하지 않음을 의미합니다.

우리는 고객과 넓은 커뮤니티를 계속 지원하고, SaaS 러너 유지보수를 개선하기 위해 GitLab Runner 자동 스케일링을 위한 새로운 메커니즘을 설계해야 합니다. 이는 자동 스케일링을 지원할 뿐만 아니라 효율성, 신뢰성 및 가용성을 향상시키기 위해 그 기반으로 삼을 수 있어야 합니다.

이를 “다음 GitLab Runner 스케일링 아키텍처”라고 부릅니다.

Docker Machine을 계속 사용하기

현재, 저희의 핵심 제품 중 하나인 GitLab Runner 및 그 중요한 기능 중 하나인 작업 실행 환경 자동 스케일링은 버려진 외부 제품에 의존하고 있습니다.

Docker Machine 프로젝트 자체도 관리하기 어렵습니다. 그 설계는 나이가 들어왔음을 보여주며, 이로 인해 새로운 기능과 수정 내용을 가져오기가 어렵습니다. 이것으로 인한 거대한 코드베이스와 내부 지식 부족은 우리 유지보수자들이 지원하고 들어오는 기능 요청 및 커뮤니티 기여를 적절히 처리하기 어렵게 만듭니다.

또한 Docker Machine과 통합된 20개 이상의 클라우드 및 가상화 제공자용 드라이버는 다른 일련의 문제를 야기합니다.

  • 각 클라우드/가상화 환경은 사라지고 나타나는 기능을 제공하며, 우리는 그것들에 대한 지원을 유지해야 합니다(새로운 기능 추가, 버그 수정).

  • 우리는 각각의 가상화/클라우드 제공자에 대해 전문가가 되어야만 하며, 그들의 API 통합을 적절히 지원해야 합니다.

  • Docker Machine과 통합된 각 공급자는 그들만의 버그, 보안 업데이트, 취약점을 가지고 있습니다. 프로젝트를 적절히 유지하려면 이 모든 것에 주시하고 필요할 때마다 업데이트를 처리해야 합니다.

또 다른 문제는 Docker Machine이 처음부터 Linux 기반이 인스턴스 관리에 중점을 두었던 사실입니다. 이 때문에 어느 순간부터 Docker가 공식적으로 Windows에 통합되었음에도 불구하고 Docker Machine은 이 단계를 따르지 않았습니다. 또한 MacOS를 지원하는 것 또한 아닙니다. 우리의 공식적으로 지원하는 플랫폼 중 하나인 Linux, Windows 및 MacOS 중 단 하나만이 완전히 기능을 갖춘 CI/CD 자동 스케일링을 가지고 있습니다. Windows의 경우 Kubernetes를 사용하는 가능성(특정 경우에 제한이 있음)이 있으며, 노력을 많이 기울이면 Windows에 대한 지원을 Docker Machine으로 가져올 수도 있습니다. 그러나 MacOS의 경우, GitLab Runner에서는 기본적으로 자체적인 CI/CD 자동 스케일링 솔루션이 제공되지 않습니다.

이것은 우리 사용자들과 자주 요청되는 기능에 대한 엄청난 제한입니다. 또한 SaaS 러너 제공에도 한계가 있습니다. 우리는 SaaS Windows 및 SaaS MacOS 러너의 자동 스케일링을 유지하려고 커스텀 실행자를 변경해왔습니다. 그러나 지난 3년간의 경험결과, 이것이 최선의 방법은 아니라는 것을 보여줍니다. 그리고 이 시간 이후에도 Windows 및 MacOS 러너의 자동 스케일링은 저희가 SaaS Linux 러너에서 가진 성능 및 기능 지원이 부족합니다.

우리 고객과 넓은 커뮤니티를 계속 지원하고, SaaS 러너 유지보수를 개선하기 위해 GitLab Runner 자동 스케일링을 위한 새로운 메커니즘을 설계해야 합니다. 이는 자동 스케일링을 지원할 뿐만 아니라 효율성, 신뢰성 및 가용성을 향상시키기 위해 그 기반으로 삼을 수 있어야 합니다.

제안

현재 GitLab Runner의 자동 스케일링은 몇 가지 방법으로 구성할 수 있습니다. 일부 고객은 쿠버네티스에서 자동 스케일된 환경을 성공적으로 사용하고 있습니다. 우리는 쿠버네티스에서 자동 스케일링을 더 신뢰할 수 있게 만들기 위해 사용자 정의 GitLab Runner 버전이 구축되었다는 것을 알고 있습니다. 병렬로 여러 작업을 실행하는 데에 중요한 쿠버네티스 솔루션이 가지는 중요성을 인지하고 있지만, 이러한 영역의 개선은 이 구조적 이니셔티브의 범위를 벗어나 있습니다.

우리는 Docker Machine의 문제를 해결하고, 신뢰할 수 있고 유연한 메커니즘으로 이를 대체하고자 합니다. 우리는 Docker Machine에 대체할 수 있는 것을 구축할 수 없을지도 모릅니다. 어째서 더 이상 사용되지 않게 된 이유가 분명히 많기 때문입니다. 다양한 클라우드 공급업체와의 호환성을 유지하는 것은 매우 어렵고, Docker Machine은 Docker Desktop의 대체품으로 이 존재하는 것 같지 않다는 점이 적합하지 않습니다. 이 문제는 현재 사용 중인 Docker Machine에 대한 토론을 담고 있으며, GitLab CI가 Docker Machine을 계속 사용하는 사람들 중 가장 빈번한 이유로 보입니다.

또한, 단일 대형 가상 머신에서 선택적으로 여러 작업을 실행할 수 있는 기회가 있습니다. 오늘은 그것을 할 수 없지만, 이것은 효율성을 크게 향상시킬 수 있는 가능성이 있다는 것을 알고 있습니다. 우리는 PoC(Concept-of-Proof)로 그것이 얼마나 효율적인지 테스트할 수 있는 새로운 아키텍처를 구축하고, 기존 작업 환경을 지원하고 이에 대한 효율성을 테스트할 수 있는 아키텍처를 구축하고자 합니다. 단일 머신에서 여러 작업을 실행하는 것은 “sticky context”라고 부르는 것을 재사용할 수 있게 만들어줄 수도 있습니다 - 빌드 결과물/사용자 데이터를 작업 실행 간에 공유할 수 있는 공간입니다.

💡 사용자가 더 잘 활용할 수 있는 간단한 추상화 설계

Docker Machine이 사용한 것을 추상화하는 것이 중요한 설계 요구사항입니다. 이것은 새로운 아키텍처를 구축하고, 기존의 GitLab.com에서의 작업 환경을 지원할 수 있도록 사용자가 더 잘 활용할 수 있는 간단한 추상화 설계를 원합니다.

이 설계된 메커니즘은 Docker Machine executor가 하던 작업을 추상화해야 합니다: 외부 Docker 환경을 생성하는 방법을 제공하고, 이러한 환경을 프로비저닝하고 이러한 작업을 수행하는 데 필요한 자격증명을 반환해야 합니다.

새로운 플러그인 시스템은 모든 주요 플랫폼(Linux, Windows, MacOS)에서 사용할 수 있어야 합니다.

💡 기존 Docker Machine 솔루션을 플러그인으로 이전

새로운 추상화를 설계하고 구현한 후에는 기존의 Docker Machine 메커니즘을 플러그인으로 마이그레이션할 수 있어야 합니다. 이를 통해 사용자와 고객이 새로운 아키텍처를 즉시 사용할 수 있지만, Docker Machine의 기존 워크플로 및 구성을 유지할 수 있게 해줄 것입니다. 이렇게 하면 모든 사람이 레거시 자동 스케일링을 완전히 지원 중단하기 전에 새 아키텍처로 마이그레이션할 시간을 제공할 것입니다.

💡 AWS, Google Cloud Platform 및 Azure용 플러그인 구축

Docker Machine이 지원했던 모든 클라우드 공급업체를 지원할 수 없을 수 있지만, AWS, Google Cloud Platform 및 Azure와 같은 주요 클라우드 공급업체를 위한 GitLab 유지 관리 플러그인을 제공하는 것이 중요한 것으로 보입니다.

이러한 플러그인은 아마도 별도의 저장소에서 쉽게 기여하고 포크하고 수정할 수 있게 구축되어야 합니다. 이를 통해 넓은 커뮤니티 팀원들이 필요로 하는 특정한 요구 사항을 위해 수정할 수 있게 해줄 것입니다. 또한, 새로운 플러그인을 설치할 때마다 GitLab Runner를 다시 빌드할 필요가 없도록 설치하는 것이 쉬워야 합니다.

💡 자체 플러그인 구축 방법에 대한 튼튼한 설명서 작성

사용자가 자신의 클라우드 인프라를 지원하도록 플러그인을 구축하는 방법에 대해 사용자에게 보여주는 것이 중요합니다.

새로운 플러그인을 구축하는 것은 간단하며 훌륭한 문서로 지원됩니다. 새로운 플러그인에 대한 기여의 진입 장벽이 매우 낮도록 플러그인 시스템을 설계하고자 합니다.

💡 단일 머신에서 여러 빌드를 실행하기 위한 PoC(Concept-of-Proof) 구축

단일 머신에서 여러 작업을 실행하는 것이 어떤 효율성을 가져올 수 있는지 더 잘 이해하고 싶습니다. 그것은 예측하기가 어려우므로, 이에 대한 우리의 기대를 더 잘 이해할 수 있는 PoC를 구축해야 할 것입니다.

우리가 이 실험을 실행하기 위해서는 아마도 실험적인 플러그인을 구축해야 할 것입니다. 이것은 단일 머신에서 여러 빌드를 실행할 수 있게 스케줄링할 뿐만 아니라, 이러한 빌드의 종합적인 메트릭을 내장하여 성능을 더 잘 이해하기 쉽게 만들 것입니다.

세부 정보

추상화가 어떻게 보일지는 원형 프로토타입, PoC(Concept-of-Proof) 및 데이터 기반 결정이 필요합니다. 자세히 설명하고 개발 요구사항을 개발하여 PoC를 수행하고 평가해야 합니다. 우리는 우리의 목표를 가장 잘 지원하는 솔루션을 선택할 것입니다.

우리는 제안을 설명하기 위해 현재 자동 스케일링 아키텍처 및 순서도를 조사할 필요가 있습니다.

GitLab Runner 자동 스케일링 개요

위 다이어그램에서 보듯이 현재 러너 관리자는 클라우드 공급업체 API에 액세스 할 수 있는 컴퓨터에서 실행됩니다. Docker Machine을 사용하여 Docker Engine이 설치된 새 가상 머신을 프로비저닝하고, 해당 환경에서 외부 인증된 요청을 허용하도록 Docker 데몬을 구성합니다. 이러한 일시적인 Docker 환경의 자격증명을 디스크에 저장합니다. 컴퓨터가 프로비저닝되고 러너 관리자가 빌드를 실행할 수 있도록 만들어진 후, 기존 실행자 중 하나를 사용하여 사용자가 제공한 스크립트를 실행합니다. 자동 스케일링에서 일반적으로 Docker 실행자를 사용하여 이것을 수행합니다.

관심사 분리

현재 아키텍처에는 여러 관심사가 표현되어 있습니다. 현재 구현에서는 각 관심사를 독립적으로 고려하기 위해 결합되어 있으므로 따로 분리할 것입니다.

  • 가상 머신 (VM) 구성. VM의 기본 제공 업체는 어떤 종류의 머신을 생성할지를 알기 위해 구성이 필요합니다. 예를 들어 코어, 메모리, 장애 도메인 등이 있습니다. 이 정보는 매우 제공 업체에 구체적입니다.
  • VM 라이프사이클 관리. 여러 머신이 생성되고 시스템은 이 실행기에 속하는 머신을 추적해야 합니다. 일반적으로 클라우드 제공 업체에는 동질적인 머신 집합을 관리하는 방법이 있습니다. 예를 들어 GCE 인스턴스 그룹이 있습니다. 기본적인 작업은 증가, 감소 그리고 일반적으로 특정 머신을 삭제하는 것입니다.
  • VM 오토스케일링. 저수준의 라이프사이클 관리에 더해서 작업 인식형 용량 결정이 필요하며, 필요할 때 용량을 제공하지만 비용 문제로 초과 용량을 유지하지는 않아야 합니다.
  • 작업에서 VM 매핑 (라우팅). 현재 시스템에서는 특정 머신에 작업을 하나만 할당합니다. 특정 실행기 구성에 따라 머신을 재사용할 수 있습니다.
  • VM 내 작업 실행. 각 VM 내에서 작업은 미리 정의된 여러 단계를 거쳐 실행되어야 하며 결과 및 추적 정보가 실행기 시스템으로 반환되어야 합니다. 이러한 세부 정보들은 VM 아키텍처 및 운영 체제 및 실행기 유형에 매우 의존적입니다.

아래 용어집을 참조하세요.

현재 상태

현재 아키텍처에는 여러 관심사 간의 결합점이 있습니다. 결합은 추상화 기회를 줄이며(예: 커뮤니티 지원 플러그인) 코드를 이해하기 어렵고 테스트하거나 유지, 확장하는 데 복잡성을 증가시킵니다.

주요 설계 결정 사항은 어떤 관심사를 플러그인에 외부화하고 어떤 것을 실행기 시스템에 유지할지입니다. 현재 구현에는 새로운 추상화를 위한 절단점으로 사용될 수 있는 여러 내부 추상화가 있습니다.

예를 들어 Build 유형은 dispatching 실행기 문자열에 기반하여 실행기 제공자를 가져오기 위해 GetExecutorProvider 함수를 사용합니다. 다양한 실행기 유형은 가져온 후 초기화를 위해 RegisterExecutorProvider를 호출하면서 시스템에 등록됩니다. 이곳에 추상화는 ExecutorProviderExecutor 인터페이스입니다.

docker+autoscaling 실행기 내에서 machineExecutor 유형은 공통 Prepare 단계에서 VM을 얻기 위해 사용하는 Machine 인터페이스를 가지고 있습니다. 이 추상화는 주로 VM을 생성, 접근 및 삭제합니다.

VM 오토스케일링 로직에 대한 현재 추상화는 없습니다. 이것은 VM 라이프사이클 및 작업 라우팅 로직과 강하게 결합되어 있습니다. 비활성 용량은 (machineProvider에서 Acquire를 호출하면서) 작업을 VM에 바인딩하는 사이드 이펙트로 발생합니다.

또한 VM 내 작업 실행에 대한 현재 추상화가 없습니다. VM별 명령은 관리자가 작업 실행 단계를 수행하는 동안 만들어진 후 GenerateShellScript 함수를 통해 VM에 주입됩니다.

디자인 원칙

우리의 목표는 넓은 커뮤니티가 소비하기에 유연하고 간단한 GitLab Runner 플러그인 시스템 인터페이스를 디자인하는 것입니다. 우리는 모든 클라우드 플랫폼에 대해 플러그인을 구축할 수 없기 때문에 플러그인을 개발해야 하는 사람들에 대한 진입 장벽을 낮추기를 원합니다. 누구나 기여할 수 있도록 하고 싶습니다.

이러한 목표를 달성하기 위해 우리는 몇 가지 중요한 디자인 원칙을 준수할 것입니다. 이러한 원칙은 새로운 플러그인 시스템 추상화의 개발 프로세스를 안내할 것입니다.

일반 고수준 원칙

  • 미래에 더 많은 선택지와 유연성을 갖기 위해 새로운 오토 스케일링 아키텍처를 설계합니다. 새로운 제약 조건을 부과하는 대신.
  • 단일 기계에서 병렬로 여러 작업을 실행하는 실험을 위해 새로운 오토 스케일링 아키텍처를 설계합니다.
  • Docker Machine을 대체하기 위한 새로운 프로비저닝 아키텍처를 설계합니다. 이를 통해 넓은 커뮤니티가 새로운 추상화 위에 쉽게 빌드할 수 있도록 합니다.
  • 새로운 오토 스케일링 방법은 GitLab Runner 제품의 핵심 구성 요소가 되어야 하므로 유지 관리를 단순화하고 다른 주요 제품들에서 하는 것과 동일한 도구, 테스트 구성 및 Go 언어 설정을 사용할 수 있어야 합니다.
  • Linux 운영 체제에서 Docker 컨테이너뿐만 아니라 여러 작업 실행 환경을 지원해야 합니다.

    최상의 디자인은 현재의 실행기(예: Docker 또는 셸) 주변으로 오토 스케일링을 가져 오는 것입니다.

새로운 플러그인 시스템의 원칙

  • 새로운 플러그인을 작성하는 진입 장벽을 낮춥니다.
  • 새로운 플러그인을 개발하는 것은 프로그래밍 언어와 클라우드 공급업체 API의 기본 지식만 있으면 간단해야 합니다.
  • 플러그인 시스템의 간단함과 유연성 사이의 균형을 추구합니다. 이 둘은 서로 배타적이지 않아야 합니다.
  • 가능한 기술적인 세부 사항을 추상화하지만 완전히 숨기지는 않습니다.
  • 커뮤니티에 유용한 추상화를 구축하지만 신속하게 배포할 수 있는 여지를 남깁니다.
  • 유연한 솔루션에 투자하고 단방향 문을 피하며 반복을 유도합니다.
  • 의심스러울 때는 넓은 커뮤니티를 위해 더 간단하게 만드는 쪽으로 결정합니다.
  • 시스템을 더 간단하고 확장 가능하게 만들기 위해 관심사 간의 결합을 제한합니다.
  • 관심사는 플러그 또는 다른 중 하나에 위치해야 하며, 노력을 중복시키고 결합을 증가시키는 것을 방지해야 합니다.

가장 중요한 기술적인 세부 사항

  • 플러그인과 GitLab Runner 간의 gRPC 통신을 선호합니다.
  • 통신 인터페이스를 버전화하고 여러 버전을 지원할 수 있도록 합니다.
  • Go를 주요 언어로 플러그인을 작성할 수 있도록 만듭니다. 다른 언어도 허용합니다.
  • 오토 스케일링 메커니즘은 GitLab이 완전히 소유해야 합니다.

    클라우드 제공업체의 오토 스케일러는 축소할 때 어떤 가상 머신을 삭제해야 하는지 모르기 때문에 최적의 결정을 내릴 수 없습니다. 모든 오토 스케일러에게 GitLab 작업에 대해 가르치는 대신 한 개의 GitLab 소유 오토 스케일러(플러그인이 아닌)를 가지는 것을 선호합니다.

    이는 또한 우리가 메커니즘의 미래를 형성하고 우리의 요구 사항에 부합하는 결정을 할 수 있도록 보장할 것입니다.

플러그인 영역 제안

다음은 플러그인 경계를 어디에 그을지에 대한 제안입니다. 이러한 제안과 기술적인 제약 사항은 위에서 설명한 디자인 원칙에 따라 평가할 것입니다.

커스텀 프로바이더

작업 범위를 줄이기 위해 새로운 추상화 계층을 한 곳에만 도입하고 싶습니다.

몇 년 전에 GitLab Runner에서 Custom Executor 기능을 소개했습니다. 이를 통해 사용자는 사용자 정의 빌드 실행 방법을 설계할 수 있습니다. 커스텀 실행기 드라이버는 단순한 셸 스크립트에서부터 특정 이진 파일까지 원하는 방법으로 구현할 수 있으며, 그런 후에 Runner가 os/exec 시스템 호출을 통해 사용합니다.

커스텀 실행기 추상화 덕분에 Runner 내부에서 새로운 실행기를 구현할 필요가 더 이상 없어졌습니다. 특정한 요구 사항을 가진 사용자는 자신만의 드라이버를 구현할 수 있고, 우리가 그들의 작업을 “공식” GitLab Runner의 일부로 만들기를 기다릴 필요가 없어집니다. 각 드라이버가 별도의 프로젝트이므로 관심 있는 사람들이 함께 개선하고 버그를 수정할 수 있도록 하는 것을 더 쉽게 만들어줍니다.

우리는 새로운 커스텀 프로바이더를 커스텀 실행기의 성공을 복제하도록 디자인하고 싶습니다. 이것은 사용자들이 빌드를 실행할 환경과 콘텍스트를 제공하는 자신만의 방법을 만드는 것을 쉽게 할 것입니다.

커스텀 프로바이더 추상화를 구현하는 여러 가지 솔루션이 있습니다. 우리는 원하는 최상의 솔루션을 선택하고 싶어합니다. 이를 위해 별도의 문서에 솔루션을 설명하고 요구 사항을 정의하고 해당 솔루션에 점수를 매길 것입니다. 이를 통해 우리와 넓은 커뮤니티에 가장 잘 맞는 솔루션을 선택할 수 있을 것입니다.

이 제안은 VM 라이프사이클, 오토 스케일링 관련 사항, 작업을 VM에 매핑(라우팅)하는 것을 플러그인에 위치시킵니다. 빌드는 VM을 요청하기만 하면 플러그인이 이미 모든 라이프 사이클 및 라우팅 측면을 고려한 VM을 받게 됩니다.

근거: 커스텀 실행기 프로바이더 제안 설명

Taskscaler 제공자

우리는 “Fleeting” 인터페이스 형태로 Machine 추상화의 더 간단한 버전을 소개할 수 있습니다. Fleeting은 동질적인 VM 그룹에 대한 저수준 인터페이스를 제공하며, 그룹 크기를 증가시키고 감소시키며, 그룹 내에서 VM을 사용할 수 있게 합니다.

클라우드 제공업체 및 다른 VM 소스에 대한 플러그인은 HashiCorp go-plugin 라이브러리를 통해 구현됩니다. 이는 실제로는 STDIN/STDOUT을 통한 gRPC이지만 다른 와이어 프로토콜도 사용할 수 있습니다.

새 인터페이스를 활용하기 위해 오토스케일링 논리는 도커 실행기(Docker Executor)에서 분리되어 새로운 Taskscaler 라이브러리에 배치됩니다.

이로써 VM 라이프사이클, VM 모양 및 작업 라우팅이 플러그인 안으로 이동합니다. 또한 VM 오토스케일링 관련 관심사를 별도의 구성 요소로 놓아, docker+autoscaling뿐만 아니라 여러 Runner Executor에서 사용할 수 있게 됩니다.

근거: InstanceGroup / Fleeting 제안 설명 POC: 병합 요청

용어 해설

  • GitLab Runner - 설치 및 관리 선택이 가능한 소프트웨어 응용 프로그램으로, 소스 코드는 gitlab.com/gitlab-org/gitlab-runner에 호스팅됩니다.
  • runners - 러너는 GitLab CI/CD 작업을 실행하고 결과를 GitLab 인스턴스에 보고하는 대리자입니다. /1/ GitLab에서 작업을 검색하고, /2/ 로컬 또는 원격 빌드 환경을 구성하고, /3/ 제공된 환경에서 작업을 실행하며 로그 데이터 및 상태 업데이트를 GitLab으로 전달합니다.
  • 러너 관리자 - 러너 프로세스는 종종 Runner Manager로 지칭되며, 러너의 config.toml 파일에 정의된 [[runners]] 워커를 관리합니다.
  • 실행기 - 작업을 준비하고 실행할 수 있는 구체적인 환경입니다. 각 작업마다 새 실행기가 생성됩니다.
  • 실행기 제공자 - 요청에 따라 실행기를 제공할 수 있는 구현입니다. 실행기 제공자는 가져올 때 등록되며, 러너가 시작될 때 한 번 초기화됩니다.
  • 사용자 정의 실행기 - GitLab Runner 코드베이스를 변경하지 않고 시스템에 새로운 사용자 정의 실행기를 추가할 수 있도록 하는 새로운 추상화입니다. 이 실행기는 환경 변수 입력으로 이루어진 이진 파일이나 셸 스크립트들과 GitLab Runner 간의 인터페이스로 작동합니다.
  • 사용자 정의 실행기 제공자 - 위의 플러그인 경계 제안 섹션의 사용자 정의 제공자 제목 아래 제안된 새로운 추상화로, GitLab Runner 코드베이스를 수정하지 않고 새 실행기 제공자를 생성할 수 있게 합니다. 프로토콜은 사용자 정의 실행기와 유사하거나 gRPC를 통해 이루어질 수 있습니다. 이 추상화는 플러그인 내에서 실행기 생성의 모든 매커니즘을 배치하여, 각 구현에 대한 오토스케일링 및 라이프사이클 관리 관심사를 위임합니다.
  • taskscaler - 위의 플러그인 경계 제안 섹션의 taskscaler 제공자 제목 아래 제안된 새 라이브러리로, 구체적인 실행기 제공자와 fleeting 제공자로 매개변수화됩니다. Taskscaler는 오토스케일링 관련 관심사를 담당하며, 모든 VM 모양을 사용하여 모든 실행기 제공자에 대해 오토스케일링을 할 수 있습니다. Taskscaler는 또한 VM 라이프사이클에 대한 러너별 측면에 대한 책임과 하나의 VM을 사용하는 작업 수 및 VM이 사용된 횟수 등을 추적합니다.
  • fleeting - taskscaler와 함께 제안된 새로운 라이브러리로, 클라우드 제공업체 VM에 대한 추상화를 제공합니다.
  • 일시적 인스턴스 그룹 - 일시적이 사용되는 VM 그룹을 나타내기 위해 fleeting이 사용하는 추상화입니다. 이는 GCP IGM 또는 AWS ASG(오토스케일링 없음)를 나타낼 것입니다. 인스턴스 그룹은 증가, 감소하거나 특정 VM의 연결 세부 정보를 제공할 수 있습니다.
  • fleeting 플러그인 - 특정 IGM 또는 ASG를 나타내는 일시적 인스턴스 그룹의 구체적인 구현(초기화된 경우)입니다. 각 제공업체별로 N개의 이러한 플러그인이 있으며, 각 플러그인은 별도의 프로젝트에 속합니다. 우리는 핵심 부분을 소유하고 유지관리하지만, 일부는 커뮤니티에서 지원받을 것입니다. 새로운 fleeting 플러그인은 러너, taskscaler 또는 fleeting 코드베이스를 변경하지 않고도 생성할 수 있습니다. 이것은 서비스 제공 및 분리에 관한 사용자 정의 실행기 제공자와 유사한 방식으로, 다른 관심사에 따른 것입니다.
  • fleeting 플러그인 Google Compute - GCP 인스턴스를 생성하는 fleeting 플러그인으로, fleeting과 taskscaler와는 별도의 프로젝트에서 운영됩니다.
  • fleeting 플러그인 AWS - AWS 인스턴스를 생성하는 fleeting 플러그인으로, fleeting과 taskscaler와는 별도의 프로젝트에서 운영됩니다.

상태

상태: RFC.

누구를 위한 것인가

제안:

역할 누구
저자 Grzegorz Bizon, Tomasz Maczukin, Joseph Burnett
아키텍처 진화 코치 Kamil Trzciński
엔지니어링 리더 Elliot Rushton, Cheryl Li
제품 매니저 Darren Eastman, Jackie Porter
도메인 전문가 / 러너 Arran Walker

DRIs(Directly Responsible Individuals):

역할 누구
리더십 Elliot Rushton
제품 Darren Eastman
엔지니어링 Tomasz Maczukin

도메인 전문가:

영역 누구
도메인 전문가 / 러너 Arran Walker