Geo (개발)

Geo는 GitLab 인스턴스를 서로 연결합니다. 하나의 GitLab 인스턴스는 기본 사이트로 지정되어 여러 보조 사이트와 함께 실행할 수 있습니다. Geo는 아래 다이어그램에서 볼 수 있는 여러 컴포넌트를 조율하며, 본 문서에서 자세히 설명됩니다.

Geo 아키텍처 다이어그램

복제 레이어

Geo는 다양한 컴포넌트에 대한 복제를 처리합니다:

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

데이터베이스 복제를 제외한 모든 것은 보조 사이트에서 Geo Log Cursor에 의해 조정됩니다.

복제 상태

다음 다이어그램은 복제 동작을 설명합니다. 가독성을 위해 일부 허용된 전환은 생략되었습니다.

stateDiagram-v2 Pending --> Started Started --> Synced Started --> Failed Synced --> Pending: 다시 동기화할 표시 Failed --> Pending: 다시 동기화할 표시 Failed --> Started: 다시 시도

Geo Log Cursor 데몬

Geo Log Cursor 데몬은 각 보조 사이트에서 실행되는 별도의 프로세스입니다. 이는 새 이벤트를 모니터하고 각 특정 이벤트 유형에 대한 백그라운드 작업을 만드는 Geo 이벤트 로그를 감시합니다.

예를 들어, 리포지터리가 업데이트되면, Geo 기본 사이트는 연관된 리포지터리 업데이트 이벤트를 포함한 Geo 이벤트를 생성합니다. 그럼 Geo Log Cursor 데몬은 해당 이벤트를 가져와 Geo::ProjectSyncWorker 작업을 예약하며, 이는 Geo::RepositorySyncService를 사용하여 리포지터리를 업데이트합니다.

Geo Log Cursor 데몬은 자동으로 고가용성 모드에서 운영될 수 있습니다. 데몬은 때때로 잠금을 획들하려고 시도하며, 획들면 활성 데몬으로 작동합니다.

같은 사이트에서 실행 중인 다른 데몬은 대기 모드에 있어 활성 데몬이 잠금을 해제하면 업무를 재개할 수 있습니다.

풀링 주기마다 작은 TTL과 함께 ExclusiveLease 잠금 유형을 사용합니다. 이는 시간 제한이 있는 전역 잠금을 구현할 수 있도록 합니다.

풀링 주기가 종료되면, 데몬이 잠금을 갱신하거나 재획득할 수 없으면, 대기 모드로 전환됩니다.

데이터베이스 복제

Geo는 기본 사이트에서 보조 사이트로 데이터베이스를 복제하기 위해 스트리밍 복제를 사용합니다. 이 복제로 인해 보조 사이트는 데이터베이스에 저장된 모든 데이터에 액세스할 수 있어 사용자가 보조 사이트에 로그인하여 예를 들어 모든 이슈 및 Merge Request을 읽을 수 있습니다.

리포지터리 복제

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

리포지터리는 다음과 같은 방법으로 복제됩니다:

프로젝트 레지스트리

Geo::ProjectRegistry 클래스는 리포지터리 복제의 상태를 추적하는 데 사용되는 모델을 정의합니다. 기본 데이터베이스에 있는 각 프로젝트에 대해 트래킹 데이터베이스에 하나의 레코드가 유지됩니다.

리포지터리에 대해 다음 정보를 기록합니다:

  • 최종 동기화 시간.
  • 마지막으로 성공적으로 동기화된 시간.
  • 다시 동기화해야 하는지 여부.
  • 다시 시도해야 하는 시간.
  • 다시 시도 횟수.
  • 확인되었는지 여부 및 시간.

프로젝트 위키에 대해서도 전용 열에 대해 동일한 속성을 저장합니다.

리포지터리 동기화 워커

