저장소 저장소

Tier: Free, Premium, Ultimate Offering: Self-managed

GitLab은 저장소를 저장소 저장소에 저장합니다. 저장소 저장소는 다음 중 하나입니다:

  • Gitaly 노드를 가리키는 gitaly_address로 구성된 물리적 저장소입니다.
  • Gitaly 클러스터에 저장된 저장소의 가상 저장소입니다.
caution
저장소 저장소는 저장소가 저장된 디렉터리를 직접 가리키는 path로 구성될 수 있습니다. 저장소를 포함하는 디렉터리에 GitLab이 직접 접근하는 것은 더 이상 권장되지 않습니다. GitLab이 물리적 또는 가상 저장소를 통해 저장소에 접근하도록 구성해야 합니다.

자세한 정보는 다음을 참조하세요:

해시된 저장소

  • 저장소 경로가 프로젝트 경로를 기반으로 생성되었던 이전 저장소 지원은 GitLab 14.0에서 완전히 삭제되었습니다.
  • 저장소 이름 필드는 이름이 변경됨 Gitaly 저장소 이름 에서 상대 경로 필드는 이름이 변경됨 Gitaly 상대 경로 에서 GitLab 16.3에서 변경되었습니다.

해시된 저장소는 프로젝트 ID의 해시에 기반하여 디스크에 프로젝트를 저장합니다. 이로 인해 폴더 구조가 불변이 되며, URL에서 디스크 구조로 상태를 동기화할 필요가 없습니다. 즉, 그룹, 사용자 또는 프로젝트의 이름을 바꾸는 것은:

  • 데이터베이스 트랜잭션 비용만 발생합니다.
  • 즉시 효과를 발생합니다.

해시는 또한 디스크에서 저장소가 더 고르게 분포되도록 도와줍니다. 최상위 디렉터리는 최상위 네임스페이스의 총 수보다 적은 폴더를 포함합니다.

해시 형식은 SHA256(project.id)로 계산된 SHA256의 16진수 표현을 기반으로 합니다. 최상위 폴더는 처음 두 문자를 사용하고, 그 뒤에 다음 두 문자를 포함한 다른 폴더가 이어집니다. 이들은 기존 레거시 저장소 프로젝트와 공존할 수 있도록 특별한 @hashed 폴더에 저장됩니다. 예를 들면:

# 프로젝트의 저장소:
"@hashed/#{hash[0..1]}/#{hash[2..3]}/#{hash}.git"

# 위키의 저장소:
"@hashed/#{hash[0..1]}/#{hash[2..3]}/#{hash}.wiki.git"

해시된 저장소 경로 변환

Git 저장소의 문제를 해결하거나 후크를 추가하는 등의 작업을 하려면 사람에게 읽기 쉬운 프로젝트 이름과 해시된 저장소 경로 간의 변환이 필요합니다. 다음을 변환할 수 있습니다:

프로젝트 이름에서 해시된 경로로

관리자는 다음 방법으로 프로젝트의 해시된 경로를 이름이나 ID를 통해 찾아볼 수 있습니다:

관리자 영역에서 프로젝트의 해시 경로를 찾으려면:

  1. 왼쪽 사이드바에서 하단에 있는 관리자를 선택합니다.
  2. 개요 > 프로젝트를 선택하고 프로젝트를 선택합니다.

  3. 상대 경로 필드를 확인합니다. 값은 다음과 유사합니다:

    "@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9.git"

Rails 콘솔을 사용하여 프로젝트의 해시 경로를 찾으려면:

  1. Rails 콘솔을 시작합니다.

  2. 다음 예제와 유사한 명령을 실행합니다 (프로젝트의 ID 또는 이름 중 하나를 사용):

    Project.find(16).disk_path
Project.find_by_full_path('group/project').disk_path

해시된 경로에서 프로젝트 이름 찾기

관리자는 다음을 사용하여 해시된 상대 경로에서 프로젝트의 이름을 조회할 수 있습니다:

  • Rails 콘솔.
  • *.git 디렉터리의 config 파일.

Rails 콘솔을 사용하여 프로젝트의 이름을 조회하려면:

  1. Rails 콘솔 시작하기를 시작합니다.

  2. 다음 예와 유사한 명령을 실행합니다:

    ProjectRepository.find_by(disk_path: '@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9').project

해당 명령의 인용된 문자열은 GitLab 서버에서 찾을 수 있는 디렉터리 트리입니다. 예를 들어, 기본 Linux 패키지 설치에서는 /var/opt/gitlab/git-data/repositories/@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9.git로, 디렉터리 이름의 끝에 있는 .git가 제거됩니다.

출력에는 프로젝트 ID와 프로젝트 이름이 포함됩니다. 예를 들어:

=> #<Project id:16 it/supportteam/ticketsystem>

*.git 디렉터리의 config 파일을 사용하여 프로젝트 이름을 조회하려면:

  1. *.git 디렉터리를 찾습니다. 이 디렉터리는 /var/opt/gitlab/git-data/repositories/@hashed/에 위치하며, 해시의 처음 네 자리는 @hashed/ 아래의 첫 번째 두 디렉터리입니다. 예를 들어, 기본 Linux 패키지 설치에서는 해시 b17eb17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9의 *.git 디렉터리는 /var/opt/gitlab/git-data/repositories/@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9.git입니다.

  2. config 파일을 열고 [gitlab] 아래의 fullpath= 키를 찾습니다.

해시된 객체 풀

객체 풀은 공공 및 내부 프로젝트의 포크를 중복 제거하는 데 사용되는 저장소이며, 소스 프로젝트의 객체를 포함합니다. objects/info/alternates를 사용하여 소스 프로젝트와 포크가 공유 객체를 위해 객체 풀을 사용합니다. 자세한 내용은 GitLab에서 Git 객체 중복 제거가 작동하는 방법을 참고하세요.

