요구 사항
테스트 방법론
구성 요소 설정
외부 로드 밸런서 구성
내부 로드 밸런서 구성
Consul 구성
PostgreSQL 구성
Redis 구성
Gitaly 클러스터 구성
Sidekiq 구성
GitLab Rails 구성
- GitLab Rails 포스트 구성
프로메테우스 구성
객체 저장소 구성
- 증분 로깅 활성화
고급 검색 구성
Helm Charts를 이용한 클라우드 네이티브 하이브리드 참조 아키텍처 (대안)
다음 단계

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

Tier: 프리미엄, 얼티밋 Offering: Self-managed

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

참조 아키텍처의 전체 목록은 사용 가능한 참조 아키텍처을 참조하십시오.

참고: 이 아키텍처를 배포하기 전에 먼저 주요 문서를 읽는 것이 좋으며, 특히 시작하기 전에 및 사용할 아키텍처를 결정하기 섹션을 읽는 것이 좋습니다.

대상 부하: API: 1000 RPS, Web: 100 RPS, Git(Pull): 100 RPS, Git(Push): 20 RPS
고가용성: 예 (HA를 위해 Praefect는 제삼 자 Postgres 솔루션을 필요로 함)
비용 계산기 템플릿: 비용 계산기 템플릿 섹션을 확인하십시오
클라우드 네이티브 하이브리드 대체 옵션: 예
사용할 참조 아키텍처가 확실하지 않은가요? 더 많은 정보를 위해 이 가이드로 이동

