요구 사항
테스트 방법
컴포넌트 설정
외부 로드 밸런서 구성
PostgreSQL 구성
- 나만의 PostgreSQL 인스턴스 제공
- Linux 패키지를 사용한 독립형 PostgreSQL
Redis 구성
- 자체 Redis 인스턴스 제공
- Linux 패키지를 사용한 독립형 Redis
Gitaly 구성
- Gitaly TLS 지원
Sidekiq 구성
GitLab Rails 구성
- GitLab Rails 후-구성
Prometheus 구성
객체 리포지터리 구성
- 증분 로깅 활성화
고급 검색 구성
Helm 차트를 사용한 클라우드 네이티브 하이브리드 참조 아키텍처 (대안)

참조 아키텍처: 초당 최대 40개의 RPS 또는 2,000명 사용자까지 지원

Tier: Free, Premium, Ultimate Offering: Self-Managed

이 페이지는 실제 데이터를 기반으로 초당 최대 40개의 요청(RPS) 및 최대 2,000명의 사용자(매뉴얼 및 자동 모두 포함)에 대응하는 GitLab 참조 아키텍처에 대해 설명합니다.

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

대상 부하: API: 40 RPS, 웹: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS
고가용성: 아니요. 고가용 환경을 원하시면 수정된 3K 또는 60 RPS 참조 아키텍처를 따르십시오.
예상 비용: 비용 표 보기
클라우드 네이티브 하이브리드: 예
사용할 참조 아키텍처가 확실하지 않으신가요? 더 많은 정보를 위해 이 안내서로 이동.

