• 복제 레이어
  • 복제 상태
  • Geo Log Cursor 데몬
  • 데이터베이스 복제
  • 리포지터리 복제
    • 프로젝트 레지스트리
    • 리포지터리 동기화 작업자
  • 블롭 복제
    • 서비스 간 블롭 복제 행복한 경로 워크플로우
      • 새로운 작업 아티팩트 복제
      • 기존 작업 아티팩트의 백필잉
      • 새로운 작업 아티팩트의 검증
• 인증
• Geo 보조로 Git 푸시
• 추적 데이터베이스 사용
  • 구성
• 검색기
• Redis
• 객체 리포지터리
• 확인
  • 확인 상태
  • 리포지터리 확인
• Geo 프록시
• Geo API
• 용어 해설
  • 기본 사이트
  • 복제 사이트
  • 스트리밍 복제
  • 추적 데이터베이스
• Geo 이벤트 로그
• 코드 기능
  • Gitlab::Geo 유틸리티
    • 현재 사이트
    • 기본 또는 복제 사이트
    • Geo 데이터베이스 구성 완료?
    • 활성화
    • 읽기 전용
• 새 기능에 Geo 지원 추가
  • Git 리포지터리
  • Blob
  • 둘 이상의 종류의 데이터가 있는 기능
  • 다른 종류의 데이터
• 통신 채널의 히스토리
  • 사용자 정의 코드 (GitLab 8.6 이전)
  • 시스템 후크 (GitLab 8.7 ~ 9.5)
  • Geo 로그 커서 (GitLab 10.0 이후)
• 자체 서비스 프레임워크
• Geo 개발 워크플로우
  • GET:Geo 파이프라인
    • 아키텍처

Geo (개발)

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

복제 레이어

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

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

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

복제 상태

다음 다이어그램은 복제 작업을 보여줍니다. 명시된 전이 중 일부는 명확성을 위해 생략되었습니다.

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 Log Cursor.

프로젝트 레지스트리

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

리포지터리에 대해 다음을 기록합니다.

• 마지막으로 동기화된 시간.
• 마지막으로 성공적으로 동기화된 시간.
• 다시 동기화해야 하는지 여부.
• 재시도해야 하는 시간.
• 재시도 횟수.
• 확인된 경우 (확인된 날짜).

또한 전용 열에 대한 프로젝트 위키도 이러한 속성을 저장합니다.

리포지터리 동기화 작업자

Geo::RepositorySyncWorker 클래스는 주기적으로 백그라운드에서 실행되며 리포지터리가 업데이트해야 하는 Geo::ProjectRegistry 모델을 검색합니다. 이러한 프로젝트는 다음 중 하나일 수 있습니다.

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

보조 RETRIES_BEFORE_REDOWNLOAD에서 리포지터리를 검색하지 못하는 경우, Geo는 이를 “재다운로드”합니다. 이 과정에서 리포지터리를 스토리지 루트의 @geo-temporary 디렉터리에 깨끗하게 복제합니다. 성공하면 새로 복제된 리포지터리로 원래 리포지터리를 교체합니다.

블롭 복제

업로드, LFS 오브젝트 및 CI 작업 아티팩트와 같은 블롭은 Self-Service Framework를 통해 보조 사이트로 복제됩니다. 동기화 상태를 추적하기 위해 각 모델에 해당하는 레지스트리 테이블이 있으며, 예를 들어 업로드는 PostgreSQL Geo 추적 데이터베이스 내에 Geo::UploadRegistry를 가지고 있습니다.

서비스 간 블롭 복제 행복한 경로 워크플로우

아래 다이어그램에서 작업 아티팩트가 예시로 사용되었습니다.

새로운 작업 아티팩트 복제

주 사이트:

• Runner가 아티팩트를 업로드합니다.
• Puma가 ci_job_artifacts 행을 삽입합니다.
• Puma가 “Job Artifact with ID 123 was updated”와 같은 데이터로 geo_events 행을 삽입합니다.
• Puma가 geo_event_log 행을 삽입하며, 여기서 일부 레거시 로직 위에 SSF를 구축했기 때문에 해당 행은 geo_events 행을 가리킵니다.
• PostgreSQL 스트리밍 복제가 읽기 전용 레플리카에 행을 삽입합니다.

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

• Geo Log Cursor 루프가 새 geo_event_log 행을 찾습니다.
• Geo Log Cursor가 geo_events 행을 처리합니다.
  • Geo Log Cursor가 geo_events 행 데이터를 거쳐 Geo::EventWorker 작업을 예약합니다.
