InfoGrab DocsInfoGrab Docs

Geo (개발)

요약

Geo는 GitLab 인스턴스를 서로 연결합니다. ](/19.2/development/img/geo_architecture_v13_8.png) Geo는 다양한 구성 요소에 대한 복제를 처리합니다. 데이터베이스: 캐시와 job을 제외한 전체 애플리케이션을 포함합니다.

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

[

](/19.2/development/img/geo_architecture_v13_8.png)

복제 계층#

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 데몬은 자동으로 고가용성(High Availability) 모드에서 작동할 수 있습니다. 데몬은 주기적으로 잠금 획득을 시도하며, 일단 획득하면 활성 데몬으로 동작합니다.

동일한 사이트에서 추가로 실행 중인 데몬은 대기 모드로 전환되어, 활성 데몬이 잠금을 해제하면 즉시 작업을 재개할 준비가 됩니다.

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

폴링 사이클이 끝날 때 데몬이 잠금을 갱신하거나 재획득하지 못하면, 대기 모드로 전환됩니다.

데이터베이스 복제#

Geo는 스트리밍 복제를 사용하여 primary에서 secondary 사이트로 데이터베이스를 복제합니다. 이 복제를 통해 secondary 사이트는 데이터베이스에 저장된 모든 데이터에 접근할 수 있으며, 사용자는 secondary 사이트에 로그인하여 모든 이슈와 머지 리퀘스트 등을 읽을 수 있습니다.

리포지터리 복제#

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

리포지터리 동기화 플로와 리스 메커니즘에 대한 자세한 내용은 리포지터리 동기화 문서를 참조하세요.

Blob 복제#

Blob 복제 플로에 대한 자세한 내용은 Blob 복제 문서를 참조하세요.

인증#

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

  • 공개 액세스 키(access_key 필드).

  • 비밀 액세스 키(secret_access_key 필드).

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

secondary 사이트는 Authorization 헤더를 사용하여 HTTP 요청을 인가합니다.

Authorization: GL-Geo <access_key>:

primary 사이트는 access_key 필드를 사용하여 해당하는 secondary 사이트를 조회하고 JWT 페이로드를 복호화합니다.

JWT는 관련된 머신들 간의 동기화된 클럭을 필요로 합니다. 그렇지 않으면 **primary** 사이트가 요청을 거부할 수 있습니다.

파일 전송#

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 프록시는 gitlab-shell 구성 요소 내에 내장된 기능으로 존재합니다. secondary 사이트에서만 활성화됩니다. 이를 통해 secondary 사이트에서 리포지터리를 클론한 사용자가 동일한 URL로 push할 수 있습니다.

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는 추적 데이터베이스와 기본 데이터베이스에서 프로젝트/첨부 파일 등을 조회하는 복잡한 작업을 처리하는 클래스인 Finders를 사용합니다.

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 참조를 해시하여 데이터베이스의 project_repository_states 테이블에 해당 해시를 저장합니다.

secondary 사이트는 동일한 방식으로 클론의 해시를 계산하고, primary 사이트가 계산한 값과 비교합니다. 불일치가 있으면 Geo는 이를 불일치로 표시하며, 관리자는 Geo Admin 영역에서 이를 확인할 수 있습니다.

Geo 프록시#

Geo secondary는 primary로 웹 요청을 프록시할 수 있습니다. Geo 프록시 (개발) 페이지에서 더 자세히 알아보세요.

Geo API#

Geo는 외부 API를 사용하여 다양한 구성 요소 간의 통신을 용이하게 합니다.

용어집#

Primary 사이트#

primary 사이트는 Geo 설정에서 읽기-쓰기 기능을 가진 단일 사이트입니다. 단일 진실 공급원(Single Source Of Truth, SSOT)이며 Geo secondary 사이트는 여기에서 데이터를 복제합니다.

Geo 설정에서는 primary 사이트가 하나만 있을 수 있습니다. 모든 secondary 사이트는 해당 primary에 연결됩니다.

Secondary 사이트#

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

스트리밍 복제#

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

스트리밍 복제는 WAL(Write Ahead Logs)에 의존합니다. 이 로그는 복제본으로 복사되어 재생됩니다.

스트리밍 복제는 스키마도 복제하므로, 데이터베이스 마이그레이션을 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 복제에 의존하므로, 새 테이블이나 필드를 추가하면 Geo secondary 사이트에서 이미 작동합니다.

