Gitaly 문제 해결

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

Gitaly 문제 해결 시 아래 정보를 참조하세요. Gitaly Cluster (Praefect)를 문제 해결하는 방법은 Gitaly Cluster 문제 해결을(를) 참조하세요.

다음 섹션에서는 Gitaly 오류에 대한 가능한 해결 방법을 제공합니다.

또한 Gitaly 타임아웃 설정 및 gitaly/current 파일의 구문 분석에 대한 권고 사항을 참조하세요.

단독 Gitaly 서버 사용 시 버전 확인

단독 Gitaly 서버를 사용할 때 GitLab의 버전과 호환되도록 동일한 버전인지 확인해야 합니다.

  1. 좌측 사이드바에서 맨 아래에서 Admin 선택.
  2. 개요 > Gitaly 서버 선택.
  3. 모든 Gitaly 서버가 최신 상태임을 확인합니다.

저장소 리소스 세부 정보 찾기

다음 명령을 Rails 콘솔에서 실행하여 Gitaly 저장소의 사용 가능한 공간 및 사용된 공간을 확인할 수 있습니다. 

Gitlab::GitalyClient::ServerService.new("default").storage_disk_statistics
# Gitaly Cluster의 경우
Gitlab::GitalyClient::ServerService.new("<저장소 이름>").disk_statistics

gitaly-debug 사용

gitaly-debug 명령은 Gitaly 및 Git 성능에 대한 “프로덕션 디버깅” 도구를 제공합니다. 프로덕션 엔지니어 및 지원 엔지니어가 Gitaly 성능 문제를 조사하는 데 도움이 되도록 의도되었습니다.

지원되는 하위 명령어 목록을 보려면 gitaly-debug 도움말 페이지를 보려면 다음을 실행하세요. 

gitaly-debug -h

문제 해결에 필요한 경우 gitaly git 사용

문제 해결이 필요한 경우 Gitaly와 동일한 Git 실행 환경을 사용하여 Git 명령을 실행하기 위해 gitaly git을 사용합니다. 버전 호환성을 보장하기 위해 gitaly git을 사용하는 것이 좋습니다.

gitaly git은 모든 인수를 기본 Git 호출로 전달하고 Git가 지원하는 모든 입력 형식을 지원합니다. gitaly git을 사용하려면 다음을 실행하세요. 

sudo -u git -- /opt/gitlab/embedded/bin/gitaly git <git-명령>

예를 들어 리눅스 패키지 인스턴스의 작업 디렉토리에서 Gitaly를 통해 git ls-tree를 실행하려면 다음을 실행하세요. 

sudo -u git -- /opt/gitlab/embedded/bin/gitaly git ls-tree --name-status HEAD

커밋, 푸시, 및 복제가 401을 반환하는 경우 

remote: GitLab: 401 Unauthorized

gitlab-secrets.json 파일을 GitLab 애플리케이션 노드에 동기화해야 합니다.

저장소 페이지에서 500 및 폴더 콘텐츠 가져오기 오류

폴더 콘텐츠 가져오기 및 경우에 따라 500 오류는 GitLab과 Gitaly 간의 연결 문제를 나타냅니다. 세부 사항은 클라이언트 측 gRPC 로그를 참조하세요.

클라이언트 측 gRPC 로그

Gitaly는 gRPC RPC 프레임워크를 사용합니다. Ruby gRPC 클라이언트에는 유용한 정보가 포함될 수 있는 자체 로그 파일이 있습니다. gRPC 클라이언트의 로그 수준은 GRPC_LOG_LEVEL 환경 변수로 제어할 수 있습니다. 기본 수준은 WARN입니다.

gRPC 추적을 실행하려면 다음을 실행하세요. 

sudo GRPC_TRACE=all GRPC_VERBOSITY=DEBUG gitlab-rake gitlab:gitaly:check

이 명령이 모든 주소에 연결하지 못했습니다 오류로 실패하는 경우 SSL 또는 TLS 문제를 확인하세요. 

