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

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

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

이 페이지는 실제 데이터를 바탕으로 수동 및 자동 사용자 모두 최대 2,000명의 피크 부하 및 초당 40 요청(RPS)의 피크 부하를 목표로 하는 GitLab 참조 아키텍처를 설명합니다.

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

Target Load: API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS

High Availability: 아니요. 고가용성 환경을 위해서는 수정된 3K 또는 60 RPS 참조 아키텍처를 따를 수 있습니다.

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

Cloud Native Hybrid: 예

Unsure which Reference Architecture to use? 어떤 아키텍처를 시작해야 할지 더 많은 정보를 얻으려면 이 가이드로 가세요.

서비스	노드	구성	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`
객체 저장소⁴	-	-	-	-	-

각주:

평판이 좋은 제3자 외부 PaaS PostgreSQL 솔루션에서 선택적으로 실행할 수 있습니다. 자신의 PostgreSQL 인스턴스 제공 및 추천 클라우드 제공업체 및 서비스를 참조하여 자세한 정보를 확인하세요.
평판이 좋은 제3자 외부 PaaS Redis 솔루션에서 선택적으로 실행할 수 있습니다. 자신의 Redis 인스턴스 제공 및 추천 클라우드 제공업체 및 서비스를 참조하여 자세한 정보를 확인하세요.
평판이 좋은 제3자 로드 밸런서 또는 서비스(LB PaaS)와 함께 실행하는 것이 권장됩니다.
크기는 선택한 로드 밸런서 및 네트워크 대역폭 등의 추가 요소에 따라 달라집니다. 로드 밸런서를 참조하여 자세한 정보를 확인하세요.
평판이 좋은 클라우드 제공업체 또는 자체 관리 솔루션에서 실행해야 합니다. 객체 저장소 구성을 참조하여 자세한 정보를 확인하세요.
Gitaly 사양은 정상적인 크기의 건강한 리포지토리를 사용할 때 기준으로 합니다.
그러나 여러 기가바이트 이상의 큰 모노레포가 있는 경우 Git 및 Gitaly 성능에 상당히 영향을 미칠 수 있으며 사양 증가가 필요할 수 있습니다.
큰 모노레포를 참조하여 자세한 정보를 확인하세요.
상태 비저장 데이터는 저장하지 않기 때문에 자동 확장 그룹(ASG)에 배치할 수 있습니다.
그러나 Cloud Native Hybrid 설정이 일반적으로 선호되며 특정 구성 요소는
마이그레이션 및 메일룸과 같이 하나의 노드에서만 실행할 수 있어 Kubernetes에서 더 잘 처리됩니다.

모든 PaaS 솔루션의 인스턴스 구성과 관련하여, 원하는 경우 복원력을 위해 여러 가용 영역에 걸쳐 배포하는 것이 권장됩니다.

요구 사항

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

테스트 방법론

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

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

위의 목표는 사용자 수에 해당하는 총 환경 부담의 실제 고객 데이터를 기반으로 선택되었습니다.

위의 엔드포인트 목표에 대해 정기적으로 더 높은 처리량을 주장할 수 있는 메트릭이 있는 경우, 대규모 모노레포 또는 주목할 만한 추가 작업 부하가 성능 환경에 주목할 만한 영향을 미칠 수 있으며, 추가 조정이 필요할 수 있습니다.

이 경우, 관련 문서를 참조하고 고객 성공 관리자 또는 지원 팀에 문의하는 것이 좋습니다.

테스트는 모든 사람이 사용할 수 있는 데이터 세트를 가진 GitLab Performance Tool (GPT)를 사용하여 정기적으로 수행됩니다.

이 테스트의 결과는 GPT 위키에 공개되어 있습니다. 테스트 전략에 대한 자세한 정보는 문서의 이 섹션을 참조하세요.

테스트에 사용되는 로드 밸런서는 Linux 패키지 환경에 HAProxy 또는 클라우드 네이티브 하이브리드를 위한 NGINX Ingress를 갖춘 동등한 클라우드 제공업체 서비스입니다.

이 선택은 특정 요구 사항 또는 권장 사항을 나타내지 않으며, 대부분의 신뢰할 수 있는 로드 밸런서가 작동할 것으로 예상됩니다.

구성 요소 설정

GitLab과 그 구성 요소를 설정하여 최대 40 RPS 또는 2,000 사용자 수를 수용하려면:

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

외부 로드 밸런서 구성

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

어떤 로드 밸런서를 사용할지, 또는 정확한 구성은 GitLab 문서의 범위를 벗어나지만, 일반적인 요구 사항에 대한 자세한 내용은 로드 밸런서를 참조하세요. 이 섹션은 선택한 로드 밸런서에 대해 구성할 내용을 구체적으로 집중합니다.

준비 상태 확인

외부 로드 밸런서가 모니터링 엔드포인트가 내장된 작동하는 서비스로만 라우팅되도록 하세요. 준비 상태 확인에는 확인 중인 노드에 추가 구성이 필요하며, 그렇지 않으면 외부 로드 밸런서가 연결할 수 없습니다.

포트

사용해야 할 기본 포트는 아래 표에 나와 있습니다.

LB Port	Backend Port	Protocol
80	80	HTTP (1)
443	443	TCP 또는 HTTPS (1) (2)
22	22	TCP

(1): 웹 터미널 지원은 로드 밸런서가 WebSocket 연결을 올바르게 처리해야 합니다. HTTP 또는 HTTPS 프록시를 사용하는 경우, 이는 로드 밸런서가 Connection 및 Upgrade 홉 간 헤더를 통과하도록 구성되어야 함을 의미합니다. 더 많은 세부 정보는 웹 터미널 통합 가이드를 참조하세요.
(2): 포트 443에 HTTPS 프로토콜을 사용할 경우, 로드 밸런서에 SSL 인증서를 추가해야 합니다. GitLab 애플리케이션 서버에서 SSL을 종료하려면 TCP 프로토콜을 사용하세요.

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

LB Port	Backend Port	Protocol
80	다양함 (1)	HTTP
443	다양함 (1)	TCP (2)

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

대체 SSH 포트

일부 조직에서는 SSH 포트 22를 여는 정책을 가지고 있습니다. 이 경우, 사용자들이 포트 443에서 SSH를 사용하도록 허용하는 대체 SSH 호스트 이름을 구성하는 것이 도움이 될 수 있습니다. 대체 SSH 호스트 이름은 위의 다른 GitLab HTTP 구성에 비해 새로운 가상 IP 주소가 필요합니다.

대체 SSH 호스트 이름을 위해 DNS를 altssh.gitlab.example.com과 같은 형태로 구성하세요.

LB Port	Backend Port	Protocol
443	22	TCP

SSL

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

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

애플리케이션 노드에서 SSL 종료

로드 밸런서를 구성하여 443 포트에서 연결을 TCP로 전달하세요.

그렇지 않으면 HTTP(S) 프로토콜로 전달됩니다.

이렇게 하면 연결이 애플리케이션 노드의 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 리눅스 패키지 PostgreSQL 설정에는 PostgreSQL, PgBouncer 및 Consul이 포함됩니다. 이러한 모든 구성 요소는 타사 외부 서비스를 사용할 때 더 이상 필요하지 않습니다.
데이터베이스 요구 사항 문서에 따라 PostgreSQL을 설정합니다.
원하는 비밀번호로 gitlab 사용자 이름을 설정하세요. gitlab 사용자는 gitlabhq_production 데이터베이스를 생성할 수 있는 권한이 필요합니다.
적절한 세부정보로 GitLab 애플리케이션 서버를 구성합니다. 이 단계는 GitLab Rails 애플리케이션 구성에서 다릅니다.

리눅스 패키지를 사용하는 독립형 PostgreSQL

PostgreSQL 서버에 SSH로 접속합니다.
다운로드 및 설치할 리눅스 패키지를 선택합니다. 페이지에서 설치 단계 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'

# APPLICATION_SERVER_IP_BLOCK을 애플리케이션 노드의 CIDR 주소로 교체
postgresql['trust_auth_cidr_addresses'] = %w(127.0.0.1/32 APPLICATION_SERVER_IP_BLOCK)

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

첫 번째 리눅스 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하고 이 서버의 동일한 이름의 파일에 추가하거나 교체합니다.
GitLab 재구성을 수행하여 변경 사항을 적용합니다.
PostgreSQL 노드의 IP 주소 또는 호스트 이름, 포트 및 일반 텍스트 비밀번호를 기록해 두세요. 이 세부정보는 나중에 GitLab 애플리케이션 서버 구성 시 필요합니다.

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

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

Redis 구성하기

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

Redis는 주로 단일 스레드로 작동하며 CPU 코어 수 증가로 인해 크게 이점을 얻지 못합니다.

자세한 내용은 스케일링 문서를 참조하세요.

자신의 Redis 인스턴스 제공하기

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

평판이 좋은 공급자나 솔루션을 사용해야 합니다. Google Memorystore 그리고 AWS ElastiCache가 작동하는 것으로 알려져 있습니다.
Redis Cluster 모드는 특별히 지원되지 않지만 Redis Standalone HA는 지원됩니다.
설정에 따라 Redis 제거 모드를 설정해야 합니다.

자세한 정보는 추천 클라우드 공급자 및 서비스를 참조하세요.

Linux 패키지를 사용한 Standalone 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'

# 모니터링을 위해 수출업자가 수신 대기하는 네트워크 주소 설정
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',
}

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

구성한 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하고 이 서버의 동일한 이름의 파일에 추가하거나 교체합니다. 구성하는 첫 번째 Linux 패키지 노드인 경우 이 단계를 건너뛸 수 있습니다.
변경 사항을 적용하려면 GitLab 재구성하기를 수행하세요.
Redis 노드의 IP 주소 또는 호스트 이름, 포트 및 Redis 비밀번호를 기록해 두세요. 이는 나중에 GitLab 애플리케이션 서버 구성하기에 필요합니다.

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

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

Gitaly 구성

Gitaly 서버 노드 요구 사항은 데이터 크기, 특히 프로젝트 수와 해당 프로젝트의 크기에 따라 다릅니다.

경고:

Gitaly 사양은 양호한 상태의 사용 패턴과 저장소 크기의 높은 백분위수에 기반합니다.

하지만, 만약 대규모 모노레포 (몇 기가바이트를 초과)나 추가 작업 부하가 있는 경우, 이러한 사항이 환경 성능에 상당히 영향을 줄 수 있으며, 추가 조정이 필요할 수 있습니다.

이 사항이 해당된다면 링크된 문서와 함께 고객 성공 관리자 또는 지원 팀에 문의하여 추가 안내를 받는 것을 강력히 권장합니다.

Gitaly의 중요한 입력 및 출력 요구 사항으로 인해, 모든 Gitaly 노드에 고체 상태 드라이브(SSD)를 사용하는 것을 강력히 권장합니다. 이 SSD는 읽기 작업을 위해 최소 8,000 입출력 작업(I/O) 수치와 쓰기 작업을 위해 2,000 IOPS를 가져야 합니다. 환경을 클라우드 제공업체에서 실행 중이라면, IOPS를 올바르게 구성하는 방법에 대한 문서를 참조하세요.

다음 항목을 꼭 주의하세요:

GitLab Rails 응용 프로그램은 리포지토리를 리포지토리 저장 경로로 샤드합니다.
Gitaly 서버는 하나 이상의 저장 경로를 호스팅할 수 있습니다.
GitLab 서버는 하나 이상의 Gitaly 서버 노드를 사용할 수 있습니다.
Gitaly 주소는 모든 Gitaly 클라이언트가 올바르게 확인 가능하도록 지정되어야 합니다.
Gitaly 서버는 공용 인터넷에 노출되어서는 안 되며, Gitaly의 네트워크 트래픽은 기본적으로 암호화되지 않습니다. Gitaly 서버에 대한 접근을 제한하기 위해 방화벽 사용이 강력하게 권장됩니다. 또 다른 방법은 TLS 사용입니다.

주의:

Gitaly 문서 전반에 걸쳐 언급되는 토큰은 관리자가 선택한 임의의 비밀번호입니다. 이 토큰은 GitLab API 또는 다른 유사한 웹 API 토큰을 위해 생성된 토큰과 관련이 없습니다.

다음 절차는 비밀 토큰 gitalysecret를 사용한 gitaly1.internal라는 단일 Gitaly 서버를 구성하는 방법을 설명합니다. GitLab 설치에 default 및 storage1 두 개의 리포지토리 저장소가 있다고 가정합니다.

Gitaly 서버를 구성하려면 Gitaly를 사용하려는 서버 노드에서:

다운로드 및 설치를 하세요. 원하는 리눅스 패키지를 선택하여 설치하며, 페이지에서 오직 설치 단계 1과 2만 따라야 하고, EXTERNAL_URL 값을 제공하지 마세요.

Gitaly 서버 노드의 /etc/gitlab/gitlab.rb 파일을 편집하여 저장 경로를 구성하고 네트워크 리스너를 활성화하며 토큰을 구성하세요:

주의: gitaly['configuration'][:storage]에서 default 항목을 제거할 수 없으며, 이는 GitLab에서 필요로 함입니다.

# 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

# 모니터링에 사용될 내보내기기가 청취할 네트워크 주소를 설정합니다.
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',
      },
   ],
}

구성한 첫 번째 리눅스 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하고, 이 서버의 동일한 이름의 파일을 추가하거나 교체하세요. 이 노드를 구성하는 것이 첫 번째 리눅스 패키지 노드라면 이 단계는 건너뛰어도 됩니다.
GitLab 재구성하여 변경 사항이 적용되도록 하세요.
Gitaly가 내부 API에 대한 콜백을 수행할 수 있는지 확인하세요:
- GitLab 15.3 이상에서는 sudo -u git -- /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml를 실행하세요.
- GitLab 15.2 이하에서는 sudo -u git -- /opt/gitlab/embedded/bin/gitaly-hooks check /var/opt/gitlab/gitaly/config.toml를 실행하세요.

Gitaly TLS 지원

Gitaly는 TLS 암호화를 지원합니다. 보안 연결을 위해 대기하는 Gitaly 인스턴스와 통신하려면, GitLab 구성의 해당 저장소 항목의 gitaly_address에 tls:// URL 스킴을 사용해야 합니다.

인증서는 자동으로 제공되지 않으므로, 직접 준비해야 합니다.

인증서 또는 해당 인증 기관은 모든 Gitaly 노드(인증서를 사용하는 Gitaly 노드를 포함)와 그것과 통신하는 모든 클라이언트 노드에 설치되어야 하며, 이는 GitLab 사용자 지정 인증서 구성에서 설명한 절차를 따라야 합니다.

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

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

Gitaly가 자신에게 호출할 때 인증서를 신뢰하도록 /etc/gitlab/trusted-certs로 인증서를 복사합니다:
```
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 인스턴스에 연결해야 합니다.

