저장소 저장소

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

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

  • gitaly_address로 구성된 물리적 저장소는 Gitaly 노드를 가리킵니다.
  • 가상 저장소는 Gitaly 클러스터에서 저장소를 저장합니다.

경고: 저장소 저장소는 저장소가 저장된 디렉토리를 직접 가리키는 path로 구성될 수 있습니다. GitLab이 저장소를 직접 액세스하는 것은 사용이 중단되었습니다. 저장소에 대한 액세스는 물리적 또는 가상 저장소를 통해 구성해야 합니다.

더 많은 정보:

해시된 저장소

  • GitLab 16.3에서 Gitaly 저장소 이름 필드가 이름이 저장소 이름으로, 상대 경로 필드가 이름이 상대 경로로 변경되었습니다.

해시된 저장소는 프로젝트를 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 저장소와 관련된 문제의 해결, 후크 추가, 그리고 기타 작업을 위해서는 사람이 읽을 수 있는 프로젝트 이름과 해시된 저장소 경로 간에 변환해야 합니다. 다음을 변환할 수 있습니다:

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

관리자는 다음을 사용하여 관리자 영역이나 Rails 콘솔을 통해 프로젝트의 해시된 경로를 조회할 수 있습니다:

관리자 영역에서 프로젝트의 해시된 경로를 조회하려면:

  1. 왼쪽 사이드바에서 아래쪽에 있는 Admin Area를 선택합니다.
  2. Overview > Projects를 선택하고 프로젝트를 선택합니다.
  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 디렉터리를 찾습니다. 이 디렉터리는 @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"

경고: @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}로 시작하지 않는 한 해시된 저장와 동일한 이점을 가질 수 있습니다.

아바타

각 파일은 데이터베이스에서 할당된 id와 일치하는 디렉터리에 저장됩니다. 사용자 아바타의 경우 파일 이름은 항상 avatar.png입니다. 아바타가 교체되면 Upload 모델이 파기되고 다른 id로 새 모델이 채용됩니다.

CI/CD 아티팩트

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

LFS 객체

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

다른 리포지토리 저장 경로와 비교하여 특정 리포지토리 저장 경로의 가중치가 높을수록(가중치의 합)에 따라 더 자주 선택됩니다 ((저장소 가중치) / (모든 가중치의 합) * 100 = 기회 % ).

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

  • default100의 가중치가 지정됩니다.
  • 다른 모든 저장소는 0의 가중치가 지정됩니다.

참고: 모든 저장소 가중치가 0인 경우(예: default가 존재하지 않을 때), GitLab은 default에서 새 리포지토리를 생성하려고 시도합니다. 해당 구성이나 default가 존재하지 않는 경우에도, 추적 이슈를 참조하세요.

저장소 이동

저장소를 다른 저장소 저장소(예: 기본에서 저장소2로)로 이동하려면 Gitaly 클러스터로 이주하는 것과 동일한 프로세스를 사용합니다.