참조 아키텍처: 최대 1000 RPS 또는 50,000 사용자까지 지원

Tier: Premium, Ultimate Offering: Self-Managed

이 페이지는 실제 데이터를 기반으로 최대 초당 1000개의 요청(RPS)과 최대 50,000명의 사용자(매뉴얼 및 자동)에 대한 일반적인 최대 부하를 대상으로 설계된 GitLab 참조 아키텍처를 설명합니다.

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

note
이 아키텍처를 배포하기 전에 먼저 주요 설명서를 읽는 것이 좋습니다. 특히 시작하기 전에 및 사용할 아키텍처 결정 섹션을 참조하십시오.
서비스 노드 수 구성 GCP AWS Azure
외부 로드 밸런서3 1 16 vCPU, 14.4 GB 메모리 n1-highcpu-16 c5.4xlarge F16s v2
Consul1 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large F2s v2
PostgreSQL1 3 32 vCPU, 120 GB 메모리 n1-standard-32 m5.8xlarge D32s v3
PgBouncer1 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large F2s v2
내부 로드 밸런서3 1 16 vCPU, 14.4 GB 메모리 n1-highcpu-16 c5.4xlarge F16s v2
Redis/Sentinel - 캐시2 3 4 vCPU, 15 GB 메모리 n1-standard-4 m5.xlarge D4s v3
Redis/Sentinel - 지속적2 3 4 vCPU, 15 GB 메모리 n1-standard-4 m5.xlarge D4s v3
Gitaly5 3 64 vCPU, 240 GB 메모리6 n1-standard-64 m5.16xlarge D64s 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 12 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 코어 증가로 크게 이점을 얻지 못합니다. 이런 규모의 아키텍처에는 최적의 성능을 위해 별도의 캐시 및 지속적인 인스턴스가 필요합니다.
  3. 신뢰할 수 있는 써드파티 로드 밸런싱 서비스(LB PaaS)에서 선택적으로 실행할 수 있습니다. 자세한 내용은 권장 클라우드 제공업체 및 서비스 사용를 참조하십시오.
  4. 신뢰할 수 있는 클라우드 제공업체 또는 Self-Managed형 솔루션에서 실행해야 합니다. 자세한 내용은 객체 리포지터리 구성를 참조하십시오.
  5. Gitaly 클러스터는 장애 허용성의 이점을 제공하지만 추가 복잡성이 따릅니다. Gitaly 클러스터를 배포하기 전에 Gitaly 클러스터 배포 전 기술적 제한사항 및 고려 사항을 검토하십시오. 샤딩된 Gitaly를 사용하려면 ‘Gitaly’에 나열된 스펙과 동일한 스펙을 사용하십시오.
  6. Gitaly 사양은 건강한 상태의 리포지터리 크기와 사용 패턴의 고 비밀도 백분위수를 기반으로 합니다. 그러나 큰 모노 리포(몇 기가바이트보다 큰)나 추가 작업부하가 있을 경우 Git 및 Gitaly 성능에 많은 영향을 미치며 추가 조정이 필요할 수 있습니다.
  7. 컴포넌트가 상태 데이터를 저장하지 않음으로 ASG(Auto Scaling Groups)에 배치할 수 있습니다. 그러나 클라우드 네이티브 하이브리드 설정은 일반적으로 특정 컴포넌트 (예: 이주 및 Mailroom)가 하나의 노드에서만 실행될 수 있다는 점 때문에 더 나은 쿠버네티스에서 처리됩니다.
note
PaaS 솔루션의 경우 인스턴스 구성이 관련되므로 신뢰할 수 있는 클라우드 아키텍처 관행에 맞추기 위해 최소 세 가지 노드를 세 가지 다른 가용성 영역에 구현하는 것이 좋습니다.

요구 사항

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

테스트 방법론

50k 아키텍처는 대부분의 워크플로를 커버하도록 설계되었으며 정기적으로 흡연 및 성능 테스트가 이루어지며 다음 엔드포인트 처리량 목표에 대해 Test Platform 팀에서 테스트합니다.

  • API: 1000 RPS
  • 웹: 100 RPS
  • Git (Pull): 100 RPS
  • Git (Push): 20 RPS

