| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed |
@ayufan
@josephburnett
|
@grzegorz
|
@dhershkovitch
@DarrenEastman
@cheryl.li
| devops verify | 2023-08-23 |
GitLab 단계 실행기를 사용하여 GitLab 단계를 실행합니다
요약
이 문서는 새로운 컴포넌트 인 단계 실행기 (Step Runner)에 대한 아키텍처, 사용하는 GitLab 단계 구문 및 GitHub Actions 지원 방법을 설명합니다.
경쟁 CI 제품인 drone.io, GitHub Actions는 스텝 또는 액션 형식으로 구성 가능한 CI 작업 실행을 제공합니다.
그들의 사용 및 이전 GitLab Runner 플러그인의 평가는 CI 작업 실행을 정의하는 더 나은 방법이 필요함을 보여줍니다.
용어
- GitLab 단계: 단일 작업 실행 컨텍스트 내에서 재사용 가능한 컴포넌트를 정의하고 사용하는 GitLab CI 기능의 이름입니다.
- 단계 실행기: GitHub Actions와 호환성을 제공하는 GitLab 단계 RFC 구현입니다.
- GitHub Actions: GitHub에서 사용되는 재사용 가능한 실행 컴포넌트로 GitLab 단계와 유사합니다.
- CI 카탈로그: 공개 또는 비공개 컴포넌트 카탈로그로, 공유된 컴포넌트를 발견하고 사용하는 데 사용될 수 있습니다.
- GitLab Rails: GitLab.com 또는 온프레미스 설치에서 실행되는 파이프라인 실행을 담당하는 주요 응용 프로그램입니다.
동기
현재의 .gitlab-ci.yml은 상당히 유연하지만, 복잡한 워크플로를 지원하려고 할 때 쉽게 매우 복잡해집니다. 이 복잡성은 반복적인 패턴, 목적별 구문 또는 복잡한 명령어 실행 순서로 나타납니다.
이는 .gitlab-ci.yml이 더 복잡한 워크플로우에서 유연하지 못하며, CI 작업 실행에 대한 세밀한 조정 또는 특수 동작을 필요로 하는 경우에 특히 어려움을 겪게 됩니다. Git 복제, 아티팩트 다운로드 시점 또는 쉘 스크립트 실행 방법을 다루는 .gitlab-ci.yml의 지시적 접근은 종종 “표준”이 아닌 파이프라인에 대해 시스템을 우회해야 할 필요성으로 이어지곤 합니다.
이는 secure files 또는 release: 키워드와 같은 특정 기능을 지원하기 위해 .gitlab-ci.yml에 새로운 구문을 추가하려고 할 때 특히 어려움을 겪게 됩니다. 이러한 특별한 기능을 구문 수준에서 추가하면 유지 관리하기 어려운 더 복잡한 구성을 만들며, 요구 사항이 변경될 때 기술적 부채를 처리하기가 더 복잡해집니다.
drone.io 및 GitHub Actions의 예는 많은 워크플로가 CI 구문의 일부일 필요가 없다는 것을 보여줍니다. 대신에 CI 구성에서 일반적인 방식으로 구성된 재사용 가능한 컴포넌트 형태로 제공되고, 입력 및 매개변수에 따라 나중에 다운로드 및 실행되는 방식으로 제공될 수 있습니다.
GitLab 단계는 이러한 제품 간격을 채워주고, 경쟁 제품과 유사한 모델을 따르며 일부 경우에는 호환성을 유지하도록 하고 있습니다. GitLab 단계는 모든 목적별 구문을 대체하기 위해 의도되었습니다. .gitlab-ci.yml 외부에서 빌드되어 필요할 때 요청되고 사용되는 버전이 매겨진 재사용 가능한 컴포넌트를 제공함으로써, 이는 고객에게 더 많은 유연성을 제공하고 카탈로그에 대한 반복적으로 빠르게 반복할 수 있게 합니다.
CI 작업 실행의 일환인 재사용 가능한 컴포넌트는 GitLab.com의 공개적으로 호스팅되는 리포지터리, 온프레미스 컴포넌트 리포지터리 또는 로컬 프로젝트에서 가져올 수 있습니다.
각 CI 작업은 실행할 steps: 디렉터리을 정의하게 되며, 이 단계는 GitLab 단계 또는 GitHub Actions을 참조합니다. 이러한 단계는 대상 환경의 단계 실행기에서 직접 실행될 것입니다. GitLab Runner는 GitLab.com(또는 온프레미스 설치) 및 단계 실행기 간의 연결을 제공할 것입니다.
목표
GitLab 단계:
- GitLab 단계는 GitLab 특정 단계 구현을 위한 구문과 구조를 정의합니다.
- GitLab 단계는 CI 카탈로그에 출판됩니다.
- GitLab 단계는 인스턴스 간에 사용될 수 있습니다 (페더레이션).
- GitLab 단계는
inputs및outputs을 정의합니다. - GitLab 단계는 예상 권한과 함께 민감한 정보를 명시적으로 요청해야 합니다. 예: 비밀, 변수, 토큰.
GitLab Inc.의 관리되는 GitLab 단계 리포지터리:
- GitLab Inc.는 현재 목적별 구문 (
artifacts:,cache:,release:등)을 대체할 수 있는 GitLab 단계 리포지터리를 제공합니다. - GitLab Inc.는 여러 쉘 (
bash,powershell)을 지원하는shell단계를 실행하는 일반적인 단계를 제공할 것입니다. - 목적별 구문의 사용은 나중에 단계를 위해 단계로 대체될 수 있습니다.
단계 실행기:
- 단계 실행기는
https://gitlab.com/gitlab-org의 별도 프로젝트에 호스팅됩니다. - 단계 실행기는 대부분의 GitHub Actions를 실행하는 데 사용될 수 있습니다.
- 단계 실행기는 대상 환경의 프로세스로 실행됩니다.
- 사용자는 로컬 머신에서 단계 실행기를 사용하여 로컬로 저장된
.gitlab-ci.yml의 특정 CI 작업 단계를 실행할 수 있습니다. - 단계 실행기는 GitLab Runner의 외부 컴포넌트이며, GitLab Runner는 환경을 제공하고 페이로드를 구성하며 실행을 단계 실행기로 전달합니다.
- 단계 실행기는 모든 다양한 쉘 (
bash,powershell)에 대한클론,아티팩트,캐시,스크립트및스크립트 후의 사용자 정의 처리를 대체할 것입니다. - 단계 실행기는 GitLab 단계 및 GitHub Actions를 구문 분석하고 컴파일하는 책임이 있습니다.
- 단계 실행기는 GitLab 단계 및 GitHub Actions에 필요한 리포지터리를 다운로드하고 관리합니다.
- 단계 실행기는 개별 단계 실행의 실행 흐름을 제어하고 모니터링합니다.
- 단계 실행기는 명령줄 인터페이스 (CLI)에서 실행 가능해야 합니다. 이것은 구성 파일, 환경 파일로 구성하거나
.gitlab-ci.yml을 읽을 수 있어야 함을 의미합니다. - 단계 실행기는 실행 구성 또는 추적을 가져오는 gRPC 또는 다른 프로그래밍 가능한 인터페이스를 노출할 수 있습니다.
단계 실행:
- 각 단계는 단일 공개 또는 로컬로 정의된 GitLab 단계 또는 GitHub Action에 의해 정의됩니다.
- 각 단계는 해당 단계에 의해 정의된 조건에 따라 실행됩니다.
- 각 단계는 노출된 정보가 최소화된 상태로 실행됩니다. 단계에 명시적으로 요청된 환경 변수만이 단계에 전달됩니다. 예: 단계가 명시적으로 요청한 환경 변수만이 전달됩니다.
- 각 단계는 신뢰할 수 없는 것으로 간주됩니다. 신뢰할 수 있는 단계가 있더라도 시스템이 신뢰를 보장할 수 없기 때문에 전체 CI 작업은 신뢰할 수 없는 것으로 간주되어야 합니다.
- 각 단계는 실행에 대한 사전 조건, 사용된 버전 및 생성된 출력 형식으로 실행에 대한 서명 작성을 허용할 것입니다.
하위 호환성:
- 현재 실행 가능한 모든 구문 (예:
before_script:,script:,artifacts:,cache:등)은 GitLab(Rails)에 의해 변환될 수 있어야 합니다.
비목표
TBD
제안
Step Runner은 https://gitlab.com/gitlab-org/step-runner에 위치한 새로운 go 이진 파일입니다.
표준 proto 형식으로 컴파일된 다양한 입력 형식을 수용할 수 있을 것입니다.
출력물은 디버깅 및 빌드 재현을 위한 세부 정보가 포함된 표준 proto trace가 될 것입니다.
기능
- 스텝 읽기
- 환경 변수에서
-
.gitlab-ci.yml파일에서 - step-runner의 gRPC 서버에서
- 명령행 JSON 입력에서
- GitLab 스텝과 GitHub Actions를 기본 스텝 정의로 컴파일
- 명시적 입력 및 출력
- 명시적 환경 및 익스포트
- 기본 스텝은
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에서 표현된 단계는 기본 스텝 정의로 컴파일됩니다.
참조된 단계는 로드되어 exec 명령 또는 재귀적으로 컴파일된 추가 GitLab CI 단계 디렉터리을 생성합니다.
각 스텝은 컴파일 직후 즉시 실행되므로 해당 출력물은 이후의 컴파일에 사용할 수 있습니다.
단계는 각각의 출력과 익스포트를 파일을 통해 Step Runner에서 수집합니다.
마지막으로 각 단계의 컴파일된 입력과 출력물이 단계 추적에 수집됩니다.
GitLab 스텝 정의 및 구문
GitLab 스텝 통합
디자인 및 구현 세부정보
2023-11-28 - GitLab Steps ADR 001: Bootstrap Step Runner
참고 문헌
- GitLab 이슈 #215511
-
Step Runner 코드
본 청사진 작성 중에 만들어진 탐구용 코드입니다.
Step Runner의 구조와 컴포넌트의 상호 작용을 보여줍니다. 실행은 되지만 완전히 올바른 작업은 아닙니다 (모든 TODO 참조). -
CI 단계 / CI 이벤트 / Executors / Taskonaut(동영상)
이 4가지 청사진이 서로 어떻게 관련되는 지에 대한 고수준 논의입니다.
그리고 본 MR에 대한 동영상의 좋은 리퀄 프로그램입니다. -
러너 내 단계(동영상)
코드 관점에서 Step Runner 세부 내용을 살펴보는 동영상입니다. -
GitLab CI YAML 키워드
영향을 받는 키워드의 인벤토리입니다. - GitLab Epic 11535