Gitaly 구성

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

Gitaly를 다음 두 가지 방법 중 하나로 구성합니다:

Linux package (Omnibus)
  1. /etc/gitlab/gitlab.rb를 편집하고 Gitaly 설정을 추가하거나 변경합니다.
  2. 파일을 저장하고 GitLab을 재구성합니다.
Helm chart (Kubernetes)
  1. Gitaly 차트를 구성합니다.
  2. Helm 릴리스를 업그레이드합니다.
Self-compiled (source)
  1. /home/git/gitaly/config.toml을 편집하고 Gitaly 설정을 추가하거나 변경합니다.
  2. 파일을 저장하고 GitLab을 다시 시작합니다.

다음 구성 옵션도 사용할 수 있습니다:

Gitaly 토큰에 대해

Gitaly 문서 전체에서 언급된 토큰은 단순히 관리자가 선택한 임의의 비밀번호입니다. 이는 GitLab API나 유사한 웹 API 토큰과는 관련이 없습니다.

고유 서버에서 Gitaly 실행

기본적으로 Gitaly는 Gitaly 클라이언트와 동일한 서버에서 실행되며 위에서 설명한대로 구성되어 있습니다. 단일 서버 설치는 다음에 의해 사용됩니다:

그러나 Gitaly는 여러 대의 기기에 걸쳐 있는 GitLab 설치에 유리한 고유 서버로 배포할 수 있습니다.

note
고유 서버에서 실행하도록 구성된 경우 Gitaly 서버는 Gitaly 클라이언트보다 먼저 업그레이드해야 합니다.
note

고유 서버에 Gitaly를 설정하는 프로세스는 다음과 같습니다:

  1. Gitaly 설치.
  2. 인증 구성.
  3. Gitaly 서버 구성.
  4. Gitaly 클라이언트 구성.
  5. 필요하지 않은 경우 Gitaly 비활성화 (선택 사항)

네트워크 아키텍처

다음 목록은 Gitaly의 네트워크 아키텍처를 보여줍니다:

  • GitLab Rails은 저장소를 저장소 스토리지로 분할합니다.
  • /config/gitlab.yml에 저장소 이름에서 (Gitaly 주소, Gitaly 토큰) 쌍의 맵이 포함되어 있습니다.
  • /config/gitlab.yml에 있는 저장소 이름->(Gitaly 주소, Gitaly 토큰) 맵은 Gitaly 네트워크 토폴로지에 대한 유일한 진실입니다.
  • (Gitaly 주소, Gitaly 토큰)은 Gitaly 서버에 해당합니다.
  • Gitaly 서버는 하나 이상의 저장소를 호스팅합니다.
  • Gitaly 클라이언트는 하나 이상의 Gitaly 서버를 사용할 수 있습니다.
  • Gitaly 주소는 모든 Gitaly 클라이언트에 대해 올바르게 해석되도록 지정되어야 합니다.
  • Gitaly 클라이언트는 다음과 같습니다:
    • Puma.
    • Sidekiq.
    • GitLab Workhorse.
    • GitLab Shell.
    • Elasticsearch indexer.
    • Gitaly 자체.
  • Gitaly 서버는 /config/gitlab.yml에서 자신의 (Gitaly 주소, Gitaly 토큰) 쌍을 사용하여 자체에 대한 RPC 호출을 수행해야 합니다.
  • 인증은 Gitaly와 GitLab Rails 노드 간에 공유되는 정적 토큰을 통해 이루어집니다.

다음 다이어그램은 Gitaly 서버와 GitLab Rails 간의 통신을 보여주며 HTTP 및 HTTPs 통신의 기본 포트가 표시됩니다.

두 개의 Gitaly 서버와 GitLab Rails이 정보를 교환하는 모습

경고: Gitaly 서버는 기본적으로 암호화되지 않은 Gitaly 네트워크 트래픽으로 인해 공개 인터넷에 노출되어서는 안 됩니다. 방화벽 사용을 권장하여 Gitaly 서버로의 액세스를 제한할 수 있습니다. 또 다른 옵션으로 TLS를 사용할 수 있습니다.

다음 섹션에서는 시크릿 토큰 abc123secret으로 두 개의 Gitaly 서버를 구성하는 방법을 설명합니다:

  • gitaly1.internal.
  • gitaly2.internal.

당신의 GitLab 설치에 default, storage1, storage2라는 세 개의 저장소 스토리지가 있다고 가정합니다.

원하는 경우 하나의 서버와 하나의 저장소 스토리지만 사용할 수 있습니다.

Gitaly 설치

각각의 Gitaly 서버에 Gitaly를 다음 중 하나로 설치합니다:

Gitaly 서버 구성

Gitaly 서버를 구성하려면 다음을 수행해야 합니다:

  • 인증 구성
  • 저장소 경로 구성
  • 네트워크 리스너 활성화

git 사용자가 구성된 저장소 경로에 대해 읽기, 쓰기 및 권한을 설정할 수 있어야 합니다.

Gitaly 토큰을 회전시키는 동안 다운타임을 피하려면 gitaly['auth_transitioning'] 설정을 사용하여 일시적으로 인증을 비활성화할 수 있습니다. 자세한 내용은 “인증 전환 모드 활성화”문서를 참조하십시오.

인증 구성

Gitaly와 GitLab은 두 가지의 공유 시크릿 토큰을 사용합니다:

  • Gitaly 토큰: Gitaly로의 gRPC 요청을 인증하는 데 사용됩니다.
  • GitLab Shell 토큰: GitLab Shell에서 GitLab 내부 API로의 인증 콜백에 사용됩니다.
Linux package (Omnibus)

  1. _Gitaly 토큰_을 구성하려면 /etc/gitlab/gitlab.rb를 편집합니다: 

    gitaly['configuration'] = {
   # ...
   auth: {
     # ...
     token: 'abc123secret',
   },
}

  2. _GitLab Shell 토큰_을 다음 두 가지 방법 중 하나로 구성합니다:

    • 메서드 1 (권장):

      Gitaly 클라이언트의 /etc/gitlab/gitlab-secrets.json을 동일한 경로로 Gitaly 서버(및 기타 Gitaly 클라이언트)에 복사합니다.

    • 메서드 2:

      /etc/gitlab/gitlab.rb를 편집합니다: 

      gitlab_shell['secret_token'] = 'shellsecret'
Self-compiled (source)
  1. Gitaly 클라이언트에서 /home/git/gitlab/.gitlab_shell_secret을 Gitaly 서버(및 다른 Gitaly 클라이언트)의 동일한 경로로 복사합니다.

  2. Gitaly 클라이언트에서 /home/git/gitlab/config/gitlab.yml을 편집합니다: 

    gitlab:
  gitaly:
    token: 'abc123secret'
  3. 파일을 저장하고 GitLab을 재시작합니다.

  4. Gitaly 서버에서 /home/git/gitaly/config.toml을 편집합니다: 

    [auth]
token = 'abc123secret'
  5. 파일을 저장하고 GitLab을 재시작합니다.

Gitaly 서버 구성

Linux 패키지 (Omnibus)

  1. /etc/gitlab/gitlab.rb 편집: 

    # Gitaly 서버에서 불필요한 서비스 실행 방지
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
gitlab_exporter['enable'] = false
gitlab_kas['enable'] = false

# 별도의 모니터링 노드를 실행 중이라면 이러한 서비스를 비활성화할 수 있습니다
prometheus['enable'] = false
alertmanager['enable'] = false

