업로드 가이드: 새 업로드 추가하기

GitLab에서 새 업로드 기능을 추가할 때 사용하는 CarrierWave Uploader 설계, Direct Upload 구현, 업로드 처리 방식에 대해 설명합니다.

권장 사항 # Uploader를 생성할 때는 AttachmentUploader 의 서브클래스 로 만드세요. 이 문서의 테이블 에 Uploader를 추가하세요. 새 오브젝트 스토리지 버킷 을 추가하지 마세요. Direct Upload 를 구현하세요. 업로드를 처리해야 한다면 처리 위치 를 결정하세요. 배경 정보 # CarrierWave Uploaders CarrierWave에 대한 GitLab 수정 사항 파일을 어디에 저장해야 하나요? # CarrierWave Uploader는 파일이 저장되는 위치를 결정합니다. 새 Uploader 클래스를 생성할 때 새 기능의 파일을 어디에 저장할지 결정하게 됩니다. 우선, 새 Uploader 클래스가 필요한지 스스로 물어보세요. 서로 다른 마운트 포인트나 서로 다른 모델에 동일한 Uploader 클래스를 사용하는 것은 괜찮습니다. 자체 Uploader 클래스가 필요하거나 원한다면 AttachmentUploader 의 서브클래스 로 만들어야 합니다. 그러면 해당 클래스에서 저장 위치와 디렉터리 체계를 상속받게 됩니다. 디렉터리 체계는 다음과 같습니다: File.join(model.class.underscore, mounted_as.to_s, model.id.to_s) GitLab 코드베이스를 살펴보면 자체 저장 위치를 가진 Uploader가 꽤 많이 있습니다. 오브젝트 스토리지의 경우, Uploader마다 별도의 버킷을 가지고 있습니다. 현재 GitLab은 다음과 같은 이유로 새 버킷 추가를 권장하지 않습니다 : 새 버킷을 사용하면 GDK , Omnibus GitLab , CNG 에서 다운스트림 변경이 필요하기 때문에 개발 시간이 늘어납니다. 새 버킷을 사용하면 GitLab.com 인프라 변경이 필요하므로 새 기능 출시가 느려집니다. 새 버킷을 사용하면 GitLab Self-Managed에서 새 기능 채택이 느려집니다: 로컬 GitLab 관리자가 새 버킷을 구성하기 전까지는 사용자들이 새 기능을 사용할 수 없습니다. 기존 버킷을 사용하면 이러한 추가 작업과 마찰을 모두 피할 수 있습니다. AttachmentUploader 가 사용하는 Gitlab.config.uploads 저장 위치는 이미 구성되어 있음이 보장됩니다. Direct Upload 지원 구현 # 아래에서는 Direct Upload 지원을 구현하는 방법을 설명합니다. Direct Upload를 사용하는 것이 항상 필요한 것은 아니지만, 일반적으로 좋은 아이디어입니다. 기능에서 처리하는 업로드가 빈번하지 않고 용량이 작지 않다면 Direct Upload를 구현하는 것이 좋습니다. 빈번하지 않고 용량이 작은 업로드를 사용하는 기능의 예로는 프로젝트 아바타가 있습니다: 아바타는 거의 변경되지 않으며 애플리케이션에서 엄격한 크기 제한을 적용합니다. 기능이 빈번하지 않고 용량도 작지 않은 업로드를 처리한다면, Direct Upload 지원을 구현하지 않으면 기술 부채를 안게 됩니다. 최소한 나중에 Direct Upload 지원을 추가할 수 있도록 해야