요구 사항
테스팅 방법론
구성 요소 설정
외부 로드 밸런서 구성
내부 로드 밸런서 구성
Consul 구성
PostgreSQL 구성
Redis 구성
- 자체 Redis 인스턴스 제공
- Redis 클러스터 구성
  - 기본 Redis 노드 구성
  - 복제 Redis 노드 구성
Gitaly 클러스터 구성
Sidekiq 구성
GitLab Rails 구성
- GitLab Rails 포스트 구성
프로메테우스 구성
객체 저장소 구성
- 점진적 로깅 활성화
고급 검색 구성
낮은 사용자 수(HA)를 위한 지원되는 수정 사항
Helm 차트를 활용한 클라우드 네이티브 하이브리드 참조 아키텍처(대안)
다음 단계

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

Tier: Premium, Ultimate Offering: Self-Managed

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

이 아키텍처는 내장 HA가 구축된 가장 작은 아키텍처입니다. HA가 필요하지만 사용자 수나 총 부하가 더 적은 경우 낮은 사용자 수에 대한 지원되는 수정사항 섹션에서 HA를 유지하면서 이 아키텍처의 크기를 줄이는 방법에 대해 설명합니다.

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

대상 부하: API: 60 RPS, 웹: 6 RPS, Git (풀): 6 RPS, Git (푸시): 1 RPS
고가용성: 예, 그러나 Praefect는 타사 PostgreSQL 솔루션 필요
비용 계산기 템플릿: 비용 계산기 템플릿 섹션 참조
클라우드 네이티브 하이브리드 대체 옵션: 예
어떤 참조 아키텍처를 사용해야 하는지 확실하지 않은가요? 더 많은 정보를 위해 이 가이드 참조.

서비스	노드 수	구성	GCP	AWS	Azure
외부 로드 밸런서³	1	4 vCPU, 3.6 GB 메모리	`n1-highcpu-4`	`c5n.xlarge`	`F4s v2`
Consul¹	3	2 vCPU, 1.8 GB 메모리	`n1-highcpu-2`	`c5.large`	`F2s v2`
PostgreSQL¹	3	2 vCPU, 7.5 GB 메모리	`n1-standard-2`	`m5.large`	`D2s v3`
PgBouncer¹	3	2 vCPU, 1.8 GB 메모리	`n1-highcpu-2`	`c5.large`	`F2s v2`
내부 로드 밸런서³	1	4 vCPU, 3.6 GB 메모리	`n1-highcpu-4`	`c5n.xlarge`	`F4s v2`
Redis/Sentinel²	3	2 vCPU, 7.5 GB 메모리	`n1-standard-2`	`m5.large`	`D2s v3`
Gitaly⁵	3	4 vCPU, 15 GB 메모리⁶	`n1-standard-4`	`m5.xlarge`	`D4s v3`
Praefect⁵	3	2 vCPU, 1.8 GB 메모리	`n1-highcpu-2`	`c5.large`	`F2s v2`
Praefect PostgreSQL¹	1+	2 vCPU, 1.8 GB 메모리	`n1-highcpu-2`	`c5.large`	`F2s v2`
Sidekiq⁷	2	4 vCPU, 15 GB 메모리	`n1-standard-4`	`m5.xlarge`	`D2s v3`
GitLab Rails⁷	3	8 vCPU, 7.2 GB 메모리	`n1-highcpu-8`	`c5.2xlarge`	`F8s v2`
모니터링 노드	1	2 vCPU, 1.8 GB 메모리	`n1-highcpu-2`	`c5.large`	`F2s v2`
객체 저장소⁴	-	-	-	-	-

각주:

신뢰할 수 있는 타사 외부 PaaS PostgreSQL 솔루션에서 선택적으로 실행 가능. 자세한 내용은 자체 PostgreSQL 인스턴스 제공 참조.
신뢰할 수 있는 타사 외부 PaaS Redis 솔루션에서 선택적으로 실행 가능. 자세한 내용은 자체 Redis 인스턴스 제공 참조.
HA 기능을 제공할 수 있는 신뢰할 수 있는 타사 로드 밸런서 또는 서비스 (LB PaaS)에서 실행하는 것이 권장됨. 크기 조정은 선택한 로드 밸런서 및 네트워크 대역폭과 같은 추가 요소에 따라 다를 수 있음. 자세한 내용은 로드 밸런서를 참조하세요.
신뢰할 수 있는 클라우드 제공 업체 또는 자체 관리 솔루션에서 실행해야 함. 세부 사항은 객체 저장소 구성을 참조하세요.
Gitaly 클러스터는 결함 허용의 이점을 제공하지만, 설정 및 관리에 추가 복잡성이 따릅니다. Gitaly 클러스터를 배포하기 전에 기술적 제한 사항 및 고려사항을 검토하세요. 샤딩된 Gitaly를 원하는 경우 Gitaly에 대한 동일한 사양을 사용하세요.
Gitaly 사양은 사용 패턴 및 리포지토리 크기의 상위 백분위수를 기반으로 합니다. 그러나 대규모 단일 저장소(수 기가바이트보다 큰 경우)나 추가 작업 부하가 있다면 Git 및 Gitaly 성능에 상당한 영향을 줄 수 있으며, 추가 조정이 필요할 수 있습니다.
해당 구성요소는 상태 데이터를 저장하지 않기 때문에 Auto Scaling 그룹(ASG)에 배치될 수 있습니다. 그러나 클라우드 네이티브 하이브리드 설치가 일반적으로 선호되며 마이그레이션 및 Mailroom과 같은 특정 컴포넌트는 하나의 노드에서만 실행할 수 있으므로 Kubernetes에서 더 잘 처리됩니다.