# 별도의 모니터링 노드를 실행 중이 아니라면
# 프로메테우스 접근을 활성화하고 이러한 추가 서비스를 비활성화하세요.
# 이렇게 하면 프로메테우스가 모든 인터페이스에서 수신됩니다. 이 주소/포트로의 액세스를 제한하려면 방화벽을 사용해야 합니다.
# prometheus['listen_address'] = '0.0.0.0:9090'
# prometheus['monitor_kubernetes'] = false

# 모니터링 서비스를 실행하지 않으려면 다음을 주석처리하세요 (권장하지는 않음)
# node_exporter['enable'] = false

# 'gitlab-ctl reconfigure'에서 데이터베이스 연결 방지
gitlab_rails['auto_migrate'] = false

# gitlab-shell API 콜백 URL 구성. 이것이 없으면 `git push`가 실패합니다. 이것은 'front door' GitLab URL이거나 내부 로드 밸런서일 수 있습니다.
# Gitaly 클라이언트에서 Gitaly 서버로 `/etc/gitlab/gitlab-secrets.json`을 복사하는 것을 잊지 마세요.
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'

gitaly['configuration'] = {
   # ...
   #
   # Gitaly가 모든 네트워크 인터페이스에서 연결을 수락하도록 만듭니다. 이 주소/포트로의 액세스를 제한하려면 방화벽을 사용해야 합니다.
   # TLS 연결만 지원하기를 원한다면 다음 라인을 주석 처리하세요
   listen_addr: '0.0.0.0:8075',
   auth: {
     # ...
     #
     # Gitaly 서버와 통신할 수 있는 인가된 서버만 확인하는 인증 토큰
     token: 'AUTH_TOKEN',
   },
}

  2. 각각의 Gitaly 서버에 대해 다음을 /etc/gitlab/gitlab.rb에 추가하세요:

    gitaly1.internal에 대해: 

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

    gitaly2.internal에 대해: 

    gitaly['configuration'] = {
   # ...
   storage: [
      {
         name: 'storage2',
         path: '/srv/gitlab/git-data/repositories',
      },
   ],
}
  3. 파일을 저장하고 GitLab을 다시 구성하세요.
  4. Gitaly가 GitLab 내부 API로 콜백을 수행할 수 있는지 확인하세요:
    • GitLab 15.3 이상의 경우 sudo -u git -- /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml 실행
    • GitLab 15.2 이하의 경우 sudo -u git -- /opt/gitlab/embedded/bin/gitaly-hooks check /var/opt/gitlab/gitaly/config.toml 실행
자체 컴파일(소스)

  1. /home/git/gitaly/config.toml 편집: 

    listen_addr = '0.0.0.0:8075'

runtime_dir = '/var/opt/gitlab/gitaly'

[logging]
format = 'json'
level = 'info'
dir = '/var/log/gitaly'

  2. 각각의 Gitaly 서버에 대해 다음을 /home/git/gitaly/config.toml에 추가하세요:

    gitaly1.internal에 대해: 

    [[storage]]
name = 'default'
path = '/var/opt/gitlab/git-data/repositories'

[[storage]]
name = 'storage1'
path = '/mnt/gitlab/git-data/repositories'

    gitaly2.internal에 대해: 

    [[storage]]
name = 'storage2'
path = '/srv/gitlab/git-data/repositories'

  3. /home/git/gitlab-shell/config.yml 편집: 

    gitlab_url: https://gitlab.example.com
  4. 파일을 저장하고 GitLab을 다시 시작하세요.
  5. Gitaly가 GitLab 내부 API로 콜백을 수행할 수 있는지 확인하세요:
    • GitLab 15.3 이상의 경우 sudo -u git -- /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml 실행
    • GitLab 15.2 이하의 경우 sudo -u git -- /opt/gitlab/embedded/bin/gitaly-hooks check /var/opt/gitlab/gitaly/config.toml 실행

경고: GitLab 서버에서 Gitaly로 리포지토리 데이터를 직접 복사하는 경우, 메타데이터 파일(default path /var/opt/gitlab/git-data/repositories/.gitaly-metadata)이 전송에 포함되지 않도록 확인하세요. 이 파일을 복사하면 GitLab이 Gitaly 서버에 호스팅된 리포지토리에 대한 직접 디스크 액세스를 사용하게 되어 파이프라인 생성 오류 및 커밋을 찾을 수 없음 오류 또는 구식 데이터가 발생할 수 있습니다.

Gitaly 클라이언트 구성

마지막 단계로, 로컬 Gitaly 서비스에서 Gitaly 서버로 전환하기 위해 Gitaly 클라이언트를 업데이트해야 합니다.

참고: GitLab은 default 저장소 스토리지가 구성되어야 합니다. 이 제한 사항에 대해 자세히 읽기.

이것은 모든 Gitaly 요청이 실패하게 만드는 것으로 인해 리스크가 될 수 있습니다. 예를 들어, 네트워크, 방화벽 또는 이름 해결 문제와 같이 어떠한 상황이 Gitaly 클라이언트가 Gitaly 서버에 도달하는 것을 방해하는 경우입니다.

Gitaly는 다음을 전제로 합니다.

  • 당신의 gitaly1.internal Gitaly 서버는 당신의 Gitaly 클라이언트에서 gitaly1.internal:8075로 접속할 수 있으며, 그 Gitaly 서버는 /var/opt/gitlab/git-data 및 /mnt/gitlab/git-data에서 읽기, 쓰기, 권한 설정이 가능합니다.
  • 당신의 gitaly2.internal Gitaly 서버는 당신의 Gitaly 클라이언트에서 gitaly2.internal:8075로 접속할 수 있으며, 그 Gitaly 서버는 /srv/gitlab/git-data에서 읽기, 쓰기, 권한 설정이 가능합니다.
  • 당신의 gitaly1.internal 및 gitaly2.internal Gitaly 서버는 서로에게 접속할 수 있어야 합니다.

gitaly_address 없이 일부를 로컬 Gitaly 서버로 정의하고 일부를 원격 서버(gitaly_address로)로 정의할 수 없습니다. 혼합 구성을 사용하지 않는 한 두 가지 방법 중 하나로 Gitaly 클라이언트를 구성하세요.

두 가지 방법 중 하나로 Gitaly 클라이언트를 구성합니다. 이 지침서는 암호화되지 않은 연결에 대한 것이지만, TLS 지원을 활성화할 수도 있습니다:

Linux 패키지(옴니버스)

  1. /etc/gitlab/gitlab.rb 파일을 수정합니다: 

    # Gitaly 서버에서 구성된 동일한 토큰 값을 사용합니다.
gitlab_rails['gitaly_token'] = '<AUTH_TOKEN>'

git_data_dirs({
  'default'  => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
  'storage1' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
  'storage2' => { 'gitaly_address' => 'tcp://gitaly2.internal:8075' },
})

    또는, 각 Gitaly 서버가 다른 인증 토큰을 사용하도록 구성된 경우: 

    git_data_dirs({
  'default'  => { 'gitaly_address' => 'tcp://gitaly1.internal:8075', 'gitaly_token' => '<AUTH_TOKEN_1>' },
  'storage1' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075', 'gitaly_token' => '<AUTH_TOKEN_1>' },
  'storage2' => { 'gitaly_address' => 'tcp://gitaly2.internal:8075', 'gitaly_token' => '<AUTH_TOKEN_2>' },
})
  2. 파일을 저장하고 GitLab을 재구성합니다.
  3. Gitaly 클라이언트(예: Rails 애플리케이션)에서 sudo gitlab-rake gitlab:gitaly:check를 실행하여 Gitaly 서버에 연결할 수 있는지 확인합니다.

  4. 요청 사항을 보기 위해 로그를 확인하세요: 

    sudo gitlab-ctl tail gitaly