• Sidekiq가 Geo::EventWorker 작업을 픽업합니다.
  • Sidekiq은 PostgreSQL Geo 추적 데이터베이스에 job_artifact_registry 행을 삽입합니다. 이 행이 존재하지 않기 때문에 “시작된 동기화”로 표시됩니다.
  • Sidekiq은 주 사이트의 내부 API 엔드포인트에서 GET 요청을 수행하고 파일을 다운로드합니다.
  • Sidekiq은 job_artifact_registry 행을 “동기화됨” 및 “검증 대기 중”으로 표시합니다.

기존 작업 아티팩트의 백필잉

• 시스템 관리자는 Geo 없는 기존 GitLab 사이트를 가지고 있습니다.
• 기존의 CI 작업 및 작업 아티팩트가 있습니다.
• 시스템 관리자는 새로운 GitLab 사이트를 설정하고 이를 보조 Geo 사이트로 구성합니다.

보조 사이트:

분당 두 개의 cron 작업이 매 분마다 실행됩니다: Geo::Secondary::RegistryConsistencyWorker 및 Geo::RegistrySyncWorker. 아래의 워크플로우는 이에 따라 둘로 분리됩니다.

• Sidekiq-cron은 매 분마다 Geo::Secondary::RegistryConsistencyWorker 작업을 인큐합니다. 이 작업은 활발히 작업(행 생성 및 삭제)을 수행하는 한 즉시 다시 자체를 인큐합니다. 이 작업은 동시에 여러 인스턴스가 동시에 실행되는 것을 방지하기 위해 배타적인 리스를 사용합니다.
• Sidekiq은 Geo::Secondary::RegistryConsistencyWorker 작업을 픽업합니다
  • Sidekiq은 최대 10000개의 행에 대해 ci_job_artifacts 테이블을 쿼리합니다
  • Sidekiq은 최대 10000개의 행에 대해 job_artifact_registry 테이블을 쿼리합니다
  • Sidekiq은 기존 작업 아티팩트에 해당하는 PostgreSQL Geo Tracking Database에 job_artifact_registry 행을 삽입합니다

• Sidekiq-cron은 매 분마다 Geo::RegistrySyncWorker 작업을 인큐합니다. 이 작업은 활발히 작업을 수행하는 한 최대 1시간 동안 동기화 작업을 예약합니다. 이 작업은 동시에 여러 인스턴스가 동시에 실행되는 것을 방지하기 위해 배타적인 리스를 사용합니다.
• Sidekiq은 Geo::RegistrySyncWorker 작업을 픽업합니다
  • Sidekiq은 PostgreSQL Geo Tracking Database의 모든 registry 테이블을 “시도하지 않은 동기화” 행에 대해 쿼리합니다. 각 테이블에서 행을 번갈아가며 메모리 내 큐에 추가합니다.
  • 이전 단계에서 1000개 미만의 행이 생성된 경우, Sidekiq은 “동기화 실패 및 재시도 준비” 행에 대해 모든 registry 테이블을 쿼리하고, 이를 메모리 내 큐에 추가합니다.
  • Sidekiq은 큐의 각 항목마다 “ID가 123인 작업 아티팩트가 업데이트되었습니다”와 같은 인자를 사용하여 Geo::EventWorker 작업을 인큐하고, 인큐된 Sidekiq 작업 ID를 추적합니다.
  • “최대 동시성 한도” 설정에 도달하면 Sidekiq은 더 이상 Geo::EventWorker 작업을 인큐하지 않습니다
  • 더 이상 수행할 작업이 없을 때까지 Sidekiq은 이러한 작업을 반복합니다
• Sidekiq은 Geo::EventWorker 작업을 픽업합니다
  • Sidekiq은 job_artifact_registry 행을 “동기화 시작됨”으로 표시합니다
  • Sidekiq은 주요 Geo 사이트의 API 엔드포인트에서 GET 요청을 수행하고 파일을 다운로드합니다
  • Sidekiq은 job_artifact_registry 행을 “동기화됨” 및 “검증 대기 중”으로 표시합니다

새로운 작업 아티팩트의 검증

주요 사이트:

• Runner가 아티팩트를 업로드합니다
• Puma는 ci_job_artifacts 행을 생성합니다
• Puma는 검증 상태를 저장하는 ci_job_artifact_states 행을 생성합니다.
  • 행은 “검증 대기 중”으로 표시됩니다
