참조 아키텍처: 최대 100 RPS 또는 5,000 사용자까지

Tier: Premium, Ultimate Offering: Self-Managed

이 페이지에서는 실제 데이터를 기반으로 최대 100 초당 요청(RPS)과 최대 5,000 사용자(매뉴얼 및 자동)에 대응하기 위해 설계된 GitLab 참조 아키텍처에 대해 설명합니다.

전체 참조 아키텍처 디렉터리은 다음을 참조하십시오 사용 가능한 참조 아키텍처.

note
이 아키텍처를 배포하기 전에 먼저 주요 문서를 읽는 것이 좋습니다. 특히 시작하기 전에 및 사용할 아키텍처 결정 섹션을 참조하십시오.
  • 대상 부하: API: 100 RPS, 웹: 10 RPS, Git(풀): 10 RPS, Git(푸시): 2 RPS
  • 고가용성: 예(현재 HA용 제 3자 PostgreSQL 솔루션이 필요합니다)
  • 예상 비용: 비용 표 참조
  • 클라우드 네이티브 하이브리드 대체 옵션: 예
  • 어떤 참조 아키텍처를 사용해야 하는지 확신이 안 들면? 더 많은 정보를 보려면 여기로 이동
서비스 노드 수 구성 GCP AWS Azure
외부 로드 밸런서3 1 4 vCPU, 3.6 GB 메모리 n1-highcpu-4 c5n.xlarge F4s v2
Redis2 3 2 vCPU, 7.5 GB 메모리 n1-standard-2 m5.large D2s v3
Consul1 + Sentinel2 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large F2s v2
PostgreSQL1 3 4 vCPU, 15 GB 메모리 n1-standard-4 m5.xlarge D4s v3
PgBouncer1 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large F2s v2
내부 로드 밸런서3 1 4 vCPU, 3.6 GB 메모리 n1-highcpu-4 c5n.xlarge F4s v2
Gitaly5 3 8 vCPU, 30 GB 메모리6 n1-standard-8 m5.2xlarge D8s v3
Praefect5 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large F2s v2
Praefect PostgreSQL1 1+ 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large F2s v2
Sidekiq7 2 4 vCPU, 15 GB 메모리 n1-standard-4 m5.xlarge D2s v3
GitLab Rails7 3 16 vCPU, 14.4 GB 메모리 n1-highcpu-16 c5.4xlarge F16s v2
모니터링 노드 1 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large F2s v2
객체 리포지터리4 - - - - -

각주:

  1. 신뢰할 수 있는 제 3자 외부 PaaS PostgreSQL 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 자체 PostgreSQL 인스턴스 제공를 참조하십시오.
  2. 신뢰할 수 있는 제 3자 외부 PaaS Redis 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 자체 Redis 인스턴스 제공를 참조하십시오.
  3. HA 기능을 제공할 수 있는 신뢰할 수 있는 제 3자 로드 밸런서 또는 서비스(LB PaaS)에서 실행하는 것이 좋습니다. 또한 크기 조정은 선택된 로드 밸런서 및 네트워크 대역폭과 같은 추가 요소에 따라 다를 수 있습니다. 자세한 내용은 로드 밸런서를 참조하십시오.
  4. 신뢰할 수 있는 클라우드 제공업체 또는 Self-Managed형 솔루션에서 실행하는 것이 좋습니다. 자세한 내용은 객체 리포지터리 구성를 참조하십시오.
  5. Gitaly 클러스터는 장애 허용성의 이점을 제공하지만 추가 설정 및 관리의 복잡성을 동반합니다. Gitaly 클러스터를 배포하기 전에 기존의 기술적 한계 및 고려 사항을 검토하십시오. 샤드로 분할된 Gitaly를 사용하려면Gitaly에 대해 위에서 나열한 동일한 사양을 사용하십시오.
  6. Gitaly 사양은 좋은 상태의 사용 패턴 및 리포지터리 크기의 높은 백분위수를 기반으로 합니다. 그러나 대형 단일 리포지터리(수 기가바이트보다 큰)나 추가 작업 부하가 있는 경우 Git 및 Gitaly 성능에 중대한 영향을 미칠 수 있으며 추가적인 조정이 필요할 수 있습니다.
  7. 컴포넌트가 상태 데이터를 저장하지 않기 때문에 Auto Scaling Group (ASG)에 배치할 수 있습니다. 그러나 클라우드 네이티브 하이브리드 설정이 일반적으로 선호됩니다. 특정 컴포넌트(예: 마이그레이션 및 Mailroom)는 한 노드에서만 실행할 수 있으며 Kubernetes에서 더 잘 처리됩니다.
note
인스턴스 구성을 포함하는 모든 PaaS 솔루션에 대해, 견고한 클라우드 아키텍처 관행과 일치하도록 세 가지 이용 가능한 영역에서 최소 세 개의 노드를 구현하는 것이 좋습니다.

요구 사항

시작하기 전에 참조 아키텍처의 요구 사항을 확인하세요.

테스트 방법론

5k 아키텍처는 대부분의 워크플로를 커버하는 것을 목표로 설계되었으며 정기적으로 Test Platform team에 의해 스모크 및 성능 테스트가 진행됩니다.

다음 엔드포인트 처리량 대상에 대해 테스트가 진행됩니다:

  • API: 100 RPS
  • Web: 10 RPS
  • Git (Pull): 10 RPS
  • Git (Push): 2 RPS

위의 대상은 사용자 수에 해당하는 총 환경 부하에 따라 선택되었으며, CI 및 기타 워크로드가 포함됩니다.

위 엔드포인트 대상에 대해 정기적으로 더 높은 처리량을 제안하는 메트릭이 있다면, 대형 모노 리포지터리 또는 주목할 만한 추가 워크로드가 환경에 주목할 만한 영향을 미칠 수 있으며, 추가 조정이 필요할 수 있습니다. 이 경우 해당 문서를 참조하고 고객 성공 관리자 또는 지원팀에 문의하는 것이 좋습니다.

테스팅은 정기적으로 GitLab Performance Tool (GPT) 및 해당 데이터셋을 사용하여 진행되며, 누구든 사용할 수 있습니다. 이 테스트 결과는 GPT 위키에서 공개적으로 제공되어 있습니다. 테스트 전략에 대한 자세한 정보는 이 섹션의 문서를 참조하세요.

테스트에 사용된 로드 밸런서는 Linux 패키지 환경에 대해 HAProxy를 사용하거나 클라우드 네이티브 하이브리드에 대해 해당 클라우드 제공 업체 서비스를 사용했습니다. 이러한 선택은 특정 요구 사항이나 권장 사항을 나타내는 것이 아니며, 대부분의 평판 있는 로드 밸런서가 작동할 것으로 예상됩니다.

컴포넌트 설정

GitLab 및 해당 컴포넌트를 설정하여 최대 100 RPS 또는 5,000 사용자를 수용하도록 설정하세요.

  1. 외부 로드 밸런서 구성
    • GitLab 응용 프로그램 서비스 노드의 로드 밸런싱을 처리하기 위해 구성하세요.
  2. 내부 로드 밸런서 구성
    • GitLab 응용 프로그램 내부 연결의 로드 밸런싱을 처리하기 위해 구성하세요.
  3. Redis 구성.
  4. Consul 및 Sentinel 구성.
  5. PostgreSQL 구성
    • GitLab의 데이터베이스입니다.
  6. PgBouncer 구성.
  7. Gitaly 클러스터 구성
    • Git 리포지터리에 대한 액세스를 제공합니다.
  8. Sidekiq 구성.
  9. 주요 GitLab Rails 애플리케이션의 구성
    • Puma, Workhorse, GitLab Shell을 실행하고 UI, API, Git over HTTP/SSH를 모두 제공합니다.
  10. Prometheus 구성
    • GitLab 환경을 모니터링합니다.
  11. 객체 리포지터리 구성
    • 공유 데이터 객체에 사용됩니다.
  12. 고급 검색 구성 (옵션)
    • 전체 GitLab 인스턴스를 대상으로 더 빠르고 고급 코드 검색을 위한 구성입니다.

서버는 동일한 10.6.0.0/24 사설 네트워크 범위에서 시작되며, 이들은 서로 자유롭게 다음 주소로 연결할 수 있습니다.

다음 디렉터리에는 각 서버와 해당 할당된 IP에 대한 설명이 포함됩니다:

  • 10.6.0.10: 외부 로드 밸런서
  • 10.6.0.11: Consul/Sentinel 1
  • 10.6.0.12: Consul/Sentinel 2
  • 10.6.0.13: Consul/Sentinel 3
  • 10.6.0.21: PostgreSQL 프라이머리
  • 10.6.0.22: PostgreSQL 세컨더리 1
  • 10.6.0.23: PostgreSQL 세컨더리 2
  • 10.6.0.31: PgBouncer 1
  • 10.6.0.32: PgBouncer 2
  • 10.6.0.33: PgBouncer 3
  • 10.6.0.20: 내부 로드 밸런서
  • 10.6.0.61: 레디스 프라이머리
  • 10.6.0.62: 레디스 레플리카 1
  • 10.6.0.63: 레디스 레플리카 2
  • 10.6.0.51: Gitaly 1
  • 10.6.0.52: Gitaly 2
  • 10.6.0.93: Gitaly 3
  • 10.6.0.131: Praefect 1
  • 10.6.0.132: Praefect 2
  • 10.6.0.133: Praefect 3
  • 10.6.0.141: Praefect PostgreSQL 1 (HA 아님)
  • 10.6.0.71: Sidekiq 1
  • 10.6.0.72: Sidekiq 2
  • 10.6.0.41: GitLab 응용 프로그램 1
  • 10.6.0.42: GitLab 응용 프로그램 2
  • 10.6.0.43: GitLab 응용 프로그램 3
  • 10.6.0.81: 프로메테우스

외부 로드 밸런서 구성

다중 노드 GitLab 구성에서 응용 프로그램 서버로의 트래픽을 라우팅하기 위해 외부 로드 밸런서가 필요합니다.

설정해야 할 로드 밸런서 또는 정확한 구성 사항에 대한 세부 정보는 GitLab 문서의 범위를 벗어나지만 로드 밸런서를 참조하여 일반적인 요구 사항에 대한 자세한 정보를 확인하세요. 이 섹션에서는 선택한 로드 밸런서의 구체적인 구성 사항에 중점을 두었습니다.

준비성 확인

외부 로드 밸런서가 모니터링 엔드포인트가 내장된 작동하는 서비스로만 라우팅되도록하고, 더 많은 구성이 필요합니다. 준비성 확인은 노드가 확인되는 중 추가 구성이 필요하며, 그렇지 않으면 외부 로드 밸런서가 연결할 수 없습니다.

포트

사용할 기본 포트는 아래 표에 표시되어 있습니다.

LB 포트 백엔드 포트 프로토콜
80 80 HTTP (1)
443 443 TCP or HTTPS (1) (2)
22 22 TCP
  • (1): Web terminal 지원은 로드 밸런서가 WebSocket 연결을 올바르게 처리해야합니다. HTTP 또는 HTTPS 프록시를 사용할 때 이는 로드 밸런서가 Connection 및 Upgrade hop-by-hop 헤더를 전달해야 함을 의미합니다. 자세한 내용은 웹 터미널 통합 가이드를 참조하세요.
  • (2): 포트 443에 HTTPS 프로토콜을 사용할 경우 로드 밸런서에 SSL 인증서를 추가해야 합니다. SSL을 GitLab 응용 프로그램 서버에서 종료하려면 TCP 프로토콜을 사용하세요.

사용자가 사용자 정의 도메인을 사용하는 GitLab Pages를 사용하는 경우 추가 포트 구성이 필요합니다. GitLab Pages는 별도의 가상 IP 주소가 필요합니다. DNS를 구성하여 /etc/gitlab/gitlab.rb의 pages_external_url을 새 가상 IP 주소로 지정하세요. 자세한 내용은 GitLab Pages 문서를 참조하세요.