서비스	노드 수	구성	GCP	AWS	Azure
외부 로드 밸런서³	1	4 vCPU, 3.6 GB 메모리	`n1-highcpu-4`	`c5n.xlarge`	`F4s v2`
PostgreSQL¹	1	2 vCPU, 7.5 GB 메모리	`n1-standard-2`	`m5.large`	`D2s v3`
Redis²	1	1 vCPU, 3.75 GB 메모리	`n1-standard-1`	`m5.large`	`D2s v3`
Gitaly⁵	1	4 vCPU, 15 GB 메모리⁵	`n1-standard-4`	`m5.xlarge`	`D4s v3`
Sidekiq⁰⁶	1	4 vCPU, 15 GB 메모리	`n1-standard-4`	`m5.xlarge`	`D4s v3`
GitLab Rails⁰⁶	2	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`
객체 스토리지⁴	-	-	-	-	-

각주: 1. 명성있는 제3자 외부 PaaS PostgreSQL 솔루션에서 선택 사항으로 실행될 수 있습니다. 자세한 내용은 단독 PostgreSQL 인스턴스 제공 및 권장 클라우드 제공업체 및 서비스를 참조하십시오. 2. 명성있는 제3자 외부 PaaS Redis 솔루션에서 선택 사항으로 실행될 수 있습니다. 자세한 내용은 단독 Redis 인스턴스 제공 및 권장 클라우드 제공업체 및 서비스를 참조하십시오. 3. 명성있는 제3자 로드 밸런서 또는 서비스(LB PaaS)와 함께 실행하는 것이 권장됩니다. 또한 크기 조정은 선택된 로드 밸런서 및 네트워크 대역폭과 같은 추가 요소에 따라 달라집니다. 자세한 내용은 로드 밸런서를 참조하십시오. 4. 신뢰할 수 있는 클라우드 제공업체 또는 Self-Managed형 솔루션에서 실행하는 것이 좋습니다. 자세한 내용은 객체 스토리지 구성를 참조하십시오. 5. Gitaly 사양은 보통 사이즈의 리포지터리를 기준으로 합니다. 그러나 큰 모노리포(수 기가바이트 이상)를 사용하는 경우 Git 및 Gitaly 성능에 상당한 영향을 미칠 수 있으며 사양을 늘리는 것이 필요할 수 있습니다. 자세한 내용은 큰 모노리포를 참조하십시오. 6. 해당 컴포넌트는 상태 데이터를 저장하지 않기 때문에 Auto Scaling 그룹(ASG)에 배치할 수 있습니다. 그러나 클라우드 네이티브 하이브리드 설정은 특히 마이그레이션 및 Mailroom과 같은 일부 컴포넌트의 경우 Kubernates에서 더 잘 처리되므로 일반적으로 선호됩니다.

모든 PaaS 솔루션에서 인스턴스 구성을 구성하는 경우 원하는 경우 강건성을 위해 여러 가용 영역에 배포하는 것이 좋습니다.

요구 사항

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

테스트 방법

2k 아키텍처는 대부분의 워크플로를 커버하도록 설계되어 있으며 정기적으로 테스트 플랫폼 팀에 의해 관점 부하량 목표별로 스모크 및 성능 테스트가 진행됩니다.

API: 40 RPS
웹: 4 RPS
Git (Pull): 4 RPS
Git (Push): 1 RPS

위의 목표는 사용자 수에 대응하는 총체적 환경 부하에 따라 실제 고객 데이터를 기반으로 선택되었습니다.

위의 목표에 대한 정기적으로 더 높은 부하량, 큰 모노리포 또는 주목할만한 추가 작업 부하가 소요된다는 메트릭을 보유하고 있는 경우, 이는 환경 및 추가 조정이 필요할 수 있으므로 이에 대해 문서 및 고객 성공 관리자나 지원 팀에 문의하시기를 강력히 권장드립니다.

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

테스트에 사용된 로드 밸런서는 리눅스 패키지 환경의 HAProxy 또는 등가 클라우드 제공자 서비스인 NGINX Ingress를 통해 진행되었습니다. 이러한 선택은 특정 요구 사항을 나타내는 것은 아니며 대부분의 신뢰할 수 있는 로드 밸런서가 작동할 것으로 예상합니다.

컴포넌트 설정

GitLab 및 해당 컴포넌트를 설정하여 최대 40 RPS 또는 2,000명의 사용자를 수용하려면 다음을 수행하세요.

외부 로드 밸런싱 노드 구성
- GitLab 애플리케이션 서비스 노드의 로드 밸런싱을 처리하는 데 사용됩니다.
PostgreSQL 구성
- GitLab의 데이터베이스입니다.
Redis 구성
Gitaly 구성
- Git 리포지터리에 대한 액세스를 제공합니다.
메인 GitLab Rails 애플리케이션 구성
- Puma, Workhorse, GitLab Shell을 실행하고 UI, API, Git(HTTP/SSH 포함)를 제공합니다.
Prometheus 구성
- GitLab 환경을 모니터링합니다.
객체 리포지터리 구성
- 공유 데이터 객체에 사용됩니다.
고급 검색 구성 (옵션)
- 전체 GitLab 인스턴스에 대해 빠르고 고급 코드 검색을 위해 사용됩니다.

외부 로드 밸런서 구성

다중 노드 GitLab 구성에서는 외부 로드 밸런서가 필요합니다. 이로써 트래픽이 애플리케이션 서버로 라우팅됩니다.

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

준비 상태 확인

외부 로드 밸런서는 모니터링 엔드포인트가 포함된 작동 중인 서비스로의 라우팅만 처리하도록 설정해야 합니다. 준비 상태 확인에 대한 추가 구성이 필요하며, 그렇지 않을 경우 외부 로드 밸런서가 연결할 수 없습니다.

포트

사용해야 하는 기본 포트는 아래 표에 표시된 대로입니다.

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

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

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

로드 밸런서 포트	백엔드 포트	프로토콜
80	가변 (1)	HTTP
443	가변 (1)	TCP (2)

(1): GitLab Pages의 백엔드 포트는 gitlab_pages['external_http'] 및 gitlab_pages['external_https'] 설정에 따라 다릅니다. 자세한 내용은 GitLab Pages 문서를 참조하세요.
(2): GitLab Pages의 포트 443은 항상 TCP 프로토콜을 사용해야 합니다. 사용자는 사용자 지정 SSL로 사용자 정의 도메인을 구성할 수 있습니다. 이는 SSL을 로드 밸런서에서 해지하는 경우 불가능합니다.

대체 SSH 포트

일부 조직은 SSH 포트 22를 열지 않는 정책을 가지고 있습니다. 이 경우 사용자가 SSH를 포트 443에서 사용할 수 있도록 대체 SSH 호스트 이름을 구성하는 것이 도움이 될 수 있습니다. 대체 SSH 호스트 이름을 설정하려면 기타 GitLab HTTP 구성과는 다른 새 가상 IP 주소가 필요합니다.

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

로드 밸런서 포트	백엔드 포트	프로토콜
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에 대한 구성은 추가할 필요가 없습니다. 그러나 GitLab에 SSL 인증서를 구성해야 합니다. SSL 인증서 관리 및 NGINX 설정에 대한 자세한 내용은 HTTPS 문서를 참조하세요.

컴포넌트 설정으로 돌아가기

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 애플리케이션 구성에서 다룹니다.

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

PostgreSQL 서버에 SSH로 로그인합니다.
선택한 Linux 패키지를 다운로드하고 설치합니다. 페이지에서 설치 단계 1과 2만 따를 것을 권장합니다.
PostgreSQL용 암호 해시를 생성합니다. 이는 기본 사용자 이름인 gitlab을 사용할 것을 가정합니다(권장사항). 명령은 암호와 확인을 요청할 것입니다. 이 명령의 출력 값을 다음 단계의 POSTGRESQL_PASSWORD_HASH 값으로 사용합니다.
```
sudo gitlab-ctl pg-password-md5 gitlab
```

/etc/gitlab/gitlab.rb 파일을 편집하여 아래 내용을 추가하고, 플레이스홀더 값을 적절히 업데이트합니다.

POSTGRESQL_PASSWORD_HASH - 이전 단계에서 출력된 값
APPLICATION_SERVER_IP_BLOCKS - 데이터베이스에 연결할 GitLab Rails 및 Sidekiq 서버의 IP 서브넷 또는 IP 주소의 공백으로 구분된 디렉터리입니다. 예: %w(123.123.123.123/32 123.123.123.234/32)

# PostgreSQL 관련 컴포넌트만 사용하지록 설정
roles(['postgres_role'])
   
# 모니터링에 사용되는 내부 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
postgres_exporter['listen_address'] = '0.0.0.0:9187'
postgres_exporter['dbname'] = 'gitlabhq_production'
postgres_exporter['password'] = 'POSTGRESQL_PASSWORD_HASH'
   
# PostgreSQL 주소 및 포트 설정
postgresql['listen_address'] = '0.0.0.0'
postgresql['port'] = 5432
   
# 생성된 md5 값으로 POSTGRESQL_PASSWORD_HASH 교체
postgresql['sql_user_password'] = 'POSTGRESQL_PASSWORD_HASH'
   
# 애플리케이션 노드의 CIDR 주소로 APPLICATION_SERVER_IP_BLOCK 교체
postgresql['trust_auth_cidr_addresses'] = %w(127.0.0.1/32 APPLICATION_SERVER_IP_BLOCK)
   
# 업그레이드 시 자동으로 데이터베이스 마이그레이션 방지
gitlab_rails['auto_migrate'] = false

이전에 구성한 첫 번째 Linux 패키지 노드의 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 동일한 이름의 파일을 추가하거나 교체합니다. 이것이 첫 번째 구성하는 Linux 패키지라면, 이 단계는 생략할 수 있습니다.
변경 사항이 적용되려면 GitLab을 다시 구성합니다.
PostgreSQL 노드의 IP 주소 또는 호스트 이름, 포트, 암호를 메모합니다. 이 정보는 나중에 GitLab 애플리케이션 서버 구성 시 필요합니다.

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

Redis 구성

이 섹션에서는 GitLab에서 사용할 외부 Redis 인스턴스를 구성하는 방법에 대해 안내합니다.

Redis는 주로 단일 스레드로 실행되며 CPU 코어 증가로 큰 이점을 얻지 못합니다. 더 많은 정보는 스케일링 문서를 참조하십시오.

자체 Redis 인스턴스 제공

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

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

더 많은 정보는 권장 클라우드 제공업체와 서비스를 참조하십시오.

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

Linux 패키지를 사용하여 독립형 Redis 서버를 구성할 수 있습니다. 아래 단계는 Linux 패키지로 Redis 서버를 구성하는 데 필요한 최소한의 단계입니다.

Redis 서버에 SSH로 로그인합니다.
선택한 Linux 패키지를 다운로드하고 설치합니다. 페이지에서 설치 단계 1과 2만 따를 것을 권장합니다.

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

## Redis 사용 설정
roles(["redis_master_role"])
   
redis['bind'] = '0.0.0.0'
redis['port'] = 6379
redis['password'] = 'SECRET_PASSWORD_HERE'
   
gitlab_rails['enable'] = false
   
# 모니터링에 사용되는 내부 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'
redis_exporter['flags'] = {
      'redis.addr' => 'redis://0.0.0.0:6379',
      'redis.password' => 'SECRET_PASSWORD_HERE',
}

이전에 구성한 첫 번째 Linux 패키지 노드의 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 동일한 이름의 파일을 추가하거나 교체합니다. 이것이 첫 번째 구성하는 Linux 패키지라면, 이 단계는 생략할 수 있습니다.
변경 사항이 적용되려면 GitLab을 다시 구성합니다.
Redis 노드의 IP 주소 또는 호스트 이름, 포트 및 Redis 암호를 메모합니다. 이 정보는 나중에 GitLab 애플리케이션 서버 구성시 필요합니다.

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

Gitaly 구성

Gitaly 서버 노드 요구 사항은 데이터 크기에 따라 달라지며 특히 프로젝트 수 및 해당 프로젝트 크기에 따라 달라집니다.

Gitaly 사양은 사용 패턴 및 리포지터리 크기의 상위 백분위수에 기반합니다. 그러나 대형 모노 리포(여러 기가바이트 이상) 또는 추가 워크로드가 있다면, 환경의 성능에 중대한 영향을 미칠 수 있습니다. 이 경우 연관 문서를 참조하거나 고객 성공 관리자나 지원 팀에게 조언을 구하는 것이 강력히 권장됩니다.

Gitaly의 중요한 입력 및 출력 요구 사항 때문에 모든 Gitaly 노드가 SSD(고성능 디스크)를 사용하는 것이 좋습니다. 이 SSD는 읽기 작업에 대해 최소 8,000 IOPS(초당 입출력)의 처리량을 가져야 하며, 쓰기 작업에 대해서는 2,000 IOPS가 필요합니다. 환경을 클라우드 제공업체에서 실행 중이라면, 올바른 IOPS 구성 방법에 대해 제공업체 문서를 참조하십시오.

다음 사항을 반드시 확인하십시오:

GitLab 애플리케이션은 리포지터리 스토리지 경로로 분할됩니다.
Gitaly 서버는 하나 이상의 리포지터리 경로를 호스팅할 수 있습니다.
GitLab 서버는 하나 이상의 Gitaly 서버 노드를 사용할 수 있습니다.
Gitaly 주소는 모든 Gitaly 클라이언트에서 올바르게 해석되도록 명시되어야 합니다.
Gitaly 서버는 기본적으로 암호화되지 않으므로 공개 인터넷에 노출되어서는 안됩니다. 방화벽의 사용을 강력히 권장합니다. 다른 옵션으로는 TLS 사용이 있습니다.

Gitaly 문서 전반에서 언급된 토큰은 관리자가 선택하는 임의의 암호입니다. 이 토큰은 GitLab API용 또는 유사한 웹 API 토큰과는 무관합니다.

아래 절차에서는 gitaly1.internal이라는 단일 Gitaly 서버에 gitalysecret라는 시크릿 토큰을 구성하는 방법에 대해 설명합니다. GitLab 설치에서 default 및 storage1이라는 두 개의 리포지터리 스토리지가 있는 것으로 가정합니다.

Gitaly 서버를 구성하려면, Gitaly를 사용할 서버 노드에서 다음을 실행합니다.

원하는 Linux 패키지로 선택한 Linux 패키지를 다운로드하고 설치합니다. 페이지에서 _설치 단계 1과 2_를 따르며 EXTERNAL_URL 값을 제공해서는 안 됩니다.

Gitaly 서버 노드의 /etc/gitlab/gitlab.rb 파일을 편집하여 리포지터리 경로를 구성하고, 네트워크 수신기를 활성화하고, 토큰을 구성합니다:

gitaly[‘configuration’][:storage]에서 default 항목을 제거할 수 없습니다.

# 불필요한 서비스가 Gitaly 서버에서 실행되지 않도록 설정
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
gitlab_exporter['enable'] = false
gitlab_kas['enable'] = false
   
# 업그레이드 시 자동으로 데이터베이스 마이그레이션 방지
gitlab_rails['auto_migrate'] = false
   
# Gitlab Shell API 콜백 URL을 구성합니다. 이 작업을 하지 않으면 `git push`가 실패합니다. 이것은 '프론트도어' GitLab URL이거나 내부 로드 밸런서일 수 있습니다.
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
   
# Gitaly
gitaly['enable'] = true
   
# 시크릿 토큰은 Gitaly에서 GitLab 내부 API로의 인증 콜백에 사용됩니다.
# 이것은 GitLab Rails 애플리케이션 설정 값과 일치해야 합니다.
gitlab_shell['secret_token'] = 'shellsecret'
   
# 모니터링에 사용되는 내부 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
   
gitaly['configuration'] = {
   # ...
   #
   # Gitaly가 모든 네트워크 인터페이스에서 연결을 수락하도록 설정합니다. 이 주소/포트에 대한 액세스를 제한하기 위해서는 방화벽을 사용해야 합니다.
   # 단일 TLS 연결을 지원하려면 다음 줄을 주석 처리하려면 다음 줄을 주석 처리하십시오
   listen_addr: '0.0.0.0:8075',
   prometheus_listen_addr: '0.0.0.0:9236',
   # Gitaly 인증 토큰
   # praefect_internal_token과 일치해야 합니다.
   auth: {
      # ...
      #
      # Gitaly의 인증 토큰은 Gitaly로의 gRPC 요청을 인증하는 데 사용됩니다. 이 값은 GitLab Rails 애플리케이션 구성과 일치해야 합니다.
      token: 'gitalysecret',
   },
   # Gitaly Pack-objects 캐시
   # 성능 향상을 위해 활성화하는 것이 좋지만 디스크 I/O를 상당히 증가시킬 수 있습니다.
   # 자세한 정보는 https://docs.gitlab.com/ee/administration/gitaly/configure_gitaly.html#pack-objects-cache를 참조하십시오.
   pack_objects_cache: {
      # ...
      enabled: true,
   },
   storage: [
      {
         name: 'default',
         path: '/var/opt/gitlab/git-data',
      },
      {
         name: 'storage1',
         path: '/mnt/gitlab/git-data',
      },
   ],
}

변경 사항이 적용되려면 GitLab을 다시 구성합니다.
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 실행

Gitaly TLS 지원

Gitaly는 TLS 암호화를 지원합니다. 안전한 연결을 위해 Gitaly 인스턴스에서 사용하는 gitaly_address에 tls:// URL scheme을 사용해야 합니다.

자동으로 제공되지 않기 때문에 사용자가 직접 인증서를 가져와야 합니다. 인증서 또는 해당 인증서의 기관은 모든 Gitaly 노드(인증서를 사용하는 Gitaly 노드 포함) 및 통신하는 모든 클라이언트 노드에 설치되어야 합니다. 이러한 절차는 GitLab 사용자 정의 인증서 구성에서 설명된 대로 진행되어야 합니다.

참고: 자체 서명 인증서는 Gitaly 서버에 액세스하는 데 사용하는 주소를 지정해야 합니다. Gitaly 서버의 호스트명으로 액세스하는 경우 대체 주소로 추가해야 합니다. Gitaly 서버의 IP 주소로 액세스하는 경우, 인증서에 대체 주소로 추가해야 합니다.

Gitaly 서버를 암호화되지 않은 수신 주소 (listen_addr) 및 암호화된 수신 주소 (tls_listen_addr)로 동시에 구성할 수 있습니다. 이를 통해 필요한 경우 암호화되지 않은 트래픽에서 암호화된 트래픽으로 점진적인 전환을 수행할 수 있습니다.

TLS로 Gitaly를 구성하려면:

/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/trusted-certs로 복사하여 Gitaly가 자체를 호출할 때 인증서를 신뢰하도록 하십시오:
```
sudo cp /etc/gitlab/ssl/cert.pem /etc/gitlab/trusted-certs/
```

/etc/gitlab/gitlab.rb 파일을 편집하고 다음을 추가하십시오:

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

gitaly['listen_addr']를 삭제하여 암호화된 연결만 허용합니다.
파일을 저장하고 GitLab 재구성을 수행하십시오.

컴포넌트 설정으로 돌아가기

Sidekiq 구성

Sidekiq는 Redis, PostgreSQL, 및 Gitaly 인스턴스에 연결해야 합니다. 또한 권장 사항으로 Object Storage에도 연결해야 합니다.

참고: 환경의 Sidekiq 작업 처리 속도가 느리고 대기열이 긴 경우 해당 속도에 맞게 스케일링할 수 있습니다. 자세한 내용은 스케일링 문서를 참조하십시오.

Sidekiq 서버를 구성하려면 Sidekiq를 사용하려는 서버 노드에서 다음을 수행하십시오:

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

/etc/gitlab/gitlab.rb 파일을 생성 또는 편집하고 다음 구성을 사용합니다:

# https://docs.gitlab.com/omnibus/roles/#sidekiq-roles
roles(["sidekiq_role"])
   
# 외부 URL
external_url 'https://gitlab.example.com'
   
## Redis 연결 세부 정보
gitlab_rails['redis_port'] = '6379'
gitlab_rails['redis_host'] = '10.1.0.6' # Redis 서버의 IP/호스트명
gitlab_rails['redis_password'] = 'Redis 비밀번호'
   
# Gitaly 및 GitLab은 gRPC 요청의 인증을 위해 두 개의 공유 비밀로, GitLab-Shell에서 GitLab 내부 API로의 인증을 위해 두 번째 인증을 사용합니다.
# 다음 값은 Gitaly 설정의 해당 값과 동일해야 합니다.
gitlab_rails['gitaly_token'] = 'gitalysecret'
gitlab_shell['secret_token'] = 'shellsecret'
   
git_data_dirs({
  'default' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
  'storage1' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
  'storage2' => { 'gitaly_address' => 'tcp://gitaly2.internal:8075' },
})
   
## PostgreSQL 연결 세부 정보
gitlab_rails['db_adapter'] = 'postgresql'
gitlab_rails['db_encoding'] = 'unicode'
gitlab_rails['db_host'] = '10.1.0.5' # 데이터베이스 서버의 IP/호스트명
gitlab_rails['db_password'] = '데이터베이스 비밀번호'
   
## 업그레이드 시 자동으로 데이터베이스 마이그레이션을 실행하지 않음
gitlab_rails['auto_migrate'] = false
   
# Sidekiq
sidekiq['enable'] = true
sidekiq['listen_address'] = "0.0.0.0"
   
## 사용 가능한 CPU와 동일한 수의 Sidekiq 큐 프로세스 수로 설정
sidekiq['queue_groups'] = ['*'] * 4
   
## 수출자가 수신 대기할 네트워크 주소를 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
   
# 객체 스토리지
## 이 구성은 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: logrotate: (pid 192292) 2990s; run: log: (pid 26374) 93048s
run: node-exporter: (pid 26864) 92997s; run: log: (pid 26446) 93036s
run: sidekiq: (pid 26870) 92996s; run: log: (pid 26391) 93042s

컴포넌트 설정으로 돌아가기

GitLab Rails 구성

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

우리의 아키텍처에서는 Puma 웹서버를 사용하여 각 GitLab Rails 노드를 실행하고 가용 CPU의 90%로 워커 수를 설정하고 스레드 수를 4로 설정합니다. 다른 컴포넌트와 함께 실행 중인 노드에서는 작업량에 따라 워커 값을 감소해야 합니다. 워커 값을 50%로 설정하면 좋은 균형이 달성된다는 것을 확인했지만, 이는 작업 부하에 따라 다를 수 있습니다.

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

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

/etc/gitlab/gitlab.rb을 만들거나 편집하고 다음 구성을 사용하십시오. 노드 간에 링크를 균일하게 유지하기 위해 응용 프로그램 서버의 external_url은 사용자가 GitLab에 액세스할 URL을 가리키도록해야 합니다. 이는 GitLab 애플리케이션 서버로 트래픽을 경로로 지정하는 로드 밸런서의 URL입니다.

external_url 'https://gitlab.example.com'
   
# Gitaly와 GitLab은 gRPC 요청을 검증하기 위해 두 가지 공유 비밀을 사용하며,
# GitLab-Shell에서 GitLab 내부 API로의 인증 콜백을 위해 두 번째 공유 비밀을 사용합니다.
# 다음 두 값은 Gitaly 설정의 해당 값과 동일해야 합니다.
gitlab_rails['gitaly_token'] = 'gitalysecret'
gitlab_shell['secret_token'] = 'shellsecret'
   
git_data_dirs({
  'default' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
  'storage1' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
  'storage2' => { 'gitaly_address' => 'tcp://gitaly2.internal:8075' },
})
   
## GitLab 애플리케이션 서버에 없어야 할 컴포넌트 비활성화
roles(['application_role'])
gitaly['enable'] = false
nginx['enable'] = true
sidekiq['enable'] = false
   
## PostgreSQL 연결 세부 정보
gitlab_rails['db_adapter'] = 'postgresql'
gitlab_rails['db_encoding'] = 'unicode'
gitlab_rails['db_host'] = '10.1.0.5' # 데이터베이스 서버의 IP/호스트 이름
gitlab_rails['db_password'] = 'DB 비밀번호'
   
## Redis 연결 세부 정보
gitlab_rails['redis_port'] = '6379'
gitlab_rails['redis_host'] = '10.1.0.6' # Redis 서버의 IP/호스트 이름
gitlab_rails['redis_password'] = 'Redis 비밀번호'
   
# 모니터링에 사용될 내트워크 주소 지정
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 메트릭을 수집할 수 있도록 허용합니다.
# 플레이스홀더 `monitoring.gitlab.example.com`을 모니터링 노드에서 수집된 주소 및/또는 서브넷으로 대체하십시오
gitlab_rails['monitoring_whitelist'] = ['<MONITOR NODE IP>/32', '127.0.0.0/8']
nginx['status']['options']['allow'] = ['<MONITOR NODE IP>/32', '127.0.0.0/8']
   
# 객체 스토리지
# GCP에서 객체 스토리지를 구성하는 예시입니다
# 이 구성은 필요에 따라 선택한 객체 스토리지 공급자로 대체하십시오
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['object_store']['objects']['artifacts']['bucket'] = "<gcp-artifacts-bucket-name>"
gitlab_rails['object_store']['objects']['external_diffs']['bucket'] = "<gcp-external-diffs-bucket-name>"
gitlab_rails['object_store']['objects']['lfs']['bucket'] = "<gcp-lfs-bucket-name>"
gitlab_rails['object_store']['objects']['uploads']['bucket'] = "<gcp-uploads-bucket-name>"
gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
   
gitlab_rails['backup_upload_connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
   
gitlab_rails['ci_secure_files_object_store_enabled'] = true
gitlab_rails['ci_secure_files_object_store_remote_directory'] = "gcp-ci_secure_files-bucket-name"
   
gitlab_rails[
  'ci_secure_files_object_store_connection'] = {
   'provider' => 'Google',
   'google_project' => '<gcp-project-name>',
   'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
   
## 다음 옵션을 주석 처리하고 편집하십시오.
## NFS를 구성한 경우에만 설정합니다
##
## NFS 데이터 마운트를 사용할 수 없을 경우 GitLab 시작 방지
##
#high_availability['mountpoint'] = '/var/opt/gitlab/git-data'
##
## 권한을 위해 서버 간 UID와 GID가 일치하는지 확인하기 위해
##
#user['uid'] = 9000
#user['gid'] = 9000
#web_server['uid'] = 9001
#web_server['gid'] = 9001
#registry['uid'] = 9002
#registry['gid'] = 9002

Gitaly TLS 지원을 사용하는 경우, git_data_dirs 항목을 tls로 구성해야 합니다.

git_data_dirs({
  'default' => { 'gitaly_address' => 'tls://gitaly1.internal:9999' },
  'storage1' => { 'gitaly_address' => 'tls://gitaly1.internal:9999' },
  'storage2' => { 'gitaly_address' => 'tls://gitaly2.internal:9999' },
})

인증서를 /etc/gitlab/trusted-certs로 복사합니다.
```
sudo cp cert.pem /etc/gitlab/trusted-certs/
```

첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 동일한 이름의 파일을 추가하거나 교체하십시오. 이것이 구성 중인 첫 번째 Linux 패키지 노드이면 이 단계를 건너뛸 수 있습니다.
데이터베이스 마이그레이션이 업그레이드시 자동으로 실행되지 않고 재구성 중에만 실행되도록하려면 다음 명령을 실행하십시오.
```
sudo touch /etc/gitlab/skip-auto-reconfigure
```
단일 지정된 노드만 GitLab Rails 후 구성 섹션에 설명된 대로 마이그레이션을 처리해야 합니다.
변경 사항이 적용되려면 GitLab 재구성을 실행하십시오.
증분 로깅 활성화.
sudo gitlab-rake gitlab:gitaly:check를 실행하여 노드가 Gitaly에 연결할 수 있는지 확인하십시오.
요청을 보려면 로그를 찾으십시오.
```
sudo gitlab-ctl tail gitaly
```

이전 예제와 같이 external_url에 https를 지정하면 GitLab은 SSL 인증서가 /etc/gitlab/ssl/에 있다고 기대합니다. 인증서가 없으면 NGINX가 시작하지 않습니다. 자세한 내용은 HTTPS 문서를 참조하십시오.

GitLab Rails 후-구성

설치 및 업데이트 중에 데이터베이스 마이그레이션을 실행할 응용 프로그램 노드를 지정합니다. GitLab 데이터베이스를 초기화하고 모든 마이그레이션이 실행되었는지 확인합니다:
```
sudo gitlab-rake gitlab:db:configure
```
이는 레일스 노드가 기본 데이터베이스에 직접 연결하도록 구성되어 있어야 함을 의미합니다. 마이그레이션이 완료된 후 노드를 다시 PgBouncer를 통과하도록 구성해야 합니다.
데이터베이스에서 인가된 SSH 키를 빠르게 찾을 수 있도록 구성합니다.

구성 컴포넌트로 돌아가기

Prometheus 구성

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

모니터링 노드에 SSH로 로그인합니다.
사용하려는 Linux 패키지를 다운로드하고 설치합니다. 페이지의 설치 단계 1과 2만 따르도록 합니다.

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

roles(['monitoring_role'])
nginx['enable'] = false
   
external_url 'http://gitlab.example.com'
   
# Prometheus
prometheus['listen_address'] = '0.0.0.0:9090'
prometheus['monitor_kubernetes'] = false

또한 Prometheus는 다양한 노드에서 모든 데이터를 가져오기 위해 스크래이핑 구성이 필요합니다. 노드의 IP가 다음과 같다고 가정합니다:

1.1.1: postgres
1.1.2: redis
1.1.3: gitaly1
1.1.4: rails1
1.1.5: rails2

다음을 /etc/gitlab/gitlab.rb에 추가합니다:

prometheus['scrape_configs'] = [
  {
     'job_name': 'postgres',
     'static_configs' => [
     'targets' => ['1.1.1.1:9187'],
     ],
  },
  {
     'job_name': 'redis',
     'static_configs' => [
     'targets' => ['1.1.1.2:9121'],
     ],
  },
  {
     'job_name': 'gitaly',
     'static_configs' => [
     'targets' => ['1.1.1.3:9236'],
     ],
  },
  {
     'job_name': 'gitlab-nginx',
     'static_configs' => [
     'targets' => ['1.1.1.4:8060', '1.1.1.5:8060'],
     ],
  },
  {
     'job_name': 'gitlab-workhorse',
     'static_configs' => [
     'targets' => ['1.1.1.4:9229', '1.1.1.5:9229'],
     ],
  },
  {
     'job_name': 'gitlab-rails',
     'metrics_path': '/-/metrics',
     'static_configs' => [
     'targets' => ['1.1.1.4:8080', '1.1.1.5:8080'],
     ],
  },
  {
     'job_name': 'gitlab-sidekiq',
     'static_configs' => [
     'targets' => ['1.1.1.4:8082', '1.1.1.5:8082'],
     ],
  },
  {
     'job_name': 'node',
     'static_configs' => [
     'targets' => ['1.1.1.1:9100', '1.1.1.2:9100', '1.1.1.3:9100', '1.1.1.4:9100', '1.1.1.5:9100'],
     ],
  },
]

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

구성 컴포넌트로 돌아가기

객체 리포지터리 구성

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

GitLab에서 객체 리포지터리 구성을 지정하는 두 가지 방법이 있습니다:

통합 형식: 모든 지원되는 객체 유형이 공유 자격 증명을 사용합니다.
스토리지별 형식: 모든 객체는 자체 객체 리포지터리 연결 및 구성을 정의합니다.

통합 형식은 가능한 경우에 사용됩니다.

GitLab에서 각 데이터 유형에 대한 별도의 버킷을 사용하는 것이 권장됩니다. 이로써 GitLab이 저장하는 다양한 유형의 데이터 사이에서 충돌이 발생하지 않도록 합니다. 미래에 단일 버킷 사용을 가능하게 하는 것이 계획되어 있습니다.

구성 컴포넌트로 돌아가기

증분 로깅 활성화

GitLab Runner는 작업 로그를 청크로 반환하며 기본적으로 /var/opt/gitlab/gitlab-ci/builds에 임시로 캐시합니다. 이는 통합 객체 리포지터리를 사용할 때에도 해당됩니다. 기본 구성으로는 이 디렉터리가 모든 GitLab Rails 및 Sidekiq 노드에서 NFS를 통해 공유되어야 합니다.

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

고급 검색 구성

Tier: Premium, Ultimate Offering: 온프레미스

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

Elasticsearch 클러스터 디자인 및 요구 사항은 특정 데이터에 따라 다릅니다. 인스턴스와 함께 Elasticsearch 클러스터를 설정하는 권장 사항에 대한 자세한 내용은 적절한 클러스터 구성 선택에 대한 안내를 읽어보십시오.

구성 컴포넌트로 돌아가기

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

GitLab Helm 차트를 사용하여 Kubernetes에서 클라우드 네이티브 GitLab의 선택한 컴포넌트를 실행할 수 있습니다. 이 설정에서는 Kubernetes 클러스터인 Webservice라는 곳에 GitLab Rails의 동등한 기능을 실행할 수 있습니다. 또한 Sidekiq 노드의 동등한 기능을 실행할 수 있는 Kubernetes 클러스터인 Sidekiq도 실행할 수 있습니다. 또한 다음과 같은 다른 지원 서비스도 지원됩니다: NGINX, Toolbox, Migrations, Prometheus.

하이브리드 설치는 클라우드 네이티브 및 전통적인 컴퓨팅 배포의 이점을 모두 활용합니다. 이를 통해 상태가 없는 컴포넌트는 클라우드 네이티브 워크로드 관리의 이점을 얻을 수 있으며 상태가 있는 컴포넌트는 증가된 지속성을 얻기 위해 Linux 패키지 설치를 한 컴퓨트 VM에 배포됩니다.

설정 지침과 Kubernetes 및 백엔드 컴포넌트 간에 동기화해야 하는 GitLab 비밀을 안내하는 고급 구성에 대한 Helm 차트 문서를 참조하십시오.

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

2,000 참조 아키텍처는 고가용성(HA) 설정이 아닙니다. HA를 달성하려면 수정된 3K 또는 60 RPS 참조 아키텍처를 따르십시오.

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

클러스터 토폴로지

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

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

컴포넌트 노드 그룹	대상 노드 풀 총계	GCP 예시	AWS 예시
Webservice	12 vCPU 15 GB 메모리 (요청) 21 GB 메모리 (제한)	3 x `n1-standard-8`	3 x `c5.2xlarge`
Sidekiq	3.6 vCPU 8 GB 메모리 (요청) 16 GB 메모리 (제한)	2 x `n1-standard-4`	2 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 제공자의 시스템 프로세스에 대한 추가 리소스가 필요합니다. 제공된 예시는 이 사항을 고려합니다.
Supporting 대상 노드 풀 총계는 GitLab 배포를 지원하고 다양한 요구에 따라 만들고자 하는 추가 배포를 수용하기 위해 일반적으로 제공됩니다. 다른 노드 풀과 마찬가지로 선택한 Kubernetes 제공자의 시스템 프로세스도 리소스가 필요합니다. 제공된 예시는 이 사항을 고려합니다.
실제 배포에서는 특정 노드에 파드를 할당할 필요는 없습니다. 그러나 견고한 클라우드 아키텍처 관행과 일치하기 위해 각 풀에 여러 노드를 여러 가용 영역에 분산시키는 것이 권장됩니다.
효율성을 위해 Cluster Autoscaler와 같은 오토스케일링 기능을 활성화하는 것이 권장되지만 보통 Webservice 및 Sidekiq 파드를 지속적인 성능을 보장하기 위해 75%의 최소값을 타깃으로 하는 것이 일반적으로 권장됩니다.

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

서비스	노드	구성	GCP	AWS
PostgreSQL¹	1	2 vCPU, 7.5 GB 메모리	`n1-standard-2`	`m5.large`
Redis²	1	1 vCPU, 3.75 GB 메모리	`n1-standard-1`	`m5.large`
Gitaly	1	4 vCPU, 15 GB 메모리	`n1-standard-4`	`m5.xlarge`
객체 리포지터리³	-	-	-	-

각주:

신뢰할 수 있는 서드파티 외부 PaaS PostgreSQL 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 Provide your own PostgreSQL instance 및 Recommended cloud providers and services를 참조하십시오.
신뢰할 수 있는 서드파티 외부 PaaS Redis 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 Provide your own Redis instance 및 Recommended cloud providers and services를 참조하십시오.
신뢰할 수 있는 클라우드 제공자 또는 Self-Managed형 솔루션에서 실행되어야 합니다. 자세한 내용은 Configure the object storage를 참조하십시오.

인스턴스 구성을 포함하는 모든 PaaS 솔루션에 대해 견고한 클라우드 아키텍처 관행과 일치하기 위해 세 가용 영역 각각에 세 개의 노드를 구현하는 것이 권장됩니다.

Kubernetes 컴포넌트 대상

다음 섹션에서는 Kubernetes에서 실행되는 GitLab 컴포넌트에 대한 대상을 자세히 설명합니다.

웹서비스

각 웹서비스 파드(Puma 및 Workhorse)는 다음 구성으로 실행하는 것이 좋습니다.

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

40 RPS 또는 2,000명의 사용자를 위해서는 약 12개의 Puma 워커 전체 수를 추천하며, 이에 따라 적어도 3개의 웹서비스 파드를 실행하는 것이 좋습니다.

웹서비스 자원 사용에 대한 자세한 정보는 웹서비스 자원에 대한 차트 문서를 참조하십시오.

NGINX

또한 NGINX 컨트롤러 파드를 웹서비스 노드의 전체에 걸쳐 DaemonSet으로 배포하는 것이 좋습니다. 이렇게 하면 컨트롤러가 제공하는 웹서비스 파드와 동적으로 확장하고 일반적으로 더 큰 머신 유형에서 더 높은 네트워크 대역폭을 활용할 수 있습니다.

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

Sidekiq

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

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

표준 배포와 유사하게 여기에서 초기 목표로 4개의 Sidekiq 워커가 사용되었습니다. 구체적인 워크플로에 따라 추가 워커가 필요할 수 있습니다.

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

지원

지원 노드 풀은 웹서비스 및 Sidekiq 풀에 필요하지 않은 모든 지원 배포를 수용하기 위해 설계되었습니다.

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

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

구성 파일 예시

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

컴포넌트 설정으로 돌아가기

참조 아키텍처: 초당 최대 40개의 RPS 또는 2,000명 사용자까지 지원

요구 사항

테스트 방법

컴포넌트 설정

외부 로드 밸런서 구성

준비 상태 확인

포트

대체 SSH 포트

SSL

응용 프로그램 노드에서 SSL을 해지

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

로드 밸런서가 백엔드 SSL과 함께 SSL을 해지

PostgreSQL 구성

나만의 PostgreSQL 인스턴스 제공

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

Redis 구성

자체 Redis 인스턴스 제공

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

Gitaly 구성

Gitaly TLS 지원

Sidekiq 구성

GitLab Rails 구성

GitLab Rails 후-구성

Prometheus 구성

객체 리포지터리 구성

증분 로깅 활성화

고급 검색 구성

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

클러스터 토폴로지

Kubernetes 컴포넌트 대상

웹서비스

NGINX

Sidekiq

지원

구성 파일 예시

도움말

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

도움받기