Geo는 여러 GitLab 인스턴스를 서로 연결합니다. 하나의 GitLab 인스턴스가 primary 사이트로 지정되며 여러 secondary 사이트와 함께 운영할 수 있습니다. Geo는 아래 다이어그램에서 볼 수 있고 이 문서에서 더 자세히 설명하는 여러 컴포넌트를 조율합니다.

복제 계층#

Geo는 여러 컴포넌트의 복제를 처리합니다.

• 데이터베이스: 캐시와 job을 제외한 전체 애플리케이션을 포함합니다.
• Git 리포지터리: 프로젝트와 위키를 모두 포함합니다.
• Blob: 이슈에 첨부된 이미지부터 CI의 원시 로그와 에셋까지 모든 항목을 포함합니다.

데이터베이스 복제를 제외하면 secondary 사이트에서는 모든 작업이 Geo Log Cursor에 의해 조율됩니다.

복제 상태#

다음 다이어그램은 복제가 동작하는 방식을 보여 줍니다. 일부 허용된 전환은 명확성을 위해 생략했습니다.

stateDiagram-v2
    Pending --> Started
    Started --> Synced
    Started --> Failed
    Synced --> Pending: Mark for resync
    Failed --> Pending: Mark for resync
    Failed --> Started: Retry

Geo Log Cursor 데몬#

Geo Log Cursor 데몬은 각 secondary 사이트에서 실행되는 별도의 프로세스입니다. Geo Event Log에서 새 이벤트가 있는지 모니터링하고, 각 특정 이벤트 유형에 대해 백그라운드 job을 생성합니다.

예를 들어 리포지터리가 업데이트되면 Geo primary 사이트는 연관된 리포지터리 업데이트 이벤트와 함께 Geo 이벤트를 생성합니다. Geo Log Cursor 데몬은 이 이벤트를 가져와 Geo::EventWorker job을 스케줄링하며, 이 job은 Geo::EventService를 사용해 리포지터리를 업데이트합니다.

Geo Log Cursor 데몬은 고가용성 모드로 자동으로 동작할 수 있습니다. 데몬은 주기적으로 잠금 획득을 시도하고, 잠금을 획득하면 활성 데몬으로 동작합니다.

같은 사이트에서 추가로 실행 중인 데몬은 대기 모드에 있으며, 활성 데몬이 잠금을 해제하면 작업을 재개할 준비가 되어 있습니다.

GitLab은 TTL이 짧은 ExclusiveLease 잠금 유형을 사용하며, 이 잠금은 풀링 주기마다 갱신됩니다. 이를 통해 타임아웃이 있는 전역 잠금을 구현할 수 있습니다.

풀링 주기가 끝날 때 데몬이 잠금을 갱신하거나 다시 획득할 수 없으면 대기 모드로 전환됩니다.

데이터베이스 복제#

Geo는 스트리밍 복제를 사용해 primary 사이트에서 secondary 사이트로 데이터베이스를 복제합니다. 이 복제를 통해 secondary 사이트는 데이터베이스에 저장된 모든 데이터에 액세스할 수 있으므로, 사용자는 secondary 사이트에 로그인해 예를 들어 모든 이슈와 머지 리퀘스트를 읽을 수 있습니다.

리포지터리 복제#

Geo는 리포지터리도 복제합니다. 각 secondary 사이트는 추적 데이터베이스에서 모든 리포지터리의 상태를 추적합니다.

리포지터리 동기화 흐름과 리스 메커니즘에 관한 자세한 내용은 리포지터리 동기화 문서를 참고합니다.

Blob 복제#

blob 복제 흐름에 관한 자세한 내용은 blob 복제 문서를 참고합니다.

업로드 파티션의 Geo 복제를 로컬에서 테스트하려면 업로드 파티션의 Geo 복제 테스트를 참고합니다.

인증#

Git 및 파일 전송을 인증하기 위해 각 GeoNode 레코드에는 두 개의 필드가 있습니다.

• 공개 액세스 키(access_key 필드).
• 시크릿 액세스 키(secret_access_key 필드).