자체 컴파일(소스)

  1. /home/git/gitlab/config/gitlab.yml 파일을 수정합니다: 

    gitlab:
  repositories:
    storages:
      default:
        gitaly_address: tcp://gitaly1.internal:8075
        gitaly_token: AUTH_TOKEN_1
      storage1:
        gitaly_address: tcp://gitaly1.internal:8075
        gitaly_token: AUTH_TOKEN_1
      storage2:
        gitaly_address: tcp://gitaly2.internal:8075
        gitaly_token: AUTH_TOKEN_2
  2. 파일을 저장하고 GitLab을 다시 시작합니다.
  3. Gitaly 클라이언트가 Gitaly 서버에 연결할 수 있는지 확인하려면 sudo -u git -H bundle exec rake gitlab:gitaly:check RAILS_ENV=production를 실행합니다.

  4. 요청 사항을 보기 위해 로그를 확인합니다: 

    tail -f /home/git/gitlab/log/gitaly.log

당신의 Gitaly 서버에서 Gitaly 로그를 확인할 때, 요청이 들어오는 것을 볼 수 있어야 합니다. Gitaly 요청을 트리거하는 확실한 방법은 GitLab에서 HTTP 또는 HTTPS로 저장소를 복제하는 것입니다.

경고: 서버 후크가 저장소별로 또는 전역적으로 구성된 경우, 이를 모두 Gitaly 서버로 이동해야 합니다. 여러 Gitaly 서버가 있는 경우, 서버 후크를 모든 Gitaly 서버로 복사해야 합니다.

혼합 구성

GitLab은 많은 Gitaly 서버 중 하나와 동일한 서버에 속할 수 있지만 로컬 및 원격 구성을 혼합하는 구성은 지원하지 않습니다. 다음 설정은 옳지 않습니다. 왜냐하면:

  • 모든 주소는 다른 Gitaly 서버에서 도달 가능해야 합니다.
  • storage1은 gitaly_address에 대한 Unix 소켓을 할당 받았으며, 이것은 일부 Gitaly 서버에는 잘못된 설정입니다. 
git_data_dirs({
  'default' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
  'storage1' => { 'path' => '/mnt/gitlab/git-data' },
  'storage2' => { 'gitaly_address' => 'tcp://gitaly2.internal:8075' },
})

로컬 및 원격 Gitaly 서버를 혼합하려면, 지역 Gitaly 서버에 대한 외부 주소를 사용하세요. 예를 들어: 

git_data_dirs({
  'default' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
  # Gitaly가 작동하는 GitLab 서버의 주소
  'storage1' => { 'gitaly_address' => 'tcp://gitlab.internal:8075' },
  'storage2' => { 'gitaly_address' => 'tcp://gitaly2.internal:8075' },
})

gitaly['configuration'] = {
  # ...
  #
  # Gitaly가 모든 네트워크 인터페이스에서 연결을 수락하도록 만듭니다
  listen_addr: '0.0.0.0:8075',
  # 또는 TLS의 경우
  tls_listen_addr: '0.0.0.0:9999',
  tls: {
    certificate_path:  '/etc/gitlab/ssl/cert.pem',
    key_path: '/etc/gitlab/ssl/key.pem',
  },
  storage: [
    {
      name: 'storage1',
      path: '/mnt/gitlab/git-data/repositories',
    },
  ],
}

path는 로컬 Gitaly 서버에 저장되는 저장소 샤드를 위해 포함될 수 있습니다. 제외되면, 해당 저장소 샤드에는 기본 Git 저장소 디렉토리가 사용됩니다.

GitLab 기본 저장소를 필요로 합니다

환경에 Gitaly 서버를 추가할 때, 원래의 default Gitaly 서비스를 교체하려 할 수 있습니다. 그러나 GitLab은 git_data_dirs에서 default 항목을 제거하도록 GitLab 응용 프로그램 서버를 다시 구성할 수 없습니다. 왜냐하면 GitLab은 default라는 이름의 git_data_dirs 항목이 필요하기 때문입니다. 이 제한에 대해 자세히 보기.

이 제한을 우회하려면:

  1. 새 Gitaly 서비스에 추가 저장소 위치를 정의하고 추가 저장소를 default로 구성합니다.
  2. 관리자 영역에서 default를 무게가 0인 상태로 설정하여 저장소가 그곳에 저장되지 않도록 합니다.

필요하지 않은 경우 Gitaly 비활성화 (선택 사항)

Gitaly를 원격 서비스로 실행하는 경우, 기본적으로 GitLab 서버에서 실행되는 로컬 Gitaly 서비스를 비활성화하고 필요한 곳에서만 실행할 수 있습니다.

GitLab 인스턴스에서 Gitaly를 비활성화하는 것은 Gitaly가 GitLab 인스턴스와 별도의 머신에서 실행되는 사용자 지정 클러스터 구성에서만 의미가 있습니다. 클러스터의 모든 머신에서 Gitaly를 비활성화하는 것은 유효한 구성이 아닙니다(일부 머신은 Gitaly 서버로 작동해야 함).

GitLab 서버에서 Gitaly를 비활성화하는 방법은 다음 중 하나입니다:

Linux 패키지(Omnibus)

  1. /etc/gitlab/gitlab.rb 파일을 편집합니다: 

    gitaly['enable'] = false

  2. 파일을 저장하고 GitLab을 다시 구성합니다.

직접 컴파일한 소스

  1. /etc/default/gitlab 파일을 편집합니다: 

    gitaly_enabled=false

  2. 파일을 저장하고 GitLab을 다시 시작합니다.

제어 그룹

경고: 환경에 제한을 설정하는 것은 신중히하고 예상치 못한 트래픽으로부터 보호하는 등 특정 상황에서만 해야 합니다. 제한에 도달하면 사용자에게 부정적인 영향을 주는 연결이 끊길 수 있습니다. 일관된 안정적인 성능을 위해 먼저 노드 사양을 조정하거나 대형 저장소를 검토하는 등 다른 옵션을 찾아보는 것이 좋습니다.

메모리에 대한 cgroup을 활성화할 때는 스왑이 Gitaly 노드에 구성되어 있지 않아야 합니다. 프로세스가 종료되지 않고 스왑을 사용하게 될 수 있는 상황이며, 이는 현저히 성능을 저하시킬 수 있습니다.

Linux에서 제어 그룹(cgroups)을 사용하여 Gitaly 프로세스가 사용할 수 있는 메모리 및 CPU 양을 제한할 수 있습니다. 더 많은 정보는 cgroups Linux 맨 페이지 를 참조하세요. cgroups는 메모리 및 CPU의 과소비로 인한 예상치 못한 리소스 고갈에 대비하여 시스템을 보호하는 데 도움이 될 수 있습니다.

일부 Git 작업은 다음과 같은 상황에서 예상치 못한 리소스를 소모할 수 있습니다: - 예상치 못한 높은 트래픽. - 모범 사례를 따르지 않는 대형 저장소에 대해 작동하는 작업 등.