Geo::RepositorySyncWorker 클래스는 주기적으로 백그라운드에서 실행되며 업데이트가 필요한 프로젝트를 검색합니다. 해당 프로젝트는 다음과 같습니다:

  • 동기화되지 않은 프로젝트: 보조 사이트에 아직 동기화되지 않은 프로젝트로 아직 존재하지 않음.
  • 최근에 업데이트된 프로젝트: Geo::ProjectRegistry 모델의 last_repository_updated_at 타임스탬프가 last_repository_successful_sync_at 타임스탬프보다 최근임.
  • 매뉴얼으로: 관리자는 Geo 관리 영역에서 리포지터리를 매뉴얼으로 다시 동기화할 수 있습니다.

보조 사이트에서 리포지터리를 가져올 때 RETRIES_BEFORE_REDOWNLOAD회 실패하면, Geo는 이를 재다운로드라고 합니다. 이는 리포지터리의 루트에 있는 @geo-temporary 디렉터리로 깨끗한 복제를 수행합니다. 성공하면, 새롭게 복제된 리포지터리로 기본 리포지터리를 교체합니다.

Blob 복제

업로드와 같은 Blob(대용량 데이터 덩어리)은 Self-Service Framework를 사용하여 보조 사이트로 복제됩니다. 동기화 상태를 추적하기 위해 각 모델에 해당하는 레지스트리 테이블이 있으며, 예를 들어 Upload는 PostgreSQL Geo Tracking Database에 Geo::UploadRegistry를 가지고 있습니다.

서비스 간 Blob 복제 행복 경로 워크플로우

작업 아티팩트는 한 예로서 다이어그램에서 사용됩니다.

새 작업 아티팩트 복제

기본 사이트:

sequenceDiagram participant R as Runner participant P as Puma participant DB as PostgreSQL participant SsP as 보조 사이트 PostgreSQL R->>P: 아티팩트 업로드 P->>DB: `ci_job_artifacts` 행 삽입 P->>DB: `geo_events` 행 삽입 P->>DB: `geo_event_log` 행 삽입 DB->>SsP: 행 복제
  • Runner가 아티팩트를 업로드합니다.
  • Puma가 ci_job_artifacts 행을 삽입합니다.
  • Puma가 “Job Artifact with ID 123 was updated”와 같은 데이터를 가진 geo_events 행을 삽입합니다.
  • Puma가 geo_event_log 행을 삽입하고 geo_events 행을 가리킵니다(일부 레거시 로직 위에 SSF를 빌드했기 때문에).
  • PostgreSQL 스트리밍 복제는 읽기 전용 레플리카에 행을 삽입합니다.

PostgreSQL DB 행이 복제된 후의 보조 사이트:

sequenceDiagram participant DB as PostgreSQL participant GLC as Geo Log Cursor participant R as Redis participant S as Sidekiq participant TDB as 추적 데이터베이스 PostgreSQL participant PP as 기본 사이트 Puma GLC->>DB: `geo_event_log` 조회 GLC->>DB: `geo_events` 조회 GLC->>R: `Geo::EventWorker`를 큐에 추가 S->>R: `Geo::EventWorker` 픽업 S->>TDB: `job_artifact_registry`에 "동기화 시작" 삽입 S->>PP: <기본 사이트 내부 URL>로부터 `job_artifact/123` 검색 S->>TDB: `job_artifact_registry` 업데이트, "동기화됨"
  • Geo Log Cursor 루프가 새 geo_event_log 행을 찾습니다.
  • Geo Log Cursor가 geo_events 행을 처리합니다.
    • Geo Log Cursor가 geo_events 행 데이터를 전달하는 Geo::EventWorker 작업을 큐에 추가합니다.
  • Sidekiq가 Geo::EventWorker 작업을 픽업합니다.
    • Sidekiq는 PostgreSQL Geo Tracking Database의 job_artifact_registry 행을 삽입합니다(존재하지 않으므로) 및 “시작된 동기화”로 표시합니다.
    • Sidekiq은 기본 Geo 사이트에서 API 엔드포인트에 GET 요청을 수행하고 파일을 다운로드합니다.
    • Sidekiq은 job_artifact_registry 행을 “동기화됨” 및 “검증 대기 중”으로 표시합니다.
