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

참조 아키텍처: 최대 2,000 사용자

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

이 페이지에서는 최대 2,000명의 사용자에 대한 GitLab 참조 아키텍처에 대해 설명합니다 (notable headroom(non-HA)이 포함됨).

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

대상 부하: API: 40 RPS, Web: 4 RPS, Git(풀): 4 RPS, Git(푸시): 1 RPS
고가용성: 아니요. 고가용성 환경이 필요한 경우 변경된 3,000 사용자 참조 아키텍처를 따를 수 있습니다.
예상 비용: 비용 표 보기
Cloud Native Hybrid: 예
어떤 참조 아키텍처를 사용해야 하는지 잘 모르겠습니까? 자세한 정보는 여기 가이드로 이동.

서비스	노드 수	구성	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)에 배치할 수 있습니다. 그러나 GitLab Rails의 경우 마이그레이션 및 Mailroom과 같은 특정 프로세스는 하나의 노드에서만 실행되어야 합니다.

주의: 모든 PaaS 솔루션의 경우 인스턴스를 구성하는 것이 원한다면 원하는 만큼 여러 가용 영역에 배포하는 것이 좋습니다.

요구사항

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

테스트 방법론

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

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

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

위의 엔드포인트 목표에 대해 정기적으로 더 높은 처리량을 가지고 있다는 메트릭스가 있다면, 대형 단일 저장소 또는 주목할만한 추가 워크로드가 성능 환경에 미치는 영향을 참조하여 추가적인 조정이 필요할 수 있습니다. 이 경우, 링크된 문서를 참조하고 고객 성공 관리자나 지원팀에 연락하여 추가적인 지침을 얻기를 강력히 권장합니다.

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

테스트에 사용된 로드 밸런서는 Linux 패키지 환경에서는 HAProxy 또는 Cloud Native Hybrid의 경우 등가의 NGINX Ingress를 통해 사용되었습니다. 이 선택은 특정 요구 사항이나 권장사항을 나타내는 것은 아니며, 대부분의 신뢰할 수 있는 로드 밸런서가 작동할 것으로 예상됩니다.

구성 구성 요소

GitLab 및 해당 구성 요소를 2,000명까지 수용하도록 설정하는 방법:

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

외부 로드 밸런서 구성

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

어떤 로드 밸런서를 사용해야 하는지 또는 정확한 구성은 GitLab 문서의 범위를 벗어나지만 더 자세한 정보는 로드 밸런서를 참조하십시오. 이 섹션에서는 선택한 로드 밸런서에 대한 구체적인 구성에 중점을 둡니다.

준비 확인

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

포트

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

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

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

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

LB 포트	백엔드 포트	프로토콜
80	다양 (1)	HTTP
443	다양 (1)	TCP (2)

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

대체 SSH 포트

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

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

LB 포트	백엔드 포트	프로토콜
443	22	TCP

SSL

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

응용 프로그램 노드가 SSL을 종료함.
로드 밸런서가 백엔드 SSL 없이 SSL을 종료함 그리고 로드 밸런서와 응용 프로그램 노드 간 통신이 안전하지 않음.
로드 밸런서가 백엔드 SSL을 사용하여 SSL을 종료함 그리고 로드 밸런서와 응용 프로그램 노드 간 통신이 안전함.

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

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

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

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

로드 밸런서를 TCP 대신 HTTP(S) 프로토콜을 사용하도록 구성하세요. 이렇게 하면 로드 밸런서가 SSL 인증서를 관리하고 SSL을 종료하게 됩니다.

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

로드 밸런서가 백엔드 SSL을 사용하여 SSL을 종료함

로드 밸런서를 ‘TCP’ 대신 ‘HTTP(S)’ 프로토콜을 사용하도록 구성하세요. 로드 밸런서는 엔드 사용자가 볼 SSL 인증서를 관리하게 됩니다.

또한 이러한 시나리오에서 로드 밸런서와 NGINX 간 트래픽도 안전합니다. 연결이 끝까지 안전하기 때문에 프록시된 SSL에 대한 구성을 추가할 필요가 없습니다. 그러나 SSL 인증서를 구성하기 위해 GitLab에 구성을 추가해야 합니다. 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 레일 응용 프로그램 구성에서 다루어집니다.

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 레일 및 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는 지원됩니다.
설정에 따라 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'] = '여기에_비밀_비밀번호_입력'

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' => '여기에_비밀_비밀번호_입력',
}

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

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

설치 구성 요소로 돌아가기

Gitaly 구성

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

경고: Gitaly 사양은 사용 패턴 및 저장소 크기의 높은 백분위를 기반으로 합니다. 그러나 큰 모노 저장소 (몇 기가바이트보다 큰 경우)나 추가 작업량이 있는 경우 이러한 요소들은 환경의 성능에 적지 않은 영향을 줄 수 있으며, 추가적인 조정이 필요할 수 있습니다. 이에 해당하는 경우, 이 문서를 참조하시거나 고객 성공 관리자나 지원 팀에 문의하는 것을 강력히 권장합니다.