강력한 보호를 위해 커널에 의해 이러한 작업을 종료하기 전에 시스템 자원을 모두 소비하지 못하도록 처리할 수 있습니다. Gitaly에는 내장된 cgroups 제어 기능이 있습니다. 구성된 경우 Gitaly는 Git 명령이 작동하는 Git 저장소에 기반하여 cgroup에 Git 프로세스를 할당합니다. 이러한 cgroups는 저장소 cgroup이라고 합니다. 각 저장소 cgroup: - 메모리 및 CPU 제한이 있습니다. - 단일 저장소의 Git 프로세스가 포함됩니다. - 일관된 해시를 사용하여 특정 저장소의 Git 프로세스가 항상 동일한 cgroup에 끝나도록합니다.

저장소 cgroup이 다음과 같은 경우: - 메모리 제한이 달성되면 커널은 종료할 후보 프로세스를 찾습니다. - CPU 제한이 있으면 프로세스는 종료되지 않지만 허용된 것보다 더 많은 CPU를 소비하지 못하도록됩니다.

참고: 이러한 제한에 도달하면 성능이 저하되고 사용자가 연결이 끊길 수 있습니다.

저장소 cgroups 구성(새로운 방법)

새 방법을 사용하여 Gitaly에서 저장소 cgroups을 구성하려면 /etc/gitlab/gitlab.rb의 gitaly['configuration'][:cgroups]에 다음과 같은 설정을 사용하세요: - mountpoint는 부모 cgroup 디렉토리가 마운트된 위치입니다. 기본값은 /sys/fs/cgroup입니다. - hierarchy_root는 Gitaly이 그룹을 생성하는 부모 cgroup이며, Gitaly의 사용자 및 그룹이 소유해야 합니다. Linux 패키지 설치는 Gitaly가 시작되면 일련의 디렉터리 /cpu|memory/hierarchy_root를 생성합니다. - memory_bytes는 Gitaly가 생성하는 모든 Git 프로세스에 공통으로 적용되는 총 메모리 제한입니다. 0은 제한이 없음을 의미합니다. - cpu_shares는 Gitaly가 생성하는 모든 Git 프로세스에 공통으로 적용되는 CPU 제한입니다. 0은 제한이 없음을 의미합니다. 최대값은 1024 shares로 100% CPU를 나타냅니다. - cpu_quota_us는 cgroups의 프로세스가 이 할당 한계 값을 초과하면 그룹의 프로세스를 속도 제한하는 것입니다. 우리는 cfs_period_us를 100ms로 설정하여 1코어는 100000입니다. 0은 제한이 없음을 의미합니다. - repositories.count는 cgroups 풀에 포함된 cgroups 수입니다. 새로운 Git 명령이 생성될 때마다 Gitaly는 이 cgroups 중 하나에 할당합니다. 저장소 cgroup을 대상으로 한 Git 명령은 이러한 cgroups 중 하나에 항상 할당되도록 순환 해싱 알고리즘을 사용합니다. - repositories.memory_bytes는 저장소 cgroup에 포함된 모든 Git 프로세스에 적용되는 총 메모리 제한입니다. 0은 제한이 없음을 의미합니다. 이 값은 최상위 memory_bytes 값보다 클 수 없습니다. - repositories.cpu_shares는 저장소 cgroup에 포함된 모든 Git 프로세스에 적용되는 CPU 제한입니다. 0은 제한이 없음을 의미합니다. 최대값은 1024 shares로 100% CPU를 나타냅니다. 이 값은 최상위 cpu_shares 값보다 클 수 없습니다. - repositories.cpu_quota_us는 저장소 cgroup에 포함된 모든 Git 프로세스에 적용되는 cfs_quota_us입니다. Git 프로세스가 주어진 할당량을 초과하지 못합니다. 우리는 cfs_period_us를 100ms로 설정하여 1코어는 100000입니다. 0은 제한이 없음을 의미합니다. - repositories.max_cgroups_per_repo는 특정 저장소 cgroups를 타겟으로 하는 Git 프로세스가 분산될 수 있는 리포지토리 cgroups의 수입니다. 이를 통해 리포지토리 cgroups에 대해 더 보수적인 CPU 및 메모리 제한을 설정하고 여전히 버스트 워크로드를 허용할 수 있습니다. 예를 들어, max_cgroups_per_repo가 2라면 memory_bytes 제한이 10GB인 Git 작업이 독립적으로 특정 저장소에 대해 최대 20GB의 메모리를 사용할 수 있습니다.

예(필수는 아닌 설정): ruby # in /etc/gitlab/gitlab.rb gitaly['configuration'] = { # ... cgroups: { mountpoint: '/sys/fs/cgroup', hierarchy_root: 'gitaly', memory_bytes: 64424509440, # 60gb cpu_shares: 1024, cpu_quota_us: 400000 # 4 cores repositories: { count: 1000, memory_bytes: 32212254720, # 20gb cpu_shares: 512, cpu_quota_us: 200000, # 2 cores max_cgroups_per_repo: 2 }, }, }

리파지토리 cgroups 구성(레거시 방법)

Gitaly에서 레거시 방법을 사용하여 리파지토리 cgroups를 구성하려면 /etc/gitlab/gitlab.rb에서 다음 설정을 사용합니다:

  • cgroups_count는 생성된 cgroups의 수입니다. 새로운 명령이 실행될 때마다 Gitaly는 명령의 명령행 인수에 기반하여 이러한 cgroups 중 하나에 할당합니다. 원형 해싱 알고리즘은 명령을 이러한 cgroups에 할당합니다.
  • cgroups_mountpoint는 부모 cgroup 디렉터리가 마운트된 위치입니다. 기본값은 /sys/fs/cgroup입니다.
  • cgroups_hierarchy_root는 Gitaly가 그룹을 생성하는 부모 cgroup이며 사용자 및 그룹 Gitaly가 실행됩니다. Linux 패키지 설치시 Gitaly가 시작될 때 마운트지점/<cpu|memory>/헤어라키_루트 디렉터리 세트가 생성됩니다.
  • cgroups_memory_enabled는 cgroups에서 메모리 제한을 활성화 또는 비활성화합니다.
  • cgroups_memory_bytes는 각 cgroup이 추가된 프로세스에 부과하는 총 메모리 한도입니다.
  • cgroups_cpu_enabled는 cgroups에서 CPU 제한을 활성화 또는 비활성화합니다.
  • cgroups_cpu_shares는 각 cgroup이 추가된 프로세스에 부과하는 CPU 제한입니다. 최대 1024개의 쉐어가 있으며, 이것은 CPU의 100%를 나타냅니다.

예시: 

# in /etc/gitlab/gitlab.rb
gitaly['cgroups_count'] = 1000
gitaly['cgroups_mountpoint'] = "/sys/fs/cgroup"
gitaly['cgroups_hierarchy_root'] = "gitaly"
gitaly['cgroups_memory_limit'] = 32212254720
gitaly['cgroups_memory_enabled'] = true
gitaly['cgroups_cpu_shares'] = 1024
gitaly['cgroups_cpu_enabled'] = true

오버 서브스크립션 구성

이전의 예에서 새 구성 방법을 사용하여:

  • 최상위 레벨 메모리 제한은 60GB로 제한됩니다.
  • 리파지토리 풀의 1000개 cgroups마다 20GB로 제한됩니다.

이 구성은 “오버 서브스크립션”으로 이어집니다. 풀의 각 cgroup은 최상위 메모리 제한의 1/1000보다 훨씬 큰 용량을 갖습니다.