서비스	노드 수	구성	GCP	AWS	Azure
외부 로드 밸런서³	1	16 vCPU, 14.4 GB 메모리	`n1-highcpu-16`	`c5.4xlarge`	`F16s v2`
Consul¹	3	2 vCPU, 1.8 GB 메모리	`n1-highcpu-2`	`c5.large`	`F2s v2`
PostgreSQL¹	3	32 vCPU, 120 GB 메모리	`n1-standard-32`	`m5.8xlarge`	`D32s v3`
PgBouncer¹	3	2 vCPU, 1.8 GB 메모리	`n1-highcpu-2`	`c5.large`	`F2s v2`
내부 로드 밸런서³	1	16 vCPU, 14.4 GB 메모리	`n1-highcpu-16`	`c5.4xlarge`	`F16s v2`
Redis/Sentinel - 캐시²	3	4 vCPU, 15 GB 메모리	`n1-standard-4`	`m5.xlarge`	`D4s v3`
Redis/Sentinel - 지속적²	3	4 vCPU, 15 GB 메모리	`n1-standard-4`	`m5.xlarge`	`D4s v3`
Gitaly⁵	3	64 vCPU, 240 GB 메모리⁶	`n1-standard-64`	`m5.16xlarge`	`D64s v3`
Praefect⁵	3	4 vCPU, 3.6 GB 메모리	`n1-highcpu-4`	`c5.xlarge`	`F4s v2`
Praefect PostgreSQL¹	1+	2 vCPU, 1.8 GB 메모리	`n1-highcpu-2`	`c5.large`	`F2s v2`
Sidekiq⁷	4	4 vCPU, 15 GB 메모리	`n1-standard-4`	`m5.xlarge`	`D4s v3`
GitLab Rails⁷	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`
객체 저장소⁴	-	-	-	-	-

각주:

이름이 있는 신뢰할 수 있는 제삼 자 외부 PaaS PostgreSQL 솔루션에서 선택 사항으로 실행될 수 있습니다. 자세한 정보는 자체 PostgreSQL 인스턴스를 제공를 참조하십시오.
이름이 있는 신뢰할 수 있는 제삼 자 외부 PaaS Redis 솔루션에서 선택 사항으로 실행될 수 있습니다. 자세한 정보는 자체 Redis 인스턴스를 제공를 참조하십시오.
- Redis는 주로 단일 스레드이며 CPU 코어의 증가로 크게 이득을 보지 않습니다. 이러한 규모의 아키텍처의 경우 최적의 성능을 달성하기 위해 별도로 Cache 및 Persistent 인스턴스를 구분하는 것이 강력히 권장됩니다.
이름이 있는 신뢰할 수 있는 제삼 자 로드 밸런싱 서비스(LB PaaS)에서 선택 사항으로 실행될 수 있습니다. 자세한 정보는 추천되는 클라우드 제공업체 및 서비스를 참조하십시오.
신뢰할 수 있는 클라우드 제공업체 또는 자체 관리 솔루션에서 실행해야 합니다. 자세한 정보는 객체 저장소 설정를 참조하십시오.
Gitaly 클러스터는 장애 허용성의 이점을 제공하지만 추가 복잡성을 동반합니다. Gitaly 클러스터를 배포하기 전의 기술적 한계 및 고려 사항을 검토하십시오. Sharded Gitaly를 사용하려면 ‘Gitaly’에 대해 위에 나열된 동일한 사양을 사용하십시오.
Gitaly 사양은 사용 패턴 및 리포지토리 크기의 높은 백분위수에 기반합니다. 그러나 대형 단일 리포지토리(몇 기가바이트보다 큼)가 있거나 추가 Workload가 있는 경우 Git 및 Gitaly 성능에 중요한 영향을 미칠 수 있으며 추가 조정이 필요할 수 있습니다.
컴포넌트에 상태 데이터를 저장하지 않는 Auto Scaling 그룹(ASG)에 배치할 수 있습니다. 그러나 클라우드 네이티브 하이브리드 설정이 특정 컴포넌트의 경우 더 나은 처리 방식을 제공하므로 마이그레이션 및 Mailroom과 같은 일부 컴포넌트는 한 노드에서만 실행할 수 있으며 Kubernetes에서 더 잘 처리됩니다.

참고: PaaS 솔루션의 경우 인스턴스 구성을 구성하는 것이 권장되며, 견고한 클라우드 아키텍처 관행과 일치하도록 세 개의 노드를 세 가용 영역에서 최소로 구현하는 것이 좋습니다.

요구 사항

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

테스트 방법론

50k 아키텍처는 대부분의 워크플로를 커버하기 위해 설계되었으며 정기적으로 스모크 및 성능 테스트가 Test Platform 팀에 의해 수행되었습니다. 다음 엔드포인트 처리량 목표에 대해:

API: 1000 RPS
웹: 100 RPS
Git (풀): 100 RPS
Git (푸시): 20 RPS

위의 목표는 사용자 카운트에 해당하는 총 환경 부하의 실제 고객 데이터를 기반으로 선정되었습니다. 이에는 CI 및 기타 워크로드가 포함됩니다.

위 엔드포인트 목표에 대해 정기적으로 높은 처리량을 가지고 있다고 제안할 메트릭이 있다면, 대형 단일 저장소 또는 주목할만한 추가 워크로드가 있을 수 있으며, 이는 성능 환경에 크게 영향을 줄 수 있으며 추가 조정이 필요할 수 있습니다. 당신의 경우, 링크된 문서를 참조하고 고객 성공 매니저 또는 지원팀에 문의하는 것을 권장합니다.

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

테스트에 사용된 로드 밸런서는 리눅스 패키지 환경의 경우 HAProxy를 사용하였거나 클라우드 네이티브 하이브리드의 경우 NGINX 인그레스를 사용했습니다. 이러한 선택은 특정 요구 사항이나 권장 사항을 나타내는 것이 아니며, 신뢰할 수 있는 로드 밸런서가 작동할 것으로 예상됩니다.

구성 요소 설정

GitLab 및 해당 구성 요소를 1000 RPS 또는 50,000 사용자까지 수용할 수 있도록 설정하려면 다음을 수행하세요:

외부 로드 밸런서 구성 GitLab 애플리케이션 서비스 노드의 부하 분산을 처리합니다.
내부 로드 밸런서 구성 GitLab 애플리케이션 내부 연결의 부하 분산을 처리합니다.
서비스 검색 및 헬스 체크를 위해 Consul 구성합니다.
GitLab을 위한 데이터베이스인 PostgreSQL 구성합니다.
데이터베이스 연결 풀링 및 관리를 위해 PgBouncer 구성합니다.
세션 데이터, 임시 캐시 정보 및 백그라운드 작업 대기열을 저장하는 Redis 구성합니다.
Git 리포지토리에 대한 액세스를 제공하는 Gitaly Cluster 구성합니다.
백그라운드 작업 처리를 위해 Sidekiq 구성합니다.
Puma, Workhorse, GitLab Shell을 실행하고 UI, API 및 HTTP/SSH를 포함하는 모든 프론트엔드 요청을 제공하기 위해 주요 GitLab Rails 애플리케이션 구성합니다.
GitLab 환경을 모니터링하기 위해 Prometheus 구성합니다.
공유 데이터 객체를 위해 사용되는 객체 저장소 구성합니다.
빠르고 더 고급 코드 검색을 위한 선택 사항으로 고급 검색 구성합니다.

서버는 동일한 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: 프레펙트 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 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 호스트 이름에 대한 DNS 구성은 altssh.gitlab.example.com과 같이 하십시오.

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

SSL

다음 질문은 환경에서 SSL을 어떻게 처리할 것인가입니다. 여러 가지 다른 옵션이 있습니다.

응용 프로그램 노드가 SSL을 종료.
로드 밸런서가 백엔드 SSL 없이 SSL을 종료하고 로드 밸런서와 응용 프로그램 노드 사이의 통신이 안전하지 않습니다.
로드 밸런서가 백엔드 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 문서를 참조하십시오.

구성 요소 설정으로 돌아가기

내부 로드 밸런서 구성

다중 노드 GitLab 구성에서는 PgBouncer 및 Praefect (Gitaly Cluster)에 대한 연결을 경로로 지정하는 내부 로드 밸런서가 필요할 수 있습니다.

다음과 같은 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 서버를 설정합니다.

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

다음 IP 주소들은 예시로 사용될 것입니다:

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

Consul을 구성하려면:

Consul을 호스팅할 서버에 SSH로 접속합니다.
선택한 리눅스 패키지를 다운로드하고 설치합니다. 페이지에서 installation steps 1 and 2만 따르고, 현재 설치된 것과 동일한 버전 및 유형(커뮤니티 또는 엔터프라이즈 판)의 올바른 리눅스 패키지를 선택해야 합니다.

/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

첫 번째 리눅스 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버에 같은 이름의 파일이 없다면 추가하거나 교체합니다. 이것이 구성하는 첫 번째 리눅스 패키지 노드라면, 이 단계는 건너뛸 수 있습니다.
변경 사항이 적용되려면 GitLab을 다시 구성합니다.
다른 Consul 노드에 대해 위 단계를 모두 다시 진행하고, 올바른 IP를 설정했는지 확인합니다.

세 번째 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을 위해 제 3 자 외부 서비스를 선택적으로 사용할 수 있습니다.

이를 위해 신뢰할 수 있는 제공업체나 솔루션이 사용되어야 합니다. Google Cloud SQL 및 Amazon RDS가 알려져 있는 솔루션입니다. 그러나 Amazon Aurora는 기본적으로 사용 중인 로드 밸런싱과 호환되지 않습니다 14.4.0부터.

자체 PostgreSQL을 사용할 경우:

HA Linux 패키지 PostgreSQL 설정에는 PostgreSQL, PgBouncer 및 Consul이 모두 포함됩니다. 이러한 구성요소는 모두 제 3자 외부 서비스를 사용할 때 필요하지 않습니다.
데이터베이스 요구 사항 문서에 따라 PostgreSQL을 설정합니다.
gitlab 사용자명과 사용자 선택의 암호를 설정합니다. gitlab 사용자는 gitlabhq_production 데이터베이스를 생성할 권한이 필요합니다.
GitLab 애플리케이션 서버를 적절한 세부 정보로 구성합니다. 이 단계는 GitLab Rails 애플리케이션 구성에 포함됩니다.
HA를 달성하기 위해 필요한 노드의 수는 서비스에 따라 달라질 수 있으며 Linux 패키지와 일치할 필요가 없습니다.
그러나 더 나은 성능을 위해 Database Load Balancing을 통한 데이터베이스 로드 밸런싱이 의도된 경우, 참조 아키텍처의 노드 수를 따르는 것이 권장됩니다.

독립적인 Linux 패키지 사용 PostgreSQL

복제와 장애 조치가 가능한 PostgreSQL 클러스터를 위한 권장 리눅스 패키지 구성은 다음을 요구합니다:

최소 3개의 PostgreSQL 노드
최소 3개의 Consul 서버 노드
주요 데이터베이스 읽기 및 쓰기를 추적 및 처리하는 최소 3개의 PgBouncer 노드
- PgBouncer 노드 간의 요청을 균형 잡기 위한 내부 로드 밸런서(TCP)
활성화된 Database Load Balancing
각 PostgreSQL 노드에 구성된 로컬 PgBouncer 서비스. 이 서비스는 주요 데이터베이스를 추적하는 주요 PgBouncer 클러스터와 별도입니다.

다음 IP 주소들은 예시로 사용될 것입니다:

10.6.0.21: PostgreSQL 프라이머리
10.6.0.22: PostgreSQL 세컨더리 1
10.6.0.23: PostgreSQL 세컨더리 2

먼저, 각 노드에 리눅스 GitLab 패키지를 설치해야 합니다. 단계별로, 1단계의 필요한 종속성을 설치하고 2단계에서 GitLab 패키지 저장소를 추가해야 합니다. 두 번째 단계에서 EXTERNAL_URL 값을 입력할 필요는 없습니다.

PostgreSQL 노드

PostgreSQL 노드 중 하나에 SSH로 로그인합니다.
PostgreSQL 사용자/비밀번호 쌍에 대한 비밀번호 해시를 생성합니다. 이는 기본 사용자명 gitlab (권장)을 사용할 것으로 가정합니다. 명령은 비밀번호와 확인을 요청할 것입니다. 이 명령이 출력하는 값을 다음 단계의 <postgresql_password_hash> 값으로 사용하세요:
```
sudo gitlab-ctl pg-password-md5 gitlab
```
PgBouncer 사용자/비밀번호 쌍에 대한 비밀번호 해시를 생성합니다. 이는 기본 사용자명 pgbouncer (권장)을 사용할 것으로 가정합니다. 명령은 비밀번호와 확인을 요청할 것입니다. 이 명령이 출력하는 값을 다음 단계의 <pgbouncer_password_hash> 값으로 사용하세요:
```
sudo gitlab-ctl pg-password-md5 pgbouncer
```
PostgreSQL 복제 사용자/비밀번호 쌍에 대한 비밀번호 해시를 생성합니다. 이는 기본 사용자명 gitlab_replicator (권장)을 사용할 것으로 가정합니다. 명령은 비밀번호와 확인을 요청할 것입니다. 이 명령이 출력하는 값을 다음 단계의 <postgresql_replication_password_hash> 값으로 사용하세요:
```
sudo gitlab-ctl pg-password-md5 gitlab_replicator
```
Consul 데이터베이스 사용자/비밀번호 쌍에 대한 비밀번호 해시를 생성합니다. 이는 기본 사용자명 gitlab-consul (권장)을 사용할 것으로 가정합니다. 명령은 비밀번호와 확인을 요청할 것입니다. 이 명령이 출력하는 값을 다음 단계의 <consul_password_hash> 값으로 사용하세요:
```
sudo gitlab-ctl pg-password-md5 gitlab-consul
```

모든 데이터베이스 노드에서 /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`를 데이터베이스 노드 수의 2배로 설정합니다.
# 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 user configuration
# 필수 정보 섹션에서 설명한 대로 실제 값을 설정하세요
#
# 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>'

