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

Tier: Premium, Ultimate Offering: Self-Managed

이 페이지는 실제 데이터를 기반으로 최대 부하를 처리하도록 설계된 GitLab 참조 아키텍처에 대해 설명합니다. 이 아키텍처는 내장 HA(고가용성)가 구축된 가장 작은 아키텍처입니다. HA가 필요하지만 사용자 수나 총 부하량이 낮은 경우 낮은 사용자 수에 대한 지원되는 수정 사항 섹션에서 HA를 유지하면서 이 아키텍처의 크기를 줄이는 방법에 대해 설명합니다.

모든 참조 아키텍처 디렉터리은 사용 가능한 참조 아키텍처를 참조하세요.

  • 대상 부하: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS
  • 고가용성: 예, 단 Praefect는 타사 PostgreSQL 솔루션을 필요로 합니다.
  • 예상 비용: 비용 표를 참조하세요.
  • 클라우드 네이티브 하이브리드 대체 품목: 예
  • 어떤 참조 아키텍처를 사용해야 하는지 확실하지 않나요? 더 많은 정보를 보려면 이 가이드로 이동.
Service 노드 수 구성 GCP AWS Azure
External load balancer3 1 4 vCPU, 3.6 GB 메모리 n1-highcpu-4 c5n.xlarge F4s v2
Redis2 3 2 vCPU, 7.5 GB 메모리 n1-standard-2 m5.large D2s v3
Consul1 + Sentinel2 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large F2s v2
PostgreSQL1 3 2 vCPU, 7.5 GB 메모리 n1-standard-2 m5.large D2s v3
PgBouncer1 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large F2s v2
Internal load balancer3 1 4 vCPU, 3.6 GB 메모리 n1-highcpu-4 c5n.xlarge F4s v2
Gitaly5 3 4 vCPU, 15 GB 메모리6 n1-standard-4 m5.xlarge D4s v3
Praefect5 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large F2s v2
Praefect PostgreSQL1 1+ 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large F2s v2
Sidekiq7 2 4 vCPU, 15 GB 메모리 n1-standard-4 m5.xlarge D2s v3
GitLab Rails7 3 8 vCPU, 7.2 GB 메모리 n1-highcpu-8 c5.2xlarge F8s v2
모니터링 노드 1 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large F2s v2
Object storage4 - - - - -

각주:

  1. 신뢰할 수 있는 타사 외부 PaaS PostgreSQL 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 자체 PostgreSQL 인스턴스 제공를 참조하세요.
  2. 신뢰할 수 있는 타사 외부 PaaS Redis 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 자체 Redis 인스턴스 제공를 참조하세요.
  3. HA 기능을 제공하는 신뢰할 수 있는 타사 로드 밸런서 또는 서비스(LB PaaS)에서 실행하는 것이 좋습니다. 또한 크기 조정은 선택한 로드 밸런서 및 네트워크 대역폭과 같은 추가 요소에 따라 달라집니다. 자세한 내용은 로드 밸런서를 참조하세요.
  4. 신뢰할 수 있는 클라우드 제공업체 또는 Self-Managed형 솔루션에서 실행하는 것이 좋습니다. 자세한 내용은 객체 리포지터리 구성를 참조하세요.
  5. Gitaly 클러스터는 오류 허용성의 이점을 제공하지만 추가 복잡성이 따릅니다. Gitaly 클러스터 배포 전 기술적 제한 및 고려 사항을 확인하십시오. 샤딩된 Gitaly를 사용하려면 Gitaly에 대해 동일한 사양을 사용하세요.
  6. Gitaly 사양은 주로 사용 패턴 및 리포지터리 크기의 상위 백분위수를 기반으로 합니다. 그러나 대형 모노 리포지터리 (수 기가바이트 이상)나 추가 워크로드가 있으면 Git 및 Gitaly 성능에 중대하게 영향을 미칠 수 있으며 추가 조정이 필요할 수 있습니다.
  7. 해당 컴포넌트가 상태 데이터를 저장하지 않기 때문에 ASG(Auto Scaling Groups)에 배치할 수 있습니다. 그러나 클라우드 네이티브 하이브리드 설정에서 기본적으로 Kubernetes에서 더 잘 처리되는 Gitaly의 특정 컴포넌트 (예: 마이그레이션 및 Mailroom)가 하나의 노드만에서 실행되고 관리되며, 이는 일반적으로 선호됩니다.
note
인스턴스 구성을 포함하는 모든 PaaS 솔루션에 대해, 신뢰할 수 있는 클라우드 아키텍처 관행에 맞추려면 세 가용 영역에서 최소 세 개의 노드를 구현하는 것이 좋습니다.

요구 사항

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

테스트 방법론

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

  • API: 60RPS
  • 웹: 6RPS
  • Git (Pull): 6RPS
  • Git (Push): 1RPS

위의 대상은 CI 및 기타 워크로드를 포함한 사용자 수에 해당하는 실제 고객 데이터를 기반으로 선정되었습니다.

만약 위의 엔드포인트 대상 대비 정기적으로 더 높은 처리량을 가지고 있다는 지표가 있다면, 대형 모노 레포 또는 주목할만한 추가 워크로드가 성능 환경에 미치는 영향이 클 수 있으며, 추가적인 조정이 필요할 수 있습니다. 이러한 경우라면 링크된 설명서를 참고하거나 고객 성공 매니저 또는 지원 팀에 문의하여 추가 지침을 받기를 강력히 권고합니다.

테스트는 주로 우리의 GitLab 성능 도구 (GPT) 및 해당 데이터셋을 사용하여 정기적으로 수행됩니다. 이러한 테스트의 결과는 GPT 위키에서 공개적으로 사용할 수 있습니다. 테스트 전략에 대한 자세한 정보는 설명서의 이 섹션을 참조하세요.

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

컴포넌트 설정

GitLab 및 해당 컴포넌트를 60RPS 또는 3,000 사용자까지 수용하도록 설정하려면 다음을 수행하세요:

  1. 외부 로드 밸런서 구성 GitLab 애플리케이션 서비스 노드의 로드 밸런싱을 처리하도록 구성합니다.
  2. 내부 로드 밸런서 구성 GitLab 애플리케이션 내부 연결의 로드 밸런싱을 처리하도록 구성합니다.
  3. Redis 구성
  4. Consul 및 Sentinel 구성
  5. PostgreSQL 구성, GitLab의 데이터베이스.
  6. PgBouncer 구성
  7. Gitaly 클러스터 구성 Git 리포지터리에 액세스 제공
  8. Sidekiq 구성
  9. 주요 GitLab Rails 애플리케이션 구성 Puma, Workhorse, GitLab Shell 실행 및 모든 프론트엔드 요청 (UI, API, Git over HTTP/SSH 포함) 제공
  10. Prometheus 구성 GitLab 환경 모니터링
  11. 객체 리포지터리 구성 공유 데이터 객체를 위해 사용
  12. 고급 검색 구성 (선택 사항) 전체 GitLab 인스턴스에서 더 빠르고 고급 코드 검색을 위해.

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

다음 디렉터리은 각 서버와 해당 지정 IP에 대한 설명을 포함합니다.

  • 10.6.0.10: 외부 로드 밸런서
  • 10.6.0.11: Consul/Sentinel 1
  • 10.6.0.12: Consul/Sentinel 2
  • 10.6.0.13: Consul/Sentinel 3
  • 10.6.0.21: PostgreSQL 주 서버
  • 10.6.0.22: PostgreSQL 보조 서버 1
  • 10.6.0.23: PostgreSQL 보조 서버 2
  • 10.6.0.31: PgBouncer 1
  • 10.6.0.32: PgBouncer 2
  • 10.6.0.33: PgBouncer 3
  • 10.6.0.20: 내부 로드 밸런서
  • 10.6.0.61: Redis 기본
  • 10.6.0.62: Redis 복제본 1
  • 10.6.0.63: Redis 복제본 2
  • 10.6.0.51: Gitaly 1
  • 10.6.0.52: Gitaly 2
  • 10.6.0.93: Gitaly 3
  • 10.6.0.131: Praefect 1
  • 10.6.0.132: Praefect 2
  • 10.6.0.133: Praefect 3
  • 10.6.0.141: Praefect PostgreSQL 1 (HA가 아님)
  • 10.6.0.71: Sidekiq 1
  • 10.6.0.72: Sidekiq 2
  • 10.6.0.41: GitLab 애플리케이션 1
  • 10.6.0.42: GitLab 애플리케이션 2
  • 10.6.0.43: GitLab 애플리케이션 3
  • 10.6.0.81: Prometheus

외부 로드 밸런서 구성

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

어떤 로드 밸런서를 사용해야 하는지 또는 정확한 구성은 GitLab 설명서의 범위를 벗어나지만 로드 밸런서를 참조하여 일반적인 요구 사항에 대한 자세한 정보가 포함되어 있습니다. 이 섹션은 선택한 로드 밸런서에 대해 구체적으로 무엇을 구성해야 하는지에 중점을 둡니다.

운영 준비 확인

외부 로드 밸런서는 내장된 모니터링 엔드포인트로 작동하는 서비스로만 라우팅하도록 보증하는 것이 중요합니다. 준비 확인에는 노드를 확인하는 데 추가 구성이 필요한데, 그렇지 않은 경우 외부 로드 밸런서가 연결할 수 없게 됩니다.

포트

사용할 기본 포트는 아래 표에 표시되어 있습니다.