그러나 기본 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
• Git repositories") GitLabApp("GitLab Application") PostgreSQL("PostgreSQL
• Group metadata
• Project metadata
• OpenBao data") PostgreSQL2("PostgreSQL
• Manifests
• Tags
• Repositories") Registry("Registry
(GitLab Application does not control its datastores)") Filesystem("Filesystem
• LFS objects
• Job artifacts
• Attachments
• MR diffs") ObjectStorage("Object Storage
• LFS objects
• Job artifacts
• Attachments
• MR diffs") ObjectStorage2("Object Storage
• Container image layers
• Manifests if legacy registry
• Tags if legacy registry")

GitLabApp <--> Gitaly
GitLabApp --> PostgreSQL
GitLabApp <--> Registry
GitLabApp --> ObjectStorage
GitLabApp --> Filesystem

Registry --> PostgreSQL2
Registry --> ObjectStorage2

end

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

2GitLabApp <--> 2Gitaly
2GitLabApp --> 2PostgreSQL
2GitLabApp --> 2TrackingDB
2GitLabApp <--> 2Registry
2GitLabApp --> 2ObjectStorage
2GitLabApp --> 2Filesystem

2Registry --> 2PostgreSQL2
2Registry --> 2ObjectStorage2

end

Users --> 2GitLabApp Users --> GitLabApp Users --> Registry

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

복제되지 않은 데이터#

이 예시 다이어그램은 복제되지 않는 GitLab 데이터를 보여줍니다. GitLab 환경에는 다양한 구성이 가능합니다. 이 다이어그램은 모든 경우를 완전히 포괄하지는 않습니다.

graph TB Users((Users))