위의 목표는 사용자 수에 해당하는 실제 고객 데이터를 기반으로 선택되었으며, CI 및 기타 워크로드를 포함합니다.

위의 엔드포인트 목표에 대해 정기적으로 더 높은 처리량을 갖고 있다고 증명하는 메트릭이 있는 경우, 대형 모노 리포를 사용하거나 명백한 추가 워크로드가 있다면, 성능 환경에 주목할 수 있으며 추가 조정이 필요할 수 있습니다. 해당 사항이 해당되는 경우 연관된 문서를 참조하고 더 나아가 고객 성공 관리자 또는 지원 팀에게 문의하여 추가 지침을 받는 것이 강력히 권장됩니다.

테스트는 정기적으로 GitLab 성능 도구 (GPT)와 해당 데이터 세트를 통해 수행되며, 이러한 테스트의 결과는 GPT 위키에서 공개적으로 사용 가능합니다. 테스트 전략에 대한 자세한 정보는 문서의 이 섹션을 참조하세요.

테스트에 사용된 로드 밸런서는 리눅스 패키지 환경의 경우 HAProxy 또는 클라우드 네이티브 하이브리드의 경우 해당 클라우드 제공자 서비스를 이용했습니다. 이러한 선택은 특정 요구 사항이나 권장에서 벗어난 것이 아니며 대부분 신뢰할 수 있는 로드 밸런서가 작동할 것으로 기대됩니다.

구성 컴포넌트

GitLab 및 해당 컴포넌트를 설정하여 최대 1000 RPS 또는 50,000 사용자를 수용하도록 설정하려면:

  1. 외부 로드 밸런서 구성
    • GitLab 응용 프로그램 서비스 노드의 로드 밸런싱을 처리하도록합니다.
  2. 내부 로드 밸런서 구성
    • GitLab 응용 프로그램 내부 연결의 로드 밸런싱을 처리하도록합니다.
  3. Consul 구성.
  4. PostgreSQL 구성, GitLab용 데이터베이스.
  5. PgBouncer 구성.
  6. Redis 구성.
  7. Gitaly Cluster 구성,
    • Git 리포지터리에 대한 액세스를 제공합니다.
  8. Sidekiq 구성.
  9. GitLab 메인 Rails 응용 프로그램 구성
    • Puma, Workhorse, GitLab Shell을 실행하고 UI, API 및 HTTP/SSH를 포함하는 모든 프론트엔드 요청을 처리하도록합니다.
  10. Prometheus 구성, GitLab 환경 모니터링.
  11. 객체 리포지터리 구성
    • 공유 데이터 객체에 사용됩니다.
  12. 고급 검색 구성 (선택 사항)
    • 전체 GitLab 인스턴스에서 더 빠르고 고급 코드 검색을 위해 사용합니다.

서버는 동일한 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.141: 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.116: GitLab 응용 프로그램 6
  • 10.6.0.117: GitLab 응용 프로그램 7
  • 10.6.0.118: GitLab 응용 프로그램 8
  • 10.6.0.119: GitLab 응용 프로그램 9
  • 10.6.0.120: GitLab 응용 프로그램 10
  • 10.6.0.121: GitLab 응용 프로그램 11
  • 10.6.0.122: GitLab 응용 프로그램 12
  • 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 호밥-바-호 프로토콜을 통과해야합니다. 자세한 내용은 웹 터미널 통합 가이드를 참조하세요.
  • (2): 포트 443에 HTTPS 프로토콜을 사용하는 경우 로드 밸런서에 SSL 인증서를 추가해야합니다. GitLab 응용 프로그램 서버에서 SSL을 종료시키려면 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을 종료함

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

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

로드 밸런서가 백엔드 SSL 없이 SSL을 종료함

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

로드 밸런서와 GitLab 간 통신이 안전하지 않으므로 추가 구성이 필요합니다. 자세한 정보는 프록시된 SSL 문서를 참조하세요.

로드 밸런서가 백엔드 SSL과 함께 SSL을 종료함

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

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

내부 로드 밸런서 구성