이 전략에는 두 가지 주요 이점이 있습니다:

  • 최상위 cgroup의 메모리 제한이 호스트 전체 메모리 공방(OMM)으로부터 호스트를 보호해줍니다. 최상위 cgroup의 메모리 제한이 호스트 용량보다 작게 설정될 수 있습니다. 해당 cgroup 외의 프로세스는 OMM 위험에 노출되지 않습니다.
  • 풀의 각 개별 cgroup이 부모 cgroup의 한계보다 작지만 부모의 한계의 1/N보다 크게 터져버릴 수 있는 후 버스트를 허용합니다(이 예에서는 20GB). 이 예에서 최대 3개의 하위 cgroup가 각자의 최대치까지 동시에 버스트할 수 있습니다. 일반적으로 모든 1000개의 cgroups은 20GB보다 작은 용량을 사용합니다.

배경 리파지토리 최적화

리파지토리에는 빈 디렉터리와 불필요한 구성 설정이 축적되어 Git 작업을 느리게 할 수 있습니다. Gitaly는 이러한 항목을 정리하고 성능을 향상시키기 위해 매일 백그라운드 작업을 예약할 수 있습니다.

경고: 백그라운드 리파지토리 최적화는 실험적인 기능이며 실행 중에 호스트에 상당한 부하를 줄 수 있습니다. 이 작업을 피크 시간 외에 스케줄하고 지속 시간을 짧게 유지(예: 30-60분)하도록 합니다.

다음 중 한 가지 방법으로 백그라운드 리파지토리 최적화를 구성합니다:

리눅스 패키지(Omnibus)

/etc/gitlab/gitlab.rb를 편집하고 다음을 추가합니다: 

gitaly['configuration'] = {
  # ...
  daily_maintenance: {
    # ...
    start_hour: 4,
    start_minute: 30,
    duration: '30m',
    storages: ['default'],
  },
}
직접 컴파일(소스)

/home/git/gitaly/config.toml을 편집하고 다음을 추가합니다: 

[daily_maintenance]
start_hour = 4
start_minute = 30
duration = '30m'
storages = ["default"]

Gitaly 인증 토큰 회전

운영 환경에서 자격 증명을 회전시키는 것은 종종 다운타임이 필요하며 장애를 유발할 수 있습니다.

그러나 Gitaly 자격 증명을 서비스 중단 없이 회전할 수 있습니다. Gitaly 인증 토큰을 회전하는 것은 다음을 포함합니다:

이 절차는 GitLab을 단일 서버에서 실행하는 경우에도 잘 작동합니다. 이 경우 “Gitaly 서버” 및 “Gitaly 클라이언트”는 동일한 기계를 가리킵니다.

인증 모니터링 확인

Gitaly 인증 토큰을 회전하기 전에 GitLab 설치의 Prometheus를 사용하여 인증 동작을 모니터링할 수 있는지 확인합니다.

그런 다음 절차를 계속할 수 있습니다.

“인증 전환” 모드 활성화하기

다음과 같이 Gitaly 서버에서 Gitaly 인증을 일시적으로 비활성화하여 “인증 전환” 모드로 넣습니다: 

# in /etc/gitlab/gitlab.rb
gitaly['configuration'] = {
  # ...
  auth: {
    # ...
    transitioning: true,
  },
}

이 변경을 한 후 Prometheus 쿼리를 실행하면 다음과 유사한 값을 반환해야 합니다: 

{enforced="false",status="would be ok"}  4424.985419441742

enforced="false"이므로 새 토큰을 배포해도 안전합니다.

Gitaly 인증 토큰 업데이트

새 Gitaly 인증 토큰으로 업데이트하기 위해 각 Gitaly 클라이언트 및 Gitaly 서버에서 다음을 수행합니다.

  1. 구성 업데이트: ruby # in /etc/gitlab/gitlab.rb gitaly['configuration'] = { # ... auth: { # ... token: '<new secret token>', }, }

  2. Gitaly 재시작: shell gitlab-ctl restart gitaly

이 변경사항이 배포되는 동안에 Prometheus 쿼리를 실행하면 enforced="false",status="denied" 카운터에 0이 아닌 값이 반환됩니다.

권한 인증 실패가 없는지 확인하세요

새 토큰이 설정되고 관련된 모든 서비스가 재시작된 후에, 여러분은 임시로 다음과 같은 혼합 결과를 인증 모니터링 확인할 수 있습니다:

  • status="would be ok"
  • status="denied"

새 토큰이 모든 Gitaly 클라이언트 및 Gitaly 서버에서 파악되면, 오직 0이 아닌 비율은 enforced="false",status="would be ok"여야 합니다.

“인증 전환” 모드 비활성화

Gitaly 인증을 다시 활성화하려면 “인증 전환” 모드를 비활성화하세요. 다음과 같이 Gitaly 서버의 구성을 업데이트하세요: 

# in /etc/gitlab/gitlab.rb
gitaly['configuration'] = {
  # ...
  auth: {
    # ...
    transitioning: false,
  },
}

경고: 이 단계를 완료하지 않으면, Gitaly 인증이 되지 않습니다.

인증이 강제되고 있는지 확인하세요

Prometheus 쿼리를 새로고침하세요. 이제 시작할 때와 유사한 결과를 확인해야 합니다. 예: 

{enforced="true",status="ok"}  4424.985419441742

enforced="true"는 인증이 강제되고 있음을 의미합니다.

Pack-objects 캐시

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

Gitaly, Git 저장소의 저장소를 제공하는 서비스로 구성할 수 있으며, Git fetch 응답의 짧은 롤링 창을 캐시할 수 있습니다. 이를 통해 서버가 많은 CI fetch 트래픽을 수신할 때 서버 부하를 감소시킬 수 있습니다.

pack-objects 캐시는 git pack-objects를 감싸며, Git의 내부 부분으로써 PostUploadPack 및 SSHUploadPack Gitaly RPCs를 간접적으로 호출합니다. 캐시가 활성화되면 PostUploadPack 또는 SSHUploadPack를 사용하는 모든 것에 이점이 있습니다. 이 캐시는 다음과 정말 관계없이:

  • 전송(HTTP 또는 SSH).
  • Git 프로토콜 버전(v0 또는 v2).
  • 전체 복제, 점진적 fetch, 얕은 복제 또는 부분 복제와 같은 Fetch 유형.

이 캐시의 강점은 중복된 동시 Fetch를 중복 처리할 수 있는 능력입니다. 이것은 다음을 가집니다:

  • 많은 동시 작업을 실행하는 GitLab 인스턴스에 이점이 있습니다. 서버 CPU 사용량이 현저히 감소해야 합니다.
  • 고유 fetch에 전혀 이점이 없습니다. 예를 들어, 로컬 컴퓨터에 저장소를 복제하여 빠른 확인 작업을 실행하는 경우, 이 캐시로 인해 혜택을 볼 가능성이 낮습니다.

pack-objects 캐시는 로컬 캐시입니다. 이것은 다음을 포함합니다:

  • 활성화된 Gitaly 프로세스의 메모리에 메타데이터를 저장합니다.
  • 실제로 캐시하는 Git 데이터를 로컬 저장소의 파일에 저장합니다.

로컬 파일 사용은 운영 체제가 캐시 파일의 일부를 자동으로 RAM에 유지할 수 있기 때문에 더 빨라집니다.

pack-objects 캐시는 디스크 쓰기 IO를 크게 증가시킬 수 있으므로 기본적으로 비활성화됩니다. GitLab 15.11 이후, 작성 작업량은 대략적으로 50% 적지만, 이 캐시는 여전히 기본적으로 비활성화되어 있습니다.

캐시 구성

pack-objects 캐시에 대한 이 구성 설정이 제공됩니다. 각 설정에 대한 자세한 내용은 아래에서 논의됩니다.