또한 객체 저장소와의 연결이 권장됩니다.

참고: 환경의 Sidekiq 작업 처리가 큐가 길어지면 느린 경우, 이에 따라 확장할 수 있습니다. 자세한 내용은 확장 문서를 참조하세요.

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

Sidekiq 서버를 구성하려면, Sidekiq에 사용할 서버 노드에서:

Sidekiq 서버에 SSH로 접속합니다.

PostgreSQL, Gitaly 및 Redis 포트에 접근할 수 있는지 확인합니다:

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

원하는 Linux 패키지를 다운로드하고 설치합니다. 페이지에서 1단계와 2단계만 반드시 따라야 합니다.

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

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

# 외부 URL
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은 인증을 위해 두 개의 공유 비밀을 사용합니다. 하나는 Gitaly에 대한 gRPC 요청을 인증하고, 두 번째는 GitLab-Shell에서 GitLab 내부 API로의 인증 콜백을 위해 /etc/gitlab/gitlab-secrets.json에 저장됩니다.
# 무엇이라도 Gitaly 설정의 해당 값과 같아야 합니다.
gitlab_rails['gitaly_token'] = 'gitalysecret'

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'] = 'DB 비밀번호'

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

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

## Sidekiq 큐 프로세스 수를 사용 가능한 CPU 수와 동일하게 설정
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%에 해당하는 작업자 수를 설정하고 스레드는 네 개로 설정합니다. 다른 구성 요소와 함께 Rails를 실행하는 노드의 경우, 작업자 값을 그에 맞게 줄여야 합니다. 우리는 50%의 작업자 값이 좋은 균형을 이룬다고 판단했지만, 이는 작업 부하에 따라 다릅니다.

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

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