다중 노드 GitLab 구성에서 특정 내부 구성요소의 트래픽을 라우팅하기 위해 내부 로드 밸런서가 필요할 수 있습니다. 예를 들어 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. 선택한 리눅스의 다운로드 및 설치를 수행하세요. 페이지의 설치 단계 1과 2만 따르고 현재 설치한 것과 동일한 버전 및 타입(커뮤니티 또는 엔터프라이즈 버전)의 올바른 리눅스 패키지를 선택하세요.

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

  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 패키지 구성은 다음과 같습니다.

  • 최소 세 개의 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 패키지 리포지터리를 추가하세요. 두 번째 단계에서 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`를 클러스터의 복제 슬롯 수보다 하나 더 설정합니다.
# 이는 모든 가능한 데이터베이스 연결이 복제에 사용되는 것을 방지하기 위해 사용됩니다.
patroni['postgresql']['max_wal_senders'] = 7
   
# 업그레이드시 데이터베이스 마이그레이션 자동 실행하지 않도록 설정
gitlab_rails['auto_migrate'] = false
   
# Consul 에이전트 설정
consul['enable'] = true
consul['services'] = %w(postgresql)
## Prometheus를 위한 서비스 검색을 활성화합니다
consul['monitoring_service_discovery'] =  true
   
# START 사용자 구성
# 필요한 정보 섹션에 설명된 대로 실제 값을 설정하십시오
#
# PGBOUNCER_PASSWORD_HASH를 생성된 md5 값을 대체합니다
postgresql['pgbouncer_user_password'] = '<pgbouncer_password_hash>'
# POSTGRESQL_REPLICATION_PASSWORD_HASH를 생성된 md5 값을 대체합니다
postgresql['sql_replication_password'] = '<postgresql_replication_password_hash>'
# POSTGRESQL_PASSWORD_HASH를 생성된 md5 값을 대체합니다
postgresql['sql_user_password'] = '<postgresql_password_hash>'
   
# Patroni API에 대한 기본 인증 설정(모든 노드에서 동일한 사용자 이름/암호를 사용합니다).
patroni['username'] = '<patroni_api_username>'
patroni['password'] = '<patroni_api_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: '<pgbouncer_password_hash>'
   }
}
   
# 모니터링을 위해 수신 대기하는 익스포터의 네트워크 주소 설정
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가 장애 조치를 관리하는 PostgreSQL은 기본적으로 충돌을 다루기 위해 기본적으로 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         | *               |

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

  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 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 인스턴스 제공

다음 안내에 따라 Redis 캐시 및 유지 관리 인스턴스를 위한 외부 서비스를 선택적으로 사용할 수 있습니다.

  • 신뢰할 수 있는 제공 업체나 솔루션을 사용해야 합니다. Google Memorystore 및 AWS ElastiCache가 작동하는 것으로 알려져 있습니다.
  • Redis 클러스터 모드는 특별히 지원되지 않지만 Redis 스탠드얼론과 HA는 지원됩니다.
  • 설정에 따라 Redis 에박션 모드를 설정해야 합니다.

더 많은 정보는 권장 클라우드 제공 업체 및 서비스를 참조하세요.

Redis 캐시 클러스터 구성

여기서 새로운 Redis 캐시 인스턴스를 설치하고 설정하는 섹션입니다.

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

기본 Redis 캐시 노드 구성

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

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

    # Sentinel 및 Consul 에이전트를 사용하여 서버 역할을 '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
   
## Sentinel용 기본 Redis 서버 포트, 변경하려면 비주류로 변경
## 기본값은 `6379`입니다.
#redis['master_port'] = 6379
   
# Redis 및 복제본의 암호 인증 설정(모든 노드에서 동일한 비밀번호 사용)
redis['password'] = '첫 번째 클러스터의 REDIS_PRIMARY_PASSWORD'
redis['master_password'] = '첫 번째 클러스터의 REDIS_PRIMARY_PASSWORD'
   
## 모든 Redis 노드에서 동일해야 함
redis['master_name'] = 'gitlab-redis-cache'
   
## 이 기본 Redis 노드의 IP
redis['master_ip'] = '10.6.0.51'
   
# Redis 캐시 인스턴스를 LRU로 설정
# MB에서 사용 가능한 RAM의 90%
redis['maxmemory'] = '13500mb'
redis['maxmemory_policy'] = "allkeys-lru"
redis['maxmemory_samples'] = 5
   
## 프로메테우스를 위한 서비스 검색 활성화
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),
}
   
# Exporter가 수신 대기하는 네트워크 주소 설정
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' => '여기에 레디스 비밀번호 입력',
}
   
# 업그레이드시 데이터베이스 마이그레이션 자동 실행 방지
gitlab_rails['auto_migrate'] = false

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

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

복제 Redis 캐시 노드 구성

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

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

    1. 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하고 이 서버에 동일한 이름의 파일을 추가하거나 교체합니다. 이가 구성하는 첫 번째 Linux 패키지 노드라면이 단계는 건너뛰어도 됩니다.

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

    3. 모든 기타 복제 노드에 대해 다시 한 번 단계를 진행하고 IP를 올바르게 설정해야 합니다.

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

Redis Persistent 클러스터 구성

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

주 노드와 복제 노드 Redis 모두 동일한 비밀번호가 redis['password']에 정의되어야 합니다. 장애 조치 중에 언제든지 Sentinels는 노드를 재구성하고 해당 상태를 주(primary)에서 복제(replica)로 변경(그 반대도 마찬가지)할 수 있습니다.

주(primary) Redis Persistent 노드 구성

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

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

    # Sentinel을 사용하여 'redis_master_role'로 서버 역할을 지정하고 Consul 에이전트를 활성화합니다.
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.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'
   
## 프로메테우스를 위한 서비스 디스커버리를 활성화합니다.
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'
   
# 업그레이드 시 자동으로 데이터베이스 마이그레이션을 실행하지 않도록 합니다.
gitlab_rails['auto_migrate'] = false

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

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

복제 Redis Persistent 노드 구성

  1. 복제 Redis Persistent 서버에 SSH로 로그인합니다.
  2. Linux 패키지를 다운로드하고 설치하십시오. 페이지의 설치 단계 1과 2를 따로 따르고 현재 설치와 동일한 버전 및 유형(커뮤니티 또는 엔터프라이즈 에디션)을 선택하세요.

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

    # Sentinel을 사용하여 'redis_replica_role'로 서버 역할을 지정하고 Consul 에이전트를 활성화합니다.
roles ['redis_sentinel_role', 'redis_replica_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.62'
   
# 다른 머신이 연결할 수 있도록 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'
   
## 프로메테우스를 위한 서비스 디스커버리를 활성화합니다.
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'
   
# 업그레이드 시 자동으로 데이터베이스 마이그레이션을 실행하지 않도록 합니다.
gitlab_rails['auto_migrate'] = false

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

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

  6. 모든 다른 복제 노드에 대해 다시 단계를 진행하고, IP를 올바르게 설정했는지 확인하세요.

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

Gitaly 클러스터 구성

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

caution
Gitaly 규격은 모두 좋은 상태에서 사용 패턴 및 리포지터리 크기의 높은 백분위에 기반합니다. 그러나 큰 모노 리포(몇 기가바이트 이상)나 추가 작업 부하가 있는 경우 환경의 성능에 상당한 영향을 미칠 수 있으며 추가 조정이 필요할 수 있습니다. 해당 사항이 해당되는 경우 연결된 문서를 참조하거나 고객 성공 관리자 또는 지원 팀에 문의하는 것을 강력히 권장합니다.

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

다음 컴포넌트를 포함하여 권장 클러스터 설정을 구성하는 방법에 대한 세부 정보가 포함되어 있습니다:

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

이 섹션에서는 순서대로 권장 표준 설정을 구성하는 방법에 대해 자세히 설명합니다. 더 고급화된 설정에 대해서는 독립 Gitaly 클러스터 문서를 참조하세요.

Praefect PostgreSQL 구성

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

고가용성(HA) 설정을 원하는 경우, Praefect에는 타사 PostgreSQL 데이터베이스가 필요합니다. 내장 솔루션이 진행 중에 있습니다.

Praefect 고가용성이 아닌 단독 Linux 패키지를 사용한 PostgreSQL

다음 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 섹션의 값들을 대체하십시오: 

    # PostgreSQL 및 Consul을 제외한 모든 컴포넌트를 비활성화합니다
roles(['postgres_role', 'consul_role'])
   
# PostgreSQL 구성
postgresql['listen_address'] = '0.0.0.0'
   
# 업그레이드 시 자동으로 데이터베이스 마이그레이션을 방지합니다
gitlab_rails['auto_migrate'] = false
   
# Consul 에이전트 구성
## 프로메테우스에 대한 서비스 검색 활성화
consul['monitoring_service_discovery'] =  true
   
# START user configuration
# 필요한 정보 섹션에 설명된대로 실제 값을 설정하십시오
#
# PRAEFECT_POSTGRESQL_PASSWORD_HASH를 생성된 md5 값으로 대체하십시오
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. 구성한 다음, /etc/gitlab/gitlab-secrets.json 파일을 첫 번째 Linux 패키지 노드에서 복사하여 이 서버의 동일한 이름의 파일을 추가하거나 대체하십시오. 이것이 구성하는 첫 번째 Linux 패키지 노드라면 이 단계를 건너뛰어도 됩니다.

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

  7. 포스트 구성을 따르십시오.

Praefect 고가용성을 위한 타사 PostgreSQL 솔루션

여기서 언급된 대로, 고가용성을 위해 Praefect의 데이터베이스에 대한 타사 PostgreSQL 솔루션이 권장됩니다.

PostgreSQL 고가용성을 위한 다양한 타사 솔루션이 있습니다. 선택한 솔루션이 Praefect와 함께 작동하려면 다음이 필요합니다:

  • 장애 조치(failover) 시 변경되지 않는 모든 연결에 대한 정적 IP
  • LISTEN SQL 기능을 지원해야 함
note
타사 설정을 통해 본격적으로 Praefect의 데이터베이스를 기본 GitLab 데이터베이스와 동일한 서버에 편리하게 둘 수 있습니다. 단, 복제 처리를 올바르게 다루기 위해 Geo를 사용하는 경우에는 별도의 데이터베이스 인스턴스가 필요합니다. 이러한 설정에서는 본 데이터베이스 설정의 사양을 변경할 필요가 없어야 하며, 영향은 최소화되어야 합니다.

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

위와 같은 예는 Google의 Cloud SQL이나 Amazon RDS 등을 포함할 수 있습니다.

데이터베이스가 설정된 후, 포스트 구성을 따르십시오.

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 사용자를 생성하십시오. <praefect_postgresql_password>를 대체하십시오: 

    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. /etc/gitlab/gitlab.rb 파일을 편집하여 Praefect를 구성하세요.

    note
    GitLab이 필요로 하는 바임으로 virtual_storages에서 default 항목을 제거할 수 없습니다.
    # 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
   
# 사용자 구성 시작
# 필요한 정보 섹션에 설명된 대로 실제 값을 설정하세요
#
   
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 서버(gitaly-1)의 git_data_dirs 및 Gitaly 노드(gitaly-1)의 gitaly['configuration'][:storage]에서 리포지터리 이름과 일치해야 합니다
   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가 모니터링을 위해 수신 대기할 네트워크 주소 설정
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),
}
#
# 사용자 구성 끝

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

  5. Praefect는 데이터베이스 마이그레이션을 실행해야 하며, 주 GitLab 애플리케이션과 마찬가지로 특정 Praefect 노드에서만 이 마이그레이션을 실행해야 합니다. 이 노드를 _배포 노드_로 지정해야 합니다. 이 노드는 다른 노드보다 먼저 다음과 같이 구성되어야 합니다:

    1. /etc/gitlab/gitlab.rb 파일에서 praefect['auto_migrate'] 설정 값을 false에서 true로 변경합니다.

    2. 재구성(reconfigure) 시에 데이터베이스 마이그레이션이 자동으로 실행되지 않도록 하기 위해 다음 명령을 실행합니다: 

    sudo touch /etc/gitlab/skip-auto-reconfigure
    1. 변경 사항이 적용되고 Praefect 데이터베이스 마이그레이션을 실행하려면 GitLab을 다시 구성하세요.
  6. 다른 Praefect 노드에서도 변경 사항이 적용되도록 GitLab을 다시 구성하세요.

Gitaly 구성

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

caution
Gitaly 사양은 활용 패턴 및 리포지터리 크기의 상위 백분율에 따라 결정됩니다. 그러나 대형 모노리포(여러 기가바이트 이상)나 추가 워크로드가 있다면, 환경의 성능에 상당한 영향을 미칠 수 있으며 추가 조치가 필요할 수 있습니다. 해당되는 경우, 링크된 문서를 참조하고 고객 성공 관리자 또는 지원팀에 문의할 것을 강력히 권장합니다.

Gitaly는 상당한 입출력 요구 사항을 가지고 있기 때문에, 모든 Gitaly 노드가 SSD(Solid-State Drive)를 사용하는 것이 좋습니다. 이러한 SSD는 읽기 작업에 대해 초당 최소 8,000개, 쓰기 작업에 대해 초당 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가 수신 대기할 네트워크 주소 설정
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 클러스터 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. 파일을 저장하고 GitLab 재구성을 수행합니다.

  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 구성이 포함됩니다.
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']
   
# 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. 구성한 첫 번째 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 인스턴스에 대한 연결을 필요로 합니다. 또한 권장사항으로 객체 리포지터리(Object Storage)에 대한 연결도 필요합니다.

note
객체 리포지터리(Object storage)를 데이터 객체에 대해 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
  • 10.6.0.116: GitLab 응용 프로그램 6
  • 10.6.0.117: GitLab 응용 프로그램 7
  • 10.6.0.118: GitLab 응용 프로그램 8
  • 10.6.0.119: GitLab 응용 프로그램 9
  • 10.6.0.120: GitLab 응용 프로그램 10
  • 10.6.0.121: GitLab 응용 프로그램 11
  • 10.6.0.122: GitLab 응용 프로그램 12

각 노드에서 다음을 수행하십시오:

  1. 선호하는 Linux 패키지를 다운로드하여 설치합니다. 페이지에서 설치 단계 1과 2만 따르십시오.

  2. /etc/gitlab/gitlab.rb를 편집하고 다음 구성을 사용하십시오. 노드 간 링크의 일관성을 유지하기 위해 응용 프로그램 서버의 external_url는 사용자가 GitLab에 액세스하는 데 사용할 외부 URL을 가리켜야 합니다. 이것은 GitLab 응용 프로그램 서버로 트래픽을 라우팅할 외부 로드 밸런서의 URL이 됩니다: 

    external_url 'https://gitlab.example.com'
   
# Praefect 가상 리포지터리를 위해 git_data_dirs 구성
# 주소는 Praefect 내부 로드 밸런서
# 토큰은 praefect_external_token
git_data_dirs({
  "default" => {
    "gitaly_address" => "tcp://10.6.0.40:2305", # 내부 로드 밸런서 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' # 내부 로드 밸런서 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. Gitaly의 TLS 지원을 사용하는 경우 external_url에 https를 지정하면 tls 대신 tcp로 구성된 git_data_dirs 항목을 확인하세요: 

    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. 데이터베이스 마이그레이션은 업그레이드에서 자동으로 실행되지 않고 reconfigure 중에만 실행되도록 하려면 다음을 실행하세요: 

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

    지정된 노드는 GitLab Rails 사후 구성 섹션에 설명된 대로 마이그레이션을 담당해야 합니다.

  6. 변경 사항이 적용되려면 GitLab을 다시 구성하십시오.
  7. 증분 로깅을 활성화하십시오.

  8. 노드가 Gitaly에 연결할 수 있는지 확인합니다: 

    sudo gitlab-rake gitlab:gitaly:check

    그런 다음 요청을 보려면 로그를 확인하십시오: 

    sudo gitlab-ctl tail gitaly
  9. 선택적으로 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를 지정하는 경우 SSL 인증서가 /etc/gitlab/ssl/에 있어야 합니다. 인증서가 없으면 NGINX가 시작되지 않습니다. 자세한 정보는 HTTPS 문서를 참조하세요.

GitLab Rails 포스트 구성

  1. 설치 및 업데이트 중에 데이터베이스 마이그레이션을 실행할 애플리케이션 노드를 지정하십시오. GitLab 데이터베이스를 초기화하고 모든 마이그레이션이 실행되었는지 확인하십시오: 

    sudo gitlab-rake gitlab:db:configure

    다음은 레일스 노드가 주 데이터베이스에 직접 연결하도록 구성되어 있어야 하며, PgBouncer 우회가 필요합니다. 마이그레이션을 완료한 후에는 노드를 다시 PgBouncer로 전환해야 합니다.

  2. 데이터베이스에서 승인된 SSH 키를 빠르게 조회하도록 구성합니다(상세 내용).

프로메테우스 구성

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

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

  • 10.6.0.151: 프로메테우스

모니터링 노드를 구성하려면 다음을 수행하십시오:

  1. 모니터링 노드로 SSH를 연결하십시오.

  2. 원하는 Linux 패키지를 다운로드하고 설치하십시오. 페이지에서 설치 단계 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는 작업 로그를 청크 단위로 반환하며, 기본적으로 /var/opt/gitlab/gitlab-ci/builds에 임시로 캐시합니다. 통합된 객체 리포지터리를 사용할 때도 NFS 노드가 배포되지 않은 경우에는 증분 로깅을 활성화하여 디스크 공간 대신 Redis를 사용하여 작업 로그를 임시로 캐시하는 것이 권장됩니다.

NFS를 통해 작업 로그를 공유하는 것은 지원되지만, NFS 노드를 배포하지 않을 경우 증분 로깅을 활성화하여 NFS의 필요성을 피하는 것이 좋습니다.

고급 검색 구성

Elasticsearch를 활용하여 GitLab 인스턴스 전체에 걸친 고급 검색 기능을 사용할 수 있습니다.

Elasticsearch 클러스터 디자인 및 요구 사항은 특정 데이터에 따라 다릅니다. Elasticsearch 클러스터 구성에 대한 권장 사항에 대해서는 최적의 클러스터 구성 선택을 읽어보십시오.

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

Kubernetes에서 클라우드 네이티브 GitLab의 일부 컴포넌트를 GitLab Helm 차트로 실행할 수 있습니다. 이 설정에서는 Kubernetes 클러스터에서 GitLab 레일스에 해당하는 웹서비스 및 사이드킥 노드를 실행할 수 있습니다. 또한, NGINX, Toolbox, 마이그레이션, 프로메테우스와 같은 관련 지원 서비스를 실행할 수 있습니다.

하이브리드 설치는 클라우드 네이티브 워크로드 관리 이점과 함께 전통적인 컴퓨팅 배포의 장단점을 효율적으로 활용합니다. 이로써 무상태 컴포넌트는 클라우드 네이티브 워크로드 관리 이점을 활용하고, 상태 컴포넌트는 Linux 패키지 설치를 통해 컴퓨팅 VM에 배포하여 증가된 영속성을 활용할 수 있습니다.

Kubernetes 및 백엔드 컴포넌트 간의 GitLab 시크릿 동기화를 포함한 설정 지침에 대해서는 Helm 차트 고급 구성 문서를 참조하십시오.

참고: 이는 고급 설정입니다. Kubernetes에서 서비스를 실행하는 것은 복잡한 작업임이 널리 알려져 있습니다. 이 설정은 단지 Kubernetes에 대해 강력한 지식과 경험이 있는 경우에만 권장됩니다. 본 섹션의 나머지는 해당 가정하에 제공됩니다.

경고: Gitaly 클러스터는 Kubernetes에서 실행되는 것을 지원하지 않습니다. 자세한 내용은 에픽 6127을 참조하십시오.

클러스터 토폴로지

다음 표 및 다이어그램은 일반적인 환경과 동일한 형식을 사용하여 하이브리드 환경의 구현 내용을 설명합니다.

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

컴포넌트 노드 그룹 타겟 노드 풀 총계 GCP 예시 AWS 예시
웹서비스 308 vCPU
385 GB 메모리 (요청)
539 GB 메모리 (제한) 		11 x n1-standard-32 11 x c5.9xlarge
사이드킥 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을 배포할 수 있도록 해야 합니다.
  • 웹서비스 및 사이드킥 타겟 노드 풀 총계는 GitLab 컴포넌트에만 해당합니다. 여기에는 적용되는 Kubernetes 공급업체의 시스템 프로세스에 대한 추가 리소스가 필요합니다. 제공된 예시는 이 사항을 고려하였습니다.
  • 지원 서비스 타겟 노드 풀 총계는 GitLab 배포를 지원하기 위한 여러 리소스와 함께 선택한 Kubernetes 공급업체의 시스템 프로세스에 대한 리소스를 포용하기 위한 것입니다. 제공된 예시는 이를 반영하고 있습니다.
  • 프로덕션 배포에서는 pod을 특정 노드에 지정할 필요가 없습니다. 그러나 저항성 있는 클라우드 아키텍처의 기본 원칙을 준수하기 위해 각 풀에 여러 노드를 다양한 가용 영역에 걸쳐 배치해서 선호됩니다.
  • 효율성을 위한 클러스터 오토스케일링(예: 클러스터 오토스케일러)을 사용하는 것이 좋지만, 일반적으로 Webservice 및 Sidekiq pod에 대한 75% 바닥 타겟을 추천하여 지속적인 성능을 보장하도록 하는 것이 좋습니다.

다음은 Linux 패키지(또는 외부 PaaS 서비스가 해당할 경우)를 사용하여 정적 컴퓨트 VM에서 실행되는 백엔드 컴포넌트입니다:

서비스 노드 구성 GCP AWS
Consul1 3 2 vCPU, 1.8 GB memory n1-highcpu-2 c5.large
PostgreSQL1 3 32 vCPU, 120 GB memory n1-standard-32 m5.8xlarge
PgBouncer1 3 2 vCPU, 1.8 GB memory n1-highcpu-2 c5.large
내부 로드 밸런서3 1 16 vCPU, 14.4 GB memory n1-highcpu-16 c5.4xlarge
Redis/Sentinel - 캐시2 3 4 vCPU, 15 GB memory n1-standard-4 m5.xlarge
Redis/Sentinel - 영속성2 3 4 vCPU, 15 GB memory n1-standard-4 m5.xlarge
Gitaly5 3 64 vCPU, 240 GB memory6 n1-standard-64 m5.16xlarge
Praefect5 3 4 vCPU, 3.6 GB memory n1-highcpu-4 c5.xlarge
Praefect PostgreSQL1 1+ 2 vCPU, 1.8 GB memory `n  