LB 포트 백엔드 포트 프로토콜
80 80 HTTP (1)
443 443 TCP 또는 HTTPS (1) (2)
22 22 TCP
  • (1): Web terminal 지원에는 로드 밸런서가 WebSocket 연결을 올바르게 처리해야 합니다. HTTP 또는 HTTPS 프록시를 사용할 때, 로드 밸런서는 Connection 및 Upgrade hop-by-hop 헤더를 통과해야 합니다. 자세한 내용은 web terminal 통합 가이드를 참조하세요.
  • (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을 구성할 수 있지만, 그럴 경우 SSL이 종료되지 않게 됩니다.

대체 SSH 포트

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

altssh.gitlab.example.com와 같은 대체 SSH 호스트 이름에 대한 DNS를 구성합니다.

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

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에 구성을 추가해야 합니다. 자세한 내용은 HTTPS 문서를 참조하십시오.

— (중략) —

내부 로드 밸런서 구성

다중 노드 GitLab 구성에서 내부 로드 밸런서가 필요할 수 있습니다. 이는 구성된 경우 PgBouncer에 대한 연결 및 Praefect에 대한 연결과 같이 선택된 내부 구성요소의 트래픽을 경로로 지정하기 위함입니다.

사용할 로드 밸런서의 구체적인 구성이나 사용할 로드 밸런서의 종류는 GitLab 문서의 범위를 벗어나지만 일반적인 요구 사항에 대한 자세한 내용은 로드 밸런서를 참조하십시오. 이 섹션에서는 선택한 로드 밸런서를 구성하는 구체적인 내용에 초점을 맞출 것입니다.

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

  • 10.6.0.40: 내부 로드 밸런서

HAProxy를 사용하여 다음과 같이 수행할 수 있습니다. 

(중략)

추가 지침은 선호하는 로드 밸런서의 문서를 참조하십시오.

— (중략) —

Redis 구성

스케일링 가능한 환경에서 Redis를 사용하는 것은 기본(Primary) x 복제(Replica) 토폴로지를 사용하여 Redis Sentinel 서비스로 감시하고 자동으로 장애 조치를 시작하는 것이 가능합니다.

note
Redis는 홀수 개의 3개 이상의 노드로 멀티 노드 Redis를 배포하여 Redis Sentinel이 과반수의 투표를 받을 수 있도록 해야 합니다. 이는 Redis를 클라우드 제공 업체 서비스와 같이 외부에서 구성하는 경우에 해당되지 않습니다.
note
Redis는 주로 단일 스레드이며 CPU 코어 증가로 큰 이점을 보지 않습니다. 자세한 내용은 스케일링 문서를 참조하십시오.

Sentinel을 사용하는 경우 Redis에 인증이 필요합니다. 자세한 내용은 Redis 보안 문서를 참조하십시오. Redis 서비스를 보호하기 위해 Redis 비밀번호 및 엄격한 방화벽 규칙의 조합을 권장합니다. Redis를 GitLab과 구성하기 전에 토폴로지와 아키텍처를 완전히 이해하려면 Redis Sentinel 문서를 꼭 읽어보시기를 권장합니다.

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

  • 10.6.0.61: Redis 기본
  • 10.6.0.62: Redis 복제본 1
  • 10.6.0.63: Redis 복제본 2

자체 Redis 인스턴스 제공

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

  • 이에 대해 신뢰할 만한 제공업체나 솔루션을 사용해야 합니다. Google Memorystore 및 AWS ElastiCache가 작동한다는 것이 알려져 있습니다.
  • Redis 클러스터 모드는 구체적으로 지원되지 않지만 (Redis Sentinel)이 있는 Redis 스탠드얼론 with HA는 지원됩니다.
  • 설정에 따라서 Redis 삭제 모드를 설정해야 합니다.

자세한 내용은 권장되는 클라우드 제공 업체 및 서비스를 참조하십시오.

Linux 패키지를 사용한 스탠드얼론 Redis

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

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

  1. 모든 Redis 노드는 서로 통신할 수 있어야 하며 Redis(6379) 및 Sentinel(26379) 포트를 통해 들어오는 연결을 수락해야 합니다(기본 포트를 변경하지 않는 한).
  2. GitLab 애플리케이션을 호스팅하는 서버는 Redis 노드에 액세스할 수 있어야 합니다.
  3. 외부 네트워크(인터넷)에서 노드를 보호하기 위해 방화벽을 사용하세요.

기본 및 복제 Redis 노드는 redis['password']에서 정의된 동일한 암호를 가져야 합니다. 장애 조치 중에 Sentinels는 노드를 재구성하고 해당 상태를 기본 또는 복제로 변경할 수 있습니다.

기본 Redis 인스턴스 구성

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

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

    # 서버 역할을 'redis_master_role'로 지정하고 Consul 에이전트를 활성화합니다.
roles(['redis_master_role', 'consul_role'])
   
# 다른 기계들이 연결할 수 있는 로컬 IP를 가리키는 IP 주소
# 모든 인터페이스에서 청취하는 '0.0.0.0'으로도 바인딩할 수 있습니다.
# 외부 액세스 가능한 IP에 바인딩해야 하는 경우,
# 무단 액세스를 방지하기 위해 추가 방화벽 규칙을 추가해야 합니다.
redis['bind'] = '10.6.0.61'
   
# 다른 기계가 연결할 수 있도록 Redis가 TCP 요청을 수신할 수 있는 포트 지정
redis['port'] = 6379
   
# Redis에 대한 암호 인증 설정(모든 노드에 동일한 암호 사용).
redis['password'] = '여기에-redis-암호-입력'
   
## 프로메테우스의 서비스 검색을 활성화
consul['monitoring_service_discovery'] =  true
   
## Consul 서버 노드의 IP
## FQDN을 사용하거나 IP와 혼합하여 사용할 수 있습니다
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
   
# 익스포터가 청취할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'
redis_exporter['flags'] = {
     'redis.addr' => 'redis://10.6.0.61:6379',
     'redis.password' => '여기에-redis-암호-입력',
}
   
# 업그레이드 시 데이터베이스 마이그레이션 자동 실행 방지
gitlab_rails['auto_migrate'] = false

  4. 이전에 구성한 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 동일한 이름의 파일을 추가하거나 교체합니다. 이것이 구성하는 첫 번째 Linux 패키지 노드인 경우, 이 단계를 건너뛰어도 됩니다.

  5. 변경 사항을 적용하려면 GitLab을 다시 구성합니다.

여러 역할을 지정할 수 있습니다. 예를 들어, roles ['redis_sentinel_role', 'redis_master_role']처럼 여러 역할을 지정할 수 있습니다. 역할에 대해 자세히 알아보세요.

shell을 사용하여 현재 Redis Primary, Replica 상태를 볼 수 있습니다: 

/opt/gitlab/embedded/bin/redis-cli -h <host> -a '여기에-redis-암호-입력' info replication

다음을 사용하여 실행 중인 GitLab 서비스를 확인할 수 있습니다: 

gitlab-ctl status

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

run: consul: (pid 30043) 76863s; run: log: (pid 29691) 76892s
run: logrotate: (pid 31152) 3070s; run: log: (pid 29595) 76908s
run: node-exporter: (pid 30064) 76862s; run: log: (pid 29624) 76904s
run: redis: (pid 30070) 76861s; run: log: (pid 29573) 76914s
run: redis-exporter: (pid 30075) 76861s; run: log: (pid 29674) 76896s

복제 Redis 인스턴스 구성

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

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

    # 서버 역할을 'redis_replica_role'로 지정하고 Consul 에이전트를 활성화합니다.
roles(['redis_replica_role', 'consul_role'])
   
# 다른 기계들이 연결할 수 있는 로컬 IP를 가리키는 IP 주소
# 모든 인터페이스에서 청취하는 '0.0.0.0'으로도 바인딩할 수 있습니다.
# 외부 액세스 가능한 IP에 바인딩해야 하는 경우,
# 무단 액세스를 방지하기 위해 추가 방화벽 규칙을 추가해야 합니다.
redis['bind'] = '10.6.0.62'
   
# 다른 기계가 연결할 수 있도록 Redis가 TCP 요청을 수신할 수 있는 포트 지정
redis['port'] = 6379
   
# 기본 노드에 대해 설정한 Redis 인증용 동일한 암호
redis['password'] = '여기에-redis-암호-입력'
   
# 기본 Redis 노드의 IP
redis['master_ip'] = '10.6.0.61'
   
# 기본 Redis 서버의 포트, 기본값은 `6379`입니다. 변경하려면 주석 처리를 제거하세요.
#redis['master_port'] = 6379
   
## 프로메테우스의 서비스 검색을 활성화
consul['monitoring_service_discovery'] =  true
   
## Consul 서버 노드의 IP
## FQDN을 사용하거나 IP와 혼합하여 사용할 수 있습니다
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
   
# 익스포터가 청취할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'
redis_exporter['flags'] = {
     'redis.addr' => 'redis://10.6.0.62:6379',
     'redis.password' => '여기에-redis-암호-입력',
}
   
# 업그레이드 시 데이터베이스 마이그레이션 자동 실행 방지
gitlab_rails['auto_migrate'] = false
  4. 이전에 구성한 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 동일한 이름의 파일을 추가하거나 교체합니다. 이것이 구성하는 첫 번째 Linux 패키지 노드인 경우, 이 단계를 건너뛰어도 됩니다.
  5. 변경 사항을 적용하려면 GitLab을 다시 구성합니다.
  6. 다른 복제 노드에 대해 다시 단계를 진행하고 IP를 올바르게 설정했는지 확인하세요.

roles(['redis_sentinel_role', 'redis_master_role'])와 같이 Sentinel 및 Redis와 같은 여러 역할을 지정할 수 있습니다. 역할에 대해 자세히 알아보세요.

이러한 값들은 Sentinels를 통해 관리될 것이고 장애 조치 후에도 /etc/gitlab/gitlab.rb에서 다시 변경할 필요가 없을 것입니다. 또한 gitlab-ctl reconfigure 후에도 동일한 Sentinels에 의해 구성이 복원될 것입니다.

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

Consul 및 Sentinel 구성

이제 Redis 서버들이 모두 설정되었으므로, Consul + Sentinel 서버를 구성해 보겠습니다.

note
Consul 및 Redis Sentinel은 홀수 개(3개 이상)의 노드에 배포되어야 합니다. 이는 노드가 쿼럼의 일부로서 투표를 할 수 있도록 보장하기 위한 것입니다.

다음과 같은 IP가 예시로 사용될 것입니다:

  • 10.6.0.11: Consul/Sentinel 1
  • 10.6.0.12: Consul/Sentinel 2
  • 10.6.0.13: Consul/Sentinel 3
note
외부 Redis Sentinel 인스턴스를 사용하는 경우 Sentinel 구성에서 requirepass 매개변수를 제외해야 합니다. 이 매개변수는 클라이언트가 NOAUTH Authentication required.를 보고하도록 합니다. Redis Sentinel 3.2.x에서는 비밀번호 인증이 지원되지 않습니다.

Sentinel을 구성하려면:

  1. Consul/Sentinel을 호스팅할 서버에 SSH로 로그인합니다.
  2. 원하는 Linux 패키지를 다운로드하고 설치합니다. 페이지에서 설치 단계 1과 2 만 따르고 현재 설치된 버전과 유형(Community 또는 Enterprise 에디션)과 동일한 올바른 Linux 패키지를 선택했는지 확인하세요.

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

    roles(['redis_sentinel_role', 'consul_role'])
   
# 모든 Sentinel 노드에서 동일해야 함
redis['master_name'] = 'gitlab-redis'
   
# 기본 노드에 설정한 Redis 인증용 동일한 비밀번호
redis['master_password'] = '여기에 Redis 비밀번호 입력'
   
# 주요 Redis 노드의 IP
redis['master_ip'] = '10.6.0.61'
   
# 다른 기계가 연결할 수 있도록 레디스가 TCP 요청을 수신하도록하는 포트 정의
redis['port'] = 6379
   
# 기본 Redis 서버의 포트, 비정상일 경우 변경해야 함. 기본값은 `6379`.
#redis['master_port'] = 6379
   
## Sentinel 구성
sentinel['bind'] = '10.6.0.11'
   
# Sentinel이 수신하는 포트, 비정상일 경우 변경해야 함. 기본값은 `26379`.
# sentinel['port'] = 26379
   
## 쿼럼은 장애 조치(FAILOVER)를 시작하는 데 필요한 투표 Sentinels의 수를 반영해야 합니다.
## 값은 Sentinels의 수보다 커서는 안됩니다.
##
## 쿼럼은 두 가지 방법으로 Sentinel을 조정할 수 있습니다:
## 1. Sentinels의 과반수보다 작은 값을 쿼럼으로 설정하면 기본 장애에 Sentinel을 쉽게 반응시킵니다.
##    심지어 Sentinels의 소수가 기본과 대화를 할 수 없을 때라도 장애 조치를 즉시 트리거합니다.
## 1. 쿼럼을 Sentinels의 과반수보다 큰 값으로 설정하면 Sentinels의 매우 큰 수(다수보다 큰 수)가
##    기본의 다운에 동의하는 경우에만 Sentinel이 장애 조치를 수행할 수 있습니다.
sentinel['quorum'] = 2
   
## 지정한 시간(ms) 이후 응답하지 않는 서버를 다운으로 간주합니다.
# sentinel['down_after_milliseconds'] = 10000
   
## 밀리초 단위의 FAILOVER 타임아웃 지정
## - 동일한 기본에 대해 이전 FAILOVER에 대한 다음 FAILOVER를 재시작하는 데 걸리는 시간은
sentinel['failover_timeout'] = 60000
   
## Prometheus를 위한 서비스 검색 활성화
consul['monitoring_service_discovery'] =  true
   
## Consul 서버 노드들의 IP
## FQDN도 사용할 수 있으며 IP와 혼용하여 사용할 수 있습니다.
consul['configuration'] = {
   server: true,
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
   
# Exporter가 수신 대기할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'
   
# 업그레이드 시 자동으로 데이터베이스 마이그레이션을 실행하지 않도록 함
gitlab_rails['auto_migrate'] = false

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

  5. 변경 사항이 적용되도록 GitLab을 다시 구성하세요.

  6. 다른 Consul/Sentinel 노드 모두에 대해 위 단계를 다시 진행하고 올바른 IP를 설정했는지 확인하세요.

Consul 리더는 세 번째 Consul 서버의 프로비저닝이 완료되면 _선출(elected)_됩니다. Consul 로그 sudo gitlab-ctl tail consul을 보면 ...[INFO] consul: New leader elected: ...가 표시됩니다.

현재 Consul 멤버(서버, 클라이언트)를 나열할 수 있습니다: 

sudo /opt/gitlab/embedded/bin/consul members

GitLab 서비스가 실행 중인지 확인할 수 있습니다: 

sudo gitlab-ctl status

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

run: consul: (pid 30074) 76834s; run: log: (pid 29740) 76844s
run: logrotate: (pid 30925) 3041s; run: log: (pid 29649) 76861s
run: node-exporter: (pid 30093) 76833s; run: log: (pid 29663) 76855s
run: sentinel: (pid 30098) 76832s; run: log: (pid 29704) 76850s

PostgreSQL 구성

이 섹션에서는 GitLab과 함께 사용할 고가용성 PostgreSQL 클러스터를 구성하는 과정을 안내합니다.

독자의 PostgreSQL 인스턴스 제공

선택적으로 PostgreSQL을 위한 서드파티 외부 서비스를 사용할 수 있습니다.

이를 위해 신뢰할 수 있는 제공 업체 또는 솔루션을 사용해야 합니다. Google Cloud SQL과 Amazon RDS가 잘 작동하는 것으로 알려져 있습니다. 그러나 Amazon Aurora는 기본적으로 14.4.0부터 로드 밸런싱을 지원하지 않으므로 호환되지 않습니다. 자세한 내용은 권장 클라우드 제공 업체 및 서비스를 참조하세요.

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

  1. PostgreSQL HA Linux 패키지 설정에는 PostgreSQL, PgBouncer 및 Consul이 모두 더 이상 필요하지 않습니다.
  2. 데이터베이스 요구 사항 문서에 따라 PostgreSQL을 설정합니다.
  3. 원하는 비밀번호로 gitlab 사용자를 설정합니다. gitlab 사용자는 gitlabhq_production 데이터베이스를 생성할 수 있는 권한이 필요합니다.
  4. 적절한 세부 정보로 GitLab 응용 프로그램 서버를 구성합니다. 이 단계는 GitLab Rails 응용 프로그램 구성에서 다루고 있습니다.
  5. 서비스에 필요한 노드 수는 Linux 패키지와 달리 서드파티 서비스에 따라 다를 수 있으며, 일치시킬 필요가 없습니다.
  6. 그러나 Read Replicas를 통한 데이터베이스 로드 밸런싱을 통해 성능 향상을 위해 추가 노드 수를 따르는 것이 좋습니다.

단독 PostgreSQL에는 Linux 패키지를 사용합니다.

추천되는 Linux 패키지 구성으로는 복제 및 장애 조치가 포함된 PostgreSQL 클러스터를 위해 다음이 필요합니다.

  • 최소 세 개의 PostgreSQL 노드.
  • 최소 세 개의 Consul 서버 노드.
  • 주 데이터베이스 읽기 및 쓰기를 추적하고 처리하는 최소 세 개의 PgBouncer 노드.
  • 데이터베이스 로드 밸런싱 활성화.

각 PostgreSQL 노드에는 별도로 구성된 로컬 PgBouncer 서비스가 있어야 합니다. 이는 주요 부분을 추적하는 본 PgBouncer 클러스터와 별도입니다.

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

  • 10.6.0.21: PostgreSQL 프라이머리
  • 10.6.0.22: PostgreSQL 세컨더리 1
  • 10.6.0.23: PostgreSQL 세컨더리 2

먼저, 각 노드에 Linux GitLab 패키지를 설치합니다. 그 후 단계를 따라 필요한 의존성을 설치하고, 단계 2에서 GitLab 패키지 리포지터리를 추가합니다. 두 번째 단계에서는 EXTERNAL_URL 값은 제공하지 않습니다.

PostgreSQL 노드

  1. PostgreSQL 노드 중 하나에 SSH로 로그인합니다.

  2. PostgreSQL 사용자명/암호 쌍에 대한 암호 해시를 생성합니다. 여기서는 기본 사용자명 gitlab (권장)을 사용한다고 가정합니다. 명령은 암호와 확인을 요청할 것입니다. 이 명령의 출력 값을 다음 단계에서 <postgresql_password_hash>의 값으로 사용하세요: 

    sudo gitlab-ctl pg-password-md5 gitlab

  3. PgBouncer 사용자명/암호 쌍에 대한 암호 해시를 생성합니다. 여기서는 기본 사용자명 pgbouncer (권장)을 사용한다고 가정합니다. 명령은 암호와 확인을 요청할 것입니다. 이 명령의 출력 값을 다음 단계에서 <pgbouncer_password_hash>의 값으로 사용하세요: 

    sudo gitlab-ctl pg-password-md5 pgbouncer

  4. PostgreSQL 복제 사용자명/암호 쌍에 대한 암호 해시를 생성합니다. 여기서는 기본 사용자명 gitlab_replicator (권장)을 사용한다고 가정합니다. 명령은 암호와 확인을 요청할 것입니다. 이 명령의 출력 값을 다음 단계에서 <postgresql_replication_password_hash>의 값으로 사용하세요: 

    sudo gitlab-ctl pg-password-md5 gitlab_replicator

  5. Consul 데이터베이스 사용자명/암호 쌍에 대한 암호 해시를 생성합니다. 여기서는 기본 사용자명 gitlab-consul (권장)을 사용한다고 가정합니다. 명령은 암호와 확인을 요청할 것입니다. 이 명령의 출력 값을 다음 단계에서 <consul_password_hash>의 값으로 사용하세요: 

    sudo gitlab-ctl pg-password-md5 gitlab-consul

  6. 모든 데이터베이스 노드에서 /etc/gitlab/gitlab.rb 파일을 편집하여 # START user configuration 섹션에 있는 값들을 변경합니다: 

    # Patroni, PgBouncer 및 Consul만 사용하도록 모든 컴포넌트를 비활성화합니다.
roles(['patroni_role', 'pgbouncer_role'])
   
# PostgreSQL 구성
postgresql['listen_address'] = '0.0.0.0'
   
# `max_replication_slots`를 데이터베이스 노드 수의 두 배로 설정합니다.
# Patroni는 복제를 초기화할 때 노드당 하나의 추가 슬롯을 사용합니다.
patroni['postgresql']['max_replication_slots'] = 6
   
# `max_wal_senders`를 클러스터의 복제 슬롯 수보다 하나 더 설정합니다.
# 이는 복제가 사용 가능한 모든 데이터베이스 연결을 소진하는 것을 방지하기 위한 것입니다.
patroni['postgresql']['max_wal_senders'] = 7
   
# 업그레이드 시 자동으로 데이터베이스 마이그레이션을 실행하는 것을 방지합니다.
gitlab_rails['auto_migrate'] = false
   
# Consul 에이전트 구성
consul['services'] = %w(postgresql)
## Prometheus를 위한 서비스 검색 활성화
consul['monitoring_service_discovery'] =  true
   
# START user configuration
# 필수 정보 섹션에서 설명한 대로 실제 값을 설정하세요
#
# PGBOUNCER_PASSWORD_HASH를 생성된 md5 값으로 바꿉니다
postgresql['pgbouncer_user_password'] = '<pgbouncer_password_hash>'
# POSTGRESQL_REPLICATION_PASSWORD_HASH를 생성된 md5 값으로 바꿉니다
postgresql['sql_replication_password'] = '<postgresql_replication_password_hash>'
# POSTGRESQL_PASSWORD_HASH를 생성된 md5 값으로 바꿉니다
postgresql['sql_user_password'] = '<postgresql_password_hash>'
   
# Patroni API에 기본 인증 설정 (모든 노드에서 동일한 사용자명/암호를 사용하세요).
patroni['username'] = '<patroni_api_username>'
patroni['password'] = '<patroni_api_password>'
   
# 네트워크 주소를 설정합니다. (모니터링을 위해 익스포터가 수신 대기하는 주소)
postgresql['trust_auth_cidr_addresses'] = %w(10.6.0.0/24 127.0.0.1/32)
   
# 데이터베이스 로드 밸런싱을 위한 로컬 PgBouncer 서비스
pgbouncer['databases'] = {
   gitlabhq_production: {
      host: "127.0.0.1",
      user: "pgbouncer",
      password: '<pgbouncer_password_hash>'
   }
}
   
# 모니터링을 위해 익스포터가 수신 대기하는 네트워크 주소를 설정합니다.
node_exporter['listen_address'] = '0.0.0.0:9100'
postgres_exporter['listen_address'] = '0.0.0.0:9187'
   
## Consul 서버 노드의 IP
## FQDN을 사용하거나 IP와 혼합하여 사용할 수 있습니다
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
#
# END user configuration

    PostgreSQL은 장애 조치를 관리하는 Patroni를 사용하여 충돌을 처리하기 위해 기본적으로 pg_rewind를 사용합니다. 대부분의 장애 조치 처리 방법과 마찬가지로, 이 방법에는 데이터 손실 가능성이 약간 존재합니다. 자세한 내용은 다양한 Patroni 복제 방법을 참조하세요.

  7. 처음 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 동일한 이름의 파일을 추가하거나 교체합니다. 이것이 처음 구성 중인 Linux 패키지 노드이면 이 단계를 건너뛸 수 있습니다.

  8. 변경 사항이 적용되도록 GitLab을 다시 구성합니다.

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

PostgreSQL 구성 후

프라이머리 사이트의 Patroni 노드 중 하나에 SSH로 로그인합니다.

  1. 리더 및 클러스터 상태를 확인합니다: 

    gitlab-ctl patroni members

    다음과 유사한 출력이어야 합니다. 

    | Cluster       | Member                            |  Host     | Role   | State   | TL  | Lag in MB | Pending restart |
|---------------|-----------------------------------|-----------|--------|---------|-----|-----------|-----------------|
| postgresql-ha | <PostgreSQL primary hostname>     | 10.6.0.21 | Leader | running | 175 |           | *               |
| postgresql-ha | <PostgreSQL secondary 1 hostname> | 10.6.0.22 |        | running | 175 | 0         | *               |
| postgresql-ha | <PostgreSQL secondary 2 hostname> | 10.6.0.23 |        | running | 175 | 0         | *               |

    어떤 노드의 ‘State’ 열이 “running”이 아니면, 계속 진행하기 전에 PostgreSQL 복제 및 장애 조치 문제 해결 섹션을 확인하세요.

PgBouncer 구성

이제 PostgreSQL 서버가 모두 설정되었으므로 주 창고에 대한 읽기/쓰기를 추적하고 처리하기 위해 PgBouncer를 구성해 봅시다.

note
PgBouncer는 싱글 스레드이며 CPU 코어가 증가함에 따라 혜택을 거의 받지 않습니다. 자세한 내용은 스케일링 문서를 참조하세요.

다음 IP 주소는 예시로 사용됩니다:

  • 10.6.0.31: PgBouncer 1
  • 10.6.0.32: PgBouncer 2
  • 10.6.0.33: PgBouncer 3

  1. 각 PgBouncer 노드에서 /etc/gitlab/gitlab.rb를 편집하고 <consul_password_hash>와 <pgbouncer_password_hash>를 이전에 설정한 비밀번호 해시로 대체하세요: 

    # Pgbouncer 및 Consul 에이전트를 제외한 모든 구성요소 비활성화
roles(['pgbouncer_role'])
   
# PgBouncer 구성
pgbouncer['admin_users'] = %w(pgbouncer gitlab-consul)
pgbouncer['users'] = {
   'gitlab-consul': {
      password: '<consul_password_hash>'
   },
   'pgbouncer': {
      password: '<pgbouncer_password_hash>'
   }
}
   
# Consul 에이전트 구성
consul['watchers'] = %w(postgresql)
consul['configuration'] = {
retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}
   
# Prometheus를 위한 서비스 검색 활성화
consul['monitoring_service_discovery'] = true
   
# 익스포터가 청취할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
pgbouncer_exporter['listen_address'] = '0.0.0.0:9188'

  2. 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 동일한 이름의 파일을 추가하거나 대체하세요. 이것이 구성 중인 첫 번째 Linux 패키지 노드인 경우 이 단계를 건너뛸 수 있습니다.

  3. 변경 사항이 적용되려면 GitLab을 다시 구성하세요.

  4. Consul이 PgBouncer를 다시로드할 수 있도록 .pgpass 파일을 만듭니다. 묻힐 때 PgBouncer 비밀번호를 두 번 입력하세요: 

    gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul

  5. 각 노드가 현재 마스터에 연결되었는지 확인하세요: 

    gitlab-ctl pgb-console # PGBOUNCER_PASSWORD를 입력해야 합니다

    비밀번호를 입력한 후 오류 psql: ERROR: Auth failed가 발생하면 이전에 올바른 형식으로 MD5 비밀번호 해시를 생성했는지 확인하세요. 올바른 형식은 비밀번호와 사용자 이름을 연결하는 것입니다: PASSWORDUSERNAME. 예를들어 Sup3rS3cr3tpgbouncer는 pgbouncer 사용자의 MD5 비밀번호 해시를 생성하는 데 필요한 텍스트입니다.

  6. 콘솔 프롬프트를 사용할 수 있는 경우 다음 쿼리를 실행하세요: 

    show databases ; show clients ;

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

            name         |  host       | port |      database       | force_user | pool_size | reserve_pool | pool_mode | max_connections | current_connections
---------------------+-------------+------+---------------------+------------+-----------+--------------+-----------+-----------------+---------------------
 gitlabhq_production | MASTER_HOST | 5432 | gitlabhq_production |            |        20 |            0 |           |               0 |                   0
 pgbouncer           |             | 6432 | pgbouncer           | pgbouncer  |         2 |            0 | statement |               0 |                   0
(2 rows)
    
 type |   user    |      database       |  state  |   addr         | port  | local_addr | local_port |    connect_time     |    request_time     |    ptr    | link | remote_pid | tls
------+-----------+---------------------+---------+----------------+-------+------------+------------+---------------------+---------------------+-----------+------+------------+-----
 C    | pgbouncer | pgbouncer           | active  | 127.0.0.1      | 56846 | 127.0.0.1  |       6432 | 2017-08-21 18:09:59 | 2017-08-21 18:10:48 | 0x22b3880 |      |          0 |
(2 rows)

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

    sudo gitlab-ctl status

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

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

Gitaly 클러스터 구성

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

caution
Gitaly 사양은 사용 패턴과 리포지터리 크기의 높은 백분위 수에 기반합니다. 그러나 대형 모노 리포지터리(여러 기가바이트보다 큼)나 추가 워크로드가 있는 경우 환경 성능에 상당한 영향을 줄 수 있습니다. 이 경우, 연결된 문서를 참고하거나 고객 성공 관리자 또는 지원팀에 문의하여 추가 지침을 얻는 것이 강력히 권장됩니다.

Gitaly 클러스터는 고장 허용성의 장점을 제공하지만 구성 및 관리의 추가 복잡성을 가지고 있습니다. Gitaly 클러스터 배포 전 기술적 한계 및 고려 사항을 검토하세요.

참고용: - 분리된 Gitaly 클러스터 문서 대신 셰딩된 Gitaly를 구현하는 경우 동일한 Gitaly 사양을 사용하세요. - Gitaly 클러스터에서 관리되지 않는 기존 리포지터리를 마이그레이션하려면 Gitaly 클러스터로 마이그레이션을 참조하세요.

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

  • 3개의 Gitaly 노드: Git 리포지터리의 복제된 리포지터리.
  • 3개의 Praefect 노드: Gitaly 클러스터의 라우터 및 트랜잭션 관리자.
  • 1개의 Praefect PostgreSQL 노드: Praefect에 대한 데이터베이스 서버. Praefect 데이터베이스 연결을 고도로 사용 가능하게 하려면 제3자 솔루션이 필요합니다.
  • 1개의 로드 밸런서: Praefect에 대해 로드 밸런서가 필요합니다. 내부 로드 밸런서가 사용됩니다.

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

Praefect PostgreSQL 구성

Praefect는 Gitaly Cluster용 라우팅 및 트랜잭션 관리자이며, Gitaly Cluster 상태에 대한 데이터를 저장하기 위해 자체 데이터베이스 서버가 필요합니다.

고가용성 설정을 원하는 경우 Praefect에는 타사 PostgreSQL 데이터베이스가 필요합니다. 내장 솔루션은 작업 중입니다.

Praefect 비-HA PostgreSQL 독립형 Linux 패키지 사용

다음 IP들은 예시로 사용될 것입니다:

  • 10.6.0.141: Praefect PostgreSQL

먼저, Praefect PostgreSQL 노드에 Linux GitLab 패키지를 설치합니다. 단계를 따라 진행하여 1단계에서 필요한 종속 항목을 설치하고, 2단계에서 GitLab 패키지 리포지터리를 추가합니다. 2단계에서 GitLab을 설치할 때 EXTERNAL_URL 값을 제공하지 않도록 주의하세요.

  1. Praefect PostgreSQL 노드에 SSH로 로그인합니다.
  2. Praefect PostgreSQL 사용자에 사용할 강력한 암호를 생성합니다. 이 암호는 <praefect_postgresql_password>로 지정하고 이를 기록해 놓습니다.

  3. Praefect PostgreSQL 사용자/암호 쌍에 대한 암호 해시를 생성합니다. 이 명령은 기본 사용자 이름이 praefect라고 가정합니다(권장). 명령은 암호 <praefect_postgresql_password>와 확인을 요청할 것입니다. 이 명령이 출력하는 값은 다음 단계에서 <praefect_postgresql_password_hash> 값으로 사용됩니다. 

    sudo gitlab-ctl pg-password-md5 praefect

  4. /etc/gitlab/gitlab.rb 파일을 편집하여 # START user configuration 섹션에 기록된 값을 교체합니다: 

    # PostgreSQL 및 Consul 외의 모든 컴포넌트 비활성화
roles(['postgres_role', 'consul_role'])
   
# PostgreSQL 구성
postgresql['listen_address'] = '0.0.0.0'
   
# 업그레이드 시 자동으로 데이터베이스 마이그레이션을 방지합니다
gitlab_rails['auto_migrate'] = false
   
# Consul 에이전트 구성
## Prometheus용 서비스 검색 활성화
consul['monitoring_service_discovery'] =  true
   
# START user configuration
# Please set the real values as explained in Required Information section
#
# Replace PRAEFECT_POSTGRESQL_PASSWORD_HASH with a generated md5 value
postgresql['sql_user_password'] = "<praefect_postgresql_password_hash>"
   
# Replace XXX.XXX.XXX.XXX/YY with Network Address
postgresql['trust_auth_cidr_addresses'] = %w(10.6.0.0/24 127.0.0.1/32)
   
# 모니터링을 위해 수신 할 IP 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
postgres_exporter['listen_address'] = '0.0.0.0:9187'
   
## Consul 서버 노드의 IP
## FQDN을 사용할 수도 있으며 IP와 혼용할 수도 있습니다
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
#
# END user configuration

  5. 이전에 구성한 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버에 같은 이름의 파일을 추가하거나 교체합니다. 이것이 구성한 첫 번째 Linux 패키지 노드인 경우 이 단계를 건너뛰어도 됩니다.

  6. 변경 사항이 적용되려면 GitLab을 재구성하기 위해 리컨피그를 실행합니다.
  7. 포스트 구성 단계를 따릅니다.

Praefect HA PostgreSQL 타사 솔루션

Praefect PostgreSQL 구성에서 언급한 대로 고가용성을 원한다면 Praefect의 데이터베이스에 대해 타사 PostgreSQL 솔루션이 권장됩니다.

PostgreSQL HA에 대한 많은 타사 솔루션이 있습니다. Praefect와 작동하려면 다음이 필요합니다:

  • 장애 조치(Failover) 시 변경되지 않는 모든 연결에 대한 정적 IP
  • LISTEN SQL 기능이 지원되어야 함
note
타사 설정을 사용하면 별도의 데이터베이스 인스턴스가 Geo를 사용하지 않는 한 기본 GitLab 데이터베이스와 동일한 서버에 Praefect의 데이터베이스를 혼합할 수 있습니다. 이런 설정에서는 주요 데이터베이스 설정 사양을 변경할 필요가 없어야 하고 영향은 최소화되어야 합니다.

신뢰할 수 있는 제공 업체나 솔루션을 사용해야 합니다. Google Cloud SQL 및 Amazon RDS가 작동하는 것으로 알려져 있습니다. 그러나 Amazon Aurora는 14.4.0에서 기본적으로 로드 밸런싱이 사용된 상태에서 호환되지 않습니다. 자세한 내용은 추천 클라우드 제공 업체 및 서비스를 참조하십시오.

데이터베이스를 설정한 후, 포스트 구성 단계를 따릅니다.

Praefect PostgreSQL 포스트 구성

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

사용자의 이름은 praefect로, 데이터베이스의 이름은 praefect_production으로 권장합니다. 이러한 것들은 PostgreSQL에서 표준적으로 구성될 수 있습니다. 사용자의 암호는 이전에 <praefect_postgresql_password>로 구성한 것과 같습니다.

Linux 패키지 PostgreSQL 설정을 사용하는 경우 다음과 같이 진행됩니다:

  1. Praefect PostgreSQL 노드에 SSH로 로그인합니다.

  2. PostgreSQL 서버에 관리 액세스로 연결합니다. Linux 패키지에서 기본적으로 추가되는 gitlab-psql 사용자를 여기에 사용해야 합니다. 데이터베이스 template1는 모든 PostgreSQL 서버에 기본적으로 생성되기 때문에 여기에 사용됩니다. 

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

  3. 암호를 변경하여 새 사용자 praefect를 만듭니다. <praefect_postgresql_password>를 교체합니다: 

    CREATE ROLE praefect WITH LOGIN CREATEDB PASSWORD '<praefect_postgresql_password>';

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

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

  5. 새 데이터베이스 praefect_production을 만듭니다: 

    CREATE DATABASE praefect_production WITH ENCODING=UTF8;

Praefect 구성

Praefect는 Gitaly Cluster의 라우터 및 트랜잭션 관리자이며, Gitaly로의 모든 연결이 이를 거칩니다. 이 섹션에는 Praefect를 구성하는 방법에 대한 내용이 포함되어 있습니다.

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

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

  • <praefect_external_token>: Gitaly 클러스터에 호스팅된 리포지터리에 사용되며, 이 토큰을 가진 Gitaly 클라이언트만 액세스할 수 있습니다.
  • <praefect_internal_token>: Gitaly 클러스터 내에서 복제 트래픽에 사용됩니다. 이는 praefect_external_token과 구분되며, Gitaly 클라이언트는 Praefect 클러스터의 내부 노드에 직접 액세스해서는 안 됩니다. 그렇게 하면 데이터 손실이 발생할 수 있습니다.
  • <praefect_postgresql_password>: 이전 섹션에서 정의한 Praefect PostgreSQL 암호가 이 구성에 필요합니다.

Gitaly 클러스터 노드는 가상 리포지터리를 통해 Praefect에서 구성됩니다. 각 리포지터리에는 클러스터를 구성하는 각 Gitaly 노드에 대한 세부 정보가 포함됩니다. 각 리포지터리에는 이름이 지정되며, 이 이름은 구성의 여러 영역에서 사용됩니다. 이 가이드에서는 리포지터리 이름을 default로 할 것이며, 기존 환경을 Gitaly 클러스터 사용으로 업그레이드하는 경우 다른 이름을 사용해야 할 수도 있습니다. 자세한 정보는 Praefect documentation을 참조하십시오.

다음 IP들은 예시로 사용될 것입니다:

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

Praefect 노드를 구성하려면 다음을 각각의 노드에서 수행합니다:

  1. Praefect 서버에 SSH로 로그인합니다.
  2. 적합한 Linux 패키지를 다운로드하고 설치합니다. 페이지의 설치 단계 1 및 2만을 따르도록 주의하십시오.

  3. Praefect를 구성하기 위해 /etc/gitlab/gitlab.rb 파일을 편집합니다:

    caution
    GitLab에 필요로 virtual_storage의 default 항목을 제거할 수 없습니다.
    # Praefect 서버에서 불필요한 서비스 실행 방지
gitaly['enable'] = false
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
gitlab_exporter['enable'] = false
gitlab_kas['enable'] = false
   
# Praefect Configuration
praefect['enable'] = true
   
# Prevent database migrations from running on upgrade automatically
praefect['auto_migrate'] = false
gitlab_rails['auto_migrate'] = false
   
# Configure the Consul agent
consul['enable'] = true
## Enable service discovery for Prometheus
consul['monitoring_service_discovery'] = true
   
# START user configuration
# Please set the real values as explained in Required Information section
#
   
praefect['configuration'] = {
   # ...
   listen_addr: '0.0.0.0:2305',
   auth: {
     # ...
     #
     # Praefect External Token
     # 이는 Praefect 클러스터와 통신하기 위해 클러스터 외부에서(예: GitLab Shell) 필요합니다
     token: '<praefect_external_token>',
   },
   # Praefect Database Settings
   database: {
     # ...
     host: '10.6.0.141',
     port: 5432,
     # `no_proxy` 설정은 캐싱을 위해 항상 직접 연결이어야 합니다
     session_pooled: {
        # ...
        host: '10.6.0.141',
        port: 5432,
        dbname: 'praefect_production',
        user: 'praefect',
        password: '<praefect_postgresql_password>',
     },
   },
   # Praefect Virtual Storage config
   # 이름 해시는 GitLab의 git_data_dirs('praefect') 및 Gitaly 노드('gitaly-1')에서 사용되는 리포지터리 이름과 일치해야 합니다
   virtual_storage: [
      {
         # ...
         name: 'default',
         node: [
            {
               storage: 'gitaly-1',
               address: 'tcp://10.6.0.91:8075',
               token: '<praefect_internal_token>'
            },
            {
               storage: 'gitaly-2',
               address: 'tcp://10.6.0.92:8075',
               token: '<praefect_internal_token>'
            },
            {
               storage: 'gitaly-3',
               address: 'tcp://10.6.0.93:8075',
               token: '<praefect_internal_token>'
            },
         ],
      },
   ],
   # 모니터링을 위해 Praefect가 수신 대기할 네트워크 주소를 설정합니다
   prometheus_listen_addr: '0.0.0.0:9652',
}
   
# 모니터링을 위해 노드 익스포터가 수신 대기할 네트워크 주소를 설정합니다
node_exporter['listen_address'] = '0.0.0.0:9100'
   
## Consul 서버 노드의 IP
## FQDN을 사용할 수도 있으며 IP와 혼용할 수도 있습니다
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
#
# END user configuration

  4. 이전에 구성한 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버에 같은 이름의 파일을 추가하거나 교체합니다. 이것이 구성한 첫 번째 Linux 패키지 노드인 경우 이 단계를 건너뛰어도 됩니다.

  5. Praefect는 메인 Git

Gitaly 구성

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

caution
Gitaly 사양은 사용 패턴 및 리포지터리 크기의 상위 백분위 수에 기반합니다. 그러나 대규모 단일 리포(여러 기가바이트보다 큼) 또는 추가 워크로드가 있으면 환경의 성능에 큰 영향을 미칠 수 있으며 추가 조정이 필요할 수 있습니다. 이 경우 연결된 문서를 참조하거나 더 많은 지침을 얻기 위해 고객 성공 관리자 또는 지원팀에 문의하는 것이 강력히 권장됩니다.

Gitaly가 상당한 입력 및 출력 요구 사항이 있으므로, 모든 Gitaly 노드에서는 SSD(Solid-State Drive)를 사용하는 것이 강력히 권장됩니다. 이러한 SSD는 읽기 작업에 대해 초당 8,000개의 입/출력 작업(IOPS) 및 쓰기 작업에 대해 2,000개의 IOPS 이상의 처리량을 가져야 합니다. 환경을 클라우드 제공 업체에서 실행 중이라면, 올바른 IOPS를 구성하는 방법에 대해서는 해당 제공 업체의 문서를 참조하십시오.

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

Gitaly를 구성할 때 다음을 고려해야 합니다:

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

다음 IP 주소가 예시로 사용될 것입니다:

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

각 노드에서:

  1. 선택한 Linux 패키지를 다운로드하고 설치하십시오. 페이지의 설치 단계 1과 2만 따르고 EXTERNAL_URL 값을 제공하지 않도록 주의하십시오.

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

    # Gitaly 서버에서 불필요한 서비스 실행 방지
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
gitlab_exporter['enable'] = false
gitlab_kas['enable'] = false
   
# 업그레이드 시 데이터베이스 마이그레이션 자동 실행 방지
gitlab_rails['auto_migrate'] = false
   
# Gitaly
gitaly['enable'] = true
   
# gitlab-shell API 콜백 URL 구성. 이를 설정하지 않으면 `git push`가 실패합니다. 'front door' GitLab URL 또는 내부 로드 밸런서가 될 수 있습니다.
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
   
# Consul 에이전트 구성
consul['enable'] = true
## Prometheus를 위한 서비스 탐색 활성화
consul['monitoring_service_discovery'] = true
   
# START 사용자 구성
# 필수 정보 섹션에서 설명한 대로 실제 값 설정
#
## Consul 서버 노드의 IP
## FQDN을 사용하거나 IP와 섞어서 사용할 수도 있습니다.
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
   
# 모니터링을 위해 node exporter가 청취하는 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
   
gitaly['configuration'] = {
   # ...
   #
   # Gitaly가 모든 네트워크 인터페이스에서 연결을 수락하도록 구성합니다. 이 주소/포트로의 액세스를 제한하려면 방화벽을 사용해야 합니다.
   # TLS 연결만 지원하려면 다음 줄을 주석 처리하십시오.
   listen_addr: '0.0.0.0:8075',
   # 모니터링을 위해 Gitaly가 청취하는 네트워크 주소 설정
   prometheus_listen_addr: '0.0.0.0:9236',
   # Gitaly 인증 토큰
   # praefect_internal_token과 동일해야 합니다
   auth: {
      # ...
      token: '<praefect_internal_token>',
   },
   # Gitaly Pack-objects 캐시
   # 성능 향상을 위해 활성화하는 것이 권장되지만 디스크 I/O를 상당히 높일 수 있습니다.
   # 자세한 내용은 https://docs.gitlab.com/ee/administration/gitaly/configure_gitaly.html#pack-objects-cache를 참조하십시오.
   pack_objects_cache: {
      # ...
      enabled: true,
   },
}
   
#
# END 사용자 구성
  3. 각각의 서버에 다음을 /etc/gitlab/gitlab.rb에 추가하십시오:

    • Gitaly 노드 1: 

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

    • Gitaly 노드 2: 

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

    • Gitaly 노드 3: 

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

  4. 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 동일한 이름의 파일을 추가하거나 교체하십시오. 이것이 구성하는 첫 번째 Linux 패키지 노드인 경우 이 단계를 건너뛸 수 있습니다.

  5. 파일을 저장한 후 GitLab을 재구성하십시오.

Gitaly 클러스터 TLS 지원

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

  • GitLab 구성에서 대응하는 리포지터리 항목의 gitaly_address에 tls:// URL scheme을 사용하십시오.
  • 자동으로 제공되지 않으므로 자체 인증서를 사용하십시오. 각 Praefect 서버에 해당하는 인증서를 설치해야 합니다.

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

다음을 참고하십시오:

  • 인증서는 Praefect 서버에 액세스하는 데 사용하는 주소를 지정해야 합니다. 호스트 이름 또는 IP 주소를 인증서의 대체 주체 이름으로 추가해야 합니다.
  • Praefect 서버를 암호화되지 않은 청취 주소 listen_addr와 암호화된 청취 주소 tls_listen_addr 둘 다 구성할 수 있습니다. 필요한 경우, 암호화되지 않은 트래픽에서 암호화된 트래픽으로 천천히 전환할 수 있도록 합니다. 암호화되지 않은 청취 주소를 비활성화하려면 praefect['configuration'][:listen_addr] = nil을 설정하십시오.
  • 내부 로드 밸런서도 인증서에 액세스하고 TLS 직통(passthrough)을 허용하도록 구성해야 합니다. 이에 대한 구성 방법은 로드 밸런서 문서를 참조하십시오.

TLS로 Praefect를 구성하려면 다음을 수행하십시오:

  1. Praefect 서버에 대한 인증서를 생성하십시오.

  2. Praefect 서버에서 /etc/gitlab/ssl 디렉터리를 생성하고 키 및 인증서를 복사하십시오: 

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

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

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

  4. 파일을 저장한 후 재구성하십시오.

  5. Praefect 클라이언트(각 Gitaly 서버 포함)에서 인증서 또는 해당 인증서 기관을 /etc/gitlab/trusted-certs에 복사하십시오: 

    sudo cp cert.pem /etc/gitlab/trusted-certs/

  6. Praefect 클라이언트(Gitaly 서버 제외)에서 /etc/gitlab/gitlab.rb의 git_data_dirs를 다음과 같이 편집하십시오: 

    git_data_dirs({
  "default" => {
    "gitaly_address" => 'tls://LOAD_BALANCER_SERVER_ADDRESS:3305',
    "gitaly_token" => 'PRAEFECT_EXTERNAL_TOKEN'
  }
})

  7. 파일을 저장한 후 GitLab을 재구성하십시오.

Sidekiq 구성

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

note
데이터 객체에 대해 NFS 대신 Object Storage를 사용하는 것이 추천되므로, 다음 예제에는 Object Storage 구성이 포함됩니다.
note
환경의 Sidekiq 작업 처리가 오랜 대기열로 느리다고 판단되면 이에 맞게 확장할 수 있습니다. 자세한 내용은 확장 문서를 참조하세요.

다음 IP 주소가 예시로 사용될 것입니다:

  • 10.6.0.71: Sidekiq 1
  • 10.6.0.72: Sidekiq 2

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

  1. Sidekiq 서버에 SSH로 로그인합니다.
  2. 선택한 Linux 패키지를 다운로드하고 설치합니다. 페이지에서 설치 단계 1과 2만 따르도록 합니다.

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

    # https://docs.gitlab.com/omnibus/roles/#sidekiq-roles
roles(["sidekiq_role"])
   
# 외부 URL
## 이것은 외부 로드 밸런서의 URL과 일치해야 합니다
external_url 'https://gitlab.example.com'
   
# Redis
redis['master_name'] = 'gitlab-redis'
   
## 마스터 노드에 설정한 Redis 인증용 동일한 암호
redis['master_password'] = '<redis_primary_password>'
   
## `host` 및 `port`에 대한 디렉터리
gitlab_rails['redis_sentinels'] = [
   {'host' => '10.6.0.11', 'port' => 26379},
   {'host' => '10.6.0.12', 'port' => 26379},
   {'host' => '10.6.0.13', 'port' => 26379},
]
   
# Gitaly 클러스터
## git_data_dirs는 Praefect 가상 스토리지용으로 구성됩니다
## 주소는 Praefect의 내부 로드 밸런서
## 토큰은 praefect_external_token
git_data_dirs({
  "default" => {
    "gitaly_address" => "tcp://10.6.0.40:2305", # 내부 로드 밸런서 IP
    "gitaly_token" => '<praefect_external_token>'
  }
})
   
# PostgreSQL
gitlab_rails['db_host'] = '10.6.0.40' # 내부 로드 밸런서 IP
gitlab_rails['db_port'] = 6432
gitlab_rails['db_password'] = '<postgresql_user_password>'
gitlab_rails['db_load_balancing'] = { 'hosts' => ['10.6.0.21', '10.6.0.22', '10.6.0.23'] } # PostgreSQL IP
   
## 업그레이드시 자동으로 데이터베이스 마이그레이션을 실행하지 않도록 합니다
gitlab_rails['auto_migrate'] = false
   
# Sidekiq
sidekiq['enable'] = true
sidekiq['listen_address'] = "0.0.0.0"
   
## 이용 가능한 CPU 수만큼 Sidekiq 대기열 프로세스 수 설정
sidekiq['queue_groups'] = ['*'] * 4
   
# 모니터링
consul['enable'] = true
consul['monitoring_service_discovery'] =  true
   
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}
   
## 수집기가 수신 대기할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
   
## 모니터링 노드의 IP 주소를 모니터링 화이트리스트에 추가
gitlab_rails['monitoring_whitelist'] = ['10.6.0.81/32', '127.0.0.0/8']
gitlab_rails['prometheus_address'] = '10.6.0.81:9090'
   
# Object Storage
## GCP에서 Object Storage를 구성하는 예시입니다
## 이를 원하는 대로 선택한 Object Storage 제공업체로 대체합니다
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['object_store']['objects']['artifacts']['bucket'] = "<gcp-artifacts-bucket-name>"
gitlab_rails['object_store']['objects']['external_diffs']['bucket'] = "<gcp-external-diffs-bucket-name>"
gitlab_rails['object_store']['objects']['lfs']['bucket'] = "<gcp-lfs-bucket-name>"
gitlab_rails['object_store']['objects']['uploads']['bucket'] = "<gcp-uploads-bucket-name>"
gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
   
gitlab_rails['backup_upload_connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
   
gitlab_rails['ci_secure_files_object_store_enabled'] = true
gitlab_rails['ci_secure_files_object_store_remote_directory'] = "gcp-ci_secure_files-bucket-name"
   
gitlab_rails['ci_secure_files_object_store_connection'] = {
   'provider' => 'Google',
   'google_project' => '<gcp-project-name>',
   'google_json_key_location' => '<path-to-gcp-service-account-key>'
}

  4. 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 동일한 이름의 파일을 추가하거나 교체합니다. 이번이 첫 번째 구성 중인 Linux 패키지 노드인 경우, 이 단계를 건너뜁니다.

  5. 데이터베이스 마이그레이션이 업그레이드 중 자동으로 실행되지 않고 reconfigure 중에만 실행되도록 하려면 다음을 실행합니다: 

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

    세부사항은 GitLab Rails 포스트-구성 섹션에서 설명된 대로 단일 지정된 노드만 마이그레이션을 처리해야 합니다.

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

  7. GitLab 서비스가 실행 중인지 확인합니다: 

    sudo gitlab-ctl status

    다음과 유사한 출력이어야 합니다: 

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

GitLab Rails 구성

이 섹션에서는 GitLab 애플리케이션 (Rails) 컴포넌트를 설정하는 방법에 대해 설명합니다.

Rails는 Redis, PostgreSQL, Gitaly 인스턴스에 연결을 필요로 합니다. 또한 권장되는 대로 Object Storage에 연결해야 합니다.

note
데이터 객체에 대해 NFS 대신 Object Storage를 사용하는 것이 권장되므로 다음 예제에는 Object Storage 구성이 포함되어 있습니다.

각 노드에서 다음을 수행하세요:

  1. 선택한 Linux 패키지를 다운로드하고 설치하세요. 페이지의 설치 단계 1과 2를 따로 따르도록 주의하세요.

  2. /etc/gitlab/gitlab.rb 파일을 만들거나 편집하고 다음 구성을 사용하세요. 링크의 일관성을 유지하기 위해 애플리케이션 서버의 external_url을 사용자가 GitLab에 액세스하는 데 사용할 외부 URL을 가리키도록 설정해야 합니다. 이 URL은 GitLab 애플리케이션 서버로 트래픽을 라우팅할 외부 로드 밸런서의 URL이 됩니다. 

    external_url 'https://gitlab.example.com'
   
# git_data_dirs는 Praefect 가상 스토리지를 위해 구성됩니다.
# 주소는 Praefect의 내부 로드 밸런서입니다.
# 토큰은 praefect_external_token입니다.
git_data_dirs({
  "default" => {
    "gitaly_address" => "tcp://10.6.0.40:2305", # 내부 로드 밸런서 IP
    "gitaly_token" => '<praefect_external_token>'
  }
})
   
## GitLab 애플리케이션 서버에서 사용되지 않을 컴포넌트 비활성화
roles(['application_role'])
gitaly['enable'] = false
nginx['enable'] = true
sidekiq['enable'] = false
   
# PostgreSQL 연결 세부 정보
# 애플리케이션 노드에서 PostgreSQL 비활성화
postgresql['enable'] = false
gitlab_rails['db_host'] = '10.6.0.20' # 내부 로드 밸런서 IP
gitlab_rails['db_port'] = 6432
gitlab_rails['db_password'] = '<postgresql_user_password>'
gitlab_rails['db_load_balancing'] = { 'hosts' => ['10.6.0.21', '10.6.0.22', '10.6.0.23'] } # PostgreSQL IPs
   
# 업그레이드 시 자동으로 데이터베이스 마이그레이션을 방지
gitlab_rails['auto_migrate'] = false
   
## Redis 연결 세부 정보
## 모든 센티넬 노드에서 동일해야 합니다.
redis['master_name'] = 'gitlab-redis'
   
## Redis 기본 노드에 설정한 Redis 인증을 위한 동일한 비밀번호입니다.
redis['master_password'] = '<redis_primary_password>'
   
## `host`와 `port`를 가진 센티넬 디렉터리
gitlab_rails['redis_sentinels'] = [
  {'host' => '10.6.0.11', 'port' => 26379},
  {'host' => '10.6.0.12', 'port' => 26379},
  {'host' => '10.6.0.13', 'port' => 26379}
]
   
## Prometheus를 위한 서비스 디스커버리 활성화
consul['enable'] = true
consul['monitoring_service_discovery'] =  true
   
# 모니터링에 사용할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
gitlab_workhorse['prometheus_listen_addr'] = '0.0.0.0:9229'
sidekiq['listen_address'] = "0.0.0.0"
puma['listen'] = '0.0.0.0'
   
## Consul 서버 노드의 IP
## FQDN 및 IP를 혼합하여 사용할 수 있습니다.
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
   
# 모니터링 노드의 IP 주소를 모니터링 화이트리스트에 추가하여 NGINX 메트릭을 수집하도록 허용
gitlab_rails['monitoring_whitelist'] = ['10.6.0.81/32', '127.0.0.0/8']
nginx['status']['options']['allow'] = ['10.6.0.81/32', '127.0.0.0/8']
gitlab_rails['prometheus_address'] = '10.6.0.81:9090'
   
## NFS를 설정한 경우 다음 옵션들의 주석 처리를 해제하고 편집하세요
##
## NFS 데이터 마운트 사용 불가시 GitLab 시작 방지
##
#high_availability['mountpoint'] = '/var/opt/gitlab/git-data'
##
## NFS를 통한 권한을 위해 서버 간의 UID 및 GID가 일치함을 보장
##
#user['uid'] = 9000
#user['gid'] = 9000
#web_server['uid'] = 9001
#web_server['gid'] = 9001
#registry['uid'] = 9002
#registry['gid'] = 9002
   
# Object Storage
# GCP에서 Object Storage를 구성하는 예시
# 이 구성은 원하는 Object Storage 공급자로 교체하세요
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['object_store']['objects'][...] = "<gcp-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>'
}

  3. Gitaly에 TLS 지원이 있는 경우 git_data_dirs 항목이 tcp 대신 tls로 구성되었는지 확인하세요. 

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

    1. -cert.pem을 /etc/gitlab/trusted-certs/로 복사합니다: 

      sudo cp cert.pem /etc/gitlab/trusted-certs/

  4. 이 서버에서 처음 Linux 패키지 노드를 구성하는 경우 /etc/gitlab/gitlab-secrets.json 파일을 복사하고 추가하거나 해당 파일을 바꿉니다. 이 서버가 처음 구성하는 첫 번째 Linux 패키지 노드인 경우이 단계를 건너뛸 수 있습니다.

  5. 이 서버에서 처음 Linux 패키지 노드를 구성하는 경우 첫 번째 Linux 패키지 노드에서 SSH 호스트 키(ssh_host_*_key* 형식의 이름을 가진 모두)를 복사하고 추가하거나 해당 파일을 바꿉니다. 이렇게 하면 사용자가 로드 밸런스된 Rails 노드에 접속할 때 호스트 불일치 오류가 발생하지 않습니다. 이 서버가 처음 구성하는 첫 번째 Linux 패키지 노드인 경우 이 단계를 건너뛸 수 있습니다.

  6. 데이터베이스 마이그레이션이 업그레이드시 자동으로 실행되지 않고 재구성 시에만 실행되도록하기 위해 다음 명령을 실행하세요: 

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

    GitLab Rails 재구성 섹션에서 설명된 대로 마이그레이션을 처리할 단일 지정된 노드만 처리해야 합니다.

  7. 변경 사항을 적용하려면 GitLab을 재구성하세요.

  8. 증분 로깅을 활성화하세요.

  9. sudo gitlab-rake gitlab:gitaly:check를 실행하여 노드가 Gitaly에 연결할 수 있는지 확인하세요.

  10. 요청을 보기 위해 로그를 확인하세요: 

    sudo gitlab-ctl tail gitaly

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

    sudo gitlab-ctl status

    다음과 비슷한 출력이어야 합니다: 

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

external_url에 https를 지정한 경우 앞의 예제와 같이 GitLab은 SSL 인증서가 /etc/gitlab/ssl/에 있는 것으로 기대합니다. 인증서가 없는 경우 NGINX가 시작하지 못할 수 있습니다. 자세한 정보는 HTTPS 문서를 참조하세요.

GitLab Rails 포스트 구성

  1. 모든 마이그레이션이 실행되었는지 확인하십시오: 

    gitlab-rake gitlab:db:configure

    주의: 이를 위해서는 레일스 노드가 기본 데이터베이스에 직접 연결하도록 구성되어 있어야 합니다. PgBouncer 우회가 필요합니다. 마이그레이션이 완료되면 노드를 다시 PgBouncer로 지나가도록 구성해야 합니다.

  2. 데이터베이스에서 인증된 SSH 키를 빠르게 조회하도록 구성합니다](../operations/fast_ssh_key_lookup.md).

