리포지토리 미러링

심층 분석

2018년 12월, Tiago Botelho는 풀 미러링 기능에 대해 도메인 특화 지식을 가진 누구나 이후에 이 코드 영역에서 작업할 수 있는 사람들과 지식을 공유하기 위해 Deep Dive를 진행했습니다 (https://gitlab.com/gitlab-org/create-stage/-/issues/1). GitLab 팀 멤버만 참여할 수 있는 깊은 토론을 녹화한 것을 YouTube에서 볼 수 있으며, 슬라이드는 PDF에서 확인할 수 있습니다. 이 심층 분석에서 다룬 내용은 GitLab 11.6을 기준으로 정확했으며, 특정 세부 정보는 그 이후에 변경되었을 수 있지만 여전히 좋은 소개 자료로 활용될 것입니다.

미러링 프로세스 설명

GitLab 버전 14에서는 API 호출이 풀 미러링을 트리거할 때 다음 단계를 수행합니다. 예약된 미러 업데이트는 유사하지만 API 호출로 시작되지는 않습니다:

  1. 요청은 API 호출에서 시작되어 project_mirror.rb의 start_pull_mirroring_service를 트리거합니다.
  2. 이 단계에서는 풀 미러링 서비스 (start_pull_mirroring_service.rb)가 시작됩니다. 이는 프로젝트 상태를 업데이트하고 작업을 즉시 시작하도록 강제합니다.
  3. 프로젝트 가져오기 상태가 업데이트되어 project_import_state.rb의 update_all_mirrors_worker를 트리거합니다.
  4. 업데이트 모든 미러 워커 (update_all_mirrors_worker.rb)는 프로젝트 가져오기 일정 워커를 호출하여 동시성 문제를 피하려고 시도합니다.
  5. 프로젝트 가져오기 일정 워커 (project_import_schedule_worker.rb)는 프로젝트 상태를 업데이트하고 가져오기 전환 프로세스를 관리하기 위해 Ruby state_machine을 시작합니다.
  6. 프로젝트 상태를 업데이트하는 동안, project.rb의 호출은 repository_update_mirror 워커를 시작합니다.
  7. Sidekiq 백그라운드 미러 워커 (repository_update_mirror_worker.rb)는 미러링 작업의 상태를 추적하고 좋은 오류 상태 정보를 제공합니다. 이 단계에서 Git 단계를 관리하기 때문에 프로세스가 여기서 hang될 수 있습니다.
  8. 업데이트 미러 서비스 (update_mirror_service.rb)가 Git 작업을 수행합니다.

업데이트 미러 서비스 단계 이후 가져오기 및 미러 업데이트 프로세스가 완료됩니다. 그러나 포함된 변경 사항에 따라 더 많은 작업(커밋에 대한 파이프라인 등)이 트리거될 수 있습니다.