LB 포트 백엔드 포트 프로토콜
80 다양함 (1) HTTP
443 다양함 (1) TCP (2)
  • (1): GitLab Pages의 백엔드 포트는 gitlab_pages['external_http'] 및 gitlab_pages['external_https'] 설정에 따라 다릅니다. 자세한 내용은 GitLab Pages 문서를 참조하세요.
  • (2): GitLab Pages의 포트 443은 항상 TCP 프로토콜을 사용해야 합니다. 사용자는 사용자 정의 SSL로 사용자 정의 도메인을 구성할 수 있으며, 로드 밸런서에서 SSL을 종료하면 불가능합니다.

대체 SSH 포트

일부 조직은 SSH 포트 22를 열지 않는 정책을 가지고 있습니다. 이 경우, 유저가 포트 443에서 SSH를 사용할 수 있도록 대체 SSH 호스트 이름을 구성하는 것이 도움이 될 수 있습니다. 대체 SSH 호스트 이름은 기존의 기타 GitLab HTTP 구성과는 다른 새로운 가상 IP 주소가 필요합니다.

altssh.gitlab.example.com과 같은 대체 SSH 호스트 이름을 위해 DNS를 구성하세요.

LB 포트 백엔드 포트 프로토콜
443 22 TCP

SSL

다음 질문은 환경에서 SSL을 어떻게 처리할 지입니다. 다양한 옵션이 있습니다:

애플리케이션 노드에서 SSL 종료

로드 밸런서를 구성하여 포트 443의 연결을 HTTP(S) 프로토콜이 아닌 TCP로 전달하세요. 이렇게 하면 연결이 애플리케이션 노드의 NGINX 서비스로 그대로 전달됩니다. NGINX는 SSL 인증서를 보유하고 포트 443에서 수신 대기할 것입니다.

SSL 인증서를 관리하고 NGINX를 구성하는 세부 정보는 HTTPS 문서를 참조하세요.

백엔드 SSL 없이 로드 밸런서에서 SSL 종료

로드 밸런서를 TCP 대신 HTTP(S) 프로토콜을 사용하도록 구성하세요. 로드 밸런서는 SSL 인증서를 관리하고 SSL을 종료할 책임이 있을 것입니다.

로드 밸런서와 GitLab 간의 통신이 안전하지 않기 때문에 추가 구성이 필요합니다. 세부 사항은 프록시 SSL 문서를 참조하세요.

백엔드 SSL에서 SSL 종료하는 로드 밸런서

로드 밸런서를 ‘TCP’ 대신 ‘HTTP(S)’ 프로토콜을 사용하도록 구성하세요. 로드 밸런서는 엔드 사용자가 볼 SSL 인증서를 관리할 것입니다.

이러한 시나리오에서 로드 밸런서와 NGINX 간의 트래픽도 안전합니다. 연결이 전체적으로 안전하기 때문에 프록시 SSL을 추가할 필요가 없습니다. 그러나 SSL 인증서를 구성하기 위해 GitLab에 구성을 추가해야 합니다. 세부 정보는 HTTPS 문서를 참조하세요.

내부 로드 밸런서 구성

다중 노드 GitLab 구성에서 선택된 내부 구성요소에 대한 트래픽을 라우팅하기 위해 내부 로드 밸런서가 필요합니다. 이 내용의 세부 정보는 GitLab 문서의 범위를 벗어나지만 일반적인 요구 사양에 대한 더 많은 정보는 로드 밸런서를 참조하세요. 이 섹션은 선택한 로드 밸런서의 구체적인 구성에 중점을 둡니다.

다음 IP가 예시로 사용됩니다:

  • 10.6.0.40: 내부 로드 밸런서

HAProxy를 사용하여 다음과 같이 수행할 수 있습니다: 

global
    log /dev/log local0
    log localhost local1 notice
    log stdout format raw local0

defaults
    log global
    default-server inter 10s fall 3 rise 2
    balance leastconn

frontend internal-pgbouncer-tcp-in
    bind *:6432
    mode tcp
    option tcplog
    
    default_backend pgbouncer

frontend internal-praefect-tcp-in
    bind *:2305
    mode tcp
    option tcplog
    option clitcpka
    
    default_backend praefect

backend pgbouncer
    mode tcp
    option tcp-check
    
    server pgbouncer1 10.6.0.31:6432 check
    server pgbouncer2 10.6.0.32:6432 check
    server pgbouncer3 10.6.0.33:6432 check

backend praefect
    mode tcp
    option tcp-check
    option srvtcpka
    
    server praefect1 10.6.0.131:2305 check
    server praefect2 10.6.0.132:2305 check
    server praefect3 10.6.0.133:2305 check

더 많은 지침은 선호하는 로드 밸런서의 문서를 참조하세요.

주요 Redis 인스턴스 구성

  1. 주요 Redis 서버에 SSH로 로그인합니다.
  2. 선택한 Linux 패키지를 다운로드하고 설치합니다. 페이지의 설치 단계 1과 2를 따라하기만 하고 현재 설치된 버전 및 유형(커뮤니티 또는 엔터프라이즈 버전)과 동일한 Linux 패키지를 선택해야 합니다.

  3. /etc/gitlab/gitlab.rb 파일을 수정하고 다음 내용을 추가합니다. 

    # 서버 역할을 'redis_master_role'로 지정하고 Consul 에이전트를 활성화합니다.
roles(['redis_master_role', 'consul_role'])
   
# 다른 머신에서 액세스할 수 있는 로컬 IP를 가리키는 IP 주소입니다.
# 모든 인터페이스에서 수신 대기하도록 '0.0.0.0'으로 바인딩할 수도 있습니다.
# 외부 접근 가능한 IP에 바인딩해야 하는 경우, 무단 액세스를 방지하기 위해 추가 방화벽 규칙을 추가해야 합니다.
redis['bind'] = '10.6.0.61'
   
# 다른 머신이 연결할 수 있도록 Redis가 TCP 요청을 수신할 포트를 정의합니다.
redis['port'] = 6379
   
# Redis에 대한 비밀번호 인증을 설정합니다(모든 노드에서 동일한 비밀번호 사용).
redis['password'] = '여기에-redis-비밀번호-입력'
   
## Prometheus를 위한 서비스 검색 활성화
consul['monitoring_service_discovery'] =  true
   
## Consul 서버 노드의 IP
## FQDN을 사용하거나 IP와 혼용할 수도 있습니다.
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
   
# 수출자가 수신 대기할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'
redis_exporter['flags'] = {
     'redis.addr' => 'redis://10.6.0.61:6379',
     'redis.password' => '여기에-redis-비밀번호-입력',
}
   
# 자동으로 업그레이드될 때 데이터베이스 마이그레이션을 방지
gitlab_rails['auto_migrate'] = false

  4. 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하고 해당 서버의 동일한 이름의 파일을 추가하거나 교체합니다. 만약 이게 처음 구성하는 Linux 패키지 노드라면 이 단계를 건너뛸 수 있습니다.

  5. 변경 사항이 적용되려면 GitLab을 재구성하십시오.

여러 역할을 지정할 수 있습니다. 예를 들어 roles(['redis_sentinel_role', 'redis_master_role'])처럼입니다. 역할에 대해 더 알아보세요.

아래의 명령어를 사용하여 현재 Redis Primary 및 Replica 상태를 확인할 수 있습니다. 

/opt/gitlab/embedded/bin/redis-cli -h <host> -a '여기에-redis-비밀번호-입력' info replication

그리고 실행 중인 GitLab 서비스를 확인하려면 다음 명령어를 사용합니다. 

gitlab-ctl status

결과는 다음과 유사해야 합니다. 

run: consul: (pid 30043) 76863s; run: log: (pid 29691) 76892s
run: logrotate: (pid 31152) 3070s; run: log: (pid 29595) 76908s
run: node-exporter: (pid 30064) 76862s; run: log: (pid 29624) 76904s
run: redis: (pid 30070) 76861s; run: log: (pid 29573) 76914s
run: redis-exporter: (pid 30075) 76861s; run: log: (pid 29674) 76896s

레플리카 Redis 인스턴스 구성

  1. 레플리카 Redis 서버에 SSH로 로그인합니다.
  2. 선택한 Linux 패키지를 다운로드하고 설치합니다. 페이지의 설치 단계 1과 2를 따라하기만 하고 현재 설치된 버전 및 유형(커뮤니티 또는 엔터프라이즈 버전)과 동일한 Linux 패키지를 선택해야 합니다.

  3. /etc/gitlab/gitlab.rb 파일을 수정하고 다음 내용을 추가합니다. 

    # 서버 역할을 'redis_replica_role'로 지정하고 Consul 에이전트를 활성화합니다.
roles(['redis_replica_role', 'consul_role'])
   
# 다른 머신에서 액세스할 수 있는 로컬 IP를 가리키는 IP 주소입니다.
# 모든 인터페이스에서 수신 대기하도록 '0.0.0.0'으로 바인딩할 수도 있습니다.
# 외부 접근 가능한 IP에 바인딩해야 하는 경우, 무단 액세스를 방지하기 위해 추가 방화벽 규칙을 추가해야 합니다.
redis['bind'] = '10.6.0.62'
   
# 다른 머신이 연결할 수 있도록 Redis가 TCP 요청을 수신할 포트를 정의합니다.
redis['port'] = 6379
   
# 기본 노드에 설정한 Redis 인증용 동일한 비밀번호입니다.
redis['password'] = '여기에-redis-비밀번호-입력'
   
# 기본 Redis 노드의 IP 주소
redis['master_ip'] = '10.6.0.61'
   
# 기본 Redis 서버의 포트, 기본값이 아닌 값으로 변경하려면 주석 해제합니다. 기본값은 `6379`입니다.
#redis['master_port'] = 6379
   
## Prometheus를 위한 서비스 검색 활성화
consul['monitoring_service_discovery'] =  true
   
## Consul 서버 노드의 IP
## FQDN을 사용하거나 IP와 혼용할 수도 있습니다.
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
   
# 수출자가 수신 대기할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'
redis_exporter['flags'] = {
     'redis.addr' => 'redis://10.6.0.62:6379',
     'redis.password' => '여기에-redis-비밀번호-입력',
}
   
# 자동으로 업그레이드될 때 데이터베이스 마이그레이션을 방지
gitlab_rails['auto_migrate'] = false
  4. 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하고 해당 서버의 동일한 이름의 파일을 추가하거나 교체합니다. 만약 이게 처음 구성하는 Linux 패키지 노드라면 이 단계를 건너뛸 수 있습니다.
  5. 변경 사항이 적용되려면 GitLab을 재구성하십시오.
  6. 다른 레플리카 노드에 대해 위 단계를 다시 진행하고 IP를 올바르게 설정했는지 확인하십시오.

roles(['redis_sentinel_role', 'redis_master_role'])처럼 센티넬과 Redis와 같이 여러 역할을 지정할 수 있습니다. 역할에 대해 자세히 알아보세요. 트위치: root_anchor 설정 구성으로 돌아가기

Consul 및 Sentinel 구성

Redis 서버가 모두 설정되었으므로 Consul 및 Sentinel 서버를 구성해 봅시다.

note
Consul 및 Redis Sentinel은 홀수 개의 3개 이상의 노드에 배포되어야 합니다. 이는 노드가 퀩럼의 일부로서 투표를 할 수 있도록 하기 위한 것입니다.

다음 IP가 예시로 사용될 것입니다:

  • 10.6.0.11: Consul/Sentinel 1
  • 10.6.0.12: Consul/Sentinel 2
  • 10.6.0.13: Consul/Sentinel 3
