Consul 구성
PostgreSQL 구성
Redis 구성
Gitaly 클러스터 구성
Sidekiq 구성
GitLab Rails 구성
- GitLab Rails 포스트 구성
프로메테우스 구성
객체 저장소 구성
- 증분 로깅 활성화
고급 검색 구성
Helm 차트를 활용한 클라우드 네이티브 하이브리드 참조 아키텍처 (대체 옵션)

참조 아키텍처: 최대 25,000명의 사용자까지

Tier: Premium, Ultimate Offering: Self-Managed

이 페이지는 최대 25,000명의 사용자 부하를 고려하여 설계된 GitLab 참조 아키텍처를 설명합니다. 주목할만한 여유 공간이 있습니다.

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

참고: 이 아키텍처를 배포하기 전에 먼저 기본 설명서를 읽는 것이 좋습니다. 특히 시작하기 전에 및 사용할 아키텍처 결정 섹션을 읽어보십시오.

대상 부하: API: 500 RPS, Web: 50 RPS, Git (Pull): 50 RPS, Git (Push): 10 RPS
고가용성: 예 (HA를 위해 Praefect는 서드파티 PostgreSQL 솔루션이 필요합니다.)
예상 비용: 비용 표 참조
클라우드 네이티브 하이브리드 대체 옵션: 예
어떤 참조 아키텍처를 사용해야 하는지 잘 모르겠습니까? 자세한 정보는 여기서 확인

서비스	노드	구성	GCP	AWS	Azure
외부 로드 밸런서³	1	8 vCPU, 7.2 GB 메모리	`n1-highcpu-8`	`c5n.2xlarge`	`F8s v2`
Consul¹	3	2 vCPU, 1.8 GB 메모리	`n1-highcpu-2`	`c5.large`	`F2s v2`
PostgreSQL¹	3	16 vCPU, 60 GB 메모리	`n1-standard-16`	`m5.4xlarge`	`D16s v3`
PgBouncer¹	3	2 vCPU, 1.8 GB 메모리	`n1-highcpu-2`	`c5.large`	`F2s v2`
내부 로드 밸런서³	1	8 vCPU, 7.2 GB 메모리	`n1-highcpu-8`	`c5n.2xlarge`	`F8s 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	32 vCPU, 120 GB 메모리⁶	`n1-standard-32`	`m5.8xlarge`	`D32s 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⁷	5	32 vCPU, 28.8 GB 메모리	`n1-highcpu-32`	`c5.9xlarge`	`F32s v2`
모니터링 노드	1	4 vCPU, 3.6 GB 메모리	`n1-highcpu-4`	`c5.xlarge`	`F4s v2`
객체 저장소⁴	-	-	-	-	-

각주:

신뢰할 수 있는 서드파티 외부 PaaS PostgreSQL 솔루션에서 선택 사항으로 실행할 수 있습니다. 자세한 내용은 고유의 PostgreSQL 인스턴스 제공를 참조하십시오.
신뢰할 수 있는 서드파티 외부 PaaS Redis 솔루션에서 선택 사항으로 실행할 수 있습니다. 자세한 내용은 고유의 Redis 인스턴스 제공를 참조하십시오.
- Redis는 주로 단일 스레드이며 CPU 코어의 증가로 크게 이점을 얻지 못합니다. 이 크기의 아키텍처의 경우, 최적의 성능을 위해 별도의 캐시 및 지속 인스턴스를 지정하여야 합니다.
신뢰할 수 있는 서드파티 로드 밸런서 또는 HA 기능을 제공할 수 있는 서비스 (LB PaaS)에서 추천됩니다. 또한, 사이징은 선택한 로드 밸런서에 따라 네트워크 대역폭과 같은 추가 요인에 따라 달라집니다. 자세한 내용은 로드 밸런서를 참조하십시오.
신뢰할 수 있는 클라우드 제공 업체 또는 자체 관리 솔루션에서 실행해야 합니다. 자세한 내용은 객체 저장소 구성를 참조하십시오.
Gitaly 클러스터는 오류 허용성의 이점을 제공하지만 추가적인 설정 및 관리 복잡성을 동반합니다. Gitaly 클러스터를 배포하기 전에 기존의 기술적 제한 사항 및 고려 사항을 검토해야 합니다. 샤드된 Gitaly를 원하시는 경우, Gitaly에 대해 위에서 나열한 동일한 사양을 사용하십시오.
Gitaly 사양은 주로 건강한 상태에서의 사용 패턴 및 저장소 크기의 높은 백분위수에 기반합니다. 그러나, 대형 모노 리포지토리 (몇 기가바이트 이상) 또는 추가 작업 부하가 있을 경우 이는 Git 및 Gitaly 성능에 크게 영향을 미치며 추가 조정이 필요할 수 있습니다.
컴포넌트는 stateful data의 자동 확장을 수행하기 때문에 Auto Scaling 그룹 (ASG)에 배치할 수 있습니다. 그러나, GitLab Rails의 경우 마이그레이션 및 Mailroom과 같은 특정 프로세스는 하나의 노드에서만 실행되어야 합니다.

참고: 인스턴스를 구성하는 PaaS 솔루션의 경우, 견고한 클라우드 아키텍처 원칙을 따르기 위해 3개의 노드가 최소한 3개의 다른 가용 영역에 구현하는 것이 강력히 권장됩니다.

## 요구 사항