Prometheus 구성

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

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

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

    roles(['monitoring_role', 'consul_role'])
   
external_url 'http://gitlab.example.com'
   
# Prometheus
prometheus['listen_address'] = '0.0.0.0:9090'
prometheus['monitor_kubernetes'] = false
   
# Prometheus를 위한 서비스 디스커버리 활성화
consul['monitoring_service_discovery'] =  true
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}
   
# Prometheus의 서비스 디스커버리를 구성합니다
prometheus['scrape_configs'] = [
   {
      'job_name': 'pgbouncer',
      'static_configs' => [
         'targets' => [
         "10.6.0.31:9188",
         "10.6.0.32:9188",
         "10.6.0.33:9188",
         ],
      ],
   },
   {
      'job_name': 'praefect',
      'static_configs' => [
         'targets' => [
         "10.6.0.131:9652",
         "10.6.0.132:9652",
         "10.6.0.133:9652",
         ],
      ],
   },
]
   
nginx['enable'] = false
  4. 파일을 저장하고 GitLab을 다시 구성합니다.

  5. GitLab 서비스가 실행되고 있는지 확인합니다: 

    sudo gitlab-ctl status

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

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

객체 리포지터리 구성

GitLab은 여러 유형의 데이터를 보유하기 위해 객체 리포지터리 서비스 사용을 지원합니다. 데이터 객체에 대해 NFS보다 권장되며 일반적으로 성능, 신뢰성 및 확장성 면에서 훨씬 우수합니다. 자세한 정보는 추천되는 클라우드 제공업체 및 서비스를 참조하십시오.

