| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed | - |
이 문서는 작업 중인 상태이며 매우 초기의 Cells 설계 상태를 나타냅니다. 중요한 측면들이 문서화되지 않았지만, 미래에 추가할 것으로 예상됩니다. 이것은 Cells를 위한 하나의 가능한 아키텍처이며, 우리는 이 접근 방법을 구현하기 전에 대안과 대조할 것을 의도하고 있습니다. 이 문서는 이 접근 방법을 선택하지 않기로 결정했을 때 그 이유를 문서로 남겨둘 것입니다.
Cells: CI Runners
GitLab은 GitLab Runner를 통해 CI 작업을 실행하며, 이는 매우 자주 고객들의 인프라에서 관리됩니다. CI 파이프라인의 일부로 생성된 모든 CI 작업은 프로젝트의 컨텍스트에서 실행됩니다. 이는 GitLab 러너를 어떻게 관리해야 하는지에 대한 도전 과제를 제기합니다.
1. 정의
3가지 유형의 러너가 있습니다:
- 인스턴스 전역: 특정 태그(선택 기준)로 전역적으로 등록된 러너
- 그룹 러너: 특정 최상위 그룹이나 해당 그룹 내 프로젝트에서 작업을 실행하는 러너
- 프로젝트 러너: 하나 이상의 프로젝트에서 작업을 실행하는 러너. 일부 러너는 다른 최상위 그룹의 프로젝트에서 할당된 프로젝트를 보유할 수 있습니다.
이러한 점과 기존의 ci_runners가 모든 유형의 러너를 설명하는 테이블인 데이터 구조는 Cells 환경에서 ci_runners를 어떻게 관리해야 하는지에 대한 도전 과제를 제기합니다.
2. 데이터 흐름
GitLab 러너는 전역으로 범위가 지정된 여러 엔드포인트를 사용하여 다음을 수행합니다:
-
https://gitlab.com/api/v4/runners를 통해 등록 토큰(registration token)을 통해 새로운 러너를 등록 - 사용자 컨텍스트에서 새로운 러너를 생성하는
https://gitlab.com/api/v4/user/runners(runner token) - 인증된
https://gitlab.com/api/v4/jobs/request엔드포인트를 통해 작업 요청 -
https://gitlab.com/api/v4/jobs/:job_id를 통해 작업 상태 업로드(build token) -
https://gitlab.com/api/v4/jobs/:job_id/trace를 통해 추적 업로드(build token) -
https://gitlab.com/api/v4/jobs/:job_id/artifacts를 통해 아티팩트 다운로드 및 업로드(build token)
현재 3가지 유형의 인증 토큰이 사용됩니다:
- 러너 등록 토큰
- 특정 구성을 가진 시스템에서 등록된 러너를 나타내는 러너 토큰(
tags,locked등 포함) - 특정 작업을 업데이트하거나 제한적인 액세스 권한을 부여하는 짧은 수명의 빌드 토큰
이러한 엔드포인트 각각은 헤더를 통해 인증 토큰을 수신합니다 (/trace의 경우 JOB-TOKEN, 다른 모든 엔드포인트의 경우 token).
CI 파이프라인이 특정 Cell의 컨텍스트에서 생성되므로 특정 Cell에서 빌드를 선택해야 합니다. 이로 인해 솔루션에 따라 빌드 선택을 처리해야 하는 필요성이 있습니다.
- 첫 번째로 올바른 Cell로 라우팅
- 전역 풀에서 빌드 요청, 특정 Cell에서 Cell별 URL을 사용하여 빌드를 요청하고 가져오기
3. 제안
3.1. 인증 토큰
CI 러너의 경로가 라우팅되지는 않지만, 이들을 라우팅할 수 있는 2가지 가능한 솔루션 방안이 있습니다:
-
https://gitlab.com/api/v4/jobs/request는 긴 폴링 메커니즘을 사용하여 티켓팅 메커니즘(기반X-GitLab-Last-Update헤더)을 사용합니다. 러너가 처음 시작되면, GitLab에 요청을 보내고 GitLab은 러너가 가져갈 빌드 또는204 No job와last_update토큰 중 하나를 응답합니다. 이 값은 GitLab이 완전히 제어합니다. 이를 통해 GitLab은cell식별자를 인코딩할 수 있는 JWT 또는 기타 수단을 사용하여 Router가 쉽게 디코딩할 수 있는 토큰을 인코딩할 수 있습니다. - (볼륨 측면에서) 대부분의 통신은
build token을 사용하며, 러너가 나중에 특정 작업에 대해 사용하는 토큰의 소유자인 GitLab이 변경하기 가장 쉬운 대상이 됩니다.build token을 저장하지 않고 정의된 스코프를 가진JWT토큰을 사용하는 것에 대한 이전 토론이 있었습니다. 그러한 토큰은 Router가 모든 요청을 라우팅할 수 있도록 디코딩할 수 있는 더 강력한 방법을 제공할 수 있습니다.
3.2. 요청 본문
이 문장은 더 이상 사실이 아닙니다:
가장 많이 사용되는 엔드포인트는 요청 본문에 인증 토큰을 전달합니다. 요청을 프록시하지 않고 Router가 이 정보에 쉽게 액세스하기 위해 HTTP 헤더를 사용하는 것이 원하는 경우일 수 있습니다.
러너(runner) 토큰을 헤더에 추가된 MR로 모든 요청에서 러너는 이제 HTTP 헤더에 토큰을 전송합니다.
3.3. 인스턴스 전역은 Cell로 지역화됨
모든 러너가 항상 주어진 Cell에 로컬로 등록되고 있는 디자인을 선택할 수 있습니다:
- 각 Cell은 자체 인스턴스 전역 러너 세트를 자체적으로 업데이트합니다.
- 프로젝트 러너는 동일한 조직의 프로젝트에만 연결될 수 있으며 강력한 격리 환경을 만듭니다.
- 이 모델에서
ci_runners테이블은 Cell에 지역적입니다. - 이 모델에서 위 엔드포인트들은 어떤 방식으로든 Cell에 스코프가 지정되어야 하거나 라우팅될 수 있어야 합니다. 이는 prefixing, 추가 Cell 매개변수 추가 또는 러너 토큰을 디코딩하고 Cell에 일치시키는 훨씬 더 견고한 방법을 제공하는 것일 수 있습니다.
- 라우터가 모든 요청을 라우팅할 수 있도록 라우팅 가능한 토큰을 사용하면 데이터베이스에 저장된 암호화 무작위보다는 JWT 토큰을 사용하는 것이 선호될 수 있습니다.
- 등록된 러너를 보여주는 관리 영역은 Cell에 스코프가 지정되어야 합니다.
이 모델은 강력한 격리 보장을 제공하기 때문에 원하는 모델일 수 있습니다. 그러나 각 Cell은 별도로 관리되기 때문에 유지보수 부담이 상당히 증가합니다. 이 모델은 프로젝트가 Cell 간에 일관된 러너 경험을 가질 수 있도록 runner 태그 기능을 조정해야 할 수도 있습니다.
3.4. 인스턴스 전역은 클러스터 전역
모든 러너가 Cell로 지역화되어 있는 제안과 대조적으로, 모든 러너가 전역 또는 인스턴스 전역 러너만 전역으로 고려할 수 있습니다.
그러나 이를 위해 시스템을 상당한 탈바꿈해야 하며, 다음과 같은 측면을 변경해야 합니다:
-
ci_runners테이블을ci_instance_runners등으로 분해해야 합니다. - 모든 인터페이스가 올바른 테이블을 사용하도록 적용해야 합니다.
- 빌드 대기열 구조를 변경하여, 각 Cell이 모든 대기 중 및 실행 중인 빌드를 알고 있지만 빌드의 실제 클레임은 데이터를 가지는 Cell에 의해 발생될 것입니다.
-
ci_pending_builds및ci_running_builds를클러스터 전역테이블로 만들어야 하며, 이로 인해 CI 대기열과 관련된 시스템에서 핫스pod을 만드는 가능성이 높아집니다.
이 모델은 공학적 관점에서 구현하기 복잡합니다. Cell 간에 데이터가 공유됩니다. 남은 몇몇 에러들은 다른 Cells의 조직 경험에 영향을 줄 수 있어, 시스템에서 핫스pod 및 확장성 문제가 발생합니다.
3.5. GitLab CI 데몬
탐구할 수 있는 또 다른 잠재적인 솔루션은 빌드 대기열에 책임을 지고, 자체 데이터베이스를 소유하고 또는 샤딩 또는 Cell된 서비스 모델에서 작동하는 전용 서비스를 가지는 것입니다. CI/CD Daemon에 대해 이전 토론이 있었습니다.
서비스가 샤딩된 경우:
- 모델에 따라, 러너가 클러스터 전역 또는 Cell 로컬인 경우, 이 서비스는 모든 Cell에서 데이터를 가져와야 합니다.
- 서비스와 함께 사용하는
ci_pending_builds/ci_running_builds를 포함하는 데이터베이스를 공유하는 모델을 채택할 수 있습니다. - 각 Cell이 가져가야 할 작업을 CI/CD 데몬에 푸시할 수 있는 푸시 모델을 고려해볼 수 있습니다.
- 샤딩된 서비스는 주어진 빌드를 처리할 책임 있는 Cell을 인식하고 지정된 Cell로 작업을 라우팅할 수 있습니다.
서비스가 Cell-ed인 경우:
- 라우팅 가능한 엔드포인트에 대한 모든 기대사항은 여전히 유효합니다.
일반적으로 CI 데몬의 사용은 명시된 문제에 대해 큰 도움이 되지는 않습니다. 그러나 이견은 관련된 몇 가지 장점을 제공합니다: 효율적인 처리 및 결합 모델에 대한 가능성, 푸시 모델 및 GitLab 러너와의 상태 있는 통신 제공 가능(ex. gRPC 또는 웹소켓).
4. 평가
모든 옵션을 고려해본 결과, 가장 유망한 솔루션은 다음과 같습니다:
- 인스턴스 전체 또는 셀 내부 사용
- 엔드포인트를 더 정교하게 조정하여 라우터 식별자를 갖게 함(특정 경로 또는 더 나은 토큰을 통해)
다른 잠재적인 이점은 ci_builds.token을 없애고 대신 CI 실행기에서 허용되는 더 넓은 범위의 스코프를 더 잘 암호화하고 더 쉽게 할 수 있는 JWT 토큰을 사용하는 것입니다.