Geo 자체 서비스 프레임워크

참고: 이 문서는 프레임워크를 구현하고 반복하는 과정에서 계속해서 변경될 수 있습니다. 진행 상황은 epic에서 따를 수 있습니다. 새로운 데이터 유형을 복제해야 하는 경우 Geo 팀에 연락하여 옵션을 논의하십시오. Slack의 #g_geo 채널에서 연락하거나 이슈나 병합 요청에서 @geo-team을 언급할 수 있습니다.

Geo는 Geo 사이트 전반에 걸쳐 데이터 유형을 쉽게 복제할 수 있도록 하는 API를 제공합니다. 이 API는 Ruby 도메인별 언어(DSL)로 제공되며, 데이터 유형을 생성한 엔지니어가 최소한의 노력으로 데이터를 복제할 수 있도록 목표로 합니다.

Geo는 완료 기준에 대한 요구 사항입니다

Geo는 재해 복구를 위한 GitLab 솔루션입니다. 견고한 재해 복구 솔루션은 모든 GitLab 데이터를 성공적으로 복원하여 재해 발생 시 최소한의 데이터 손실로 모든 GitLab 서비스를 복원해야 합니다.

이러한 이유로, Geo 복제 및 GitLab 생성 데이터에 대한 확인 지원은 완료 기준의 일부입니다. 새로운 기능이 Geo 지원으로 제공되고 고객이 데이터 손실에 노출되지 않도록 보장합니다.

자체 서비스 프레임워크(SSF)를 사용하여 Geo를 지원하는 것은 간단하며, 이 페이지에서 다양한 데이터 유형에 대한 자세한 내용이 개요로 제시되어 있습니다. 그러나 새로운 GitLab 기능에 Geo 지원을 추가해야 하는지 및 어떻게 추가해야 하는지 결정하는 데 도움이 되는 일반 가이드에 대해서는 여기서 시작할 수 있습니다.

명명법

API로 들어가기 전에, 개발자들은 특정 Geo 명명 규칙을 알아야 합니다:

  • 모델: 모델은 전체 레일 코드베이스에서 알려진 Active Model입니다. 일반적으로 데이터베이스 테이블에 바인딩됩니다. Geo 관점에서 모델은 하나 이상의 리소스를 가질 수 있습니다.

  • 리소스: 리소스는 모델에 속하는 데이터로서 GitLab 기능에서 생성됩니다. 기본적으로 리소스는 Geo에서 복제할 수 없습니다.

  • 데이터 유형: 데이터 유형은 리소스가 저장되는 방식입니다. 각 리소스는 Geo가 지원하는 데이터 유형 중 하나에 적합해야 합니다:
    • Git 저장소
    • Blob
    • 데이터베이스

    자세한 내용은 데이터 유형을 참조하세요.

  • Geo 복제 가능: 복제 가능은 Geo가 Geo 사이트 전반에 동기화하려는 리소스입니다. 복제 가능한 데이터 유형으로는 한정된 집합이 있습니다. 알려진 데이터 유형에 속하는 리소스를 복제하는 데 필요한 노력은 최소화됩니다.

  • Geo 복제자: Geo 복제자는 복제 가능한 리소스를 복제하는 방법을 알고 있는 객체입니다. 다음과 같은 책임을 가지고 있습니다:
    • 이벤트 발생(생산자)
    • 이벤트 소비(소비자)

    이것은 Geo 복제 가능한 데이터 유형에 바인딩됩니다. 모든 복제자는 이벤트를 처리(즉, 생성 및 소비)하는 데 사용할 수 있는 공통 인터페이스를 가집니다. 이것은 이벤트가 생성되는 기본 사이트와 이벤트가 소비되는 보조 사이트 간의 통신을 처리합니다. 자체 기능에 Geo를 통합하려는 엔지니어는 이것을 사용하여 이를 수행합니다.

  • Geo 도메인별 언어: 엔지니어가 쉽게 복제해야 하는 리소스를 지정할 수 있도록 하는 구문 설탕입니다.

Geo 도메인별 언어

복제자