GitLab에서 객체 리포지터리 구성을 지정하는 두 가지 방법이 있습니다: - 통합된 형식: 모든 지원되는 객체 유형이 공유 자격 증명을 사용합니다. - 리포지터리별 형식: 각 객체는 고유한 객체 리포지터리 연결 및 구성을 정의합니다.

객체 유형마다 별도의 버킷을 사용하는 것이 GitLab에서 권장하는 방법입니다. 이렇게 하면 GitLab이 저장하는 다양한 유형의 데이터에서 충돌이 없어집니다. 미래에는 단일 버킷 사용을 허용할 계획입니다.

증분 로깅 활성화

GitLab Runner는 작업 로그를 청크 단위로 반환하며, 보통 리눅스 패키지를 사용하여 일시적으로 /var/opt/gitlab/gitlab-ci/builds에 캐시합니다. 리눅스 패키지를 사용하여도 고유 객체 리포지터리를 사용하지 않는 경우에도 기본 구성에서는 이 디렉터리를 NFS를 통해 공유해야 합니다.

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

고급 검색 구성

Elasticsearch를 활용하여 전체 GitLab 인스턴스 전체에서 더 빠르고 고급 코드 검색을 사용할 수 있습니다. Elasticsearch 클러스터 설계 및 요구 사항은 특정 데이터에 따라 달라집니다. 인스턴스와 함께 Elasticsearch 클러스터를 설정하는 권장 사항에 대한 자세한 내용은 최적의 클러스터 구성 선택하기를 읽어보십시오.

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