secondary 사이트는 JWT 요청으로 자신을 인증합니다.

secondary 사이트는 Authorization 헤더로 HTTP 요청을 인가합니다.

Authorization: GL-Geo <access_key>:

primary 사이트는 access_key 필드로 해당하는 secondary 사이트를 찾아 JWT 페이로드를 복호화합니다.

파일 전송#

secondary 사이트가 파일을 다운로드하려고 할 때 JWT 페이로드에는 파일 요청을 식별하기 위한 추가 정보가 담깁니다. 이를 통해 secondary 사이트는 올바른 데이터베이스 ID에 해당하는 올바른 파일을 다운로드합니다. 예를 들어 LFS 객체의 경우 요청에 파일의 SHA256 합계도 포함되어야 합니다. JWT 페이로드 예시는 다음과 같습니다.

{"data": {"sha256": "31806bb23580caab78040f8c45d329f5016b0115"}, "iat": "1234567890"}

요청한 파일이 요청한 SHA256 합계와 일치하면 Geo primary 사이트가 X-Sendfile 기능으로 데이터를 전송하며, 이 기능을 사용하면 Rails나 Workhorse를 붙잡아 두지 않고 NGINX가 파일 전송을 처리할 수 있습니다.

Git 전송#

secondary 사이트가 primary 사이트에서 Git 리포지터리를 복제하거나 가져오려고 할 때 JWT 페이로드에는 Git 리포지터리 요청을 식별하기 위한 추가 정보가 담깁니다. 이를 통해 secondary 사이트는 올바른 데이터베이스 ID에 해당하는 올바른 Git 리포지터리를 다운로드합니다. JWT 페이로드 예시는 다음과 같습니다.

{"data": {"scope": "mygroup/myproject"}, "iat": "1234567890"}

Geo secondary로의 Git Push#

Git Push Proxy는 gitlab-shell 컴포넌트 내부에 구축된 기능으로 존재합니다. 이 기능은 secondary 사이트에서만 활성화됩니다. 이를 통해 secondary 사이트에서 리포지터리를 복제한 사용자가 같은 URL로 푸시할 수 있습니다.

secondary 사이트로 향한 Git push 요청은 primary 사이트로 전달되고, pull 요청은 최대 효율을 위해 계속 secondary 사이트가 처리합니다.

HTTPS 요청과 SSH 요청은 다르게 처리됩니다.

• HTTPS에서는 primary 사이트의 프로젝트를 가리키는 HTTP 302 Redirect를 사용자에게 보냅니다. Git 클라이언트는 그 상태 코드를 이해하고 리디렉션을 처리할 만큼 충분히 똑똑합니다.
• SSH에서는 리디렉션을 수행할 동등한 방법이 없으므로 요청을 프록시해야 합니다. 이 작업은 gitlab-shell 내부에서 먼저 요청을 HTTP 프로토콜로 변환한 다음 primary 사이트로 프록시하는 방식으로 이루어집니다.

gitlab-shell 데몬은 /api/v4/allowed의 응답을 기준으로 언제 프록시할지 판단합니다. 특별한 HTTP 300 상태 코드가 반환되면 응답 본문에 지정된 "custom action"을 실행합니다. 응답에는 프록시된 push 작업이 primary 사이트에서 일어날 수 있게 하는 추가 데이터가 담깁니다.

추적 데이터베이스 사용#

복제되는 메인 데이터베이스와 함께, Geo secondary 사이트에는 자체적인 별도 추적 데이터베이스가 있습니다.

추적 데이터베이스에는 secondary 사이트의 상태가 담겨 있습니다.

업그레이드의 일부로 실행해야 하는 데이터베이스 마이그레이션은 각 secondary 사이트의 추적 데이터베이스에도 적용해야 합니다.

구성#

데이터베이스 구성은 config/database.yml에 설정합니다. ee/db/geo 디렉터리에는 이 데이터베이스의 스키마와 마이그레이션이 있습니다.

이 데이터베이스용 마이그레이션을 작성하려면 다음을 실행합니다.

rails g migration [args] [options] --database geo