가장 먼저, 복제자를 작성해야 합니다. 복제자는 ee/app/replicators/geo에 있습니다. 복제해야 하는 각 리소스에 대해 별도의 복제자를 지정해야 합니다. 여러 리소스가 동일한 모델에 바인딩되어 있더라도 따로 지정해야 합니다.

예를 들어, 다음과 같은 복제자는 패키지 파일을 복제합니다:

module Geo
   class PackageFileReplicator< Gitlab:replicator
     # 사용하는 전략 중 하나를 포함합니다
     include::Geo::BlobReplicatorStrategy

     # 사용된 전략에 필요한 CarrierWave 업로더를 지정합니다
     def carrierwave_uploader
       model_record.file
     end

     # 이 복제자가 속하는 모델을 지정합니다
     def self.model
       :PackagePackageFile
     end
   end
end

클래스 이름은 고유해야 합니다. 또한, 이는 레지스트리의 테이블 이름과 강하게 결합되어 있으므로, 이 예시의 경우 레지스트리 테이블은 package_file_registry입니다. Geo가 지원하는 다양한 데이터 유형에는 포함해야 하는 다른 전략이 있습니다. 필요에 맞는 전략을 선택하세요.

모델에 연결하기

이 복제기를 모델에 연결하려면 모델 코드에 다음을 추가해야 합니다:

class Packages::PackageFile < ApplicationRecord
  include ::Geo::ReplicableModel

  with_replicator Geo::PackageFileReplicator
end

API

이 작업이 완료되면 모델을 통해 복제기에 쉽게 접근할 수 있습니다:

package_file = Packages::PackageFile.find(4) # 예시로 임의의 ID를 사용합니다
replicator = package_file.replicator

또는 복제기에서 모델을 다시 가져올 수 있습니다:

replicator.model_record
=> <Packages::PackageFile id:4>

복제기는 예를 들어 ActiveRecord 후크에서 이벤트를 생성하는 데 사용할 수 있습니다:

  after_create_commit -> { replicator.publish_created_event }

라이브러리

이 모든 작업의 기밀은 ee/lib/gitlab/geo/에 있습니다.

기존 복제기 전략

새로운 종류의 복제기 전략을 작성하기 전에, 기존 전략 중 하나로 리소스를 처리할 수 있는 지 아래 내용을 확인하세요. 확신이 없는 경우 Geo 팀과 상의하세요.

Blob Replicator 전략

CarrierWave’s Uploader::Base를 사용하는 모델은 Geo::BlobReplicatorStrategy 모듈로 Geo에서 지원됩니다. 예를 들어, 파이프라인 아티팩트에 대한 Geo 복제가 어떻게 구현되었는지를 확인하세요.

각 파일은 자체 기본 ID와 모델을 가져야 합니다. Geo는 모든 파일을 일급 시민으로 다루는 것을 강력히 권장합니다. 경험상 이렇게 하면 복제 및 검증 상태를 크게 단순화할 수 있습니다.

새로운 블롭 유형 Model의 Geo 복제를 구현하려면, 제공된 이슈 템플릿을 사용하여 이슈를 등록하세요.

이슈를 오픈하지 않고 구현 단계를 보려면, 이슈 템플릿 파일을 확인하세요.

저장소 복제기 전략

디스크 상의 Git 저장소를 참조하는 모델은 Geo::RepositoryReplicatorStrategy 모듈로 Geo에서 지원됩니다. 예를 들어, 그룹 레벨 위키에 대한 Geo 복제가 어떻게 구현되었는지를 확인하세요. Git 저장소의 검증은 아직 Geo 셀프 서비스 프레임워크에 추가되지 않았으므로 이슈가 검증을 구현하는 것은 아님에 유의하세요. 검증을 구현하는 예는 스니펫 저장소 검증 추가의 MR에서 확인할 수 있습니다.

각 Git 저장소는 자체 기본 ID와 모델을 가져야 합니다.

새로운 Git 저장소 유형 Model의 Geo 복제를 구현하려면, 제공된 이슈 템플릿을 사용하여 이슈를 등록하세요.

이슈를 오픈하지 않고 구현 단계를 보려면, 이슈 템플릿 파일을 확인하세요.