기존 작업 설명서의 백필(Packfilling)
  • 시스템 관리자는 Geo 없이 기존 GitLab 사이트를 보유하고 있습니다.
  • 기존 CI 작업(job)과 작업 아티팩트가 있습니다.
  • 시스템 관리자는 새로운 GitLab 사이트를 설정하고 보조 Geo 사이트로 구성합니다.

보조 사이트:

매분 두 개의 cron 작업이 실행됩니다. Geo::Secondary::RegistryConsistencyWorker와 Geo::RegistrySyncWorker를 따라 아래 작업 흐름이 둘로 나뉩니다.

sequenceDiagram participant SC as Sidekiq-cron participant R as Redis participant S as Sidekiq participant DB as PostgreSQL participant TDB as PostgreSQL Tracking DB SC->>R: `Geo::Secondary::RegistryConsistencyWorker`를 Enqueue S->>R: `Geo::Secondary::RegistryConsistencyWorker`를 픽업 S->>DB: `ci_job_artifacts`를 쿼리 S->>TDB: `job_artifact_registry`를 쿼리 S->>TDB: `job_artifact_registry`에 삽입
  • Sidekiq-cron은 매 분마다 Geo::Secondary::RegistryConsistencyWorker 작업을 enqueues합니다. 이 작업은 활발하게 작업을 수행하는 동안(행 생성 및 삭제) 즉시 자체를 re-enqueues 합니다. 이 작업은 동시에 여러 인스턴스가 실행되는 것을 방지하기 위해 배타적 임대(exclusive lease)를 사용합니다.
  • Sidekiq은 Geo::Secondary::RegistryConsistencyWorker 작업을 픽업합니다.
    • Sidekiq은 최대 10000행까지의 ci_job_artifacts 테이블을 쿼리합니다.
    • Sidekiq은 최대 10000행까지의 job_artifact_registry 테이블을 쿼리합니다.
    • Sidekiq은 기존 Job Artifact에 해당하는 PostgreSQL Geo Tracking Database에 job_artifact_registry 행을 삽입합니다.
sequenceDiagram participant SC as Sidekiq-cron participant R as Redis participant S as Sidekiq participant DB as PostgreSQL participant TDB as PostgreSQL Tracking DB participant PP as Primary site Puma SC->>R: `Geo::RegistrySyncWorker`를 Enqueue S->>R: `Geo::RegistrySyncWorker`를 픽업 S->>TDB: `*_registry` 테이블을 쿼리 S->>R: `Geo::EventWorker`를 Enqueue S->>R: `Geo::EventWorker`를 픽업 S->>TDB: `job_artifact_registry`에 삽입하여 "sync 시작" S->>PP: <primary site 내부 URL>의 GET /geo/retrieve/job_artifact/123 S->>TDB: `job_artifact_registry`를 업데이트하여 "synced"
  • Sidekiq-cron은 매 분마다 Geo::RegistrySyncWorker 작업을 enqueues합니다. 작업이 활발한 동안 최대 한 시간까지 동기화 작업을 스케줄링합니다. 이 작업은 동시에 여러 인스턴스가 실행되는 것을 방지하기 위해 배타적 임대를 사용합니다.
  • Sidekiq은 Geo::RegistrySyncWorker 작업을 픽업합니다.
    • Sidekiq은 PostgreSQL Geo Tracking Database에 있는 모든 registry 테이블을 “시도하지 않은 동기화” 행을 쿼리합니다. 각 테이블에서 행을 교대로 가져와 메모리 큐에 추가합니다.
    • 이전 단계에서 1000개 미만의 행이 생성된 경우, Sidekiq은 모든 registry 테이블에서 “동기화 실패 및 재시도 준비” 행을 쿼리하고, 이를 메모리 큐에 추가합니다.
    • Sidekiq은 각 항목에 대해 “ID가 123인 Job Artifact가 업데이트되었습니다”와 같은 인수를 가진 Geo::EventWorker 작업을 enqueues하고 enqueued된 Sidekiq 작업 ID를 추적합니다.
    • 설정된 “최대 동시성 제한”에 도달하면 Sidekiq은 더 이상 Geo::EventWorker 작업을 enqueues하지 않습니다.
    • 더 이상 처리할 작업이 없을 때까지 Sidekiq은 이러한 작업을 반복합니다.
  • Sidekiq은 Geo::EventWorker 작업을 픽업합니다.
    • Sidekiq은 job_artifact_registry 행을 “동기화 시작됨”으로 표시합니다.
    • Sidekiq은 주 자 Geo 사이트의 API 엔드포인트에 GET 요청을 수행하여 파일을 다운로드합니다.
    • Sidekiq은 job_artifact_registry 행을 “동기화됨” 및 “검증 대기 중”으로 표시합니다.