/opt/gitlab/embedded/bin/openssl s_client -connect <gitaly-ipaddress>:<port> -verify_return_error

openssl이 성공하더라도 gitlab-rake gitlab:gitaly:check이 실패하는 경우, Gitaly에 대한 인증서 요구 사항을 확인하세요.

서버 측 gRPC 로그

Gitaly 자체에서 gRPC 추적도 GODEBUG=http2debug 환경 변수로 활성화할 수 있습니다. Linux 패키지 설치에서는 다음을 수행합니다.

  1. gitlab.rb 파일에 다음을 추가합니다. 

    gitaly['env'] = {
  "GODEBUG=http2debug" => "2"
}

  2. GitLab을 재구성합니다.

Git 프로세스와 RPC 관련성 확인

특정 Git 프로세스를 생성한 Gitaly RPC를 찾아야 하는 경우가 있습니다.

이를 위해 DEBUG 로깅을 사용하는 방법이 있지만, 미리 활성화해야 하며 생성된 로그는 매우 마구간성이 있습니다.

이 관련성을 쉽게 파악하는 가법은 해당 Git 프로세스의 환경(그 PID)을 검사하고 CORRELATION_ID 변수를 찾는 것입니다. 다음을 사용하세요. 

PID=<Git 프로세스 ID>
sudo cat /proc/$PID/environ | tr '\0' '\n' | grep ^CORRELATION_ID=

Gitaly 내부적으로 해당 git cat-file 프로세스에 대해 이 방법이 신뢰할 수 없습니다. 왜냐하면 Gitaly는 RPC 간에 내부적으로 해당 프로세스를 풀링하여 재사용하기 때문입니다.

저장소 변경이 401 Unauthorized 오류로 실패하는 경우

Gitaly를 별도의 서버에서 실행하고 다음 조건을 확인한 경우:

  • 사용자가 SSH 및 HTTPS 모두를 사용하여 저장소를 성공적으로 복제하고 검색할 수 있습니다.
  • 사용자가 저장소에 푸시할 수 없거나 웹 UI에서 변경을 시도할 때 401 Unauthorized 메시지를 받는 경우.

Gitaly 클라이언트가 올바른 시크릿 파일을 가지고 인증에 실패할 수 있습니다. 이를 확인하려면 다음을 확인하세요:

  • 이 Gitaly 서버의 어떤 사용자가 어떤 저장소로 git push를 수행하는 경우 401 Unauthorized 오류로 실패합니다. 

    remote: GitLab: 401 Unauthorized
To <REMOTE_URL>
! [remote rejected] branch-name -> branch-name (pre-receive hook declined)
error: failed to push some refs to '<REMOTE_URL>'
  • 사용자가 저장소의 파일을 추가하거나 수정하는 경우 GitLab UI에서 즉시 빨간색 401 Unauthorized 배너로 실패합니다.
  • README로 초기화된 새 프로젝트를 생성할 때 프로젝트는 성공적으로 생성되지만 README가 생성되지 않습니다.

  • Gitaly 클라이언트에서 로그를 추적하고 오류를 재현하는 경우 401 오류를 얻습니다. 

    # api_json.log
{
  "time": "2019-07-18T00:30:14.967Z",
  "severity": "INFO",
  "duration": 0.57,
  "db": 0,
  "view": 0.57,
  "status": 401,
  "method": "POST",
  "path": "\/api\/v4\/internal\/allowed",
  ...
}

이 문제를 해결하려면 Gitaly 서버의 gitlab-secrets.json 파일이 Gitaly 클라이언트와 일치하는지 확인하세요. 일치하지 않는 경우 Gitaly 서버의 시크릿 파일을 Gitaly 클라이언트와 일치하도록 업데이트하고, 재구성하세요.

gitlab-secrets.json 파일이 모든 Gitaly 서버 및 클라이언트에서 동일하다는 것을 확인했다면, 애플리케이션이 다른 파일에서이 시크릿을 가져오고 있을 수 있습니다. Gitaly 서버의 config.toml 파일은 사용중인 시크릿 파일을 나타냅니다. 해당 설정이 누락된 경우 GitLab은 /opt/gitlab/embedded/service/gitlab-rails/.gitlab_shell_secret 아래의 .gitlab_shell_secret를 사용합니다.