시작하기 전에 참조 아키텍처의 [요구 사항](index.md#requirements)을 확인하세요.

## 테스트 방법론

25k 아키텍처는 다양한 워크플로우를 포괄하도록 설계되었으며 정기적으로 Quality Engineering 팀에 의해 [스모크 및 성능 테스트](index.md#validation-and-test-results)되어 다음 엔드포인트 처리량 목표에 대해 평가됩니다.

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

위의 목표는 CI 및 기타 워크로드와 함께 총 환경 부하에 해당하는 실제 고객 데이터를 기반으로 선택되었으며 추가적인 상당한 여유가 추가되었습니다.

위 엔드포인트 목표에 대해 정기적으로 더 높은 처리량을 나타내는 메트릭이 있는 경우, [대형 모노레포](index.md#large-monorepos)나 주목할만한 [추가 워크로드](index.md#additional-workloads)가 있는 경우, 성능 환경에 상당한 영향을 줄 수 있으며 [추가적인 조정이 필요할 수 있습니다](index.md#scaling-an-environment). 해당 사항이 해당되는 경우, 링크된 문서를 참조하는 것과 더불어 추가적인 지침을 위해 귀하의 [고객 성공 관리자](https://handbook.gitlab.com/job-families/sales/customer-success-management/) 또는 [지원팀](https://about.gitlab.com/support/)에 문의하는 것을 강력히 권장합니다.

테스트는 정기적으로 [GitLab 성능 도구 (GPT)](https://gitlab.com/gitlab-org/quality/performance) 및 해당 데이터셋을 사용하여 수행됩니다. 이러한 테스트의 결과는 [GPT 위키에서 공개적으로 사용 가능](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Benchmarks/Latest)합니다. 테스트 전략에 대한 자세한 정보는 [문서의 이 섹션](index.md#validation-and-test-results)을 참조하세요.

테스트에 사용되는 로드 밸런서는 Linux 패키지 환경의 경우 HAProxy이며 크라우드 네이티브 하이브리드의 경우 같은 선택 사항이 해당되며, 이러한 선택 사항은 특정 요구 사항이나 권장 사항을 대표하지 않음을 알립니다. 대부분의 [신뢰할 수 있는 로드 밸런서가 작동되도록 예상됩니다](#configure-the-external-load-balancer).

## 구성 구성 요소

GitLab 및 해당 구성 요소를 25,000명까지 수용할 수 있도록 설정하려면 다음을 수행하세요:

1. [외부 로드 밸런서 구성](#configure-the-external-load-balancer)
   - GitLab 애플리케이션 서비스 노드의 부하 분산을 처리합니다.
1. [내부 로드 밸런서 구성](#configure-the-internal-load-balancer)
   - GitLab 애플리케이션 내부 연결의 부하 분산을 처리합니다.
1. [Consul 구성](#configure-consul).
1. [PostgreSQL 구성](#configure-postgresql), GitLab의 데이터베이스.
1. [PgBouncer 구성](#configure-pgbouncer).
1. [Redis 구성](#configure-redis).
1. [Gitaly 클러스터 구성](#configure-gitaly-cluster)
   - Git 저장소에 액세스를 제공합니다.
1. [Sidekiq 구성](#configure-sidekiq).
1. [주 GitLab Rails 애플리케이션 구성](#configure-gitlab-rails)
   - Puma, Workhorse, GitLab Shell을 실행하고 모든 프론트엔드 요청(UI, API, Git over HTTP/SSH 포함)을 제공합니다.
1. [Prometheus 구성](#configure-prometheus)
   - GitLab 환경을 모니터링합니다.
1. [객체 저장소 구성](#configure-the-object-storage)
   - 공유 데이터 객체에 사용됩니다.
1. [고급 검색 구성](#configure-advanced-search) (선택 사항)
   - 전체 GitLab 인스턴스에서 더 빠르고 고급 코드 검색을 위해 설정됩니다.

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

다음 목록에는 각 서버와 해당 IP가 지정되어 있습니다:

- `10.6.0.10`: 외부 로드 밸런서
- `10.6.0.11`: Consul 1
- `10.6.0.12`: Consul 2
- `10.6.0.13`: Consul 3
- `10.6.0.21`: PostgreSQL 주
- `10.6.0.22`: PostgreSQL 보조 1
- `10.6.0.23`: PostgreSQL 보조 2
- `10.6.0.31`: PgBouncer 1
- `10.6.0.32`: PgBouncer 2
- `10.6.0.33`: PgBouncer 3
- `10.6.0.40`: 내부 로드 밸런서
- `10.6.0.51`: Redis - 캐시 프라이머리
- `10.6.0.52`: Redis - 캐시 레플리카 1
- `10.6.0.53`: Redis - 캐시 레플리카 2
- `10.6.0.61`: Redis - 지속적인 프라이머리
- `10.6.0.62`: Redis - 지속적인 레플리카 1
- `10.6.0.63`: Redis - 지속적인 레플리카 2
- `10.6.0.91`: Gitaly 1
- `10.6.0.92`: Gitaly 2
- `10.6.0.93`: Gitaly 3
- `10.6.0.131`: Praefect 1
- `10.6.0.132`: Praefect 2
- `10.6.0.133`: Praefect 3
- `10.6.0.141`: Praefect PostgreSQL 1 (비 HA)
- `10.6.0.101`: Sidekiq 1
- `10.6.0.102`: Sidekiq 2
- `10.6.0.103`: Sidekiq 3
- `10.6.0.104`: Sidekiq 4
- `10.6.0.111`: GitLab 애플리케이션 1
- `10.6.0.112`: GitLab 애플리케이션 2
- `10.6.0.113`: GitLab 애플리케이션 3
- `10.6.0.114`: GitLab 애플리케이션 4
- `10.6.0.115`: GitLab 애플리케이션 5
- `10.6.0.151`: Prometheus

## 외부 로드 밸런서 구성

다중 노드 GitLab 구성에서는 응용 프로그램 서버로 트래픽을 라우팅하기 위해 외부 로드 밸런서가 필요합니다.

로드 밸런서의 사용 또는 정확한 구성에 대한 구체적인 정보는 GitLab 설명서의 범위를 벗어나지만 일반 요구 사항에 대한 자세한 정보는 [로드 밸런서](index.md)를 참조하십시오. 본 섹션은 선택한 로드 밸런서를 구성하는 구체적인 내용에 중점을 두겠습니다.

### 준비 확인

외부 로드 밸런서가 노드에 대한 모니터링 엔드포인트가 포함된 작동 중인 서비스로만 라우팅되도록 합니다. [준비 확인](../monitoring/health_check.md) 모두에는 노드에 대한 [추가 구성](../monitoring/ip_allowlist.md)이 필요하며, 그렇지 않으면 외부 로드 밸런서가 연결할 수 없게 됩니다.

### 포트

사용되는 기본 포트는 다음 표에 표시됩니다.

| 로드 밸런서 포트 | 백엔드 포트 | 프로토콜                 |
| --------------- | ------------ | ------------------------ |
| 80              | 80           | HTTP (*1*)               |
| 443             | 443          | TCP 또는 HTTPS (*1*) (*2*) |
| 22              | 22           | TCP                      |

- (*1*): [웹 터미널](../../ci/environments/index.md#web-terminals-deprecated) 지원에는 로드 밸런서가 WebSocket 연결을 올바르게 처리해야합니다. HTTP 또는 HTTPS 프록시를 사용할 때, 로드 밸런서는 `Connection` 및 `Upgrade` hop-by-hop 헤더를 통과해야합니다. 자세한 내용은 [웹 터미널](../integration/terminal.md) 통합 가이드를 참조하세요.
- (*2*): 포트 443에 HTTPS 프로토콜을 사용하는 경우, 로드 밸런서에 SSL 인증서를 추가해야합니다. SSL을 GitLab 응용 프로그램 서버에서 종료하려면 TCP 프로토콜을 사용합니다.

사용자 정의 도메인 지원이 있는 GitLab Pages를 사용하는 경우 추가 포트 구성이 필요합니다.
GitLab Pages에는 별도의 가상 IP 주소가 필요합니다. DNS를 구성하여 `/etc/gitlab/gitlab.rb`의 `pages_external_url`을 새로운 가상 IP 주소를 가리키도록합니다. 자세한 내용은 [GitLab Pages 문서](../pages/index.md)를 참조하십시오.

| 로드 밸런서 포트 | 백엔드 포트  | 프로토콜  |
| --------------- | ------------- | --------- |
| 80              | 다양함 (*1*)  | HTTP      |
| 443             | 다양함 (*1*)  | TCP (*2*) |

- (*1*): GitLab Pages의 백엔드 포트는 `gitlab_pages['external_http']` 및 `gitlab_pages['external_https']` 설정에 따라 다릅니다. 자세한 내용은 [GitLab Pages 문서](../pages/index.md)를 참조하십시오.
- (*2*): GitLab Pages의 포트 443은 항상 TCP 프로토콜을 사용해야합니다. 사용자는 로드 밸런서에서 SSL을 종료시키는 경우 사용자 지정 SSL로 사용자 정의 도메인을 구성할 수 있습니다.

#### 대체 SSH 포트

일부 기관은 SSH 포트 22를 열지 않는 정책을 가지고 있습니다. 이러한 경우 사용자가 443 포트에서 SSH를 사용할 수 있는 대체 SSH 호스트 이름을 구성하는 것이 도움이 될 수 있습니다. 다른 GitLab HTTP 구성과 비교하여 대체 SSH 호스트 이름은 새로운 가상 IP 주소가 필요합니다.

대체 SSH 호스트 이름인 `altssh.gitlab.example.com`에 대해 DNS를 구성하세요.

| 로드 밸런서 포트 | 백엔드 포트 | 프로토콜 |
| --------------- | ------------ | -------- |
| 443             | 22           | TCP      |

### SSL

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

- [응용 프로그램 노드가 SSL을 종료](#application-node-terminates-ssl).
- [로드 밸런서가 백엔드 SSL 없이 SSL을 종료](#load-balancer-terminates-ssl-without-backend-ssl)하고 로드 밸런서와 응용 프로그램 노드 사이의 통신은 안전하지 않습니다.
- [로드 밸런서가 백엔드 SSL과 함께 SSL을 종료](#load-balancer-terminates-ssl-with-backend-ssl)하고 로드 밸런서와 응용 프로그램 노드 사이의 통신은 *안전*합니다.

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

로드 밸런서를 구성하여 포트 443의 연결을 `HTTP(S)` 프로토콜 대신 `TCP`로 전달합니다. 이렇게하면 연결이 응용 프로그램 노드의 NGINX 서비스로 그대로 전달됩니다. NGINX에는 SSL 인증서가 있으며 포트 443에서 수신 대기합니다.

SSL 인증서 관리 및 NGINX 구성에 대한 자세한 내용은 [HTTPS 문서](https://docs.gitlab.com/omnibus/settings/ssl/index.html)를 참조하십시오.

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

로드 밸런서를 구성하여 `TCP` 대신 `HTTP(S)` 프로토콜을 사용합니다. 로드 밸런서는 SSL 인증서를 관리하고 SSL을 종료할 책임이 있습니다.

로드 밸런서와 GitLab 사이의 통신이 안전하지 않기 때문에 추가 구성이 필요합니다. 자세한 내용은 [프록시 SSL 문서](https://docs.gitlab.com/omnibus/settings/ssl/index.html#configure-a-reverse-proxy-or-load-balancer-ssl-termination)를 참조하십시오.

#### 로드 밸런서는 백엔드 SSL에 대해 SSL을 종료합니다.

로드 밸런서를 'TCP'가 아닌 'HTTP(S)' 프로토콜을 사용하도록 구성하세요.  
로드 밸런서는 사용자가 보는 SSL 인증서를 관리할 것입니다.

또한 이 시나리오에서는 로드 밸런서와 NGINX 사이의 트래픽도 안전합니다. 연결이 안전하므로 프락시 SSL을 추가할 필요가 없습니다. 그러나 GitLab에 SSL 인증서를 구성해야 합니다. SSL 인증서 관리 및 NGINX 구성에 대한 자세한 내용은 [HTTPS 문서](https://docs.gitlab.com/omnibus/settings/ssl/index.html)를 참조하세요.

<div align="right">
  <a type="button" class="btn btn-default" href="#setup-components">
    설정 구성 요소로 돌아가기 <i class="fa fa-angle-double-up" aria-hidden="true"></i>
  </a>
</div>

## 내부 로드 밸런서 구성

내부 로드 밸런서는 [PgBouncer](#configure-pgbouncer) 및 [Praefect](#configure-praefect) (Gitaly 클러스터)와 같은 GitLab 환경이 필요로 하는 내부 연결을 균형잡기 위해 사용됩니다.

내부 로드 밸런서는 외부적으로 액세스할 필요가 없는 완전히 별도의 노드입니다.

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

- `10.6.0.40`: 내부 로드 밸런서

다음은 [HAProxy](https://www.haproxy.org/)를 사용하여 수행하는 방법입니다:

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

    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 로그를 보면 다음과 같이 ‘…[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부터 기본적으로 활성화된 로드 밸런싱과 호환되지 않습니다. 자세한 내용은 권장 클라우드 공급업체 및 서비스를 참조하십시오.

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

HA Linux 패키지 PostgreSQL 설정에는 PostgreSQL, PgBouncer 및 Consul이 포함됩니다. 이러한 구성 요소들은 외부의 PostgreSQL 서비스를 사용할 때 더 이상 필요하지 않을 수 있습니다.
데이터베이스 요구 사항 문서에 따라 PostgreSQL을 설정합니다.
gitlab 사용자를 원하는 비밀번호로 설정합니다. gitlab 사용자는 gitlabhq_production 데이터베이스를 생성할 수 있는 권한이 필요합니다.
GitLab 애플리케이션 서버를 적절한 세부 정보로 구성합니다. 이 단계는 GitLab Rails 애플리케이션 구성에서 다루고 있습니다.
HA를 달성하기 위해 필요한 노드 수는 Linux 패키지와 비교할 때 서비스에 따라 다를 수 있으며, 해당 사항에 맞춰 일치시킬 필요가 없습니다.
그러나 추가적인 성능 향상을 위해 데이터베이스 로드 밸런싱을 위해 읽기 전용 복제본을 희망하는 경우, 참조 아키텍처에 대한 노드 수를 따르는 것이 권장됩니다.

독립적인 Linux 패키지를 사용한 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 패키지 저장소를 추가합니다. 두 번째 단계에서는 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
# 필요한 정보 섹션에 설명된대로 실제 값을 설정하십시오
#
# PGBOUNCER_PASSWORD_HASH를 생성된 md5 값으로 대체
postgresql['pgbouncer_user_password'] = '<pgbouncer_password_hash>'
# POSTGRESQL_REPLICATION_PASSWORD_HASH를 생성된 md5 값으로 대체
postgresql['sql_replication_password'] = '<postgresql_replication_password_hash>'
# POSTGRESQL_PASSWORD_HASH를 생성된 md5 값으로 대체
postgresql['sql_user_password'] = '<postgresql_password_hash>'

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

# 네트워크 주소를 리스닝하게 하는 PostgreSQL
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

# 내보내기가 수신 대기할 네트워크 주소 설정
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을 다시 구성하십시오.

각 노드가 현재 primary와 통신하도록 확인합니다:

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를 사용하는 것은 주 서버 x 복제본 토폴로지와 Redis Sentinel 서비스를 사용하여 장애 조치 절차를 자동으로 시작하는 것이 가능합니다.

주의: Redis 클러스터는 각각 홀수 개의 3개 노드 이상에 배포되어야 합니다. 이는 Redis Sentinel이 쿼럼의 일부로서 투표를 할 수 있도록 보장하기 위함입니다. 이는 클라우드 제공 업체 서비스와 같이 외부에서 Redis를 구성할 때는 해당되지 않습니다.

주의: Redis는 기본적으로 단일 스레드이며 CPU 코어의 증가로부터 혜택을 거의 받지 않습니다. 이런 규모의 아키텍처에서는 최적의 성능을 달성하기 위해 별도의 캐시 및 영속성 인스턴스를 사용하는 것이 강력히 권장됩니다. 자세한 내용은 스케일링 문서를 참조하세요.

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

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

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

이 섹션에서는 GitLab에서 사용할 외부 Redis 클러스터 2개를 구성하는 방법을 안내합니다. 다음 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']에서 정의된 동일한 암호를 가져야 합니다. 장애 조치 중에 Sentinels는 노드를 재구성하고 그 상태를 주 서버에서 복제본으로 변경할 수 있습니다(그 반대도 가능합니다).

주 서버 Redis 캐시 노드 구성

주 서버 Redis 서버에 SSH로 접속하세요.
선택한 Linux 패키지를 다운로드 및 설치하세요. 페이지에서 설치 단계 1 및 2만 따르고, 현재 설치된 버전 및 타입(커뮤니티 또는 엔터프라이즈 에디션)과 동일한 Linux 패키지를 선택해야 합니다.

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

# 서버 역할을 'redis_sentinel_role', 'redis_master_role', 'consul_role'로 지정
roles ['redis_sentinel_role', 'redis_master_role', 'consul_role']

# Redis Sentinel 서비스용 바인딩 주소 및 쿼럼 번호를 설정합니다.
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

# 전송중인 Redis 서버의 포트, 비고를 제거하여 기본값으로 변경할 수 있습니다.
# 이 항목은 `6379`로 기본값을 가지고 있습니다.
# redis['master_port'] = 6379

# Redis에 대한 암호 인증을 설정합니다(모든 노드에서 동일한 암호를 사용하세요).
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

## 프로메테우스를 위한 서비스 검색을 활성화
consul['monitoring_service_discovery'] =  true

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

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

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

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

레디스 캐시 노드의 복제본 구성

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

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

# 서버 역할을 '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.52'

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

## Sentinel을 위한 주 Redis 서버의 포트, 비기본값으로 변경하려면 주석 처리합니다. 기본값은 `6379`입니다.
#redis['master_port'] = 6379

# Redis 및 복제본에 대한 암호 인증 설정(모든 노드에서 동일한 암호 사용)
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
## 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'
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']에서 정의된 동일한 암호가 필요합니다. 장애 조치 중에는 Sentinels가 노드를 재구성하고 그 상태를 주 또는 복제본으로 변경할 수 있습니다.

주(Primary) Redis 지속 노드 구성

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

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

# 서버 역할을 'redis_sentinel_role'와 'redis_master_role'로 지정합니다
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'

## 이 주(Primary) 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

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

복제 레디스 지속 노드 구성

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

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

# 서버 역할을 '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 주소입니다.
# 모든 인터페이스에서 수신하도록 bind를 '0.0.0.0'로도 설정할 수 있습니다.
# 외부 접근 가능한 IP에 바인드해야 하는 경우 무단 액세스를 방지하기 위해 추가 방화벽 규칙을 설정하세요.
redis['bind'] = '10.6.0.62'

# 다른 기계가 연결할 수 있게하는 TCP 요청을 수신하기 위해 Redis가 수신 대기할 포트를 정의합니다.
redis['port'] = 6379

## Sentinel을 위한 주된 Redis 서버의 포트로, 기본적으로 변경되어 있지 않은 경우 주석 처리하세요. 기본값은 `6379`입니다.
#redis['master_port'] = 6379

# 주 노드에 대한 Redis 인증용 동일한 암호를 설정하세요.
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'

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

# 주 Redis 노드의 IP입니다.
redis['master_ip'] = '10.6.0.61'

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

## Consul 서버 노드의 IP
## FQDN을 사용하고 IP와 섞어도 괜찮습니다.
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}

# 내보내기가 수신 대기할 네트워크 주소를 설정합니다.
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'
redis_exporter['flags'] = {
     'redis.addr' => 'redis://10.6.0.62:6379',
     'redis.password' => 'redis-password-goes-here',
}

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

첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하고 이 서버의 동일한 이름의 파일에 추가하거나 바꿔치기하세요. 이것이 구성 중인 첫 번째 Linux 패키지 노드인 경우 이 단계를 건너뛸 수 있습니다.
변경 사항이 적용되려면 GitLab을 다시 구성하세요.
다른 복제 노드에 대해 다시 단계를 통과하고 IP를 올바르게 설정했는지 확인하세요.

고급 구성 옵션은 필요한 경우 지원됩니다.

설정 구성 요소로 돌아가기

Gitaly 클러스터 구성

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

경고: Gitaly 사양은 사용 패턴 및 저장소 크기의 높은 백분위수를 기반으로 합니다. 그러나 대형 모노 리포(여러 기가바이트보다 큼) 또는 추가 워크로드의 경우 이러한 요소는 *환경의 성능에 중대한 영향을 미치며 추가 조정이 필요할 수 있습니다. 이러한 요소가 해당되는 경우 연결된 문서를 참조하고 Customer Success Manager 또는 Support team에 문의하여 안내를 받는 것이 강력히 권장됩니다.

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

가이드:

sharded Gitaly를 구현하려면 별도의 Gitaly 문서를 참조하세요. 동일한 Gitaly 사양을 사용하세요.
Gitaly 클러스터에서 관리되지 않는 기존 저장소를 이주하려면 Gitaly 클러스터로의 이주를 참조하세요.

권장 클러스터 구성에는 다음 구성요소가 포함됩니다:

3개의 Gitaly 노드: Git 저장소의 복제 저장
3개의 Praefect 노드: Gitaly 클러스터의 라우터 및 트랜잭션 관리자
1개의 Praefect PostgreSQL 노드: Praefect의 데이터베이스 서버. Praefect 데이터베이스 연결을 고도화하기 위해 제삿구멍 솔루션이 필요합니다.
1개의 로드 밸런서: Praefect에 필요한 로드 밸런서. 내부 로드 밸런서 설정를 사용합니다.

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

Praefect PostgreSQL 구성

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

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

Praefect 비-HA PostgreSQL 스탠드얼론(Linux 패키지 사용)

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

10.6.0.141: Praefect PostgreSQL

먼저, Praefect PostgreSQL 노드에 Linux GitLab 패키지를 설치하십시오. 다음 단계에서 필요한 종속성을 설치하고, 두 번째 단계에서 GitLab 패키지 저장소를 추가하십시오. 두 번째 단계에서 GitLab을 설치할 때 EXTERNAL_URL 값을 제공하지 마십시오.

Praefect PostgreSQL 노드로 SSH하여 들어갑니다.
Praefect PostgreSQL 사용자에게 사용할 강력한 암호를 생성하십시오. 이 암호를 <praefect_postgresql_password>로 기록해 두십시오.
Praefect PostgreSQL 사용자 이름/암호 쌍의 암호 해시를 생성하십시오. 이 명령은 기본 사용자 이름으로 praefect (권장)를 사용할 것으로 가정합니다. 해당 명령은 암호인 <praefect_postgresql_password>와 확인을 요청할 것입니다. 이 명령에 의해 출력된 값을 다음 단계의 <praefect_postgresql_password_hash> 값으로 사용하십시오.
```
sudo gitlab-ctl pg-password-md5 praefect
```

/etc/gitlab/gitlab.rb를 편집하고 # START user configuration 섹션에 주석 처리된 값들을 변경하십시오:

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

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

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

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

# START user configuration
# 필수 정보 섹션에서 설명한대로 실제 값 설정
#
# 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의 데이터베이스에 제3자 PostgreSQL 솔루션이 권장됩니다.

PostgreSQL HA를 위한 많은 제3자 솔루션이 있습니다. Praefect와 호환되기 위해서는 선택한 솔루션이 다음 사항을 갖춰야 합니다:

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

참고: 제3자 설정을 사용하면 본 GitLab 데이터베이스와 같은 서버에 Praefect의 데이터베이스를 편리하게 함께 두는 것이 가능하며(단, Geo를 사용하는 경우 복제를 올바르게 처리하기 위해 별도의 데이터베이스 인스턴스가 필요합니다), Amazon Aurora는 14.4.0에서 기본적으로 활성화된 로드 밸런싱과 호환되지 않습니다. 더 많은 정보는 추천하는 클라우드 제공업체 및 서비스를 참조하십시오.

데이터베이스를 설정한 후 포스트 구성을 따르십시오.

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>';
```

PostgreSQL 서버에 다시 praefect 사용자로 연결합니다:

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

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

설정 구성 요소로 돌아가기

Praefect 구성

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

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

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

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

Gitaly 클러스터 노드들은 Praefect를 통해 가상 저장소를 통해 구성됩니다. 각 저장소에는 클러스터를 구성하는 각 Gitaly 노드의 세부정보가 포함됩니다. 또한 각 저장소에 이름이 지정되며, 이 이름은 설정의 여러 영역에서 사용됩니다. 이 가이드에서는 저장소의 이름을 default로 지정하며, 기존 환경을 Gitaly 클러스터를 사용하도록 업그레이드하려면 다른 이름을 사용해야 할 수 있습니다. 자세한 정보는 Praefect 설명서를 참조하세요.

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

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

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

Praefect 서버에 SSH로 접속합니다.
선택한 Linux 패키지를 다운로드하고 설치합니다. 페이지에서 _installation steps 1 and 2_만 따르십시오.

/etc/gitlab/gitlab.rb 파일을 편집하여 Praefect를 구성합니다:

참고: GitLab requires itdefault 항목을 virtual_storages에서 제거할 수 없습니다.

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

# 사용자 구성 시작
# 필수 정보 섹션에 설명된 대로 실제 값을 설정하세요
#

praefect['configuration'] = {
   # ...
   listen_addr: '0.0.0.0:2305',
   auth: {
     # ...
     #
     # Praefect 외부 토큰
     # 이것은 Praefect 클러스터와 같은 클러스터 외부에서 (예: GitLab Shell) 클러이언트가 Praefect 클러스터와 통신하기 위해 필요합니다
     token: '<praefect_external_token>',
   },
   # Praefect 데이터베이스 설정
   database: {
     # ...
     host: '10.6.0.141',
     port: 5432,
     # `no_proxy` 설정은 항상 캐싱을 위한 직접 연결이어야 합니다
     session_pooled: {
        # ...
        host: '10.6.0.141',
        port: 5432,
        dbname: 'praefect_production',
        user: 'praefect',
        password: '<praefect_postgresql_password>',
     },
   },
   # Praefect 가상 저장소 구성
   # 저장소 해시의 이름은 GitLab의 git_data_dirs 서버 ('praefect') 및 Gitaly 노드 ('gitaly-1')의 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'

## 콘설 서버 노드의 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는 읽기 작업에 대해 초당 최소 8,000개의 입/출력 작업(IOPS), 쓰기 작업에 대해 2,000개의 IOPS를 갖춰야 합니다. 환경을 클라우드 제공업체에서 실행하는 경우, IOPS를 올바르게 구성하는 방법에 대해서는 해당 문서를 참조하십시오.

Gitaly 서버는 기본적으로 네트워크 트래픽 암호화가 되어있지 않기 때문에 공개 인터넷에 노출시키면 안 됩니다. 방화벽의 사용이 강력히 권장되며, 또 다른 옵션은 TLS 사용입니다.

Gitaly를 구성할 때 다음 사항을 주의해야 합니다:

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

다음 IP 주소를 예로 사용합니다:

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

각 노드에서:

선택한 리눅스 패키지의 다운로드 및 설치를 수행합니다. 해당 페이지에서 설치 단계 1 및 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

# git push가 실패하지 않도록 gitlab-shell API 콜백 URL을 구성합니다. 이는 'front door' GitLab URL이나 내부 로드 밸런서가 될 수 있습니다.
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'

# Gitaly
gitaly['enable'] = true

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

# 사용자 구성 시작
# 필수 정보 섹션에서 설명된 대로 실제 값을 설정하십시오
##
## Consul 서버 노드의 IP 주소
## FQDN(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'

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 캐시
      # 성능 향상을 위해 활성화하는 것이 좋지만 디스크 입출력을 현저히 증가시킬 수 있습니다.
      # 자세한 내용은 https://docs.gitlab.com/ee/administration/gitaly/configure_gitaly.html#pack-objects-cache를 참조하십시오.
      enabled: true,
   },
}

#
# 사용자 구성 완료

각 해당 서버의 /etc/gitlab/gitlab.rb에 다음을 추가합니다:

Gitaly 노드 1에서:

gitaly['configuration'] = {
   # ...
   storage: [
      {
         name: 'gitaly-1',
         path: '/var/opt/gitlab/git-data',
      },
   ],
}

Gitaly 노드 2에서:

gitaly['configuration'] = {
   # ...
   storage: [
      {
         name: 'gitaly-2',
         path: '/var/opt/gitlab/git-data',
      },
   ],
}

Gitaly 노드 3에서:

gitaly['configuration'] = {
   # ...
   storage: [
      {
         name: 'gitaly-3',
         path: '/var/opt/gitlab/git-data',
      },
   ],
}

첫 번째 리눅스 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하고, 해당 서버의 동일한 이름의 파일을 추가하거나 교체합니다. 이것이 구성 중인 첫 번째 리눅스 패키지 노드인 경우, 이 단계는 생략할 수 있습니다.
파일을 저장하고, GitLab 재구성을 진행합니다.

Gitaly Cluster TLS 지원

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

GitLab 구성 파일의 해당 저장소 항목의 gitaly_address에 tls:// URL 스키마를 사용해야 합니다.
이 기능은 자동으로 제공되지 않으므로 각 Praefect 서버에 해당하는 인증서를 직접 가져와야 합니다.

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

다음 사항을 고려하세요:

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

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

Praefect 서버용 인증서를 생성하세요.

Praefect 서버에서 /etc/gitlab/ssl 디렉토리를 생성하고 키와 인증서를 해당 디렉토리로 복사하세요.

sudo mkdir -p /etc/gitlab/ssl
sudo chmod 755 /etc/gitlab/ssl
sudo cp key.pem cert.pem /etc/gitlab/ssl/
sudo chmod 644 key.pem cert.pem

/etc/gitlab/gitlab.rb를 편집하고 다음을 추가하세요.

praefect['configuration'] = {
   # ...
   tls_listen_addr: '0.0.0.0:3305',
   tls: {
      # ...
      certificate_path: '/etc/gitlab/ssl/cert.pem',
      key_path: '/etc/gitlab/ssl/key.pem',
   },
}

파일을 저장하고 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 작업 처리가 긴 대기열로 인해 느리다고 판단될 경우 이에 따라 조정할 수 있습니다. 자세한 내용은 스케일링 문서를 참조하세요.

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로 로그인하세요.
선택한 Linux 패키지를 다운로드하고 설치하세요. 페이지에서 _설치 단계 1_과 _설치 단계 2_만 따르세요.

/etc/gitlab/gitlab.rb를 생성하거나 편집하고 다음 구성을 사용하세요.

# https://docs.gitlab.com/omnibus/roles/#sidekiq-roles
roles(["sidekiq_role"])

# 외부 URL
## 이는 외부 로드 밸런서의 URL과 일치해야합니다.
external_url 'https://gitlab.example.com'

# Redis
## Redis 연결 세부 정보
## 캐시 데이터를 호스팅할 첫 번째 클러스터
gitlab_rails['redis_cache_instance'] = 'redis://:<REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER>@gitlab-redis-cache'

gitlab_rails['redis_cache_sentinels'] = [
  {host: '10.6.0.51', port: 26379},
  {host: '10.6.0.52', port: 26379},
  {host: '10.6.0.53', port: 26379},
]

## 다른 모든 지속 데이터를 호스팅하는 두 번째 클러스터
redis['master_name'] = 'gitlab-redis-persistent'
redis['master_password'] = '<REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER>'

gitlab_rails['redis_sentinels'] = [
  {host: '10.6.0.61', port: 26379},
  {host: '10.6.0.62', port: 26379},
  {host: '10.6.0.63', port: 26379},
]

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

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

## 자동 업그레이드 중에 데이터베이스 마이그레이션을 자동으로 실행하지 못하게합니다
gitlab_rails['auto_migrate'] = false

# Sidekiq
sidekiq['enable'] = true
sidekiq['listen_address'] = "0.0.0.0"

## 사용 가능한 CPU 수에 따라 Sidekiq 대기열 프로세스 수를 설정합니다
sidekiq['queue_groups'] = ['*'] * 4

# Monitoring
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에서 객체 스토리지를 구성하는 예시입니다
# 이 구성은 필요한대로 선택한 객체 스토리지 제공자로 교체합니다
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 재구성을 처리하도록 자세한 내용은 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

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

원하는 Linux 패키지를 다운로드 및 설치하십시오. 페이지의 설치 단계 1 및 2만을 따르십시오.

/etc/gitlab/gitlab.rb 파일을 편집하고 다음 구성을 사용하십시오. 노드 간에 링크의 균일성을 유지하기 위해, 응용 프로그램 서버의 external_url은 사용자가 GitLab에 액세스하는 데 사용할 외부 URL을 가리키도록 설정되어야 합니다. 이것은 외부 로드 밸런서의 URL이 될 것이며, 이로써 트래픽이 GitLab 애플리케이션 서버로 라우팅될 것입니다.

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
nginx['enable'] = true
sidekiq['enable'] = false

## PostgreSQL 연결 세부 정보
# 애플리케이션 노드에서 PostgreSQL 비활성화
postgresql['enable'] = false
gitlab_rails['db_host'] = '10.6.0.20' # 내부 로드 밸런서 IP
gitlab_rails['db_port'] = 6432
gitlab_rails['db_password'] = '<postgresql_user_password>'
gitlab_rails['db_load_balancing'] = { 'hosts' => ['10.6.0.21', '10.6.0.22', '10.6.0.23'] } # PostgreSQL IPs

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

## Redis 연결 세부 정보
## 캐시 데이터를 호스팅할 첫 번째 클러스터
gitlab_rails['redis_cache_instance'] = 'redis://:<REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER>@gitlab-redis-cache'

gitlab_rails['redis_cache_sentinels'] = [
  {host: '10.6.0.51', port: 26379},
  {host: '10.6.0.52', port: 26379},
  {host: '10.6.0.53', port: 26379},
]

## 다른 모든 지속적인 데이터를 호스팅하는 두 번째 클러스터
redis['master_name'] = 'gitlab-redis-persistent'
redis['master_password'] = '<REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER>'

gitlab_rails['redis_sentinels'] = [
  {host: '10.6.0.61', port: 26379},
  {host: '10.6.0.62', port: 26379},
  {host: '10.6.0.63', port: 26379},
]

# 모니터링을 위해 수신 대기할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
gitlab_workhorse['prometheus_listen_addr'] = '0.0.0.0:9229'
puma['listen'] = '0.0.0.0'

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

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

TLS 지원을 사용하는 Gitaly을 사용하는 경우, git_data_dirs 항목이 tcp 대신 tls로 구성되어 있는지 확인하십시오:

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

인증서를 /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을 다시 구성하십시오.
증분적 로깅을 활성화하십시오.
노드가 Gitaly에 연결할 수 있는지 확인하십시오:
```
sudo gitlab-rake gitlab:gitaly:check
```
그런 다음 요청을 볼 로그를 확인하려면:
```
sudo gitlab-ctl tail gitaly
```
옵션으로, Gitaly 서버에서 Gitaly가 내부 API로 콜백을 수행할 수 있는지 확인하십시오:
- GitLab 15.3 이상의 경우, sudo /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml을 실행하십시오.
- GitLab 15.2 이하의 경우, sudo /opt/gitlab/embedded/bin/gitaly-hooks check /var/opt/gitlab/gitaly/config.toml을 실행하십시오.

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

GitLab Rails 포스트 구성

설치 및 업데이트 중에 데이터베이스 마이그레이션을 실행할 애플리케이션 노드를 지정합니다. GitLab 데이터베이스를 초기화하고 모든 마이그레이션이 실행되었는지 확인하세요:
```
sudo gitlab-rake gitlab:db:configure
```
이 작업은 기본 데이터베이스에 연결하도록 Rails 노드를 구성해야 합니다. PgBouncer를 우회합니다. 마이그레이션이 완료된 후, 노드를 다시 PgBouncer로 전환해야 합니다.
데이터베이스에서 인증된 SSH 키를 빠르게 조회하도록 설정하세요. 자세한 내용은 여기를 참조하세요.

설정 구성 요소로 돌아가기

프로메테우스 구성

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

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

10.6.0.151: 프로메테우스

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

모니터링 노드에 SSH로 접속하세요.
원하는 Linux 패키지를 다운로드하고 설치하세요. 페이지의 설치 단계 1 및 2만 따르도록 해야 합니다.

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

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

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

# 프로메테우스
prometheus['listen_address'] = '0.0.0.0:9090'
prometheus['monitor_kubernetes'] = false

# 프로메테우스를 위한 서비스 디스커버리 활성화
consul['monitoring_service_discovery'] =  true
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}

# 프로메테우스에 대한 서비스 스크레이핑 구성
prometheus['scrape_configs'] = [
   {
      'job_name': 'pgbouncer',
      'static_configs' => [
         'targets' => [
         "10.6.0.31:9188",
         "10.6.0.32:9188",
         "10.6.0.33:9188",
         ],
      ],
   },
   {
      'job_name': 'praefect',
      'static_configs' => [
         'targets' => [
         "10.6.0.131:9652",
         "10.6.0.132:9652",
         "10.6.0.133:9652",
         ],
      ],
   },
]

nginx['enable'] = false

파일을 저장하고 GitLab을 다시 구성하세요.

설정 구성 요소로 돌아가기

객체 저장소 구성

GitLab은 여러 유형의 데이터를 보유하기 위해 객체 저장소 서비스를 사용할 수 있습니다. 대규모 설정에서 데이터 객체에 대해 NFS 대신 객체 저장소를 사용하는 것이 권장됩니다. 일반적으로 객체 저장소는 훨씬 더 효율적이고 신뢰성이 있으며 확장 가능하기 때문입니다. 자세한 내용은 권장되는 클라우드 제공업체 및 서비스를 참조하세요.

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

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

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

참고: GitLab 14.x 및 이전 버전에서 저장소별 형식을 사용할 때, 직접 업로드 모드를 활성화해야 합니다. 14.9에서 폐지된 이전 백그라운드 업로드 모드는 NFS와 같은 공유 저장소가 필요합니다.

각 데이터 유형에 대해 별도의 버킷을 사용하는 것이 GitLab에서 권장하는 방법입니다. 이를 통해 GitLab이 저장하는 다양한 유형의 데이터에 충돌이 없도록 보장할 수 있습니다. 앞으로 단일 버킷 사용을 가능하게 할 계획이 있습니다.

설정 구성 요소로 돌아가기

증분 로깅 활성화

기본적으로 GitLab Runner는 Linux 패키지를 사용하는 경우에도 일시적으로 디스크에 있는 /var/opt/gitlab/gitlab-ci/builds에 작업 로그를 조각으로 반환합니다. 기본 구성에서는 이 디렉토리를 NFS를 통해 GitLab Rails와 Sidekiq 노드에 공유해야 합니다.

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

고급 검색 구성

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

Elasticsearch 클러스터 디자인 및 요구 사항은 특정 데이터에 따라 다릅니다. 권장되는 최적의 클러스터 구성 방법에 대한 정보는 인스턴스와 함께 Elasticsearch 클러스터를 설정하는 방법에 대한 지침에서 확인할 수 있습니다.

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

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

Kubernetes에서 클라우드 네이티브 GitLab 구성 요소 중 일부를 GitLab Helm 차트를 사용하여 실행할 수 있습니다. 이 설정에서는 Kubernetes 클러스터에서 GitLab Rails에 해당하는 구성 요소인 Webservice를 실행할 수 있습니다. 또한 Sidekiq 노드에 해당하는 구성 요소도 Sidekiq라고 불리는 Kubernetes 클러스터에서 실행할 수 있습니다. 추가로 NGINX, Toolbox, Migrations, Prometheus, Grafana과 같은 지원 서비스도 지원됩니다.

하이브리드 설치는 클라우드 네이티브 및 전통적인 컴퓨팅 배포의 이점을 모두 활용합니다. 이를 통해 무상태 구성 요소는 클라우드 네이티브 워크로드 관리 이점을 얻을 수 있으며, 상태를 유지하는 구성 요소는 Linux 패키지 설치를 통해 컴퓨팅 VM에서 배포하여 지속성을 높일 수 있습니다.

Kubernetes와 백엔드 구성 요소 사이에서 GitLab 보안을 위해 동기화해야 하는 GitLab 비밀키에 대한 안내와 함께 설정 지침에 대한 정보는 Helm 차트 고급 구성 문서에서 확인할 수 있습니다.

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

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

클러스터 토폴로지

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

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

서비스 노드 그룹	노드	구성	GCP	AWS	할당 가능한 최소 CPU 및 메모리
Webservice	7	32 vCPU, 28.8 GB 메모리	`n1-highcpu-32`	`c5.9xlarge`	223 vCPU, 206.5 GB 메모리
Sidekiq	4	4 vCPU, 15 GB 메모리	`n1-standard-4`	`m5.xlarge`	15.5 vCPU, 50 GB 메모리
지원 서비스	2	4 vCPU, 15 GB 메모리	`n1-standard-4`	`m5.xlarge`	7.75 vCPU, 25 GB 메모리

이 설정에서 우리는 Google Kubernetes Engine (GKE) 및 Amazon Elastic Kubernetes Service (EKS)를 권장하고 있으며 정기적으로 테스트를 수행합니다.
노드 구성은 전체 성능 테스트 중에는 포드 vCPU / 메모리 비율을 보장하고 확장을 피하기 위해 강제로 표시됩니다.
- 프로덕션 배포에서는 특정 노드에 포드를 할당할 필요가 없습니다. 세 가용성 영역의 세 가용성 영역 당 최소 세 개의 노드가 강력하게 권장되며, 이는 강건한 클라우드 아키텍처 모범 사례에 부합합니다.

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

서비스	노드	구성	GCP	AWS
Consul¹	3	2 vCPU, 1.8 GB 메모리	`n1-highcpu-2`	`c5.large`
PostgreSQL¹	3	16 vCPU, 60 GB 메모리	`n1-standard-16`	`m5.4xlarge`
PgBouncer¹	3	2 vCPU, 1.8 GB 메모리	`n1-highcpu-2`	`c5.large`
내부 로드 밸런서³	1	8 vCPU, 7.2 GB 메모리	`n1-highcpu-8`	`c5.2xlarge`
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	32 vCPU, 120 GB 메모리⁶	`n1-standard-32`	`m5.8xlarge`
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`
객체 스토리지⁴	-	-	-	-

각주:

신용할 만한 타사 외부 PaaS PostgreSQL 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 정보는 Provide your own PostgreSQL instance를 참조하세요.
신용할 만한 타사 외부 PaaS Redis 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 정보는 Provide your own Redis instances를 참조하세요.
- Redis는 주로 단일 스레드이며 CPU 코어 증가로부터 크게 이득을 보지 못합니다. 이러한 규모의 아키텍처에서는 최적의 성능을 위해 별도의 캐시 및 지속적인 인스턴스가 필요합니다.
신용할 만한 타사 로드 밸런싱 서비스 (LB PaaS)에서 선택적으로 실행할 수 있습니다. 자세한 정보는 Recommended cloud providers and services를 참조하세요.
신용할 만한 클라우드 제공업체 또는 Self Managed 솔루션에서 실행할 수 있습니다. 자세한 정보는 Configure the object storage를 참조하세요.
Gitaly 클러스터는 장애 허용성의 이점을 제공하지만 추가적인 설치 및 관리의 복잡성이 동반됩니다. Before deploying Gitaly Cluster에서 Gitaly 클러스터를 배포하기 전에 기술적인 제한과 고려사항을 확인하세요. 샤드 Gitaly가 필요한 경우, Gitaly에 대해 위에 나열된 동일한 사양을 사용하세요.
Gitaly 사양은 잘 유지된 건강 상태의 사용 패턴 및 리포지토리 크기의 고 백분위에 기반합니다. 그러나 대형 모노 리포 (몇 기가바이트 이상) 또는 추가 작업량이 있는 경우 Git과 Gitaly 성능에 유의한 영향을 미칠 수 있으며 추가 조정이 필요할 수 있습니다.

참고: 인스턴스를 구성하는 PaaS 솔루션의 경우, 신뢰할 수 있는 클라우드 아키텍처 관행과 일치하기 위해 서로 다른 세 가용성 영역의 세 개 노드를 구현하는 것이 강력히 권장됩니다.

리소스 사용량 설정

다음 공식은 리소스 제한 내에서 배포할 수 있는 파드 수를 계산하는 데 도움이 됩니다. 25k reference architecture example values file은 계산된 구성을 Helm 차트에 적용하는 방법을 문서화합니다.

웹서비스

웹서비스 파드는 일반적으로 1 CPU 및 1.25 GB의 메모리 _퍼 워커_가 필요합니다. 각 웹서비스 파드는 기본적으로 생성되는 네 개의 워커 프로세스 및 각 파드에 다른 작은 프로세스가 실행됨으로써 대략적으로 4 CPU 및 5 GB의 메모리를 소비합니다. 25000명의 사용자에 대해 Puma 워커 수를 대략 140 정도로 권장합니다. 제공된 권장 사항에 따르면 이는 각각 4개의 워커가 있는 35개의 웹서비스 파드를 배포할 수 있도록 합니다. 추가 웹서비스 파드마다 1 CPU당 1.25GB의 메모리의 비율을 사용하여 사용 가능한 리소스를 확장하세요.

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

Sidekiq

일반적으로 Sidekiq 파드는 0.9 CPU 및 2GB의 메모리가 필요합니다.

제공된 시작 지점에 따르면 최대 14개의 Sidekiq 파드를 배포할 수 있습니다. 추가 파드마다 0.9 CPU당 2GB의 메모리 비율을 사용하여 사용 가능한 리소스를 확장하세요.

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

지원

지원 노드 풀은 웹서비스 및 Sidekiq 풀에 있을 필요가 없는 모든 지원 배포를 수용하는 것을 목표로 합니다.

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

모니터링과 같은 추가 배포를 하려면 가능한 경우 이러한 배포를 이 풀에 배포하는 것이 좋으며, 웹서비스나 Sidekiq 풀이 아닌 곳에 배포하는 것이 좋습니다. 지원 풀은 여러 추가 배포를 수용하도록 명시적으로 설계되었기 때문입니다. 그러나 제공된 풀에 배포가 맞지 않는 경우 노드 풀을 추가로 확장할 수 있습니다.

구성 구성요소로 돌아가기

참조 아키텍처: 최대 25,000명의 사용자까지

Consul 구성

PostgreSQL 구성

본인의 PostgreSQL 인스턴스 제공

독립적인 Linux 패키지를 사용한 PostgreSQL

PostgreSQL 노드

PostgreSQL 포스트 구성

PgBouncer 구성

Redis 구성

고유한 Redis 인스턴스 제공

Redis 캐시 클러스터 구성

주 서버 Redis 캐시 노드 구성

레디스 캐시 노드의 복제본 구성

Redis 지속 클러스터 구성

주(Primary) Redis 지속 노드 구성

복제 레디스 지속 노드 구성

Gitaly 클러스터 구성

Praefect PostgreSQL 구성

Praefect 비-HA PostgreSQL 스탠드얼론(Linux 패키지 사용)

Praefect HA PostgreSQL 제3자 솔루션

Praefect PostgreSQL 포스트 구성

Praefect 구성

Gitaly 구성

Gitaly Cluster TLS 지원

Sidekiq 구성

GitLab Rails 구성

GitLab Rails 포스트 구성

프로메테우스 구성

객체 저장소 구성

증분 로깅 활성화

고급 검색 구성

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

클러스터 토폴로지

리소스 사용량 설정

웹서비스

Sidekiq

지원

도움말

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

도움받기