60 RPS 또는 3,000 사용자 GitLab 참고 아키텍처는 고가용성을 달성하는 데 권장하는 가장 작은 크기입니다. 그러나 더 적은 사용자나 낮은 RPS를 제공할 환경에서는 복잡성과 비용을 줄이기 위해 여러 지원되는 수정 사항을 고려할 수 있습니다.

GitLab을 통해 고가용성을 달성하려면 60 RPS 또는 3,000 사용자 아키텍처의 구성이 궁극적으로 필요합니다. 각 컴포넌트에는 고려해야 할 여러 가지 사항 및 규칙이 있으며, 아키텍처는 이러한 모든 사항을 충족합니다. 이 아키텍처의 작은 버전은 근본적으로 동일하지만 성능 요구 사항이 줄어들기 때문에 여러 가지 수정 사항이 다음과 같이 고려될 수 있습니다:

  • 노드 사양 낮추기: 사용자 수에 따라 원하는대로 모든 제안된 노드 사양을 낮출 수 있습니다. 그러나 일반 요구 사항보다 작게 설정하지 않도록 권장합니다.
  • 특정 노드 결합: 일부 노드를 결합하여 일부 성능을 희생하는 대신 복잡성을 줄일 수 있습니다:
    • GitLab Rails 및 Sidekiq: Sidekiq 노드를 제거하고 해당 컴포넌트를 대신 GitLab Rails 노드에서 활성화할 수 있습니다.
    • PostgreSQL 및 PgBouncer: PgBouncer 노드를 제거하고 대신 PostgreSQL 노드에서 활성화할 수 있습니다. 그러나 Database Load Balancing을 활성화하려면 별도의 PgBouncer 배열이 여전히 필요합니다.
  • 노드 수 줄이기: 일부 노드 유형은 합의가 필요하지 않으며 더 적은 노드로 실행 가능합니다(그러나 여분의 레드런시를 위해 하나 이상 필요). 이로 인해 성능이 감소됩니다.
    • GitLab Rails 및 Sidekiq: 상태가 없는 서비스에는 최소 노드 수가 필요하지 않습니다. 여분의 레드런시를 위해 두 개가 충분합니다.
    • PostgreSQL 및 PgBouncer: 크로움이 엄격히 필요하지 않습니다. PostgreSQL 노드 두 개와 PgBouncer 노드 두 개가 충분합니다.
  • 신회용되는 클라우드 PaaS 솔루션에서 일부 컴포넌트 실행: GitLab 설정의 일부 컴포넌트는 대신 클라우드 제공자 PaaS 솔루션에서 실행될 수 있습니다. 이렇게 하면 다른 의존 컴포넌트도 제거할 수 있습니다:
    • PostgreSQL: Google Cloud SQL이나 Amazon RDS와 같은 신회용되는 클라우드 PaaS 솔루션에서 실행할 수 있습니다. 이 설정에서는 더 이상 PgBouncer 및 Consul 노드가 필요하지 않습니다:
      • Prometheus 자동 검색이 필요한 경우 Consul은 여전히 원하는 경우에 필요할 수 있으나, 그렇지 않으면 모든 노드에 매뉴얼으로 스크랩 구성을 추가해야 합니다.
        • 이 아키텍처에서 Redis Sentinel은 Redis 패키지를 사용하여 여전히 실행하고 있는 경우 별도의 상자에서 실행되어야 할 수 있습니다.
    • Redis: Google Memorystore나 AWS ElastiCache 같은 신회용되는 클라우드 PaaS 솔루션에서 실행할 수 있습니다. Redis Sentinel이 더 이상 필요하지 않습니다.

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

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