설정 기본값 설명
enabled false 캐시를 켭니다. 꺼져 있으면, Gitaly는 요청마다 별도의 git pack-objects 프로세스를 실행합니다.
dir <PATH TO FIRST STORAGE>/+gitaly/PackObjectsCache 캐시 파일이 저장되는 로컬 디렉터리.
max_age 5분 (5 minutes) 이보다 오래된 캐시 엔트리는 삭제되어 디스크에서 제거됩니다.
min_occurrences 1 캐시 엔트리가 작성되기 전에 키가 발생해야 하는 최소 횟수.

/etc/gitlab/gitlab.rb에서 다음과 같이 설정하세요: 

gitaly['configuration'] = {
  # ...
  pack_objects_cache: {
    # ...
    enabled: true,
    # dir: '/var/opt/gitlab/git-data/repositories/+gitaly/PackObjectsCache',
    # max_age: '5m',
    # min_occurrences: 1,
  },
}

enabled 기본값은 false입니다

캐시는 기본적으로 비활성화되어 있습니다. 이것은 경우에 따라 디스크에 기록되는 바이트 수가 극심하게 증가할 수 있기 때문입니다. GitLab.com에서, 저장소 스토리지 디스크가 추가 작업량을 처리할 수 있는 것을 확인했지만, 이것이 어디에서나 동일하다고 가정할 수 없다고 생각했습니다.

캐시 저장 디렉토리 dir

캐시는 파일을 저장할 디렉토리가 필요합니다. 이 디렉토리는 다음과 같아야 합니다:

  • 충분한 공간을 갖춘 파일 시스템에서 실행되어야 합니다. 캐시 파일 시스템이 공간 부족 상태가 되면 모든 fetch가 실패합니다.
  • 충분한 IO 대역폭을 갖춘 디스크에 있어야 합니다. 캐시 디스크의 IO 대역폭이 고갈되면 모든 fetch뿐만 아니라 전체 서버가 느려집니다.

기본적으로, 캐시 저장 디렉터리는 구성 파일에서 정의된 첫 번째 Gitaly 저장소의 하위 디렉터리로 설정됩니다.

여러 Gitaly 프로세스는 캐시 저장을 위해 동일한 디렉토리를 사용할 수 있습니다. 각 Gitaly 프로세스 는 고유한 랜덤 문자열을 캐시 파일 이름의 일부로 사용합니다. 이것은 다음을 의미합니다:

  • 충돌하지 않습니다.
  • 다른 프로세스의 파일을 재사용하지 않습니다.

기본 디렉터리는 캐시 파일을 저장소 데이터와 동일한 파일 시스템에 저장하지만 이는 필수 조건이 아닙니다. 인프라에 더 잘 작동하는 경우, 캐시 파일을 다른 파일 시스템에 저장할 수 있습니다.

디스크에서 필요로 하는 IO 대역폭의 양은 다음에 의존합니다:

  • Gitaly 서버의 저장소의 크기와 모양.
  • 사용자가 생성하는 트래픽의 유형.

gitaly_pack_objects_generated_bytes_total 메트릭을 초기에 캐시 히트 비율이 0%라고 가정하여 비관적으로 추정할 수 있습니다.

필요한 공간은 다음에 의존합니다:

  • 사용자가 캐시에서 끌어오는 초당 바이트 수.
  • max_age 캐시 만료 윈도우의 크기.

사용자가 100MB/s를 끌어오고 5분 창을 사용한다면, 평균적으로 캐시 디렉토리에는 5*60*100MB = 30GB의 데이터가 있다고 예상됩니다. 이 평균은 예상 평균이며 보장된 것이 아닐 수 있습니다. 최대 크기는 이 평균을 초과할 수 있습니다.

캐시 만료 윈도우 max_age

max_age 구성 설정을 사용하면 캐시 히트 확률과 캐시 파일의 평균 저장 용량을 제어할 수 있습니다. max_age보다 오래된 항목은 디스크에서 삭제됩니다.

추방은 진행 중인 요청에는 간섭하지 않습니다. 느린 연결을 통한 가져오기 소요 시간보다 max_age가 짧아도 상관 없습니다. 왜냐하면 유닉스 파일 시스템은 삭제된 파일을 읽는 모든 프로세스가 파일을 닫을 때까지 파일을 진정으로 삭제하지 않기 때문입니다.

최소 키 발생 횟수 min_occurrences

min_occurrences 설정은 동일한 요청이 새 캐시 항목을 만들기 전에 얼마나 자주 발생해야 하는지를 제어합니다. 기본값은 1로, 고유 요청은 캐시에 기록되지 않습니다.

만약:

  • 이 번호를 늘리면 캐시 히트 비율이 감소하고 캐시가 더 적은 디스크 공간을 사용합니다.
  • 이 번호를 줄이면 캐시 히트 비율이 증가하고 캐시가 더 많은 디스크 공간을 사용합니다.

min_occurrences를 1로 설정해야 합니다. GitLab.com에서 0에서 1로 변경함으로써 캐시 디스크 공간을 50% 절약했으며 캐시 히트 비율에 거의 영향을 주지 않았습니다.

캐시 확인

캐시를 메트릭을 사용하여 확인하고 다음에 로그된 정보를 확인할 수 있습니다. 이러한 로그는 gRPC 로그의 일부이며 호출이 실행될 때 발견할 수 있습니다.

필드 설명
pack_objects_cache.hit 현재 pack-objects 캐시가 히트되었는지를 나타냄 (true 또는 false)
pack_objects_cache.key pack-objects 캐시에 사용된 캐시 키
pack_objects_cache.generated_bytes 새로 작성되는 캐시의 크기(바이트)
pack_objects_cache.served_bytes 제공되는 캐시의 크기(바이트)
pack_objects.compression_statistics pack-objects 생성에 관한 통계
pack_objects.enumerate_objects_ms 클라이언트가 보낸 객체를 열거하는 데 사용된 총 시간(밀리초)
pack_objects.prepare_pack_ms 클라이언트에게 다시 전송하기 전에 팩 파일을 준비하는 데 사용된 총 시간(밀리초)
pack_objects.write_pack_file_ms 클라이언트에게 팩 파일을 다시 전송하기 위해 사용된 총 시간(밀리초). 클라이언트의 인터넷 연결에 크게 의존함
pack_objects.written_object_count Gitaly가 클라이언트에게 다시 전송한 총 객체 수
  • 캐시 미스인 경우, Gitaly는 pack_objects_cache.generated_bytes와 pack_objects_cache.served_bytes 메시지를 모두 기록합니다. 또한 pack-object 생성에 대한 더 자세한 통계를 기록합니다.
  • 캐시 히트인 경우, Gitaly는 pack_objects_cache.served_bytes 메시지만 기록합니다.

예시: 