저장소 푸시가 401 Unauthorized 및 JWT::VerificationError로 실패함

git push를 시도하면 다음을 볼 수 있습니다:

  • 401 Unauthorized 에러.

  • 서버 로그에 다음이 표시됨: 

    {
  ...
  "exception.class":"JWT::VerificationError",
  "exception.message":"Signature verification raised",
  ...
}

이 오류 조합은 GitLab 서버가 GitLab 15.5 이상으로 업그레이드되었지만 Gitaly가 아직 업그레이드되지 않은 경우 발생합니다.

GitLab 15.5부터 GitLab은 공유된 비밀을 사용하는 대신 JWT 토큰을 사용하여 GitLab Shell을 인증합니다. GitLab 서버 이전에 외부 Gitaly를 업그레이드하기 위한 권장 사항을 따라야 합니다.

deny updating a hidden ref 오류로 저장소 푸시가 실패함

Gitaly에는 사용자가 업데이트 권한이 없는 읽기 전용 내부 GitLab 참조가 있습니다. 내부 참조를 git push --mirror로 업데이트하려고 하면 Git이 deny updating a hidden ref 거부 오류를 반환합니다.

다음 참조는 읽기 전용입니다:

  • refs/environments/
  • refs/keep-around/
  • refs/merge-requests/
  • refs/pipelines/

브랜치와 태그만 미러 푸시하고 보호된 참조를 미러 푸시하지 않으려면 다음을 실행하세요: 