하이브리드 설치는 클라우드 네이티브 및 전통적인 컴퓨팅 배포의 이점을 활용합니다. 이에 따라 무상태(stateless) 컴포넌트는 클라우드 네이티브 워크로드 관리의 이점을 누리는 반면, 상태 유지(stateful) 컴포넌트는 Linux 패키지 설치를 통해 컴퓨팅 가상 머신에 배포하여 증가된 영속성의 이점을 활용합니다.

설정 지침 및 Kubernetes와 백엔드 컴포넌트 간에서 GitLab 비밀을 동기화하는 방법을 포함한 설정 지침을 확인하려면 Helm 차트 고급 구성 문서를 참조하세요.

note
이는 고급 설정으로, Kubernetes에서 서비스를 실행하는 것은 복잡하다는 것으로 잘 알려져 있습니다. 이 설정은 근본적인 지식과 경험이 있는 경우에만 권장됩니다. 이 섹션의 나머지 부분은 이러한 것을 전제로 합니다.
caution
Gitaly Cluster는 Kubernetes에서 실행할 수 없습니다. 자세한 내용은 epic 6127를 참조하세요.

클러스터 토폴로지

일반적인 환경과 동일한 형식을 사용하여 하이브리드 환경의 세부 정보를 제공하는 다음 표와 다이어그램이 있습니다.

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