# Network Address로 10.6.0.0/24 대체
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 user configuration

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

첫 번째 리눅스 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 동일한 이름의 파일을 추가하거나 교체하세요. 이것이 처음 구성하는 리눅스 패키지 노드인 경우, 이 단계를 건너뛸 수 있습니다.
변경 사항이 적용되려면 GitLab을 다시 구성하세요.

필요에 따라 고급 구성 옵션을 지원하며 추가할 수 있습니다.

구성 요소 설정으로 돌아가기

PostgreSQL 사후 구성

주 사이트(primary site)의 Patroni 노드 중 하나에 SSH로 로그인합니다.

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

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 구성

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

참고: PgBouncer는 단일 스레드이며 CPU 코어가 증가함에 따라 혜택을 거의 받지 않습니다. 자세한 내용은 스케일링 문서를 참조하세요.

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

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

각 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'

첫 번째 리눅스 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 동일한 이름 파일로 추가하거나 대체하세요. 이게 첫 번째로 구성하는 리눅스 패키지 노드라면, 이 단계는 건너 뛰어도 됩니다.
변경 사항이 적용되려면 GitLab을 다시 구성하세요.
execute[generate databases.ini] 오류가 발생한다면, 이는 기존의 알려진 이슈 때문입니다. 다음 단계 이후에 두 번째 reconfigure를 실행하면 해결됩니다.
Consul이 PgBouncer를 다시 불러올 수 있도록 .pgpass 파일을 생성하세요. 두 번째로 물어보는 경우 PgBouncer 암호를 입력하세요:
```
gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul
```
이전 단계에서 발생한 가능한 오류를 해결하기 위해 GitLab을 다시 구성하세요.

각 노드가 현재 기본 서버와 통신하도록 확인하세요:

gitlab-ctl pgb-console # PGBOUNCER_PASSWORD를 입력 요청받습니다.

콘솔 프롬프트를 사용할 수 있는 경우, 다음 쿼리를 실행하세요:

show databases ; show clients ;

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

        name         |  host       | port |      database       | force_user | pool_size | reserve_pool | pool_mode | max_connections | current_connections
---------------------+-------------+------+---------------------+------------+-----------+--------------+-----------+-----------------+---------------------
 gitlabhq_production | MASTER_HOST | 5432 | gitlabhq_production |            |        20 |            0 |           |               0 |                   0
 pgbouncer           |             | 6432 | pgbouncer           | pgbouncer  |         2 |            0 | statement |               0 |                   0
(2 rows)

 type |   user    |      database       |  state  |   addr         | port  | local_addr | local_port |    connect_time     |    request_time     |    ptr    | link | remote_pid | tls
------+-----------+---------------------+---------+----------------+-------+------------+------------+---------------------+---------------------+-----------+------+------------+-----
 C    | pgbouncer | pgbouncer           | active  | 127.0.0.1      | 56846 | 127.0.0.1  |       6432 | 2017-08-21 18:09:59 | 2017-08-21 18:10:48 | 0x22b3880 |      |          0 |
(2 rows)

구성 요소 설치로 돌아가기

Redis 구성

확장 가능한 환경에서 Redis를 사용하는 것은 Primary x Replica 위상과 Redis Sentinel 서비스를 사용하여 장애 조치 절차를 자동으로 시작하는 것이 가능합니다.

참고: Redis 클러스터는 각각 홀수 개(3개 이상)의 노드로 배포되어야 합니다. 이는 Redis Sentinel이 퀘러럼의 일부로 투표를 수행할 수 있도록 하는 것입니다. 이는 클라우드 제공 업체 서비스 등 외부적으로 Redis를 구성하는 경우에는 해당되지 않습니다.

참고: Redis는 주로 단일 스레드이며 CPU 코어가 증가함에 따라 혜택을 거의 받지 않습니다. 이런 규모의 구조에 대해서는 최적의 성능을 위해 별도의 캐시와 영구 인스턴스가 권장됩니다. 자세한 내용은 스케일링 문서를 참조하세요.

Redis는 Sentinel과 함께 사용될 경우 인증이 필요합니다. 더 많은 정보를 원하신다면 Redis 보안 문서를 참조하세요. Redis 서비스를 보안하는 데 Redis 암호와 엄격한 방화벽 규칙의 조합을 권장합니다. Redis를 GitLab과 함께 구성하기 전에 Redis Sentinel 문서를 꼭 읽는 것을 권장드립니다.

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

모든 Redis 노드가 서로 통신하고 Redis(6379) 및 Sentinel(26379) 포트로 들어오는 연결을 수락해야 합니다 (기본값을 변경하지 않는 한).
GitLab 애플리케이션을 호스팅하는 서버가 Redis 노드에 액세스할 수 있어야 합니다.
외부 네트워크(인터넷)로부터 노드를 보호하기 위해 방화벽을 사용하세요.

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

10.6.0.51: Redis - 캐시 Primary
10.6.0.52: Redis - 캐시 Replica 1
10.6.0.53: Redis - 캐시 Replica 2
10.6.0.61: Redis - 영구 Primary
10.6.0.62: Redis - 영구 Replica 1
10.6.0.63: Redis - 영구 Replica 2

자체 Redis 인스턴스 제공

다음 안내에 따라 선택적으로 서드파티 외부 서비스를 사용하여 Redis Cache 및 Persistence 인스턴스를 사용할 수 있습니다:

이에 대해 신뢰할 수 있는 제공 업체 또는 솔루션이 사용되어야 합니다. Google Memorystore 및 AWS ElastiCache가 작동하는 것으로 알려져 있습니다.
Redis 클러스터 모드는 특별히 지원되지 않지만 HA가 있는 Redis Standalone은 지원됩니다.
설정에 따라 Redis 유출 모드를 설정해야 합니다.

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

Redis Cache 클러스터 구성

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

주 레디스 및 복제 레디스 노드는 모두 redis['password']에 정의된 동일한 암호가 필요합니다. 장애 조치 중에 언제든지 센티넬은 노드를 재구성하고 해당 상태를 주 또는 복제로 바꿀 수 있습니다.

주 레디스 캐시 노드 구성

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

/etc/gitlab/gitlab.rb 파일을 편집하고 다음 내용을 추가하세요:

# 센티넬이 있는 서버 역할 및 Consul 에이전트 사용으로 서버 역할 지정
roles(['redis_sentinel_role', 'redis_master_role', 'consul_role'])

# Redis 센티넬 서비스에 대한 IP 바인드 주소 및 쿼럼 번호 설정
sentinel['bind'] = '0.0.0.0'
sentinel['quorum'] = 2

# 다른 기계가 연결할 수 있는 로컬 IP를 가리키는 IP 주소입니다.
# 모든 인터페이스에서 청취하도록 bind를 설정하기도 합니다.
# 외부 접근 가능한 IP에 바인딩하는 경우,
# 무단 액세스를 방지하기 위해 추가 방화벽 규칙을 추가해야 합니다.
redis['bind'] = '10.6.0.51'

