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

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

Tier: Premium, Ultimate Offering: Self-managed

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

참조 아키텍처의 전체 목록은
사용 가능한 참조 아키텍처를 참조하세요.

이 아키텍처를 배포하기 전에 주요 문서를 먼저 읽는 것이 권장됩니다,
특히 시작하기 전에 및 어떤 아키텍처를 사용할지 결정하기 섹션을 참조하십시오.

목표 부하: API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS

고가용성: 예 (Praefect는 HA를 위한 서드파티 PostgreSQL 솔루션이 필요함)

비용 계산기 템플릿: 비용 계산기 템플릿 섹션 보기

클라우드 네이티브 하이브리드 대안: 예

어떤 참조 아키텍처를 사용해야 할지 확실하지 않으신가요? 이 가이드를 통해 추가 정보를 얻으세요

서비스	노드	구성	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 코어 수를 증가시켜도 크게 이점을 얻지 못합니다. 이 크기의 아키텍처에서는 최적의 성능을 달성하기 위해 캐시 및 영구 인스턴스를 분리하여 구성하는 것이 강력히 권장됩니다.
검증된 서드파티 로드 밸런싱 서비스(LB PaaS)에서 선택적으로 실행할 수 있습니다. 추천 클라우드 제공업체 및 서비스에 대한 자세한 내용은 참고하십시오.
신뢰할 수 있는 클라우드 제공업체 또는 자사 관리 솔루션에서 실행해야 합니다. 객체 저장소 구성하기에 대한 자세한 내용은 참고하십시오.
Gitaly 클러스터는 내결함성의 이점을 제공하지만 설정 및 관리의 복잡성이 추가됩니다.
Gitaly 클러스터를 배포하기 전에 기존의 기술적 한계 및 고려사항을 검토하십시오. 분할된 Gitaly를 원한다면, 위에 명시된 Gitaly와 동일한 사양을 사용하십시오.
Gitaly 사양은 사용 패턴과 양호한 상태의 저장소 크기를 기준으로 하는 높은 백분위수를 기반으로 합니다.
그러나 대형 모노레포(수 기가바이트 이상) 또는 추가 작업 부하가 있는 경우 Git 및 Gitaly 성능에 상당히 영향을 미치며 추가 조정이 필요할 수 있습니다.
이 구성 요소는 어떤 상태 저장 데이터를 저장하지 않으므로 오토 스케일링 그룹(ASG)에 배치할 수 있습니다.
그러나 특정 구성 요소가 하나의 노드에서만 실행될 수 있으므로 클라우드 네이티브 하이브리드 설정이 일반적으로 더 선호됩니다.

인스턴스 구성을 포함하는 모든 PaaS 솔루션의 경우, 복원력 있는 클라우드 아키텍처 관행에 맞게 서로 다른 가용 영역에 최소 3개의 노드를 구현하는 것이 권장됩니다.

요구사항

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

테스트 방법론

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

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

위의 목표는 사용자 수에 해당하는 총 환경 부하에 대한 실제 고객 데이터를 기반으로 선택되었습니다,
CI 및 기타 작업 부하를 포함합니다.

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

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

테스트에 사용된 로드 밸런서는 Linux 패키지 환경의 HAProxy 또는
클라우드 네이티브 하이브리드를 위한 NGINX Ingress를 갖춘 동등한 클라우드 제공업체 서비스입니다.
이 선택은 특정 요구 사항이나 권장 사항을 나타내지 않으며 대부분의
신뢰할 수 있는 로드 밸런서가 작동할 것으로 예상됩니다.

구성 요소 설정

최대 1000 RPS 또는 50,000 사용자를 수용하기 위해 GitLab 및 그 구성 요소를 설정하려면:

외부 로드 밸런서 구성
GitLab 애플리케이션 서비스 노드의 로드 밸런싱을 처리합니다.
내부 로드 밸런서 구성
GitLab 애플리케이션 내부 연결의 로드 밸런싱을 처리합니다.
Consul 구성
서비스 검색 및 상태 점검을 위해.
PostgreSQL 구성,
GitLab을 위한 데이터베이스.
PgBouncer 구성
데이터베이스 연결 풀 및 관리.
Redis 구성,
세션 데이터, 임시 캐시 정보 및 백그라운드 작업 큐를 저장합니다.
Gitaly 클러스터 구성,
Git 리포지토리에 대한 액세스를 제공합니다.
Sidekiq 구성
백그라운드 작업 처리를 위해.
주요 GitLab Rails 애플리케이션 구성
Puma, Workhorse, GitLab Shell을 실행하고, 모든 프론트엔드 요청(UI, API, HTTP/SSH를 통한 Git)을 제공합니다.
Prometheus 구성
GitLab 환경을 모니터링합니다.
객체 저장소 구성
공유 데이터 객체를 위해 사용됩니다.
고급 검색 구성 (선택적)
전체 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 (non 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 Port	Backend Port	Protocol
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 주소가 필요합니다. 새로운 가상 IP 주소에 /etc/gitlab/gitlab.rb의 pages_external_url을 가리키도록 DNS를 구성하십시오. 자세한 내용은 GitLab Pages 문서를 참조하십시오.

LB Port	Backend Port	Protocol
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 Port	Backend Port	Protocol
443	22	TCP

SSL

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

애플리케이션 노드가 SSL을 종료합니다.
로드 밸런서가 백엔드 SSL 없이 SSL을 종료합니다.
그리고 로드 밸런서와 애플리케이션 노드 간의 통신은 안전하지 않습니다.
로드 밸런서가 백엔드 SSL로 SSL을 종료합니다.
그리고 로드 밸런서와 애플리케이션 노드 간의 통신은 안전합니다.

애플리케이션 노드가 SSL을 종료합니다.

로드 밸런서를 포트 443에서 TCP 프로토콜로 연결을 전달하도록 구성하세요.
이것은 연결을 애플리케이션 노드의 NGINX 서비스로 변경 없이 전달합니다.
NGINX는 SSL 인증서를 가지고 있으며 포트 443에서 수신합니다.

SSL 인증서 관리 및 NGINX 구성에 대한 자세한 내용은
HTTPS 문서를 참조하세요.

로드 밸런서가 백엔드 SSL 없이 SSL을 종료합니다.

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

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

로드 밸런서가 백엔드 SSL로 SSL을 종료합니다.

로드 밸런서를 HTTP(S) 프로토콜을 사용하도록 구성하세요.
로드 밸런서는 최종 사용자가 볼 SSL 인증서를 관리하는 책임이 있습니다.

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

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

내부 로드 밸런서 구성

다중 노드 GitLab 구성에서 선택된 내부 구성 요소에 대한 트래픽을 라우팅하기 위해
내부 로드 밸런서가 필요합니다.
이러한 구성 요소에는 PgBouncer 및 Praefect (Gitaly Cluster)에 대한 연결이 포함될 수 있습니다.

어떤 로드 밸런서를 사용할지, 또는 그 정확한 구성은
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 서버를 설정합니다.

참고: Consul은 3개 이상의 홀수 개수로 배포되어야 합니다. 이는 노드가 과반수의 일환으로 투표를 할 수 있도록 보장하기 위함입니다.

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

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

Consul을 구성하려면:

Consul을 호스팅할 서버에 SSH로 접속합니다.
다운로드 및 설치를 진행합니다. 원하는 Linux 패키지를 선택하여 페이지에서 설치 단계 1 및 2만 따르도록 하세요. 현재 설치한 버전 및 종류(커뮤니티 또는 엔터프라이즈 에디션)와 동일한 Linux 패키지를 선택해야 합니다.

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

roles(['consul_role'])

## Prometheus를 위한 서비스 발견 활성화
consul['monitoring_service_discovery'] =  true

## Consul 서버 노드의 IP
## FQDN과 IP를 혼합해서 사용할 수 있습니다
consul['configuration'] = {
   server: true,
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}

# 익스포터가 수신 대기할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'

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

구성한 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하고 이 서버에 같은 이름의 파일을 추가하거나 교체합니다. 만약 구성하고 있는 첫 번째 Linux 패키지 노드라면 이 단계를 생략할 수 있습니다.
변경 사항을 적용하기 위해 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에서 기본적으로 로드 밸런싱이 활성화되어 호환되지 않습니다.

자세한 내용은 권장 클라우드 제공자 및 서비스를 참조하십시오.

제3자 외부 서비스를 사용하는 경우:

HA Linux 패키지 PostgreSQL 설정에는 PostgreSQL, PgBouncer 및 Consul이 포함됩니다. 이러한 구성 요소는 제3자 외부 서비스를 사용할 때 더 이상 필요하지 않습니다.
데이터베이스 요구 사항 문서에 따라 PostgreSQL을 설정하십시오.
선택한 비밀번호로 gitlab 사용자 이름을 설정합니다. gitlab 사용자는 gitlabhq_production 데이터베이스를 생성할 수 있는 권한이 필요합니다.
적절한 세부정보로 GitLab 애플리케이션 서버를 구성하십시오. 이 단계는 GitLab Rails 애플리케이션 구성에서 다룹니다.
HA를 달성하는 데 필요한 노드 수는 서비스에 따라 Linux 패키지와 달라질 수 있으며 반드시 일치할 필요는 없습니다.
그러나 성능 향상을 위해 데이터베이스 로드 밸런싱이 Read Replicas를 통해 필요하다면 참조 아키텍처에 대한 노드 수를 따르는 것이 좋습니다.

Linux 패키지를 사용하는 독립형 PostgreSQL

복제 및 장애 조치를 위한 PostgreSQL 클러스터의 권장 Linux 패키지 구성은 다음을 요구합니다:

최소 3개의 PostgreSQL 노드.
최소 3개의 Consul 서버 노드.
기본 데이터베이스 읽기 및 쓰기를 처리하는 최소 3개의 PgBouncer 노드.
- PgBouncer 노드 간 요청을 균형 잡기 위한 내부 로드 밸런서 (TCP).
데이터베이스 로드 밸런싱 활성화.

각 PostgreSQL 노드에 대해 구성할 로컬 PgBouncer 서비스. 이는 기본 PgBouncer 클러스터와 별개이며 기본을 추적합니다.

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

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

먼저 설치를 확인하십시오.

각 노드에서 Linux GitLab 패키지를 설치합니다. 단계에 따라 단계 1에서 필요한 종속성을 설치하고 단계 2에서 GitLab 패키지 저장소를 추가합니다. GitLab을 설치할 때 단계 2에서 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`를 데이터베이스 노드 수의 두 배로 설정합니다.
# 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>'

# 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 복제 방법을 참조하십시오.

설정한 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하고 이 서버의 같은 이름의 파일을 추가하거나 교체합니다. 설정하는 첫 번째 Linux 패키지 노드인 경우 이 단계를 건너뛸 수 있습니다.
GitLab 재구성을 수행하여 변경 사항이 적용되도록 합니다.

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

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

PostgreSQL 사후 구성

기본 사이트의 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 구성

이제 PostgreSQL 서버가 모두 설정되었으므로 기본 데이터베이스에 대한 읽기/쓰기 작업을 추적하고 처리하기 위해 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

# Exporter가 수신할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'

첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하고 같은 이름의 파일을 이 서버에 추가하거나 교체합니다. 이 노드가 구성하고 있는 첫 번째 Linux 패키지 노드인 경우 이 단계를 건너뛸 수 있습니다.
변경 사항이 적용되도록 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 - 캐시 프라이머리
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 클러스터 모드는 특별히 지원되지 않지만 HA와 함께하는 Redis 독립형은 지원됩니다.
설정에 따라 Redis 제거 모드를 설정해야 합니다.

자세한 내용은 추천 클라우드 제공자 및 서비스를 참조하세요.

Redis 캐시 클러스터 구성

이 섹션에서는 새 Redis 캐시 인스턴스를 설치하고 설정합니다.

프라이머리 및 레플리카 Redis 노드 모두 redis['password']에 정의된 동일한 비밀번호가 필요합니다.
장애 조치 중 언제든지 Sentinel은 노드를 재구성하고 상태를 프라이머리에서 레플리카로(그 반대도 가능) 변경할 수 있습니다.

기본 Redis Cache 노드 구성

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

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

# 서버 역할을 'redis_master_role'로 지정하고 Sentinel을 설정하며 Consul 에이전트를 활성화합니다
roles(['redis_sentinel_role', 'redis_master_role', 'consul_role'])

# Redis Sentinel 서비스에 대한 IP 바인드 주소와 정족수 숫자를 설정합니다
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_OF_FIRST_CLUSTER'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'

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

## 이 기본 Redis 노드의 IP입니다.
redis['master_ip'] = '10.6.0.51'

# Redis Cache 인스턴스를 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 캐시 노드 구성

replica Redis 서버에 SSH로 접속합니다.
다운로드 및 설치를 통해 원하는 Linux 패키지를 설치합니다. 페이지에서 오직 설치 단계 1과 2만 따르고, 현재 설치와 동일한 버전과 유형(커뮤니티 또는 엔터프라이즈 에디션)을 선택해야 합니다.

/etc/gitlab/gitlab.rb 파일을 편집하고 이전 섹션의 기본 노드와 동일한 내용을 추가하되, redis_master_node를 redis_replica_node로 바꿉니다:

# 'redis_replica_role'로 서버 역할을 지정하고 Sentinel을 사용하며 Consul 에이전트를 활성화합니다.
roles(['roles_sentinel_role', 'redis_replica_role', 'consul_role'])

# Redis Sentinel 서비스의 IP 바인드 주소와 쿼럼 수를 설정합니다.
sentinel['bind'] = '0.0.0.0'
sentinel['quorum'] = 2

# 다른 머신이 접근할 수 있는 로컬 IP를 가리키는 IP 주소입니다.
# '0.0.0.0'으로 바인드하면 모든 인터페이스에서 수신합니다.
# 정말로 외부에서 접근 가능한 IP에 바인드해야 한다면
# 무단 접근을 방지하기 위해 추가 방화벽 규칙을 추가해야 합니다.
redis['bind'] = '10.6.0.52'

# Redis가 TCP 요청을 수신할 수 있도록 포트를 정의합니다.
redis['port'] = 6379

## Sentinel의 기본 Redis 서버 포트로, 기본값이 아닌 값을 변경하려면 주석을 제거합니다.
## 기본적으로 `6379`입니다.
#redis['master_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'

## 기본 Redis 노드의 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 노드는 모두 redis['password']에 정의된 동일한 비밀번호가 필요합니다.

장애 조치 중 언제든지 Sentinel이 노드를 재구성하고 상태를 기본에서 복제로 (그리고 그 반대로) 변경할 수 있습니다.

기본 Redis 영구 노드 구성

Primary Redis 서버에 SSH로 접속합니다.
다운로드 및 설치 하고자 하는 리눅스 패키지를 선택합니다.

페이지에서 설치 단계 1과 2만 따르도록 하고, 현재 설치와 동일한 버전 및 유형(커뮤니티 또는 엔터프라이즈 에디션)의 올바른 리눅스 패키지를 선택해야 합니다.

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

# 서버 역할을 'redis_master_role'로 지정하고 Sentinel을 활성화하여 Consul 에이전트를 설정합니다.
roles ['redis_sentinel_role', 'redis_master_role', 'consul_role']

# Redis Sentinel 서비스의 IP 바인드 주소 및 쿼럼 수 설정
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'

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

## Consul 서버 노드의 IP들
## IP와 FQDN을 혼합하여 사용할 수 있습니다.
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

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

첫 번째 리눅스 패키지 노드를 구성하는 경우 이 단계는 생략할 수 있습니다.
변경 사항을 적용하기 위해 GitLab 재구성을 실행합니다.

복제 Redis 지속적 노드 구성하기

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

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

# Redis Sentinel과 함께 'redis_replica_role'로 서버 역할을 지정하고 Consul 에이전트를 활성화합니다.
roles ['redis_sentinel_role', 'redis_replica_role', 'consul_role']

# Redis Sentinel 서비스의 IP 바인드 주소 및 쿼럼 수 설정
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'

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

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

첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하고 이 서버의 동일한 이름의 파일을 추가하거나 교체합니다. 설정 중인 노드가 첫 번째 Linux 패키지 노드인 경우 이 단계를 건너뛰어도 됩니다.
GitLab 재구성하기 변경 사항을 적용합니다.
다른 모든 복제 노드에 대해 다시 단계를 반복하고 IP를 올바르게 설정합니다.

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

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

Gitaly 클러스터 구성

Gitaly 클러스터는 GitLab에서 제공하고 권장하는 Git 리포지토리를 저장하기 위한 내결함성 솔루션입니다. 이 구성에서는 클러스터의 모든 Gitaly 노드에 모든 Git 리포지토리가 저장되며, 하나의 노드가 기본(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을 설치하는 2단계에서는 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
# 필수 정보 섹션에 설명된대로 실제 값을 설정하세요
#
# 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 타사 솔루션

언급된 바와 같이, 완전한 고가용성을 목표로 할 때 Praefect의 데이터베이스에 대한 타사 PostgreSQL 솔루션을 권장합니다.

PostgreSQL HA에 대한 많은 타사 솔루션이 있습니다. 선택된 솔루션은 Praefect와 함께 작동하기 위해 다음 기준을 충족해야 합니다:

장애 조치 시 변경되지 않는 모든 연결을 위한 정적 IP.
LISTEN SQL 기능이 지원되어야 합니다.

참고: 타사 설정을 통해 편의상 Praefect의 데이터베이스를 주요 GitLab 데이터베이스와 동일한 서버에 공동 배치할 수 있습니다. 그러나 Geo를 사용하는 경우 복제를 올바르게 처리하기 위해 별도의 데이터베이스 인스턴스가 필요합니다. 이 설정에서는 주요 데이터베이스 설정의 사양을 변경할 필요가 없으며, 영향을 최소화해야 합니다.

신뢰할 수 있는 공급자 또는 솔루션이 사용되어야 합니다. Google Cloud SQL과 Amazon RDS는 잘 작동하는 것으로 알려져 있습니다. 그러나 Amazon Aurora는 기본적으로 로드 밸런싱이 활성화된 상태에서 호환되지 않습니다 from 14.4.0.

위의 예로는 Google의 Cloud SQL 또는 Amazon RDS가 포함될 수 있습니다.

데이터베이스가 설정되면 게시 구성을 따르세요.

Praefect PostgreSQL 게시 구성

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

사용자 이름을 praefect로, 데이터베이스를 praefect_production으로 설정하는 것을 권장하며, 이는 PostgreSQL에서 표준으로 구성할 수 있습니다. 사용자의 비밀번호는 이전에 구성한 <praefect_postgresql_password>와 동일합니다.

다음은 Linux 패키지 PostgreSQL 설정에서 작동하는 방식입니다:

Praefect PostgreSQL 노드에 SSH로 접속합니다.
관리 액세스로 PostgreSQL 서버에 연결합니다. 여기서는 Linux 패키지에서 기본적으로 추가된 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는 3개 노드의 홀수 개수로 배포되어야 합니다. 이는 노드들이 쿼럼의 일환으로 투표할 수 있도록 보장하기 위함입니다.

Praefect는 클러스터 전반에 걸쳐 통신을 보안하기 위해 여러 개의 비밀 토큰이 필요합니다:

<praefect_external_token>: Gitaly 클러스터에서 호스팅되는 리포지토리에 사용되며, 이 토큰을 가진 Gitaly 클라이언트만 접근할 수 있습니다.
<praefect_internal_token>: Gitaly 클러스터 내에서 복제 트래픽에 사용됩니다. 이는 praefect_external_token과는 다른 것으로, Gitaly 클라이언트가 Praefect 클러스터의 내부 노드에 직접 접근할 수 없어야 하며, 이는 데이터 손실을 초래할 수 있습니다.
<praefect_postgresql_password>: 이전 섹션에서 정의된 Praefect PostgreSQL 비밀번호도 이 설정의 일부로 필요합니다.

Gitaly 클러스터 노드는 Praefect를 통해 virtual storage로 구성됩니다. 각 스토리지는 클러스터를 구성하는 각 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를 구성합니다:

참고:
virtual_storages에서 default 항목을 제거할 수 없습니다. GitLab에서는 이를 요구합니다.

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

# Praefect 구성
praefect['enable'] = true

# 자동으로 데이터베이스 마이그레이션이 실행되지 않도록 방지
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,
      dbname: 'praefect_production',
      user: 'praefect',
      password: '<praefect_postgresql_password>',
   },
   # Praefect 가상 스토리지 구성
   # 저장소 해시의 이름은 GitLab의 git_data_dirs 및 Gitaly 노드의 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),
}
#
# 사용자 구성 종료

첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하고, 이 서버의 동일한 이름의 파일에 추가하거나 대체합니다. 이는 처음으로 구성하는 Linux 패키지 노드인 경우 이 단계를 건너뛸 수 있습니다.
Praefect는 메인 GitLab 애플리케이션과 유사하게 일부 데이터베이스 마이그레이션을 실행해야 합니다. 이를 위해서는 마이그레이션을 실행할 Praefect 노드 하나만 선택해야 하며, 이를 _배포 노드_라고 합니다. 이 노드는 다른 노드들보다 먼저 구성되어야 합니다:
1. /etc/gitlab/gitlab.rb 파일에서 praefect['auto_migrate'] 설정 값을 false에서 true로 변경합니다.
2. 데이터베이스 마이그레이션이 자동으로 업그레이드 중에 실행되지 않도록 하려면, 다음을 실행합니다:
```
sudo touch /etc/gitlab/skip-auto-reconfigure
```
1. GitLab 재구성을 실행하여 변경 사항이 적용되고 Praefect 데이터베이스 마이그레이션이 실행되도록 합니다.
모든 다른 Praefect 노드에서 GitLab 재구성을 실행하여 변경 사항이 적용되도록 합니다.

Gitaly 구성

Gitaly 서버 노드로 구성된 클러스터는 데이터와 부하에 따라 요구 사항이 다릅니다.

경고:
Gitaly 사양은 사용 패턴과 건강한 상태의 리포지토리 크기의 높은 백분위수에 기반합니다.
하지만, 대형 모노레포 (여러 기가바이트 이상)나 추가 작업 부담이 있는 경우 성능에 상당히 영향을 미칠 수 있으며 추가 조정이 필요할 수 있습니다.
이 경우, 링크된 문서를 참조하고 고객 성공 관리자 또는 지원 팀에 문의하여 추가 지침을 받는 것이 좋습니다.

Gitaly의 입력 및 출력 요구 사항이 주목할 만하기 때문에 모든 Gitaly 노드에서 SSD(솔리드 스테이트 드라이브)를 사용하는 것을 강력히 권장합니다. 이 SSD는 읽기 작업을 위한 IOPS(초당 입출력 작업 수)가 최소 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`가 실패합니다. 
# 이것은 귀하의 '프론트 도어' 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

# START 사용자 구성
# 필수 정보 섹션에 설명된 대로 실제 값을 설정하세요
#
## 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 Pack-objects 캐시
      # 성능 개선을 위해 활성화하는 것이 권장되지만 디스크 I/O가 상당히 증가할 수 있습니다
      # 더 많은 정보는 https://docs.gitlab.com/ee/administration/gitaly/configure_gitaly.html#pack-objects-cache를 참조하세요
      enabled: true,
   },
}

#
# END 사용자 구성

각 해당 서버에 대해 /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 클러스터 TLS 지원

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

GitLab 구성의 해당 스토리지 항목의 gitaly_address에 tls:// URL 스킴을 사용합니다.
인증서는 자동으로 제공되지 않으므로 본인의 인증서를 가져와야 합니다. 각 Praefect 서버에 해당하는 인증서는 해당 Praefect 서버에 설치되어야 합니다.

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

다음 사항에 유의하세요:

인증서는 Praefect 서버에 접근하는 데 사용하는 주소를 지정해야 합니다. 인증서에 주체 대체 이름(Subject Alternative Name)으로 호스트 이름 또는 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 인스턴스에 연결이 필요합니다. 또한 추천에 따라 Object Storage와의 연결이 필요합니다.

주의: 데이터 객체를 위한 NFS 대신 Object Storage를 사용하는 것이 권장됩니다. 다음 예제에는 Object Storage 구성 내용이 포함되어 있습니다.

주의: 환경의 Sidekiq 작업 처리 속도가 느리고 긴 큐가 있는 경우, 이를 적절하게 확장할 수 있습니다. 더 많은 정보는 스케일링 문서를 참조하세요.

주의: Container Registry, SAML 또는 LDAP과 같은 추가 GitLab 기능을 구성하는 경우, 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 host> 5432 # PostgreSQL
telnet <GitLab host> 8075 # Gitaly
telnet <GitLab host> 6379 # Redis

다운로드 및 설치를 원하는 리눅스 패키지를 선택하십시오. 페이지에서 설치 단계 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_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['listen_address'] = "0.0.0.0"

## Sidekiq 큐 프로세스 수를 사용 가능한 CPU 수와 동일하게 설정
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>'
}

첫 번째 리눅스 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 동일한 이름의 파일에 추가하거나 교체합니다. 이 리눅스 패키지 노드를 처음 구성하는 경우 이 단계를 건너뛰어도 됩니다.
데이터베이스 마이그레이션이 재구성 중에만 실행되고 업그레이드 중에 자동으로 실행되지 않도록 하려면 다음을 실행합니다:
```
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 애플리케이션 서버로 트래픽을 라우팅할 external load balancer의 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 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']

#############################
###     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 재구성하여 변경 사항을 적용합니다.
증분 로깅 활성화.
노드가 Gitaly에 연결할 수 있는지 확인합니다:
```
sudo gitlab-rake gitlab:gitaly:check
```
그런 다음 로그를 tail하여 요청을 확인합니다:
```
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를 우회합니다.

마이그레이션이 완료된 후, 노드를 다시 PgBouncer를 통과하도록 구성해야 합니다.
데이터베이스에서 허가된 SSH 키의 빠른 조회를 구성합니다.

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

Prometheus 구성

Linux 패키지를 사용하여 Prometheus를 실행하는 독립형 모니터링 노드를 구성할 수 있습니다.

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

10.6.0.151: Prometheus

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

모니터링 노드에 SSH로 접속합니다.
다운로드 및 설치 선택한 Linux 패키지를 설치합니다. 페이지의 설치 단계 1 및 2만 따르도록 합니다.

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

roles(['monitoring_role', 'consul_role'])

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

# Prometheus
prometheus['listen_address'] = '0.0.0.0:9090'
prometheus['monitor_kubernetes'] = false

# Prometheus에 대한 서비스 검색 활성화
consul['monitoring_service_discovery'] = true
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}

# 검색되지 않은 서비스를 스크랩하도록 Prometheus 구성
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이 저장하는 다양한 유형의 데이터 간에 충돌이 발생하지 않도록 보장합니다.

앞으로 단일 버킷 사용을 활성화할 계획이 있습니다.

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

증분 로깅 활성화

GitLab Runner는 기본적으로 작업 로그를 청크로 반환하며, Linux 패키지는 /var/opt/gitlab/gitlab-ci/builds에 임시로 디스크에 캐시합니다. 이는 통합 객체 저장소를 사용하는 경우에도 마찬가지입니다. 기본 구성에서는 이 디렉터리를 모든 GitLab Rails 및 Sidekiq 노드에서 NFS를 통해 공유해야 합니다.

작업 로그를 NFS를 통해 공유하는 것은 지원되지만, NFS 노드가 배포되지 않은 경우에는 증분 로깅을 활성화하여 NFS 사용을 피하는 것을 권장합니다. 증분 로깅은 작업 로그의 임시 캐시를 위해 디스크 공간 대신 Redis를 사용합니다.

고급 검색 구성

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

Elasticsearch 클러스터 설계 및 요구 사항은 특정 데이터에 따라 달라집니다. 인스턴스와 함께 Elasticsearch 클러스터를 설정하는 방법에 대한 권장 모범 사례는 최적 클러스터 구성을 선택하는 방법을 읽어보세요.

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

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

Kubernetes에서 GitLab Helm chart를 사용하여 클라우드 네이티브 GitLab의 선택 구성 요소를 실행하세요. 이 설정에서는 Kubernetes 클러스터에 Webservice라고 불리는 GitLab Rails와 동등한 작업을 실행할 수 있습니다. 또한 Kubernetes 클러스터에서 Sidekiq라고 불리는 Sidekiq 노드와 동등한 작업을 실행할 수 있습니다. 추가로 다음과 같은 지원 서비스도 지원됩니다: NGINX, Toolbox, Migrations, Prometheus.

하이브리드 설치는 클라우드 네이티브 및 전통적인 컴퓨팅 배포의 이점을 활용합니다. 이렇게 하면 무상태 구성 요소는 클라우드 네이티브 워크로드 관리의 이점을 누릴 수 있는 반면, 유상태 구성 요소는 증가된 영구성을 활용하기 위해 Linux 패키지 설치가 포함된 컴퓨팅 VM에 배포됩니다.

Helm charts 고급 구성 문서를 참조하여 Kubernetes와 백엔드 구성 요소 간에 동기화해야 할 GitLab 비밀에 대한 지침을 포함한 설정 지침을 참조하세요.

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

Gitaly 클러스터는 Kubernetes에서 실행하는 것이 지원되지 않습니다.

자세한 내용은 epic 6127를 참조하세요.

클러스터 토폴로지

다음 표와 다이어그램은 위의 일반 환경과 동일한 형식을 사용하는 하이브리드 환경을 자세히 설명합니다.

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

구성 요소 노드 그룹	목표 노드 풀 총합	GCP 예제	AWS 예제
Webservice	308 vCPU 385 GB 메모리 (요청) 539 GB 메모리 (제한)	11 x `n1-standard-32`	11 x `c5.9xlarge`
Sidekiq	12.6 vCPU 28 GB 메모리 (요청) 56 GB 메모리 (제한)	4 x `n1-standard-4`	4 x `m5.xlarge`
지원 서비스	8 vCPU 30 GB 메모리	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 제공자의 시스템 프로세스에는 추가 리소스가 필요합니다. 주어진 예제는 이를 고려합니다.
지원 목표 노드 풀 총합은 GitLab 배포를 지원하는 여러 리소스를 수용할 수 있도록 일반적으로 제공됩니다. 여기에 원하는 추가 배포를 고려해야 합니다. 다른 노드 풀과 마찬가지로 선택한 Kubernetes 제공자의 시스템 프로세스 또한 리소스가 필요합니다. 주어진 예제는 이를 고려합니다.
프로덕션 배포에서는 포드를 특정 노드에 할당할 필요가 없습니다. 그러나 각 풀에 여러 노드가 있어야 서로 다른 가용 영역에 분산되어 탄력적인 클라우드 아키텍처 관행에 부합하는 것이 좋습니다.
클러스터 오토스케일러와 같은 오토스케일링을 활성화하여 효율성을 높이는 것이 권장되지만, 일반적으로 Webservice 및 Sidekiq 포드의 목표는 75%를 기준으로 잡는 것이 좋습니다.

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

서비스	노드	구성	GCP	AWS
Consul¹	3	2 vCPU, 1.8 GB 메모리	`n1-highcpu-2`	`c5.large`
PostgreSQL¹	3	32 vCPU, 120 GB 메모리	`n1-standard-32`	`m5.8xlarge`
PgBouncer¹	3	2 vCPU, 1.8 GB 메모리	`n1-highcpu-2`	`c5.large`
내부 로드 밸런서³	1	16 vCPU, 14.4 GB 메모리	`n1-highcpu-16`	`c5.4xlarge`
Redis/Sentinel - 캐시²	3	4 vCPU, 15 GB 메모리	`n1-standard-4`	`m5.xlarge`
Redis/Sentinel - 영구²	3	4 vCPU, 15 GB 메모리	`n1-standard-4`	`m5.xlarge`
Gitaly⁵	3	64 vCPU, 240 GB 메모리⁶	`n1-standard-64`	`m5.16xlarge`
Praefect⁵	3	4 vCPU, 3.6 GB 메모리	`n1-highcpu-4`	`c5.xlarge`
Praefect PostgreSQL¹	1+	2 vCPU, 1.8 GB 메모리	`n1-highcpu-2`	`c5.large`
객체 저장소⁴	-	-	-	-

각주:

평판이 좋은 제3자 외부 PaaS PostgreSQL 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 자신의 PostgreSQL 인스턴스 제공을 참조하세요.
평판이 좋은 제3자 외부 PaaS Redis 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 자신의 Redis 인스턴스 제공을 참조하세요.
- Redis는 주로 단일 스레드이며 CPU 코어 수의 증가로 인해 크게 이득을 보지 않습니다. 이러한 아키텍처 크기에는 최적의 성능을 달성하기 위해 명시된 대로 별도의 캐시 및 영구 인스턴스를 사용하는 것이 강력히 권장됩니다.
평판이 좋은 제3자 로드 밸런싱 서비스(LB PaaS)에서 선택적으로 실행될 수 있습니다. 자세한 내용은 권장 클라우드 공급자 및 서비스를 참조하세요.
평판이 좋은 클라우드 제공자 또는 자체 관리 솔루션에서 실행되어야 합니다. 자세한 내용은 객체 저장소 구성을 참조하세요.
Gitaly 클러스터는 내결함성의 이점을 제공하지만 설치 및 관리의 추가 복잡성을 동반합니다. Gitaly 클러스터를 배포하기 전에 기존의 기술적 제한사항 및 고려사항을 검토하십시오. Sharded Gitaly를 원하신다면 Gitaly에 대해 상기 명세를 사용하세요.
Gitaly 사양은 건강한 상태의 사용 패턴 및 리포지토리 크기의 높은 백분위수를 기준으로 합니다. 그러나 대형 모노레포(수 기가바이트 이상) 또는 추가 작업 부하가 있는 경우 이로 인해 Git 및 Gitaly 성능에 상당한 영향을 미칠 수 있으며, 추가 조정이 필요할 수 있습니다.

모든 PaaS 솔루션에서 인스턴스를 구성할 경우 최소한 세 개의 노드를 세 개의 다른 가용 영역에 구현하는 것이 권장되어 탄력적인 클라우드 아키텍처 관행에 부합해야 합니다.

Kubernetes 구성 요소 대상

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

웹 서비스

각 웹 서비스 포드(Puma 및 Workhorse)는 다음 구성을 실행하는 것이 권장됩니다:

4 Puma 작업자
4 vCPU
5 GB 메모리(요청)
7 GB 메모리(제한)

500 RPS 또는 25,000 사용자에 대해 약 308개의 Puma 작업자 수를 권장하며, 따라서 최소 77개의 웹 서비스 포드를 실행하는 것이 좋습니다.

웹 서비스 리소스 사용에 대한 자세한 내용은 웹 서비스 리소스 문서의 차트를 참조하세요.

NGINX

웹 서비스 노드 전역에 NGINX 컨트롤러 포드를 DaemonSet으로 배포하는 것이 권장됩니다. 이는 컨트롤러가 서비스를 제공하는 웹 서비스 포드와 함께 동적으로 확장될 수 있도록 하여, 일반적으로 대형 기계 유형이 가지는 더 높은 네트워크 대역폭을 활용할 수 있도록 하기 위함입니다.

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

사이드킥

각 사이드킥 포드는 다음 구성을 실행하는 것이 권장됩니다:

1 사이드킥 작업자
900m vCPU
2 GB 메모리(요청)
4 GB 메모리(제한)

위의 표준 배포와 유사하게, 여기에는 초기 목표로 14개의 사이드킥 작업자가 사용되었습니다. 특정 워크플로에 따라 추가 작업자가 필요할 수 있습니다.

사이드킥 리소스 사용에 대한 자세한 내용은 사이드킥 리소스 문서의 차트를 참조하세요.

지원

지원 노드 풀은 웹 서비스 및 사이드킥 풀에 있을 필요가 없는 모든 지원 배포를 수용하도록 설계되었습니다.

여기에는 클라우드 제공업체의 구현과 관련된 다양한 배포 및 GitLab Shell과 같은 GitLab 배포를 포함합니다.

컨테이너 레지스트리, 페이지 또는 모니터링과 같은 추가 배포를 원하는 경우, 가능한 한 지원 풀에 배포하고 웹 서비스 또는 사이드킥 풀에는 배포하지 않는 것이 좋습니다. 지원 풀은 여러 추가 배포를 수용할 수 있도록 특별히 설계되었습니다. 그러나 배포가 주어진 풀에 적합하지 않으면 노드 풀을 적절히 늘릴 수 있습니다. 반대로 사용 사례에서 풀이 과도하게 제공된 경우 적절히 줄일 수 있습니다.

예시 구성 파일

위의 1000 RPS 또는 50,000 참고 아키텍처 구성을 목표로 하는 GitLab Helm 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 캐시 클러스터 구성

기본 Redis Cache 노드 구성

복제 Redis 캐시 노드 구성

Redis 영구 클러스터 구성

기본 Redis 영구 노드 구성

복제 Redis 지속적 노드 구성하기

Gitaly 클러스터 구성

Praefect PostgreSQL 구성

Praefect 비 HA PostgreSQL 독립형 사용 (Linux 패키지)

Praefect HA PostgreSQL 타사 솔루션

Praefect PostgreSQL 게시 구성

Praefect 구성

Gitaly 구성

Gitaly 클러스터 TLS 지원

Sidekiq 구성

GitLab Rails 구성

GitLab Rails 설정 후 구성

Prometheus 구성

개체 스토리지 구성

증분 로깅 활성화

고급 검색 구성

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

클러스터 토폴로지

Kubernetes 구성 요소 대상

웹 서비스

NGINX

사이드킥

지원

예시 구성 파일

다음 단계

도움말

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

도움받기