• 복제 레이어
  • 복제 상태
  • Geo 로그 커서 데몬
  • 데이터베이스 복제
  • 저장소 복제
    • 프로젝트 레지스트리
    • 저장소 동기화 워커
  • 블랍 복제
    • 서비스 간 블랍 복제 성공적인 스텝 플로우
      • 새로운 작업 아티팩트 복제
      • 기존 작업 아티팩트의 백필링
      • 새로운 작업 아티팩트 검증
• 인증
  • 파일 전송
  • Git 전송
• Geo 보조에 Git Push
• 추적 데이터베이스 사용
  • 구성
• 검색기
• Redis
• 객체 저장
• 확인
  • 확인 상태
  • 저장소 확인
• Geo 프록시
• Geo API
• 용어집
  • 주 사이트
  • 보조 사이트
  • 스트리밍 복제
  • 추적 데이터베이스
• Geo 이벤트 로그
• 코드 기능
  • Gitlab::Geo 유틸리티
    • 현재 사이트
    • 주 사이트 또는 보조 사이트
    • Geo 데이터베이스 구성됨?
    • 읽기 전용
• 새로운 기능이 Geo를 지원하는지 확인하기
  • Git 저장소
  • 블롭
  • 여러 종류의 데이터를 갖는 기능
  • 다른 종류의 데이터
• 자체 서비스 프레임워크
• Geo 개발 워크플로우
  • GET:Geo 파이프라인
    • 아키텍쳐

Geo (개발)

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

복제 레이어

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

• 데이터베이스: 캐시와 작업을 제외한 모든 응용 프로그램을 포함합니다.
• Git 저장소: 프로젝트와 위키를 모두 포함합니다.
• 블랍: 이슈에 첨부된 이미지부터 CI의 로그 및 에셋까지 모두 포함합니다.

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

복제 상태

다음 다이어그램은 복제가 작동하는 방식을 보여줍니다. 가독성을 위해 특정 허용된 전이는 생략되었습니다.

Geo 로그 커서 데몬

Geo 로그 커서 데몬은 각 보조 사이트에서 실행되는 별도의 프로세스입니다. 이는 Geo 이벤트 로그를 모니터링하여 각 특정 이벤트 유형에 대한 백그라운드 작업을 생성합니다.

예를 들어, 저장소가 업데이트되면 Geo 주 사이트에서 관련 저장소 업데이트 이벤트를 가진 Geo 이벤트가 생성됩니다. 그럼 Geo 로그 커서 데몬은 해당 이벤트를 가져와 Geo::ProjectSyncWorker 작업을 예약하며 이 작업은 Geo::RepositorySyncService를 사용하여 저장소를 업데이트합니다.

Geo 로그 커서 데몬은 자동으로 고가용성 모드에서 작동할 수 있습니다. 이 데몬은 때때로 잠금을 획들하려고 시도하며 한 번 획들되면 활성 데몬처럼 작동합니다.

같은 사이트에서 추가로 실행되는 데몬은 대기 모드에 있어서 활성 데몬이 잠금을 풀면 작업을 계속할 수 있습니다.

우리는 TTL이 짧은 ExclusiveLease 잠금 유형을 사용하여 이 전역 잠금을 구현할 수 있습니다. 이로써 우리는 시간 제한이 있는 전역 잠금을 구현할 수 있게 됩니다.

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

데이터베이스 복제

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

저장소 복제

Geo는 저장소도 복제합니다. 각 보조 사이트는 추적 데이터베이스의 모든 저장소 상태를 추적합니다.

저장소가 복제되는 몇 가지 방법이 있습니다:

• 저장소 동기화 워커.
• Geo 로그 커서.

프로젝트 레지스트리

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

이는 저장소에 대해 다음과 같은 사항을 기록합니다:

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

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

저장소 동기화 워커

Geo::RepositorySyncWorker 클래스는 주기적으로 백그라운드에서 실행되며 업데이트가 필요한 Geo::ProjectRegistry 모델에서 프로젝트를 검색합니다. 이러한 프로젝트에는 다음이 포함될 수 있습니다:

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

보조 사이트에서 저장소를 가져올 때 RETRIES_BEFORE_REDOWNLOAD 회 수를 초과하면 복제에 실패했다고 판단하고, 이를 다시 다운로드라고 합니다. 이는 저장소의 @geo-temporary 디렉터리에 깨끗한 클론을 수행합니다. 성공적으로 수행되면 새로 복제된 저장소로 기존 저장소를 대체합니다.

