용어집

check: 관례상 병합 전 테스트(pre-merge tests)를 수행하는 파이프라인의 이름입니다. 이러한 파이프라인은 새로운 변경 사항이나 풀 리퀘스트를 생성할 때 트리거될 수 있습니다. 사람의 리뷰를 아직 거치지 않은 변경 사항으로 실행될 수 있으므로 시스템 오용이나 자격 증명(credential) 손상을 방지하기 위해 실행할 잡 종류와 해당 잡에서 사용할 수 있는 리소스를 선택할 때 주의해야 합니다. 업로드 시점에는 병합할 변경 사항의 최종 순서를 일반적으로 알 수 없으므로 주로 independent 파이프라인 관리자를 가집니다.
config-project: 관리자가 테넌트 구성 파일에서 지정할 수 있는 두 가지 유형의 프로젝트 중 하나입니다. config-project의 주요 임무는 Zuul에 대한 구성 정보와 잡 콘텐츠를 보관하는 것입니다. config-project에 정의된 잡은 상승된 권한(elevated privileges)으로 실행되며, 모든 Zuul 구성 항목을 사용할 수 있습니다. config-project에 대한 변경 사항은 병합되기 전에 세심한 검토(scrutiny)를 거칠 것으로 예상됩니다.
gate: 관례상 프로젝트 게이팅(project gating)을 수행하는 파이프라인의 이름입니다. 이러한 파이프라인은 코어 팀(core team) 멤버가 변경 사항이나 풀 리퀘스트를 승인할 때 트리거될 수 있습니다. 승인되는 순서대로 변경 사항을 결합하고 순서를 지정할 수 있도록 dependent 파이프라인 관리자를 가져야 합니다.
post: 관례상 브랜치가 업데이트된 후 실행되는 파이프라인의 이름입니다. (병합이 아닌) 브랜치 업데이트 이벤트에서 트리거됨으로써, 이 파이프라인의 잡들은 병합 후 최종 git 상태(업스트림 코드 리뷰 시스템에서 생성된 모든 병합 커밋 포함)로 실행될 수 있습니다. 이는 정확한 커밋 ID가 git 저장소에 존재하도록 일부 아티팩트를 빌드할 때 중요합니다. 이 방식의 단점은 이 파이프라인의 잡들이 커밋을 생성한 기본 변경 사항들과 아무런 연결 없이 실행된다는 점입니다. 브랜치에 대한 최신 업데이트만 중요하다면 supercedent 파이프라인 관리자를 권장하며, 그렇지 않은 경우 independent 가 더 나은 선택일 수 있습니다. tag 및 release 도 참조하세요.
promote: 관례상 이전에 빌드된 아티팩트를 업로드하는 파이프라인의 이름입니다. 이러한 아티팩트는 :term:gate 파이프라인에서 구성되어 임시 위치에 업로드되어야 합니다. gate 파이프라인의 모든 잡이 성공하면 변경 사항이 병합된 후 promote 파이프라인 큐에 추가될 수 있습니다. 이 파이프라인에서 실행되는 잡들은 변경 사항이 gate에서 테스트된 대로 병합되었으므로 당시에 생성된 모든 아티팩트를 이제 안전하게 프로덕션 환경으로 승격(promote)할 수 있다는 가정 하에 수행됩니다. 수많은 변경 사항이 빠른 순서로 병합되는 경우 Zuul이 최신 아티팩트를 제외한 모든 아티팩트의 프로덕션 승격을 건너뛸 수 있도록 supercedent 파이프라인 관리자를 사용하는 것이 좋습니다.
release: 관례상 릴리스 형식의 태그가 업데이트된 후 실행되는 파이프라인의 이름입니다. 일치하는 참조(ref)를 제외하면, 이는 일반적으로 post 파이프라인과 동일하게 구성됩니다. tag 도 참조하세요.
untrusted-project: 관리자가 테넌트 구성 파일에서 지정할 수 있는 두 가지 유형의 프로젝트 중 하나입니다. untrusted-project는 주로 Zuul 운영이 목적이 아니라 테스트되거나 배포되는 프로젝트 중 하나입니다. 이러한 프로젝트에서 사용할 수 있는 Zuul 구성 언어는 다소 제한되어 있으며, 이러한 프로젝트에 정의된 잡들은 아직 리뷰를 거치지 않은 변경 사항에 대해 작동할 수 있으므로 제한된 실행 환경에서 실행됩니다.
노드 (node): 익스큐터 환경과의 강력한 격리를 위해 Ansible 플레이북을 실행할 수 있는 원격 시스템 리소스입니다. Ansible 인벤토리 용어로는 원격 호스트(remote host)를 의미합니다.
노드셋 (nodeset): 잡에 적용될 때 해당 빌드의 Ansible 인벤토리에 호스트 항목으로 추가되는 하나 이상의 노드 집합입니다. 노드셋 내의 노드들은 잡 플레이북에서 참조하기 쉽도록 편리한 이름을 부여받을 수 있습니다.
데이터 시크릿 (data secret): 암호화 여부와 관계없이 사용자 정의 데이터로 구성된 Secret 입니다. 원격 리소스에 대한 정보(예: 사용자 이름, 비밀번호, URL 등)를 잡(jobs)에 안전하게 제공하는 데 유용합니다.
디플로이 (deploy): 관례상 지속적 배포(continuous-deployment) 파이프라인의 이름입니다. 이러한 파이프라인은 일반적으로 임시 빌드 노드가 아닌 프로덕션 시스템과 상호 작용합니다. 병합 이벤트에 의해 트리거됨으로써 배포 결과를 원래의 변경 사항에 다시 보고할 수 있습니다. 여러 저장소가 관련되어 있고 각 변경 사항에 대해 일부 잡(파일 일치자 기준)만 실행되는 경우 serial 파이프라인 관리자를 사용하는 것이 권장됩니다. 단일 저장소가 관련되어 있고 병합된 모든 변경 사항에 대해 모든 배포 잡이 실행되는 경우 supercedent 이 더 적합할 수 있습니다.
리포터 (reporter): 리포터는 잡 완료 후 항목이 큐에서 제외(dequeued)될 때 수행되는 조치(action)를 설명하는 pipeline attribute 입니다. 리포터는 Drivers 에 의해 구현되므로 해당 조치는 매우 다양할 수 있습니다. 예를 들어 리포터는 제안된 변경 사항에 대해 원격 시스템에 피드백을 남기거나, 이메일을 보내거나, 데이터베이스에 정보를 저장할 수 있습니다.
머저 (merger): 트리거된 이벤트에서 제공된 변경 컨텍스트를 기반으로 빌드에 제공되는 Git 참조(refs) 구성을 담당하는 Zuul의 컴포넌트입니다. 효율성 향상을 위해 로컬 병합 프로세스를 실행하도록 익스큐터를 구성할 수도 있습니다.
베이스 잡 (base job): 부모(parent)가 없는 잡입니다. 베이스 잡은 config-project 에서만 정의될 수 있습니다. 여러 개의 베이스 잡을 정의할 수 있지만, 각 테넌트(tenant)는 명시적으로 부모를 지정하지 않은 모든 잡의 부모로 사용될 단일 기본 잡(default job)을 가집니다.
변경 사항 (change): Git 저장소의 특정 상태입니다. 변경 사항은 코드 리뷰 시스템의 변경 리비전/풀 리퀘스트(pull request), 원격 브랜치 팁(tip), 태그, 또는 기타 모든 종류의 Git 참조(ref)를 나타낼 수 있습니다. 변경 사항은 또한 커밋 기록에서 암묵적으로 가져오거나 크로스 프로젝트 종속성 선언(예: 커밋 메시지나 풀 리퀘스트 요약에서, 정확한 메커니즘은 소스 연결 드라이버에 따라 다름)을 사용하여 명시적으로 가져온 추가적인 종속성 컨텍스트와 함께 올 수 있습니다.
부모 잡 (parent job): 자식 잡이 플레이북과 변수 같은 값들을 상속받는 원본 잡입니다. 플레이북과 변수의 종류에 따라 이러한 값들은 자식 잡에 병합되거나 덮어쓰일 수 있습니다. 부모를 지정하지 않은 모든 잡은 테넌트의 베이스 잡(base job)을 상속합니다.
빌드 (build): 잡의 실행(run)입니다. 모든 빌드에는 Zuul의 컴포넌트 서비스 간에 조정할 때, 그리고 상태 API 및 웹 대시보드에서 로그 스트림과 결과를 처리하는 등의 목적으로 사용되는 전역적으로 고유한 식별자가 할당됩니다. 빌드의 컨텍스트는 잡 정의뿐만 아니라 해당 빌드가 예약(scheduled)된 파이프라인에서도 가져옵니다.
빌드셋 (buildset): 공통 컨텍스트를 공유하는 빌드들의 모음입니다. 빌드셋의 모든 빌드는 동일한 트리거 이벤트와 변경 사항 식별자(change identifier)를 가집니다.
스케줄러 (scheduler): 테넌트 구성의 파이프라인 정의에 의해 트리거된 빌드에 대해 소스 및 보고 연결과 노드, 머저(mergers), 익스큐터(executors)에 대한 요청을 조정하는 Zuul의 컴포넌트입니다.
신뢰할 수 없는 실행 컨텍스트 (untrusted execution context): untrusted-project 에 정의된 플레이북은 신뢰할 수 없는(untrusted) 실행 컨텍스트에서 실행됩니다.
신뢰할 수 있는 실행 컨텍스트 (trusted execution context): config-project 에 정의된 플레이북은 신뢰할 수 있는(trusted) 실행 컨텍스트에서 실행됩니다. 운영자가 구성한 경우, 신뢰할 수 있는 실행 컨텍스트는 버블랩(bubblewrap) 컨테이너 내의 추가 디렉터리에 접근할 수 있습니다.
아티팩트 (artifact): 빌드에 의해 생성되어 재사용을 위해 보관(archived)되는 파일 또는 파일의 집합입니다. 이 용어는 주로 릴리스 패키지나 렌더링된 문서와 같은 주요 빌드 결과물을 지칭하지만, 로그와 같이 부산물(byproduct)로 생성된 파일을 의미할 수도 있습니다.
연결 (connection): 코드 리뷰 플랫폼, 일반 Git 호스팅 사이트 또는 SMTP나 SQL 같은 전송(emitting) 프로토콜 등 특정 이벤트 소스에 대한 자격 증명(credentials) 및 위치 정보를 트리거 및 보고 드라이버와 결합한 것입니다.
요구되는 아티팩트 (required artifact): 하나 이상의 잡에서 제공되는 아티팩트로, 이를 필요로 하는 잡의 실행이 이 아티팩트에 의존합니다.
요구되는 프로젝트 (required project): 잡에서 해당 소스 코드를 필요로 하는 프로젝트입니다. 잡은 자신의 빌드를 트리거한 이벤트와 관련된 프로젝트를 암묵적으로 요구하지만, 추가 프로젝트를 명시적으로 지정할 수도 있습니다. Zuul은 빌드에 요구되는 모든 프로젝트의 투기적인 미래 상태(speculative future states)를 나타내는 병합 커밋(merge commits)을 제공합니다.
윈도우 (window): 잡을 실행하도록 허용된 파이프라인의 일부(가장 관련성이 높은 것은 dependent pipelines )입니다. Zuul은 병합될 가능성이 없는 변경 사항에 테스트 리소스를 낭비하지 않고 변경 사항을 신속하게 병합하기 위해 파이프라인 처리량과 리소스 사용량을 일치시키도록 설계된 여러 가지 구성 옵션과 휴리스틱(heuristics)을 갖추고 있습니다.
익스큐터 (executor): 빌드를 생성하기 위해 샌드박스 처리된 Ansible 프로세스의 실행을 담당하는 Zuul의 컴포넌트입니다. 잡이 적절하게 구성된 경우 일부 빌드는 익스큐터(executor)가 제공하는 작업 공간(workspace) 내에서 전적으로 실행될 수 있으며, 또는 더 복잡하고 위험한 작업을 위해 실행기가 원격 노드에 연결해야 할 수도 있습니다.
인벤토리 (inventory): Zuul이 Ansible에 제공하는 호스트 및 변수 할당의 집합으로, 빌드의 컨텍스트를 형성합니다.
자식 잡 (child job): 부모 잡으로부터 플레이북과 변수 같은 값들을 상속받는 잡입니다. 모든 잡은 명시적으로 부모를 선언하든 안 하든 최소한 베이스 잡으로부터 상속받기 때문에 암묵적으로 자식 잡입니다.
잡 (job): 의도된 상황에서 호출될 때 취해야 할 일련의 조치(actions)들을 정의하는 Ansible 플레이북, 변수, 필터링 조건 및 기타 메타데이터의 모음입니다. 잡은 파이프라인의 컨텍스트에서 실행될 때 빌드를 생성하는, 순서가 지정된 익명의 동작 집합입니다.
잡 변형 (job variant): 변수 및 필터링 기준을 변경하는 다른 정의된 잡의 가벼운 수정본입니다.
잡 종속성 (job dependency): 한 잡이 하나 이상의 다른 잡에 대한 빌드 완료, 또는 해당 빌드가 생성할 수 있는 제공된 아티팩트(provided artifacts)에 명시적으로 의존하는 것입니다. 잡은 종속성의 특정 빌드 결과에 조건부로 의존할 수도 있습니다.
제공된 아티팩트 (provided artifact): 다른 잡의 종속성 선언 목적으로, 잡의 빌드가 생성할 것으로 예상되는 이름이 지정된 아티팩트입니다. 여러 잡이 동일한 이름을 가진 동등한 아티팩트를 제공할 수 있으므로, 해당 아티팩트를 제공하는 특정 잡과 무관하게 이러한 관계를 정의할 수 있습니다.
최종 잡 (final job): 예를 들어 실행할 태스크 목록이 잠재적인 자식 잡에 의해 변경되는 것을 방지하기 위해, 다른 잡들이 부모로 사용할 수 없도록 허용된 잡입니다.
추상 잡 (abstract job): 직접 실행할 수 없으며, 오직 다른 잡들을 그 위에 구성하기 위한 부모(parent) 역할을 하도록 의도된 잡입니다.
크로스 프로젝트 종속성 (cross-project dependency): 변경 사항이 다른 변경 사항에 의존한다는 명시적인 선언으로, 동일한 Git 저장소에 있거나 심지어 동일한 연결을 통해 액세스할 필요가 없습니다. Zuul은 종속성 관계를 선언하는 변경 사항의 컨텍스트에 모든 크로스 프로젝트 종속성을 통합할 것으로 예상됩니다.
태그 (tag): 관례상 태그가 업데이트된 후 실행되는 파이프라인의 이름입니다. 일치하는 참조(ref)를 제외하면, 이는 일반적으로 post 파이프라인과 동일하게 구성됩니다. release 도 참조하세요.
테넌트 (tenant): Zuul이 작동해야 하는 프로젝트의 집합입니다. 구성(Configuration)은 테넌트 간에 공유되지 않지만, 동일한 연결의 동일한 프로젝트가 둘 이상의 테넌트에 나타날 수 있으며, 동일한 이벤트가 동일한 변경 사항을 둘 이상의 테넌트의 파이프라인 큐에 추가할 수도 있습니다. Zuul의 HTTP API 메서드와 웹 대시보드는 뚜렷한 테넌트별 인증 및 인가를 지원하기 위해 테넌트별로 범위가 지정됩니다.
토큰 시크릿 (token secret): 시크릿을 고유하게 식별하는 자동으로 생성된 OpenID Connect 토큰과 이를 사용하는 잡에 대한 정보로 구성된 Secret 입니다. 연합된(federated) 타사 서비스 인증에 유용합니다.
투기적 실행 (speculative execution): 마이크로프로세서 설계에서 차용한 용어로, 예상되는 결과를 예측하여 순차적인 연산들을 병렬로 수행한 다음 사실이 아닌 것으로 판명되는 논리적 분기(logical branches)는 모두 폐기한다는 아이디어입니다. Zuul은 긍정적인 예측(optimistic prediction)을 사용하여 변경 사항에 대한 모든 빌드가 성공할 것이라고 가정하고, 순서상 뒤따르는 다른 변경 사항들에 대해 병렬 빌드를 진행합니다. 변경 사항이 실패 상태(적어도 하나의 투표용 빌드에서 실패 결과가 나타남)가 되면 Zuul은 이후의 모든 큐 항목에 대한 테스트를 재설정하여 해당 항목을 각각의 컨텍스트에 더 이상 포함하지 않도록 합니다.
트리거 (trigger): Zuul이 변경 사항을 파이프라인 큐에 추가하기 위한 신호(cue)로 의존할 수 있는 (일반적으로 외부의) 이벤트입니다.
파이프라인 (pipeline): 빌드의 컨텍스트를 제공하는 트리거, 우선순위 지정, 스케줄링 및 보고 규칙의 집합입니다.
파이프라인 관리자 (pipeline manager): 파이프라인이 트리거 이벤트의 큐잉(queuing)을 관리하는 알고리즘입니다. 구체적으로는 변경 사항들이 독립적으로 큐에 추가될지, 승인된 순서대로 함께 순서가 지정될지, 아니면 후속 이벤트에 의해 완전히 대체(superceded)될지 여부를 결정합니다.
프로젝트 (project): 테넌트 내의 연결을 통해 사용할 수 있는 고유한 Git 소스 저장소입니다. 이름이 같은 두 저장소가 다른 연결을 통해 제공될 때 모호성을 피하기 위해 프로젝트는 연결 또는 호스트 이름과 해당 저장소가 결합된 형태로 식별됩니다.
프로젝트 게이팅 (project gating): 제안된 변경 사항이 해당 저장소에 대해 선언된 테스트를 통과할 수 있을 때까지 프로젝트의 정규 소스 코드 저장소에 병합되는 것을 자동으로 방지합니다. 프로젝트 게이팅 워크플로에서는 사용자로부터 신호를 받을 수 있지만, 궁극적으로 변경 사항의 병합을 제어하는 것은 사용자가 아니라 게이팅 시스템입니다.
프로젝트 큐 (project queue): 종속성 관계를 통해 명시적으로, 또는 이를 큐에 추가한 트리거 이벤트의 시간적 순서에 따라 암시적으로 테스트를 위해 순서가 지정된 변경 사항 집합입니다. 여러 프로젝트가 프로젝트 큐의 이름을 지정하고 공유하여, 해당 프로젝트 전반에 걸쳐 변경 사항을 순차적으로 병합하도록 보장할 수 있습니다.
프로젝트 템플릿 (project template): 하나 이상의 프로젝트에 적용하기 위해 잡들을 파이프라인에 매핑하여 이름을 부여한 것입니다. 이 구조는 여러 프로젝트에 걸쳐 동일한 파이프라인에서 동일한 잡 집합을 재사용할 수 있는 편리한 수단을 제공합니다.
프로젝트 파이프라인 (project pipeline): 파이프라인에 잡을 적용하는 것입니다. 프로젝트 파이프라인 항목에는 잡이 빌드를 생성해야 하는 조건을 지정하는 필터링 및 일치 규칙과 해당 잡들이 다른 잡에서 제공하는 빌드 결과 및 지정된 아티팩트에 대해 가질 수 있는 모든 상호 종속성이 포함되는 경우가 많습니다.