새로운 작업 아티팩트 검증

주 사이트:

sequenceDiagram participant Ru as Runner participant P as Puma participant DB as PostgreSQL participant SC as Sidekiq-cron participant Rd as Redis participant S as Sidekiq participant F as Filesystem Ru->>P: 아티팩트 업로드 P->>DB: `ci_job_artifacts` 삽입 P->>DB: `ci_job_artifact_states` 삽입 SC->>Rd: `Geo::VerificationCronWorker`를 Enqueue S->>Rd: `Geo::VerificationCronWorker`를 픽업 S->>DB: `ci_job_artifact_states` 쿼리 S->>Rd: `Geo::VerificationBatchWorker`를 Enqueue S->>Rd: `Geo::VerificationBatchWorker`를 픽업 S->>DB: `ci_job_artifact_states` 쿼리 S->>DB: `ci_job_artifact_states` 행 업데이트, "시작됨" S->>F: 파일 체크섬 S->>DB: `ci_job_artifact_states` 행 업데이트, "성공"
  • Runner가 아티팩트를 업로드합니다.
  • Puma는 ci_job_artifacts 행을 생성합니다.
  • Puma는 verification 상태를 저장하기 위해 ci_job_artifact_states 행을 생성합니다.
    • 해당 행은 “검증 대기 중”으로 표시됩니다.
  • Sidekiq-cron은 매 분마다 Geo::VerificationCronWorker 작업을 enqueues합니다.
  • Sidekiq은 Geo::VerificationCronWorker 작업을 픽업합니다.
    • Sidekiq은 “검증 대기 중” 또는 “검증 실패 및 재시도 준비”로 표시된 행의 수를 위해 ci_job_artifact_states를 쿼리합니다.
    • Sidekiq은 “최대 검증 동시성” 설정으로 제한된 하나 이상의 Geo::VerificationBatchWorker 작업을 enqueues합니다.
  • Sidekiq은 Geo::VerificationBatchWorker 작업을 픽업합니다.
    • Sidekiq은 “검증 대기 중”으로 표시된 행을 위해 ci_job_artifact_states를 쿼리합니다.
    • 이전 단계에서 10개 미만의 행이 생성된 경우, Sidekiq은 “검증 실패 및 재시도 준비”로 표시된 행을 위해 ci_job_artifact_states를 쿼리합니다.
    • 각 행에 대해
      • Sidekiq은 “검증 시작됨”으로 표시합니다.
      • Sidekiq은 파일의 SHA256 체크섬을 가져옵니다.
      • Sidekiq은 체크섬을 해당 행에 저장하고 “검증 성공”으로 표시합니다.
      • 이제 보조 Geo 사이트가 이 체크섬과 비교할 수 있습니다.

보조 사이트:

sequenceDiagram participant SC as Sidekiq-cron participant R as Redis participant S as Sidekiq participant TDB as PostgreSQL Tracking DB participant F as Filesystem participant DB as PostgreSQL SC->>R: `Geo::VerificationCronWorker`를 Enqueue S->>R: `Geo::VerificationCronWorker`를 픽업 S->>TDB: `job_artifact_registry`를 쿼리 S->>R: `Geo::VerificationBatchWorker`를 Enqueue S->>R: `Geo::VerificationBatchWorker`를 픽업 S->>TDB: `job_artifact_registry`를 쿼리 S->>TDB: `job_artifact_registry` 행 업데이트, "시작됨" S->>F: 파일 체크섬 S->>DB: `ci_job_artifact_states` 쿼리 S->>TDB: `job_artifact_registry` 행 업데이트, "성공"
  • 아티팩트가 성공적으로 동기화되면 “검증 대기 중” 상태가 됩니다.
  • Sidekiq-cron은 매 분마다 Geo::VerificationCronWorker 작업을 enqueues합니다.
  • Sidekiq은 Geo::VerificationCronWorker 작업을 픽업합니다.
    • Sidekiq은 “검증 대기 중” 또는 “검증 실패 및 재시도 준비”로 표시된 행의 수를 위해 PostgreSQL Geo Tracking Database에 있는 job_artifact_registry를 쿼리합니다.
    • Sidekiq은 “최대 검증 동시성” 설정으로 제한된 하나 이상의 Geo::VerificationBatchWorker 작업을 enqueues합니다.
  • Sidekiq은 Geo::VerificationBatchWorker 작업을 픽업합니다.
    • Sidekiq은 PostgreSQL Geo Tracking Database에 있는 “검증 대기 중”으로 표시된 행을 위해 job_artifact_registry를 쿼리합니다.
    • 이전 단계에서 10개 미만의 행이 생성된 경우, Sidekiq은 “검증 실패 및 재시도 준비”로 표시된 행을 위해 job_artifact_registry를 쿼리합니다.
    • 각 행에 대해
      • Sidekiq은 “검증 시작됨”으로 표시합니다.
      • Sidekiq은 파일의 SHA256 체크섬을 가져옵니다.
      • Sidekiq은 체크섬을 해당 행에 저장합니다.
      • Sidekiq은 PostgreSQL에 의해 복제된 ci_job_artifact_states 행의 체크섬과 비교합니다.
      • 체크섬이 일치하면, Sidekiq은 job_artifact_registry 행을 “성공적으로 검증됨”으로 표시합니다.

인증

파일 전송을 인증하려면 각 GeoNode 레코드에는 두 가지 필드가 있습니다.

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

보조 사이트는 JWT 요청을 통해 자체를 인증합니다. 보조 사이트가 파일을 다운로드하려는 경우 Authorization 헤더와 함께 HTTP 요청을 보냅니다. 

Authorization: GL-Geo <access_key>:<JWT 페이로드>

주 사이트는 access_key 필드를 사용하여 해당 보조 사이트를 찾고 JWT 페이로드를 해독하여 파일 요청을 식별하는 추가 정보를 포함합니다. 이는 보조 사이트가 올바른 데이터베이스 ID에 대한 올바른 파일을 다운로드하는 것을 보장합니다. 예를 들어 LFS 객체의 경우 요청에 파일의 SHA256 합을 포함해야 합니다. 예시 JWT 페이로드는 다음과 같습니다. 

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

요청된 파일이 요청된 SHA256 합과 일치하는 경우, Geo 주 사이트는 X-Sendfile 기능을 사용하여 데이터를 보내어 NGINX가 Rails 또는 Workhorse를 묶지 않고 파일 전송을 처리합니다.

note
JWT는 관련된 기계들 사이의 동기화된 시계가 필요하며, 그렇지 않으면 암호화 오류가 발생할 수 있습니다.

Geo 보조로 Git Push

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