note
외부의 Redis Sentinel 인스턴스를 사용하는 경우 Sentinel 구성에서 requirepass 매개변수를 제외하는 것이 중요합니다. 이 매개변수는 클라이언트가 NOAUTH Authentication required.를 보고하는 것을 일으킵니다. Redis Sentinel 3.2.x는 패스워드 인증을 지원하지 않습니다.

Sentinel을 구성하려면:

  1. Consul/Sentinel을 호스팅하는 서버에 SSH로 로그인합니다.
  2. 선택한 리눅스 패키지를 다운로드 및 설치합니다. 페이지의 설치 단계 1과 2를 정확히 따르고, 현재 설치된 것과 동일한 버전 및 유형(커뮤니티 또는 엔터프라이즈 버전)의 올바른 리눅스 패키지를 선택해야 합니다.

  3. /etc/gitlab/gitlab.rb 파일을 편집하고 아래 내용을 추가합니다: 

    roles(['redis_sentinel_role', 'consul_role'])
   
# 모든 센티널 노드에서 동일해야 합니다
redis['master_name'] = 'gitlab-redis'
   
# 주 노드를 위해 설정한 Redis 인증용 동일한 비밀번호
redis['master_password'] = '여기에 레디스 비밀번호 입력'
   
# 주요 Redis 노드의 IP
redis['master_ip'] = '10.6.0.61'
   
# 다른 기기가 연결할 수 있도록 Redis가 TCP 요청을 수신할 수 있도록 포트 정의
redis['port'] = 6379
   
# 기본값과 다른 포트로 변경하려면 주요 Redis 서버의 포트를 지정 해제하세요. 
#redis['master_port'] = 6379
   
## Sentinel 구성
sentinel['bind'] = '10.6.0.11'
   
# 센티넬이 수신 대기하는 포트입니다. 기본값으로 변경하려면 주석을 해제하세요. 기본값은 `26379`
# sentinel['port'] = 26379
   
## 퀩럼은 장애 조치를 시작하는 데 필요한 투표 센티넬의 수를 반영해야 합니다.
## 값은 센티넬의 수보다 크지 않아야 합니다.
##
## 퀩럼은 Sentinel을 두 가지 방법으로 조정하는 데 사용할 수 있습니다 :
## 1. 적은 수의 센티넬로 투표할 수 있도록 퀩럼값을 전체 센티넬의 과반보다 작은 값으로 설정하면,
##    기본 장애에 대해 Sentinel을 보다 민감하게 만들 수 있습니다.
## 1. 퍼져있는 Sentinels의 대다수보다 큰 값으로 퀩럼을 설정하면, 자신과 동의하는 매우 많은 수의
##    센티넬이 있을 때에만 Sentinel이 장애 조치를 수행할 수 있도록 만들 수 있습니다.
sentinel['quorum'] = 2
   
## 지정한 시간(ms) 이상 응답하지 않는 서버를 다운으로 간주합니다.
# sentinel['down_after_milliseconds'] = 10000
   
## 밀리 초 단위로 지정된 장애 조치 타임아웃입니다. 이 값은 다양한 방법으로 사용됩니다 :
##
## - 이전 장애 조치 후에 동일한 주요에 대해 동일한 센티넬에 의해 시도된 재시작에 필요한
##   시간은 장애 조치 타임아웃의 두 배입니다.
##
## - 현재 구성에 따라 잘못된 주요에 복제 중인 복제본이 올바른 주요와 복제 되도록
##   강제되기까지 걸리는 시간은 정확히 장애 조치 타임아웃입니다 (센티넬이 잘못된 설정을 감지한 후부터 계산).
##
## - 이미 진행 중인 장애 조치를 취소하는 데 필요한 시간(아직 PROMOTE된 복제본에게 REPLICAOF NO ONE
##   그리고 출연된 복제본에게 인증되지 않은 경우).
##
## - 실패중인 모든 복제본을 기다리는 최대 시간, 그러나 실제 복제본은 여전히 센티넬에 의해 재구성됩니다.
##   하지만 원하는 첨부 복제본의 진행과 동일항 동기화가 진행되지 않습니다.
# sentinel['failover_timeout'] = 60000
   
## 프로메테우스를 위한 서비스 검색 활성화
consul['monitoring_service_discovery'] =  true
   