추적 데이터베이스를 마이그레이션하려면 다음을 실행합니다.

bundle exec rake db:migrate:geo

Finder#

Geo는 Finder를 사용하며, 이 클래스는 추적 데이터베이스와 메인 데이터베이스에서 프로젝트, 첨부 파일 등을 조회하는 무거운 작업을 담당합니다.

Redis#

secondary 사이트의 Redis는 primary 사이트와 같은 방식으로 동작합니다. 캐싱, 세션 저장, 그 외 영속 데이터에 사용됩니다.

primary 사이트와 secondary 사이트 간의 Redis 데이터 복제는 사용하지 않으므로, 세션 등은 사이트 간에 공유되지 않습니다.

오브젝트 스토리지#

GitLab은 원래 디스크에 저장할 데이터를 선택적으로 오브젝트 스토리지에 저장할 수 있습니다. 예를 들면 다음과 같습니다.

• LFS 객체
• CI job 아티팩트
• 업로드

기본적으로 Geo는 오브젝트 스토리지에 저장된 객체를 복제하지 않습니다. 상황과 고객의 필요에 따라 다음을 할 수 있습니다.

• GitLab 관리 오브젝트 스토리지 복제 활성화.
• 클라우드 공급자의 내장 서비스를 사용해 Geo 사이트 간에 오브젝트 스토리지를 복제합니다.
• secondary Geo 사이트가 primary 사이트와 같은 오브젝트 스토리지 엔드포인트에 액세스하도록 구성합니다.

오브젝트 스토리지 복제 테스트에 관한 자세한 내용을 참고합니다.

검증#

검증 상태#

다음 다이어그램은 검증이 동작하는 방식을 보여 줍니다. 일부 허용된 전환은 명확성을 위해 생략했습니다.

stateDiagram-v2
    Pending --> Started
    Pending --> Disabled: No primary checksum
    Disabled --> Started: Primary checksum succeeded
    Started --> Succeeded
    Started --> Failed
    Succeeded --> Pending: Mark for reverify
    Failed --> Pending: Mark for reverify
    Failed --> Started: Retry

리포지터리 검증#

리포지터리는 체크섬으로 검증합니다.

primary 사이트는 리포지터리의 체크섬을 계산합니다. 기본적으로 모든 Git ref를 함께 해싱하고 그 해시를 데이터베이스의 project_repository_states 테이블에 저장합니다.

secondary 사이트는 같은 방식으로 자신의 복제본 해시를 계산하고, primary 사이트가 계산한 값과 비교합니다. 값이 일치하지 않으면 Geo는 이를 불일치로 표시하며, 관리자는 Geo Admin area에서 이를 확인할 수 있습니다.

Geo 프록시#

Geo secondary는 웹 요청을 primary로 프록시할 수 있습니다. 자세한 내용은 Geo 프록시(개발) 페이지를 참고합니다.

Geo API#

Geo는 외부 API를 사용해 여러 컴포넌트 간의 통신을 돕습니다.

용어집#

Primary 사이트#

primary 사이트는 Geo 구성에서 읽기·쓰기 기능을 갖춘 단일 사이트입니다. 단일 진실 공급원이며 Geo secondary 사이트는 이곳에서 데이터를 복제합니다.

Geo 구성에서 primary 사이트는 하나만 있을 수 있습니다. 모든 secondary 사이트가 그 primary에 연결됩니다.

Secondary 사이트#

secondary 사이트는 다른 지리적 위치에서 실행되는 primary 사이트의 읽기 전용 복제본입니다.

스트리밍 복제#

Geo는 PostgreSQL의 스트리밍 복제 기능에 의존합니다. 이 기능은 데이터베이스 데이터와 데이터베이스 스키마를 완전히 복제합니다. 데이터베이스 복제본은 읽기 전용 사본입니다.

스트리밍 복제는 Write Ahead Log, 즉 WAL에 의존합니다. 이러한 로그는 복제본으로 복사되어 그곳에서 재생됩니다.