보조 사이트로 직접적으로 전송된 Git push 요청은 주 사이트로 보내지고, pull 요청은 최대 효율성을 위해 계속해서 보조 사이트에 의해 처리됩니다.

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

  • HTTPS의 경우 사용자에게 주 사이트의 프로젝트를 가리키는 HTTP 302 Redirect가 제공됩니다. Git 클라이언트는 이 상태 코드를 이해하고 리디렉션을 처리합니다.
  • SSH의 경우 리디렉션을 수행할 등가 방법이 없기 때문에 요청을 프록시해야 합니다. 이것은 첫째로 요청을 HTTP 프로토콜로 변환한 후 주 사이트로 프록시합니다.

gitlab-shell 데몬은 /api/v4/allowed의 응답에 기반하여 프록시할 때 언제인지 알 수 있습니다. 특별한 HTTP 300 상태 코드가 반환되며 우리는 응답 본문에 명시된 “사용자 정의 동작”을 실행합니다. 이 응답에는 프록시된 push 작업을 주 사이트에서 수행하기 위한 추가 데이터가 포함됩니다.

추적 데이터베이스 사용

복제된 메인 데이터베이스와 Geo 보조 사이트에는 별도의 추적 데이터베이스가 있습니다.

추적 데이터베이스에는 보조 사이트의 상태가 포함되어 있습니다.

업그레이드의 일환으로 실행해야 하는 모든 데이터베이스 마이그레이션은 각 보조 사이트의 추적 데이터베이스에 적용되어야 합니다.

구성

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

데이터베이스에 대한 마이그레이션을 작성하려면 다음과 같이 실행하십시오. 

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

Gitlab::Database::Migration[1.0]을 사용하여 Geo는 계속해서 사용해야 하며, 현재는 Gitlab::Database::Migration[2.0]에서는 검증에서 제외됩니다. 이는 개발자가 마이그레이션 파일을 매뉴얼으로 [2.0]에서 [1.0]로 변경해야 하는데, 마이그레이션 기본 설정이 2.0인 것 때문입니다.

자세한 정보는 Geo 마이그레이션을 Migration[2.0]을 사용하도록 활성화 문제를 참조하십시오.

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

bundle exec rake db:migrate:geo

파인더

Geo는 추적 데이터베이스 및 주 데이터베이스에서 프로젝트/첨부 파일 등을 찾는 데 중점을 둔 파인더를 사용합니다.

Redis

보조 사이트의 Redis는 주 사이트와 마찬가지로 작동합니다. 캐싱, 세션 저장 및 기타 지속 데이터에 사용됩니다.

주 사이트와 보조 사이트 간에 Redis 데이터 복제는 사용되지 않으므로 세션 등은 사이트 간에 공유되지 않습니다.

오브젝트 리포지터리

GitLab은 기본적으로 디스크에 저장하던 데이터를 오브젝트 리포지터리에 저장할 수 있습니다. 예를 들어:

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

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

  • GitLab 관리형 오브젝트 리포지터리 복제 활성화.
  • 클라우드 제공 업체의 내장된 서비스를 사용하여 Geo 사이트 간에 오브젝트 리포지터리를 복제합니다.
  • 주 사이트와 동일한 오브젝트 리포지터리 엔드포인트에 보조 Geo 사이트를 구성합니다.

확인

확인 상태

다음 다이어그램은 확인 작업이 작동하는 방식을 설명합니다. 몇 가지 허용된 전이는 명확성을 위해 생략되었습니다.

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

리포지터리 확인

리포지터리는 체크섬을 사용하여 확인됩니다.

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

보조 사이트는 클론의 해시를 계산하기 위해 동일한 작업을 수행하고 그 해시를 주 사이트가 계산한 값과 비교합니다. 불일치가 있는 경우 Geo는 이것을 불일치로 표시하고 관리자는 Geo 관리 영역에서 이를 볼 수 있습니다.

Geo 프록시

Geo 보조는 웹 요청을 기본 사이트로 프록시할 수 있습니다. 자세한 내용은 Geo 프록시 (개발) 페이지를 참조하십시오.

Geo API

