내부 허용 API

GitLab 내부 API의 internal/allowed 엔드포인트가 Git 리포지터리 작업 권한 검증을 수행하는 방법과 관련 성능 이슈를 설명합니다.

internal/allowed 엔드포인트는 사용자가 Git 리포지터리에서 특정 작업을 수행할 권한이 있는지 평가합니다. 이 엔드포인트는 다음과 같은 여러 검사를 수행합니다: 브랜치 또는 태그 이름이 허용 가능한지 확인합니다. 사용자가 해당 작업을 수행할 권한이 있는지 여부를 확인합니다. 엔드포인트 정의 # 내부 API 엔드포인트는 lib/api/internal 아래에 정의되어 있으며, /allowed 경로는 lib/api/internal/base.rb 에 있습니다. 엔드포인트 사용 # internal/allowed 는 다음과 같은 경우에 호출됩니다: 리포지터리에 푸시하는 경우. 제안 적용 또는 GitLab IDE 사용과 같이 GitLab 사용자 인터페이스를 통해 리포지터리에서 작업을 수행하는 경우. Gitaly는 일반적으로 이 엔드포인트를 호출합니다. 이 엔드포인트는 API의 외부 사용자가 아닌 애플리케이션의 다른 부분에 의해 내부적으로만 호출됩니다. 푸시 검사 # internal/allowed 플로의 핵심 부분은 EE::Gitlab::Checks::PushRuleCheck 호출이며, 다음과 같은 검사를 수행할 수 있습니다: EE::Gitlab::Checks::PushRules::CommitCheck EE::Gitlab::Checks::PushRules::TagCheck EE::Gitlab::Checks::PushRules::BranchCheck 재귀 호출 # internal/allowed 에 의해 호출된 일부 Gitaly RPC는 다시 internal/allowed 로 콜백 호출을 합니다. 이러한 호출은 이제 원래 요청과 연관됩니다. Gitaly는 인가를 위해 Rails 애플리케이션에 의존하며, 자체적으로 권한 모델을 유지하지 않습니다. 이러한 호출은 초기 요청과 다르게 로그에 표시됩니다. {example} 이 엔드포인트는 재귀적으로 호출될 수 있기 때문에, 이 엔드포인트의 느린 성능은 기하급수적인 성능 영향을 초래할 수 있습니다. 이 문서는 실제로 성능 조사 에서 도출된 내용을 기반으로 합니다. 알려진 성능 문제 # Refs # Git 리포지터리의 refs 수는 해당 리포지터리에서 호출되는 git 명령의 성능에 상당한 영향을 미칩니다. Gitaly RPC도 마찬가지로 영향을 받습니다. 특정 git 명령은 모든 refs를 탐색하므로, 해당 명령의 속도에 현저한 영향을 줍니다. internal/allowed 엔드포인트에서 RPC 호출의 재귀적 특성으로 인해 ref 수가 성능에 기하급수적인 영향을 미칩니다. 환경 refs # 오래된 환경 refs 는 과도한 refs로 인해 성능 문제가 발생하는 일반적인 예입니다. 오래된 환경 refs는 자동으로 정리되지 않기 때문에 활성 리포지터리에서 수만 개에 이를 수 있습니다. 댕글링 refs # 댕글링 refs는 오브젝트 풀에서 오브젝트가 우발적으로 삭제되는 것을 방지하기 위해 생성됩니다. 이러한 refs는 많은 수가 존재할 수 있으며, 잠재적인 성능 영향이 있을 수 있습니다. 이 문제에 대한 기존