subgraph GitLab Secondary Site 2GitLabApp("GitLab Application") 2Redis("Redis
• CI job trace chunks
• User sessions
• Background job queues
• Temporary caches") 2Elasticsearch("Elasticsearch") 2Clickhouse("Clickhouse") 2Prometheus("Prometheus
• Application metrics")

2GitLabApp --> 2Redis
2GitLabApp --> 2Elasticsearch
2GitLabApp --> 2Clickhouse
2GitLabApp --> 2Prometheus

end

subgraph GitLab Primary Site GitLabApp("GitLab Application") Redis("Redis
• CI job trace chunks
• User sessions
• Background job queues
• Temporary caches") Elasticsearch("Elasticsearch") Clickhouse("Clickhouse") IAMService("IAM services
• LDAP
• SAML") Prometheus("Prometheus
• Application metrics")

GitLabApp --> Redis
GitLabApp --> Elasticsearch
GitLabApp --> Clickhouse
GitLabApp --> IAMService
GitLabApp --> Prometheus

end

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

Git 리포지터리#

Git 리포지터리로 지원되는 기능을 추가하는 경우, Geo 지원을 추가해야 합니다. Geo 셀프서비스 프레임워크의 리포지터리 복제기 전략을 참조하세요.

Geo 새 Blob 유형 복제 템플릿을 기반으로 이슈를 생성하고 가이드라인을 따르세요.

Blob#

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

Blob이 새 테이블에서 추적되는 경우(예: GitLab.com 규모에서 수백만 행이 예상되는 경우), Geo 지원을 추가해야 합니다. Geo 셀프서비스 프레임워크의 Blob 복제기 전략을 참조하세요.

Geo는 spec으로 새 Blob을 탐지하며, Uploader에 해당하는 Replicator가 없을 때 실패합니다.

Geo 새 Git 리포지터리 유형 복제 템플릿을 기반으로 이슈를 생성하고 가이드라인을 따르세요.

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

새로운 복잡한 기능이 여러 종류의 데이터(예: Git 리포지터리와 Blob)로 지원되는 경우, 각 종류의 데이터를 별도로 고려할 수 있습니다.

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

  • LFS 객체는 이미 Geo에서 지원되었으므로 Geo 관련 작업이 필요하지 않았습니다.

  • 썸네일 구현은 Upload 모델을 재사용하였으므로 Geo 관련 작업이 필요하지 않았습니다.

  • Design Git 리포지터리는 기본적으로 Geo에서 지원되지 않았으므로 작업이 필요했습니다.

또 다른 예로, Dependency Proxy는 두 종류의 Blob, DependencyProxy::Blob과 DependencyProxy::Manifest로 지원됩니다. 서로 독립적으로 각 유형에 Geo 셀프서비스 프레임워크의 Blob 복제기 전략을 사용할 수 있습니다.

기타 종류의 데이터#

새 기능이 Git 리포지터리도 아니고 Blob도 아니며 둘의 조합도 아닌 새로운 종류의 데이터를 도입하는 경우, 처리 방법에 대해 Geo 팀에 문의하세요.

예를 들어, 컨테이너 레지스트리 데이터는 위의 범주에 쉽게 맞지 않습니다. 데이터를 소유하는 레지스트리 서비스로 지원되며, GitLab은 레지스트리 서비스의 API와 상호 작용합니다. 따라서 컨테이너 레지스트리의 Geo 지원을 위한 일회성 접근 방식이 필요합니다. 그럼에도 불구하고 Geo 셀프서비스 프레임워크의 글루 코드를 많이 재사용할 수 있습니다.

셀프서비스 프레임워크#

작업 중인 리소스에 Geo 복제를 쉽게 추가하려면 셀프서비스 프레임워크를 확인하세요.

Geo 개발 워크플로#

GET:Geo 파이프라인#

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

  • GitLab 프로젝트에서 머지 리퀘스트의 Pipelines 탭을 선택합니다.

  • 최신 파이프라인에서 Stage: qa Stage를 선택하여 모든 관련 job을 확장하고 나열합니다.

  • 트리거 job e2e:test-on-omnibus-ee를 선택하여 하위 파이프라인 내부로 이동합니다.

  • trigger-omnibus를 선택하여 머지 리퀘스트에 해당하는 Omnibus GitLab Mirror 파이프라인을 확인합니다.

  • GET:Geo job은 trigger-qa Stage 아래에서 찾고 트리거할 수 있습니다.

이 파이프라인은 GET을 사용하여 20 RPS / 1k 사용자 Geo 설치를 구성하고, 인스턴스에 대해 gitlab-qa Geo 시나리오를 실행합니다. Geo 기능을 개발할 때, 트리거된 GET:Geo 파이프라인에서 qa-geo job이 통과하는지 확인하는 것이 좋습니다.

인스턴스의 프로비저닝 및 종료를 제어하는 파이프라인은 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

Geo (개발)

GitLab v19.2
원문 보기
요약

Geo는 GitLab 인스턴스를 서로 연결합니다. ](/19.2/development/img/geo_architecture_v13_8.png) Geo는 다양한 구성 요소에 대한 복제를 처리합니다. 데이터베이스: 캐시와 job을 제외한 전체 애플리케이션을 포함합니다.

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

[

](/19.2/development/img/geo_architecture_v13_8.png)

복제 계층#

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 데몬은 자동으로 고가용성(High Availability) 모드에서 작동할 수 있습니다. 데몬은 주기적으로 잠금 획득을 시도하며, 일단 획득하면 활성 데몬으로 동작합니다.

동일한 사이트에서 추가로 실행 중인 데몬은 대기 모드로 전환되어, 활성 데몬이 잠금을 해제하면 즉시 작업을 재개할 준비가 됩니다.

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

폴링 사이클이 끝날 때 데몬이 잠금을 갱신하거나 재획득하지 못하면, 대기 모드로 전환됩니다.

데이터베이스 복제#

Geo는 스트리밍 복제를 사용하여 primary에서 secondary 사이트로 데이터베이스를 복제합니다. 이 복제를 통해 secondary 사이트는 데이터베이스에 저장된 모든 데이터에 접근할 수 있으며, 사용자는 secondary 사이트에 로그인하여 모든 이슈와 머지 리퀘스트 등을 읽을 수 있습니다.

리포지터리 복제#

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

리포지터리 동기화 플로와 리스 메커니즘에 대한 자세한 내용은 리포지터리 동기화 문서를 참조하세요.

Blob 복제#

Blob 복제 플로에 대한 자세한 내용은 Blob 복제 문서를 참조하세요.

인증#

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

  • 공개 액세스 키(access_key 필드).

  • 비밀 액세스 키(secret_access_key 필드).

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

secondary 사이트는 Authorization 헤더를 사용하여 HTTP 요청을 인가합니다.

Authorization: GL-Geo <access_key>:

primary 사이트는 access_key 필드를 사용하여 해당하는 secondary 사이트를 조회하고 JWT 페이로드를 복호화합니다.

JWT는 관련된 머신들 간의 동기화된 클럭을 필요로 합니다. 그렇지 않으면 **primary** 사이트가 요청을 거부할 수 있습니다.

파일 전송#

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 프록시는 gitlab-shell 구성 요소 내에 내장된 기능으로 존재합니다. secondary 사이트에서만 활성화됩니다. 이를 통해 secondary 사이트에서 리포지터리를 클론한 사용자가 동일한 URL로 push할 수 있습니다.

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는 추적 데이터베이스와 기본 데이터베이스에서 프로젝트/첨부 파일 등을 조회하는 복잡한 작업을 처리하는 클래스인 Finders를 사용합니다.

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 참조를 해시하여 데이터베이스의 project_repository_states 테이블에 해당 해시를 저장합니다.

secondary 사이트는 동일한 방식으로 클론의 해시를 계산하고, primary 사이트가 계산한 값과 비교합니다. 불일치가 있으면 Geo는 이를 불일치로 표시하며, 관리자는 Geo Admin 영역에서 이를 확인할 수 있습니다.

Geo 프록시#

Geo secondary는 primary로 웹 요청을 프록시할 수 있습니다. Geo 프록시 (개발) 페이지에서 더 자세히 알아보세요.

Geo API#

Geo는 외부 API를 사용하여 다양한 구성 요소 간의 통신을 용이하게 합니다.

용어집#

Primary 사이트#

primary 사이트는 Geo 설정에서 읽기-쓰기 기능을 가진 단일 사이트입니다. 단일 진실 공급원(Single Source Of Truth, SSOT)이며 Geo secondary 사이트는 여기에서 데이터를 복제합니다.

Geo 설정에서는 primary 사이트가 하나만 있을 수 있습니다. 모든 secondary 사이트는 해당 primary에 연결됩니다.

Secondary 사이트#

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

스트리밍 복제#

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

스트리밍 복제는 WAL(Write Ahead Logs)에 의존합니다. 이 로그는 복제본으로 복사되어 재생됩니다.

스트리밍 복제는 스키마도 복제하므로, 데이터베이스 마이그레이션을 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 복제에 의존하므로, 새 테이블이나 필드를 추가하면 Geo secondary 사이트에서 이미 작동합니다.

그러나 기본 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
• Git repositories") GitLabApp("GitLab Application") PostgreSQL("PostgreSQL
• Group metadata
• Project metadata
• OpenBao data") PostgreSQL2("PostgreSQL
• Manifests
• Tags
• Repositories") Registry("Registry
(GitLab Application does not control its datastores)") Filesystem("Filesystem
• LFS objects
• Job artifacts
• Attachments
• MR diffs") ObjectStorage("Object Storage
• LFS objects
• Job artifacts
• Attachments
• MR diffs") ObjectStorage2("Object Storage
• Container image layers
• Manifests if legacy registry
• Tags if legacy registry")

GitLabApp <--> Gitaly
GitLabApp --> PostgreSQL
GitLabApp <--> Registry
GitLabApp --> ObjectStorage
GitLabApp --> Filesystem

Registry --> PostgreSQL2
Registry --> ObjectStorage2

end

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

2GitLabApp <--> 2Gitaly
2GitLabApp --> 2PostgreSQL
2GitLabApp --> 2TrackingDB
2GitLabApp <--> 2Registry
2GitLabApp --> 2ObjectStorage
2GitLabApp --> 2Filesystem

2Registry --> 2PostgreSQL2
2Registry --> 2ObjectStorage2

end

Users --> 2GitLabApp Users --> GitLabApp Users --> Registry

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

복제되지 않은 데이터#

이 예시 다이어그램은 복제되지 않는 GitLab 데이터를 보여줍니다. GitLab 환경에는 다양한 구성이 가능합니다. 이 다이어그램은 모든 경우를 완전히 포괄하지는 않습니다.

graph TB Users((Users))

subgraph GitLab Secondary Site 2GitLabApp("GitLab Application") 2Redis("Redis
• CI job trace chunks
• User sessions
• Background job queues
• Temporary caches") 2Elasticsearch("Elasticsearch") 2Clickhouse("Clickhouse") 2Prometheus("Prometheus
• Application metrics")

2GitLabApp --> 2Redis
2GitLabApp --> 2Elasticsearch
2GitLabApp --> 2Clickhouse
2GitLabApp --> 2Prometheus

end

subgraph GitLab Primary Site GitLabApp("GitLab Application") Redis("Redis
• CI job trace chunks
• User sessions
• Background job queues
• Temporary caches") Elasticsearch("Elasticsearch") Clickhouse("Clickhouse") IAMService("IAM services
• LDAP
• SAML") Prometheus("Prometheus
• Application metrics")

GitLabApp --> Redis
GitLabApp --> Elasticsearch
GitLabApp --> Clickhouse
GitLabApp --> IAMService
GitLabApp --> Prometheus

end

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

Git 리포지터리#

Git 리포지터리로 지원되는 기능을 추가하는 경우, Geo 지원을 추가해야 합니다. Geo 셀프서비스 프레임워크의 리포지터리 복제기 전략을 참조하세요.

Geo 새 Blob 유형 복제 템플릿을 기반으로 이슈를 생성하고 가이드라인을 따르세요.

Blob#

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

Blob이 새 테이블에서 추적되는 경우(예: GitLab.com 규모에서 수백만 행이 예상되는 경우), Geo 지원을 추가해야 합니다. Geo 셀프서비스 프레임워크의 Blob 복제기 전략을 참조하세요.

Geo는 spec으로 새 Blob을 탐지하며, Uploader에 해당하는 Replicator가 없을 때 실패합니다.

Geo 새 Git 리포지터리 유형 복제 템플릿을 기반으로 이슈를 생성하고 가이드라인을 따르세요.

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

새로운 복잡한 기능이 여러 종류의 데이터(예: Git 리포지터리와 Blob)로 지원되는 경우, 각 종류의 데이터를 별도로 고려할 수 있습니다.

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

  • LFS 객체는 이미 Geo에서 지원되었으므로 Geo 관련 작업이 필요하지 않았습니다.

  • 썸네일 구현은 Upload 모델을 재사용하였으므로 Geo 관련 작업이 필요하지 않았습니다.

  • Design Git 리포지터리는 기본적으로 Geo에서 지원되지 않았으므로 작업이 필요했습니다.

또 다른 예로, Dependency Proxy는 두 종류의 Blob, DependencyProxy::Blob과 DependencyProxy::Manifest로 지원됩니다. 서로 독립적으로 각 유형에 Geo 셀프서비스 프레임워크의 Blob 복제기 전략을 사용할 수 있습니다.

기타 종류의 데이터#

새 기능이 Git 리포지터리도 아니고 Blob도 아니며 둘의 조합도 아닌 새로운 종류의 데이터를 도입하는 경우, 처리 방법에 대해 Geo 팀에 문의하세요.

예를 들어, 컨테이너 레지스트리 데이터는 위의 범주에 쉽게 맞지 않습니다. 데이터를 소유하는 레지스트리 서비스로 지원되며, GitLab은 레지스트리 서비스의 API와 상호 작용합니다. 따라서 컨테이너 레지스트리의 Geo 지원을 위한 일회성 접근 방식이 필요합니다. 그럼에도 불구하고 Geo 셀프서비스 프레임워크의 글루 코드를 많이 재사용할 수 있습니다.

셀프서비스 프레임워크#

작업 중인 리소스에 Geo 복제를 쉽게 추가하려면 셀프서비스 프레임워크를 확인하세요.

Geo 개발 워크플로#

GET:Geo 파이프라인#

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

  • GitLab 프로젝트에서 머지 리퀘스트의 Pipelines 탭을 선택합니다.

  • 최신 파이프라인에서 Stage: qa Stage를 선택하여 모든 관련 job을 확장하고 나열합니다.

  • 트리거 job e2e:test-on-omnibus-ee를 선택하여 하위 파이프라인 내부로 이동합니다.

  • trigger-omnibus를 선택하여 머지 리퀘스트에 해당하는 Omnibus GitLab Mirror 파이프라인을 확인합니다.

  • GET:Geo job은 trigger-qa Stage 아래에서 찾고 트리거할 수 있습니다.

이 파이프라인은 GET을 사용하여 20 RPS / 1k 사용자 Geo 설치를 구성하고, 인스턴스에 대해 gitlab-qa Geo 시나리오를 실행합니다. Geo 기능을 개발할 때, 트리거된 GET:Geo 파이프라인에서 qa-geo job이 통과하는지 확인하는 것이 좋습니다.

인스턴스의 프로비저닝 및 종료를 제어하는 파이프라인은 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