참고: 인스턴스 구성을 포함하는 모든 PaaS 솔루션에 대해 신뢰할 수 있는 클라우드 아키텍처 방법론에 따라 세 가지 노드에서 최소 구현하는 것이 권장됩니다.

요구 사항

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

테스팅 방법론

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

API: 60 RPS
Web: 6 RPS
Git (Pull): 6 RPS
Git (Push): 1 RPS

상기 목표는 사용자 수에 해당하는 총 환경 부하에 대한 실제 고객 데이터를 바탕으로 선택되었습니다. 여기에는 CI 및 기타 작업 부하가 포함됩니다.

상기 엔드포인트 목표에 대해 정기적으로 높은 처리량을 가지고 있다는 메트릭이 있다면, 대규모 단일 레포지토리 또는 주목할 만한 추가 작업 부하가 성능 환경에 주목할 만한 영향을 미칠 수 있으며, 추가 조정이 필요할 수 있습니다. 해당 사항이 해당된다면, 링크된 문서를 참조하고 고객 성공 담당자 또는 지원 팀에 문의하여 추가 지침을 받는 것을 권장합니다.

테스트는 정기적으로 저희의 GitLab 성능 도구 (GPT)와 해당 데이터셋을 사용하여 실시됩니다. 이 테스트의 결과는 GPT 위키에서 공개적으로 확인할 수 있습니다. 저희의 테스트 전략에 대한 자세한 정보는 문서의 이 섹션을 참조하세요.

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

구성 요소 설정

GitLab 및 해당 구성 요소를 설정하여 최대 60 RPS 또는 3,000 사용자를 수용하도록 설정하세요:

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

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

다음 목록은 각 서버와 해당 할당된 IP에 대한 설명을 포함합니다:

10.6.0.10: 외부 로드 밸런서
10.6.0.11: Consul/Sentinel 1
10.6.0.12: Consul/Sentinel 2
10.6.0.13: Consul/Sentinel 3
10.6.0.21: PostgreSQL 프라이머리
10.6.0.22: PostgreSQL 세컨더리 1
10.6.0.23: PostgreSQL 세컨더리 2
10.6.0.31: PgBouncer 1
10.6.0.32: PgBouncer 2
10.6.0.33: PgBouncer 3
10.6.0.20: 내부 로드 밸런서
10.6.0.61: Redis 프라이머리
10.6.0.62: Redis 레플리카 1
10.6.0.63: Redis 레플리카 2
10.6.0.51: Gitaly 1
10.6.0.52: Gitaly 2
10.6.0.93: Gitaly 3
10.6.0.131: Praefect 1
10.6.0.132: Praefect 2
10.6.0.133: Praefect 3
10.6.0.141: Praefect PostgreSQL 1 (HA 없음)
10.6.0.71: Sidekiq 1
10.6.0.72: Sidekiq 2
10.6.0.41: GitLab 애플리케이션 1
10.6.0.42: GitLab 애플리케이션 2
10.6.0.43: GitLab 애플리케이션 3
10.6.0.81: Prometheus

외부 로드 밸런서 구성

다중 노드 GitLab 구성에서 애플리케이션 서버로의 트래픽을 경로 설정하기 위해 외부 로드 밸런서가 필요합니다.

어떤 로드 밸런서를 사용해야 하는지 또는 정확한 구성에 대한 구체적인 세부 정보는 GitLab 문서의 범위를 벗어나지만, 자세한 사항은 로드 밸런서를 참조하세요. 이 섹션은 선택한 로드 밸런서에 대한 구체적인 구성에 초점을 맞춥니다.

준비 상태 확인

외부 로드 밸런서가 내장된 모니터링 엔드포인트를 이용하여 작동하는 서비스로만 경로를 지정하도록 보장하세요. 준비 상태 확인은 아이피 허용 목록에 대한 추가 구성이 필요하므로, 그렇지 않으면, 외부 로드 밸런서가 연결할 수 없을 것입니다.

포트

사용해야 하는 기본 포트는 아래 표에 표시됩니다.

LB 포트	백엔드 포트	프로토콜
80	80	HTTP (1)
443	443	TCP 또는 HTTPS (1) (2)
22	22	TCP

(1): Web terminal 지원을 위해서는 로드 밸런서가 WebSocket 연결을 올바르게 처리해야 합니다. HTTP 또는 HTTPS 프록시를 사용할 때, 로드 밸런서는 Connection 및 Upgrade hop-by-hop 헤더를 통과시키도록 구성되어야 합니다. 자세한 내용은 웹 터미널 통합 가이드를 참조하세요.
(2): 포트 443에 HTTPS 프로토콜을 사용하는 경우, 로드 밸런서에 SSL 인증서를 추가해야 합니다. 로드 밸런서에서 SSL을 해제하려면 GitLab 애플리케이션 서버에서 TCP 프로토콜을 사용하세요.

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

LB 포트	백엔드 포트	프로토콜
80	Varies (1)	HTTP
443	Varies (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 호스트 이름을 구성하는 것이 도움이 될 수 있습니다. 다른 GitLab HTTP 구성과 비교하여 대체 SSH 호스트 이름에는 새 가상 IP 주소가 필요합니다.

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

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을 추가로 구성할 필요가 없습니다. 그런데 SSL 인증서를 구성하기 위해 GitLab에 구성을 추가해야 합니다. SSL 인증서를 관리하고 NGINX를 구성하는 방법에 대한 자세한 내용은 HTTPS 문서를 참조하세요.

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

내부 로드 밸런서 구성

다중 노드 GitLab 구성에서 특정 내부 구성요소의 트래픽을 라우팅하기 위해 내부 로드 밸런서가 필요합니다. 구성된 경우 PgBouncer 및 Praefect (Gitaly 클러스터)와의 연결과 같은 내부 구성요소를 위해 트래픽을 라우팅할 수 있습니다.

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

다음 IP를 예로 들어봅시다.

10.6.0.40: 내부 로드 밸런서

아래는 HAProxy를 사용하여 구성하는 방법입니다:

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

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

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

    default_backend pgbouncer

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

    default_backend praefect

backend pgbouncer
    mode tcp
    option tcp-check

    server pgbouncer1 10.6.0.31:6432 check
    server pgbouncer2 10.6.0.32:6432 check
    server pgbouncer3 10.6.0.33:6432 check

backend praefect
    mode tcp
    option tcp-check
    option srvtcpka

    server praefect1 10.6.0.131:2305 check
    server praefect2 10.6.0.132:2305 check
    server praefect3 10.6.0.133:2305 check

원하는 로드 밸런서의 자세한 가이드는 해당 로드 밸런서 문서를 참조하세요.

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

Consul 구성

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

참고: 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만 따르고, 현재 설치 중인 버전 및 유형(Community 또는 Enterprise editions)과 동일한 Linux 패키지를 선택해야 합니다.

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

roles(['consul_role'])

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

## Consul 서버 노드들의 IP
## FQDNs를 사용하거나 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을 위한 서드파티 외부 서비스를 사용할 수 있습니다.

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

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

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

HA Linux 패키지 PostgreSQL 설정에는 PostgreSQL, PgBouncer 및 Consul이 포함됩니다. 이러한 구성요소들은 외부 서비스를 사용할 때 더이상 필요하지 않습니다.
데이터베이스 요구 사항 문서에 따라 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을 설치할 때, 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['services'] = %w(postgresql)
## Prometheus를 위한 서비스 검색 활성화
consul['monitoring_service_discovery'] =  true

# START user configuration
# 필수 정보 섹션에 설명된 대로 실제 값을 설정하세요
#
# 생성된 md5 값을 사용하여 PGBOUNCER_PASSWORD_HASH 대체
postgresql['pgbouncer_user_password'] = '<pgbouncer_password_hash>'
# 생성된 md5 값을 사용하여 POSTGRESQL_REPLICATION_PASSWORD_HASH 대체
postgresql['sql_replication_password'] = '<postgresql_replication_password_hash>'
# 생성된 md5 값을 사용하여 POSTGRESQL_PASSWORD_HASH 대체
postgresql['sql_user_password'] = '<postgresql_password_hash>'

# Patroni API에 기본 인증 설정 (모든 노드에서 동일한 사용자 이름/비밀번호 사용)
patroni['username'] = '<patroni_api_username>'
patroni['password'] = '<patroni_api_password>'

# 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

PostgreSQL은 pg_rewind를 사용하여 충돌을 처리하기 위해 기본적으로 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

# 익스포터가 청취할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
pgbouncer_exporter['listen_address'] = '0.0.0.0:9188'

첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하고, 이 서버의 동일한 파일에 추가하거나 대체하세요. 이 것이 구성 중인 첫 번째 Linux 패키지 노드이면 이 단계를 건너뛸 수 있습니다.
변경 사항이 적용되려면 GitLab을 재구성하세요.
Consul이 PgBouncer를 다시로드할 수 있도록 .pgpass 파일을 생성하세요. 묻는 대로 PgBouncer 암호를 두 번 입력하세요:
```
gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul
```
각 노드가 현재 마스터와 통신하는지 확인하세요:
```
gitlab-ctl pgb-console # PGBOUNCER_PASSWORD를 입력하라는 메시지가 표시됩니다
```
암호를 입력한 후에 ‘psql: ERROR: Auth failed’와 같은 오류가 발생하면, 이전에 올바른 형식으로 MD5 암호 해시를 생성했는지 확인하세요. 올바른 형식은 암호와 사용자 이름을 연결하는 것입니다. 예: Sup3rS3cr3tpgbouncer는 pgbouncer 사용자를 위한 MD5 암호 해시를 생성하는 데 필요한 텍스트입니다.

콘솔 프롬프트가 사용 가능하면 다음 쿼리를 실행하세요:

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)

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

sudo gitlab-ctl status

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

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

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

Redis 구성

스케일링 환경에서 Redis를 Primary x Replica 토폴로지와 Redis Sentinel 서비스를 사용하여 사용하는 것이 가능합니다. 이는 감시하고 자동으로 장애 조치 절차를 시작합니다.

참고: Redis 클러스터는 각각을 홀수 개의 노드 또는 그 이상으로 배포해야 합니다. 이는 Redis Sentinel이 쿼럼의 일부로 투표할 수 있도록 하기 위한 것입니다. 이는 클라우드 제공 업체 서비스와 같이 외부에서 Redis를 구성할 때는 적용되지 않습니다.

참고: Redis는 주로 단일 스레드이며 CPU 코어 수 증가로 크게 이점을 얻지 않습니다. 자세한 내용은 스케일링 문서를 참조하세요.

Redis는 Sentinel과 함께 사용될 경우 인증이 필요합니다. 자세한 내용은 Redis 보안 문서를 참조해 주세요. Redis 서비스를 보호하기 위해 Redis 암호 및 엄격한 방화벽 규칙의 조합을 사용하는 것을 권장합니다. Redis를 GitLab과 구성하기 전에 전적으로 토폴로지와 아키텍처를 이해하기 위해 Redis Sentinel 문서를 읽는 것을 강력히 권장합니다.

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

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

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

10.6.0.61: Redis Primary
10.6.0.62: Redis Replica 1
10.6.0.63: Redis Replica 2

자체 Redis 인스턴스 제공

다음 안내에 따라 외부 Redis 인스턴스를 위한 제3자 외부 서비스를 선택적으로 사용할 수 있습니다:

신뢰할 수 있는 공급업체 또는 솔루션을 사용해야 합니다. Google Memorystore와 AWS ElastiCache가 작동하는 것으로 알려져 있습니다.
특별히 Redis 클러스터 모드는 지원되지 않지만, HA와 함께 Redis 단독을 지원합니다.
설정에 따라 Redis 유출 모드를 설정해야 합니다.

추가 정보는 권장 클라우드 제공업체 및 서비스를 참조하십시오.

Redis 클러스터 구성

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

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

기본 Redis 노드 구성

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

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

# 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'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD'

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

## 이 기본 Redis 노드의 IP
redis['master_ip'] = '10.6.0.61'

## 프로메테우스를 위한 서비스 검색 활성화
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 만을 따르고 현재 설치와 동일한 버전 및 유형(커뮤니티 또는 엔터프라이즈 에디션)의 올바른 Linux 패키지를 선택해야합니다.

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

# 'redis_sentinel_role' 및 'redis_replica_role' 서버 역할 지정
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'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD'

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

# 기본 Redis 노드의 IP
redis['master_ip'] = '10.6.0.61'

## 프로메테우스를 위한 서비스 검색 활성화
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 클러스터는 GitLab에서 제공하고 권장하는 내고장 허용 솔루션으로, Git 저장소를 저장하는 데 사용됩니다. 이 구성에서 모든 Git 저장소는 클러스터의 각 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 노드에 설치를 확인하십시오. 그런 다음 단계 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

# 사용자 구성 시작
# 필수 정보 섹션에 설명된 대로 실제 값을 설정하세요
#
# 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의 데이터베이스가 완전한 고가용성을 목표로 한다면 언급된 바에 따르면, Praefect의 데이터베이스에 대한 제 3자 PostgreSQL 솔루션이 권장됩니다.

PostgreSQL HA의 많은 제 3자 솔루션이 있습니다. Praefect와 함께 사용하려면 다음이 필요합니다:

failover 시 변경되지 않는 모든 연결을 위한 정적 IP.
LISTEN SQL 기능이 지원되어야 함.

참고: 제 3자 설정을 통해 편리함을 위해 Praefect의 데이터베이스를 기본 GitLab 데이터베이스와 동일한 서버에 함께 배치할 수 있지만, Geo를 사용하는 경우, 별도의 데이터베이스 인스턴스가 복제를 올바르게 처리하기 위해 필요합니다. 이러한 설정에서는 기본 데이터베이스 설정 사양을 변경할 필요가 없어야 하며 영향은 최소화되어야 합니다.

존경받는 제공자나 솔루션이 사용되어야 합니다. Google Cloud SQL 및 Amazon RDS가 작동하는 것으로 알려져 있습니다. 그러나 Amazon Aurora는 기본적으로 로드 밸런싱이 활성화된 경우에 호환되지 않습니다 14.4.0.

자세한 정보는 추천 클라우드 제공자 및 서비스를 참조하십시오.

데이터베이스가 설정된 후 포스트 구성을 따르세요.

Praefect PostgreSQL 포스트 구성

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

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

이를 Linux 패키지 PostgreSQL 설정에서 어떻게 작동하는 지는 다음과 같습니다:

Praefect PostgreSQL 노드에 SSH로 연결합니다.
관리 액세스를 사용하여 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는 꼭 홀수 개의 3개 노드 이상에 배포되어야 합니다. 이는 노드가 의결의 일환으로 투표를 할 수 있도록 보장하기 위한 것입니다.

Praefect는 클러스터 전체의 통신을 보호하는 몇 가지 비밀 토큰을 필요로 합니다:

<praefect_external_token>: 귀하의 Gitaly 클러스터에 호스팅된 저장소에 대한 것으로 이 토큰만을 가진 Gitaly 클라이언트만 접근할 수 있습니다.
<praefect_internal_token>: Gitaly 클러스터 내부의 복제 트래픽에 사용됩니다. 이는 praefect_external_token과 구분되는 것이며, Gitaly 클라이언트는 Praefect 클러스터의 내부 노드에 직접 액세스할 수 없어야 하기 때문에 이것이 필요합니다; 그렇지 않으면 데이터 손실이 발생할 수 있습니다.
<praefect_postgresql_password>: 앞서 이전 섹션에서 정의한 Praefect PostgreSQL 암호가 이 설정에서도 필요합니다.

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

다음 IP 주소를 예로 들겠습니다.

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

각 Praefect 노드에서 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
## Prometheus를 위한 서비스 검색 활성화
consul['monitoring_service_discovery'] = true

# START 사용자 구성
# 필요한 정보 부분에 설명된 대로 실제 값으로 설정하십시오
#