Gitaly는 주목할만한 입력 및 출력 요구 사항이 있으므로, 모든 Gitaly 노드가 반드시 SSD(Solid-State Drive)를 사용하는 것이 좋습니다. 이러한 SSD는 읽기 작업에 대해 최소한 8,000 IOPS(입출력 작업 수) 및 쓰기 작업에 대해 2,000 IOPS의 처리량을 가져야 합니다. 환경을 클라우드 제공자에서 실행 중이라면, 어떻게 하면 IOPS를 올바르게 구성할 수 있는지에 대해 해당 제공업체의 문서를 참조하세요.

다음 사항을 잘 기억해야 합니다:

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

참고: Gitaly 문서 전체에서 언급된 토큰은 관리자가 선택한 임의의 비밀 번호입니다. 이 토큰은 GitLab API 또는 유사한 웹 API 토큰과는 무관합니다.

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

Gitaly 서버를 구성하려면, Gitaly에 사용하려는 서버 노드에서 다음을 수행하세요:

원하는 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`가 실패합니다. 이것은 'front door' GitLab URL이거나 내부 로드 밸런서일 수 있습니다.
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'

# Gitaly
gitaly['enable'] = true

# secret token은 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의 인증 토큰은 gRPC 요청을 Gitaly에 대해 인증하는 데 사용됩니다. 이 값은 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',
      },
   ],
}

여러분이 구성한 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하고 이 서버의 동일한 이름의 파일을 추가하거나 교체합니다. 만약 이것이 처음 구성하는 첫 번째 Linux 패키지 노드라면, 이 단계는 생략할 수 있습니다.
변경 사항이 적용되려면 GitLab을 다시 구성하세요.

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

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 인스턴스에 연결을 요구하며 권장 사항으로 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'] = 'gitaly비밀'
gitlab_shell['secret_token'] = 'shell비밀'

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['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' => '<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' => '<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' => '<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개의 스레드를 갖습니다. 기타 구성 요소와 함께 Rails를 실행하는 노드의 경우 작업자 값은 그에 따라 감소해야합니다. 우리는 작업자 값이 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 password'

## Redis 연결 세부 정보
gitlab_rails['redis_port'] = '6379'
gitlab_rails['redis_host'] = '10.1.0.6' # Redis 서버의 IP/호스트명
gitlab_rails['redis_password'] = 'Redis Password'

# 모니터링에 사용되는 익스포터가 청취할 네트워크 주소 설정
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'] = ['<모니터링 노드 IP>/32', '127.0.0.0/8']
nginx['status']['options']['allow'] = ['<모니터링 노드 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이 NFS 데이터 마운트를 사용할 수 없으면 시작하지 못하도록 합니다.
##
#high_availability['mountpoint'] = '/var/opt/gitlab/git-data'
##
## 권한을 위해 서버 간에 사용자 ID 및 그룹 ID가 일치하는지 확인합니다.
##
#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 대신 tcp로 구성되어 있는지 확인하세요.

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에 연결할 수 있는지 확인하세요.
요청을 보기 위해 로그를 Tail하세요.
```
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 우회가 필요합니다. 마이그레이션이 완료된 후 노드를 다시 PgBouncer로 전환해야 합니다.
데이터베이스에 인가된 SSH 키를 빠르게 조회하도록 구성합니다(../operations/fast_ssh_key_lookup.md).

설정 구성으로 돌아가기

프로메테우스 구성

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

모니터링 노드에 SSH로 로그인합니다.
선택한 리눅스 패키지를 다운로드하고 설치합니다. 페이지의 설치 단계 1 및 2를 딱 따라하기 하기 바랍니다.

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

roles(['monitoring_role'])
nginx['enable'] = false

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

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

프로메테우스는 또한 구성된 내용을 수집하기 위해 스크래이프 구성을 필요로 합니다. 노드의 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은 다양한 유형의 데이터를 보관하기 위해 객체 저장소 서비스를 사용할 수 있습니다. 이는 데이터 객체에 대한 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를 사용합니다.

고급 검색 구성

Tier: 프리미엄, 얼티메이트 Offering: Self-Managed

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

Elasticsearch 클러스터 디자인과 요구 사항은 특정 데이터에 따라 다릅니다. 인스턴스와 함께 Elasticsearch 클러스터를 설정하는 권장 사항에 대한 정보는 최적의 클러스터 구성 선택 방법을 참조하세요.

설정 구성으로 돌아가기

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

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

하이브리드 설치는 클라우드 네이티브 및 전통적인 컴퓨팅 배포의 장점을 모두 활용합니다. 이에 따라 stateless 구성 요소는 클라우드 네이티브 워크로드 관리의 이점을 누리는 반면, stateful 구성 요소는 Linux 패키지 설치가 포함된 컴퓨팅 VM에서 배포되어 증가된 지속성 이점을 누릅니다.

