Zuul 개념

Zuul은 파이프라인 개념을 중심으로 설계됩니다. Zuul에서, 파이프라인은 하나 이상의 프로젝트에 적용할 수 있는 워크플로 프로세스를 포함합니다. 예시로, “check” 파이프라인은 프로젝트에 새롭게 제안된 변경 사항을 테스트하도록 만드는 작업을 정의할 수 있습니다 “gate” 파이프라인은 프로젝트 게이팅 (Project Gating) 을 구현하여 테스트를 통과한 경우에만 프로젝트에 변경 사항을 자동으로 병합할 수 있습니다. “post” 파이프라인은 변경 사항이 반영되었을 때 프로젝트의 공개 문서를 업데이트할 수 있습니다.

“check”, “gate”, “post”라는 이름은 임의적인 것입니다. 이는 Zuul 내부에 고정된 개념들이 아니라, Zuul에서 정의하고 파이프라인으로 구현할 수 있는 워크플로 프로세스들의 몇 가지 일반적인 예시일 뿐입니다.

파이프라인이 정의되면, 원하는 수만큼 프로젝트를 해당 파이프라인에 연결할 수 있으며, 각 프로젝트는 연결된 파이프라인에서 실행할 잡을 정하게 됩니다.

파이프라인에는 특정 이벤트를 파이프라인에 큐로 넣도록 정의된 트리거 가 연결되어 있습니다. 예를 들어, Gerrit에 패치셋이 업로드되면, Gerrit patchset-created 이벤트가 발생합니다. patchset-created 이벤트 트리거가 설정된 파이프라인은 Zuul이 해당 이벤트를 수신할 때 관련 변경 사항을 대기열에 넣습니다. 해당 프로젝트 및 파이프라인에 연결된 잡이 있다면, 함께 실행됩니다. Gerrit 외에도 GitHub, 타이머, Zuul 등 다른 트리거를 사용할 수 있습니다. 사용할 수 있는 전체 트리거 목록은 Drivers 를 참고하십시오.

파이프라인 내 항목의 모든 잡 실행이 완료되면, 해당 파이프라인의 리포터 가 모든 잡의 결과를 보고합니다. 앞선 예시를 이어가자면, 파이프라인에 Gerrit 리포터가 설정된 경우, 리포터는 변경 사항에 리뷰 코멘트를 남기고 설정된 승인 투표를 진행합니다. 여러 보고 단계가 제공되며, 각 단계에는 원하는 수만큼 리포터를 설정할 수 있습니다. 사용 가능한 전체 리포터 목록은 Drivers 를 참조하십시오.

파이프라인 큐에 들어간 각 항목은 git 참조 와 연결됩니다. 해당 참조는 제안된 변경 사항을 가리키거나, 브렌치의 끝(tip) 또는 태그일 수 있습니다. 트리거 이벤트에 따라 참조가 결정되며, 이것이 제안된 커밋인지 병합된 커밋인지기 정해집니다. Zuul은 잡을 실행하기 전에 해당 항목에 대한 참조를 준비합니다. 제안된 변경 사항의 경우, 이는 변경 사항을 대상 브렌치에 추측 기반 병합(speculatively merging)을 하는 것을 의미합니다. 즉, 해당 변경 사항에 대해 작동하는 모든 잡은 변경 사항이 병합된 후의 상태로 git 저장소에서 실행됩니다(변경 사항이 처음 작성된 이후 저장소에 다른 변경 사항들이 병합되었을 수 있으므로, 이는 변경 사항 자체의 git 저장소 상태와 크게 다를 수 있습니다 ). 파이프라인의 항목은 다른 항목에 의존할 수 있으며, 이 경우 의존하는 모든 변경 사항이 Zuul이 준비한 git 저장소 상태에 포함됩니다. Zuul은 여러 변경사항에 대한 잡을 병렬로 실행하여 처리량을 극대화합니다. 잡에서 추가 git 저장소가 필요하다고 지정할 수도 있으며, 이 경우 해당 저장소들의 상태(항목이 파이프라인에 들어간 시점 기준)도 포함됩니다. 이 과정의 상세한 내용은 프로젝트 게이팅 (Project Gating), 크로스 프로젝트 종속성 (Cross-Project Dependencies), 전역 저장소 상태 (Global Repo State) 를 참고하십시오.

위에서 설명한 거의 모든 설정은 Zuul이 관리하는 git 저장소 내부 파일에 보관됩니다. Zuul의 설정은 전역적(global)이지만 분산되어 있습니다. 한 프로젝트에서 정의된 잡은 다른 프로젝트에서 사용될 수 있으며, 파이프라인은 모든 프로젝트에서 사용할 수 있습니다. Zuul은 시작되면, 관리하는 모든 프로젝트에서 설정을 읽어 옵니다. 설정 변경이 제안되면, 해당 변경 사항이 나타난 프로젝트의 유형에 따라 제안된 변경 사항의 일부로 일시적으로 적용되거나, 변경 사항이 병합된 직후 즉시 적용됩니다.

잡은 필요한 노드의 유형과 개수를 지정합니다. Zuul은 정적 노드를 제공하거나 필요에 따라 클라우드 제공자에게 연락하여 노드를 생성 또는 삭제하도록 구성할 수 있습니다.

잡의 실제 실행 내용은 Ansible 플레이북입니다. 원격 노드에서 태스크를 오케스트레이션하는 Ansible의 기능은 Zuul의 다중 노드 테스트 지원에 특히 적합합니다. Ansible은 단순한 태스크(쉘 스크립트 실행 등)부터 정교한 배포 시나리오까지 쉽게 사용할 수 있습니다. Zuul이 Ansible을 실행할 때는 Ansible이 원격 시스템을 오케스트레이션하는 방식과 가장 유사하게 작동하도록 시도합니다. Ansible 자체는 executor 에서 실행되며, 잡에 제공된 테스트 노드에 대해 원격으로 작동합니다. 이는 테스트와 운영 환경에서 동일한 Ansible 플레이북을 사용할 수 있게 함으로써 지속적 인도(Continuous Delivery)를 용이하게 합니다.