참조 아키텍처: 최대 500 RPS 또는 25,000 사용자를 대상으로 함

Tier: Premium, Ultimate Offering: Self-Managed

이 페이지는 GitLab 참조 아키텍처를 설명하여 설계되었으며, 실제 데이터를 기반으로 최대 500 초당 요청(RPS) - 최대 25,000 사용자(매뉴얼 및 자동)의 일반적인 최대 부하를 대상으로 합니다.

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

note
이 아키텍처를 배포하기 전에, 먼저 본 문서를 읽는 것이 좋습니다. 특히 시작하기 전에 및 사용할 아키텍처 결정 섹션을 참조하십시오.
서비스 노드 구성 GCP AWS Azure
외부 로드 밸런서3 1 8 vCPU, 7.2 GB 메모리 n1-highcpu-8 c5n.2xlarge F8s v2
Consul1 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large F2s v2
PostgreSQL1 3 16 vCPU, 60 GB 메모리 n1-standard-16 m5.4xlarge D16s v3
PgBouncer1 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large F2s v2
내부 로드 밸런서3 1 8 vCPU, 7.2 GB 메모리 n1-highcpu-8 c5n.2xlarge F8s v2
Redis/Sentinel - Cache2 3 4 vCPU, 15 GB 메모리 n1-standard-4 m5.xlarge D4s v3
Redis/Sentinel - Persistent2 3 4 vCPU, 15 GB 메모리 n1-standard-4 m5.xlarge D4s v3
Gitaly5 3 32 vCPU, 120 GB 메모리6 n1-standard-32 m5.8xlarge D32s v3
Praefect5 3 4 vCPU, 3.6 GB 메모리 n1-highcpu-4 c5.xlarge F4s v2
Praefect PostgreSQL1 1+ 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large F2s v2
Sidekiq7 4 4 vCPU, 15 GB 메모리 n1-standard-4 m5.xlarge D4s v3
GitLab Rails7 5 32 vCPU, 28.8 GB 메모리 n1-highcpu-32 c5.9xlarge F32s v2
모니터링 노드 1 4 vCPU, 3.6 GB 메모리 n1-highcpu-4 c5.xlarge F4s v2
객체 리포지터리4 - - - - -

각주:

  1. 신뢰할 수 있는 서드파티 외부 PaaS PostgreSQL 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 정보는 본인의 PostgreSQL 인스턴스 제공를 참조하십시오.
  2. 신뢰할 수 있는 서드파티 외부 PaaS Redis 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 정보는 본인의 Redis 인스턴스 제공를 참조하십시오.
    • Redis는 주로 싱글 스레드이며 CPU 코어의 증가로 큰 이득을 보지 않습니다. 이 사이즈의 아키텍처의 경우, 최적의 성능을 달성하기 위해 별도로 지정된 Cache 및 Persistent 인스턴스를 고유하게 가져야 합니다.
  3. HA 기능을 제공할 수 있는 신뢰할 수 있는 서드파티 로드 밸런서 또는 서비스(LB PaaS)에서 실행하는 것이 좋습니다. 또한, 사이징은 선택한 로드 밸런서와 네트워크 대역폭과 같은 추가 요소에 따라 달라질 수 있습니다. 자세한 내용은 로드 밸런서를 참조하십시오.
  4. 신뢰할 수 있는 클라우드 제공업체 또는 Self-Managed형 솔루션에서 실행하도록 되어 있습니다. 자세한 정보는 객체 리포지터리 구성를 참조하십시오.
  5. Gitaly 클러스터는 용량을 증가시키면서 추가 복잡성이 동반되는 고장 허용 기능을 제공합니다. Gitaly 클러스터를 배포하기 전 기존 기술적 한계와 고려할 사항을 검토하십시오. Sharded Gitaly를 원하는 경우 Gitaly에 동일한 사양을 사용하십시오.
  6. Gitaly 사양은 건강한 상태의 높은 백분위수에 기초로 하여 사용 패턴 및 리포지터리 크기의 큰 부분에 기반합니다. 그러나 대규모 모노 레포 (몇 기가바이트 이상) 또는 추가 워크로드가 있다면 Git 및 Gitaly 성능에 상당한 영향을 미치며 추가적인 조정이 필요할 수 있습니다.
  7. 컴포넌트는 stateful data의 자동 스케일링을 제한하기 때문에 Auto Scaling Groups (ASGs)에 배치할 수 있습니다. 그러나, 클라우드 네이티브 하이브리드 세트업이 보편적으로 선호되는데 이것은 마이그레이션 및 Mailroom과 같은 특정 컴포넌트를 단일 노드에서만 실행할 수 있기 때문입니다.
note
인스턴스 구성을 포함하는 모든 PaaS 솔루션에 대해서는, 탄력적인 클라우드 아키텍처 관행에 따라 세 가지 다른 가용성 영역에 각각 최소 세 노드를 구현하는 것이 좋습니다.

요구 사항

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

테스트 방법론

25k 아키텍처는 다수의 워크플로를 커버하도록 설계되었으며, 정기적으로 스모크 및 성능 테스트를 테스트 플랫폼 팀에 의해 수행됩니다. 다음의 엔드포인트 처리량 목표에 대해 테스트되었습니다:

  • API: 500 RPS
  • Web: 50 RPS
  • Git (Pull): 50 RPS
  • Git (Push): 10 RPS

위의 목표는 CI 및 다른 워크로드를 포함한 총 환경 부하에 대한 실제 고객 데이터를 기반으로 선정되었습니다.

만약 위의 엔드포인트 목표에 대해 정기적으로 더 높은 처리량을 갖고 있다는 메트릭이 있다면, 대규모 모노 리포 또는 주목할만한 추가 워크로드가 성능 환경에 주목할 만한 영향을 미칠 수 있으며, 추가 조정이 필요할 수 있습니다. 해당 사항이 해당된다면, 해당 링크된 문서를 참고하고 고객 성공 관리자에게 문의하여 추가 지침을 얻을 것을 강력히 권장합니다.

테스트는 주기적으로 GitLab 성능 도구 (GPT) 및 해당 데이터셋을 통해 수행되며, 누구나 사용할 수 있습니다. 이러한 테스트 결과는 GPT 위키에서 공개적으로 확인하실 수 있습니다. 테스트 전략에 대한 자세한 내용은 문서의 해당 섹션을 참고하세요.

테스트에 사용된 로드 밸런서는 리눅스 패키지 환경의 경우 HAProxy를, 또는 클라우드 네이티브 하이브리드의 경우 NGINX Ingress를 사용하였습니다. 이러한 선택들은 특정 요구사항 또는 권장사항을 나타내는 것이 아니며, 대부분 신뢰할 수 있는 로드 밸런서를 사용하는 것이 기대됩니다.

컴포넌트 설정