Geo는 여러 컴포넌트 간의 통신을 용이하게 하는 외부 API를 사용합니다.

용어집

주 사이트

주 사이트는 Geo 설정에서 읽기-쓰기 기능을 가진 단일 사이트입니다. 이것은 단일 진실의 원천이며, Geo 보조 사이트는 거기서 데이터를 복제합니다.

Geo 설정에서는 하나의 주 사이트만 가능합니다. 모든 보조 사이트가 해당 주 사이트에 연결합니다.

보조 사이트

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

스트리밍 복제

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

스트리밍 복제는 Write Ahead Log(WAL)에 의존합니다. 해당 로그는 복제본으로 복사되고 거기에서 다시 재생됩니다.

스트리밍 복제는 스키마도 복제하기 때문에 데이터베이스 마이그레이션이 보조 사이트에서 실행될 필요가 없습니다.

추적 데이터베이스

각 Geo secondary 사이트에있는 사이트 상태를 유지하는 데이터베이스입니다. 추적 데이터베이스 사용하기에서 자세히 알아보기.

Geo 이벤트 로그

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

  • 리포지터리 삭제 이벤트
  • 리포지터리 이름 바꾸기 이벤트
  • 리포지터리 변경 이벤트
  • 리포지터리 생성 이벤트
  • 해시 리포지터리 마이그레이션 이벤트
  • LFS 오브젝트 삭제 이벤트
  • 해시 리포지터리 첨부 파일 이벤트
  • 작업 아티팩트 삭제 이벤트
  • 업로드 삭제 이벤트

Geo 로그 커서 데몬을 참조하세요.

코드 기능

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 노드 화면에서 최소한 하나의 사이트를 정의했다면, 그리고 해당 기능이 포함 된 유효한 라이선스를 소유하고 있다면, Geo 기능이 활성화됐다고 간주합니다.

Gitlab::Geo.enabled? 및 Gitlab::Geo.license_allows? 메서드를 참조하세요.

읽기 전용

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

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

사이트가 secondary인 경우 일부 쓰기 작업이 허용되지 않는 경우, Gitlab::Database.read_only?나 Gitlab::Database.read_write? 가드를 추가하는 것을 고려해보세요. 데이터베이스 자체는 이미 복제 된 설정에서 읽기 전용이기 때문에 추가 조치를 취할 필요가 없습니다.

새로운 기능이 Geo를 지원하는지 확인

Geo는 본사 및 CI 데이터베이스의 PostgreSQL 복제에 의존하기 때문에, 새로운 테이블이나 필드를 추가하는 경우에는 이미 secondary Geo 사이트에서 작동해야 합니다.

그러나 본사 및 CI PostgreSQL 데이터베이스 외부에 저장된 새로운 유형의 데이터를 도입하는 경우, 이러한 데이터가 복제되고 Geo에서 확인되도록 해야 합니다. 이것은 고객이 재해 복구를 위해 보조 사이트를 신뢰할 수 있어야하기 때문입니다.

다음 절에서는 필요한 작업을 확인하고, 작업이 필요한 경우 진행 방법을 설명합니다. 질문 사항이 있으면 Geo 팀에 문의하십시오.

사용자의 특성과 비교하려면, 지원되는 Geo 데이터 유형을 참조하십시오. 이 문서는 Geo가 복제하고 확인하는 데이터 유형에 대한 상세하고 최신의 디렉터리을 가지고 있습니다.

Git 리포지터리

Git 리포지터리를 지원하는 기능을 추가하는 경우, Geo 지원을 추가해야 합니다. Geo self-service framework의 리포지터리 복제 전략을 참조하세요.

Geo 새로운 blob 유형 복제에 관한 이슈를 만들고 가이드라인을 따르세요.

Blob