스트리밍 복제는 스키마도 복제하므로, 데이터베이스 마이그레이션은 secondary 사이트에서 실행할 필요가 없습니다.

추적 데이터베이스#

각 Geo secondary 사이트에 있는 데이터베이스로, 자신이 위치한 사이트의 상태를 유지합니다. 자세한 내용은 추적 데이터베이스 사용을 참고합니다.

Geo Event Log#

Geo primary는 geo_event_log 테이블에 이벤트를 저장합니다. 로그의 각 항목에는 특정 유형의 이벤트가 담깁니다. 이러한 이벤트 유형에는 다음이 포함됩니다.

• 리포지터리 삭제 이벤트
• 리포지터리 이름 변경 이벤트
• 리포지터리 변경 이벤트
• 리포지터리 생성 이벤트
• 해시 스토리지 마이그레이션 이벤트
• LFS 객체 삭제 이벤트
• 해시 스토리지 첨부 파일 이벤트
• Job 아티팩트 삭제 이벤트
• 업로드 삭제 이벤트

Geo Log Cursor 데몬을 참고합니다.

코드 기능#

Gitlab::Geo 유틸리티#

Geo와 관련된 작은 유틸리티 메서드는 ee/lib/gitlab/geo.rb 파일에 넣습니다.

이러한 메서드 중 다수는 RequestStore 클래스로 캐시되며, 이는 코드베이스 전반에서 메서드를 사용할 때 발생하는 성능 영향을 줄이기 위한 것입니다.

현재 사이트#

.current_node 클래스 메서드는 현재 사이트의 GeoNode 레코드를 반환합니다.

gitlab.yml의 host, port, relative_url_root 값을 사용해 데이터베이스를 검색하여 현재 어느 사이트에 있는지 식별합니다 (GeoNode.current_node 참고).

Primary 또는 Secondary#

현재 사이트가 primary 사이트인지 secondary 사이트인지 판단하려면 .primary? 및 .secondary? 클래스 메서드를 사용합니다.

사이트가 활성화되지 않은 경우 이 두 메서드가 모두 false를 반환할 수 있습니다. 활성화를 참고합니다.

Geo 데이터베이스 구성 여부#

초기화 시점에 일어나는 작업을 다룰 때 추가로 주의할 점이 있습니다. 몇몇 위치에서는 Gitlab::Geo.geo_database_configured? 메서드로 해당 사이트에 추적 데이터베이스가 있는지 확인하는데, 이 데이터베이스는 secondary 사이트에만 존재합니다. 이렇게 하면 새 사이트를 부트스트랩하는 동안 발생할 수 있는 경쟁 조건을 극복할 수 있습니다.

활성화#

사용자가 해당 기능이 포함된 유효한 라이선스를 보유하고 Geo Nodes 화면에 사이트를 하나 이상 정의한 경우에 Geo 기능이 활성화된 것으로 간주합니다.

Gitlab::Geo.enabled? 및 Gitlab::Geo.license_allows? 메서드를 참고합니다.

읽기 전용#

모든 Geo secondary 사이트는 읽기 전용입니다.

읽기 전용 데이터베이스의 일반 원칙은 모든 Geo secondary 사이트에 적용됩니다. 따라서 Gitlab::Database.read_only? 메서드는 secondary 사이트에서 항상 true를 반환합니다.

사이트가 secondary이기 때문에 일부 쓰기 동작이 허용되지 않을 때는 Gitlab::Geo.secondary? 대신 Gitlab::Database.read_only? 또는 Gitlab::Database.read_write? 가드를 추가하는 것을 검토합니다.

복제 구성에서는 데이터베이스 자체가 이미 읽기 전용이므로, 그에 대해 추가 조치를 할 필요가 없습니다.

새 기능에 Geo 지원 보장#

Geo는 메인 데이터베이스와 CI 데이터베이스의 PostgreSQL 복제에 의존하므로, 새 테이블이나 필드를 추가하면 secondary Geo 사이트에서 이미 동작합니다.