GitLab 및 해당 컴포넌트를 500 RPS 또는 25,000 사용자까지 수용할 수 있도록 설정하려면 다음을 수행하세요:

  1. 외부 로드 밸런서를 구성하여 GitLab 애플리케이션 서비스 노드의 로드 밸런싱을 처리합니다.
  2. 내부 로드 밸런서를 구성하여 GitLab 애플리케이션 내부 연결의 로드 밸런싱을 처리합니다.
  3. Consul을 구성.
  4. GitLab용 데이터베이스인 PostgreSQL을 구성합니다.
  5. PgBouncer를 구성합니다.
  6. Redis를 구성합니다.
  7. Gitaly 클러스터를 구성하여 Git 리포지터리에 액세스합니다.
  8. Sidekiq를 구성합니다.
  9. 주요 GitLab Rails 응용프로그램을 구성하여 Puma, Workhorse, GitLab Shell을 실행하고 모든 프론트엔드 요청 (UI, API 및 Git over HTTP/SSH 포함)을 제공합니다.
  10. GitLab 환경을 모니터링하기 위해 Prometheus를 구성합니다.
  11. 공유 데이터 오브젝트를 위해 사용되는 객체 리포지터리를 구성합니다.
  12. 더 빠르고 차별화된 코드 검색을 위해 고급 검색을 구성합니다(선택 사항).

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

다음 디렉터리에는 각 서버와 해당 할당된 IP의 설명이 포함되어 있습니다:

  • 10.6.0.10: 외부 로드 밸런서
  • 10.6.0.11: Consul 1
  • 10.6.0.12: Consul 2
  • 10.6.0.13: Consul 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.40: 내부 로드 밸런서
  • 10.6.0.51: Redis - 캐시 주 서버
  • 10.6.0.52: Redis - 캐시 복제본 1
  • 10.6.0.53: Redis - 캐시 복제본 2
  • 10.6.0.61: Redis - 영속적 주 서버
  • 10.6.0.62: Redis - 영속적 복제본 1
  • 10.6.0.63: Redis - 영속적 복제본 2
  • 10.6.0.91: Gitaly 1
  • 10.6.0.92: 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.134: Praefect PostgreSQL 1 (HA 아님)
  • 10.6.0.101: Sidekiq 1
  • 10.6.0.102: Sidekiq 2
  • 10.6.0.103: Sidekiq 3
  • 10.6.0.104: Sidekiq 4
  • 10.6.0.111: GitLab 애플리케이션 1
  • 10.6.0.112: GitLab 애플리케이션 2
  • 10.6.0.113: GitLab 애플리케이션 3
  • 10.6.0.114: GitLab 애플리케이션 4
  • 10.6.0.115: GitLab 애플리케이션 5
  • 10.6.0.151: Prometheus

외부 로드 밸런서 구성

멀티노드 GitLab 구성에서 애플리케이션 서버로의 트래픽을 라우팅하기 위해 외부 로드 밸런서가 필요합니다.

어떤 로드 밸런서를 사용할지 또는 해당 정확한 구성은 GitLab 문서의 범위를 벗어나지만, 일반 요구 사항에 대한 자세한 정보는 로드 밸런서를 참조하십시오. 이 섹션은 선택한 로드 밸런서에 대한 구체적인 구성에 중점을 둡니다.

준비성 확인

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

포트

사용되는 기본 포트는 다음 표에서 확인할 수 있습니다.

LB 포트 백엔드 포트 프로토콜
80 80 HTTP (1)
443 443 TCP 또는 HTTPS (1) (2)
22 22 TCP
  • (1): 웹 터미널 지원을 위해서는 로드 밸런서가 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에 구성을 추가해야 할 것입니다. SSL 인증서를 관리하고 NGINX를 구성하는 세부 정보는 HTTPS 문서를 참조하십시오.

내부 로드 밸런서 구성

내부 로드 밸런서는 PgBouncer 및 Praefect (Gitaly 클러스터)와 같이 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

호환하는 로드 밸런서의 자세한 지침은 해당 로드 밸런서의 문서를 참조하십시오.

Consul 구성

다음으로, Consul 서버를 설정합니다.

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

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

  • 10.6.0.11: Consul 1
  • 10.6.0.12: Consul 2
  • 10.6.0.13: Consul 3

Consul을 구성하려면:

  1. Consul을 호스팅할 서버에 SSH로 로그인합니다.
  2. 선택한 Linux 패키지를 다운로드 및 설치합니다. 페이지에서 설치 단계 1과 2를 따르고, 현재 설치된 버전과 유형(커뮤니티 또는 엔터프라이즈 에디션)이 동일한 올바른 Linux 패키지를 선택하도록 합니다.

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

    roles(['consul_role'])
   
## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] =  true
   
## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
consul['configuration'] = {
   server: true,
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
   
# Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
   
# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false

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

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

  6. 다른 Consul 노드에 대해서도 단계를 다시 한 번 거치고 올바른 IP를 설정했는지 확인하십시오.

제 3 Consul 서버의 프로비저닝이 완료되면 Consul 리더가 _선출_됩니다. Consul 로그 sudo gitlab-ctl tail consul을 보면 ...[INFO] consul: New leader elected: ...와 같은 메시지가 표시됩니다.

현재 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

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. 서비스에 따라 HA를 달성하려면 필요한 노드 수가 Linux 패키지와 일치할 필요는 없습니다.
  6. 그러나, 더 향상된 성능을 원한다면 데이터베이스 로드 밸런싱을 위해 읽기 전용 복제본을 통한 원하는 경우, 참조 아키텍처의 노드 수를 따르는 것이 권장됩니다.

Linux 패키지를 사용한 독립형 PostgreSQL

복제 및 장애 조치 기능이 있는 PostgreSQL 클러스터를위한 권장 Linux 패키지 구성은 다음과 같습니다:

  • 최소 3개의 PostgreSQL 노드
  • 최소 3개의 Consul 서버 노드
  • 기본 데이터베이스 읽기와 쓰기를 추적하고 처리하는 최소 3개의 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 패키지 설치를 확인하세요. 그 후 1단계에서 필요한 의존성을 설치하고, 2단계에서 GitLab 패키지 리포지터리를 추가합니다. 2단계에서는 EXTERNAL_URL 값을 제공하지 않습니다.

PostgreSQL 노드

  1. PostgreSQL 노드 중 하나에 SSH로 연결합니다.

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

  3. PgBouncer 사용자/암호 쌍에 대한 암호 해시를 생성합니다. 기본 사용자 이름 인 pgbouncer을 사용할 것으로 가정합니다 (권장). 명령은 암호 및 확인을 요청할 것입니다. 이 명령으로 출력되는 값을 다음 단계의 값 <pgbouncer_password_hash>로 사용하세요: shell sudo gitlab-ctl pg-password-md5 pgbouncer

  4. PostgreSQL 복제 사용자/암호 쌍에 대한 암호 해시를 생성합니다. 기본 사용자 이름 인 gitlab_replicator을 사용할 것으로 가정합니다 (권장). 명령은 암호 및 확인을 요청할 것입니다. 이 명령으로 출력되는 값을 다음 단계의 값 <postgresql_replication_password_hash>로 사용하세요: shell sudo gitlab-ctl pg-password-md5 gitlab_replicator

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

  6. 모든 데이터베이스 노드에서 /etc/gitlab/gitlab.rb를 편집하여 # START user configuration 섹션에 기록된 값들을 대체하세요: ```ruby # 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를 클러스터의 복제 슬롯 수보다 하나 더 설정합니다.

    이는 복제가 모든 가능한 데이터베이스 연결을 사용하는 것을 막기위해 사용됩니다.

    patroni[‘postgresql’][‘max_wal_senders’] = 7

    업그레이드시 데이터베이스 마이그레이션을 자동으로 방지합니다

    gitlab_rails[‘auto_migrate’] = false

    Consul 에이전트 구성

    consul[‘services’] = %w(postgresql) ## Prometheus용 서비스 검색 활성화 consul[‘monitoring_service_discovery’] = true

    START 유저 구성

    필수 정보 섹션에 설명된 대로 실제 값을 설정하세요

    # # PGBOUNCER_PASSWORD_HASH를 생성된 md5 값으로 대체 postgresql[‘pgbouncer_user_password’] = ‘' # POSTGRESQL_REPLICATION_PASSWORD_HASH를 생성된 md5 값으로 대체 postgresql['sql_replication_password'] = '' # POSTGRESQL_PASSWORD_HASH를 생성된 md5 값으로 대체 postgresql['sql_user_password'] = ''

    Patroni API에 기본 인증 설정(모든 노드에서 동일한 사용자 이름/암호 사용)

    patroni[‘username’] = ‘' patroni['password'] = ''

    네트워크 주소를 세트업합니다

    postgresql[‘trust_auth_cidr_addresses’] = %w(10.6.0.0/24 127.0.0.1/32)

    데이터베이스 로드 밸런싱을 위한 로컬 PgBouncer 서비스

    pgbouncer[‘databases’] = { gitlabhq_production: { host: “127.0.0.1”, user: “pgbouncer”, password: ‘' } }

    모니터링을 위해 익스포터가 청취할 네트워크 주소 설정

    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 유저 구성 ```

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

  7. 처음 Linux 패키지 노드의 /etc/gitlab/gitlab-secrets.json 파일을 복사하여이 서버의 동일한 이름의 파일을 추가하거나 교체합니다. 이것이 처음 구성하는 Linux 패키지 노드이면이 단계를 건너 뛸 수 있습니다.

  8. 변경 사항이 적용되도록 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         | *               |

만약 어떤 노드의 ‘State’ 열이 “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'

  2. 이전에 구성한 첫 번째 리눅스 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버와 동일한 파일에 추가하거나 대체하십시오. 이것이 구성하는 첫 번째 리눅스 패키지 노드라면 해당 단계를 건너뛰어도 됩니다.

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

    execute[generate databases.ini] 오류가 발생하면, 이는 기존의 알려진 문제 때문입니다. 이는 다음 단계 이후에 두 번째 reconfigure를 실행할 때 해결될 것입니다.

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

    gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul
  5. 이전 단계에서 발생할 수 있는 잠재적인 오류를 해결하기 위해 다시 GitLab 다시 구성하십시오.

  6. 각 노드가 현재 주 클러스터와 통신하고 있는지 확인하십시오: 

    gitlab-ctl pgb-console # PGBOUNCER_PASSWORD를 입력하라는 프롬프트가 표시됩니다

  7. 콘솔 프롬프트가 표시되면, 다음 쿼리를 실행하십시오: 

    show databases ; show clients ;

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

    ```plaintext 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)

Redis 구성

Redis를 확장 가능한 환경에서는 주 x 복제 형식의 토폴로지와 Redis Sentinel 서비스를 사용하여 장애 조치 절차를 감시하고 자동으로 시작하는 것이 가능합니다.

note
Redis 클러스터는 홀수 개수의 3개 노드 이상으로 각각 배포되어야 합니다. 이는 Redis Sentinel이 쿼럼의 일부로 투표를 할 수 있도록 합니다. 이는 클라우드 제공 업체 서비스와 같은 외부 Redis를 구성하는 경우에는 해당되지 않습니다.
note
Redis는 주로 단일 스레드이며 CPU 코어 수가 증가하더라도 혜택을 거의 받지 못합니다. 이러한 규모의 아키텍처에 대해서는 최적의 성능을 위해 별도의 캐시 및 지속적 인스턴스를 보유하는 것이 강력히 권장됩니다. 자세한 정보는 스케일링 문서를 참조하십시오.

Redis는 Sentinel과 함께 사용될 경우 인증이 필요합니다. 자세한 내용은 Redis 보안 문서를 참조하십시오. Redis 서비스를 안전하게 보호하려면 Redis 패스워드 및 엄격한 방화벽 규칙을 조합하여 사용하는 것을 권장합니다. Redis를 GitLab과 구성하기 전에 Redis Sentinel 문서를 꼭 읽으시기를 권장합니다. 토폴로지와 아키텍처를 완전히 이해하기 위해요.

Redis 설정에 필요한 요구 사항은 다음과 같습니다:

  1. 각 Redis 노드는 서로 통신하고 Redis (6379) 및 Sentinel (26379) 포트로부터의 들어오는 연결을 수락해야 합니다 (기본 포트를 변경하지 않는 이상).
  2. GitLab 애플리케이션을 호스팅하는 서버는 Redis 노드에 접근할 수 있어야 합니다.
  3. 외부 네트워크(예: 인터넷)에서 노드에 접근하는 것을 방지하기 위해 방화벽을 사용해야 합니다.

이 섹션에서는 GitLab에서 사용하기 위해 두 개의 외부 Redis 클러스터를 구성하는 방법에 대해 안내할 것입니다. 다음 IP 주소들이 예시로 사용됩니다:

  • 10.6.0.51: Redis - 캐시 주
  • 10.6.0.52: Redis - 캐시 복제 1
  • 10.6.0.53: Redis - 캐시 복제 2
  • 10.6.0.61: Redis - 지속 주
  • 10.6.0.62: Redis - 지속 복제 1
  • 10.6.0.63: Redis - 지속 복제 2

본인의 Redis 인스턴스 제공

다음 가이드를 따라 Cloud 제공업체 및 서비스에서 자세한 내용을 확인하세요.

Redis 캐시 클러스터 구성

이곳은 새로운 Redis 캐시 인스턴스를 설치하고 설정하는 섹션입니다.

주 및 복제 Redis 노드는 redis['password']에 정의된 동일한 비밀번호가 필요합니다. 장애 조치 중에는 Sentinels가 노드를 다시 구성하고 주요를 복제(또는 그 반대)로 변경할 수 있습니다.

주요 Redis 캐시 노드 구성

  1. Primary Redis 서버에 SSH로 연결합니다.
  2. 선택한 Linux 패키지를 다운로드하고 설치합니다. 페이지에서 설치 단계 1과 2만 따르고, 현재 설치와 동일한 버전 및 유형(Community 또는 Enterprise 버전)의 올바른 Linux 패키지를 선택해야 합니다.

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

    # 서버 역할을 'redis_sentinel_role' 'redis_master_role'로 지정
roles ['redis_sentinel_role', 'redis_master_role', 'consul_role']
   
# Redis Sentinel 서비스의 IP 바인딩 주소 및 Quorum 번호를 설정
sentinel['bind'] = '0.0.0.0'
sentinel['quorum'] = 2
   
# 다른 기기가 연결할 수 있는 로컬 IP를 가리키는 IP 주소
# '0.0.0.0'으로 바인딩하면 모든 인터페이스에서 수신합니다.
# 외부 접근 가능한 IP에 바인딩해야 하는 경우, 무단 접근을 방지하기 위해 추가 방화벽 규칙을 추가합니다.
redis['bind'] = '10.6.0.51'
   
# Redis가 TCP 요청을 수신할 수 있도록 포트 정의
redis['port'] = 6379
   
# Sentinels에 의해 Redis의 상태를 변경할 수 있도록 설정
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'  # Redis에 대한 패스워드 인증 설정(모든 노드에서 동일한 패스워드 사용)
redis['master_name'] = 'gitlab-redis-cache'  # 모든 Redis 노드에서 동일해야 함
redis['master_ip'] = '10.6.0.51'  # 주요 Redis 노드의 IP
redis['maxmemory'] = '13500mb'  # 사용 가능한 RAM의 90%
redis['maxmemory_policy'] = "allkeys-lru"  # Redis 캐시 인스턴스를 LRU로 설정
redis['maxmemory_samples'] = 5  # 최대 메모리 샘플링
   
## Prometheus를 위한 서비스 디스커버리 활성화
consul['monitoring_service_discovery'] =  true
   
## Consul 서버 노드의 IP 주소
## FQDNs을 사용하거나 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.51:6379',
     'redis.password' => 'redis-password-goes-here',
}
   
# 업그레이드 시 자동으로 데이터베이스 마이그레이션 실행 방지
gitlab_rails['auto_migrate'] = false

  4. 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 해당 서버의 동일한 이름의 파일에 추가하거나 교체합니다.

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

복제 Redis Cache 노드 구성

  1. 복제 Redis 서버에 SSH로 연결합니다.
  2. 선택한 Linux 패키지를 다운로드하고 설치합니다. 페이지에서 설치 단계 1과 2만 따르고, 현재 설치와 동일한 버전 및 유형(Community 또는 Enterprise 버전)의 올바른 Linux 패키지를 선택해야 합니다.

  3. /etc/gitlab/gitlab.rb를 편집하고 이전 섹션의 주요 노드와 동일한 내용을 추가하되 redis_master_node를 redis_replica_node로 대체합니다.

  4. 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 해당 서버의 동일한 이름의 파일에 추가하거나 교체합니다.

  5. GitLab을 다시 구성하십시오.

  6. 다른 복제 노드에 대해서도 동일한 단계를 수행하고 IP를 올바르게 설정했는지 확인하세요.

    Redis 설정 옵션은 지원되며 필요한 경우 추가할 수 있습니다.

Redis Persistent 클러스터 구성

이 섹션은 새로운 Redis Persistent 인스턴스를 설치하고 설정하는 곳입니다.

기본 및 복제 Redis 노드는 언제든지 장애 조치(failover) 중에 Sentinel이 노드를 재구성하고 상태를 기본에서 복제(또는 그 반대)로 변경할 수 있는 redis['password']에 정의된 동일한 암호가 필요합니다.

기본 Redis Persistent 노드 구성

  1. 기본 Redis 서버에 SSH로 로그인합니다.
  2. 사용하려는 Linux 패키지를 다운로드 및 설치합니다. 페이지에서 설치 단계 1과 2만 따르고 현재 설치된 것과 동일한 버전과 유형(Community 또는 Enterprise Edition)의 올바른 Linux 패키지를 선택해야 합니다.

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

    # 서버 역할을 'redis_sentinel_role' 및 'redis_master_role', 'consul_role'로 지정
roles ['redis_sentinel_role', 'redis_master_role', 'consul_role']
   
# Redis Sentinel 서비스를 위한 IP 바인드 주소 및 Quorum 번호를 지정
sentinel['bind'] = '0.0.0.0'
sentinel['quorum'] = 2
   
# 다른 기계가 연결할 수 있는 로컬 IP를 가리키는 IP 주소
redis['bind'] = '10.6.0.61'
   
# 다른 기계가 이에 연결할 수 있도록 Redis가 TCP 요청을 수신할 수 있게 포트를 정의
redis['port'] = 6379
   
## Sentinel을 위한 기본 Redis 서버의 포트, 기본 설정에서 벗어난 경우 주석 해제. 기본값은 `6379` 입니다.
#redis['master_port'] = 6379
   
# Redis 및 복제본에 대한 암호 인증 설정 (모든 노드에서 동일한 암호 사용)
redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
   
## 모든 Redis 노드에서 동일해야 함
redis['master_name'] = 'gitlab-redis-persistent'
   
## 기본 Redis 노드의 IP 주소
redis['master_ip'] = '10.6.0.61'
   
## 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'
redis_exporter['listen_address'] = '0.0.0.0:9121'
   
# 업그레이드 시 자동으로 데이터베이스 마이그레이션을 방지
gitlab_rails['auto_migrate'] = false

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

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

복제 Redis Persistent 노드 구성

  1. 복제 Redis Persistent 서버에 SSH로 로그인합니다.
  2. 사용하려는 Linux 패키지를 다운로드 및 설치합니다. 페이지에서 설치 단계 1과 2만 따르고 현재 설치된 것과 동일한 버전과 유형(Community 또는 Enterprise Edition)의 올바른 Linux 패키지를 선택해야 합니다.

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

    # 서버 역할을 'redis_sentinel_role' 및 'redis_replica_role', 'consul_role'로 지정
roles ['redis_sentinel_role', 'redis_replica_role', 'consul_role']
   
# Redis Sentinel 서비스를 위한 IP 바인드 주소 및 Quorum 번호를 지정
sentinel['bind'] = '0.0.0.0'
sentinel['quorum'] = 2
   
# 다른 기계가 연결할 수 있는 로컬 IP를 가리키는 IP 주소
redis['bind'] = '10.6.0.62'
   
# 다른 기계가 이에 연결할 수 있도록 Redis가 TCP 요청을 수신할 수 있게 포트를 정의
redis['port'] = 6379
   
## Sentinel을 위한 기본 Redis 서버의 포트, 기본 설정에서 벗어난 경우 주석 해제. 기본값은 `6379` 입니다.
#redis['master_port'] = 6379
   
# Redis 인증을 위해 기본 노드에 설정한 동일한 암호
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
   
## 모든 Redis 노드에서 동일해야 함
redis['master_name'] = 'gitlab-redis-persistent'
   
# 기본 Redis 노드의 IP
redis['master_ip'] = '10.6.0.61'
   
## 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'
redis_exporter['listen_address'] = '0.0.0.0:9121'
redis_exporter['flags'] = {
     'redis.addr' => 'redis://10.6.0.62:6379',
     'redis.password' => 'redis-password-goes-here',
}
   
# 업그레이드 시 자동으로 데이터베이스 마이그레이션을 방지
gitlab_rails['auto_migrate'] = false

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

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

  6. 다른 복제 노드에 대해 다시 모든 단계를 거치고 IP를 올바르게 설정했는지 확인합니다.

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

Gitaly 클러스터 구성

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

caution
Gitaly 사양은 사용 패턴 및 리포지터리 크기의 고 백분위에 기반합니다. 그러나 큰 단일 리포지터리(몇 기가바이트보다 큰) 또는 추가 작업량이 있는 경우 환경의 성능에 의미있는 영향을 줄 수 있습니다. 해당하는 경우 연결된 문서를 참조하거나 고객 성공 관리자 또는 지원팀에 문의하는 것이 강력히 권장됩니다.

Praefect PostgreSQL 구성

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

고가용성 설치를 원하는 경우, Praefect에게는 타사 PostgreSQL 데이터베이스가 필요합니다. 내장 솔루션이 작업 중입니다.

Praefect 고가용성이 없는 PostgreSQL 단독 사용을 위한 Linux 패키지

다음 IP가 예제로 사용됩니다.

  • 10.6.0.141: Praefect PostgreSQL

먼저, Praefect PostgreSQL 노드에서 Linux 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 섹션에 적시된 값으로 대체합니다. 

    # Disable all components except PostgreSQL and Consul
roles(['postgres_role', 'consul_role'])
   
# PostgreSQL configuration
postgresql['listen_address'] = '0.0.0.0'
   
# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false
   
# Configure the Consul agent
## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] =  true
   
# START user configuration
# Please set the real values as explained in Required Information section
#
# Replace PRAEFECT_POSTGRESQL_PASSWORD_HASH with a generated md5 value
postgresql['sql_user_password'] = "<praefect_postgresql_password_hash>"
   
# Replace XXX.XXX.XXX.XXX/YY with Network Address
postgresql['trust_auth_cidr_addresses'] = %w(10.6.0.0/24 127.0.0.1/32)
   
# Set the network addresses that the exporters will listen on for monitoring
node_exporter['listen_address'] = '0.0.0.0:9100'
postgres_exporter['listen_address'] = '0.0.0.0:9187'
   
## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
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 타사 솔루션

Praefect PostgreSQL 구성에서 언급된 대로, 고가용성을 지향하는 경우 Praefect의 데이터베이스에 대해 타사 PostgreSQL 솔루션이 권장됩니다.

PostgreSQL HA를 위한 여러 타사 솔루션이 있습니다. Praefect와 함께 사용하려면 다음이 필요합니다.

  • 장애 조치(failover) 시 변경되지 않는 모든 연결을 위한 고정 IP.
  • LISTEN SQL 기능을 지원해야 함.
note
타사 설정으로, 편의상 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>로 설정한 것과 동일합니다.

Linux 패키지 PostgreSQL 설정에서는 다음과 같이 작동합니다.

  1. Praefect PostgreSQL 노드에 SSH로 로그인합니다.

  2. 관리 권한으로 PostgreSQL 서버에 연결합니다. 이때, 이는 Linux 패키지에서 기본적으로 추가되는 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개 이상의 홀수 개의 노드에 배포되어야 합니다.

Praefect는 클러스터 내 통신을 안전하게 하기 위해 몇 가지 비공개 토큰이 필요합니다:

  • <praefect_external_token>: Gitaly 클러스터에 호스트되는 리포지터리에 사용되며, 이 토큰을 지닌 Gitaly 클라이언트만 액세스할 수 있습니다.
  • <praefect_internal_token>: Gitaly 클러스터 내부의 복제 트래픽에 사용됩니다. 이는 praefect_external_token과는 다르며, Gitaly 클라이언트는 Praefect 클러스터의 내부 노드에 직접 액세스하지 못해야 합니다. 그렇게 할 경우 데이터 손실이 발생할 수 있습니다.
  • <praefect_postgresql_password>: 이전 섹션에서 정의한 Praefect PostgreSQL 암호도 이 설정에서 필요합니다.

Gitaly 클러스터 노드들은 가상 스토리지를 통해 Praefect로 구성되었습니다. 각 스토리지에는 클러스터를 구성하는 각 Gitaly 노드의 세부 정보가 포함되어 있습니다. 또한, 각 스토리지에는 이름이 지정되며, 이 이름은 설정의 여러 영역에서 사용됩니다. 이 가이드에서는 스토리지의 이름을 default로 지정할 것입니다. 또한, 이 가이드는 새로운 설치를 기반으로 하고 있으므로, 기존 환경을 Gitaly 클러스터를 사용하도록 업그레이드할 경우 다른 이름을 사용해야 할 수도 있습니다. 더 많은 정보는 Praefect 문서를 참조하십시오.

다음 IP가 예제로 사용됩니다.

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

Praefect 노드를 구성하려면 각 노드에서:

  1. Praefect 서버에 SSH로 로그인합니다.
  2. 원하는 Linux 패키지를 다운로드 및 설치합니다. 페이지에서 설치 단계 1과 2만 따르십시오.

  3. Praefect를 구성하기 위해 /etc/gitlab/gitlab.rb 파일을 수정하십시오:

    note
    여기서 default 항목은 GitLab이 필요로 한다고합니다.
    # 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
   
# Prevent database migrations from running on upgrade automatically
praefect['auto_migrate'] = false
gitlab_rails['auto_migrate'] = false
   
# Configure the Consul agent
consul['enable'] = true
## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] = true
   
# START user configuration
# Please set the real values as explained in Required Information section
#
   
praefect['configuration'] = {
   # ...
   listen_addr: '0.0.0.0:2305',
   auth: {
     # ...
     #
     # Praefect 외부 토큰
     # 이는 클러스터 외부(예: GitLab Shell과 같은) 클라이언트가 Praefect 클러스터와 통신하는 데 필요합니다
     token: '<praefect_external_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_postgresql_password>',
     },
   },
   # Praefect 가상 스토리지 구성
   # 스토리지 이름 해시는 GitLab의 git_data_dirs 서버('praefect') 및 Gitaly 노드('gitaly-1')에서 설정하는 스토리지 이름과 일치해야 합니다.
   virtual_storage: [
      {
         # ...
         name: 'default',
         node: [
            {
               storage: 'gitaly-1',
               address: 'tcp://10.6.0.91:8075',
               token: '<praefect_internal_token>'
            },
            {
               storage: 'gitaly-2',
               address: 'tcp://10.6.0.92:8075',
               token: '<praefect_internal_token>'
            },
            {
               storage: 'gitaly-3',
               address: 'tcp://10.6.0.93:8075',
               token: '<praefect_internal_token>'
            },
         ],
      },
   ],
   # 모니터링을 위해 Praefect가 청취할 네트워크 주소 설정
   prometheus_listen_addr: '0.0.0.0:9652',
}
   