CarrierWave::Uploader::Base의 하위 클래스를 추가하는 경우, Geo가 blob이라고 하는 것을 추가하는 것입니다. AttachmentUploader를 구체적으로 하위 클래스화하는 경우, 데이터는 이미 uploads 테이블을 사용하여 Upload 모델과 함께 blob을 추적합니다. 이러한 이유로 해당 데이터는 이미 Geo 지원을 받고 있으므로 더 이상의 작업이 필요하지 않습니다.

만일 여러 백만 개의 행을 예상하기 때문에 새로운 테이블에 blobs를 추적하는 경우, Geo 지원을 추가해야 합니다. Geo self-service framework의 blob 복제 전략을 참조하세요.

Geo는 Spec를 사용하여 새로운 blob을 감지합니다. 이 Spec는 Uploader가 해당 Replicator가 없을 경우 실패합니다.

Geo에서 새로운 Git 리포지터리 유형 복제에 관한 이슈를 만들고 가이드라인을 따르세요.

여러 유형의 데이터를 가진 기능

새로운 복잡한 기능이 여러 유형의 데이터를 지원한다면, 예를 들어 Git 리포지터리와 blob이 있다면, 각 유형의 데이터를 개별적으로 고려할 수 있습니다.

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

  • LFS 오브젝트는 이미 Geo에서 지원되었으므로 Geo에 특정 작업이 필요하지 않았습니다.
  • 썸네일 구현은 이미 Upload 모델을 재사용했으므로 Geo에 특정 작업이 필요하지 않았습니다.
  • 디자인 Git 리포지터리는 기본적으로 Geo에서 지원되지 않았기 때문에 작업이 필요했습니다.

다른 예로, 의존성 프록시는 DependencyProxy::Blob과 DependencyProxy::Manifest 두 가지 종류의 blob을 사용합니다. 이 두 유형에 대해 Geo self-service framework의 blob 복제 전략를 사용할 수 있습니다.

기타 유형의 데이터

새로운 기능이 Git 리포지터리, blob 또는 그 두 가지의 조합이 아닌 새로운 데이터 유형을 도입하는 경우, Geo 팀에 연락하여 이를 처리하는 방법에 대해 논의해야 합니다.

예를 들어, 컨테이너 레지스트리 데이터는 위의 범주에 쉽게 들어 맞지 않습니다. 이 데이터는 데이터를 소유하는 레지스트리 서비스에 의해 지원되며, GitLab은 레지스트리 서비스의 API와 상호 작용합니다. 그래서 컨테이너 레지스트리의 Geo 지원에는 일회성 접근 방법이 필요합니다. 그럼에도 불구하고, Geo self-service framework의 많은 접착 코드를 재사용할 수 있습니다.

Self-service framework

귀하가 작업 중인 리소스에 쉬운 Geo 복제를 추가하려면 self-service framework를 확인하십시오.

개발자 Geo 워크플로우

GET:Geo 파이프라인

성공적으로 e2e:package-and-test-ee 파이프라인을 트리거한 후에 GET:Geo라는 작업을 수동으로 트리거할 수 있습니다.

  1. GitLab 프로젝트에서 Merge Request의 파이프라인 탭을 선택합니다.
  2. 최신 파이프라인에서 Stage: qa 단계를 선택하여 관련 작업을 확장하고 나열합니다.
  3. Merge Request에 해당하는 Omnibus GitLab Mirror 파이프라인을 확인하려면 trigger-omnibus를 선택합니다.
  4. GET:Geo 작업은 trigger-qa 단계 아래에서 찾을 수 있으며 트리거할 수 있습니다.

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

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

새 기능을 추가할 때는 동작을 확인하는 새로운 테스트를 추가하는 것을 고려하세요. 단계는 QA 문서를 참조하세요.

아키텍처

이 파이프라인은 여러 다른 프로젝트의 상호 작용을 포함합니다:

  • GitLab - 이 프로젝트의 Merge Request에서 e2e:package-and-test-ee 작업이 시작됩니다.
  • omnibus-gitlab - 트리거된 Merge Request 파이프라인에서 변경 사항을 포함하는 관련 아티팩트를 빌드합니다.
  • 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