/etc/gitlab/gitlab.rb 파일을 생성하거나 편집하고 다음 구성을 사용하십시오.

링크의 일관성을 유지하기 위해, 애플리케이션 서버의 external_url은 사용자가 GitLab에 접근하는 데 사용할 외부 URL을 가리켜야 합니다. 이는 GitLab 애플리케이션 서버로 트래픽을 라우팅할 로드 밸런서의 URL이 될 것입니다:

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

# Gitaly 및 GitLab은 인증을 위해 두 개의 공유 비밀을 사용합니다.
# 하나는 Gitaly에 대한 gRPC 요청을 인증하고,
# 두 번째는 /etc/gitlab/gitlab-secrets.json에 저장되어 GitLab-Shell에서 GitLab 내부 API에 대한 인증 콜백을 수행합니다.
# 다음 값은 각각 Gitaly 설정의 값과 같아야 합니다.
gitlab_rails['gitaly_token'] = 'gitalysecret'

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
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'
##
## NFS를 통해 권한을 위해 서버 간 UID 및 GID가 일치하는지 확인하십시오.
##
#user['uid'] = 9000
#user['gid'] = 9000
#web_server['uid'] = 9001
#web_server['gid'] = 9001
#registry['uid'] = 9002
#registry['gid'] = 9002

TLS 지원이 있는 Gitaly를 사용하는 경우,

git_data_dirs 항목이 tcp 대신 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
```
이 작업은 Rails 노드를 기본 데이터베이스에 직접 연결하도록 설정해야 하며, PgBouncer 우회합니다.

마이그레이션이 완료된 후에는 노드를 다시 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
1.1.6: sidekiq

/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.6:8082'],
     ],
  },
  {
     'job_name': 'static-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', '1.1.1.6:9100'],
     ],
  },
]

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

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

객체 저장소 구성

GitLab은 다양한 유형의 데이터를 저장하기 위해 객체 저장소 서비스를 사용하는 것을 지원합니다.

데이터 객체에 대해서는 NFS보다 권장되며, 일반적으로 더 큰 설정에서 더 나은 성능, 신뢰성 및 확장성을 제공합니다. 더 많은 정보는 권장 클라우드 공급자 및 서비스를 참조하세요.

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

통합 형식: 모든 지원되는 객체 유형이 공유하는 단일 자격 증명입니다.
스토리지 특정 형식: 각 객체가 자신의 객체 저장소 연결 및 구성을 정의합니다.

이용 가능한 경우 예제에서는 통합 형식이 사용됩니다.

각 데이터 유형에 대해 별도의 버킷을 사용하는 것이 GitLab에 권장되는 접근 방식입니다.

이것은 GitLab이 저장하는 다양한 유형의 데이터 간에 충돌이 없도록 보장합니다.

미래에 단일 버킷 사용을 활성화할 계획이 있습니다.

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

증분 로깅 활성화

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

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

고급 검색 구성

Tier: Premium, Ultimate Offering: Self-managed

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

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

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

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

GitLab Helm 차트를 사용하여 Kubernetes에서 클라우드 네이티브 GitLab의 선택 구성 요소를 실행합니다. 이 설정에서는 Kubernetes 클러스터에서 웹 서비스라고 하는 GitLab Rails에 상응하는 것을 실행할 수 있습니다. 또한, Kubernetes 클러스터에서 Sidekiq라고 하는 Sidekiq 노드에 상응하는 것을 실행할 수 있습니다. 추가로, 다음과 같은 기타 지원 서비스도 지원됩니다: NGINX, Toolbox, Migrations, Prometheus.

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

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

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

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

Gitaly 클러스터는 Kubernetes에서 실행할 수 없습니다. 더 많은 세부 사항은 epic 6127를 참조하세요.

클러스터 토폴로지

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

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

구성 요소 노드 그룹	대상 노드 풀 합계	GCP 예시	AWS 예시
웹 서비스	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의 대상 노드 풀 총계를 도달하는 방법에 대한 예시가 편리함을 위해 제공됩니다. 이러한 크기는 성능 테스트에 사용되지만, 예시를 따를 필요는 없습니다. 필요한 대로 다른 노드 풀 디자인을 사용할 수 있으며, 목표를 충족하고 모든 파드를 배포할 수 있어야 합니다.
웹 서비스와 Sidekiq의 대상 노드 풀 총계는 GitLab 구성 요소에만 해당됩니다. 선택한 Kubernetes 공급자의 시스템 프로세스에 추가 리소스가 필요합니다. 제공된 예시는 이를 고려합니다.
지원 대상 노드 풀 총계는 GitLab 배포 및 요구 사항에 따라 추가 배포를 지원하기 위한 여러 리소스를 수용하기 위해 일반적으로 제공됩니다. 다른 노드 풀과 유사하게, 선택한 Kubernetes 공급자의 시스템 프로세스에도 리소스가 필요합니다. 제공된 예시는 이를 고려합니다.
프로덕션 배포에서는 특정 노드에 파드를 할당할 필요는 없습니다. 그러나 복원력이 있는 클라우드 아키텍처 관행에 맞추기 위해 각 풀에 여러 노드를 여러 가용 영역에 분산시키는 것이 권장됩니다.
효율성을 위해 클러스터 오토스케일러와 같은 오토스케일링을 활성화하는 것이 권장되지만, 웹 서비스 및 Sidekiq 파드의 경우 75%의 바닥을 목표로 하는 것이 일반적으로 권장됩니다.

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

서비스	노드	구성	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`
객체 스토리지³	-	-	-	-