# 모니터링을 위해 노드 익스포터가 청취할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
   
## Consul 서버 노드의 IP
## FQDN을 사용하거나 IP와 함께 혼용할 수 있음
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
#
# END user configuration
  4. 처음 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 같은 파일에 추가하거

Gitaly 구성

클러스터를 구성하는 Gitaly 서버 노드는 데이터 및 부하에 따라 요구 사항이 달라집니다.

caution
Gitaly 사양은 사용 패턴 및 리포지터리 크기의 고 백분위수에 기반합니다. 그러나 대형 단일 리포지터리(large monorepos) (여러 기가바이트보다 큼) 또는 추가 작업이 있을 경우 이는 환경의 성능에 큰 영향을 미칠 수 있으며 추가적인 조정이 필요할 수 있습니다. 이 경우 해당 문서를 참조하거나 추가 지침이 필요하면 고객 성공 관리자나 지원팀에 문의하는 것이 좋습니다.

Gitaly는 중요한 입력 및 출력 요구 사항이 있으므로 모든 Gitaly 노드가 고정 디스크 드라이브(SSD)를 사용하는 것이 좋습니다. 이 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. 선택한 Linux 패키지의 다운로드 및 설치를 진행하십시오. 해당 페이지에서 설치 단계 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을 사용하거나 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 Auth 토큰
      # praefect_internal_token과 동일해야 합니다
      token: '<praefect_internal_token>',
   },
   pack_objects_cache: {
      # Gitaly 팩-오브젝트 캐시
      # 성능 향상을 위해 활성화하는 것이 좋지만 디스크 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. 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 같은 이름의 파일을 추가하거나 교체하십시오. 이 서버를 구성하는 첫 번째 Linux 패키지 노드인 경우 이 단계를 건너뛸 수 있습니다.

  5. 파일을 저장한 후 GitLab 재구성을 수행하십시오.

Gitaly 클러스터 TLS 지원

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

  • GitLab 구성의 해당 리포지터리 항목의 gitaly_address에서 tls:// URL scheme을 사용해야 합니다.
  • 자동으로 제공되지 않기 때문에 각 Praefect 서버에 해당하는 인증서를 제공해야 합니다. 각 Praefect 서버에 해당하는 인증서도 설치해야 합니다.

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

다음을 참고하십시오:

  • 해당 인증서는 Praefect 서버에 액세스하는 데 사용하는 주소를 지정해야 합니다. 인증서에 대상 대체 이름(Subject Alternative Name)으로 호스트 이름 또는 IP 주소를 추가해야 합니다.
  • 필요한 경우 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 인스턴스에 연결해야 합니다. 또한 권장 사항으로 객체 리포지터리에 연결해야 합니다.

note
데이터 객체에 대해 NFS 대신 객체 리포지터리를 사용하는 것이 권장되므로, 다음 예제에는 객체 리포지터리 구성이 포함됩니다.
note
환경의 Sidekiq 작업 처리가 대기열이 길어 느린 경우 해당 환경을 적정하게 확장할 수 있습니다. 자세한 내용은 확장 설명서를 참조하세요.
  • 10.6.0.101: Sidekiq 1
  • 10.6.0.102: Sidekiq 2
  • 10.6.0.103: Sidekiq 3
  • 10.6.0.104: Sidekiq 4

Sidekiq 노드를 구성하려면 각 노드에서 다음을 수행하십시오:

  1. Sidekiq 서버에 SSH로 로그인합니다.
  2. 선호하는 Linux 패키지를 다운로드하고 설치합니다. 페이지의 설치 단계 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 연결 세부 정보
## 캐시 데이터를 보관할 첫 번째 클러스터
gitlab_rails['redis_cache_instance'] = 'redis://:<REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER>@gitlab-redis-cache'
   
gitlab_rails['redis_cache_sentinels'] = [
  {host: '10.6.0.51', port: 26379},
  {host: '10.6.0.52', port: 26379},
  {host: '10.6.0.53', port: 26379},
]
   
## 모든 기타 영구 데이터를 저장하는 두 번째 클러스터
redis['master_name'] = 'gitlab-redis-persistent'
redis['master_password'] = '<REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER>'
   
gitlab_rails['redis_sentinels'] = [
  {host: '10.6.0.61', port: 26379},
  {host: '10.6.0.62', port: 26379},
  {host: '10.6.0.63', 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.20' # 내부 로드 밸런서 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.151/32', '127.0.0.0/8']
   
# 객체 리포지터리
# GCP에 대한 객체 리포지터리 구성 예시
# 이 구성은 원하는 객체 리포지터리 제공업체 구성으로 대체합니다
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. 구성한 첫 번째 Linux 패키지 노드의 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 동일한 이름의 파일에 추가하거나 덮어씁니다. 이것이 구성하는 첫 번째 Linux 패키지 노드라면 이 단계를 건너뛸 수 있습니다.

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

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

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

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

GitLab Rails 구성

이 섹션에서는 GitLab 애플리케이션 (Rails) 구성 방법을 설명합니다.

Rails는 Redis, PostgreSQL, Gitaly 인스턴스에 대한 연결이 필요합니다. 또한 객체 리포지터리에 대한 연결이 권장됩니다.

note
데이터 객체에 대해 NFS 대신 객체 리포지터리를 사용하는 것이 권장되므로, 다음 예제는 객체 리포지터리 구성을 포함합니다.

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

  • 10.6.0.111: GitLab 애플리케이션 1
  • 10.6.0.112: GitLab 애플리케이션 2
  • 10.6.0.113: GitLab 애플리케이션 3
  • 10.6.0.114: GitLab 애플리케이션 4
  • 10.6.0.115: GitLab 애플리케이션 5

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

  1. 선택한 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", # 내부 로드 밸런서 IP
    "gitaly_token" => '<praefect_external_token>'
  }
})
   