{
  "bytes":26186490,
  "correlation_id":"01F1MY8JXC3FZN14JBG1H42G9F",
  "grpc.meta.deadline_type":"none",
  "grpc.method":"PackObjectsHook",
  "grpc.request.fullMethod":"/gitaly.HookService/PackObjectsHook",
  "grpc.request.glProjectPath":"root/gitlab-workhorse",
  "grpc.request.glRepository":"project-2",
  "grpc.request.repoPath":"@hashed/d4/73/d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35.git",
  "grpc.request.repoStorage":"default",
  "grpc.request.topLevelGroup":"@hashed",
  "grpc.service":"gitaly.HookService",
  "grpc.start_time":"2021-03-25T14:57:52.747Z",
  "level":"info",
  "msg":"finished unary call with code OK",
  "peer.address":"@",
  "pid":20961,
  "span.kind":"server",
  "system":"grpc",
  "time":"2021-03-25T14:57:53.543Z",
  "pack_objects.compression_statistics": "Total 145991 (delta 68), reused 6 (delta 2), pack-reused 145911",
  "pack_objects.enumerate_objects_ms": 170,
  "pack_objects.prepare_pack_ms": 7,
  "pack_objects.write_pack_file_ms": 786,
  "pack_objects.written_object_count": 145991,
  "pack_objects_cache.generated_bytes": 49533030,
  "pack_objects_cache.hit": "false",
  "pack_objects_cache.key": "123456789",
  "pack_objects_cache.served_bytes": 49533030,
  "peer.address": "127.0.0.1",
  "pid": 8813,
}

cat-file 캐시

많은 Gitaly RPCs는 저장소에서 Git 객체를 찾아야 합니다. 대부분의 경우 이를 위해 git cat-file --batch 프로세스를 사용합니다. 성능을 개선하기 위해 Gitaly는 이러한 git cat-file 프로세스를 RPC 호출 간에 재사용할 수 있습니다. 이전에 사용한 프로세스는 “Git cat-file 캐시”에 유지됩니다. 이를 통제하여 시스템 리소스를 얼마나 많이 사용하는지 제어할 수 있습니다.

기본 제한은 100개의 cat-file으로, git cat-file --batch와 git cat-file --batch-check 프로세스로 이루어집니다. “너무 많은 파일이 열려 있습니다”와 같은 오류나 새로운 프로세스를 생성할 수 없는 경우에는 이 제한을 낮추어야 할 수 있습니다.

이상적으로는 이 숫자가 표준 트래픽을 처리할 수 있을 만큼 크게 설정되어야 합니다. 제한을 높이면 전후로 캐시 히트 비율을 측정해야 합니다. 히트 비율이 개선되지 않는다면 더 높은 제한은 의미 있는 차이를 만들지 않을 것입니다. 다음은 히트 비율을 확인하기 위한 예시 Prometheus 쿼리입니다: 

sum(rate(gitaly_catfile_cache_total{type="hit"}[5m])) / sum(rate(gitaly_catfile_cache_total{type=~"(hit)|(miss)"}[5m]))

cat-file 캐시를 Gitaly 구성 파일에서 구성하세요.

GitLab UI 커밋에 대한 Gitaly 서명 구성

  • GitLab 15.4에 도입됨(소개됨).
  • GitLab 16.3에 도입된 GitLab UI 커밋에 대한 Verified 뱃지 표시, 기본적으로 비활성화된 gitaly_gpg_signing 플래그로 available.
  • GitLab 16.3에 도입된 multiple keys specified in rotated_signing_keys 옵션을 사용한 서명 검증.
  • GitLab 17.0에서 self-managed 및 GitLab Dedicated에서 기본적으로 활성화됨.

플래그: self-managed GitLab에서는 기본적으로 이 기능을 사용할 수 있습니다. 피처를 숨기려면 관리자가 gitaly_gpg_signing이름의 피처 플래그를 비활성화할 수 있습니다. GitLab.com에서는 이 기능을 사용할 수 없습니다. GitLab Dedicated에서는 이 기능을 사용할 수 있습니다.

기본적으로 Gitaly는 GitLab UI를 사용하여 만든 커밋에 서명을하지 않습니다. 예를 들어, 다음을 사용하여 만든 커밋에 서명하지 않습니다.

  • Web 편집기.
  • Web IDE.
  • 병합 리퀘스트.

Gitaly를 구성하여 GitLab UI를 사용하여 만든 커밋에 서명하도록 설정할 수 있습니다.

기본적으로 Gitaly는 커밋의 작성자를 커미터로 설정합니다. 이 경우, 커밋의 서명이 작성자나 커미터 중 어느 쪽에도 속하지 않기 때문에, 로컬에서는 커밋을 Verify하기가 더 어려울 수 있습니다.

Gitaly를 구성하여 커밋이 인스턴스에 의해 커밋된 것으로 표시하도록 committer_email 및 committer_name을 설정할 수 있습니다. 예를 들어, GitLab.com의 경우 이러한 구성 옵션은 noreply@gitlab.com 및 GitLab로 설정됩니다.

rotated_signing_keys는 검증에만 사용할 키 목록입니다. Gitaly는 구성된 signing_key를 사용하여 웹 커밋을 검증하고, 성공할 때까지 하나씩 로테이팅된 키를 사용합니다. 다음 중 하나에 해당하는 경우 rotated_signing_keys 옵션을 설정합니다.

  • 서명 키가 로테이션된 경우.
  • 다른 인스턴스에서 프로젝트를 마이그레이션하려는 경우 여러 키를 지정하고, 웹 커밋을 Verified로 표시하려는 경우.

GitLab UI로 만든 커밋에 서명하는 Gitaly를 두 가지 방법 중 하나로 구성할 수 있습니다.

Linux 패키지 (Omnibus)

  1. GPG 키를 생성하고 내보내거나, SSH 키를 생성합니다. 최적의 성능을 위해 EdDSA 키를 사용하세요.

    GPG 키 내보내기: 

     gpg --export-secret-keys <ID> > signing_key.gpg

    또는 SSH 키 생성(암호 없음): 

     ssh-keygen -t ed25519 -f signing_key.ssh
  2. Gitaly 노드에서 키를 /etc/gitlab/gitaly/로 복사합니다.

  3. /etc/gitlab/gitlab.rb를 편집하고 gitaly['git']['signing_key']를 구성합니다: 

     gitaly['configuration'] = {
     # ...
     git: {
         # ...
         committer_name: 'Your Instance',
         committer_email: 'noreply@yourinstance.com',
         signing_key: '/etc/gitlab/gitaly/signing_key.gpg',
         rotated_signing_keys: ['/etc/gitlab/gitaly/previous_signing_key.gpg'],
         # ...
     },
 }
  4. 파일을 저장하고 GitLab 다시 구성합니다.
자체 컴파일(소스)

  1. GPG 키를 생성하고 내보내거나, SSH 키를 생성합니다. 최적의 성능을 위해 EdDSA 키를 사용하세요.

    GPG 키 내보내기: 

     gpg --export-secret-keys <ID> > signing_key.gpg

    또는 SSH 키 생성(암호 없음): 

     ssh-keygen -t ed25519 -f signing_key.ssh
  2. Gitaly 노드에서 키를 /etc/gitlab로 복사합니다.

  3. /home/git/gitaly/config.toml을 편집하고 signing_key를 구성합니다: 

     [git]
 committer_name = "Your Instance"
 committer_email = "noreply@yourinstance.com"
 signing_key = "/etc/gitlab/gitaly/signing_key.gpg"
 rotated_signing_keys = ["/etc/gitlab/gitaly/previous_signing_key.gpg"]
  4. 파일을 저장하고 GitLab 재시작합니다.

외부 명령을 사용하여 구성 생성

외부 명령을 사용하여 Gitaly 구성의 일부를 생성할 수 있습니다. 다음을 수행할 수 있습니다.

  • 각각의 노드에 전체 구성을 배포하지 않고 노드를 구성합니다.
  • 노드 설정의 자동 발견을 사용하여 구성합니다. 예를 들어, DNS 항목을 사용할 수 있습니다.
  • 노드 시작시 시크릿을 구성하여 평문으로 표시되지 않아도록 합니다.