Kubernetes 컴포넌트 대상

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

Webservice

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

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

500 RPS 또는 25,000 사용자의 경우, Puma worker 총수를 약 308 정도로 권장하며, 그에 따라 적어도 77개의 Webservice pod를 실행하는 것이 좋습니다.

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

NGINX

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

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

Sidekiq

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

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

일반적인 배포와 마찬가지로 여기서는 8개의 Sidekiq worker를 초기 대상으로 사용했습니다. 특정 워크플로에 따라 추가 worker가 필요할 수 있습니다.

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

지원

지원 노드 풀은 Webservice 및 Sidekiq 풀에 필요하지 않은 모든 지원 배포를 수용하도록 설계되었습니다.

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

컨테이너 레지스트리, 페이지 또는 모니터링과 같은 추가 배포를 하려면 가능한 경우 이 풀에 배포하는 것이 좋으며, Webservice 또는 Sidekiq 풀에는 배포하지 않는 것이 좋습니다. Supporting 풀은 몇 가지 추가 배포를 수용하도록 특별히 설계되었기 때문입니다. 그러나 사용 사례에 따라 풀에 맞지 않는 배포가 있는 경우 노드 풀을 적절하게 늘릴 수 있습니다. 반대로 사용 사례에 따라 풀이 과다하게 제공된 경우 이를 줄일 수 있습니다.

예시 구성 파일

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