## 애플리케이션 서버에 없을 컴포넌트 비활성화
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' # 내부 로드 밸런서 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 연결 세부 정보
## 캐시 데이터를 저장할 첫 번째 클러스터
gitlab_rails['redis_cache_instance'] = 'redis://:<REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER>@gitlab-redis-cache'
   
gitlab_rails['redis_cache_sentinels'] = [
  {host: '10.6.0.51', port: 26379},
  {host: '10.6.0.52', port: 26379},
  {host: '10.6.0.53', port: 26379},
]
   
## 다른 영속 데이터를 호스팅하는 두 번째 클러스터
redis['master_name'] = 'gitlab-redis-persistent'
redis['master_password'] = '<REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER>'
   
gitlab_rails['redis_sentinels'] = [
  {host: '10.6.0.61', port: 26379},
  {host: '10.6.0.62', port: 26379},
  {host: '10.6.0.63', port: 26379},
]
   
# 모니터링에 사용되는 수집기가 수신 대기할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
gitlab_workhorse['prometheus_listen_addr'] = '0.0.0.0:9229'
puma['listen'] = '0.0.0.0'
   
# 모니터링 노드의 IP 주소를 디렉터리에 추가하고 NGINX 메트릭을 스크랩할 수 있도록 허용
gitlab_rails['monitoring_whitelist'] = ['10.6.0.151/32', '127.0.0.0/8']
nginx['status']['options']['allow'] = ['10.6.0.151/32', '127.0.0.0/8']
   