그러나 메인 PostgreSQL 데이터베이스와 CI PostgreSQL 데이터베이스 외부에 저장되는 새로운 종류의 데이터를 도입하는 경우에는 그 데이터가 Geo로 복제되고 검증되도록 해야 합니다. 이는 고객이 재해 복구를 위해 secondary 사이트에 의존할 수 있도록 하기 위해 필요합니다.

다음 하위 절에서는 작업이 필요한지 판단하는 방법과, 필요한 경우 진행하는 방법을 설명합니다. 문의 사항이 있으면 Geo 팀에 문의합니다.

직접 만든 기능과 비교하려면 지원되는 Geo 데이터 유형을 참고합니다. Geo가 복제하고 검증하는 데이터 유형의 자세하고 최신인 목록이 있습니다.

Geo 복제와 GitLab 데이터 저장소#

복제된 데이터#

이 예시 다이어그램은 복제되는 GitLab 데이터를 보여 줍니다. GitLab 환경에는 가능한 구성이 많습니다. 이 다이어그램이 모든 경우를 완전히 담으려는 것은 아닙니다.

---
config:
  layout: elk
---
graph TB
  Users((Users))
subgraph GitLab Primary Site
Gitaly("Gitaly<br>• Git repositories")
GitLabApp("GitLab Application")
PostgreSQL("PostgreSQL<br>• Group metadata<br>• Project metadata<br>• OpenBao data")
PostgreSQL2("PostgreSQL<br>• Manifests<br>• Tags<br>• Repositories")
Registry("Registry<br>(GitLab Application does not control its datastores)")
Filesystem("Filesystem<br>• LFS objects<br>• Job artifacts<br>• Attachments<br>• MR diffs")
ObjectStorage("Object Storage<br>• LFS objects<br>• Job artifacts<br>• Attachments<br>• MR diffs")
ObjectStorage2("Object Storage<br>• Container image layers<br>• Manifests if legacy registry<br>• Tags if legacy registry")
GitLabApp &lt;--&gt; Gitaly
GitLabApp --&gt; PostgreSQL
GitLabApp &lt;--&gt; Registry
GitLabApp --&gt; ObjectStorage
GitLabApp --&gt; Filesystem

Registry --&gt; PostgreSQL2
Registry --&gt; ObjectStorage2

end
subgraph GitLab Secondary Site
2Gitaly(Gitaly<br>• Git repositories)
2GitLabApp("GitLab Application")
2PostgreSQL("PostgreSQL<br>(read-only replica)<br>• Group metadata<br>• Project metadata<br>• OpenBao data")
2PostgreSQL2("PostgreSQL<br>• Manifests<br>• Tags<br>• Repositories")
2TrackingDB("Geo Tracking DB<br>(PostgreSQL)<br>• Replication state<br>• Verification state<br>• Registry tables")
2Registry(Registry)
2Filesystem("Filesystem<br>• LFS objects<br>• Job artifacts<br>• Attachments<br>• MR diffs")
2ObjectStorage("Object Storage<br>• LFS objects<br>• Job artifacts<br>• Attachments<br>• MR diffs")
2ObjectStorage2("Object Storage<br>• Container image layers<br>• Manifests if legacy registry<br>• Tags if legacy registry")
2GitLabApp &lt;--&gt; 2Gitaly
2GitLabApp --&gt; 2PostgreSQL
2GitLabApp --&gt; 2TrackingDB
2GitLabApp &lt;--&gt; 2Registry
2GitLabApp --&gt; 2ObjectStorage
2GitLabApp --&gt; 2Filesystem

2Registry --&gt; 2PostgreSQL2
2Registry --&gt; 2ObjectStorage2

end
Users --> 2GitLabApp
Users --> GitLabApp
Users --> Registry
2GitLabApp -.-> |Download files<br>• Managed by Geo SSF<br>• LFS objects<br>• Job artifacts<br>• Attachments<br>• MR diffs| GitLabApp
2GitLabApp -.-> |Pull registry tags<br>• Managed by Geo SSF| Registry
PostgreSQL -.-> |Streaming replication<br>• Configured by sysadmin| 2PostgreSQL
2Gitaly -.-> |Git fetch<br>• Managed by Geo SSF| GitLabApp