블랍 복제

업로드, LFS 오브젝트 및 CI 작업 아티팩트와 같은 블랍은 자체 서비스 프레임워크를 사용하여 보조 사이트로 복제됩니다. 복제 상태를 추적하기 위해 각 모델에 해당하는 레지스트리 테이블이 있으며, 예를 들어 Upload의 경우 PostgreSQL Geo 추적 데이터베이스에 Geo::UploadRegistry가 있습니다.

서비스 간 블랍 복제 성공적인 스텝 플로우

작업 아티팩트는 블랍의 일부 사례로 사용하며 저 아래 다이어그램에서 보여줍니다.

새로운 작업 아티팩트 복제

주 사이트:

• Runner가 아티팩트를 업로드함
• Puma가 ci_job_artifacts 행을 삽입함
• Puma가 “ID 123인 Job Artifact가 업데이트됨”과 같은 데이터를 지닌 geo_events 행 삽입
• Puma가 geo_event_log 행을 삽입함 (일부 레거시 로직 위에 SSF를 구축했기 때문에)
• PostgreSQL 스트리밍 복제가 읽기 복제본에 행을 삽입함

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

• Geo 로그 커서 루프는 새 geo_event_log 행을 찾음
• Geo 로그 커서가 geo_events 행을 처리함
  • Geo 로그 커서가 geo_events 행 데이터를 통과시켜 Geo::EventWorker 작업을 인큐
• Sidekiq이 Geo::EventWorker 작업을 선택함
  • Sidekiq이 PostgreSQL Geo 추적 DB에 job_artifact_registry 행을 삽입함 (존재하지 않으므로) 및 “변환 시작”으로 표시함
  • Sidekiq이 주 Geo 사이트에서 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 작업을 큐에 넣습니다. 이 작업은 활발하게 실행 중이라면 최대 한 시간 동안 동기화 작업을 예약하도록 루프를 돕니다. 이 작업은 여러 병행 실행을 방지하기 위해 독점 임대를 사용합니다.
• Sidekiq은Geo::RegistrySyncWorker 작업을 처리
  • Sidekiq은 PostgreSQL Geo Tracking Database의 모든 registry 테이블에 대해 “시도하지 않은 동기화” 행을 조회합니다. 각 테이블에서 행을 번갈아가며 내부 큐에 추가합니다.
  • 이전 단계에서 1000개 미만의 행을 반환했다면, Sidekiq은 “실패한 동기화 및 다시 시도 준비” 행을 모두 조회하고 해당 행들을 내부 큐에 추가합니다.
  • 각 항목에 대해 Sidekiq은 “ID가 123인 Job Artifact가 업데이트됨”과 같은 인수로 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은 “검증 대기” 또는 “실패한 검증 및 다시 시도 준비”로 표시된 행 수를 조회합니다.
  • Sidekiq은 “최대 검증 동시성” 설정으로 제한된 하나 이상의Geo::VerificationBatchWorker 작업을 큐에 넣습니다.
• Sidekiq은 Geo::VerificationBatchWorker 작업을 처리
  • Sidekiq은 “검증 대기”로 표시된 행을 조회합니다.
  • 이전 단계에서 10개 미만의 행을 반환했다면, Sidekiq은 “실패한 검증 및 다시 시도 준비”로 표시된 행을 조회합니다.
  • 각 행에 대해
    • Sidekiq은 “검증 시작됨”으로 표시
    • Sidekiq은 파일의 SHA256 체크섬을 가져옴
    • Sidekiq은 해당 체크섬을 행에 저장하고 “검증 성공함”으로 표시
    • 이제 이와 같은 체크섬을 갖는 이차 Geo 사이트가 비교할 수 있음

이차 사이트:

• 아티팩트가 성공적으로 동기화되면 “검증 대기” 상태가 됨
• Sidekiq-cron은 매 분 Geo::VerificationCronWorker 작업을 큐에 넣음
• Sidekiq은Geo::VerificationCronWorker 작업을 처리
  • Sidekiq은 “검증 대기” 또는 “실패한 검증 및 다시 시도 준비”로 표시된 행 수를 조회합니다.
  • Sidekiq은 “최대 검증 동시성” 설정으로 제한된 하나 이상의Geo::VerificationBatchWorker 작업을 큐에 넣음