컴포넌트 노드 그룹 목표 노드 풀 총계 GCP 예시 AWS 예시
Webservice 16 vCPU
20 GB 메모리 (요청)
28 GB 메모리 (한도) 		2 x n1-standard-16 2 x c5.4xlarge
Sidekiq 7.2 vCPU
16 GB 메모리 (요청)
32 GB 메모리 (한도) 		3 x n1-standard-4 3 x m5.xlarge
지원 서비스 4 vCPU
15 GB 메모리 		2 x n1-standard-2 2 x m5.large
  • 이 설정에 대해 GKE(Google Kubernetes Engine)와 EKS(Amazon Elastic Kubernetes Service)를 권장하고 정기적으로 테스트합니다.
  • GCP 및 AWS의 목표 노드 풀 총계에 도달하기 위한 예시가 편의를 위해 제공됩니다. 이러한 크기는 성능 테스트에 사용되지만 예시를 따를 필요는 없습니다. 다른 노드 풀 디자인을 원하는대로 사용할 수 있습니다. 모든 pod이 배포될 수 있다면 목표를 충족시키는 한 원하는 노드 풀을 사용할 수 있습니다.
  • Webservice 및 Sidekiq 목표 노드 풀 총계는 GitLab 컴포넌트에만 적용됩니다. 선택된 Kubernetes 제공 업체의 시스템 프로세스에 대한 추가 자원이 필요합니다. 제공된 예시에는 이러한 사항이 반영되어 있습니다.
  • Supporting 목표 노드 풀 총계는 GitLab 배포를 지원하는 여러 리소스와 필요에 따라 추가로 만들고자 하는 배포에 필요한 자원을 수용하기 위해 일반적으로 제공됩니다. 다른 노드 풀과 마찬가지로 선택된 Kubernetes 제공 업체의 시스템 프로세스도 자원이 필요합니다. 제공된 예시에는 이러한 사항이 반영되어 있습니다.
  • 프로덕션 배포에서 특정 노드에 pod을 할당할 필요는 없지만, 강건한 클라우드 아키텍처 관행과 일치하기 위해 각 풀에 여러 노드를 여러 가용 영역(Availability Zone)에 걸쳐 분산하는 것이 권장됩니다.
  • 클러스터 오토스케일링(Cluster Autoscaler)과 같은 효율성을 위한 오토스케일링을 활성화하는 것이 권장되지만, 일반적으로 Webservice 및 Sidekiq pod의 성능을 지속적으로 보장하기 위해 75% 지점을 목표로 하는 것이 일반적입니다.

