Geo Self-Service Framework
참고:
이 문서는 계속 구현 및 반복 작업을 진행함에 따라 변경될 수 있습니다.
epic에서 진행 상황을 확인하세요.
새로운 데이터 유형을 복제해야 하는 경우 Geo 팀에 문의하여 옵션을 논의하세요. Slack의 #g_geo
에서 연락하거나 이슈 또는 병합 요청에서 @geo-team
을 언급할 수 있습니다.
Geo는 Geo 사이트 간에 데이터 유형을 쉽게 복제할 수 있도록 API를 제공합니다. 이 API는 Ruby 도메인별 언어(DSL)로 제공되며, 데이터 유형을 생성한 엔지니어가 최소한의 노력으로 데이터를 복제할 수 있도록 목표로 합니다.
Geo는 Definition of Done에서 필수 요건입니다
Geo는 재해 복구를 위한 GitLab 솔루션입니다. 견고한 재해 복구 솔루션은 모든 GitLab 데이터가 재해 발생 시 최소한의 데이터 손실로 완전히 복구될 수 있도록 해야 합니다.
이러한 이유로, Geo가 생성한 데이터의 복제 및 검증 지원이 definition of done의 일부입니다. 이를 통해 새로운 기능이 Geo 지원과 함께 제공되며 고객들이 데이터 손실에 노출되지 않도록 합니다.
셀프 서비스 프레임워크 (SSF)를 사용하여 Geo 지원을 추가하는 것은 쉽습니다. 다양한 유형의 데이터에 대한 자세한 내용은 이 페이지에서 설명되어 있습니다. 그러나 새로운 GitLab 기능에 대한 Geo 지원을 추가해야 할지 및 어떻게 해야 할지 결정하는 데 도움이 되는 일반 가이드에 대해서는 여기에서 시작할 수 있습니다.
명명 규칙
API에 대해 자세히 살펴보기 전에, 개발자들은 일부 Geo 특정 명명 규칙을 알아야 합니다.
-
모델: 모델은 Active Model로, 전체 Rails 코드베이스에서 알려진 방식입니다. 일반적으로 데이터베이스 테이블에 연결됩니다. Geo 관점에서 모델은 하나 이상의 리소스를 가질 수 있습니다.
-
리소스: 리소스는 모델에 속하는 데이터로서 GitLab 기능에 의해 생성됩니다. 보통 저장 메커니즘을 사용하여 유지됩니다. 기본적으로 리소스는 Geo에서 복제할 수 없습니다.
-
데이터 유형:
데이터 유형은 리소스의 저장 방식입니다. 각 리소스는 Geo에서 지원하는 데이터 유형 중 하나에 적합해야 합니다.
- Git 저장소
- Blob
- 데이터베이스
자세한 내용은 데이터 유형을 참조하세요.
-
Geo 복제 가능: 복제 가능은 Geo가 Geo 사이트 간에 동기화하려는 리소스입니다. 지원되는 복제 가능 데이터 유형의 집합이 제한적으로 있습니다. 이미 알려진 데이터 유형에 속하는 리소스의 복제를 구현하는 데 필요한 노력이 최소화됩니다.
-
Geo 복제기:
Geo 복제기는 복제 가능을 복제하는 방법을 알고 있는 객체입니다. 다음을 담당합니다.
- 이벤트 발행(생산자)
- 이벤트 소비(소비자)
이것은 Geo 복제 가능 데이터 유형에 연결됩니다. 모든 복제기에는 이벤트를 처리(즉, 생성 및 소비)할 수 있는 공통 인터페이스가 있습니다. 이는 기능에 Geo를 통합하려는 엔지니어가 복제 기능을 구현하기 위해 복제기 API를 사용할 수 있게 합니다.
- Geo 도메인별 언어: 엔지니어가 복제해야 하는 리소스를 쉽게 지정할 수 있도록 하는 문법적 설탕입니다.
Geo 도메인별 언어
복제기
우선적으로, 복제기를 작성해야 합니다. 복제기는
ee/app/replicators/geo
에 있습니다. 복제해야 하는 각 리소스에는 별도의 복제기가 있어야 하며, 한 모델에 여러 리소스가 연결된 경우에도 마찬가지입니다.
예를 들어, 다음과 같은 복제기는 패키지 파일을 복제합니다:
module Geo
class PackageFileReplicator < Gitlab::Geo::Replicator
# 사용하는 리소스에 맞는 전략을 포함하기
include ::Geo::BlobReplicatorStrategy
# 사용된 전략에 필요한 CarrierWave 업로더 지정
def carrierwave_uploader
model_record.file
end
# 이 복제기가 속한 모델 지정
def self.model
::Packages::PackageFile
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의 Uploader::Base
를 사용하는 모델은 Geo::BlobReplicatorStrategy
모듈로 Geo에서 지원됩니다. 예를 들어, 파이프라인 아티팩트에 대한 Geo 복제가 어떻게 구현되었는지를 확인하세요.
각 파일은 고유한 기본 ID와 모델이 있어야 합니다. Geo에서 모든 단일 파일을 우선순위로 간주하는 것이 복제 및 검증 상태 추적을 크게 단순화하는 것으로 관찰되었습니다.
새로운 블롭 유형 모델의 Geo 복제를 구현하려면, 제공된 이슈 템플릿으로 이슈를 오픈하세요.
이슈를 오픈하지 않고 구현 단계를 보려면, 이슈 템플릿 파일을 확인하세요.
레포지토리 복제 전략
디스크에 있는 Git 레포지토리와 관련된 모델은 Geo::RepositoryReplicatorStrategy
모듈을 사용하여 Geo에서 지원됩니다. 예를 들어, 그룹 수준 위키의 Geo 복제가 어떻게 구현되었는지 확인해보세요. 이 문제는 아직 Geo Self-Service 프레임워크에 Git 레포지토리의 검증이 추가되기 전이기 때문에 검증이 구현되지 않았음을 유의하세요. 검증이 구현된 예는 스니펫 레포지토리 검증 추가의 병합 요청에서 찾을 수 있습니다.
각 Git 레포지토리는 자체 기본 ID 및 모델을 가져야합니다.
새로운 Git 레포지토리 유형 모델의 Geo 복제를 구현하려면, 제공된 이슈 템플릿으로 이슈를 열어주세요.
이슈를 열지 않고 구현 단계를 보려면, 이슈 템플릿 파일을 확인하세요.