각주:

평판이 좋은 제3자 외부 PaaS PostgreSQL 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 자신의 PostgreSQL 인스턴스 제공 및 추천 클라우드 공급자 및 서비스를 참조하세요.
평판이 좋은 제3자 외부 PaaS Redis 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 자신의 Redis 인스턴스 제공 및 추천 클라우드 공급자 및 서비스를 참조하세요.
평판 좋은 클라우드 공급자 또는 자체 관리 솔루션에서 실행해야 합니다. 자세한 내용은 객체 스토리지 구성을 참조하세요.

참고:
모든 PaaS 솔루션은 인스턴스를 구성할 때 최소 세 개의 노드를 세 개의 다른 가용 영역에 배치하는 것이 권장되며, 이는 복원력이 있는 클라우드 아키텍처 관행에 맞춰져 있습니다.

Kubernetes 구성 요소 목표

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

웹 서비스

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

4 Puma Worker
4 vCPU
5 GB 메모리 (요청)
7 GB 메모리 (제한)

40 RPS 또는 2,000 사용자에 대해서는 총 Puma Worker 수를 약 12로 권장하므로, 최소한 3개의 웹 서비스 포드를 실행하는 것이 좋습니다.

웹 서비스 리소스 사용에 대한 자세한 정보는 웹 서비스 리소스에서 차트 문서를 참조하세요.