# Redis가 TCP 요청을 수신하도록 포트 정의. 이를 통해 다른 기계가 연결할 수 있습니다.
redis['port'] = 6379

# Redis 및 복제본을 위한 암호 인증 설정(모든 노드에서 동일한 암호 사용).
redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'

## 모든 Redis 노드에서 동일해야 함
redis['master_name'] = 'gitlab-redis-cache'

## 주 레디스 노드의 IP
redis['master_ip'] = '10.6.0.51'

# Redis 캐시 인스턴스를 LRU로 설정
# 사용 가능한 RAM의 90% (MB)
redis['maxmemory'] = '13500mb'
redis['maxmemory_policy'] = "allkeys-lru"
redis['maxmemory_samples'] = 5

## Prometheus에 대한 서비스 검색 활성화
consul['monitoring_service_discovery'] =  true

## Consul 서버 노드의 IP
## FQDN을 사용하거나 IP와 혼용하여 사용할 수 있습니다
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}

# 내보내기가 청취할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'
redis_exporter['flags'] = {
     'redis.addr' => 'redis://10.6.0.51:6379',
     'redis.password' => 'redis-password-goes-here',
}

# 업그레이드 시 자동으로 데이터베이스 마이그레이션을 방지
gitlab_rails['auto_migrate'] = false

첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버에 같은 이름의 파일을 추가 또는 교체하세요. 첫 번째로 구성하는 Linux 패키지 노드인 경우 이 단계를 건너뛰셔도 됩니다.
변경 사항이 적용되려면 GitLab을 다시 구성하세요.

복제본 Redis 캐시 노드 구성

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

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

# 센티넬이 있는 서버 역할 및 Consul 에이전트 사용으로 서버 역할 지정
roles(['roles_sentinel_role', 'redis_replica_role', 'consul_role'])

# Redis 센티넬 서비스에 대한 IP 바인드 주소 및 쿼럼 번호 설정
sentinel['bind'] = '0.0.0.0'
sentinel['quorum'] = 2

# 다른 기계가 연결할 수 있는 로컬 IP를 가리키는 IP 주소입니다.
# 모든 인터페이스에서 청취하도록 bind를 설정하기도 합니다.
# 외부 접근 가능한 IP에 바인딩하는 경우,
# 무단 액세스를 방지하기 위해 추가 방화벽 규칙을 추가해야 합니다.
redis['bind'] = '10.6.0.52'

# Redis가 TCP 요청을 수신하도록 포트 정의. 이를 통해 다른 기계가 연결할 수 있습니다.
redis['port'] = 6379

# Redis 및 복제본을 위한 암호 인증 설정(모든 노드에서 동일한 암호 사용).
redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'

## 모든 Redis 노드에서 동일해야 함
redis['master_name'] = 'gitlab-redis-cache'

## 주 레디스 노드의 IP
redis['master_ip'] = '10.6.0.51'

# Redis 캐시 인스턴스를 LRU로 설정
# 사용 가능한 RAM의 90% (MB)
redis['maxmemory'] = '13500mb'
redis['maxmemory_policy'] = "allkeys-lru"
redis['maxmemory_samples'] = 5

## Prometheus에 대한 서비스 검색 활성화
consul['monitoring_service_discovery'] =  true

## Consul 서버 노드의 IP
## FQDN을 사용하거나 IP와 혼용하여 사용할 수 있습니다
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}

# 내보내기가 청취할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'
redis_exporter['flags'] = {
     'redis.addr' => 'redis://10.6.0.52:6379',
     'redis.password' => 'redis-password-goes-here',
}

# 업그레이드 시 자동으로 데이터베이스 마이그레이션을 방지
gitlab_rails['auto_migrate'] = false

첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버에 같은 이름의 파일을 추가 또는 교체하세요. 첫 번째로 구성하는 Linux 패키지 노드인 경우 이 단계를 건너뛰셔도 됩니다.
변경 사항이 적용되려면 GitLab을 다시 구성하세요.
다른 복제본 노드에서도 같은 단계를 반복하고 IP를 올바르게 설정하는지 확인하세요.

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

Redis 영구 클러스터 구성

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

주 및 복제 Redis 노드는 언제든지 장애 조치(failover) 중에 Sentinels가 노드를 다시 구성하고 해당 노드의 상태를 주(primary) 또는 복제(replica)로 변경할 수 있습니다.

주 Redis 영구 노드 구성

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

/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를 지정합니다.
# 모든 인터페이스에서 수신 대기하도록 바인드를 '0.0.0.0'로 설정할 수도 있습니다.
# 외부 접근 가능한 IP에 바인드하려면 무단 접근을 방지하는 추가 방화벽 규칙을 추가해야 합니다.
redis['bind'] = '10.6.0.61'

# 기타 머신에서 Redis에 연결할 수 있도록 TCP 요청 수신을 위해 Redis가 수신 대기할 수 있도록 포트를 정의합니다.
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-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

첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버에 같은 이름의 파일을 추가하거나 교체합니다. 이것이 구성 중인 첫 번째 Linux 패키지 노드인 경우 이 단계를 생략할 수 있습니다.
변경 사항이 적용되려면 GitLab을 재구성합니다.

복제 Redis 영구 노드 구성

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

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

# Sentinel 및 Consul 에이전트를 사용하여 서버 역할을 'redis_replica_role'로 지정하고 활성화
roles ['redis_sentinel_role', 'redis_replica_role', 'consul_role']

# Redis Sentinel 서비스의 IP 바인드 주소 및 판결 과반수(Quorum) 번호를 지정합니다.
sentinel['bind'] = '0.0.0.0'
sentinel['quorum'] = 2

# 다른 모든 머신에서 접근할 수 있는 로컬 IP를 지정합니다.
# 모든 인터페이스에서 수신 대기하도록 바인드를 '0.0.0.0'로 설정할 수도 있습니다.
# 외부 접근 가능한 IP에 바인드하려면 무단 접근을 방지하는 추가 방화벽 규칙을 추가해야 합니다.
redis['bind'] = '10.6.0.62'

# 기타 머신에서 Redis에 연결할 수 있도록 TCP 요청 수신을 위해 Redis가 수신 대기할 수 있도록 포트를 정의합니다.
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-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

첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버에 같은 이름의 파일을 추가하거나 교체합니다. 이것이 구성 중인 첫 번째 Linux 패키지 노드인 경우 이 단계를 생략할 수 있습니다.
변경 사항이 적용되려면 GitLab을 재구성합니다.
다른 복제 노드에 대해 위의 단계를 다시 거치고 IP를 올바르게 설정하는지 확인합니다.

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

구성 요소 설정으로 이동

Gitaly 클러스터 구성

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

경고: Gitaly 사양은 사용 패턴 및 리포지토리 크기의 상위 백분율에 기반합니다. 그러나, 큰 단일 리포지토리(여러 기가바이트보다 큰) 또는 추가 작업 부하가 있는 경우, 환경의 성능에 상당한 영향을 미칠 수 있으며 추가 조정이 필요할 수 있습니다. 이 경우, 링크된 설명서를 참조하고 추가 지침을 위해 고객 성공 매니저 또는 지원팀에 연락하는 것을 강력히 권장합니다.

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

구성 안내:

샤드로 구성된 Gitaly를 구현하려면 별도의 Gitaly 문서를 참고하세요. 이 구역 대신 사용하세요. 동일한 Gitaly 사양을 사용합니다.
Gitaly 클러스터에서 관리되지 않는 기존 저장소를 이전하려면 Gitaly 클러스터로 이전을 참조하세요.

추천하는 클러스터 구성에는 다음 구성 요소가 포함됩니다:

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

이 섹션에서는 권장되는 표준 구성 방법을 차례대로 설명합니다. 더 고급화된 설정에 대해서는 독립 Gitaly 클러스터 문서를 참조하십시오.

Praefect PostgreSQL 구성

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

고가용성 구성을 원할 경우 Praefect에는 타사 PostgreSQL 데이터베이스가 필요합니다. 내장된 솔루션이 진행 중입니다.

Praefect 비-HA PostgreSQL Linux 패키지 단독 사용

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

10.6.0.141: Praefect PostgreSQL

먼저, Praefect PostgreSQL 노드에 Linux GitLab 패키지를 설치하십시오. 이후 단계를 따라 진행하여 1단계에서 필요한 종속성을 설치하고 2단계에서 GitLab 패키지 저장소를 추가하십시오. 두 번째 단계에서 GitLab을 설치할 때 EXTERNAL_URL 값을 제공하지 않습니다.

Praefect PostgreSQL 노드에 SSH로 연결합니다.
Praefect PostgreSQL 사용자에 사용할 강력한 암호를 생성합니다. 이 비밀번호를 <praefect_postgresql_password>로 참고하세요.
Praefect PostgreSQL 사용자/암호 쌍의 암호 해시를 생성합니다. 이때 기본 사용자를 praefect로 사용할 것으로 가정합니다(권장). 해당 명령은 암호 <praefect_postgresql_password>와 확인을 요청할 것입니다. 이 명령의 출력 값을 다음 단계의 <praefect_postgresql_password_hash> 값으로 사용하세요:
```
sudo gitlab-ctl pg-password-md5 praefect
```

/etc/gitlab/gitlab.rb를 편집하여 # START user configuration 섹션에서 기존 값들을 대체합니다:

# PostgreSQL 및 Consul 외의 모든 구성 요소 비활성화
roles(['postgres_role', 'consul_role'])

# PostgreSQL 구성
postgresql['listen_address'] = '0.0.0.0'

# 업그레이드 시 데이터베이스 마이그레이션 자동 실행 방지
gitlab_rails['auto_migrate'] = false

# Consul 에이전트 구성
## Prometheus를 위한 서비스 검색 활성화
consul['monitoring_service_discovery'] =  true

# START user configuration
# Required Information 섹션에 설명된 대로 실제 값을 설정하십시오
#
# 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

첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하고 이 서버의 동일한 이름의 파일을 추가하거나 교체하십시오. 이가 처음 구성하는 첫 번째 Linux 패키지 노드이면이 단계를 건너뛰어도 됩니다.
변경 사항이 적용되려면 GitLab 재구성을 진행하십시오.
포스트 구성을 참조하십시오.

구성 요소 설정으로 돌아가기

Praefect HA PostgreSQL 제 3자 솔루션

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

PostgreSQL HA를 위한 많은 제3자 솔루션이 있습니다. Praefect와 함께 작동하려면 선택한 솔루션이 다음 사항을 갖추고 있어야합니다:

장애 조치(failover)시 변경되지 않는 모든 연결에 대한 정적 IP.
LISTEN SQL 기능 지원.

참고: 제3자 설정으로 메인 GitLab 데이터베이스 제공 이후 편의를 위해 Praefect의 데이터베이스를 메인 데이터베이스와 동일한 서버에 위치시킬 수 있지만, 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>로 구성한 것과 동일합니다.

이것은 리눅스 패키지 PostgreSQL 설정으로 작동하는 방식입니다: 1. Praefect PostgreSQL 노드에 SSH합니다. 1. PostgreSQL 서버에 관리 액세스로 연결합니다. 리눅스 패키지에서 기본적으로 추가되는 gitlab-psql 사용자가 여기에 사용되어야 합니다. template1 데이터베이스는 모든 PostgreSQL 서버에 기본적으로 생성되어 있기 때문에 이것을 사용합니다.

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

새 사용자 praefect를 생성합니다. (<praefect_postgresql_password>를 대체하십시오.)
```
CREATE ROLE praefect WITH LOGIN CREATEDB PASSWORD '<praefect_postgresql_password>';
```

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

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

새 데이터베이스 praefect_production을 생성합니다.
```
CREATE DATABASE praefect_production WITH ENCODING=UTF8;
```

구성 요소 설정으로 돌아가기

Praefect 구성

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

참고: Praefect는 반드시 3개 이상의 홀수 개수의 노드에 배포되어야 합니다. 이는 퀄러럼의 일부로 투표를 할 수 있도록 보증하기 위한 것입니다.

Praefect에는 클러스터 내 통신을 보안하기 위한 여러 기밀 토큰이 필요합니다:

<praefect_external_token>: 귀하의 Gitaly 클러스터에 호스팅되는 저장소에 사용되며 해당 토큰을 가진 Gitaly 클라이언트만 액세스할 수 있습니다.
<praefect_internal_token>: 귀하의 Gitaly 클러스터 내 복제 트래픽에 사용됩니다. 이는 praefect_external_token과 구분되어야 합니다. 왜냐하면 Gitaly 클라이언트는 Praefect 클러스터의 내부 노드에 직접 액세스해서는 안 되기 때문입니다; 그렇게 되면 데이터 손실이 발생할 수 있습니다.
<praefect_postgresql_password>: 이전 섹션에서 정의한 Praefect PostgreSQL 암호이기도 합니다.

Gitaly 클러스터 노드는 가상 스토리지(virtual storage)를 통해 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 노드를 구성하려면 각 노드에서:

Praefect 서버에 SSH합니다.
선택한 리눅스 패키지를 다운로드 및 설치합니다. 페이지의 설치 단계 1과 2만 따르십시오.

/etc/gitlab/gitlab.rb 파일을 편집하여 Praefect를 구성하세요:

참고: 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
## 프로메테우스를 위한 서비스 디스커버리 활성화
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,
      dbname: 'praefect_production',
      user: 'praefect',
      password: '<praefect_postgresql_password>',
   },
   # Praefect Virtual Storage 구성
   # 저장소 해시의 이름은 GitLab 서버('praefect')의 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['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),
}
#
# 사용자 구성 끝

첫 번째 리눅스 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 해당 파일을 추가하거나 대체합니다. 이것이 구성하는 첫 번째 리눅스 패키지 노드인 경우 이 단계를 건너뛰어도 됩니다.
Praefect에는 main GitLab 애플리케이션과 마찬가지로 데이터베이스 마이그레이션을 실행해야 합니다. 이에 대비하여 마이그레이션을 실행할 Praefect 노드 하나를 선택해야합니다. 이를 배포 노드 라고 합니다. 이 노드는 다음과 같이 설정되어 있는 노드여야하며 다른 노드보다 먼저 구성되어야합니다:
1. /etc/gitlab/gitlab.rb 파일에서 praefect['auto_migrate'] 설정 값을 false에서 true로 변경합니다.
2. 업그레이드 시 자동으로 데이터베이스 마이그레이션이 실행되지 않도록 하려면 다음 명령을 실행합니다:
```
 sudo touch /etc/gitlab/skip-auto-reconfigure
```
1. 변경 사항이 적용되고 Praefect 데이터베이스 마이그레이션을 실행하려면, GitLab 재구성을 실행합니다.
변경 사항을 적용하려면 다른 Praefect 노드에 대해 GitLab 재구성을 실행하세요.

Gitaly 구성

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

경고: Gitaly 사양은 사용 패턴 및 리포지토리 크기의 높은 백분위수를 기반으로 합니다. 그러나, 대형 모노 리포(여러 기가바이트보다 큼) 또는 추가 작업량이 있는 경우 환경의 성능에 뚜렷한 영향을 미칠 수 있으며 추가 조정이 필요할 수 있습니다. 이에 해당하는 경우 해당 문서 및 고객 성공 담당자 또는 지원팀에 문의하여 추가 지침을 받는 것을 강력히 권장합니다.

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

기본적으로 Gitaly 서버의 네트워크 트래픽은 암호화되지 않으므로, 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

각 노드에서:

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

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 인증 토큰
      # 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,
   },
}

#
# 사용자 구성 끝

각 해당 서버에 대해 /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',
      },
   ],
}

첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 동일한 이름의 파일을 추가하거나 교체합니다. 이번이 처음 구성하는 Linux 패키지 노드라면 이 단계는 건너뛸 수 있습니다.
파일을 저장한 후 GitLab을 다시 구성합니다.

Gitaly Cluster TLS 지원

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

GitLab 구성에서 해당 storage 항목의 gitaly_address에 tls:// URL scheme을 사용해야 합니다.
자동으로 제공되지 않으므로 자체 인증서를 지참해야 합니다. 각 Praefect 서버에 해당하는 인증서를 설치해야 합니다.

또한 인증서 또는 해당 인증서 기관은 모든 Gitaly 서버와 그와 통신하는 모든 Praefect 클라이언트에 설치되어야 하며, GitLab 사용자 정의 인증서 구성에 설명된 절차를 준수해야 합니다.

다음 사항을 유의해야 합니다:

인증서에는 Praefect 서버에 액세스하는 데 사용하는 주소를 지정해야 합니다. 호스트명 또는 IP 주소를 인증서의 대체 주소로 추가해야 합니다.
Praefect 서버는 암호화되지 않은 리스닝 주소 listen_addr 및 암호화된 리스닝 주소 tls_listen_addr를 동시에 구성할 수 있습니다. 필요한 경우 암호화되지 않은 트래픽에서 암호화된 트래픽으로의 점진적인 전환이 가능합니다. 암호화되지 않은 리스너를 비활성화하려면 praefect['configuration'][:listen_addr] = nil을 설정하십시오.
내부 로드 밸런서도 인증서에 액세스해야 하며 TLS 통과를 허용하도록 구성해야 합니다. 이에 대한 자세한 내용은 로드 밸런서 설명서를 참조하십시오.

TLS로 Praefect를 구성하려면:

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

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

/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',
   },
}

파일을 저장하고 재구성합니다.
각 Praefect 클라이언트(각 Gitaly 서버 포함)에서 인증서를 /etc/gitlab/trusted-certs로 복사합니다.
```
sudo cp cert.pem /etc/gitlab/trusted-certs/
```

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'
  }
})

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

구성 요소 설정으로 돌아가기

Sidekiq 구성

Sidekiq는 Redis, PostgreSQL, Gitaly 인스턴스에 연결을 필요로 합니다. 또한 객체 저장소에 연결하는 것이 권장됩니다.

참고: 객체 저장소를 사용하는 것이 권장됩니다 (데이터 객체에 대한 NFS 대신). 따라서 아래 예제에 객체 저장소 구성이 포함되어 있습니다.

참고: 환경의 Sidekiq 작업 처리가 큐가 길어 느린 경우 적절하게 확장할 수 있습니다. 자세한 내용은 확장 설명서를 참조하십시오.

참고: 부가적인 GitLab 기능(컨테이너 레지스트리, SAML, 또는 LDAP와 같은)을 구성할 때는 Rails 구성 외에도 Sidekiq 구성을 업데이트해야 합니다. 자세한 내용은 외부 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 노드를 구성하려면 각 노드에서 다음을 수행합니다:

Sidekiq 서버에 SSH로 연결합니다.

PostgreSQL, Gitaly, 및 Redis 포트에 액세스할 수 있는지 확인합니다:

telnet <GitLab 호스트> 5432 # PostgreSQL
telnet <GitLab 호스트> 8075 # Gitaly
telnet <GitLab 호스트> 6379 # Redis

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

/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>@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>'

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_사용자_암호>'
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['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-프로젝트-이름>',
  'google_json_key_location' => '<gcp-서비스-계정-키-경로>'
}
gitlab_rails['object_store']['objects']['artifacts']['bucket'] = "<gcp-아티팩트-버킷-이름>"
gitlab_rails['object_store']['objects']['external_diffs']['bucket'] = "<gcp-외부-차이점-버킷-이름>"
gitlab_rails['object_store']['objects']['lfs']['bucket'] = "<gcp-lfs-버킷-이름>"
gitlab_rails['object_store']['objects']['uploads']['bucket'] = "<gcp-업로드-버킷-이름>"
gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-버킷-이름>"
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-의존성-프록시-버킷-이름>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-테라폼-상태-버킷-이름>"

gitlab_rails['backup_upload_connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-프로젝트-이름>',
  'google_json_key_location' => '<gcp-서비스-계정-키-경로>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-백업-상태-버킷-이름>"

gitlab_rails['ci_secure_files_object_store_enabled'] = true
gitlab_rails['ci_secure_files_object_store_remote_directory'] = "gcp-ci_secure_files-버킷-이름"

gitlab_rails['ci_secure_files_object_store_connection'] = {
   'provider' => 'Google',
   'google_project' => '<gcp-프로젝트-이름>',
   'google_json_key_location' => '<gcp-서비스-계정-키-경로>'
}

첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하거나 추가하여이 서버에 동일한 이름의 파일을 추가하거나 교체합니다. 이것이 구성하는 첫 번째 Linux 패키지 노드인 경우 이 단계는 건너뛸 수 있습니다.
데이터베이스 마이그레이션을 자동으로 업그레이드시 자동으로 실행하지 않도록하려면 다음을 실행하십시오:
```
sudo touch /etc/gitlab/skip-auto-reconfigure
```
명시된 노드 중 하나만 자세한 내용은 GitLab Rails 후 구성 섹션에서 설명되었습니다. 마이그레이션을 처리해야 합니다.
변경 사항이 적용되려면 GitLab을 재구성합니다.

구성 요소 설정으로 돌아가기

GitLab Rails 구성

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

Rails는 Redis, PostgreSQL 및 Gitaly 인스턴스에 연결이 필요합니다. 또한 추천된 대로 Object Storage에 연결해야 합니다.

참고: 데이터 객체에 대해 NFS 대신 Object Storage를 사용하는 것이 권장되므로, 다음 예제에는 Object Storage 구성이 포함됩니다.

다음 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

각 노드에서 다음을 수행합니다:

선택한 Linux 패키지를 다운로드 및 설치합니다. 페이지의 설치 단계 1 및 2를 따르세요.

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

external_url 'https://gitlab.example.com'

# 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>'
  }
})

## GitLab 애플리케이션 서버에 없을 구성 요소를 비활성화합니다.
roles(['application_role'])
gitaly['enable'] = false
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 IP

# 업그레이드시 자동 실행되지 않도록 데이터베이스 마이그레이션을 방지합니다.
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']

#############################
###     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>'
}

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

git_data_dirs({
  "default" => {
    "gitaly_address" => "tls://10.6.0.40:2305", # 내부 로드 밸런서 IP
    "gitaly_token" => '<praefect_external_token>'
  }
})

/etc/gitlab/trusted-certs로 인증서를 복사합니다.:

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

첫 번째 Linux 패키지 노드로부터 /etc/gitlab/gitlab-secrets.json 파일을 복사하여이 서버의 동일한 이름의 파일을 추가하거나 교체합니다. 이게 첫 번째로 구성하는 Linux 패키지 노드이면이 단계를 건너 뛰어도 됩니다.
데이터베이스 마이그레이션이 업그레이드시 자동으로 실행되지 않고 reconfigure에서만 실행되도록 하려면 다음을 실행하세요:
```
sudo touch /etc/gitlab/skip-auto-reconfigure
```
지정된 노드 한 대만 GitLab Rails 사후 구성 섹션에서 설명한대로 마이그레이션을 처리해야 합니다.
변경 사항이 적용되려면 GitLab 재구성을 실행하세요.
증분 로깅을(enable incremental logging) 활성화합니다.
노드가 Gitaly에 연결할 수 있는지 확인하세요:
```
sudo gitlab-rake gitlab:gitaly:check
```
그런 다음 요청을 보기 위해 로그를 확인합니다.:
```
sudo gitlab-ctl tail gitaly
```
옵션으로 Gitaly 서버에서 Gitaly가 내부 API로 콜백을 수행할 수 있는지 확인합니다.:
- GitLab 15.3 버전 이상의 경우 sudo -u git -- /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml을 실행합니다.
- GitLab 15.2 버전 이하의 경우 sudo -u git -- /opt/gitlab/embedded/bin/gitaly-hooks check /var/opt/gitlab/gitaly/config.toml을 실행합니다.

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

GitLab Rails 포스트 구성

설치 및 업데이트 중에 데이터베이스 마이그레이션을 실행할 애플리케이션 노드를 지정하세요. GitLab 데이터베이스를 초기화하고 모든 마이그레이션이 실행되었는지 확인하세요:
```
sudo gitlab-rake gitlab:db:configure
```
이 작업에는 Rails 노드가 주 데이터베이스에 직접 연결하도록 설정해야 합니다. 마이그레이션이 완료되면 노드를 다시 PgBouncer를 통과하도록 설정해야 합니다.
데이터베이스에서 권한이 부여된 SSH 키를 빠르게 조회하도록 설정하십시오.

구성 요소 설정으로 돌아가기

프로메테우스 구성

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

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

10.6.0.151: 프로메테우스

모니터링 노드를 구성하려면 다음을 수행하세요:

모니터링 노드에 SSH로 로그인합니다.
선택한 Linux 패키지를 다운로드하고 설치합니다. 페이지에서 단계 1과 2를 오직 따르도록 하세요.

/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

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

구성 요소 설정으로 돌아가기

객체 저장소 구성

GitLab은 여러 유형의 데이터를 보관하기 위해 객체 저장소 서비스를 사용하는 것을 지원합니다. 데이터 객체에 대해 NFS 대신하여 권장되며, 일반적으로 더 많은 성능, 신뢰성 및 확장 가능성을 갖고 있습니다. 자세한 내용은 권장 클라우드 제공업체 및 서비스를 참조하십시오.

GitLab에서 객체 저장소 구성을 지정하는 두 가지 방법이 있습니다:

통합된 형태: 모든 지원되는 객체 유형이 공유 자격 증명을 사용합니다.
저장소별 형태: 각 객체가 고유한 객체 저장소 연결 및 구성을 정의합니다.

통합된 형태는 가능한 경우 사용됩니다.

각 데이터 유형에 대해 별도의 버킷을 사용하는 것이 권장되는 방식입니다. 이렇게 함으로써 GitLab이 저장하는 다양한 유형의 데이터 간에 충돌이 없도록 보장할 수 있습니다. 향후 단일 버킷 사용을 활성화하는 계획이 있습니다.

구성 요소 설정으로 돌아가기

증분 로깅 활성화

GitLab 러너는 작업 로그를 청크 단위로 반환하며 기본적으로 /var/opt/gitlab/gitlab-ci/builds에서 임시로 캐시합니다. 통합 객체 저장소를 사용할 때라도 디렉토리가 기본적으로 GitLab Rails 및 Sidekiq 노드의 NFS를 통해 공유되어야 합니다.

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

고급 검색 구성

Elasticsearch를 사용하여 고급 검색 활성화를 활용할 수 있습니다. 이를 통해 전체 GitLab 인스턴스에서 빠르고 더 진보한 코드 검색을 수행할 수 있습니다.

Elasticsearch 클러스터 디자인 및 요구 사항은 특정 데이터에 따라 다를 수 있습니다. Elasticsearch 클러스터 구성에 대한 추천 사항은 최적 클러스터 구성 선택을 읽어보세요.

구성 요소 설정으로 돌아가기

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

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

하이브리드 설치는 클라우드 네이티브 및 전통적인 컴퓨팅 배포의 이점을 활용합니다. 이렇게 함으로써 무상태 컴포넌트는 클라우드 네이티브 워크로드 관리 이점을 얻을 수 있으며 상태ful 컴포넌트는 Linux 패키지 설치를 통해 증가된 지속성을 가져다 줍니다.

Kubernetes 및 백엔드 컴포넌트 간에 동기화할 GitLab 비밀을 어떻게 설정할지에 대한 안내를 포함하여 설정 지침에 대한 Helm 차트 고급 구성 문서를 참조하세요.

참고: 이것은 고급 설정입니다. Kubernetes에서 서비스를 실행하는 것은 복잡하다는 것이 잘 알려져 있습니다. Kubernetes에 강력한 지식과 경험이 있는 경우에만 이 설치를 권장합니다. 이 섹션의 나머지 부분은 이것을 전제로 합니다.

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

클러스터 토폴로지

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

우선, Kubernetes에서 실행되는 구성 요소입니다. 이러한 구성 요소는 여러 노드 그룹에서 실행되지만, 전체적인 구성은 변경할 수 있으며 최소 CPU 및 Memory 요구 사항을 준수한다면 원하는 대로 변경할 수 있습니다.

Component Node Group	Target Node Pool Totals	GCP Example	AWS Example
Webservice	308 vCPU 385 GB memory (request) 539 GB memory (limit)	11 x `n1-standard-32`	11 x `c5.9xlarge`
Sidekiq	12.6 vCPU 28 GB memory (request) 56 GB memory (limit)	4 x `n1-standard-4`	4 x `m5.xlarge`
Supporting services	8 vCPU 30 GB memory	2 x `n1-standard-4`	2 x `m5.xlarge`

이 설정에 대해 우리는 일반적으로 Google Kubernetes Engine (GKE) 및 Amazon Elastic Kubernetes Service (EKS)에서 테스트 및 권장하고 있습니다. 다른 Kubernetes 서비스도 작동할 수 있지만 실제로 작동하는지는 달라질 수 있습니다.
대상 노드 풀 총 수를 달성하는 방법으로 GCP 및 AWS 예시가 편리하게 제공됩니다. 이러한 크기는 성능 테스트에 사용되지만 예시를 따를 필요는 없습니다. 다른 노드 풀 디자인을 원하는 대로 사용할 수 있습니다. 단, 목표를 달성하고 모든 팟을 배포할 수 있는 한.
Webservice 및 Sidekiq 대상 노드 풀 총 수는 GitLab 구성 요소에 대해서만 제공됩니다. 추가 리소스는 선택한 Kubernetes 제공자의 시스템 프로세스에 필요합니다. 제공된 예시는 이를 고려하고 있습니다.
Supporting 대상 노드 풀 총 수는 GitLab 배포 및 요구 사항에 따라 추가 배포를 원하는 경우 GitLab 배포를 지원하기 위한 여러 리소스를 수용하기 위해 일반적으로 제공됩니다. 다른 노드 풀과 마찬가지로, 선택한 Kubernetes 제공자의 시스템 프로세스도 리소스를 필요로 합니다. 제공된 예시는 이를 고려하고 있습니다.
프로덕션 배포에서는 팟을 특정 노드에 할당할 필요는 없지만, 강력한 클라우드 아키텍처 관행에 따라 서로 다른 가용 영역에 걸쳐 여러 노드를 보유하는 것이 권장됩니다.
클러스터 오토 스케일링(Cluster Autoscaler)과 같은 효율성을 위한 오토스케일링을 활성화하는 것이 권장되지만, 일반적으로 Webservice 및 Sidekiq 팟의 75%를 타겟으로 하는 것이 지속적인 성능을 보장하기 위해 권장됩니다.

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

