업로드 개발 가이드라인

GitLab에서 업로드를 처리하는 방식과 파일을 스토리지 대상으로 전송하는 주요 메커니즘에 대해 설명합니다.

업로드는 많은 GitLab 기능의 핵심 구성 요소입니다. GitLab이 업로드를 처리하는 방식을 이해하기 위해, 이 페이지에서는 파일을 스토리지 대상으로 전송하는 주요 메커니즘에 대한 개요를 제공합니다. GitLab 업로드는 기능별로 구성됩니다. 업로드와 관련된 모든 기능은 동일한 구성 옵션을 제공하지만, 각각 독립적으로 구성할 수 있습니다. 예를 들어, Git LFS 업로드는 CI/CD 빌드 아티팩트 업로드와 독립적으로 구성할 수 있지만, 두 기능 모두 동일한 설정 키 세트를 제공합니다. 이러한 설정은 업로드 처리 방식을 결정하며, 성능과 확장성에 큰 영향을 미칠 수 있습니다. 이 페이지는 파일 처리 방식을 결정하는 데 중요한 업로드 설정을 요약합니다. 이어지는 섹션에서는 각 메커니즘에 대해 더 자세히 설명합니다. 업로드 설정이 업로드 흐름을 결정하는 방식 # 개별 업로드 전략을 더 자세히 살펴보기 전에, 각 업로드 설정이 어떤 전략에 매핑되는지에 대한 상위 수준의 분류를 먼저 살펴보겠습니다. 업로드 설정 자체는 업로드 관리 에 문서화되어 있습니다. 여기서는 이러한 설정이 GitLab 업로드 로직의 내부를 어떻게 구동하는지에 초점을 맞춥니다. 최상위 수준에서, 업로드된 파일의 대상 은 두 가지로 구분됩니다: 로컬 스토리지 - 파일이 웹 서버 노드에 연결된 볼륨에 저장됩니다. 오브젝트 스토리지 - 파일이 원격 오브젝트 스토어 버킷에 저장됩니다. 이 표에서 x.y.z 는 gitlab.yml 을 통해 취하는 경로를 지정합니다: 설정 값 동작 .object_store.enabled false 파일이 .storage_path에 로컬로 저장됩니다 .object_store.enabled true 파일이 .object_store.remote_directory에 원격으로 저장됩니다 오브젝트 스토리지를 사용할 때, 관리자는 파일이 해당 버킷으로 이동되는 방법을 제어할 수 있습니다. 이 이동은 다음 방법 중 하나로 수행될 수 있습니다: Rails 컨트롤러 업로드 . 다이렉트 업로드 . 개별 Sidekiq 워커도 오브젝트 스토리지에 파일을 저장할 수 있지만, 이 내용은 여기서 다루지 않습니다. 마지막으로, Workhorse는 업로드 버퍼링 메커니즘을 사용하여 Rails 컨트롤러에서 느린 작업을 처리하지 않도록 대부분의 사용자 주도 업로드를 지원합니다. 이 메커니즘은 Workhorse 지원 업로드 에서 설명하며, 앞서 설명하는 내용과는 직교적으로 실행됩니다. 이제 각 케이스를 더 자세히 살펴보겠습니다. 로컬 스토리지 # 로컬 스토리지는 업로드가 취할 수 있는 가장 간단한 경로입니다. 이것이 GitLab 초기에 업로드를 처리하던 방식입니다. storage_path 에서 Rails 애플리케이션이 접근할 수 있는 스토리지 볼륨(디스크 또는 네트워크 연결 스토리지 등)이 있다고 가정합니다. 이 파일 경로는 Rails 루트 디렉터리에 대한 상대 경로이며, 다른 업로드 설정과 마찬가지로 기능별로 구성할 수 있습니다. 클라이언트가 파일 업로드를 전송하면, Workhors