• 요약
  • 💡 기존 Docker Machine 솔루션을 플러그인으로 이관
  • 💡 AWS, Google Cloud Platform 및 Azure용 플러그인 빌드
  • 💡 자체 플러그인을 빌드하는 방법에 대한 강력한 문서 작성
  • 💡 단일 머신에서 여러 빌드 실행하는 PoC 빌드
• 세부 정보
  • 디자인 원칙
    • 일반적인 고수준 원칙
    • 새로운 플러그인 시스템 원칙
    • 가장 중요한 기술적 세부 사항
• 플러그인 경계 제안
  • 사용자 정의 공급자
  • Taskscaler 공급자
• 용어집
• 상태
• 누가

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

요약

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 도입을 지원하는 기반이 되었으며, 현재 우리는 최대 하루에 약 4백만 빌드를 실행하고 있습니다.

초기 구현 시에 Docker Machine을 사용하기로 결정하였습니다.

…

지원되어야 합니다. ```

…

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

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

💡 AWS, Google Cloud Platform 및 Azure용 플러그인 빌드

Docker Machine이 지원했던 모든 클라우드 제공업체를 지원하는 것은 어려울 수 있지만, AWS, Google Cloud Platform 및 Azure와 같은 주요 클라우드 제공업체를 위해 GitLab에서 유지보수하는 플러그인을 제공하는 것이 중요해 보입니다.

우리는 이를 빌드해야 하며, 아마도 별도의 리포지터리에서 개발하여 넓은 커뮤니티 팀원들이 기여하거나 특정 필요에 맞게 수정하기 쉽도록 해야 합니다. 또한 새로운 플러그인을 설치할 때마다 GitLab Runner를 다시 빌드할 필요 없이 간편하게 설치할 수 있는 방법이어야 합니다.

💡 자체 플러그인을 빌드하는 방법에 대한 강력한 문서 작성

사용자들이 자체 클라우드 인프라를 지원하기 위해 플러그인을 어떻게 작성할지 보여주는 것이 중요합니다.

새로운 플러그인을 작성하는 것은 간편하며 훌륭한 문서로 지원되어야 합니다. 기여하는 새로운 플러그인의 진입 장벽을 매우 낮게 설계하고자 합니다.

💡 단일 머신에서 여러 빌드 실행하는 PoC 빌드

단일 머신에서 여러 작업을 실행하는 데 어떤 효율성을 기대할 수 있는지에 대한 더 나은 이해를 원합니다. 이것을 예측하기 어려우므로, 이에 대한 기대 효과를 더 잘 이해하기 위한 PoC를 구축하는 것이 이상적입니다.

이 실험을 실행하기 위해서는 아마도 실험적인 플러그인을 빌드해야 할 것입니다. 이 플러그인은 단일 머신에서 여러 빌드를 실행할 수 있을 뿐만 아니라 성능을 더 잘 이해할 수 있도록 포괄적인 메트릭 세트를 갖추어야 할 것입니다.

세부 정보

정확히 어떻게 추상화가 보일지는 프로토타입을 만들고 PoC를 통해 데이터 기반으로 결정해야 할 사항입니다. 우리가 자세히 설명하고, 요구 사항을 개발하고, PoC를 수행하고 점수를 매길 몇 가지 제안이 있습니다. 우리는 가장 많이 목표를 지원하는 것으로 보이는 솔루션을 선택할 것입니다.

제안을 설명하기 위해 먼저 GitLab Runner의 어떤 부분을 추상화해야 하는지 더 잘 설명해야 합니다. 이러한 개념을 더 쉽게 이해하기 위해 현재의 오토 스케일링 아키텍처와 순서도를 살펴보겠습니다.

위 다이어그램에서 현재 러너 관리자가 클라우드 제공자의 API에 액세스하는 머신에서 실행되는 것을 볼 수 있습니다. 이는 Docker Machine을 사용하여 Docker Engine이 설치된 새 가상 머신을 프로비저닝하고, 거기에서 Docker 데몬을 구성하여 외부 인증된 요청을 허용합니다. 그러한 짧은 수명의 Docker 환경에 대한 자격 증명을 디스크에 저장합니다. 머신이 프로비저닝되고 러너 관리자가 빌드를 실행하는 데 사용할 수 있게 되면, 기존의 실행기 중 하나를 사용하여 사용자가 제공한 스크립트를 실행합니다. 오토 스케일링에서는 일반적으로 Docker 실행기를 사용하여 이 작업이 수행됩니다.

디자인 원칙

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

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

일반적인 고수준 원칙

• 새로운 자동 스케일링 아키텍처를 디자인할 때, 미래에 더 많은 선택과 유연성을 갖는 것을 목표로 하여 새로운 제약조건을 부여하는 대신에 디자인합니다.
• 새로운 자동 스케일링 아키텍처를 디자인할 때, 하나의 머신에서 여러 작업을 병렬로 실행하는 실험을 수행합니다.
• 새로운 프로비저닝 아키텍처를 디자인하여 Docker Machine을 대체하는 것은 넓은 커뮤니티가 새로운 추상화 위에 쉽게 빌드할 수 있도록 합니다.
• 새로운 자동 스케일링 방법은 GitLab Runner 제품의 핵심 컴포넌트가 되어야 하여 유지 보수를 간소화하고, 다른 주요 제품들에서 하는 것과 동일한 도구 지원, 테스트 구성 및 Go 언어 설정을 사용할 수 있도록 합니다.

• 이것은 리눅스 운영 체제의 Docker 컨테이너만이 아닌 여러 작업 실행 환경을 지원해야 합니다.

  최상의 디자인은 현재의 실행자인 Docker 또는 Shell 주변의 기능으로 자동 확장을 가져오는 것입니다.

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

• 새 플러그인을 작성하기 위한 진입 장벽을 낮춥니다.
• 새로운 플러그인을 개발하는 것은 프로그래밍 언어와 클라우드 공급자의 API에 대한 기본 지식만 있으면 간단해야 합니다.
• 플러그인 시스템의 단순성과 유연성 사이의 균형을 추구합니다. 이러한 것들은 서로 배타적이지 않습니다.
• 가능한 기술적 세부 사항을 추상화하지만 완전히 숨겨서는 안됩니다.
• 우리 커뮤니티에 유용한 추상화를 구축하지만 빠르게 출시할 수 있도록 허용합니다.
• 유연한 솔루션에 투자하고, 단방향 결정을 피하며, 이터레이션을 촉진합니다.
• 의심스러울 때, 넓은 커뮤니티를 위해 더 간단하게 만드는 것에 쪽을 기울입니다.
• 시스템을 더 단순하고 확장 가능하게 만들기 위해 관련성 결합을 제한합니다.
• 고민거리는 플러그인의 한 쪽에만 살아야 하며, 노력의 중복을 줄이고 관련성을 증가시키지 않아야 합니다.

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

• 플러그인과 GitLab Runner 간의 gRPC 통신을 선호합니다.
• 통신 인터페이스의 버전을 지원하고, 다양한 버전을 지원할 수 있도록 합니다.
• 플러그인을 작성하기 위해 Go를 주요 언어로 만들지만, 다른 언어도 허용합니다.

• 자동 스케일링 메커니즘은 GitLab이 완전히 소유해야 합니다.

  클라우드 공급자의 자동 확장기는 축소할 때 어떤 VM을 삭제해야 하는지 알지 못하여 최적의 결정을 내릴 수 없습니다. GitLab 작업에 대해 모든 자동 확장기에 가르치는 대신에 GitLab 소유의 자동 확장기를 가지기를 선호합니다(플러그인에는 없음).

  또한 우리가 필요로 하는 것과 요구 사항을 적합하게 만들 수 있도록 기술의 미래를 설계하고 결정할 수 있도록 합니다.

플러그인 경계 제안

다음은 플러그인 경계를 어디에 그을지에 대한 제안입니다. 이러한 제안들과 다른 것들을 위에 나열된 디자인 원칙과 기술적 제약에 따라 평가할 것입니다.

사용자 정의 공급자

작업 범위를 줄이기 위해 GitLab Runner에서 새로운 추상화 계층을 도입하려고 합니다.

몇 년 전에 GitLab Runner에서 사용자 정의 실행자 기능을 도입했습니다. 사용자는 사용자 정의 빌드 실행 방법을 설계할 수 있도록 합니다. 사용자 정의 실행자 드라이버는 단순한 셸 스크립트에서 특정 이진 파일까지 여러 방식으로 구현될 수 있으며, 그런 다음 os/exec 시스템 호출을 통해 Runner에 의해 사용됩니다.

사용자 정의 실행자 추상화로 인해 이제 Runner 내부에서 새로운 실행자를 구현할 필요가 없어졌습니다. 특정 요구사항을 갖는 사용자는 자신만의 드라이버를 구현하고, 우리가 그것을 “공식” GitLab Runner의 일부로 만드는 것을 기다릴 필요가 없어졌습니다. 각 드라이버가 별도의 프로젝트이기 때문에, 관련된 사람들이 함께 개선하고 버그를 수정하는 커뮤니티를 만드는 것이 더 쉬워졌습니다.

새로운 사용자 정의 공급자를 디자인하여 사용자가 자신만의 방법으로 컨텍스트 및 실행 환경을 제공할 수 있는 작업하는 것의 성공을 복제할 수 있게 되었습니다.

사용자 정의 공급자 추상화를 구현하기 위한 여러 가지 솔루션이 있습니다. 우리는 원시 Go 플러그인, HashiCorp의 Go 플러그인, HTTP 인터페이스 또는 gRPC 기반 파사드 서비스를 사용할 수 있습니다. 여러 가지 솔루션이 있으며, 우리는 최적의 것을 선택하고자 합니다. 이를 위해 우리는 별도의 문서에 솔루션을 설명하고, 요구사항을 정의하고, 해당 솔루션을 점수화할 것입니다. 이를 통해 우리는 우리와 넓은 커뮤니티에 가장 적합한 솔루션을 선택할 수 있게 될 것입니다.

이 제안은 VM 수명주기 및 자동 스케일링에 대한 고민이 플러그인으로 들어가도록 하는 것, 그리고 빌드는 단순히 VM을 요구하면 플러그인이 이미 VM의 모든 측면에 대한 수명주기 및 라우팅을 고려하고 나머지 작업을 해결하게 됩니다.

이유: 사용자 정의 실행자 공급자 제안 설명서

Taskscaler 공급자

더 간단한 ‘Machine’ 추상화의 형태인 “Fleeting” 인터페이스의 더 단순한 버전을 도입할 수 있습니다. Fleeting은 동질적인 VM 그룹에 대한 저수준 인터페이스를 제공하여 집합 크기를 늘리고 줄일 수 있으며, 집합 내에서 VM을 사용할 수 있도록 합니다.

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

새로운 인터페이스를 사용하기 위해서는 자동 스케일링 로직이 Docker 실행자에서 빠져 나와 새로운 Taskscaler 라이브러리에 넣어야 합니다.

이것은 플러그인 내에 VM 수명주기, VM 형태 및 작업 라우팅에 대한 고민을 두고 있습니다. 또한 VM 자동 확장에 대한 고민을 별도의 컴포넌트로 배치하여 ‘docker+자동 스케일링’이 아닌, 여러 Runner 실행자에서 사용할 수 있도록 합니다.

이유: 인스턴스 그룹 / 일시적 인터페이스 제안 설명서 POC: Merge request

용어집

• GitLab Runner - 설치하고 관리할 수 있는 소프트웨어 응용 프로그램으로, 소스 코드가 gitlab.com/gitlab-org/gitlab-runner에 호스팅됩니다.
• runners - Runner는 환경에서 GitLab CI/CD 작업을 실행하고 결과를 GitLab 인스턴스에 보고하는 에이전트입니다. 이는 1), GitLab에서 작업을 검색하고, 2) 로컬 또는 원격 빌드 환경을 구성하고, 3) 생성된 환경에서 작업을 실행하여 로그 데이터 및 상태 업데이트를 GitLab에 전달합니다.
• runner manager - Runner 프로세스는 Runner Manager로 자주 언급되며, Runner의 config.toml 파일에 정의된 [[runners]] 워커를 관리합니다.
• executor - 작업을 실행하고 사용할 수 있는 구체적인 환경. 각 작업에 대해 새로운 실행자가 생성됩니다.
• executor provider - 요청에 따라 실행자를 제공할 수 있는 구현체. Executor providers는 가져올 때 등록되고, Runner 시작 시에 한 번만 초기화됩니다.
• custom executor - GitLab Runner와 환경 변수 입력을 사용하여 이진 파일 또는 셸 스크립트 집합 사이의 인터페이스로 작동하여 어떤 호스트 컴퓨팅 환경에서 CI 작업을 실행할 수 있게 합니다. 새로운 사용자 정의 실행자는 GitLab Runner 코드베이스를 변경하지 않고 시스템에 추가할 수 있습니다.
• custom executor provider - 플러그인 경계 제안 섹션에서의 사용자 정의 공급자 하단에 제안된 새로운 추상화로, GitLab Runner 코드베이스를 수정하지 않고 새 실행자 공급자를 만들 수 있도록 합니다. 프로토콜은 사용자 정의 실행자와 유사하거나 gRPC를 통해 수행될 수 있습니다. 이 추상화는 플러그인 내에서 실행자 프로덕션의 모든 기계적인 면을 두며, 자동 스케일링 및 수명주기 관리 고민을 각 구현에 위임합니다.
• taskscaler - 플러그인 경계 제안 섹션에서 제안된 새 라이브러리로, 구체적 실행자 공급자와 일시적 공급자를 매개변수화합니다. Taskscaler는 자동 스케일링에 대한 고민을 담당하고, 어떤 VM 모양을 사용하여도 모든 실행자 공급자를 자동 조정할 수 있습니다. Taskscaler는 또한 VM 수명주기의 Runner 특정 측면을 담당하며, 특정 VM이 얼마나 많이 사용되었는지와 VM이 사용된 횟수를 추적합니다.
• fleeting - taskscaler와 함께 제안된 새 라이브러리로, 클라우드 프로바이더 VM에 대한 추상화를 제공합니다.
• fleeting instance group - 일시적인 인터페이스가 동일한 VM의 풀을 나타내기 위해 사용하는 추상화입니다. 이는 GCP IGM이나 AWS ASG(자동 확장 없이)를 나타낼 것입니다. 인스턴스 그룹은 증가, 감소할 수도 있고, 특정 VM의 연결 세부 정보를 제공할 수 있습니다.
• fleeting plugin - 특정 IGM이나 ASG(초기화 된 상태)를 나타내는 일시적인 인스턴스 그룹의 구현체입니다. 이것은 각자의 프로젝트에 N개가 있으며, 핵심적인 것은 유지보수를 할 것이고 일부는 커뮤니티에서 지원받을 것입니다. 새로운 일시적 플러그인은 Runner, taskscaler 또는 fleeting 코드베이스를 수정하지 않고 생성될 수 있습니다. 이것은 자급자족과 decoupling 측면에서 사용자 정의 실행자 공급자와 유사하게 생성되지만,

상태

Status: RFC.

누가

제안:

DRIs:

도메인 전문가들: