리포지터리 미러링

심층 연구

2018년 12월, Tiago Botelho는 GitLab Pull Repository Mirroring functionality에 대한 도메인 특화 지식을 가진 사람들과 공유하기 위해 Deep Dive를 주최했습니다. (GitLab 팀 멤버 전용: https://gitlab.com/gitlab-org/create-stage/-/issues/1) 이 내용은 YouTube 레코딩과 PDF 슬라이드에서 찾을 수 있습니다. 이 Deep Dive에서 다룬 내용은 GitLab 11.6 기준으로 정확했으며, 특정 세부 정보는 그 이후에 변경되었을 수 있지만 여전히 좋은 소개 자료로 사용될 것입니다.

미러링 프로세스 설명

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

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

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