NGINX

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

이는 엄격한 요구 사항은 아닙니다. NGINX 컨트롤러 포드는 필요한 자원을 충분히 갖추고 있다면 원하는 대로 배포할 수 있습니다.

사이드키크

각 사이드키크 포드는 다음 구성으로 실행하는 것이 권장됩니다:

1 사이드키크 워커
900m vCPU
2 GB 메모리 (요청)
4 GB 메모리 (제한)

위의 표준 배포와 유사하게, 여기서는 초기 목표로 4명의 사이드키크 워커를 사용했습니다.

특정 워크플로에 따라 추가 워커가 필요할 수 있습니다.

사이드키크 리소스 사용에 대한 자세한 정보는 사이드키크 리소스에서 차트 문서를 참조하세요.

지원

지원 노드 풀은 웹 서비스 및 사이드키크 풀에 있지 않아도 되는 모든 지원 배포를 수용하도록 설계되었습니다.

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

컨테이너 레지스트리, 페이지 또는 모니터링과 같은 추가 배포를 원하시는 경우 가능한 한 이 풀에 배포하는 것이 좋으며, 웹 서비스 또는 사이드키크 풀에는 배포하지 마세요. 지원 풀은 여러 추가 배포를 수용하도록 특별히 설계되었습니다. 그러나 귀하의 배포가 주어진 풀에 맞지 않는 경우, 노드 풀을 적절히 늘릴 수 있습니다. 반대로, 귀하의 용도에 따라 풀이 과잉 배치된 경우, 이에 맞게 축소할 수 있습니다.

예제 구성 파일

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

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

다음 단계

이 가이드를 따라한 후, 이제 주요 기능이 적절히 구성된 새로운 GitLab 환경을 갖게 되었을 것입니다.

필요에 따라 GitLab의 추가 선택적 기능을 구성할 수 있습니다. 추가 정보는 GitLab 설치 후 단계를 참조하세요.

참고: 환경 및 요구 사항에 따라 추가 기능을 설정하는 데 필요한 추가 하드웨어 요구 사항 또는 조정이 필요할 수 있습니다. 개별 페이지를 참조하여 자세한 정보를 확인하세요.

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

요구 사항

테스트 방법론

구성 요소 설정

외부 로드 밸런서 구성

준비 상태 확인

포트

대체 SSH 포트

SSL

애플리케이션 노드에서 SSL 종료

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

로드 밸런서가 백엔드 SSL로 SSL 종료

PostgreSQL 구성

자체 PostgreSQL 인스턴스 제공

리눅스 패키지를 사용하는 독립형 PostgreSQL

Redis 구성하기

자신의 Redis 인스턴스 제공하기

Linux 패키지를 사용한 Standalone Redis

Gitaly 구성

Gitaly TLS 지원

Sidekiq 구성

GitLab Rails 구성

GitLab Rails 후 구성

Prometheus 구성

객체 저장소 구성

증분 로깅 활성화

고급 검색 구성

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

클러스터 토폴로지

Kubernetes 구성 요소 목표

웹 서비스

NGINX

사이드키크

지원

예제 구성 파일

다음 단계

도움말

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

도움받기