이어서 Linux 패키지(또는 해당 가능한 경우 외부 PaaS 서비스)를 사용하여 정적 컴퓨팅 VM에서 실행되는 백엔드 컴포넌트가 있습니다:

서비스 노드 수 구성 GCP AWS
Redis2 3 2 vCPU, 7.5 GB 메모리 n1-standard-2 m5.large
Consul1 + Sentinel2 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large
PostgreSQL1 3 2 vCPU, 7.5 GB 메모리 n1-standard-2 m5.large
PgBouncer1 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large
내부 로드 밸런서3 1 4 vCPU, 3.6 GB 메모리 n1-highcpu-4 c5n.xlarge
Gitaly5 3 4 vCPU, 15 GB 메모리6 n1-standard-4 m5.xlarge
Praefect5 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large
Praefect PostgreSQL1 1+ 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large
객체 스토리지4 - - - -

각주:

  1. 신뢰할 수 있는 타사 외부 PaaS PostgreSQL 솔루션에서 선택 사항으로 실행할 수 있습니다. 자세한 내용은 사용자 고유의 PostgreSQL 인스턴스 제공를 참조하세요.
  2. 신뢰할 수 있는 타사 외부 PaaS Redis 솔루션에서 선택 사항으로 실행할 수 있습니다. 자세한 내용은 사용자 고유의 Redis 인스턴스 제공를 참조하세요.
  3. 신뢰할만한 클라우드 제공 업체 또는 Self-Managed형 솔루션에서 실행해야 합니다. 자세한 내용은 객체 스토리지 구성를 참조하세요.
  4. Gitaly 클러스터는 내고장 허용성의 이점을 제공하지만, 추가된 설정 및 관리의 복잡성과 함께 제공됩니다. Gitaly 클러스터 배포 전의 기술적 제한 및 고려 사항을 검토하세요. 만약 샤드된 Gitaly를 원한다면, Gitaly에 대한 위와 같은 사양을 사용하세요.
  5. Gitaly 사양은 건강한 상태에서 리포지터리 크기의 높은 백분율을 기반으로 합니다. 그러나 대형 단일 리포지터리(수 기가바이트 이상) 또는 추가 워크로드가 있는 경우 이는 Git 및 Gitaly 성능에 중대하게 영향을 줄 수 있으며 추가 조정이 필요할 수 있습니다.
note
인스턴스 구성과 관련된 모든 PaaS 솔루션에 대해, 강건한 클라우드 아키텍처 관행과 일치하기 위해 세 가용 영역(Availability Zone)에 각각 세 개의 노드를 구성하는 것이 권장됩니다.

쿠버네티스 컴포넌트 대상

다음 섹션에서는 쿠버네티스에서 배포된 GitLab 컴포넌트에 사용되는 대상을 상세히 설명합니다.

웹 서비스

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

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

60 RPS 또는 3,000 사용자의 경우, 약 16개의 총 Puma 워커 개수가 추천되므로 적어도 4개의 웹 서비스 pod을 실행하는 것이 좋습니다.

웹 서비스 자원 사용에 대한 자세한 내용은 웹 서비스 자원을 참조하십시오.

NGINX

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

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

Sidekiq

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

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

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

Sidekiq 자원 사용에 대한 자세한 내용은 Sidekiq 자원을 참조하십시오.

보조

보조 노드 풀은 웹 서비스 및 Sidekiq 풀에 있을 필요가 없는 모든 보조 배포를 보관하는 데 사용됩니다.

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

컨테이너 레지스트리, 페이지 또는 모니터링과 같은 추가 배포를 원하는 경우, 가능한 한 이 풀에 배포하는 것이 좋습니다. 웹 서비스 또는 Sidekiq 풀이 아닌 이 풀에 배포하도록하고, 이보다 많은 추가 배포를 수용하도록 이 풀이 특별히 설계되었습니다. 그러나 사용 사례에 해당하는 풀이 과도하게 공급되어 있는 경우, 이에 맞게 노드 풀을 증가시킬 수 있고, 반대로 너무 많이 제공된 경우 줄일 수 있습니다.

구성 파일 예시

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