오프라인 전송

소스 인스턴스와 대상 인스턴스가 직접 통신하지 않고 오브젝트 스토리지를 통해 그룹과 프로젝트를 내보내고 가져오는 오프라인 전송의 아키텍처, 모델, Sidekiq job 계층 구조, Fog 어댑터를 설명합니다.

Note 오프라인 전송은 아직 진행 중인 작업입니다. offline_transfer_exports , offline_transfer_imports , offline_transfer_ui 기능 플래그로 게이트되어 있으며, 모두 기본적으로 비활성화되어 있습니다. 오프라인 전송을 사용하면 소스 GitLab 인스턴스와 대상 GitLab 인스턴스가 서로 직접 통신하지 않고도 그룹 또는 프로젝트를 오브젝트 스토리지 버킷으로 내보낸 뒤 나중에 그 버킷에서 가져올 수 있습니다. 이는 두 인스턴스가 네트워크를 통해 서로 연결할 수 없거나, 내보내기와 가져오기가 서로 다른 시점에 이루어져야 할 때 유용합니다. 오프라인 전송은 직접 전송 아키텍처를 재사용합니다. 동일한 BulkImport , BulkImports::Entity , BulkImports::Tracker 레코드, 동일한 ETL(추출, 변환, 적재) 파이프라인 concern, 동일한 NDJSON(줄바꿈으로 구분된 JSON) 관계 형식을 사용합니다. 이 페이지는 오프라인 전송에만 고유한 부분만 설명합니다. 공유되는 개념(용어, 파이프라인 설계, NDJSON 파이프라인, 멱등성, 예외 처리)은 먼저 직접 전송 을 읽어 보세요. 이 개념들은 여기에서도 그대로 적용됩니다. 직접 전송과 다른 점 # 직접 전송에서는 대상 인스턴스가 마이그레이션 전체를 구동합니다. 대상 인스턴스가 소스 인스턴스의 API에 관계를 내보내 달라고 요청하고, 준비될 때까지 폴링한 다음, HTTP로 내려받습니다. 오프라인 전송에는 요청할 소스 인스턴스가 없습니다. 내보내기와 가져오기가 서로 다른 시점에, 서로 다른 네트워크에서 일어날 수 있고, 가져오기가 실행될 때 소스 인스턴스에 도달할 수 있다는 보장이 전혀 없기 때문입니다. 대신 내보내기와 가져오기는 각각 오브젝트 스토리지를 상대로 독립적으로 실행됩니다: 내보내기는 모든 관계 파일을 사용자가 구성한 버킷에 직접 기록한 다음, 모든 관계가 완료되면 metadata.json.gz 매니페스트를 기록합니다. 가져오기는 나중에 같은 버킷에서 그 매니페스트를 다시 읽어 어떤 엔티티가 내보내졌고 그것들이 오브젝트 키에 어떻게 매핑되는지 파악한 다음, 직접 전송이 사용하는 것과 동일한 파이프라인으로 가져옵니다. 호출할 소스 API가 없으므로, 오프라인 BulkImport ( bulk_import.offline_export? 가 true)에서는 직접 전송에만 해당하는 일부 단계가 건너뛰어집니다: BulkImports::ProcessService#import_entity 는 내보내기 시작을 요청할 소스 인스턴스가 없으므로 BulkImports::ExportRequestWorker 대신 BulkImports::EntityWorker 를 직접 큐에 넣습니다. 같은 이유로 ProcessService 는 소스 고스트 사용자 ID 캐싱을 건너뜁니다. BulkImports::Entity#pipelines 는 다른 스테이지 목록을 사용합니다. BulkImports::Groups::Stage 또는 BulkI