복제되지 않는 데이터#

이 예시 다이어그램은 복제되지 않는 GitLab 데이터를 보여 줍니다. GitLab 환경에는 가능한 구성이 많습니다. 이 다이어그램이 모든 경우를 완전히 담으려는 것은 아닙니다.

graph TB
  Users((Users))
subgraph GitLab Secondary Site
2GitLabApp("GitLab Application")
2Redis("Redis<br>• CI job trace chunks<br>• User sessions<br>• Background job queues<br>• Temporary caches")
2Elasticsearch("Elasticsearch")
2Clickhouse("Clickhouse")
2Prometheus("Prometheus<br>• Application metrics")
2GitLabApp --&gt; 2Redis
2GitLabApp --&gt; 2Elasticsearch
2GitLabApp --&gt; 2Clickhouse
2GitLabApp --&gt; 2Prometheus

end
subgraph GitLab Primary Site
GitLabApp("GitLab Application")
Redis("Redis<br>• CI job trace chunks<br>• User sessions<br>• Background job queues<br>• Temporary caches")
Elasticsearch("Elasticsearch")
Clickhouse("Clickhouse")
IAMService("IAM services<br>• LDAP<br>• SAML")
Prometheus("Prometheus<br>• Application metrics")
GitLabApp --&gt; Redis
GitLabApp --&gt; Elasticsearch
GitLabApp --&gt; Clickhouse
GitLabApp --&gt; IAMService
GitLabApp --&gt; Prometheus

end
Users --> 2GitLabApp
Users --> GitLabApp
Users --> IAMService

Git 리포지터리#

Git 리포지터리를 기반으로 하는 기능을 추가하는 경우에는 Geo 지원을 추가해야 합니다. Geo 셀프 서비스 프레임워크의 리포지터리 리플리케이터 전략을 참고합니다.

Geo Replicate a new blob type 템플릿을 기반으로 이슈를 만들고 가이드라인을 따릅니다.

Blob#

CarrierWave::Uploader::Base의 서브클래스를 추가하면 Geo가 blob이라고 부르는 것을 추가하는 것입니다. 일반적으로 권장되는 대로 AttachmentUploader를 서브클래싱하면 별도 작업 없이 데이터에 Geo 지원이 적용됩니다. AttachmentUploader가 uploads 테이블을 사용해 Upload 모델로 blob을 추적하고, 그 모델에 대한 Geo 지원이 이미 구현되어 있기 때문입니다.

GitLab.com 규모에서 수백만 행을 예상하는 등의 이유로 blob을 새 테이블에서 추적한다면 Geo 지원을 추가해야 합니다. Geo 셀프 서비스 프레임워크의 blob 리플리케이터 전략을 참고합니다.

Geo는 스펙으로 새 blob을 감지하며, 이 스펙은 Uploader에 대응하는 Replicator가 없으면 실패합니다.

Geo Replicate a new Git repository type 템플릿을 기반으로 이슈를 만들고 가이드라인을 따릅니다.

두 종류 이상의 데이터를 가진 기능#

새로운 복잡한 기능이 여러 종류의 데이터, 예를 들어 Git 리포지터리와 blob을 기반으로 한다면, 각 데이터 종류를 따로 검토해도 무리가 없습니다.

디자인을 예로 들면, 각 이슈에는 여러 LFS 객체를 가질 수 있는 Git 리포지터리가 있고, 각 LFS 객체에는 자동으로 생성된 썸네일이 있을 수 있습니다.

• LFS 객체는 Geo가 이미 지원했으므로 Geo 관련 작업이 필요하지 않았습니다.
• 썸네일 구현은 Upload 모델을 재사용했으므로 Geo 관련 작업이 필요하지 않았습니다.
• 디자인 Git 리포지터리는 Geo가 본래 지원하지 않았으므로 작업이 필요했습니다.

또 다른 예로 의존성 프록시는 DependencyProxy::Blob과 DependencyProxy::Manifest라는 두 종류의 blob을 기반으로 합니다. 각 유형에 Geo 셀프 서비스 프레임워크의 blob 리플리케이터 전략을 서로 독립적으로 적용할 수 있습니다.

