리포지터리 미러링

GitLab의 리포지터리 미러링 기능의 내부 동작 방식과 풀 미러링 프로세스의 단계별 흐름을 설명합니다.

Deep Dive # 2018년 12월, Tiago Botelho는 GitLab 팀원 전용 딥 다이브 세션(GitLab team members only: https://gitlab.com/gitlab-org/create-stage/-/issues/1 )을 진행하며 GitLab 풀 리포지터리 미러링 기능 에 대한 도메인 전문 지식을 향후 이 코드베이스에서 작업할 사람들과 공유했습니다. YouTube 녹화본 과 PDF 슬라이드 를 확인할 수 있습니다. 세부 사항은 그 이후 변경되었을 수 있지만, 여전히 좋은 입문 자료로 활용할 수 있습니다. 미러링 프로세스 설명 # GitLab은 API 호출 이 풀 미러를 트리거할 때 다음 단계를 수행합니다. 예약된 미러 업데이트도 유사하지만, API 호출로 시작하지 않습니다: 요청이 API 호출에서 시작되어 project_mirror.rb 의 start_pull_mirroring_service 를 트리거합니다. 풀 미러링 서비스( start_pull_mirroring_service.rb )가 시작됩니다. 이 서비스는 프로젝트 상태를 업데이트하고 job을 즉시 강제 시작합니다. 프로젝트 임포트 상태가 업데이트되고, project_import_state.rb 에서 update_all_mirrors_worker 를 트리거합니다. 전체 미러 업데이트 워커( update_all_mirrors_worker.rb )는 project_import_schedule 워커를 호출하여 스탬피드(stampede)를 방지하려 시도합니다. 프로젝트 임포트 스케줄 워커( project_import_schedule_worker.rb )는 프로젝트의 상태를 업데이트하고, Ruby state_machine 을 시작하여 임포트 전환 프로세스를 관리합니다. 프로젝트 상태를 업데이트하는 동안, project.rb 의 이 호출 이 repository_update_mirror 워커를 시작합니다. Sidekiq 백그라운드 미러 워커( repository_update_mirror_worker.rb )는 미러링 작업의 상태를 추적하고 오류 상태 정보를 제공합니다. 이 단계는 Git 단계를 관리하므로 프로세스가 여기서 중단될 수 있습니다. 미러 업데이트 서비스( update_mirror_service.rb )가 Git 작업을 수행합니다. 임포트 및 미러 업데이트 프로세스는 미러 업데이트 서비스 단계 이후 완료됩니다. 그러나 포함된 변경 사항에 따라 커밋에 대한 파이프라인 등 추가 작업이 트리거될 수 있습니다.