쿠버네티스에서 서비스를 실행하는 것은 복잡하다는 것이 잘 알려진 고급 설정입니다. 이 설정은 단단한 쿠버네티스에 대한 강력한 지식 및 경험이 있을 경우에만 권장합니다. 이 절의 나머지는 이를 전제로 합니다.

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

경고: Gitaly 클러스터를 쿠버네티스에서 실행할 수 없습니다. 자세한 내용은 epic 6127를 참조하세요.

클러스터 토폴로지

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

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

서비스 노드 그룹	노드 수	구성	GCP	AWS	최소 할당 가능 CPU 및 메모리
Webservice	3	8 vCPU, 7.2 GB 메모리	`n1-highcpu-8`	`c5.2xlarge`	23.7 vCPU, 16.9 GB 메모리
Sidekiq	2	4 vCPU, 15 GB 메모리	`n1-standard-4`	`m5.xlarge`	7.8 vCPU, 25.9 GB 메모리
지원 서비스	2	2 vCPU, 7.5 GB 메모리	`n1-standard-2`	`m5.large`	1.9 vCPU, 5.5 GB 메모리

이 설정에서는 Google Kubernetes Engine (GKE) 및 Amazon Elastic Kubernetes Service (EKS)를 권장하며 정기적으로 테스트하고 있습니다.
노드 구성은 Pod vCPU/메모리 비율을 확실히하고 성능 테스트 중에 스케일링을 피하기 위해 표시됩니다.
- 프로덕션 배포에서는 특정 노드에 Pod를 할당할 필요가 없습니다. 적어도 서로 다른 가용 영역에 3개의 노드를 권장하며 이는 견고한 클라우드 아키텍처 관행과 일치하는 것이 강력히 권장됩니다.

다음은 리눅스 패키지를 사용하여 정적 컴퓨팅 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`
객체 저장소 ³	-	-	-	-

각주:

신뢰할 수 있는 타사 외부 PaaS PostgreSQL 솔루션에서 선택하여 실행할 수 있습니다. 자세한 내용은 자체 PostgreSQL 인스턴스 제공 및 권장 클라우드 제공업체 및 서비스를 참조하세요.
신뢰할 수 있는 타사 외부 PaaS Redis 솔루션에서 선택하여 실행할 수 있습니다. 자세한 내용은 자체 Redis 인스턴스 제공 및 권장 클라우드 제공업체 및 서비스를 참조하세요.
신뢰할 수 있는 클라우드 제공업체 또는 Self Managed 솔루션에서 실행할 수 있습니다. 자세한 내용은 객체 저장소 구성를 참조하세요.

리소스 사용량 설정

다음의 공식은 리소스 제약 조건 내에서 배포될 수 있는 파드 수를 계산하는 데 도움이 됩니다. 2k 참조 아키텍처 예제 값 파일은 계산된 구성을 Helm 차트에 적용하는 방법을 문서화합니다.

웹서비스

웹서비스 파드는 일반적으로 각각 1 CPU 및 1.25GB의 메모리 _퍼 워커_가 필요합니다. 각 웹서비스 파드는 기본적으로 두 개의 워커 프로세스가 생성되며 각 파드에 다른 작은 프로세스가 실행되기 때문에 추천된 토폴로지를 사용하면 대략적으로 4 CPU 및 5GB의 메모리를 소비합니다.

2,000명의 사용자를 위해 약 12개의 총 푸마 워커 수를 권장합니다. 제공된 권장 사항에 따라 기존 자원을 확장하면 각 웹서비스 파드마다 4개의 워커 및 노드당 1개의 파드가 배치될 수 있습니다. 추가 웹서비스 파드마다 각각의 워커 프로세스에 대해 1 CPU에서 1.25GB의 메모리의 비율을 사용하여 사용 가능한 자원을 확장할 수 있습니다.

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

Sidekiq

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

제공된 출발점에 따라 최대 4개의 Sidekiq 파드를 배치할 수 있습니다. 추가 파드를 배치하기 위해 사용 가능한 자원을 0.9 CPU에서 2GB 메모리의 비율을 통해 확장할 수 있습니다.

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

지원

지원 노드 풀은 웹서비스 및 Sidekiq 풀에 속하지 않아도 되는 모든 지원 배포에 대한 설계입니다.

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

모니터링과 같은 추가 배포를 원하는 경우, 가능한 경우 이 풀에 배포하는 것이 좋으며 웹서비스나 Sidekiq 풀이 아닌 곳에 배포하는 것이 좋습니다. 지원 풀은 몇 가지 추가 배포를 수용하기 위해 특별히 설계되었습니다. 그러나 제공된 풀에 배포물이 들어맞지 않는 경우 노드 풀을 상응하게 늘릴 수 있습니다.

설정 구성으로 돌아가기

참조 아키텍처: 최대 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 포스트-구성

프로메테우스 구성

객체 저장소 구성

증분 로깅 활성화

고급 검색 구성

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

클러스터 토폴로지

리소스 사용량 설정

웹서비스

Sidekiq

지원

도움말

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

도움받기