기타 종류의 데이터#

새 기능이 Git 리포지터리도 blob도, 둘의 조합도 아닌 새로운 종류의 데이터를 도입한다면, Geo 팀에 연락해 처리 방법을 논의합니다.

예를 들어 컨테이너 레지스트리 데이터는 위 범주에 잘 들어맞지 않습니다. 데이터를 소유한 레지스트리 서비스가 뒤를 받치고 있고, GitLab은 레지스트리 서비스의 API와 상호 작용합니다. 따라서 컨테이너 레지스트리의 Geo 지원에는 일회성 접근이 필요합니다. 그래도 Geo 셀프 서비스 프레임워크의 글루 코드 상당 부분은 재사용할 수 있습니다.

셀프 서비스 프레임워크#

작업 중인 리소스를 Geo로 쉽게 복제하고 싶다면 셀프 서비스 프레임워크를 확인합니다.

Geo 개발 워크플로#

GET:Geo 파이프라인#

e2e:test-on-omnibus-ee 파이프라인을 성공적으로 트리거한 다음, GET:Geo라는 job을 수동으로 트리거할 수 있습니다.

1. GitLab 프로젝트에서 머지 리퀘스트의 Pipelines 탭을 선택합니다.
2. 최신 파이프라인에서 Stage: qa 스테이지를 선택해 펼치고 관련된 모든 job을 나열합니다.
3. 트리거 job e2e:test-on-omnibus-ee를 선택해 하위 파이프라인으로 이동합니다.
4. trigger-omnibus를 선택해 해당 머지 리퀘스트에 대응하는 Omnibus GitLab Mirror 파이프라인을 확인합니다.
5. GET:Geo job은 trigger-qa 스테이지 아래에서 찾아 트리거할 수 있습니다.

이 파이프라인은 GET을 사용해 20 RPS / 1k 사용자 규모의 Geo 설치를 띄우고, 해당 인스턴스를 대상으로 gitlab-qa Geo 시나리오를 실행합니다. Geo 기능을 작업할 때는 트리거된 GET:Geo pipeline에서 qa-geo job이 통과하는지 확인하는 것이 좋습니다.

인스턴스의 프로비저닝과 해체를 제어하는 파이프라인은 The GitLab Environment Toolkit Configs Geo 하위 프로젝트에 포함되어 있습니다.

새 기능을 추가할 때는 그 동작을 검증하는 새 테스트를 추가하는 것을 검토합니다. 절차는 QA 문서를 참고합니다.

아키텍처#

이 파이프라인에는 서로 다른 여러 프로젝트의 상호 작용이 관여합니다.

• GitLab - 이 프로젝트의 머지 리퀘스트에서 e2e:test-on-omnibus-ee job이 시작됩니다.
• omnibus-gitlab - 트리거한 머지 리퀘스트 파이프라인의 변경 사항이 담긴 관련 아티팩트를 빌드합니다.
• GET-Configs/Geo - 평가할 수 있는 단기 Geo 설치의 수명 주기를 조율합니다.
• GET - Geo 설치를 생성하고 제거하는 데 필요한 로직이 담겨 있습니다. GET-Configs/Geo가 사용합니다.
• gitlab-qa - GitLab 인스턴스를 대상으로 자동화 테스트를 실행하는 도구입니다.

flowchart TD;
  GET:Geo-->getcg
  Provision-->Terraform
  Configure-->Ansible
  Geo-->Ansible
  QA-->gagq
subgraph "omnibus-gitlab-mirror"
GET:Geo
end
subgraph getcg [GitLab-environment-toolkit-configs/Geo]
direction LR
Generate-terraform-config-->Provision
Provision-->Generate-ansible-config
Generate-ansible-config-->Configure
Configure-->Geo
Geo-->QA
QA-->Destroy-geo
end
subgraph get [GitLab Environment Toolkit]
Terraform
Ansible
end
subgraph GitLab QA
gagq[GitLab QA Geo Scenario]
end