• Sidekiq-cron은 매 분마다 Geo::VerificationCronWorker 작업을 인큐합니다
• Sidekiq은 Geo::VerificationCronWorker 작업을 픽업합니다
  • Sidekiq은 “검증 대기 중”이거나 “검증 실패 및 재시도 준비”로 표시된 행의 수를 위해 ci_job_artifact_states를 쿼리합니다
  • “최대 검증 동시성” 설정에 따라 여러 개의 Geo::VerificationBatchWorker 작업을 인큐합니다
• Sidekiq은 Geo::VerificationBatchWorker 작업을 픽업합니다
  • Sidekiq은 ci_job_artifact_states에서 “검증 대기 중”으로 표시된 행을 쿼리합니다
  • 이전 단계에서 10개 미만의 행이 생성된 경우, Sidekiq은 “검증 실패 및 재시도 준비”로 표시된 행을 쿼리합니다
  • 각 행에 대해
    • Sidekiq은 “검증 시작됨”으로 표시합니다
    • Sidekiq은 파일의 SHA256 체크섬을 가져옵니다
    • Sidekiq은 체크섬을 해당 행에 저장하고 “성공한 검증”으로 표시합니다
    • 이제 보조 Geo 사이트가 이 체크섬과 대조할 수 있습니다

보조 사이트:

• 아티팩트가 성공적으로 동기화된 이후 “검증 대기 중”으로 전환됩니다
• Sidekiq-cron은 매 분마다 Geo::VerificationCronWorker 작업을 인큐합니다
• Sidekiq은 Geo::VerificationCronWorker 작업을 픽업합니다
  • “검증 대기 중”이거나 “검증 실패 및 재시도 준비”로 표시된 행의 수를 위해 PostgreSQL Geo Tracking Database의 job_artifact_registry를 쿼리합니다
  • “최대 검증 동시성” 설정에 따라 여러 개의 Geo::VerificationBatchWorker 작업을 인큐합니다
• Sidekiq은 Geo::VerificationBatchWorker 작업을 픽업합니다
  • PostgreSQL Geo Tracking Database의 job_artifact_registry에서 “검증 대기 중”으로 표시된 행을 쿼리합니다
  • 이전 단계에서 10개 미만의 행이 생성된 경우, Sidekiq은 “검증 실패 및 재시도 준비”로 표시된 행을 쿼리합니다
  • 각 행에 대해
    • 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 payload>

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

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

요청된 파일이 요청된 SHA256 합계와 일치하면, Geo 주 사이트는 X-Sendfile 기능을 통해 데이터를 전송하며, 이를 통해 NGINX가 파일 전송을 처리하고 Rails나 Workhorse를 사용하지 않도록 합니다.

Geo 보조로 Git 푸시

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

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

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

• HTTPS의 경우, 사용자에게 주 사이트의 프로젝트를 가리키는 HTTP 302 Redirect가 제공됩니다. Git 클라이언트는 해당 상태 코드를 이해하고 리디렉션을 처리합니다.
• SSH의 경우, 리디렉션을 수행하는 동등한 방법이 없기 때문에 요청을 프록시해야 합니다. 이는 먼저 요청을 HTTP 프로토콜로 변환한 다음 주 사이트로 프록시하는 gitlab-shell 내에서 수행됩니다.

gitlab-shell 데몬은 /api/v4/allowed에서의 응답을 기반으로 언제 프록시해야 하는지 알고 있습니다. 특별한 HTTP 300 상태 코드가 반환되며, 응답 본문에 지정된 “사용자 정의 작업”을 실행합니다. 응답에는 프록시된 push 작업이 주 사이트에서 수행되도록 하는 추가 데이터가 포함되어 있습니다.

추적 데이터베이스 사용

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

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

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

구성

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

데이터베이스에 대한 마이그레이션을 작성하려면 다음을 실행하세요.

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

Geo는 Gitlab::Database::Migration[1.0]을 계속 사용해야 하며, gitlab_geo 스키마가 지원될 때까지 Gitlab::Database::Migration[2.0]에서 검증을 제외시킬 수 있습니다. 마이그레이션 파일을 매뉴얼으로 수정하여 기본값이 2.0에서 1.0으로 변경되도록 개발자가 매뉴얼으로 변경해야 합니다.

더 많은 정보는 Geo 마이그레이션을 Migration[2.0]를 사용하도록 활성화 문제를 참조하세요.

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

bundle exec rake db:migrate:geo

검색기