praefect['configuration'] = {
   # ...
   listen_addr: '0.0.0.0:2305',
   auth: {
      # ...
      #
      # Praefect External Token
      # 이것은 Praefect 클러스터와 같은 외부 클러스터 (예: GitLab Shell)에서 통신하기 위해 필요합니다
      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 서버의 git_data_dirs ('praefect') 및 Gitaly 노드 ('gitaly-1')의 gitaly['configuration'][:storage]에 일치해야 합니다
   virtual_storage: [
      {
         # ...
         name: 'default',
         node: [
            {
               storage: 'gitaly-1',
               address: 'tcp://10.6.0.91:8075',
               token: '<praefect_internal_token>'
            },
            {
               storage: 'gitaly-2',
               address: 'tcp://10.6.0.92:8075',
               token: '<praefect_internal_token>'
            },
            {
               storage: 'gitaly-3',
               address: 'tcp://10.6.0.93:8075',
               token: '<praefect_internal_token>'
            },
         ],
      },
   ],
   # 모니터링을 위해 Praefect가 청취할 네트워크 주소 설정
   prometheus_listen_addr: '0.0.0.0:9652',
}

# 모니터링을 위해 노드 익스포터가 청취할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'

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

이 노드에서만 Praefect 데이터베이스 마이그레이션을 실행하려면 다음과 같이 수행하여 praefect['auto_migrate'] 설정 값을 false에서 true로 변경합니다.
자동으로 업그레이드되지 않도록 하기 위해 다음 명령을 실행하여 데이터베이스 마이그레이션이 다시 설정 중에만 실행되도록 합니다.

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

변경 사항이 적용되도록 GitLab을 재구성하세요. 이렇게 하면 Praefect 데이터베이스 마이그레이션이 실행됩니다.

다른 Praefect 노드에서도 GitLab을 재구성하여 변경 사항이 적용되도록 합니다.

Gitaly 구성

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

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

Gitaly가 상당한 입력 및 출력 요구 사항을 가지고 있기 때문에 모든 Gitaly 노드가 고체 상태 드라이브(SSD)를 사용하는 것이 강력히 권장됩니다. 이러한 SSD는 읽기 작업에 대해 초당 8,000회 이상의 처리량 및 쓰기 작업에 대해 2,000회 이상의 IOPS를 가져야 합니다. 환경을 클라우드 제공업체에서 실행 중인 경우, 해당 클라우드 제공업체 문서를 참조하여 IOPS를 올바르게 구성해야 합니다.

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

Gitaly를 구성하기 위해 다음 사항을 주의해야 합니다:

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

다음 IP들은 예시로 사용됩니다:

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

각 노드에서:

선택한 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

# Gitaly
gitaly['enable'] = true

# gitlab-shell API 콜백 URL 구성
# 이를 구성하지 않을 경우 `git push`가 실패합니다. 이것은 '프론트도어' GitLab URL 또는 내부 로드밸런서가 될 수 있습니다.
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'

# 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 네트워크 주소를 모니터링하기 위해 Gitaly가 청취할 네트워크 주소를 설정합니다
   prometheus_listen_addr: '0.0.0.0:9236',
   # Gitaly Auth 토큰
   # praefect_internal_token과 동일해야 합니다
   auth: {
      # ...
      token: '<praefect_internal_token>',
   },
   # Gitaly Pack-objects 캐시
   # 성능 향상을 위해 활성화하는 것이 권장됩니다만 디스크 I/O를 상당히 증가시킬 수 있습니다
   # 자세한 내용은 https://docs.gitlab.com/ee/administration/gitaly/configure_gitaly.html#pack-objects-cache를 참조하십시오
   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 구성 파일의 해당 저장소 항목의 gitaly_address에 tls:// URL 스키마를 사용해야 합니다.
자동으로 제공되지 않으므로 고유한 인증서를 사용해야 합니다. 각 Praefect 서버에 대응하는 인증서를 해당 Praefect 서버에 설치해야 합니다.

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

다음 사항을 참고하세요.

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

Praefect를 TLS로 구성하려면 다음을 수행하세요:

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

파일을 저장하고 GitLab의 다시 구성을 수행하세요.
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 작업 처리가 긴 대기열로 인해 느린 것으로 판명될 경우 적절하게 확장할 수 있습니다. 자세한 내용은 확장 문서를 참조하세요.

참고: 컨테이너 레지스트리, SAML 또는 LDAP와 같은 추가 GitLab 기능을 구성하는 경우 Sidekiq 구성 외에도 Rails 구성을 업데이트해야 합니다. 자세한 내용은 외부 Sidekiq 문서를 참조하세요.

다음 IP 주소를 예로 듭니다.

10.6.0.71: Sidekiq 1
10.6.0.72: Sidekiq 2

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

Sidekiq 서버에 SSH로 로그인합니다.

PostgreSQL, Gitaly 및 Redis 포트에 액세스할 수 있는지 확인하세요:

telnet <GitLab host> 5432 # PostgreSQL
telnet <GitLab host> 8075 # Gitaly
telnet <GitLab host> 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['master_name'] = 'gitlab-redis'

## 마스터 노드용으로 설정한 Redis 인증에 동일한 암호를 사용합니다.
redis['master_password'] = '<redis_primary_password>'

## `host`와 `port`가 있는 sentinel 목록
gitlab_rails['redis_sentinels'] = [
   {'host' => '10.6.0.11', 'port' => 26379},
   {'host' => '10.6.0.12', 'port' => 26379},
   {'host' => '10.6.0.13', 'port' => 26379},
]

# Gitaly 클러스터
## git_data_dirs는 Praefect 가상 저장소에 대해 구성됩니다.
## 주소는 Praefect를 위한 내부 로드 밸런서입니다.
## 토큰은 praefect_external_token입니다.
git_data_dirs({
  "default" => {
    "gitaly_address" => "tcp://10.6.0.40:2305", # 내부 로드 밸런서 IP
    "gitaly_token" => '<praefect_external_token>'
  }
})

# PostgreSQL
gitlab_rails['db_host'] = '10.6.0.40' # 내부 로드 밸런서 IP
gitlab_rails['db_port'] = 6432
gitlab_rails['db_password'] = '<postgresql_user_password>'
gitlab_rails['db_load_balancing'] = { 'hosts' => ['10.6.0.21', '10.6.0.22', '10.6.0.23'] } # PostgreSQL IP

## 업그레이드시 자동으로 데이터베이스 마이그레이션을 방지합니다.
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.81/32', '127.0.0.0/8']
gitlab_rails['prometheus_address'] = '10.6.0.81:9090'

# 객체 저장소
## 이것은 GCP에 대한 객체 저장소를 구성하는 예시입니다.
## 원하는 대로 이 구성을 사용자 지정 객체 저장소 제공업체로 대체하십시오.
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['object_store']['objects']['artifacts']['bucket'] = "<gcp-artifacts-bucket-name>"
gitlab_rails['object_store']['objects']['external_diffs']['bucket'] = "<gcp-external-diffs-bucket-name>"
gitlab_rails['object_store']['objects']['lfs']['bucket'] = "<gcp-lfs-bucket-name>"
gitlab_rails['object_store']['objects']['uploads']['bucket'] = "<gcp-uploads-bucket-name>"
gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"

gitlab_rails['backup_upload_connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"

gitlab_rails['ci_secure_files_object_store_enabled'] = true
gitlab_rails['ci_secure_files_object_store_remote_directory'] = "gcp-ci_secure_files-bucket-name"

gitlab_rails['ci_secure_files_object_store_connection'] = {
   'provider' => 'Google',
   'google_project' => '<gcp-project-name>',
   'google_json_key_location' => '<path-to-gcp-service-account-key>'
}

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

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

sudo gitlab-ctl status

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

run: consul: (pid 30114) 77353s; run: log: (pid 29756) 77367s
run: logrotate: (pid 9898) 3561s; run: log: (pid 29653) 77380s
run: node-exporter: (pid 30134) 77353s; run: log: (pid 29706) 77372s
run: sidekiq: (pid 30142) 77351s; run: log: (pid 29638) 77386s

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

GitLab Rails 구성

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

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

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

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

선택한 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 IPs

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

## Redis 연결 세부 정보
## 각 센티널 노드에서 동일해야 합니다
redis['master_name'] = 'gitlab-redis'

## Redis 기본 노드에서 설정한 Redis 인증을 위한 동일한 비밀번호
redis['master_password'] = '<redis_primary_password>'

## `host` 및 `port`를 갖는 센티널 목록
gitlab_rails['redis_sentinels'] = [
  {'host' => '10.6.0.11', 'port' => 26379},
  {'host' => '10.6.0.12', 'port' => 26379},
  {'host' => '10.6.0.13', 'port' => 26379}
]

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

# 모니터링에 사용될 수 있도록 수신 대기할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
gitlab_workhorse['prometheus_listen_addr'] = '0.0.0.0:9229'
sidekiq['listen_address'] = "0.0.0.0"
puma['listen'] = '0.0.0.0'

## Consul 서버 노드의 IP 주소
## FQDN을 사용하거나 IP와 혼합해서 사용 가능
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}

# 모니터링 노드의 IP 주소를 모니터링 화이트리스트에 추가하고, NGINX 메트릭을 수집할 수 있도록 허용
gitlab_rails['monitoring_whitelist'] = ['10.6.0.81/32', '127.0.0.0/8']
nginx['status']['options']['allow'] = ['10.6.0.81/32', '127.0.0.0/8']
gitlab_rails['prometheus_address'] = '10.6.0.81:9090'

## 다음 옵션을 주석 처리하고 편집하세요 (NFS를 설정한 경우)
##
## NFS 데이터 마운트를 사용할 수 없으면 GitLab이 시작되지 않도록 하세요
##
#high_availability['mountpoint'] = '/var/opt/gitlab/git-data'
##
## NFS를 통한 권한을 위해 서버 간에 UID와 GID가 일치하는지 확인하세요
##
#user['uid'] = 9000
#user['gid'] = 9000
#web_server['uid'] = 9001
#web_server['gid'] = 9001
#registry['uid'] = 9002
#registry['gid'] = 9002

# 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 with TLS support을 사용 중이라면, 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 패키지 노드이면 이 단계를 건너뛸 수 있습니다.
첫 번째 Linux 패키지 노드에서 SSH 호스트 키(/etc/ssh/ssh_host_*_key* 포맷의 모든 파일)를 복사하고 이 서버의 동일한 이름의 파일 추가 또는 교체하세요. 이를 통해 사용자가 로드 밸런스된 Rails 노드에 접근할 때 호스트 불일치 오류가 발생하지 않습니다. 이것이 구성하는 첫 번째 Linux 패키지 노드이면 이 단계를 건너뛸 수 있습니다.
데이터베이스 마이그레이션이 업그레이드 시 자동으로 실행되는 것이 아니라 reconfigure 중에만 실행되도록 하려면 아래를 실행하세요:
```
sudo touch /etc/gitlab/skip-auto-reconfigure
```
디테일은 GitLab Rails 설정 후 구성 섹션에서 설명된 대로 마이그레이션을 처리할 유일한 지정된 노드만이 처리해야 합니다.
변경 사항이 적용되려면 GitLab을 다시 구성하세요.
증분 로깅 활성화하세요.
sudo gitlab-rake gitlab:gitaly:check를 실행하여 노드가 Gitaly에 연결할 수 있는지 확인하세요.
요청을 보려면 로그를 추적하세요:
```
sudo gitlab-ctl tail gitaly
```

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

sudo gitlab-ctl status

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

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

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

GitLab Rails 포스트 구성

모든 마이그레이션이 실행되었는지 확인하십시오:
```
gitlab-rake gitlab:db:configure
```
이 작업은 레일스 노드가 기본 데이터베이스에 직접 연결하도록 레일스 노드를 구성해야 합니다. PgBouncer 우회가 필요합니다. 마이그레이션이 완료되면 노드를 PgBouncer를 통과하도록 다시 구성해야 합니다.
데이터베이스에서 보안 SSH 키를 빠르게 조회하도록 구성하십시오.

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

프로메테우스 구성

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

모니터링 노드에 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 서비스가 실행 중인지 확인하십시오:

sudo gitlab-ctl status

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

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

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

객체 저장소 구성

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

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

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

통합된 형식은 가능한 경우 다음 예제에서 사용되었습니다.

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

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

점진적 로깅 활성화

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

NFS를 통해 작업 로그를 공유하는 것은 지원되지만, NFS 노드를 배포하지 않고도 점진적 로깅을 활성화하는 것이 좋습니다(배포되지 않은 경우 필요함). 점진적 로깅은 작업 로그를 임시로 디스크 공간 대신 Redis를 사용하여 캐싱하는 기능입니다.

고급 검색 구성

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

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

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

낮은 사용자 수(HA)를 위한 지원되는 수정 사항

60 RPS 또는 3,000명의 사용자 GitLab 참조 아키텍처는 고가용성(High Availability, HA)을 달성하는 데 권장하는 최소한의 규모입니다. 그러나 사용자 수나 RPS를 줄이지만 HA를 유지해야 하는 환경에 대해, 복잡성과 비용을 줄이기 위해 아래의 지원되는 수정 사항을 적용할 수 있습니다.

유의할 점은 GitLab에서 HA를 달성하려면 60 RPS 또는 3,000명의 사용자 아키텍처 구성이 최종적으로 필요하다는 것입니다. 각 구성 요소에는 고려해야 할 여러 사항과 규칙이 있으며, 아키텍처는 이러한 모든 사항을 충족합니다. 이 아키텍처의 작은 버전들은 기본적으로 동일하지만 성능 요구 사항이 작아진 경우, 다음 수정 사항이 지원됩니다.

참고: 아래에 명시되지 않은 경우, 낮은 사용자 수에 대한 다른 수정 사항은 지원되지 않습니다.

노드 사양 낮추기: 사용자 수에 따라 제안된 노드 사양을 낮출 수 있습니다. 그러나 일반 요구 사항보다 낮아지지 않도록 권장합니다.
특정 노드 병합: 다음 특정 구성 요소는 성능을 약간 희생하고 복잡성을 줄이기 위해 동일한 노드로 병합하는 것이 지원됩니다:
- GitLab Rails 및 Sidekiq: Sidekiq 노드를 제거하고 해당 구성 요소를 대신 GitLab Rails 노드에 활성화할 수 있습니다.
- PostgreSQL 및 PgBouncer: PgBouncer 노드를 제거하고 대신 PostgreSQL 노드에서 활성화할 수 있으며 내부 로드 밸런서는 해당 노드를 가리켜야 합니다. 그러나 데이터베이스 로드 밸런싱을 활성화하려면 별도의 PgBouncer 배열이 여전히 필요합니다.
노드 수 줄이기: 일부 노드 유형은 합의가 필요하지 않으며 더 적은 노드로 실행할 수 있습니다(하지만 여분의 노드가 있어야 함):
- GitLab Rails 및 Sidekiq: 상태가 없는 서비스에는 최소 노드 수가 없습니다. 여분의 2개가 있으면 충분합니다.
- PostgreSQL 및 PgBouncer: 합의가 엄격히 필요하지는 않습니다. 2개의 PostgreSQL 노드와 2개의 PgBouncer 노드가 여분으로 충분합니다.
- Consul, Redis Sentinel, Praefect: 홀수 개수가 필요하며, 투표 권한을 위해 최소 3개의 노드가 필요합니다.
신뢰할 수 있는 Cloud PaaS 솔루션에서 특정 구성 요소 실행: 특정 구성 요소는 신뢰할 수 있는 클라우드 제공자 PaaS 솔루션에서 실행할 수 있습니다. 이를 통해 종속 구성 요소도 제거할 수 있습니다:
- PostgreSQL: Google Cloud SQL이나 Amazon RDS와 같은 신뢰할 수 있는 클라우드 PaaS 솔루션에서 실행할 수 있습니다. 이러한 설정에서는 더 이상 PgBouncer와 Consul 노드가 필요하지 않습니다:
  - Prometheus 자동 탐지가 필요한 경우에는 여전히 Consul이 필요할 수 있으며, 그렇지 않은 경우에는 모든 노드에 대해 수동으로 스크래핑 구성을 추가해야 합니다.
- Redis: Google Memorystore 및 AWS ElastiCache와 같은 신뢰할 수 있는 클라우드 PaaS 솔루션에서 실행할 수 있습니다. 이러한 설정에서는 더 이상 Redis Sentinel이 필요하지 않습니다.

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

클라우드 네이티브 GitLab의 선택된 구성 요소를 GitLab Helm 차트를 사용하여 Kubernetes에서 실행합니다. 이 설정에서는 Kubernetes 클러스터 내의 Webservice와 같은 GitLab Rails의 동등한 구성 요소를 실행할 수 있습니다. 또한, 다음과 같은 기타 지원 서비스도 지원됩니다: NGINX, Toolbox, Migrations, Prometheus.

하이브리드 설치는 클라우드 네이티브 워크로드 관리 이점과 Linux 패키지 설치를 통해 지속성이 높아지는 컴퓨팅 배포의 이점을 활용합니다.

Kubernetes와 백엔드 구성 요소 간의 GitLab 비밀을 동기화하는 방법을 포함한 설정 지침에 대한 고급 구성에 대한 자세한 내용은 GitLab secrets to sync between Kubernetes and the backend components문서를 참조하십시오.

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

경고: Gitaly Cluster는 Kubernetes에서 실행되지 않습니다. 자세한 내용은 epic 6127를 참조하십시오.

클러스터 토폴로지

아래 표와 다이어그램은 위의 전형적인 환경과 동일한 형식으로 하이브리드 환경을 보여줍니다.

먼저 Kubernetes에서 실행되는 구성 요소입니다. 이는 전체적인 구성을 원하는대로 변경할 수 있지만, 최소 CPU 및 메모리 요구 사항을 준수해야 합니다.

구성 요소 노드 그룹	대상 노드 풀 총계	GCP 예제	AWS 예제
Webservice	16 vCPU 20 GB 메모리 (요청) 28 GB 메모리 (제한)	2 x `n1-standard-16`	2 x `c5.4xlarge`
Sidekiq	7.2 vCPU 16 GB 메모리 (요청) 32 GB 메모리 (제한)	3 x `n1-standard-4`	3 x `m5.xlarge`
지원 서비스	4 vCPU 15 GB 메모리	2 x `n1-standard-2`	2 x `m5.large`

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

다음은 Linux 패키지를 사용하여 정적 컴퓨팅 VM에서 실행되는 백엔드 구성 요소입니다:

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

각주:

선택 사항에 따라 신뢰할 수 있는 서드파티 외부 PaaS PostgreSQL 솔루션에서 실행할 수 있습니다. 자세한 내용은 Provide your own PostgreSQL instance를 참조하십시오.
선택 사항에 따라 신뢰할 수 있는 서드파티 외부 PaaS Redis 솔루션에서 실행할 수 있습니다. 자세한 내용은 Provide your own Redis instance를 참조하십시오.
고가용성 기능을 제공할 수 있는 신뢰할 수 있는 PaaS 로드 밸런서 또는 서비스(LB PaaS)로 실행되는 것을 권장합니다. 사이징은 선택한 로드 밸런서 및 네트워크 대역폭과 같은 추가 요소에 따라 달라집니다. 자세한 내용은 Load Balancers를 참조하십시오.
신뢰할 수 있는 클라우드 제공자 또는 Self Managed 솔루션에서 실행되어야 합니다. 자세한 내용은 Configure the object storage를 참조하십시오.
Gitaly 클러스터는 장애 허용 이점을 제공하지만 설정 및 관리에 추가 복잡성이 따릅니다. Gitaly Cluster를 배포하기 전에 기술적 제한 사항을 검토하십시오. 샤딩된 Gitaly를 원하는 경우 Gitaly에 대한 동일한 사양을 사용하십시오.
Gitaly 사양은 건강한 상태에서 사용 패턴 및 리포지토리 크기의 상위 백분위수에 기초합니다. 그러나 대형 모노 리포(몇 기가바이트 이상) 또는 추가 워크로드가 있는 경우 Git 및 Gitaly의 성능에 상당한 영향을 미칠 수 있으며 추가 조정이 필요할 수 있습니다.

Kubernetes 구성 요소 대상

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

Webservice

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

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

60 RPS 또는 3,000 사용자를 위해 대략 16개의 총 Puma worker 수를 권장하며, 이에 따라 적어도 4개의 Webservice pod를 실행하는 것이 좋습니다.

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

NGINX

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

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

Sidekiq

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

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

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

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

지원

Supporting 노드 풀은 Webservice 및 Sidekiq 풀에 필요하지 않은 모든 지원 배포물을 포함하는 것을 목적으로 합니다.

이에는 클라우드 공급자의 구현과 관련된 다양한 배포물 및 GitLab Shell과 같은 GitLab 배포물이 포함됩니다.

컨테이너 레지스트리, Pages 또는 모니터링과 같이 추가 배포물을 설치하려면 가능한 경우 이 풀에 설치하는 것이 좋습니다. 지원 풀은 여러 추가 배포물을 수용할 수 있도록 특별히 설계되었기 때문에 Webservice 또는 Sidekiq 풀에 설치하지 않는 것이 좋습니다. 그러나 사용 사례에 맞지 않는 배포물이 있으면 노드 풀을 적절하게 확대할 수 있습니다. 반대로 사용 사례에서 풀이 초과로 공급되는 경우에는 적절하게 줄일 수 있습니다.

구성 파일 예시

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

구성 요소 설정으로 이동

다음 단계

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

요구 사항에 따라 GitLab의 추가적인 선택적 기능을 구성할 수 있습니다. 자세한 내용은 GitLab 설치 후 단계를 참조하십시오.

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

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

요구 사항

테스팅 방법론

구성 요소 설정

외부 로드 밸런서 구성

준비 상태 확인

포트

대체 SSH 포트

SSL

응용 프로그램 노드가 SSL을 해제함

로드 밸런서가 백엔드 SSL 없이 SSL을 해제함

로드 밸런서가 백엔드 SSL로 SSL을 해제함

내부 로드 밸런서 구성

Consul 구성

PostgreSQL 구성

고유한 PostgreSQL 인스턴스 제공

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

PostgreSQL 노드

PostgreSQL 포스트-구성

PgBouncer 구성

Redis 구성

자체 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 포스트 구성

프로메테우스 구성

객체 저장소 구성

점진적 로깅 활성화

고급 검색 구성

낮은 사용자 수(HA)를 위한 지원되는 수정 사항

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

클러스터 토폴로지

Kubernetes 구성 요소 대상

Webservice

NGINX

Sidekiq

지원

구성 파일 예시

다음 단계

도움말

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

도움받기