Service	Nodes	Configuration	GCP	AWS
Consul¹	3	2 vCPU, 1.8 GB memory	`n1-highcpu-2`	`c5.large`
PostgreSQL¹	3	32 vCPU, 120 GB memory	`n1-standard-32`	`m5.8xlarge`
PgBouncer¹	3	2 vCPU, 1.8 GB memory	`n1-highcpu-2`	`c5.large`
Internal load balancer³	1	16 vCPU, 14.4 GB memory	`n1-highcpu-16`	`c5.4xlarge`
Redis/Sentinel - Cache²	3	4 vCPU, 15 GB memory	`n1-standard-4`	`m5.xlarge`
Redis/Sentinel - Persistent²	3	4 vCPU, 15 GB memory	`n1-standard-4`	`m5.xlarge`
Gitaly⁵	3	64 vCPU, 240 GB memory⁶	`n1-standard-64`	`m5.16xlarge`
Praefect⁵	3	4 vCPU, 3.6 GB memory	`n1-highcpu-4`	`c5.xlarge`
Praefect PostgreSQL¹	1+	2 vCPU, 1.8 GB memory	`n1-highcpu-2`	`c5.large`
Object storage⁴	-	-	-	-

각주:

신뢰할 수 있는 타사 외부 PaaS PostgreSQL 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 자체 PostgreSQL 인스턴스 제공를 참조하십시오.
신뢰할 수 있는 타사 외부 PaaS Redis 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 자체 Redis 인스턴스 제공를 참조하십시오.
- Redis는 주로 단일 쓰레드이며 CPU 코어 증가로부터 크게 이득을 보지 못합니다. 이런 규모의 아키텍처에서는 최적의 성능을 얻기 위해 별도의 캐시 및 지속적인 인스턴스를 따로 지정하는 것이 강력히 권장됩니다.
신뢰할 수 있는 타사 로드 밸런싱 서비스(LB PaaS)에서 선택적으로 실행할 수 있습니다. 자세한 내용은 권장 클라우드 제공자 및 서비스를 참조하십시오.
신뢰할 수 있는 클라우드 제공 업체 또는 자체 관리 솔루션에서 실행할 수 있습니다. 자세한 내용은 객체 스토리지 구성를 참조하십시오.
Gitaly 클러스터는 고장 허용의 장점을 제공하지만 추가 설치 및 관리의 복잡성을 수반합니다. Gitaly 클러스터 배포 전 기술적 한계 및 고려사항을 검토하십시오. 샤딩된 Gitaly를 사용하려면 Gitaly에 나열된 동일한 사양을 사용하십시오.
Gitaly 사양은 건강한 상태에서의 사용 패턴 및 저장소 크기의 높은 백분위수에 기초합니다. 그러나 대형 단일 저장소 (여러 기가바이트보다 큼) 또는 추가 워크로드를 보유하고 있다면 Git 및 Gitaly 성능에 상당한 영향을 끼칠 것으로 예상되며 추가 조정이 필요할 것입니다.

참고: 인스턴스 구성을 포함하는 모든 PaaS 솔루션의 경우, 강력한 클라우드 아키텍처 관행에 따라 서로 다른 가용 영역에 총 세 개의 노드를 구현하는 것이 권장됩니다.

Kubernetes 구성 요소 대상

다음 섹션은 Kubernetes에 배포된 GitLab 구성 요소에 사용된 대상을 상세히 설명합니다.

Webservice

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

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

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

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

NGINX

Webservice 노드 전체에 NGINX 컨트롤러 팟을 데몬세트로 배포하는 것이 좋습니다. 이렇게 함으로써 컨트롤러가 제공하는 Webservice 팟의 크기에 따라 동적으로 확장되고 일반적으로 더 큰 머신 유형에서 이점을 얻을 수 있습니다.

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

Sidekiq

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

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

표준 배포와 유사하게 여기에서 14개의 Sidekiq worker를 초기 대상으로 사용했습니다. 작업 흐름에 따라 추가 작업이 필요할 수 있습니다.

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

지원

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

이는 클라우드 제공 업체의 구현 및 GitLab Shell과 같은 지원 GitLab 배포와 관련된 여러 배포를 포함합니다.

컨테이너 레지스트리, 페이지 또는 모니터링과 같이 추가적인 배포를 원하는 경우, 가능하면 이러한 배포를 이 풀에 배포하는 것이 좋습니다. 또한, 지원 풀은 몇 가지 추가적인 배포를 수용하기 위해 특별히 설계되었으므로, 사용 가능한 경우 Webservice 또는 Sidekiq 풀이 아닌 이 풀에 배포하는 것이 좋습니다. 그러나 사용 사례에 맞게 풀이 오버 프로비저닝된 경우 풀을 줄일 수도 있습니다.

구성 파일 예시

위의 1000 RPS 또는 50,000 참조 구조에 대한 GitLab Helm Charts 예시 구성 Charts 프로젝트에서 찾을 수 있습니다.

구성 요소 설정으로 돌아가기

다음 단계

이 안내를 따르면 핵심 기능이 구성된 새로운 GitLab 환경을 갖게 될 것입니다.

요구 사항에 따라 GitLab의 추가적인 선택적 기능을 구성하려는 경우 해당합니다. 자세한 정보는 GitLab 설치 후 단계를 참조하십시오.

참고: 환경 및 요구 사항에 따라 원하는 추가 기능을 설정하려면 추가 하드웨어 요구 사항이나 조정이 필요할 수 있습니다. 자세한 내용은 각 페이지를 참조하십시오.

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

요구 사항

테스트 방법론

구성 요소 설정

외부 로드 밸런서 구성

준비 상태 확인

포트

대체 SSH 포트

SSL

응용 프로그램 노드가 SSL을 종료

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

로드 밸런서가 백엔드 SSL을 사용하여 SSL을 종료

내부 로드 밸런서 구성

Consul 구성

PostgreSQL 구성

자체 PostgreSQL 인스턴스 제공

독립적인 Linux 패키지 사용 PostgreSQL

PostgreSQL 노드

PostgreSQL 사후 구성

PgBouncer 구성

Redis 구성

자체 Redis 인스턴스 제공

Redis Cache 클러스터 구성

주 레디스 캐시 노드 구성

복제본 Redis 캐시 노드 구성

Redis 영구 클러스터 구성

주 Redis 영구 노드 구성

복제 Redis 영구 노드 구성

Gitaly 클러스터 구성

Praefect PostgreSQL 구성

Praefect 비-HA PostgreSQL Linux 패키지 단독 사용

Praefect HA PostgreSQL 제 3자 솔루션

Praefect PostgreSQL 포스트 구성

Praefect 구성

Gitaly 구성

Gitaly Cluster TLS 지원

Sidekiq 구성

GitLab Rails 구성

GitLab Rails 포스트 구성

프로메테우스 구성

객체 저장소 구성

증분 로깅 활성화

고급 검색 구성

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

클러스터 토폴로지

Kubernetes 구성 요소 대상

Webservice

NGINX

Sidekiq

지원

구성 파일 예시

다음 단계

도움말

기능 사용 가능성과 제품 평가판

도움받기