Geo는 프로젝트/첨부 파일을 조회하는 무거운 작업을 담당하는 검색기를 사용합니다. 이를 위해서는 추적 데이터베이스와 주 데이터베이스에서 찾아야 합니다.

Redis

보조 사이트의 Redis는 주 사이트와 동일하게 작동합니다. 이를 통해 캐싱, 세션 저장 및 기타 지속적인 데이터 저장에 사용됩니다.

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

객체 리포지터리

GitLab은 선택적으로 객체 리포지터리를 사용하여 디스크에 저장할 데이터를 저장할 수 있습니다. 예를 들어:

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

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

• GitLab 관리형 객체 리포지터리 복제 활성화.
• 클라우드 제공 업체의 기본 서비스를 사용하여 객체 리포지터리를 Geo 사이트 간에 복제합니다.
• 주 사이트와 동일한 객체 리포지터리 엔드포인트에 보조 Geo 사이트가 액세스하도록 구성합니다.

확인

확인 상태

다음 다이어그램은 확인 작업이 어떻게 수행되는지를 설명합니다. 몇 가지 허용된 전환은 명확성을 위해 생략되었습니다.

리포지터리 확인

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

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

보조 사이트에서는 동일하게 자체 복제된 문자열의 해시를 계산하고 이를 주 사이트가 계산한 값과 비교합니다. 불일치가 있는 경우, Geo는 이를 불일치로 표시하고 이를 Geo 관리 영역에서 관리자가 확인할 수 있습니다.

Geo 프록시

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

Geo API

Geo는 다양한 컴포넌트 간의 통신을 용이하게 하기 위해 외부 API를 사용합니다.

용어 해설

기본 사이트

기본 사이트는 Geo 설정에서의 단일 사이트로 읽기-쓰기 기능을 갖습니다. 이것은 참 값의 단일 진실 공급원이며, Geo secondary 사이트는 여기에서 데이터를 복제합니다.

Geo 설정에서 기본 사이트는 하나만 존재할 수 있습니다. 모든 secondary 사이트는 해당 기본 사이트에 연결합니다.

복제 사이트

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

스트리밍 복제

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

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

스트리밍 복제는 스키마를 복제하므로 데이터베이스 이관 작업은 secondary 사이트에서 실행할 필요가 없습니다.

추적 데이터베이스

각 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 참조).

기본 또는 복제 사이트

현재 사이트가 기본 사이트 또는 secondary 사이트인지 여부를 확인하려면 .primary? 및 .secondary? 클래스 메서드를 사용합니다.

이러한 메서드 모두 사이트가 활성화되지 않은 경우에도 사이트 에서 false를 반환할 수 있습니다. 가능성을 참조하세요.

Geo 데이터베이스 구성 완료?

초기화 시간에 발생하는 작업을 다룰 때 추가 주의사항이 있습니다. 몇 군데에서 Gitlab::Geo.geo_database_configured? 메서드를 사용하여 추적 데이터베이스를 가지고 있는지 확인합니다. 이 데이터베이스는 secondary 사이트에만 존재합니다. 이는 새로운 사이트의 부트스트래핑 중에 발생할 수 있는 경합 조건을 극복합니다.

활성화

user가 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? 가드를 추가하는 것이 좋습니다. Gitlab::Geo.secondary? 대신 사용하세요.

데이터베이스 자체는 이미 복제 설정에서 읽기 전용일 것이므로 추가 조치를 취할 필요가 없습니다.

새 기능에 Geo 지원 추가

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

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

다음 하위 섹션에서는 필요한 작업을 결정하는 방법 및 필요한 경우 진행하는 방법에 대해 설명합니다. 궁금한 사항이 있으시면 Geo 팀에 문의하세요.

귀하의 기능과 비교하려면 지원되는 Geo 데이터 유형을 참조하세요. 이 문서에는 Geo가 복제하고 확인하는 데이터 유형의 자세하고 최신 디렉터리이 포함되어 있습니다.

Git 리포지터리

Git 리포지터리를 백업하는 기능을 추가한다면 해당 기능에 Geo 지원을 추가해야 합니다. Geo 자체 서비스 프레임워크의 리포지터리 복제기 전략을 참조하세요.

Geo 새 블로브 유형 복제 템플릿을 기반으로 이슈를 작성하고 지침을 따르세요.

Blob