• Sidekiq은 Geo::VerificationBatchWorker 작업을 처리
  • Sidekiq은 “검증 대기”로 표시된 행을 조회함
  • 이전 단계에서 10개 미만의 행을 반환했다면, Sidekiq은 “실패한 검증 및 다시 시도 준비”로 표시된 행을 조회함
  • 각 행에 대해
    • Sidekiq은 “검증 시작됨”으로 표시
    • Sidekiq은 파일의 SHA256 체크섬을 가져옴
    • Sidekiq은 해당 체크섬을 행에 저장함
    • Sidekiq은 PostgreSQL에 의해 복제된ci_job_artifact_states 행의 체크섬과 체크함
    • 체크섬이 일치하면, Sidekiq은 job_artifact_registry 행을 “검증 성공함”으로 표시

인증

Git 및 파일 전송을 인증하려면 각 ‘GeoNode’ 레코드에 두 개의 필드가 있습니다.

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

보조 사이트는 JWT 요청을 통해 자체를 인증합니다.

보조 사이트는 Authorization 헤더로 HTTP 요청을 인가합니다:

Authorization: GL-Geo <access_key>:<JWT payload>

기본 사이트는 access_key 필드를 사용하여 해당 보조 사이트를 찾은 다음 JWT 페이로드를 해독합니다.

참고: JWT는 관련 기계 사이의 동기화된 시계를 필요로 하며, 그렇지 않을 경우 기본 사이트가 요청을 거부할 수 있습니다.

파일 전송

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

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

요청된 파일이 요청된 SHA256 합계와 일치하는 경우, Geo 기본 사이트는 X-Sendfile 기능을 통해 데이터를 보냅니다. 이를 통해 NGINX가 Rail 또는 Workhorse를 차단하지 않고 파일 전송을 처리할 수 있습니다.

Git 전송

보조 사이트가 기본 사이트에서 Git 저장소를 복제하거나 가져오려는 경우, JWT 페이로드에는 Git 저장소 요청을 식별하는 추가 정보가 포함됩니다. 이를 통해 보조 사이트가 올바른 데이터베이스 ID의 올바른 Git 저장소를 다운로드합니다. 예시 JWT 페이로드는 다음과 같습니다:

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

Geo 보조에 Git Push

Git Push Proxy는 gitlab-shell 구성 요소 내에 내장된 기능으로 존재합니다. 이는 보조 사이트에서만 활성화되며, 보조 사이트에서 복제한 저장소에 대해 동일한 URL로 push할 수 있게 합니다.

보조 사이트로 보내진 push 요청은 기본 사이트로 전송되지만 pull 요청은 최대 효율성을 위해 계속해서 보조 사이트에서 제공됩니다.

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

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

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 스키마가 지원될 때까지는 [2.0] 으로 유효성을 검사하지 않아야 합니다. 이에 따라 마이그레이션 파일을 수동으로 수정하여 기본적으로 [2.0]에서 [1.0]으로 변경해야 합니다.

더 많은 정보는 Enable Geo migrations to use Migration[2.0] issue를 확인하세요.

추적 데이터베이스의 마이그레이션은 다음을 실행하세요:

bundle exec rake db:migrate:geo

검색기

Geo는 검색기를 사용하며, 이는 추적 데이터베이스 및 주 데이터베이스에서 프로젝트/첨부 파일 등을 찾는 가장 중요한 기능을 담당하는 클래스입니다.

Redis

보조 사이트의 Redis는 기본 사이트와 동일하게 작동합니다. 이것은 캐싱, 세션 저장 및 기타 영구 데이터에 사용됩니다.

기본 및 보조 사이트 간의 Redis 데이터 복제는 사용되지 않으며, 세션 등이 사이트 간에 공유되지 않습니다.

객체 저장

GitLab은 일반적으로 디스크에 저장될 데이터를 객체 저장소에 사용할 수 있습니다. 예를 들어:

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

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

• GitLab 관리 객체 저장소 복제 활성화.
• 클라우드 제공업체의 내장된 서비스를 사용하여 객체 저장소를 Geo 사이트 간에 복제.
• 보조 Geo 사이트를 기본 사이트와 동일한 객체 저장소 엔드포인트에 액세스하도록 구성.

확인

확인 상태

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

저장소 확인

저장소는 체크섬으로 확인됩니다.

주 사이트는 저장소에 대한 체크섬을 계산합니다. 기본적으로 모든 Git 참조를 해시화하고 해당 해시를 데이터베이스의 project_repository_states 테이블에 저장합니다.

