리포지터리 미러링

심층 탐구

2018년 12월, Tiago Botelho는 GitLab 풀 리포지터리 미러링 기능에 대해 도메인 전문 지식을 가진 사람들과 공유하기 위해 Deep Dive를 진행했습니다. (GitLab 팀 멤버 전용: https://gitlab.com/gitlab-org/create-stage/-/issues/1) 미래에 이 코드베이스에서 작업할 수 있는 누구라도를 대상으로 했습니다. YouTube에 있는 녹화본과 PDF 형식의 슬라이드을 찾을 수 있습니다. 그 이후에 특정한 상세 사항이 변경되었을 수 있지만, 여전히 좋은 소개 자료가 될 것입니다.

미러링 프로세스 설명

GitLab은 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)는 project_import_schedule 워커를 호출하여 스탬피드를 피하려고 시도합니다.
  5. 프로젝트 가져오기 일정 워커(project_import_schedule_worker.rb)는 프로젝트의 상태를 업데이트하고 가져오기 전환 프로세스를 관리하기 위해 Ruby state_machine을 시작합니다.
  6. 프로젝트 상태를 업데이트하는 동안, 이러한 호출은 repository_update_mirror 워커를 시작합니다.
  7. Sidekiq 백그라운드 미러 워커(repository_update_mirror_worker.rb)는 미러링 작업의 상태를 추적하고 좋은 오류 상태 정보를 제공합니다. 여기서 프로세스가 걸릴 수 있습니다. 왜냐하면 이 단계에서 Git 단계를 관리하기 때문입니다.
  8. 업데이트 미러 서비스(update_mirror_service.rb)는 Git 작업을 수행합니다.

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