## Consul 서버 노드의 IP
## FQDN을 사용할 수 있으며 IP와 혼합하여 사용할 수 있습니다
consul['configuration'] = {
   server: true,
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
   
# 익스포터가 수신 대기할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'
   
# 업그레이드 시 자동으로 데이터베이스 마이그레이션을 방지
gitlab_rails['auto_migrate'] = false

  4. 이미 구성한 첫 번째 리눅스 패키지 노드의 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 동일한 파일에 추가하거나 교체합니다. 이것이 구성하는 첫 번째 리눅스 패키지 노드인 경우, 이 단계는 생략할 수 있습니다.

  5. 변경 내용이 적용되도록 GitLab 재구성합니다.
  6. 다른 Consul/Sentinel 노드에 대해서도 위 단계를 다시 실행하여 올바른 IP를 설정하는지 확인합니다.

Consul 서버의 프로비저닝이 완료되면 Consul 로그를 보면 Consul 리더가 _선출_됩니다. sudo gitlab-ctl tail consul 명령을 사용하여 Consul 멤버(서버, 클라이언트)를 확인할 수 있습니다. 

sudo /opt/gitlab/embedded/bin/consul members

또한 GitLab 서비스가 실행 중인지 확인할 수 있습니다. 

sudo gitlab-ctl status

다음과 유사한 출력이어야 합니다. 

run: consul: (pid 30074) 76834s; run: log: (pid 29740) 76844s
run: logrotate: (pid 30925) 3041s; run: log: (pid 29649) 76861s
run: node-exporter: (pid 30093) 76833s; run: log: (pid 29663) 76855s
run: sentinel: (pid 30098) 76832s; run: log: (pid 29704) 76850s

PostgreSQL 구성

이 섹션에서는 GitLab과 함께 사용할 고가용성 PostgreSQL 클러스터를 구성하는 방법을 안내합니다.

독자의 PostgreSQL 인스턴스 제공

PostgreSQL을 위해 서드파티 외부 서비스를 선택하여 선택할 수도 있습니다.

이를 위해서 신뢰할 수 있는 제공업체나 솔루션을 사용해야 합니다. Google Cloud SQL 및 Amazon RDS가 작동한다는 것이 알려져 있지만, Amazon Aurora는 14.4.0 이후 기본으로 활성화된 로드 밸런싱과 호환되지 않습니다. 자세한 정보는 권장 클라우드 제공업체 및 서비스를 참조하십시오.

서드파티 외부 서비스를 사용하는 경우:

  1. HA Linux 패키지 PostgreSQL 설치에는 PostgreSQL, PgBouncer 및 Consul이 모두 더 이상 필요하지 않을 수도 있음을 유의하십시오.
  2. 데이터베이스 요구 사항 문서에 따라 PostgreSQL을 설정합니다.
  3. 선택한 패스워드로 gitlab 사용자를 설정합니다. gitlab 사용자는 gitlabhq_production 데이터베이스를 만들기 위한 권한이 있어야 합니다.
  4. GitLab 응용 서버에서 적절한 세부 정보를 구성합니다. 이 단계는 GitLab Rails 응용 프로그램 구성에서 다루고 있습니다.
  5. 외부 서비스에 필요한 노드 수는 리눅스 패키지와 비교하여 달라질 수 있으며, 이에 따라 일치시킬 필요가 없습니다.
  6. 그러나 추가적인 성능 향상을 위해 Read Replicas를 통한 데이터베이스 로드 밸런싱이 원하는 경우, 참조 아키텍처에 대한 노드 카운트를 따르는 것이 권장됩니다.

독립형 PostgreSQL과 Linux 패키지 사용

추천되는 Linux 패키지 구성에는 PostgreSQL 클러스터에 대한 복제 및 장애 조치가 필요합니다.

  • 최소 세 개의 PostgreSQL 노드가 필요합니다.
  • 최소 세 개의 Consul 서버 노드가 필요합니다.
  • 기본 데이터베이스 읽기 및 쓰기를 처리 및 추적하는 최소 세 개의 PgBouncer 노드가 필요합니다.
    • PgBouncer 노드 간의 요청을 균형있게 처리하기 위한 내부 로드 밸런서(TCP)가 필요합니다.

  • 데이터베이스 로드 밸런싱을 활성화합니다.

    각 PostgreSQL 노드에 로컬 PgBouncer 서비스를 구성해야 합니다. 이는 기본적으로 주요 서비스를 추적하는 별도의 PgBouncer 클러스터와 분리됩니다.

다음과 같이 IP 주소를 예시로 사용합니다.

  • 10.6.0.21: PostgreSQL 기본
  • 10.6.0.22: PostgreSQL 보조 1
  • 10.6.0.23: PostgreSQL 보조 2

먼저, 각 노드에 Linux GitLab 패키지를 설치하십시오. 그 다음 단계에서는 설치 과정을 따라 필요한 의존성을 설치하고, 두 번째 단계에서는 GitLab 패키지 리포지터리를 추가하십시오. 두 번째 단계에서는 EXTERNAL_URL 값을 제공하지 마십시오.

PostgreSQL 노드

  1. PostgreSQL 노드 중 하나에 SSH로 접속합니다.

  2. PostgreSQL 사용자명/암호 쌍에 대한 암호 해시를 생성합니다. 이는 기본 사용자명이 gitlab (권장)인 것으로 가정합니다. 이 명령은 암호와 확인을 요청합니다. 이 명령의 출력 값을 다음 단계에서 <postgresql_password_hash> 값으로 사용하세요: 

    sudo gitlab-ctl pg-password-md5 gitlab

  3. PgBouncer 사용자명/암호 쌍에 대한 암호 해시를 생성합니다. 이는 기본 사용자명이 pgbouncer (권장)인 것으로 가정합니다. 이 명령은 암호와 확인을 요청합니다. 이 명령의 출력 값을 다음 단계에서 <pgbouncer_password_hash> 값으로 사용하세요: 

    sudo gitlab-ctl pg-password-md5 pgbouncer

  4. PostgreSQL 복제 사용자명/암호 쌍에 대한 암호 해시를 생성합니다. 이는 기본 사용자명이 gitlab_replicator (권장)인 것으로 가정합니다. 이 명령은 암호와 확인을 요청합니다. 이 명령의 출력 값을 다음 단계에서 <postgresql_replication_password_hash> 값으로 사용하세요: 

    sudo gitlab-ctl pg-password-md5 gitlab_replicator

  5. Consul 데이터베이스 사용자명/암호 쌍에 대한 암호 해시를 생성합니다. 이는 기본 사용자명이 gitlab-consul (권장)인 것으로 가정합니다. 이 명령은 암호와 확인을 요청합니다. 이 명령의 출력 값을 다음 단계에서 <consul_password_hash> 값으로 사용하세요: 

    sudo gitlab-ctl pg-password-md5 gitlab-consul

  6. 모든 데이터베이스 노드에서 /etc/gitlab/gitlab.rb를 편집하여 # START user configuration 섹션에 주석 처리된 값을 대체합니다: 

    # Patroni, PgBouncer 및 Consul 이외의 모든 컴포넌트 비활성화
roles(['patroni_role', 'pgbouncer_role'])
   
# PostgreSQL 구성
postgresql['listen_address'] = '0.0.0.0'
   
# `max_replication_slots`을 데이터베이스 노드의 두 배로 설정합니다.
# Patroni는 복제를 시작할 때 노드 당 하나의 추가 슬롯을 사용합니다.
patroni['postgresql']['max_replication_slots'] = 6
   
# `max_wal_senders`를 클러스터의 복제 슬롯 수에 1을 더하여 설정합니다.
# 이는 복제가 모든 사용 가능한 데이터베이스 연결을 사용하도록 하는 것을 방지하는 데 사용됩니다.
patroni['postgresql']['max_wal_senders'] = 7
   
# 업그레이드 시 자동으로 데이터베이스 마이그레이션을 실행하지 않도록 설정합니다.
gitlab_rails['auto_migrate'] = false
   
# Consul 에이전트 구성
consul['services'] = %w(postgresql)
## Prometheus를 위한 서비스 검색 활성화
consul['monitoring_service_discovery'] =  true
   
# START user configuration
# 필요한 정보 섹션에 설명된 대로 실제 값을 설정하세요
#
# 생성된 md5 값을 사용하여 PGBOUNCER_PASSWORD_HASH를 대체하세요
postgresql['pgbouncer_user_password'] = '<pgbouncer_password_hash>'
# 생성된 md5 값을 사용하여 POSTGRESQL_REPLICATION_PASSWORD_HASH를 대체하세요
postgresql['sql_replication_password'] = '<postgresql_replication_password_hash>'
# 생성된 md5 값을 사용하여 POSTGRESQL_PASSWORD_HASH를 대체하세요
postgresql['sql_user_password'] = '<postgresql_password_hash>'
   
# Patroni API를 위해 기본 인증 설정 (모든 노드에서 동일한 사용자명/암호 사용)
patroni['username'] = '<patroni_api_username>'
patroni['password'] = '<patroni_api_password>'
   
# 네트워크 주소를 설정하여 Exporter가 모니터링을 수신할 수 있도록 합니다
node_exporter['listen_address'] = '0.0.0.0:9100'
postgres_exporter['listen_address'] = '0.0.0.0:9187'
   
## Consul 서버 노드의 IP
## FQDN을 사용하거나 IP와 섞어서 사용할 수도 있습니다
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
#
# END user configuration

PostgreSQL은 failover를 관리하는 Patroni를 사용하여 데이터 충돌을 처리하기 위해 기본적으로 pg_rewind를 사용합니다. 대부분의 장애 조치 처리 방법과 마찬가지로 이는 데이터 손실 가능성이 매우 낮습니다. 자세한 내용은 Patroni 복제 방법을 참조하세요.

  1. 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 동일한 이름의 파일을 추가하거나 대체하십시오. 이것이 구성하는 첫 번째 Linux 패키지 노드인 경우, 이 단계를 건너 뛰어도 됩니다.

  2. 변경 사항이 적용되도록 GitLab 재구성하십시오.

필요한 경우, 고급 구성 옵션을 지원하며 추가할 수 있습니다.

PostgreSQL 후 설정

주 서버의 Patroni 노드 중 하나에 SSH로 접속합니다:

  1. 리더 및 클러스터 상태를 확인합니다: 

    gitlab-ctl patroni members

    출력은 다음과 유사해야 합니다: 

    | Cluster       | Member                            |  Host     | Role   | State   | TL  | Lag in MB | Pending restart |
|---------------|-----------------------------------|-----------|--------|---------|-----|-----------|-----------------|
| postgresql-ha | <PostgreSQL primary hostname>     | 10.6.0.21 | Leader | running | 175 |           | *               |
| postgresql-ha | <PostgreSQL secondary 1 hostname> | 10.6.0.22 |        | running | 175 | 0         | *               |
| postgresql-ha | <PostgreSQL secondary 2 hostname> | 10.6.0.23 |        | running | 175 | 0         | *               |

‘상태’ 열이 “running”이 아닌 경우, 계속 진행하기 전에 PostgreSQL 복제 및 장애 조치 문제 해결 섹션을 확인하십시오.

PgBouncer 구성

이제 PostgreSQL 서버가 모두 설정되었으므로, 주 데이터베이스에 대한 읽기/쓰기를 추적하고 처리하기 위해 PgBouncer를 구성해 봅시다.

note
PgBouncer는 단일 스레드이며 CPU 코어가 증가해도 큰 이점을 얻지 못합니다. 자세한 내용은 스케일링 문서를 참조하십시오.

다음 IP 주소는 예시로 사용됩니다:

  • 10.6.0.31: PgBouncer 1
  • 10.6.0.32: PgBouncer 2
  • 10.6.0.33: PgBouncer 3

  1. 각 PgBouncer 노드에서 /etc/gitlab/gitlab.rb 파일을 편집하고, 이전에 설정한 패스워드 해시로 <consul_password_hash>와 <pgbouncer_password_hash>를 대체합니다: 

    # Pgbouncer 및 Consul 에이전트 외의 모든 컴포넌트를 비활성화합니다
roles(['pgbouncer_role'])
   
# PgBouncer 구성
pgbouncer['admin_users'] = %w(pgbouncer gitlab-consul)
pgbouncer['users'] = {
   'gitlab-consul': {
      password: '<consul_password_hash>'
   },
   'pgbouncer': {
      password: '<pgbouncer_password_hash>'
   }
}
   
# Consul 에이전트 구성
consul['watchers'] = %w(postgresql)
consul['configuration'] = {
retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}
   
# Prometheus를 위한 서비스 검색 활성화
consul['monitoring_service_discovery'] = true
   
# 익스포터가 청취할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
pgbouncer_exporter['listen_address'] = '0.0.0.0:9188'

  2. 첫 번째 리눅스 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 동일한 이름의 파일을 추가하거나 교체합니다. 이것이 구성하는 첫 번째 리눅스 패키지 노드인 경우에는 이 단계를 건너뛸 수 있습니다.

  3. 변경 사항이 적용되려면 GitLab을 다시 구성하십시오.

  4. Consul이 PgBouncer를 다시 로드할 수 있도록 .pgpass 파일을 생성합니다. 두 번째로 PgBouncer 패스워드를 입력하십시오: 

    gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul

  5. 각 노드가 현재 마스터와 통신하도록 확인하십시오: 

    gitlab-ctl pgb-console # PGBOUNCER_PASSWORD를 묻습니다

    패스워드를 입력한 후 psql: ERROR: Auth failed 오류가 발생하면, 이전에 올바른 형식으로 MD5 패스워드 해시를 생성했는지 확인하십시오. 올바른 형식은 패스워드와 사용자 이름을 연결하는 것입니다: PASSWORDUSERNAME. 예를들어, Sup3rS3cr3tpgbouncer는 pgbouncer 사용자를 위해 MD5 패스워드 해시를 생성하기 위해 필요한 텍스트입니다.

  6. 콘솔 프롬프트가 나타나면, 다음 쿼리를 실행하십시오: 

    show databases ; show clients ;

    출력은 다음과 유사해야 합니다: 

            name         |  host       | port |      database       | force_user | pool_size | reserve_pool | pool_mode | max_connections | current_connections
---------------------+-------------+------+---------------------+------------+-----------+--------------+-----------+-----------------+---------------------
 gitlabhq_production | MASTER_HOST | 5432 | gitlabhq_production |            |        20 |            0 |           |               0 |                   0
 pgbouncer           |             | 6432 | pgbouncer           | pgbouncer  |         2 |            0 | statement |               0 |                   0
(2 rows)
    
 type |   user    |      database       |  state  |   addr         | port  | local_addr | local_port |    connect_time     |    request_time     |    ptr    | link | remote_pid | tls
------+-----------+---------------------+---------+----------------+-------+------------+------------+---------------------+---------------------+-----------+------+------------+-----
 C    | pgbouncer | pgbouncer           | active  | 127.0.0.1      | 56846 | 127.0.0.1  |       6432 | 2017-08-21 18:09:59 | 2017-08-21 18:10:48 | 0x22b3880 |      |          0 |
(2 rows)

  7. GitLab 서비스가 실행 중인지 확인하십시오: 

    sudo gitlab-ctl status

    출력은 다음과 유사해야 합니다: 

    run: consul: (pid 31530) 77150s; run: log: (pid 31106) 77182s
run: logrotate: (pid 32613) 3357s; run: log: (pid 30107) 77500s
run: node-exporter: (pid 31550) 77149s; run: log: (pid 30138) 77493s
run: pgbouncer: (pid 32033) 75593s; run: log: (pid 31117) 77175s
run: pgbouncer-exporter: (pid 31558) 77148s; run: log: (pid 31498) 77156s

Gitaly 클러스터 구성

Gitaly 클러스터는 GitLab에서 제공하고 권장하는 장애 허용 솔루션으로, Git 리포지터리를 저장하기 위한 것입니다. 이 구성에서는 모든 Git 리포지터리가 클러스터의 모든 Gitaly 노드에 저장되며, 하나는 주 노드로 지정되며, 주 노드가 다운되면 자동 장애 조치가 발생합니다.

caution
Gitaly 사양은 건강한 패턴 및 리포지터리 크기의 높은 백분위수를 기반으로 합니다. 그러나 큰 모노리포(여러 기가바이트 이상의 크기)나 추가적인 작업 부하가 있는 경우, 이 환경의 성능에 상당한 영향을 미칠 수 있으며, 추가 조정이 필요할 수 있습니다. 이 경우, 링크된 문서를 참조하거나 고객 성공 담당자나 지원 팀에 문의하는 것이 강력히 권장됩니다.

Gitaly 클러스터는 장애 허용의 이점을 제공하지만, 추가적인 설정 및 관리 복잡성을 동반하고 있습니다. Gitaly 클러스터를 배포하기 전에 기술적 한계 사항과 고려 사항을 검토하십시오.

다음과 같은 컴포넌트를 추천하는 클러스터 설정을 포함합니다:

  • 3개의 Gitaly 노드: Git 리포지터리의 복제된 리포지터리.
  • 3개의 Praefect 노드: Gitaly 클러스터의 라우터 및 트랜잭션 관리자.
  • 1개의 Praefect PostgreSQL 노드: Praefect용 데이터베이스 서버. Praefect 데이터베이스 연결을 고가용성으로 유지하려면 타사 솔루션이 필요합니다.
  • 1개의 로드 밸런서: Praefect용 로드 밸런서가 필요합니다. 내부 로드 밸런서가 사용됩니다.

본 섹션에서는 추천되는 표준 설정을 순서대로 구성하는 방법에 대해 자세히 설명합니다. 더 고급적인 설정에 대해서는 독립된 Gitaly 클러스터 문서를 참조하십시오.

Praefect PostgreSQL 구성

Praefect는 Gitaly 클러스터의 라우팅 및 트랜잭션 관리자로, Gitaly 클러스터 상태에 대한 데이터를 저장하기 위한 고유한 데이터베이스 서버를 필요로 합니다.

고가용성(Highly Available) 구성을 원하는 경우, Praefect는 제3자 PostgreSQL 데이터베이스가 필요합니다. 내장 솔루션이 작업 중입니다.

Praefect HA PostgreSQL Linux 패키지 단독으로 사용

다음의 IP 주소는 예시로 사용됩니다:

  • 10.6.0.141: Praefect PostgreSQL

먼저, Praefect PostgreSQL 노드에 리눅스 GitLab 패키지를 설치 합니다. 단계를 따라 진행하여, 1단계에서 필요한 의존성을 설치하고, 2단계에서 GitLab 패키지 리포지터리를 추가합니다. 두 번째 단계에서 GitLab을 설치할 때 EXTERNAL_URL 값은 제공하지 않도록 합니다.

  1. Praefect PostgreSQL 노드로 SSH를 실행합니다.
  2. Praefect PostgreSQL 사용자에게 사용할 강력한 비밀번호를 생성합니다. 이 비밀번호를 <praefect_postgresql_password>로서 기록해 둡니다.

  3. Praefect PostgreSQL 사용자/비밀번호 쌍에 대한 비밀번호 해시를 생성합니다. 이 명령은 기본 사용자 praefect (권장)를 사용한다고 가정합니다. 명령은 비밀번호 <praefect_postgresql_password> 및 확인을 요청합니다. 이 명령에서 출력된 값을 다음 단계에서 <praefect_postgresql_password_hash>의 값으로 사용합니다: 

    sudo gitlab-ctl pg-password-md5 praefect

  4. /etc/gitlab/gitlab.rb 파일을 편집하여 # START user configuration 섹션에 나열된 값들을 바꿉니다: 

    # PostgreSQL 및 Consul 이외의 모든 컴포넌트를 비활성화합니다
roles(['postgres_role', 'consul_role'])
   
# PostgreSQL 구성
postgresql['listen_address'] = '0.0.0.0'
   
# 업그레이드시 데이터베이스 마이그레이션을 자동으로 실행하지 않도록 합니다
gitlab_rails['auto_migrate'] = false
   
# Consul 에이전트 구성
## Prometheus를 위한 서비스 검색 활성화
consul['monitoring_service_discovery'] =  true
   
# START user configuration
# 필요한 정보 섹션에 설명된대로 실제 값을 설정해주세요
#
# 생성된 md5 값을 가진 PRAEFECT_POSTGRESQL_PASSWORD_HASH로 대체
postgresql['sql_user_password'] = "<praefect_postgresql_password_hash>"
   
# 네트워크 주소로 XXX.XXX.XXX.XXX/YY 대체
postgresql['trust_auth_cidr_addresses'] = %w(10.6.0.0/24 127.0.0.1/32)
   
# 모니터링을 위해 익스포터가 수신 대기할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
postgres_exporter['listen_address'] = '0.0.0.0:9187'
   
## Consul 서버 노드의 IP
## FQDN을 사용하거나 IP와 혼용할 수 있습니다
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
#
# END user configuration

  5. 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 동일한 이름의 파일을 추가하거나 교체합니다. 이것이 첫 번째 Linux 패키지 노드 설정이라면 이 단계는 건너뛸 수 있습니다.

  6. 변경 사항이 적용되도록 GitLab 재구성합니다.

  7. 후 구성을 진행합니다.

Praefect HA PostgreSQL 제3자 솔루션

Praefect PostgreSQL 구성에서 언급했듯이, 완전한 고가용성을 원한다면 Praefect의 데이터베이스에 대한 제3자 PostgreSQL 솔루션이 권장됩니다.

PostgreSQL HA를 위한 다양한 제3자 솔루션이 있습니다. 사용할 解 선택은 Praefect와 함께 작동해야 합니다:

  • 장애 조치(failover)에 따라 변경되지 않는 모든 연결을 위해 고정 IP가 필요합니다.
  • LISTEN SQL 기능을 지원해야 합니다.
note
제3자 설정에서 편리성을 위해 Praefect의 데이터베이스를 기본 GitLab 데이터베이스와 같은 서버에 함께 배치할 수 있습니다. 별도의 데이터베이스 인스턴스가 필요한 지리(Geo)를 사용하지 않는 이상에야 메인 데이터베이스 설정 사양을 변경할 필요가 없습니다.

이 설정에서는 신뢰할 수 있는 제공업체나 솔루션을 사용해야 합니다. Google Cloud SQL 및 Amazon RDS가 작동하는 것으로 알려져 있습니다. 그러나 Amazon Aurora는 14.4.0에서 기본적으로 활성화된 로드 밸런싱과 호환되지 않습니다. 자세한 내용은 권장 클라우드 제공 업체 및 서비스를 확인하세요.

데이터베이스가 설정되면 후 구성을 따릅니다.

Praefect PostgreSQL 후 구성

Praefect PostgreSQL 서버를 설정한 후에, Praefect가 사용할 사용자 및 데이터베이스를 구성해야 합니다.

사용자의 이름을 praefect, 데이터베이스의 이름을 praefect_production으로 지정하는 것이 좋습니다. 이들은 PostgreSQL에서 표준으로 구성할 수 있습니다. 사용자의 암호는 앞서 <praefect_postgresql_password>로 구성한 것과 동일합니다.

이것은 리눅스 패키지의 PostgreSQL 설정과 함께 작동하는 방식입니다:

  1. Praefect PostgreSQL 노드에서 SSH로 실행합니다.

  2. PostgreSQL 서버에 관리 액세스로 연결합니다. 기본적으로 리눅스 패키지에는 추가되는 gitlab-psql 사용자를 여기서 사용해야 합니다. 데이터베이스 template1은 모든 PostgreSQL 서버에 기본적으로 생성되기 때문에 여기서 사용합니다. 

    /opt/gitlab/embedded/bin/psql -U gitlab-psql -d template1 -h POSTGRESQL_SERVER_ADDRESS

  3. <praefect_postgresql_password>를 대체하여 새 사용자 praefect를 생성합니다: 

    CREATE ROLE praefect WITH LOGIN CREATEDB PASSWORD '<praefect_postgresql_password>';

  4. 이번엔 praefect 사용자로 PostgreSQL 서버에 다시 연결합니다: 

    /opt/gitlab/embedded/bin/psql -U praefect -d template1 -h POSTGRESQL_SERVER_ADDRESS

  5. praefect_production이라는 새 데이터베이스를 생성합니다: 

    CREATE DATABASE praefect_production WITH ENCODING=UTF8;

Praefect 구성

Praefect는 Gitaly 클러스터의 라우터 및 트랜잭션 관리자이며, Gitaly에 대한 모든 연결은 그를 통해 이루어집니다. 이 섹션은 Praefect의 구성 방법에 대해 자세히 설명합니다.

note
Praefect는 반드시 홀수 개의 3개 이상의 노드에 배포되어야 합니다. 이는 노드가 꺾어짐(quorum)의 일부로 투표를 할 수 있도록 보장하기 위함입니다.

Praefect는 클러스터 전체의 통신을 보호할 수 있는 여러 비밀 토큰이 필요합니다:

  • <praefect_external_token>: Gitaly 클러스터에 호스팅되는 리포지터리에 사용되며 이 토큰을 가진 Gitaly 클라이언트만 접근할 수 있습니다.
  • <praefect_internal_token>: Gitaly 클러스터 내부의 복제 트래픽에 사용됩니다. 이는 praefect_external_token과는 다릅니다. 외부 클라이언트가 Praefect 클러스터의 내부 노드에 직접 접근해서는 안 됩니다. 그렇게 되면 데이터 손실이 발생할 수 있기 때문입니다.
  • <praefect_postgresql_password>: 앞서 이전 섹션에서 정의한 Praefect PostgreSQL 비밀번호도 이 설정에 필요합니다.

Gitaly 클러스터 노드는 가상 리포지터리를 통해 Praefect에서 구성됩니다. 각 리포지터리는 클러스터를 이루는 각 Gitaly 노드의 세부 정보를 포함합니다. 또한 각 리포지터리에는 이름이 지정되며, 이 이름은 구성의 여러 영역에서 사용됩니다. 이 가이드에서는 리포지터리의 이름을 default로 정하고 있습니다. 또한 이 가이드는 새로운 설치를 기준으로 하며, 기존 환경을 Gitaly 클러스터를 사용하도록 업그레이드하는 경우 다른 이름을 사용해야 할 수 있습니다. 자세한 내용은 Praefect documentation를 참조하세요.

다음과 같은 IP 주소가 예시로 사용됩니다:

  • 10.6.0.131: Praefect 1
  • 10.6.0.132: Praefect 2
  • 10.6.0.133: Praefect 3

Praefect 노드를 구성하려면 각 노드에서 다음을 수행합니다:

  1. Praefect 서버로 SSH를 실행합니다.
  2. 선택한 리눅스 패키지를 다운로드하고 설치합니다. 페이지에서 설치 단계 1과 2만을 따르도록 합니다.

  3. Praefect를 구성하려면 /etc/gitlab/gitlab.rb 파일을 편집합니다:

    note
    GitLab에 이것이 필요합니다로 인해 virtual_storages에서 default 항목을 삭제할 수 없습니다.

    ```ruby # Praefect 서버에서 불필요한 서비스를 실행하지 않도록합니다 gitaly[‘enable’] = false postgresql[‘enable’] = false redis[‘enable’] = false nginx[‘enable’] = false puma[‘enable’] = false sidekiq[‘enable’] = false gitlab_workhorse[‘enable’] = false prometheus[‘enable’] = false alertmanager[‘enable’] = false gitlab_exporter[‘enable’] = false gitlab_kas[‘enable’] = false

    Praefect 설정

    praefect[‘enable’] = true

    업그레이드시 데이터베이스 마이그레이션을 자동으로 실행하지 않도록합니다

    praefect[‘auto_migrate’] = false gitlab_rails[‘auto_migrate’] = false

    Consul 에이전트 구성

    consul[‘enable’] = true ## Prometheus를 위한 서비스 검색 활성화 consul[‘monitoring_service_discovery’] = true

    START user configuration

    필요한 정보 섹션에 설명된대로 실제 값을 설정해주세요

    #

    praefect[‘configuration’] = { # … listen_addr: ‘0.0.0.0:2305’, auth: { # … # # Praefect 외부 토큰 # 이것은 클러스터 외부 (GitLab Shell과 같은) 클라이언트가 Praefect 클러스터와 통신하기 위해 필요합니다. token: ‘', }, # Praefect 데이터베이스 설정 database: { # ... host: '10.6.0.141', port: 5432, # 캐싱을 위한 `no_proxy` 설정은 항상 직접 연결이어야합니다 session_pooled: { # ... host: '10.6.0.141', port: 5432, dbname: 'praefect_production', user: 'praefect', password: '', }, }, # Praefect 가상 스토리지 구성 # 리포지터리 이름 해시는 GitLab의 git_data_dirs에서의 리포지터리 이름 ('praefect') 및 Gitaly 노드('gitaly-1')에서의 gitaly['configuration'][:storage]와 일치해야합니다. virtual_storage: [ { # ... name: 'default', node: [ { storage: 'gitaly-1', address: 'tcp://10.6.0.91:8075', token: '' }, { storage: 'gitaly-2', address: 'tcp://10.6.0.92:8075', token: '' }, { storage: 'gitaly-3', address: 'tcp://10.6.0.93:8075', token: '' }, ], }, ], # 모니터링을 위해 Praefect가 수신 대기할 네트워크 주소 설정 prometheus_listen_addr: '0.0.0.0:9652', }

    모니터링을 위해 노드 익스포터가 수신 대기할 네트워크 주소 설정

    node_exporter[‘listen_address’] = ‘0.0.0.0:9100’

    Cons

Gitaly 구성

클러스터를 구성하는 Gitaly 서버 노드는 데이터 및 부하에 따라 종속되는 요구 사항을 가지고 있습니다.

caution
Gitaly 사양은 사용량 패턴 및 리포지터리 크기의 높은 백분위수에 기반합니다. 하지만, 대형 모노리포(여러 기가바이트보다 큰)나 추가 워크로드가 있는 경우, 환경의 성능에 중대한 영향을 미칠 수 있으며 추가 조정이 필요할 수 있습니다. 해당 사항이 해당되는 경우, 가이드를 위해 연결된 설명서를 참조하거나 추가 지침을 위해 고객 성공 담당자나 지원팀에 문의하는 것을 강력히 권장합니다.

Gitaly의 주목할만한 입력 및 출력 요구 사항 때문에, 모든 Gitaly 노드가 SSD(Solid-State Drive)를 사용하는 것을 강력히 권장합니다. 이러한 SSD는 읽기 작업에 대해 초당 최소 8,000개의 입출력 작업(IOPS) 및 쓰기 작업에 대해 2,000개의 IOPS의 처리량을 가져야 합니다. 환경을 클라우드 제공 업체에서 실행 중이라면, IOPS를 올바르게 구성하는 방법에 대한 문서를 참조하십시오.

Gitaly 서버는 기본적으로 네트워크 트래픽이 암호화되지 않기 때문에 공개 인터넷에 노출되어서는 안 됩니다. 방화벽의 사용을 강력히 권장하여 Gitaly 서버로의 접근을 제한하는 것이 좋습니다. 다른 옵션으로는 TLS 사용하는 것이 있습니다.

Gitaly를 구성하는 데는 다음 사항을 고려해야 합니다:

  • gitaly['configuration'][:storage]는 특정 Gitaly 노드의 저장 경로를 반영하도록 구성해야 합니다.
  • auth_token은 praefect_internal_token과 동일해야 합니다.

다음은 예제로 사용되는 IP 주소입니다:

  • 10.6.0.91: Gitaly 1
  • 10.6.0.92: Gitaly 2
  • 10.6.0.93: Gitaly 3

각 노드에서:

  1. 선택한 리눅스 패키지를 다운로드하고 설치합니다. 페이지에서 설치 단계 1과 2만 따르고, EXTERNAL_URL 값을 제공하지 마십시오.

  2. Gitaly 서버 노드의 /etc/gitlab/gitlab.rb 파일을 편집하여 저장 경로를 구성하고, 네트워크 리스너를 활성화하고 토큰을 구성합니다:

    # Gitaly 서버에서 불필요한 서비스의 실행을 피합니다
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
gitlab_exporter['enable'] = false
gitlab_kas['enable'] = false
   
# 업그레이드 시 자동으로 데이터베이스 마이그레이션 실행을 피합니다
gitlab_rails['auto_migrate'] = false
   
# gitlab-shell API 콜백 URL을 구성합니다. 이를 통해 `git push`가 실패하지 않도록 합니다. 'front door' GitLab URL 또는 내부 로드 밸런서가 될 수 있습니다.
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
   
# Gitaly
gitaly['enable'] = true
   
# Consul 에이전트를 구성합니다
consul['enable'] = true
## Prometheus를 위한 서비스 검색을 활성화합니다
consul['monitoring_service_discovery'] = true
   
# 사용자 구성 시작
# 필수 정보 섹션에서 설명한 대로 실제 값으로 설정하십시오.
#
## Consul 서버 노드의 IP 주소
## FQDN(Fully Qualified Domain Name)을 사용하고 IP 주소와 번갈아가며 사용할 수도 있습니다
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
   
# 모니터링을 위해 노드 익스포터가 청취할 네트워크 주소를 설정합니다
node_exporter['listen_address'] = '0.0.0.0:9100'
   
gitaly['configuration'] = {
   # Gitaly가 모든 네트워크 인터페이스에서 연결을 수락하도록 설정합니다. 이 주소/포트로의 접근을 제한하려면 방화벽을 사용해야 합니다.
   # TLS 연결만 지원하려면 다음 라인을 주석 처리하십시오
   listen_addr: '0.0.0.0:8075',
   # 모니터링을 위해 Gitaly가 청취할 네트워크 주소를 설정합니다
   prometheus_listen_addr: '0.0.0.0:9236',
   auth: {
      # Gitaly 인증 토큰
      # praefect_internal_token과 동일해야 합니다
      token: '<praefect_internal_token>',
   },
   pack_objects_cache: {
      # Gitaly Pack-objects 캐시
      # 성능을 향상시키기 위해 활성화되어야 하지만 디스크 I/O를 현저하게 증가시킬 수 있습니다.
      # 자세한 내용은 https://docs.gitlab.com/ee/administration/gitaly/configure_gitaly.html#pack-objects-cache를 참조하십시오
      enabled: true,
   },
}
   
#
# 사용자 구성 끝
  3. 각 해당 서버에 다음을 /etc/gitlab/gitlab.rb에 추가합니다:

    • Gitaly 노드 1에서: 

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

    • Gitaly 노드 2에서: 

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

    • Gitaly 노드 3에서: 

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

  4. 구성한 첫 번째 리눅스 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 해당 서버의 동일한 이름 파일을 추가하거나 교체합니다. 이것이 구성 중인 첫 번째 리눅스 패키지 노드인 경우, 이 단계를 건너뜁니다.

  5. 파일을 저장한 후 GitLab 재구성합니다.

Gitaly 클러스터 TLS 지원

Praefect는 TLS 암호화를 지원합니다. 안전한 연결을 수신하는 Praefect 인스턴스와 통신하려면 다음을 수행해야 합니다:

  • GitLab 구성의 해당 리포지터리 항목의 gitaly_address에 tls:// URL 스키마를 사용합니다.
  • 자동으로 제공되지 않으므로 각 Praefect 서버에 해당하는 인증서를 제공해야 합니다. 각 Praefect 서버에 대응하는 인증서를 설치해야 합니다.

또한 인증서 또는 해당 인증서 기관은 모든 Gitaly 서버와 Praefect 클라이언트에서 설치되어야 하며, GitLab 사용자 정의 인증서 구성에서 설명된 절차를 따라야 합니다(아래에 반복됨).

다음을 주의하십시오:

  • 인증서는 Praefect 서버에 액세스하는 데 사용하는 주소를 지정해야 합니다. 호스트 이름 또는 IP 주소를 인증서의 대체 주체 이름(Subject Alternative Name)으로 추가해야 합니다.
  • Praefect 서버는 암호화되지 않은 청취 주소 listen_addr와 동시에 암호화된 청취 주소 tls_listen_addr를 구성할 수 있어야 합니다. 필요한 경우 암호화되지 않은 트래픽에서 암호화된 트래픽으로 점진적으로 전환할 수 있습니다. 암호화되지 않은 리스너를 사용하지 않으려면 praefect['configuration'][:listen_addr] = nil로 설정하십시오.
  • 내부 로드 밸런서는 또한 인증서에 액세스하고 TLS 패스스루를 허용하도록 구성되어야 합니다. 이에 대한 구성 방법은 로드 밸런서 문서를 참조하십시오.

TLS로 Praefect를 구성하려면:

  1. Praefect 서버용 인증서를 생성합니다.

  2. Praefect 서버에서 /etc/gitlab/ssl 디렉터리를 생성하고 키 및 인증서를 복사합니다: 

    sudo mkdir -p /etc/gitlab/ssl
sudo chmod 755 /etc/gitlab/ssl
sudo cp key.pem cert.pem /etc/gitlab/ssl/
sudo chmod 644 key.pem cert.pem

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

    praefect['configuration'] = {
   # ...
   tls_listen_addr: '0.0.0.0:3305',
   tls: {
      # ...
      certificate_path: '/etc/gitlab/ssl/cert.pem',
      key_path: '/etc/gitlab/ssl/key.pem',
   },
}

  4. 파일을 저장하고 재구성합니다.

  5. Praefect 클라이언트(각 Gitaly 서버 포함)에서 인증서를 /etc/gitlab/trusted-certs에 복사합니다: 

    sudo cp cert.pem /etc/gitlab/trusted-certs/

  6. Praefect 클라이언트(Gitaly 서버 제외)에서 /etc/gitlab/gitlab.rb의 git_data_dirs를 다음과 같이 편집합니다: 

    git_data_dirs({
  "default" => {
    "gitaly_address" => 'tls://LOAD_BALANCER_SERVER_ADDRESS:3305',
    "gitaly_token" => 'PRAEFECT_EXTERNAL_TOKEN'
  }
})

  7. 파일을 저장하고 GitLab 재구성합니다.

Sidekiq 구성

Sidekiq는 Redis, PostgreSQL 및 Gitaly 인스턴스에 연결이 필요합니다. 또한 권장사항으로 Object Storage에 연결해야 합니다.

note
데이터 오브젝트에 대해 NFS 대신 Object Storage를 사용하는 것이 권장되기 때문에, 다음 예시에는 Object Storage 구성이 포함되어 있습니다.
  • 10.6.0.71: Sidekiq 1
  • 10.6.0.72: Sidekiq 2

Sidekiq 노드를 구성하려면 각각 다음을 수행하세요:

  1. Sidekiq 서버에 SSH로 로그인합니다.
  2. 원하는 리눅스 패키지를 다운로드하고 설치합니다. 페이지에서 설치 단계 1과 2만 따르도록 합니다.

  3. /etc/gitlab/gitlab.rb 파일을 생성하거나 편집하고 다음 구성을 사용합니다:

    # https://docs.gitlab.com/omnibus/roles/#sidekiq-roles
roles(["sidekiq_role"])
   
# 외부 URL
## 외부 로드 밸런서의 URL과 일치해야 합니다
external_url 'https://gitlab.example.com'
   
# Redis
## 모든 센티넬 노드에서 동일해야 합니다
redis['master_name'] = 'gitlab-redis'
   
## 마스터 노드에서 설정한 Redis 인증용 동일한 암호입니다.
redis['master_password'] = '<redis_primary_password>'
   
## `host`와 `port`가 있는 센티넬 디렉터리입니다
gitlab_rails['redis_sentinels'] = [
   {'host' => '10.6.0.11', 'port' => 26379},
   {'host' => '10.6.0.12', 'port' => 26379},
   {'host' => '10.6.0.13', 'port' => 26379},
]
   
# Gitaly 클러스터
## git_data_dirs는 Praefect 가상 리포지터리용으로 구성됩니다
## 주소는 Praefect의 내부 로드 밸런서입니다
## 토큰은 praefect_external_token입니다
git_data_dirs({
  "default" => {
    "gitaly_address" => "tcp://10.6.0.40:2305", # 내부 로드 밸런서 IP
    "gitaly_token" => '<praefect_external_token>'
  }
})
   
# PostgreSQL
gitlab_rails['db_host'] = '10.6.0.40' # 내부 로드 밸런서 IP
gitlab_rails['db_port'] = 6432
gitlab_rails['db_password'] = '<postgresql_user_password>'
gitlab_rails['db_load_balancing'] = { 'hosts' => ['10.6.0.21', '10.6.0.22', '10.6.0.23'] } # PostgreSQL IPs
   
## 업그레이드 시 자동으로 데이터베이스 마이그레이션을 방지합니다
gitlab_rails['auto_migrate'] = false
   
# Sidekiq
sidekiq['enable'] = true
sidekiq['listen_address'] = "0.0.0.0"
   
## 사용 가능한 CPU 개수와 동일한 수의 Sidekiq 큐 프로세스 수를 설정합니다
sidekiq['queue_groups'] = ['*'] * 4
   
# 모니터링
consul['enable'] = true
consul['monitoring_service_discovery'] =  true
   
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}
   
## 익스포터가 수신 대기할 네트워크 주소를 설정합니다
node_exporter['listen_address'] = '0.0.0.0:9100'
   
## 모니터링 노드의 IP 주소를 모니터링 화이트리스트에 추가합니다
gitlab_rails['monitoring_whitelist'] = ['10.6.0.81/32', '127.0.0.0/8']
gitlab_rails['prometheus_address'] = '10.6.0.81:9090'
   
# Object Storage
## 이것은 GCP에서 Object Storage를 구성하는 예시입니다
## 이 설정을 사용하도록 선택하는 원하는 Object Storage 제공업체로 교체합니다
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['object_store']['objects']['artifacts']['bucket'] = "<gcp-artifacts-bucket-name>"
gitlab_rails['object_store']['objects']['external_diffs']['bucket'] = "<gcp-external-diffs-bucket-name>"
gitlab_rails['object_store']['objects']['lfs']['bucket'] = "<gcp-lfs-bucket-name>"
gitlab_rails['object_store']['objects']['uploads']['bucket'] = "<gcp-uploads-bucket-name>"
gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
   
gitlab_rails['backup_upload_connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
   
gitlab_rails['ci_secure_files_object_store_enabled'] = true
gitlab_rails['ci_secure_files_object_store_remote_directory'] = "gcp-ci_secure_files-bucket-name"
   
gitlab_rails['ci_secure_files_object_store_connection'] = {
   'provider' => 'Google',
   'google_project' => '<gcp-project-name>',
   'google_json_key_location' => '<path-to-gcp-service-account-key>'
}

  4. 구성한 첫 번째 리눅스 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 동일한 이름의 파일을 추가하거나 교체합니다. 처음 구성하는 리눅스 패키지 노드인 경우 이 단계를 건너뛸 수 있습니다.

  5. 데이터베이스 마이그레이션을 다시 구성 중에만 실행되고 업그레이드 시 자동으로 실행되지 않도록 하려면 다음을 실행합니다: 

    sudo touch /etc/gitlab/skip-auto-reconfigure

    단일 지정된 노드만 GitLab Rails 구성 이후 섹션에 설명된 대로 마이그레이션을 처리해야 합니다.

  6. 변경 사항이 적용되려면 GitLab을 재구성합니다.

  7. GitLab 서비스가 실행되는지 확인합니다: 

    sudo gitlab-ctl status

    다음과 유사한 출력이어야 합니다: 

    run: consul: (pid 30114) 77353s; run: log: (pid 29756) 77367s
run: logrotate: (pid 9898) 3561s; run: log: (pid 29653) 77380s
run: node-exporter: (pid 30134) 77353s; run: log: (pid 29706) 77372s
run: sidekiq: (pid 30142) 77351s; run: log: (pid 29638) 77386s
note
환경의 Sidekiq 작업 처리가 큐가 길어 처리가 느리다고 판단되면 필요에 따라 더 많은 노드를 추가할 수 있습니다. 또한 여러 Sidekiq 프로세스를 실행하도록 Sidekiq 노드를 조정할 수 있습니다.

GitLab Rails 구성

이 섹션에서는 GitLab 애플리케이션 (Rails) 컴포넌트를 구성하는 방법에 대해 설명합니다.

Rails는 Redis, PostgreSQL 및 Gitaly 인스턴스에 연결이 필요합니다. 또한 객체 리포지터리에 연결해야 합니다. 이것이 권장되는 대로입니다.

note
데이터 객체에 대해 Object Storage 대신 NFS를 사용하는 것이 권장되기 때문에 다음 예제에는 Object Storage 구성이 포함됩니다.

각 노드에서 다음을 수행하세요:

  1. (https://about.gitlab.com/install/)에서 Linux 패키지를 다운로드하고 설치하세요. 페이지의 설치 단계 1 및 2에 따라 진행해야 합니다.

  2. /etc/gitlab/gitlab.rb을 만들거나 편집하고 다음 구성을 사용하세요. 노드 간의 링크를 일관되게 유지하기 위해 애플리케이션 서버의 external_url은 사용자가 GitLab에 액세스하는 데 사용하는 외부 URL을 가리켜야 합니다. 이것은 트래픽을 GitLab 애플리케이션 서버로 라우팅하는 외부 로드 밸런서의 URL입니다. 

    external_url 'https://gitlab.example.com'
   
# git_data_dirs get configured for the Praefect virtual storage
# Address is Internal Load Balancer for Praefect
# Token is praefect_external_token
git_data_dirs({
  "default" => {
    "gitaly_address" => "tcp://10.6.0.40:2305", # internal load balancer IP
    "gitaly_token" => '<praefect_external_token>'
  }
})
   
## GitLab 애플리케이션 서버에 없을 컴포넌트 비활성화
roles(['application_role'])
gitaly['enable'] = false
nginx['enable'] = true
sidekiq['enable'] = false
   
## PostgreSQL 연결 세부 정보
# 애플리케이션 노드에서 PostgreSQL 비활성화하기
postgresql['enable'] = false
gitlab_rails['db_host'] = '10.6.0.20' # internal load balancer IP
gitlab_rails['db_port'] = 6432
gitlab_rails['db_password'] = '<postgresql_user_password>'
gitlab_rails['db_load_balancing'] = { 'hosts' => ['10.6.0.21', '10.6.0.22', '10.6.0.23'] } # PostgreSQL IPs
   
# 업그레이드 시 데이터베이스 마이그레이션 자동 실행 방지
gitlab_rails['auto_migrate'] = false
   
## Redis 연결 세부 정보
## 모든 sentinel 노드에서는 동일해야 함
redis['master_name'] = 'gitlab-redis'
   
## Redis 주 노드에 설정한 Redis 인증과 동일한 비밀번호
redis['master_password'] = '<redis_primary_password>'
   
## 'host' 및 'port'를 가진 sentinel 디렉터리
gitlab_rails['redis_sentinels'] = [
  {'host' => '10.6.0.11', 'port' => 26379},
  {'host' => '10.6.0.12', 'port' => 26379},
  {'host' => '10.6.0.13', 'port' => 26379}
]
   
## 프로메테우스에 대한 서비스 디스커버리 활성화
consul['enable'] = true
consul['monitoring_service_discovery'] =  true
   
# 모니터링을 위해 익스포터가 청취할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
gitlab_workhorse['prometheus_listen_addr'] = '0.0.0.0:9229'
sidekiq['listen_address'] = "0.0.0.0"
puma['listen'] = '0.0.0.0'
   
## 콘술 서버 노드의 IP
## FQDN 및 IP를 혼합하여 사용 가능
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
   
# 모니터링 노드의 IP 주소를 모니터링 화이트리스트에 추가하여 NGINX 메트릭을 스크래이핑할 수 있도록 허용
gitlab_rails['monitoring_whitelist'] = ['10.6.0.81/32', '127.0.0.0/8']
nginx['status']['options']['allow'] = ['10.6.0.81/32', '127.0.0.0/8']
gitlab_rails['prometheus_address'] = '10.6.0.81:9090'
   
#############################
###     Object storage    ###
#############################
   
# GCP에서 객체 리포지터리를 구성하는 예시
# 이 구성을 원하는 Object Storage 제공 업체의 구성으로 대체하세요
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['object_store']['objects']['artifacts']['bucket'] = "<gcp-artifacts-bucket-name>"
gitlab_rails['object_store']['objects']['external_diffs']['bucket'] = "<gcp-external-diffs-bucket-name>"
gitlab_rails['object_store']['objects']['lfs']['bucket'] = "<gcp-lfs-bucket-name>"
gitlab_rails['object_store']['objects']['uploads']['bucket'] = "<gcp-uploads-bucket-name>"
gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
   
gitlab_rails['backup_upload_connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
gitlab_rails['ci_secure_files_object_store_enabled'] = true
gitlab_rails['ci_secure_files_object_store_remote_directory'] = "gcp-ci_secure_files-bucket-name"
   
gitlab_rails['ci_secure_files_object_store_connection'] = {
   'provider' => 'Google',
   'google_project' => '<gcp-project-name>',
   'google_json_key_location' => '<path-to-gcp-service-account-key>'
}

  3. Gitaly에 TLS 지원을 사용하는 경우 git_data_dirs 항목이 tcp 대신 tls로 구성되었는지 확인하세요. 

    git_data_dirs({
  "default" => {
    "gitaly_address" => "tls://10.6.0.40:2305", # internal load balancer IP
    "gitaly_token" => '<praefect_external_token>'
  }
})

    1. /etc/gitlab/trusted-certs로 인증서를 복사하세요. 

      sudo cp cert.pem /etc/gitlab/trusted-certs/
  4. 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하고 이 서버의 동일한 이름의 파일을 추가하거나 교체하세요. 이것이 처음 구성하는 Linux 패키지 노드인 경우에는 이 단계를 건너뛰어도 됩니다.
  5. 첫 번째 Linux 패키지 노드에서 SSH 호스트 키(/etc/ssh/ssh_host_*_key* 형식의 모든 파일)를 복사하고 이 서버의 동일한 이름의 파일을 추가하거나 교체하세요. 이렇게 하면 사용자가 로드 밸런스된 Rails 노드에 액세스할 때 호스트 불일치 오류가 발생하지 않습니다. 이것이 처음 구성하는 Linux 패키지 노드인 경우에는 이 단계를 건너뛰어도 됩니다.

  6. 데이터베이스 마이그레이션이 업그레이드 중에 자동으로 실행되지 않고 재구성(reconfigure) 중에만 실행되도록 하려면 다음 명령을 실행하세요. 

    sudo touch /etc/gitlab/skip-auto-reconfigure

    지정된 노드 한 대만 이를 처리해야 하며 상세 내용은 GitLab Rails 재구성(post-configuration) 섹션을 참조하세요.

  7. 변경 사항이 적용되려면 GitLab을 재구성하세요(reconfigure).
  8. 증분 로깅을 활성화하세요.
  9. sudo gitlab-rake gitlab:gitaly:check를 실행하여 노드가 Gitaly에 연결할 수 있는지 확인하세요.

  10. 요청 내용을 확인하려면 로그를 확인하세요. 

    sudo gitlab-ctl tail gitaly

  11. GitLab 서비스가 실행 중인지 확인하세요. 

    sudo gitlab-ctl status

    출력은 다음과 비슷해야 합니다. 

    run: consul: (pid 4890) 8647s; run: log: (pid 29962) 79128s
run: gitlab-exporter: (pid 4902) 8647s; run: log: (pid 29913) 79134s
run: gitlab-workhorse: (pid 4904) 8646s; run: log: (pid 29713) 79155s
run: logrotate: (pid 12425) 1446s; run: log: (pid 29798) 79146s
run: nginx: (pid 4925) 8646s; run: log: (pid 29726) 79152s
run: node-exporter: (pid 4931) 8645s; run: log: (pid 29855) 79140s
run: puma: (pid 4936) 8645s; run: log: (pid 29656) 79161s

이전 예에서처럼 external_url에 https를 지정하면 GitLab은 SSL 인증서가 /etc/gitlab/ssl/에 있는 것으로 예상합니다. 인증서가 없는 경우 NGINX가 시작하지 못합니다. 자세한 내용은 HTTPS 문서를 참조하세요.

GitLab Rails 후 구성

  1. 모든 마이그레이션이 실행되었는지 확인하십시오: 

    gitlab-rake gitlab:db:configure

    레일스 노드가 본래 데이터베이스에 연결되도록 구성되어 있어야 합니다. PgBouncer 우회가 필요합니다. 마이그레이션이 완료된 후 노드를 PgBouncer를 통과하도록 다시 구성해야 합니다.

  2. 데이터베이스에서 SSH 키를 빠르게 찾도록 구성하세요(../operations/fast_ssh_key_lookup.md).

프로메테우스 구성

리눅스 패키지를 사용하여 프로메테우스를 실행하는 독립 모니터링 노드를 구성할 수 있습니다:

  1. 모니터링 노드에 SSH로 로그인합니다.
  2. 선택한 리눅스 패키지를 다운로드하고 설치합니다. 페이지의 설치 단계 1과 2만 따르도록 주의하세요.

  3. /etc/gitlab/gitlab.rb 파일을 편집하고 다음 내용을 추가합니다: 

    roles(['monitoring_role', 'consul_role'])
   
external_url 'http://gitlab.example.com'
   
# 프로메테우스
prometheus['listen_address'] = '0.0.0.0:9090'
prometheus['monitor_kubernetes'] = false
   
# 프로메테우스를 위한 서비스 검색 활성화
consul['monitoring_service_discovery'] =  true
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}
   
# 프로메테우스 구성 - 검색되지 않은 서비스를 스크레이핑하도록 구성합니다
prometheus['scrape_configs'] = [
   {
      'job_name': 'pgbouncer',
      'static_configs' => [
         'targets' => [
         "10.6.0.31:9188",
         "10.6.0.32:9188",
         "10.6.0.33:9188",
         ],
      ],
   },
   {
      'job_name': 'praefect',
      'static_configs' => [
         'targets' => [
         "10.6.0.131:9652",
         "10.6.0.132:9652",
         "10.6.0.133:9652",
         ],
      ],
   },
]
   
nginx['enable'] = false
  4. 파일을 저장하고 GitLab을 다시 구성합니다.

  5. GitLab 서비스가 실행 중인지 확인합니다: 

    sudo gitlab-ctl status

    출력은 다음과 유사해야 합니다: 

    run: consul: (pid 31637) 17337s; run: log: (pid 29748) 78432s
run: logrotate: (pid 31809) 2936s; run: log: (pid 29581) 78462s
run: nginx: (pid 31665) 17335s; run: log: (pid 29556) 78468s
run: prometheus: (pid 31672) 17335s; run: log: (pid 29633) 78456s

객체 리포지터리 구성

GitLab은 여러 유형의 데이터를 보관하기 위해 객체 리포지터리 서비스를 사용하는 것을 지원합니다. 데이터 객체에 대해 NFS 대신 추천되며, 일반적으로 객체 리포지터리는 훨씬 빠르고 안정적이며 확장 가능하기 때문에 대규모 설정에서 더 나은 성능을 제공합니다. 자세한 내용은 권장되는 클라우드 제공업체 및 서비스를 참조하세요.

GitLab에서 객체 리포지터리 구성을 지정하는 두 가지 방법이 있습니다:

통합된 형태는 가능한 경우 다음 예제에서 사용됩니다.

각 데이터 유형에 대해 별도의 버킷을 사용하는 것이 GitLab에서 권장하는 방법입니다. 이렇게 하면 GitLab이 저장하는 다양한 유형의 데이터 간에 충돌이 없도록 보장됩니다. 미래에는 단일 버킷 사용을 가능하게 함이 예정되어 있습니다.

증분 로깅 활성화

기본 구성으로 GitLab Runner는 작업 로그를 여러 조각으로 반환하며, 기본 설정에서는 /var/opt/gitlab/gitlab-ci/builds 디렉터리에 임시로 캐시합니다. 증분 로깅은 임시 작업 로그의 디스크 공간 대신 Redis를 사용하여 NFS 노드를 사용하지 않고도 임시 작업 로그의 캐싱을 가능하게 합니다.

NFS를 통해 작업 로그를 공유하는 것은 지원되지만, NFS 노드를 배포하지 않은 경우 증분 로깅을 활성화(됨)하여 NFS의 필요성을 피하는 것이 권장됩니다. NFS를 사용하지 않고 증분 로깅을 활성화할 경우 Redis를 사용합니다.

고급 검색 구성

Elasticsearch를 활용하여 전체 GitLab 인스턴스에서 더 빠르고 더 고급 코드 검색을 사용할 수 있습니다. 고급 검색 활성화를 참조하세요.

Elasticsearch 클러스터 디자인 및 요구 사항은 특정 데이터에 따라 다릅니다. Elasticsearch 클러스터 구성에 대한 권장 모범 사례에 대한 자세한 내용은 최적의 클러스터 구성 선택을 참조하세요.

Helm 차트를 사용한 클라우드 네이티브 하이브리드 참조 아키텍처(대체)

클라우드 네이티브 GitLab의 일부 컴포넌트를 쿠버네티스에서 실행하려면 GitLab Helm 차트를 사용할 수 있습니다. 이 설정에서는 쿠버네티스 클러스터인 웹서비스에서 GitLab 레일스의 동등한 버전을 실행하고 사이드킥 노드를 사이드킥에서 실행할 수 있습니다. 또한 다음과 같은 다른 지원 서비스는 지원됩니다: NGINX, Toolbox, 마이그레이션, 프로메테우스.

하이브리드 설치는 클라우드 네이티브 및 전통적인 컴퓨팅 배포의 이점을 함께 활용합니다. 이렇게 하면 상태가 없는 컴포넌트가 클라우드 네이티브 워크로드 관리의 이점을 활용할 수 있고 상태가 있는 컴포넌트는 Linux 패키지 설치로 계산 VM에서 배포되어 지속성이 높아집니다.

Kubernetes에서 서비스를 실행하는 것은 복잡하다고 잘 알려져 있습니다. 이 설정은 오직 꾸준한 쿠버네티스 지식과 경험이 있는 경우에만 추천됩니다. 이 섹션의 나머지는 이를 가정한 것입니다.

caution
Gitaly Cluster는 Kubernetes에서 실행되지 않습니다. 자세한 내용은 epic 6127을 참조하세요.

클러스터 토폴로지

다음 표와 다이어그램은 전형적인 환경과 동일한 형식을 사용하여 하이브리드 환경을 설명합니다.

먼저 Kubernetes에서 실행되는 컴포넌트입니다. 이러한 컴포넌트는 여러 노드 그룹 전체에 걸쳐 실행되지만, 최소 CPU 및 메모리 요구 사항을 준수한다면 원하는대로 전체 구성을 변경할 수 있습니다.

컴포넌트 노드 그룹 대상 노드 풀 합계 GCP 예시 AWS 예시
Webservice 36 vCPU
45 GB 메모리 (요청)
63 GB 메모리 (제한) 		3 x n1-standard-16 3 x c5.4xlarge
Sidekiq 7.2 vCPU
16 GB 메모리 (요청)
32 GB 메모리 (제한) 		3 x n1-standard-4 3 x m5.xlarge
지원 서비스 4 vCPU
15 GB 메모리 		2 x n1-standard-2 2 x m5.large
  • 이 설정에서는 Google Kubernetes Engine (GKE) 및 Amazon Elastic Kubernetes Service (EKS)를 권장하며 정기적으로 테스트합니다. 다른 Kubernetes 서비스도 작동할 수 있지만 결과는 다를 수 있습니다.
  • 대상 노드 풀 합계에 도달하는 방법에 대한 GCP 및 AWS 예시가 편리하게 제공됩니다. 이러한 크기는 성능 테스트에 사용되지만 예시를 따를 필요는 없습니다. 대상을 충족하고 모든 파드를 배포할 수 있다면 원하는 대로 다른 노드 풀 디자인을 사용할 수 있습니다.
  • Webservice 및 Sidekiq 대상 노드 풀 합계는 GitLab 구성요소에만 적용됩니다. 선택한 Kubernetes 제공 업체의 시스템 프로세스에 대한 추가 리소스가 필요합니다. 제시된 예시는 이를 고려합니다.
  • Supporting 대상 노드 풀 합계는 GitLab 배포를 지원하기 위해 여러 리소스를 수용하기 위해 일반적으로 제공됩니다. 또한 요구 사항에 따라 추가 배포도 가능합니다. 다른 노드 풀과 마찬가지로 선택한 Kubernetes 제공 업체의 시스템 프로세스도 리소스를 필요로 합니다. 제시된 예시는 이를 고려합니다.
  • 프로덕션 배포에서는 파드를 특정 노드에 할당할 필요는 없지만, 클라우드 아키텍처의 견고한 구현에 맞추기 위해 각 풀에 여러 노드를 분산 배치하는 것이 권장됩니다.
  • 클러스터 오토스케일링(Cluster Autoscaler)과 같은 효율성을 위한 오토스케일링을 활성화하는 것은 권장되지만, 계속된 성능을 보장하기 위해 Webservice 및 Sidekiq 파드의 최소값을 75%로 설정하는 것이 일반적으로 권장됩니다.

다음은 Linux 패키지를 사용하거나 (적용 가능한 경우) 정적 컴퓨팅 VM에서 실행되는 백엔드 컴포넌트입니다.

서비스 노드 수 구성 GCP AWS
Redis2 3 2 vCPU, 7.5 GB 메모리 n1-standard-2 m5.large
Consul1 + Sentinel2 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large
PostgreSQL1 3 4 vCPU, 15 GB 메모리 n1-standard-4 m5.xlarge
PgBouncer1 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large
내부 로드 밸런서3 1 4 vCPU, 3.6 GB 메모리 n1-highcpu-4 c5n.xlarge
Gitaly5 3 8 vCPU, 30 GB 메모리6 n1-standard-8 m5.2xlarge
Praefect5 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large
Praefect PostgreSQL1 1+ 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large
객체 리포지터리4 - - - -

각주:

  1. 신뢰할 수 있는 타사 외부 PaaS PostgreSQL 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 본인의 PostgreSQL 인스턴스 제공를 참조하십시오.
  2. 신뢰할 수 있는 타사 외부 PaaS Redis 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 본인의 Redis 인스턴스 제공를 참조하십시오.
  3. 신뢰할 수 있는 클라우드 제공자 또는 직접 관리하는 솔루션에서 실행하는 것이 권장됩니다. 자세한 내용은 객체 리포지터리 구성를 참조하십시오.
  4. Gitaly 클러스터는 내결함성의 장점을 제공하지만 설정 및 관리에 대한 복잡성을 동반합니다. Gitaly 클러스터를 배포하기 전에 기술적 제한 사항 및 고려 사항을 확인하십시오. 샤드된 Gitaly를 원하는 경우 Gitaly에 대해 위에 나열된 동일한 사양을 사용하십시오.
  5. Gitaly 사양은 사용 패턴 및 리포지터리 크기의 높은 백분율에 기반합니다. 그러나 대형 모노 리포지터리 (여러 기가바이트보다 큰)나 추가 워크로드가 있는 경우 Git 및 Gitaly 성능에 상당한 영향을 줄 수 있으며 추가적인 조정이 필요할 수 있습니다.
note
인스턴스 구성을 포함하는 모든 PaaS 솔루션의 경우, 견고한 클라우드 아키텍처 관행에 맞춰 세 가용 영역에서 최소한 세 개의 노드를 구현하는 것이 권장됩니다.

Kubernetes 컴포넌트 대상

다음 섹션에서는 Kubernetes에 배포된 GitLab 컴포넌트에 사용된 대상을 상세히 설명합니다.

Webservice

각 Webservice pod(Puma 및 Workhorse)은 다음 구성으로 실행하는 것이 좋습니다.

  • 4개의 Puma Workers
  • 4 vCPU
  • 5GB 메모리 (요청)
  • 7GB 메모리 (한계)

100 RPS 또는 5,000 사용자의 경우, 약 36개의 총 Puma worker 수를 권장하며, 이에 따라 최소 9개의 Webservice pod를 실행하는 것이 권장됩니다.

Webservice 리소스 사용에 대한 자세한 정보는 Webservice resources의 차트 설명서를 참조하십시오.

NGINX

Webservice 노드 전체에 NGINX 컨트롤러 pod를 데몬셋으로 배포하는 것이 좋습니다. 이렇게 하면 컨트롤러가 제공하는 Webservice pod와 동적으로 확장되며 일반적으로 더 큰 머신 유형에 높은 네트워크 대역폭을 활용할 수 있습니다.

이것이 엄격한 요구 사항은 아닙니다. NGINX 컨트롤러 pod는 웹 트래픽을 처리할 충분한 리소스가 있으면 원하는대로 배포할 수 있습니다.

Sidekiq

각 Sidekiq pod는 다음 구성으로 실행하는 것이 좋습니다.

  • 1개의 Sidekiq worker
  • 900m vCPU
  • 2GB 메모리 (요청)
  • 4GB 메모리 (한계)

표준 배포와 유사하게, 여기에서 초기 목표로 8개의 Sidekiq worker가 사용되었습니다. 특정 워크플로에 따라 추가 worker가 필요할 수 있습니다.

Sidekiq 리소스 사용에 대한 자세한 정보는 Sidekiq resources의 차트 설명서를 참조하십시오.

지원

지원 노드 풀은 Webservice 및 Sidekiq 풀에 있을 필요가 없는 모든 지원 배포를 수용하기 위해 설계되었습니다.

이에는 Cloud Provider 구현 및 GitLab Shell과 같은 GitLab 배포와 관련된 여러 배포가 포함됩니다.

컨테이너 레지스트리, 페이지 또는 모니터링과 같은 추가 배포를 하려면 가능한 경우 이 풀에 배포하는 것이 좋습니다. 특정 배포가 주어진 풀에 맞지 않는 경우, 노드 풀을 적절하게 늘릴 수 있습니다. 사용 사례에 따라 오버 프로비저닝된 경우 사용 사례에 맞게 줄일 수 있습니다.

구성 파일 예시

위의 100 RPS 또는 5,000 참고 아키텍처 구성에 대한 GitLab Helm 차트의 예시는 Charts 프로젝트에서 찾을 수 있습니다.