리포지터리 스토리지

Tier: Free, Premium, Ultimate Offering: Self-Managed형

GitLab은 리포지터리를 리포지터리에 저장합니다. 리포지터리 리포지터리는 다음 중 하나입니다:

caution
리포지터리 스토리지는 리포지터리가 저장된 디렉터리를 직접 가리키는 ‘path’로 구성할 수 있습니다. 리포지터리가 포함된 디렉터리에 GitLab이 직접 액세스하는 것은 더 이상 지원되지 않습니다. GitLab을 물리적이거나 가상 리포지터리를 통해 리포지터리에 액세스하도록 구성해야 합니다.

자세한 정보:

해시 리포지터리

  • Storage name 필드는 GitLab 16.3에서 Gitaly storage name으로부터 이름이 바뀌었으며, Relative path 필드는 GitLab 16.3에서 Gitaly relative path으로부터 이름이 바뀌었습니다.

해시 리포지터리는 프로젝트를 프로젝트 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 패키지 설치에서 이와 유사한 해시 b17eb17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9*.git 디렉터리는 /var/opt/gitlab/git-data/repositories/@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9.git입니다.

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

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

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

  1. *.git 디렉터리를 찾습니다. 이 디렉터리는 @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 객체 중복 사용 방식을 참조하십시오.

객체는 소스 프로젝트에서 housekeeping이 실행될 때 객체 풀로 이동됩니다. 객체 풀 리포지터리는 @hashed 대신 @pools 디렉터리에 저장됩니다.

# 객체 풀 경로
"@pools/#{hash[0..1]}/#{hash[2..3]}/#{hash}.git"
caution
@pools 디렉터리에 저장된 객체 풀 리포지터리에서 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 오브젝트

GitLab의 LFS 오브젝트는 Git 구현을 따라 2자와 2단계 폴더를 사용하여 유사한 저장 패턴을 구현합니다.

"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의 가중치가 할당될 수 있습니다. 새 프로젝트가 생성될 때, 이러한 가중치는 리포지터리가 생성되는 리포지터리 위치를 결정하는 데 사용됩니다.

다른 리포지터리 저장 경로에 비해 특정 리포지터리 저장 경로의 가중치가 높을수록 더 자주 선택됩니다((저장 가중치) / (모든 가중치의 합) * 100 = 확률 %).

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

  • 기본100의 가중치가 부여됩니다.
  • 다른 모든 리포지터리는 0의 가중치가 부여됩니다.
note
만약 모든 리포지터리의 가중치가 0이면(예: 기본이 존재하지 않는 경우), GitLab은 구성과 관계없이 새 리포지터리를 생성할 때 기본에 생성하려고 시도합니다. 자세한 정보는 추적 이슈를 참조하십시오.

리포지터리 이동

리포지터리를 다른 리포지터리 스토리지(예: 기본에서 리포지터리2로)로 이동하려면, Gitaly 클러스터로의 이전과 동일한 프로세스를 사용하십시오.