객체 풀에서 소스 프로젝트의 하우스키핑이 실행될 때 객체가 소스 프로젝트에서 객체 풀로 이동됩니다. 객체 풀 저장소는 @hashed 대신 @pools라는 디렉터리에 일반 저장소와 유사하게 저장됩니다.

# 객체 풀 경로
"@pools/#{hash[0..1]}/#{hash[2..3]}/#{hash}.git"

경고:
객체 풀 저장소에 대해 git prune 또는 git gc를 실행하지 마십시오. 이는 객체 풀이 의존하는 일반 저장소에서 데이터 손실을 초래할 수 있습니다.

해시된 객체 풀 저장소 경로

Rails 콘솔을 사용하여 프로젝트의 객체 풀을 조회하려면:

  1. Rails 콘솔을 시작합니다.

  2. 다음 예와 유사한 명령어를 실행합니다:

    project_id = 1
pool_repository = Project.find(project_id).pool_repository
pool_repository = Project.find_by_full_path('group/project').pool_repository

# 풀 저장소에 대한 더 많은 세부정보 가져오기
pool_repository.source_project
pool_repository.member_projects
pool_repository.shard
pool_repository.disk_path

그룹 위키 저장소

@hashed 디렉터리에 저장되는 프로젝트 위키와 달리, 그룹 위키는 @groups라는 디렉터리에 저장됩니다.

프로젝트 위키와 마찬가지로 그룹 위키는 해시된 저장소 폴더 규칙을 따르지만 프로젝트 ID 대신 그룹 ID의 해시를 사용합니다.

예를 들어:

# 그룹 위키 경로
"@groups/#{hash[0..1]}/#{hash[2..3]}/#{hash}.wiki.git"

Gitaly 클러스터 저장소

Gitaly 클러스터를 사용하는 경우, Praefect가 저장 위치를 관리합니다. Praefect가 저장소에 사용하는 내부 경로는 해시된 경로와 다릅니다. 자세한 내용은 Praefect가 생성한 복제 경로를 참조하세요.

객체 저장소 지원

이 표는 각 저장소 유형에 저장 가능한 객체를 보여줍니다:

저장할 수 있는 객체 해시된 저장소 S3 호환
저장소 예 -
첨부 파일 예 -
아바타 아니요 -
페이지 아니요 -
도커 레지스트리 아니요 -
CI/CD 작업 로그 아니요 -
CI/CD 아티팩트 아니요 예
CI/CD 캐시 아니요 예
LFS 객체 유사 예
저장소 풀 예 -

S3 호환 엔드포인트에 저장된 파일은 #{namespace}/#{project_name}로 접두사가 붙지 않는 한, 해시된 저장소의 동일한 장점을 가질 수 있습니다. 이는 CI/CD 캐시 및 LFS 객체에 해당합니다.

아바타

각 파일은 데이터베이스에 할당된 id와 일치하는 디렉터리에 저장됩니다. 사용자 아바타의 파일 이름은 항상 avatar.png입니다. 아바타가 교체될 때, Upload 모델이 삭제되고 다른 id로 새 모델이 생성됩니다.

CI/CD 아티팩트

CI/CD 아티팩트는 S3 호환입니다.

LFS 객체

LFS Objects in GitLab는 Git 구현을 따르며 두 개의 문자와 두 수준 폴더를 사용하여 유사한 저장 패턴을 구현합니다:

"shared/lfs-objects/#{oid[0..1]}/#{oid[2..3]}/#{oid[4..-1]}"

객체 oid: 8909029eb962194cfb326259411b22ae3f4a814b5be4f80651735aeef9f3229c를 기반으로 할 경우, 경로는 다음과 같습니다:

“shared/lfs-objects/89/09/029eb962194cfb326259411b22ae3f4a814b5be4f80651735aeef9f3229c”

LFS 객체는 또한 S3 호환입니다.

새로운 리포지토리를 저장할 위치 구성

여러 리포지토리 저장소를 구성한 후, 새로운 리포지토리가 저장될 위치를 선택할 수 있습니다:

  1. 왼쪽 사이드바에서 하단에 있는 관리자를 선택합니다.

  2. 설정 > 리포지토리를 선택합니다.

  3. 리포지토리 저장소를 확장합니다.

  4. 새 리포지토리를 위한 저장소 노드 필드에 값을 입력합니다.

  5. 변경 사항 저장을 선택합니다.

각 리포지토리 저장소 경로에는 0-100 범위의 가중치를 할당할 수 있습니다. 새로운 프로젝트가 생성될 때, 이 가중치는 리포지토리가 생성될 저장 위치를 결정하는 데 사용됩니다.

주어진 리포지토리 저장소 경로의 가중치가 다른 리포지토리 저장소 경로에 비해 높을수록, 더 자주 선택됩니다 ((storage weight) / (sum of all weights) * 100 = chance %).

기본적으로 리포지토리 가중치가 이전에 구성되지 않은 경우:

  • default는 가중치 100입니다.

  • 모든 다른 저장소는 가중치 0입니다.

참고:

모든 저장소 가중치가 0인 경우(예: default가 존재하지 않는 경우), GitLab은 구성이나 default의 존재 여부에 관계없이 default에 새로운 리포지토리를 생성하려고 시도합니다. 자세한 내용은 추적 문제를 참조하세요.

리포지토리 이동

리포지토리를 다른 리포지토리 저장소로 이동하려면(예: default에서 storage2로), Gitaly 클러스터로 마이그레이션하는 과정과 동일한 과정을 사용하세요.