git push origin +refs/heads/*:refs/heads/* +refs/tags/*:refs/tags/*

관리자가 푸시하고자 하는 다른 네임스페이스가 있다면 해당 패턴을 추가할 수 있습니다.

명령줄 도구가 Gitaly에 연결할 수 없음

gRPC가 Gitaly 서버에 연결할 수 없는 경우:

  • 명령줄 도구로 Gitaly 서버에 연결할 수 없음.
  • 특정 작업에서 14: Connect Failed 오류 메시지가 표시됨.

Gitaly에 TCP로 연결할 수 있는지 확인하세요: 

sudo gitlab-rake gitlab:tcp_check[GITALY_SERVER_IP,GITALY_LISTEN_PORT]

TCP 연결이:

  • 실패하는 경우 네트워크 설정과 방화벽 규칙을 확인하세요.
  • 성공하는 경우 네트워킹 및 방화벽 규칙이 올바른 것입니다.

Bash와 같은 명령줄 환경에서 프록시 서버를 사용하는 경우 gRPC 트래픽에 영향을 줄 수 있습니다.

Bash 또는 호환되는 명령줄 환경을 사용하는 경우 프록시 서버가 구성되어 있는지 확인하려면 다음 명령을 실행하세요: 

echo $http_proxy
echo $https_proxy

이러한 변수 중 하나라도 값이 있다면 Gitaly CLI 연결이 Gitaly에 연결할 수 없는 프록시를 통해 라우팅될 수 있습니다.

프록시 설정을 제거하려면 다음 명령을 실행하세요 (값이 있는 변수에 따라): 

unset http_proxy
unset https_proxy

리포지토리에 액세스할 때 Gitaly 또는 Praefect 로그에 나타나는 권한 거부 오류

Gitaly 및 Praefect 로그에 다음이 표시될 수 있습니다: 

{
  ...
  "error":"rpc error: code = PermissionDenied desc = permission denied",
  "grpc.code":"PermissionDenied",
  "grpc.meta.client_name":"gitlab-web",
  "grpc.request.fullMethod":"/gitaly.ServerService/ServerInfo",
  "level":"warning",
  "msg":"finished unary call with code PermissionDenied",
  ...
}

로그에 나타난 이 정보는 gRPC 호출 오류 응답 코드입니다.

이 오류가 발생하는 경우 Gitaly auth 토큰이 올바르게 설정되어 있는 경우에도 Gitaly 서버가 시계 드리프트에 놓여 있을 가능성이 높습니다. Gitaly에 보내는 auth 토큰에는 타임스탬프가 포함되어 있습니다. 유효하려면 Gitaly는 해당 타임스탬프가 Gitaly 서버 시간으로부터 60초 이내여야 합니다.

Gitaly 클라이언트 및 서버의 동기화를 확인하고 네트워크 시간 프로토콜(NTP) 타임 서버를 사용하여 동기화 유지하세요.

다시 구성한 후 새 주소에서 Gitaly가 수신 대기하지 않는 오류

gitaly['configuration'][:listen_addr] 또는 gitaly['configuration'][:prometheus_listen_addr] 값을 업데이트할 때, sudo gitlab-ctl reconfigure 후에도 Gitaly가 여전히 이전 주소에서 수신 대기할 수 있습니다.

이러한 경우 이 문제를 해결하려면 sudo gitlab-ctl restart를 실행하세요. 이 문제가 해결되었으므로 더 이상 필요하지 않아야 합니다.

스탠드얼론 Gitaly 노드에서 리포지토리에 액세스할 때 Gitaly 로그에 오류가 표시됨

스탠드얼론 Gitaly 노드에서 리포지토리에 액세스할 때 Gitaly 로그에 권한 거부 오류가 표시될 수 있습니다. 파일 권한이 올바르더라도 이 오류가 발생합니다. Gitaly 노드가 시계 드리프트에 놓여 있을 가능성이 높습니다.

GitLab 및 Gitaly 노드가 동기화되어 있는지 확인하고 가능하면 네트워크 시간 프로토콜(NTP) 타임 서버를 사용하여 동기화하세요.

헬스 체크 경고

/var/log/gitlab/praefect/current에서 나타나는 다음 경고는 무시해도 됩니다. 

"error":"full method name not found: /grpc.health.v1.Health/Check",
"msg":"error when looking up method info"

파일을 찾을 수 없는 오류

/var/log/gitlab/gitaly/current에서 나타나는 다음 오류는 무시해도 됩니다. 이는 GitLab Rails 애플리케이션이 리포지토리에 존재하지 않는 특정 파일을 확인하는 경우 발생합니다. 

"error":"not found: .gitlab/route-map.yml"
"error":"not found: Dockerfile"
"error":"not found: .gitlab-ci.yml"

Dynatrace 사용 시 Git 푸시가 느린 경우

Dynatrace는 사용자가 푸시할 때 sudo -u git -- /opt/gitlab/embedded/bin/gitaly-hooks 레퍼런스 트랜잭션 후크를 시작 및 종료하는 데 몇 초가 걸리도록 만들 수 있습니다. 사용자가 푸시할 때 gitaly-hooks가 두 번 실행되므로 상당한 지연이 발생합니다.

Dynatrace를 사용할 때 Git 푸시가 너무 느린 경우 Dynatrace를 비활성화하세요.

gitaly check가 401 상태 코드로 실패함

Gitaly가 내부 GitLab API에 액세스할 수 없는 경우 gitaly check가 401 상태 코드로 실패할 수 있습니다.

해결 방법 중 하나는 gitlab.rb에서 구성된 GitLab 내부 API URL이 정확한지 확인하는 것입니다. Ex) gitlab_rails['internal_api_url'].

Gitaly TLS를 사용할 때 새 병합 요청에 대한 변경 사항(diffs)이 로드되지 않는 문제

Gitaly with TLS을 활성화한 후, 새로운 병합 요청의 변경 사항(diffs)이 생성되지 않고, GitLab에서 다음 메시지가 표시됩니다: 

병합 요청을 빌드하는 중... 이 페이지는 빌드가 완료되면 업데이트됩니다.

일부 작업을 완료하기 위해 Gitaly는 자체에 연결할 수 있어야 합니다. Gitaly 인증서가 Gitaly 서버에서 신뢰되지 않으면 병합 요청 diffs를 생성할 수 없습니다.

Gitaly가 자체에 연결할 수 없는 경우, Gitaly 로그에 다음과 같은 메시지가 표시됩니다: 

{
   "level":"warning",
   "msg":"[core] [Channel #16 SubChannel #17] grpc: addrConn.createTransport failed to connect to {Addr: \"ext-gitaly.example.com:9999\", ServerName: \"ext-gitaly.example.com:9999\", }. Err: connection error: desc = \"transport: authentication handshake failed: tls: failed to verify certificate: x509: certificate signed by unknown authority\"",
   "pid":820,
   "system":"system",
   "time":"2023-11-06T05:40:04.169Z"
}
{
   "level":"info",
   "msg":"[core] [Server #3] grpc: Server.Serve failed to create ServerTransport: connection error: desc = \"ServerHandshake(\\\"x.x.x.x:x\\\") failed: wrapped server handshake: remote error: tls: bad certificate\"",
   "pid":820,
   "system":"system",
   "time":"2023-11-06T05:40:04.169Z"
}

이 문제를 해결하려면 Gitaly 서버의 /etc/gitlab/trusted-certs 폴더에 Gitaly 인증서를 추가했는지 확인하고:

  1. 인증서가 심볼릭 링크될 수 있도록 GitLab을 다시 구성합니다.
  2. Gitaly 프로세스가 인증서를 로드하도록 수동으로 Gitaly를 다시 시작하려면 sudo gitlab-ctl restart gitaly을 실행합니다.

noexec 파일 시스템에 저장된 프로세스에서 Gitaly가 실패하는 문제

(ex, /var와 같은) 마운트 지점에 noexec 옵션을 적용하면 Gitaly가 프로세스를 포크하는 것과 관련된 permission denied 오류가 발생합니다. 예를 들어: 

fork/exec /var/opt/gitlab/gitaly/run/gitaly-2057/gitaly-git2go: permission denied

이 문제를 해결하려면 파일 시스템 마운트에서 noexec 옵션을 제거합니다. 대안으로 Gitaly 실행 디렉토리를 변경할 수 있습니다:

  1. /etc/gitlab/gitlab.rb에 gitaly['runtime_dir'] = '<EXEC 허가가 설정된 경로>'를 추가하고 sudo gitlab-ctl reconfigure를 실행하여 위치를 지정합니다.

invalid argument 또는 invalid data로 커밋 서명에 실패하는 문제

커밋 서명이 다음 중 하나의 오류로 실패하는 경우:

  • invalid argument: signing key is encrypted
  • invalid data: tag byte does not have MSB set

이러한 오류는 Gitaly 커밋 서명이 블록되어 특정 사용자와 연결되지 않은 상태에서 발생합니다. GPG 서명 키는 암호가 없이 생성되거나 내보내기 전에 암호를 제거해야합니다.

info 메시지에서 Gitaly 로그에 오류가 표시되는 문제

GitLab 16.3에 도입된 버그 때문에 Gitaly 로그에 추가 항목이 작성되었습니다. 이러한 로그 항목은 "level":"info"를 포함하지만 msg 문자열에 오류가 포함되어 있는 것으로 보입니다.

예를 들어: 

{"level":"info","msg":"[core] [Server #3] grpc: Server.Serve failed to create ServerTransport: connection error: desc = \"ServerHandshake(\\\"x.x.x.x:x\\\") failed: wrapped server handshake: EOF\"","pid":6145,"system":"system","time":"2023-12-14T21:20:39.999Z"}

이 로그 항목의 이유는 기본 gRPC 라이브러리가 때로는 자세한 전송 로그를 출력하기 때문입니다. 이러한 로그 항목은 일반적으로 무시해도 안전합니다.

이 버그는 GitLab 16.4.5, 16.5.5 및 16.6.0에서 수정되어 이러한 유형의 메시지가 Gitaly 로그에 기록되지 않게 했습니다.

Gitaly 프로파일링

Gitaly는 프로메테우스 수신 포트에서 Go 내장 성능 프로파일링 도구를 노출합니다. 예를 들어, 프로메테우스가 GitLab 서버의 포트 9236에서 청취하는 경우:

  • 실행 중인 goroutines 목록과 백트레이스를 가져옵니다: 

    curl --output goroutines.txt "http://<gitaly_server>:9236/debug/pprof/goroutine?debug=2"

  • CPU 프로필을 30초간 실행합니다: 

    curl --output cpu.bin "http://<gitaly_server>:9236/debug/pprof/profile"

  • 힙 메모리 사용량을 프로필링합니다: 

    curl --output heap.bin "http://<gitaly_server>:9236/debug/pprof/heap"

  • 5초 실행 추적을 기록합니다. 실행 중에 Gitaly 성능에 영향을 줄 수 있습니다: 

    curl --output trace.bin "http://<gitaly_server>:9236/debug/pprof/trace?seconds=5"

go가 설치된 호스트에서 CPU 프로필과 힙 프로필은 브라우저에서 볼 수 있습니다: 

go tool pprof -http=:8001 cpu.bin
go tool pprof -http=:8001 heap.bin

실행 추적은 다음을 실행하여 볼 수 있습니다: 

go tool trace heap.bin

Git 작업 프로파일링

  • GitLab 16.9에서 도입됨 기능 플래그로 log_git_traces라는 플래그가 있습니다. 기본적으로 비활성화되어 있습니다.

기능 플래그: 자체 관리형 GitLab에서 기본적으로 이 기능은 사용할 수 없습니다. 사용하려면 관리자가 기능 플래그를 활성화할 필요가 있습니다. GitLab.com에서는 이 기능을 관리자만 구성할 수 있습니다. GitLab Dedicated에서는 이 기능을 사용할 수 없습니다.

Gitaly가 수행하는 Git 작업에 대한 성능 최적화, 디버깅 및 일반적인 텔레메트리 수집을 위해 Git 작업에 대한 추가 정보를 Gitaly 로그로 전송할 수 있습니다. 이 정보를 통해 사용자는 성능 최적화, 디버깅 및 일반적인 텔레메트리 수집을 위해 더 많은 통찰력을 얻을 수 있습니다. 자세한 내용은 Git Trace2 API 레퍼런스를 참조하십시오.

시스템 과부하를 방지하기 위해 추가 정보 로깅은 속도 제한이 있습니다. 속도 제한을 초과하면 추적이 건너뜁니다. 그러나 속도가 정상적으로 돌아오면 추적이 자동으로 다시 처리됩니다. 속도 제한은 시스템이 안정적으로 유지되도록 하며 과도한 추적 처리로 인한 부정적인 영향을 피하기 위해 필요합니다.

GitLab 복원 후 리포지토리가 비어 보일 때

fapolicyd를 사용하여 보안을 강화할 때, GitLab은 GitLab 백업 파일에서의 복원이 성공했지만 다음과 같은 문제가 발생할 수 있습니다:

  • 리포지토리가 비어 보입니다.

  • 새 파일을 생성하면 다음과 유사한 오류가 발생합니다: 

    13:commit: commit: starting process [/var/opt/gitlab/gitaly/run/gitaly-5428/gitaly-git2go -log-format json -log-level -correlation-id
01GP1383JV6JD6MQJBH2E1RT03 -enabled-feature-flags -disabled-feature-flags commit]: fork/exec /var/opt/gitlab/gitaly/run/gitaly-5428/gitaly-git2go: operation not permitted.

  • Gitaly 로그에 다음과 유사한 오류가 포함될 수 있습니다: 

     "error": "exit status 128, stderr: \"fatal: cannot exec '/var/opt/gitlab/gitaly/run/gitaly-5428/hooks-1277154941.d/reference-transaction':

  Operation not permitted\\nfatal: cannot exec '/var/opt/gitlab/gitaly/run/gitaly-5428/hooks-1277154941.d/reference-transaction': Operation
  not permitted\\nfatal: ref updates aborted by hook\\n\"",
 "grpc.code": "Internal",
 "grpc.meta.deadline_type": "none",
 "grpc.meta.method_type": "client_stream",
 "grpc.method": "FetchBundle",
 "grpc.request.fullMethod": "/gitaly.RepositoryService/FetchBundle",
...

현재 규칙에 따라 fapolicyd가 실행 거부를 하는지 확인하는 데 디버그 모드를 사용할 수 있습니다.

fapolicyd가 실행을 거부한다고 판명되면 다음을 고려해 보세요:

  1. fapolicyd 구성에서 /var/opt/gitlab/gitaly/의 모든 실행 파일을 허용합니다: 

    allow perm=any all : ftype=application/x-executable dir=/var/opt/gitlab/gitaly/

  2. 서비스를 재시작합니다: 

    sudo systemctl restart fapolicyd

sudo gitlab-ctl restart gitaly

fapolicyd를 사용하여 RHEL 인스턴스로 푸시할 때 Pre-receive hook declined 오류

fapolicyd가 활성화된 RHEL 기반 인스턴스로 푸시할 때 Pre-receive hook declined 오류가 발생할 수 있습니다. 이 오류는 fapolicyd가 Gitaly 이진 파일의 실행을 차단할 수 있기 때문에 발생할 수 있습니다. 이 문제를 해결하려면 다음 중 하나를 수행합니다:

  • fapolicyd를 비활성화합니다.
  • fapolicyd를 활성화한 상태에서 Gitaly 이진 파일의 실행을 허용하는 fapolicyd 규칙을 생성합니다.

Gitaly 이진 파일 실행을 허용하는 규칙을 생성하려면:

  1. /etc/fapolicyd/rules.d/89-gitlab.rules에 파일을 만듭니다.

  2. 다음을 파일에 입력합니다: 

    allow perm=any all : ftype=application/x-executable dir=/var/opt/gitlab/gitaly/

  3. 서비스를 재시작합니다: 

    systemctl restart fapolicyd

새 규칙은 데몬을 다시 시작한 후 적용됩니다.

중복 경로를 가진 스토리지를 제거한 후 리포지토리 업데이트

  • GitLab 17.1에 소개된 Rake 작업 gitlab:gitaly:update_removed_storage_projects.

GitLab 17.0에서 중복 경로로 스토리지를 구성하는 지원이 제거되었습니다. 이는 이로 인해 gitaly 구성에서 중복 스토리지 구성을 제거해야 할 수 있음을 의미합니다.

경고: 이 Rake 작업은 이전 및 새 스토리지가 동일한 Gitaly 서버의 동일한 디스크 경로를 공유하는 경우에만 사용하십시오. 다른 상황에서 이 Rake 작업을 사용하면 리포지토리가 사용 불가능해집니다. 다른 모든 상황에서는 프로젝트 리포지토리 스토리지 이동 API를 사용하여 스토리지 간에 프로젝트를 전송하세요.

Gitaly 구성에서 다른 스토리지와 동일한 경로를 사용하는 스토리지를 제거하는 경우, 이전 스토리지와 연결된 프로젝트를 새로운 스토리지로 재할당해야 합니다.

예를 들어, 다음과 유사한 구성이 있는 경우: 

gitaly['configuration'] = {
  storage: [
    {
       name: 'default',
       path: '/var/opt/gitlab/git-data/repositories',
    },
    {
       name: 'duplicate-path',
       path: '/var/opt/gitlab/git-data/repositories',
    },
  ],
}

구성에서 duplicate-path를 제거하는 경우, 다음 Rake 작업을 실행하여 해당하는 모든 프로젝트를 대신 default에 할당합니다:

Linux 패키지 설치
sudo gitlab-rake "gitlab:gitaly:update_removed_storage_projects[duplicate-path, default]"
스스로 컴파일한 설치
sudo -u git -H bundle exec rake "gitlab:gitaly:update_removed_storage_projects[duplicate-path, default]" RAILS_ENV=production