보조 사이트도 동일한 방식으로 클론의 해시를 계산하고, 이 해시를 주 사이트가 계산한 값과 비교합니다. 불일치가 있는 경우 Geo는 이를 불일치로 표시하고, 관리자는 이를 Geo 관리자 영역에서 볼 수 있습니다.

Geo 프록시

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

Geo API

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

용어집

주 사이트

주 사이트는 Geo 설정에서 읽기-쓰기 기능을 갖춘 단일 사이트입니다. 이는 진리의 단일 출처이며 Geo 보조 사이트는 여기에서 데이터를 복제합니다.

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

보조 사이트

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

스트리밍 복제

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

스트리밍 복제는 Write Ahead Logs(WAL)에 따라 작동합니다. 이러한 로그는 복제본으로 복사되어 거기에서 다시 실행됩니다.

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

추적 데이터베이스

각 Geo 보조 사이트의 데이터베이스는 해당 사이트에 대한 상태를 유지합니다. 추적 데이터베이스 사용하기에서 자세히 알아보세요.

Geo 이벤트 로그

Geo 주 사이트는 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? 클래스 메서드를 사용합니다.

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

Geo 데이터베이스 구성됨?

초기화 시간에 발생하는 일부 작업과 관련하여 추가적인 지엽성도 있습니다. 몇 군데에서는 보조 사이트에만 존재하는 추적 데이터베이스를 검사하려면 Gitlab::Geo.geo_database_configured? 메서드를 사용합니다. 이는 새로운 사이트를 부트스트래핑하는 동안 발생할 수 있는 경합 상태를 극복합니다.

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

읽기 전용

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

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

일부 쓰기 작업이 허용되지 않는 경우에는 Gitlab::Database.read_only? 또는 Gitlab::Database.read_write? 가드 대신에 사용하는 것을 고려하세요.

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

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

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

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

다음 하위 섹션에서는 필요한 작업이 있는지 여부를 확인하고, 그렇다면 어떻게 진행해야 하는지에 대해 설명합니다. 궁금한 사항이 있으면 Geo 팀에 문의하세요.

자체 기능과 비교하기 위해서 지원되는 Geo 데이터 유형을 참조하세요. Geo가 복제하고 확인하는 데이터 유형의 자세하고 최신 목록이 있습니다.

Git 저장소

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

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

블롭

CarrierWave::Uploader::Base의 서브클래스를 추가하는 경우 Geo가 블롭이라고 하는 것을 추가합니다. 특히 AttachmentUploader를 구체적으로 서브클래스화하는 경우 데이터는 추가 작업 없이 Geo 지원됩니다. 이는 AttachmentUploader가 uploads 테이블을 사용하여 Upload 모델의 블롭을 추적하고 Geo 지원이 이미 구현되어 있기 때문입니다.

당신의 블롭이 GitLab.com 규모에서 백만 개의 행을 예상하기 때문에 새 테이블에 추적될 경우, Geo 지원을 추가해야 합니다. Geo 자기 서비스 프레임워크의 블롭 복제 전략을 참조하세요.

Geo는 특정된 블롭을 감지합니다 할 때 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 자체 서비스 프레임워크의 많은 접착 코드를 재사용할 수 있습니다.

자체 서비스 프레임워크

귀하가 작업 중인 리소스에 대한 간편한 Geo 복제를 추가하고 싶다면 자체 서비스 프레임워크를 확인하세요.

Geo 개발 워크플로우

GET:Geo 파이프라인

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

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

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

인스턴스의 프로비저닝과 해제를 제어하는 파이프라인은 GitLab 환경 도구킷 설정의 일부로 포함됩니다.

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

아키텍쳐

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

• GitLab - 이 프로젝트의 병합 요청에서 e2e:test-on-omnibus-ee 작업이 시작됩니다.
• omnibus-gitlab - 트리거된 병합 요청 파이프라인에서 변경 사항이 포함된 관련 아티팩트를 빌드합니다.
• GET-Configs/Geo - 평가할 수 있는 짧은 기간 동안 활성화된 Geo 설치의 라이프사이클을 조정합니다.
• GET - Geo 설치를 생성하고 제거하는 데 필요한 로직이 포함되어 있습니다. GET-Configs/Geo에서 사용됩니다.
• gitlab-qa - GitLab 인스턴스에 대한 자동화된 테스트를 실행하는 도구입니다.