| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed |
@ayufan
@josephburnett
|
@grzegorz
|
@dhershkovitch
@DarrenEastman
@cheryl.li
| devops verify | 2023-08-23 |
GitLab 단계 실행기 (Step Runner)
요약
본 문서는 Step Runner라는 새로운 구성 요소의 아키텍처, 사용하는 GitLab Steps 구문 및 GitHub Actions 지원 방법을 설명합니다.
경쟁 CI 제품 drone.io, GitHub Actions에서는 단계 또는 액션 형태로 조합 가능한 CI 작업 실행을 지원합니다.
그들의 사용 및 우리의 이전 GitLab Runner Plugins을 평가한 결과는 CI 작업 실행을 더 잘 정의하는 데 필요성을 보여줍니다.
용어
- GitLab Steps: 단일 작업 실행 컨텍스트 내에서 재사용 가능한 구성 요소를 정의하고 사용하는 GitLab CI 기능의 이름입니다.
- Step Runner: GitHub Actions와 호환되도록하는 GitLab Steps의 RFC 구현입니다.
- GitHub Actions: GitHub에서 사용되는 재사용 가능한 실행 구성 요소로, GitLab Steps와 유사합니다.
- CI Catalog: 공개 또는 비공개 구성 요소 카탈로그로, 공유 구성 요소를 찾아 사용할 수 있습니다.
- GitLab Rails: GitLab.com이나 온프레미스 설치에서 실행되는 파이프라인 실행을 담당하는 주요 응용 프로그램입니다.
동기
현재 .gitlab-ci.yml은 상당히 유연하지만, 복잡한 워크플로를 지원하려고 하면 매우 복잡해집니다. 이 복잡성은 반복적인 패턴, 목적에 맞는 구문 또는 실행할 명령어의 복잡한 시퀀스로 표현됩니다.
이는 .gitlab-ci.yml이 더 세밀한 조정 또는 특별한 동작을 필요로 하는 더 복잡한 워크플로에 유연하지 않기 때문에 특히 도전적입니다. Git 클론, 아티팩트 다운로드, 또는 셸 스크립트 실행 방법을 처리하는 구문적 접근 방식은 종종 “표준”이 아닌 파이프라인에 대해 시스템을 우회해야 하는 필요성으로 이어집니다.
이는 새로운 구문을 secure files 또는 release: 키워드와 같은 특정 기능을 지원하도록 .gitlab-ci.yml에 추가하려고 할 때 특히 도전적입니다. 이러한 특수 기능을 구문 수준에서 추가하면 유지 관리하기 더 어려운 보다 복잡한 구성물이 결과로 나타납니다. 또한 요구 사항이 변경될 때 기술적 부채에 대한 처리가 더 복잡해집니다.
drone.io 및 GitHub Actions의 예는 많은 워크플로가 CI 구문의 일부가 아니어야만 한다는 것을 보여줍니다. 대신, 공통적으로 구성된 재사용 가능한 구성 요소로 제공되어, CI 구성에서 구성될 수 있고 후에 입력 및 매개변수에 따라 다운로드 및 실행할 수 있습니다.
GitLab Steps는 경쟁 업체와 유사한 모델을 따르고 일부 경우에는 호환성을 유지함으로써 이러한 제품간의 격차를 메우기 위해 고안되었습니다. GitLab Steps는 모든 목적별 구문을 대체하기 위해 고안되었습니다. .gitlab-ci.yml 외부에서 빌드되고 사용되며 버전이 지정되고 필요할 때 요청되는 재사용 가능한 구성 요소를 제공함으로써 고객에게 더 많은 유연성을 제공하고 카탈로그 반복을 더 빨리 진행할 수 있도록 합니다.
재사용 가능한 구성 요소는 CI 작업 실행의 일부인데, 이것은 GitLab.com의 공개적으로 호스팅된 저장소, 온프레미스 저장소, 또는 로컬 프로젝트에서 가져올 수 있습니다.
각 CI 작업은 실행할 steps: 목록을 정의할 것인데, 이는 GitLab Steps 또는 GitHub Actions을 참조할 것입니다. 이러한 단계는 Step Runner에서 직접 실행될 것입니다. GitLab Runner이 GitLab.com (또는 온프레미스 설치)과 Step Runner 사이의 연결을 담당할 것입니다.
목표
GitLab Steps:
- GitLab Steps는 GitLab 특정 Steps 구현을 위한 구문과 구조를 정의합니다.
- GitLab Steps가 CI 카탈로그에 게시됩니다.
- GitLab Steps는 인스턴스 간에 사용될 수 있습니다(페더레이션).
- GitLab Steps는
inputs와outputs를 정의해야 합니다. - GitLab Steps는 예상 권한을 가진 민감한 정보를 명시적으로 요청해야 합니다. 예를 들어: 시크릿, 변수, 토큰.
GitLab Inc.이 관리하는 GitLab Steps 저장소:
- GitLab Inc.은 현재 목적별 구문인
artifacts:,cache:,release:등의 모든 구문을 대체할 수 있는 GitLab Steps 저장소를 제공할 것입니다. - GitLab Inc.은 다양한 쉘 (
bash,powershell)을 지원하는shell단계를 실행할 수 있는 범용 단계를 제공할 것입니다. - 목적별 구문의 사용은 최종적으로 단계로 대체될 수 있습니다.
Step Runner:
- Step Runner은
https://gitlab.com/gitlab-org의 별도 프로젝트에 호스팅됩니다. - Step Runner은 GitHub Actions의 대부분을 실행할 수 있습니다.
- Step Runner은 대상 환경에서 프로세스로 실행됩니다.
- 사용자는 로컬 머신에서 Step Runner를 사용하여 로컬에 저장된
.gitlab-ci.yml의 특정 CI 작업 단계를 실행할 수 있습니다. - Step Runner은 GitLab Runner의 외부 구성 요소로, GitLab Runner은 환경을 제공하고 페이로드를 구성하고 Step Runner에 실행을 전달할 것입니다.
- Step Runner은
clone,artifacts,caches,script및after_script의 모든 사용자 정의 처리, 모든 다른 쉘(bash,powershell)의 사용자 정의 처리를 대체할 것입니다. - Step Runner은 GitLab Steps 및 GitHub Actions를 구문 분석하고 컴파일하는 데 책임이 있을 것입니다.
- Step Runner은 GitLab Steps 및 GitHub Actions에 필요한 저장소를 다운로드하고 관리할 것입니다.
- Step Runner은 개별 단계 실행의 실행 흐름을 제어하고 모니터링할 것입니다.
- Step Runner은 명령줄 인터페이스 (CLI)에서 실행 가능해야 합니다. 이것은 설정 파일이나 환경 파일을 통해 구성하거나
.gitlab-ci.yml에서 읽을 수 있어야 함을 의미합니다. - Step Runner는 실행 구성을 또는 추적을 얻을 수 있는 gRPC 또는 다른 프로그래밍 가능한 인터페이스를 노출시켜야 합니다.
단계 실행:
- 각 단계는 단일 게시된 또는 로컬에서 정의된 GitLab 단계 또는 GitHub Action으로 정의됩니다.
- 각 단계는 해당 단계에서 정의된 조건에 따라 실행됩니다.
- 각 단계는 최소한의 정보가 노출되도록 실행됩니다. 단계에게 노출된 정보는 명시적으로 단계에 의해 요청됩니다. 예를 들어: 단계에서 명시적으로 요청한 환경 변수만이 단계로 전달됩니다.
- 각 단계는 신뢰할 수 없는 것으로 간주됩니다. 즉, 일부 단계가 신뢰될 수 있다 하더라도 전반적으로 CI 작업은 신뢰될 수 없는 것으로 간주해야 합니다. 시스템은 신뢰를 보장할 수 없기 때문입니다.
- 각 단계는 재현 가능한 빌드를 만들기 위한 목적으로 단계 실행을 서명하는 것을 허용하기 위해 실행 조건, 사용된 버전 및 생성된 출력 형식으로 실행에 대한 설명을 포함합니다.
역호환성:
- 현재 실행 가능한 모든 구문(예:
before_script:,script:,artifacts:,cache:등)은 GitLab (Rails)에 의해 변환될 수 있어야 합니다.
비 목표
미정
제안
Step Runner은 https://gitlab.com/gitlab-org/step-runner에 위치한 새로운 go binary입니다.
여러 입력 형식을 표준 proto 형식으로 컴파일할 수 있을 것입니다.
출력물은 디버깅 및 빌드 재현을 위한 세부 정보가 포함된 표준 proto trace가 될 것입니다.
기능
- 단계 읽기
- 환경 변수에서
-
.gitlab-ci.yml파일에서 - step-runner의 gRPC 서버에서
- commandline JSON 입력에서
- GitLab 단계 및 GitHub 작업을 기본 단계 정의로 컴파일
- 명시적 입력 및 출력
- 명시적 환경 및 내보내기
- 기준 단계는
exec유형 또는 더 많은 단계가 될 수 있음
- 단계 다운로드 및 실행
- Git 저장소
- zip 파일
- 로컬로 제공된
- 작업은 다양한 종류의 단계로 구성될 수 있음
- 단계는 다른 출처에서 가져올 수 있고 다양한 방법으로 실행될 수 있음
- 단계는 이전 단계의 환경 내보내기 및 출력에 액세스할 수 있음
- 실행의 단계별 추적 생성
- 최종 입력 및 출력 포함
- 최종 환경 및 내보내기 포함
- 각 단계의 로그 포함
- 각 단계는 정확한 실행시간 및 구성 요소 (해시)를 지정함
- (옵션) 민감한 입력, 출력, 환경 및 내보내기 마스킹
- 추적 재생
- 추적에서 정확한 실행 시간 및 구성 요소를 재사용함
- 빌드가 결정론적인 경우, 추적의 출력물은 동일한 추적이 될 것임
예상 호출
명령줄
STEPS=$(cat steps.yml) step-runner cistep-runner local .gitlab-ci.yml --format gitlab-ci --job-name hello-world --output-file trace.jsonstep-runner replay trace.jsonstep-runner ci --port 8080
GitLab CI
hello-world:
image: registry.gitlab.com/gitlab-org/step-runner
variables:
STEPS: |
- step: gitlab.com/josephburnett/component-hello-steppy@master
inputs:
greeting: "hello ${{ env.name }}"
env:
name: world
script:
- /step-runner ci
artifacts:
paths:
- trace.json
기본 컴파일 및 실행 프로세스
GitLab CI에서 표현된 단계는 기본 단계 정의로 컴파일됩니다. 참조된 단계는 로드되어 실행 명령 또는 재귀적으로 컴파일된 추가 GitLab CI 단계 목록을 생성합니다. 각 단계는 컴파일 직후 즉시 실행되므로 그 출력물은 후속 컴파일에서 사용할 수 있게 됩니다.
단계는 각각의 컴파일 후에 Step Runner에 의해 수집된 파일을 통해 출력 및 내보내기를 반환합니다. 마지막으로 각 단계의 컴파일된 입력과 출력이 단계 추적으로 수집됩니다.
GitLab 단계 정의 및 구문
GitLab 단계 통합
디자인 및 구현 세부 정보
2023-11-28 - GitLab 단계 ADR 001: Step Runner 부트스트랩
참조
- GitLab 이슈 #215511
- Step Runner 코드. 이 코드는 이 설계안 작성 중에 생성된 탐색 코드입니다. Step Runner 바이너리의 구조와 부합되는 방식을 보여줍니다. 실행은 하지만 모든 TODO를 참조하세요.
- CI 단계 / CI 이벤트 / Executors / Taskonaut (비디오). 이 4가지 설계안이 어떻게 관련되는지에 대한 고수준 토론이 있습니다. 그리고 이 MR에 대한 좋은 전편 비디오입니다.
- Runner의 단계 (비디오). 코드 관점에서 Step Runner 세부 정보에 대한 안내입니다.
- CI YAML 키워드. 영향을 받는 키워드의 목록입니다.
- GitLab Epic 11535