외부 몹령을 사용하여 구성을 생성하려면 Gitaly 노드의 원하는 구성을 JSON 형식으로 표준 출력에 덤프하는 스크립트를 제공해야 합니다.

예를 들어, 아래 명령은 AWS 시크릿을 사용하여 GitLab 내부 API에 연결하는 데 사용되는 HTTP 암호를 구성합니다: 

#!/usr/bin/env ruby
require 'json'
JSON.generate({"gitlab": {"http_settings": {"password": `aws get-secret-value --secret-id ...`}}})

그런 다음 Gitaly가 스크립트 경로를 알 수 있도록 다음 두 가지 방법 중 하나로 스크립트 경로를 Gitaly에 알리고 있어야 합니다.

Linux 패키지 (Omnibus)

/etc/gitlab/gitlab.rb를 편집하고 config_command를 구성합니다: 

gitaly['configuration'] = {
    config_command: '/path/to/config_command',
}
자체 컴파일(소스)

/home/git/gitaly/config.toml을 편집하고 config_command를 구성합니다: 

config_command = "/path/to/config_command"

구성 후에 Gitaly는 명령을 시작하고 해당 표준 출력을 JSON으로 파싱합니다. 결과 구성은 다시 다른 Gitaly 구성에 병합됩니다.

다음 중 하나라도 해당되면 Gitaly는 시작에 실패합니다.

  • 구성 명령이 실패하는 경우.
  • 명령에 의해 생성된 출력을 유효한 JSON으로 파싱할 수 없는 경우.

서버 측 백업 구성

저장소 백업을 구성하여 각 저장소를 호스팅하는 Gitaly 노드가 백업을 생성하고 객체 스토리지로 스트리밍하도록 구성할 수 있습니다. 이는 백업을 생성하고 복원하는 데 필요한 네트워크 리소스를 줄이는 데 도움이 됩니다.

각 Gitaly 노드는 백업을 위해 객체 스토리지에 연결하도록 구성되어야 합니다.

서버 측 백업을 구성한 후 서버 측 저장소 백업을 생성할 수 있습니다.

Azure Blob 저장소 구성

백업용 Azure Blob 저장소를 구성하는 방법은 설치 유형에 따라 다릅니다. 직접 컴파일된 설치의 경우 AZURE_STORAGE_ACCOUNT 및 AZURE_STORAGE_KEY 환경 변수를 GitLab 외부에서 설정해야 합니다.

Linux 패키지 (Omnibus)

/etc/gitlab/gitlab.rb를 편집하고 go_cloud_url을 구성합니다: 

gitaly['env'] = {
    'AZURE_STORAGE_ACCOUNT' => 'azure_storage_account',
    'AZURE_STORAGE_KEY' => 'azure_storage_key' # 또는 'AZURE_STORAGE_SAS_TOKEN'
}
gitaly['configuration'] = {
    backup: {
        go_cloud_url: 'azblob://<bucket>'
    }
}
Helm 차트 (Kubernetes)

Helm 기반 배포의 경우 Gitaly 차트를 위한 서버 측 백업 설명서를 참조하십시오.

직접 컴파일 (소스)

/home/git/gitaly/config.toml을 편집하고 go_cloud_url을 구성합니다: 

[backup]
go_cloud_url = "azblob://<bucket>"

Google Cloud 저장소 구성

Google Cloud 저장소(GCP)는 Application Default Credentials를 사용하여 인증합니다. 각 Gitaly 서버에서 Application Default Credentials를 설정하는 방법은 다음 중 하나를 사용합니다:

  • gcloud auth application-default login 명령어.
  • GOOGLE_APPLICATION_CREDENTIALS 환경 변수. 직접 컴파일된 설치의 경우 GitLab 외부에서 환경 변수를 설정합니다.

자세한 정보는 Application Default Credentials를 참조하십시오.

대상 버킷은 go_cloud_url 옵션을 사용하여 구성됩니다.

Linux 패키지 (Omnibus)

/etc/gitlab/gitlab.rb를 편집하고 go_cloud_url을 구성합니다: 

gitaly['env'] = {
    'GOOGLE_APPLICATION_CREDENTIALS' => '/path/to/service.json'
}
gitaly['configuration'] = {
    backup: {
        go_cloud_url: 'gs://<bucket>'
    }
}
Helm 차트 (Kubernetes)

Helm 기반 배포의 경우 Gitaly 차트를 위한 서버 측 백업 설명서를 참조하십시오.

직접 컴파일 (소스)

/home/git/gitaly/config.toml을 편집하고 go_cloud_url을 구성합니다: 

[backup]
go_cloud_url = "gs://<bucket>"

S3 저장소 구성

S3 저장소 인증을 구성하는 방법은 다음과 같습니다:

  • AWS CLI로 인증하는 경우 기본 AWS 세션을 사용할 수 있습니다.
  • 그렇지 않으면 AWS_ACCESS_KEY_ID 및 AWS_SECRET_ACCESS_KEY 환경 변수를 사용합니다. 직접 컴파일된 설치의 경우 GitLab 외부에서 환경 변수를 설정합니다.

자세한 정보는 AWS 세션 문서를 참조하십시오.

대상 버킷 및 리전은 go_cloud_url 옵션을 사용하여 구성됩니다.

Linux 패키지 (Omnibus)

/etc/gitlab/gitlab.rb를 편집하고 go_cloud_url을 구성합니다: 

gitaly['env'] = {
    'AWS_ACCESS_KEY_ID' => 'aws_access_key_id',
    'AWS_SECRET_ACCESS_KEY' => 'aws_secret_access_key'
}
gitaly['configuration'] = {
    backup: {
        go_cloud_url: 's3://<bucket>?region=us-west-1'
    }
}
Helm 차트 (Kubernetes)

Helm 기반 배포의 경우 Gitaly 차트를 위한 서버 측 백업 설명서를 참조하십시오.

직접 컴파일 (소스)

/home/git/gitaly/config.toml을 편집하고 go_cloud_url을 구성합니다: 

[backup]
go_cloud_url = "s3://<bucket>?region=us-west-1"

S3 호환 서버 구성

MinIO와 같은 S3 호환 서버는 endpoint 매개변수를 추가하여 S3와 유사하게 구성됩니다.

다음 매개변수가 지원됩니다:

  • region: AWS 지역.
  • endpoint: 엔드포인트 URL.
  • disabledSSL: true 값은 SSL을 비활성화합니다.
  • s3ForcePathStyle: true 값은 경로 스타일 주소 지정을 강제합니다.
Helm 차트 (Kubernetes)

Helm 기반 배포의 경우 Gitaly 차트를 위한 서버 측 백업 설명서를 참조하십시오.

Linux 패키지 (Omnibus)

/etc/gitlab/gitlab.rb를 편집하고 go_cloud_url을 구성합니다: 

gitaly['env'] = {
    'AWS_ACCESS_KEY_ID' => 'minio_access_key_id',
    'AWS_SECRET_ACCESS_KEY' => 'minio_secret_access_key'
}
gitaly['configuration'] = {
    backup: {
        go_cloud_url: 's3://<bucket>?region=minio&endpoint=my.minio.local:8080&disableSSL=true&s3ForcePathStyle=true'
    }
}
직접 컴파일 (소스)

/home/git/gitaly/config.toml을 편집하고 go_cloud_url을 구성합니다: 

[backup]
go_cloud_url = "s3://<bucket>?region=minio&endpoint=my.minio.local:8080&disableSSL=true&s3ForcePathStyle=true"