CarrierWave::Uploader::Base의 서브클래스를 추가하는 경우, Geo에서는 blob이 추가됩니다. AttachmentUploader를 일반적으로 권장하는 대로 구체적으로 서브클래스를 추가하면 데이터는 추가 작업이 필요없이 Geo 지원을 받습니다. 기술적으로 AttachmentUploader는 uploads 테이블을 사용하여 Upload 모델의 blob을 추적하며 이미 해당 모델에 대한 Geo 지원이 구현되어 있기 때문입니다.

귀하의 blob이 GitLab.com 규모에서 수백만 개의 행을 예상하기 때문에 새 테이블에 blob이 추적된다면 Geo 지원을 추가해야 합니다. Geo 자체 서비스 프레임워크의 Blob 복제기 전략을 참조하세요.

Geo는 새로운 blob을 특정 사양과 함께 탐지합니다. 이 경우 Uploader에 해당하는 Replicator가 없을 때 실패합니다.

Geo 새로운 Git 리포지터리 유형 복제 템플릿을 기반으로 이슈를 작성하고 지침을 따르세요.

둘 이상의 종류의 데이터가 있는 기능

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

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

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

다른 예로, 의존성 프록시는 DependencyProxy::Blob와 DependencyProxy::Manifest라는 두 종류의 블롭을 사용합니다. 우리는 각 타입에 대해 Geo 자체 서비스 프레임워크의 블롭 복제 전략를 독립적으로 사용할 수 있습니다.

다른 종류의 데이터

새로운 기능이 Git 리포지터리, 블롭 또는 두 가지의 조합이 아닌 새로운 종류의 데이터를 도입하는 경우, Geo 팀에 연락하여 어떻게 처리할지 논의해야 합니다.

예를 들어, 컨테이너 레지스트리 데이터는 위의 범주로 쉽게 들어맞지 않습니다. 데이터를 소유하는 레지스트리 서비스로 백업되며, GitLab은 레지스트리 서비스의 API와 상호 작용합니다. 따라서 컨테이너 레지스트리의 Geo 지원에는 일회성 접근 방식이 필요합니다. 그러나 여전히 Geo 자체 서비스 프레임워크의 많은 부분의 코드를 재사용할 수 있습니다.

통신 채널의 히스토리

첫 번째 반복 이후에 통신 채널이 변경되었습니다. 여기에서는 과거의 결정과 새로운 구현으로 이동한 이유를 확인할 수 있습니다.

사용자 정의 코드 (GitLab 8.6 이전)

GitLab 8.6 이전 버전에서는 HTTP 요청을 통해 기본 사이트에서 보조 사이트로의 통지를 처리하기 위해 사용자 정의 코드가 사용되었습니다.

시스템 후크 (GitLab 8.7 ~ 9.5)

나중에, 사용자 정의 코드에서 이동하고 시스템 후크를 사용하기로 결정되었습니다. 많은 사람들이 사용하고 있어서 이 통신 레이어의 개선 사항을 많은 사람들이 누릴 수 있었습니다.

우리의 API 코드 (Grape)에는 특정 내부 엔드포인트가 있으며, 이 엔드포인트는 모든 시스템 후크로부터의 요청을 받습니다: /api/v4/geo/receive_events.

우리는 event_name 필드에 의해 각 이벤트를 전환하고 필터링합니다.

Geo 로그 커서 (GitLab 10.0 이후)

GitLab 10.0 이후에는 시스템 웹훅은 더 이상 사용되지 않고 대신 Geo 로그 커서가 사용됩니다. 로그 커서는 Geo::EventLog 행을 횡단하여 마지막으로 로그를 체크한 후에 변경 사항이 있는지 확인하고 리포지터리 업데이트, 삭제, 변경 및 이름 바꾸기를 처리합니다.

테이블은 복제된 데이터베이스 내에 있습니다. 이전 방법에 비해 이 방법에는 두 가지 장점이 있습니다:

• 복제는 동기화되며 이벤트의 순서를 보존합니다.
• 이벤트의 복제는 데이터베이스의 변경과 동시에 발생합니다.

자체 서비스 프레임워크

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

Geo 개발 워크플로우

GET:Geo 파이프라인

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

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

이 파이프라인은 GET을 사용하여 1k Geo 설치를 실행하고, 해당 인스턴스에서 gitlab-qa Geo 시나리오를 실행합니다. Geo 기능을 개발할 때는 트리거된 GET:Geo 파이프라인에서 qa-geo 작업이 통과되었는지 확인하는 것이 좋은 아이디어입니다.

인스턴스의 프로비저닝과 해제를 제어하는 파이프라인은 The 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 인스턴스에 대한 자동화된 테스트를 실행하는 도구입니다.