#############################
###     객체 리포지터리     ###
#############################
   
# GCP에 객체 리포지터리를 구성하는 예시
# 이 구성은 원하는 객체 리포지터리 공급자로 대체하세요
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. TLS 지원이 포함된 Gitaly를 사용하는 경우, git_data_dirs 항목이 tcp 대신 tls로 구성되었는지 확인하세요: 

    git_data_dirs({
  "default" => {
    "gitaly_address" => "tls://10.6.0.40:2305", # 내부 로드 밸런서 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 사후 구성 섹션에서 설명된 대로, 지정된 노드만 마이그레이션을 처리해야합니다.

  7. 변경 사항이 적용되려면 GitLab을 재구성하세요.
  8. 증분 로깅을 활성화하세요.

  9. Gitaly에 연결할 수 있는지 확인하세요: 

    sudo gitlab-rake gitlab:gitaly:check

    그런 다음 요청을 확인하기 위해 로그를 확인하세요: 

    sudo gitlab-ctl tail gitaly
  10. 옵션으로, Gitaly 서버에서 Gitaly가 내부 API에 콜백을 수행할 수 있는지 확인하세요:
    • GitLab 15.3 이상의 경우, sudo /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml를 실행합니다.
    • GitLab 15.2 이하의 경우, sudo /opt/gitlab/embedded/bin/gitaly-hooks check /var/opt/gitlab/gitaly/config.toml을 실행합니다.

이전 예제와 같이 external_url에 https를 지정하는 경우, GitLab은 SSL 인증서가 /etc/gitlab/ssl/에 있는 것으로 예상합니다. 인증서가 없으면 NGINX가 시작하지 못할 수 있습니다. 자세한 정보는 HTTPS 문서를 참조하세요.

GitLab Rails 포스트 구성

  1. 설치 및 업데이트 중에 데이터베이스 마이그레이션을 실행할 응용 프로그램 노드를 지정합니다. GitLab 데이터베이스를 초기화하고 모든 마이그레이션이 실행되었는지 확인하세요: 
sudo gitlab-rake gitlab:db:configure

주의: 이 작업은 Rails 노드가 기본 데이터베이스에 직접 연결되도록 구성되어 있어야 합니다. 마이그레이션이 완료된 후 노드를 다시 PgBouncer를 통과하도록 구성해야 합니다.

  1. 데이터베이스에서 사용자 SSH 키를 빠르게 조회하도록 구성하세요.

프로메테우스 구성

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

다음 IP는 예제로 사용됩니다:

  • 10.6.0.151: 프로메테우스

모니터링 노드를 구성하려면:

  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 재구성을 실행하세요.

객체 리포지터리 구성

GitLab은 많은 유형의 데이터를 보관하기 위해 객체 리포지터리 서비스 사용을 지원합니다. 이는 데이터 객체와 관련하여 NFS에 비해 근본적으로 더 우수하며 일반적으로 더 효율적이고 안정적이며 확장 가능합니다. 자세한 내용은 권장 클라우드 제공 업체 및 서비스를 참조하세요.

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

켄티지 형식은 사용 가능한 경우 다음 예제에서 사용되었습니다.

각 데이터 유형에 대해 별도의 버킷을 사용하는 것이 GitLab의 권장 접근 방식입니다. 이렇게 하면 GitLab이 저장하는 다양한 유형의 데이터 간에 충돌이 없도록 보장할 수 있습니다. 미래에는 하나의 버킷을 사용하는 것이 가능할 예정입니다.

증분적 로깅 활성화

GitLab Runner는 기본적으로 Linux 패키지를 사용하여 작업 로그를 일시적으로 /var/opt/gitlab/gitlab-ci/builds 디렉터리에 캐시합니다. 이 디렉터리는 NFS 노드를 사용하지 않을 때에도 증분 로깅을 활성화하는 것이 권장됩니다. 증분 로깅은 작업 로그의 임시 캐싱을 디스크 공간이 아닌 Redis를 사용하여 실행합니다.

작업 로그를 NFS를 통해 공유하는 것은 지원되지만, NFS 노드를 배포하지 않을 때 증분 로깅을 활성화하는 것이 권장됩니다. 증분 로깅을 사용하면 디스크 공간 대신 Redis를 사용하여 작업 로그를 임시로 캐싱할 수 있습니다.

고급 검색 구성

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

Elasticsearch 클러스터 설계 및 요구 사항은 특정한 데이터에 따라 다릅니다. 인스턴스와 함께 Elasticsearch 클러스터를 설정하는 권장 사항에 대한 자세한 내용은 최적의 클러스터 구성 선택에 관한 안내를 참조하세요.

Helm 차트로 클라우드 네이티브 하이브리드 참조 아키텍처 (대안)

Kubernetes에서 GitLab Helm 차트를 사용하여 클라우드 네이티브 GitLab의 일부 컴포넌트를 실행할 수 있습니다. 이러한 구성에서 Webservice라는 Kubernetes 클러스터에서 GitLab Rails를 실행할 수 있습니다. 또한 Sidekiq라는 Kubernetes 클러스터에서 GitLab의 Sidekiq 노드를 실행할 수 있습니다. 또한 NGINX, Toolbox, 마이그레이션, 프로메테우스 및 Grafana와 같은 기타 지원 서비스가 지원됩니다.

하이브리드 설치는 클라우드 네이티브 워크로드 관리 장점을 획득하되 상태를 유지할 수 있는 전통적인 컴퓨팅 배포의 이점을 활용합니다.

Kubernetes에서 서비스를 실행하는 것은 복잡한 과정으로 알려져 있으므로는 진보된 설정입니다. 이 설정은 Kubernetes에 대한 견고한 지식과 경험을 갖고 있는 경우에만 권장됩니다. 이하의 내용은 이를 전제로 합니다.

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

클러스터 토폴로지

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

먼저 여러 노드 그룹에 실행되는 Kubernetes 컴포넌트를 살펴보겠습니다. 전체적인 구성은 최소 CPU 및 메모리 요구 사항을 준수하는 한 원하는 대로 조절할 수 있습니다.

컴포넌트 노드 그룹 목표 노드 풀 총계 GCP 예시 AWS 예시
Webservice 140 vCPU
175 GB 메모리 (요청)
245 GB 메모리 (제한) 		5 x n1-standard-32 5 x c5.9xlarge
Sidekiq 12.6 vCPU
28 GB 메모리 (요청)
56 GB 메모리 (제한) 		4 x n1-standard-4 4 x m5.xlarge
지원 서비스 4 vCPU
15 GB 메모리 		2 x n1-standard-4 2 x m5.xlarge
  • 이러한 구성에서는 Google Kubernetes Engine (GKE) 및 Amazon Elastic Kubernetes Service (EKS)를 사용하는 것이 권장되며 테스트하고 있는 것이죠. 다른 Kubernetes 서비스도 사용할 수 있지만 결과는 달라질 수 있습니다.
  • GCP 및 AWS 예시는 목표 노드 풀 총계에 도달하는 방법을 편리하게 보여줍니다. 이러한 크기는 성능 테스트에 사용되었지만 일치시킬 필요는 없습니다. 대상에 도달하고 모든 pod을 배포할 수 있는 다양한 노드 풀 디자인을 사용할 수 있습니다.
  • Webservice 및 Sidekiq 목표 노드 풀 총계는 GitLab 컴포넌트에 대한 것입니다. 선택한 Kubernetes 공급자의 시스템 프로세스에 필요한 추가 리소스가 필요합니다. 여기에 대한 예시도 고려되어야 합니다.
  • 지원 목표 노드 풀 총계는 GitLab 배포를 지원하고 추가적인 필요에 따라 추가적인 배포를 위한 다양한 자원을 수용하기 위한 것입니다. 다른 노드 풀과 마찬가지로 선택한 Kubernetes 공급자의 시스템 프로세스도 필요합니다. 여기에 대한 예시도 고려되어야 합니다.
  • 프로덕션 배포에서 파드를 특정 노드에 할당할 필요는 없지만 복원력 있는 클라우드 아키텍처 관행을 준수하기 위해 각각의 풀에 여러 노드가 다른 가용성 영역에 걸쳐 배포될 수 있도록 하는 것이 권장됩니다.
  • 클러스터 오토스케일링(CA)을 활성화하여 효율성을 높이는 것이 권장되지만 보통 Webservice 및 Sidekiq 파드에 대한 최소값을 75%로 지정하여 계속해서 성능을 보장하는 것이 권장됩니다.

다음으로 Linux 패키지를 사용하는 정적 컴퓨팅 VM에서 실행되는 백엔드 컴포넌트를 살펴보겠습니다 (또는 해당되는 경우 외부 PaaS 서비스):

서비스 노드 구성 GCP AWS
Consul1 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large
PostgreSQL1 3 16 vCPU, 60 GB 메모리 n1-standard-16 m5.4xlarge
PgBouncer1 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large
내부 로드 밸런서3 1 8 vCPU, 7.2 GB 메모리 n1-highcpu-8 c5.2xlarge
Redis/Sentinel - Cache2 3 4 vCPU, 15 GB 메모리 n1-standard-4 m5.xlarge
Redis/Sentinel - Persistent2 3 4 vCPU, 15 GB 메모리 n1-standard-4 m5.xlarge
Gitaly5 3 32 vCPU, 120 GB 메모리6 n1-standard-32 m5.8xlarge
Praefect5 3 4 vCPU, 3.6 GB 메모리 n1-highcpu-4 c5.xlarge
Praefect PostgreSQL1 1+ 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large
객체 리포지터리4 - - - -

각주:

  1. 신뢰할 수 있는 타사 외부 PaaS PostgreSQL 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 본인의 PostgreSQL 인스턴스 제공를 참조하세요.
  2. 신뢰할 수 있는 타사 외부 PaaS Redis 솔루션에서 선택적으로 실행할 수 있습니다. 자세한

Kubernetes 구성요소 대상

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

Webservice

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

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

500 RPS 또는 25,000 사용자를 위해 약 140개의 총 Puma worker 카운트를 권장하므로 결과적으로 적어도 35개의 Webservice pod를 실행하는 것이 권장됩니다.

Webservice 리소스 사용에 대한 자세한 정보는 Webservice resources의 차트 문서를 참조하세요.

NGINX

Webservice 노드 전체에 NGINX 컨트롤러 pod를 데몬셋으로 배포하는 것이 좋습니다. 이는 컨트롤러가 제공하는 Webservice pod와 동적으로 확장하고 일반적으로 큰 기계 유형의 높은 네트워크 대역폭을 활용할 수 있도록합니다.

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

Sidekiq

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

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

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

Sidekiq 리소스 사용에 대한 자세한 정보는 Sidekiq resources의 차트 문서를 참조하세요.

지원

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

이에는 클라우드 제공 업체의 구현 및 GitLab Shell과 같이 GitLab 배포에 관련된 여러 배포물이 포함됩니다.

컨테이너 레지스트리, 페이지 또는 모니터링과 같이 추가적인 배포물을 원하는 경우 가능한 경우 이러한 배포물을이 풀에 배포하는 것이 좋습니다. 그렇지 않으면 지원 풀은 명시적으로 여러 추가 배포를 수용할 수 있도록 설계되었기 때문에 Webservice 또는 Sidekiq 풀에 배포하지 않는 것이 좋습니다. 그러나 사용 사례에 해당하는 풀이 제공된 것보다 큰 경우 노드 풀을 증가시킬 수 있습니다. 반대로 사용 사례에서 풀이 과다 구성된 경우 그에 맞게 줄일 수 있습니다.

예제 구성 파일

위의 500 RPS 또는 25,000 참조 아키텍처 구성을 대상으로 한 GitLab Helm Charts의 예제는 Charts 프로젝트에서 찾을 수 있습니다.