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

Tier: Premium, Ultimate Offering: Self-managed

이 페이지에서는 최대 3,000명의 사용자를 대상으로 설계된 GitLab 참조 아키텍처에 대해 설명합니다.

이 아키텍처는 최소 사이즈로 제공되며 내장된 HA가 포함되어 있습니다. HA가 필요하지만 사용자 수나 총 부하가 낮은 경우 낮은 사용자 수를 위한 지원되는 수정 사항 섹션에서 HA를 유지하면서 이 아키텍처의 크기를 줄이는 방법에 대해 알려줍니다.

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

  • 대상 부하: 60 RPS, 웹: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS
  • 고가용성: 예, 하지만 Praefect에는 서드파티 PostgreSQL 솔루션이 필요합니다.
  • 예상 비용: 비용 표를 참조하세요.
  • 클라우드 네이티브 하이브리드 대안: 예
  • 어떤 참조 아키텍처를 사용해야 하는지 확신이 안 드시나요? 자세한 정보를 보려면 이 가이드로 이동하세요.
서비스 노드 구성 GCP AWS Azure
외부 로드 밸런서3 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
내부 로드 밸런서3 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
객체 리포지터리 4 - - - - -

각주:

  1. 명성있는 서드파티 외부 PaaS PostgreSQL 솔루션에서 선택 사항으로 실행할 수 있습니다. 자세한 정보는 자체 PostgreSQL 인스턴스 제공를 참조하세요.
  2. 명성있는 서드파티 외부 PaaS Redis 솔루션에서 선택 사항으로 실행할 수 있습니다. 자세한 정보는 자체 Redis 인스턴스 제공를 참조하세요.
  3. HA 기능을 제공할 수 있는 명성 있는 서드파티 로드 밸런서 또는 서비스 (LB PaaS)에서 실행하는 것이 권장됩니다. 또한 사이징은 선택한 로드 밸런서와 네트워크 대역폭과 같은 추가 요소에 따라 달라집니다. 자세한 정보는 로드 밸런서를 참조하세요.
  4. 명성 있는 클라우드 제공업체나 Self-managed 솔루션에서 실행할 수 있습니다. 자세한 정보는 객체 리포지터리 구성를 참조하세요.
  5. Gitaly 클러스터는 장애 허용성의 장점을 제공하지만 설정 및 관리에 추가 복잡성이 동반됩니다. Gitaly 클러스터를 배포하기 전에 기존 기술적 한계 및 고려 사항을 검토하세요. Sharded Gitaly를 원하는 경우 Gitaly에 대해 위에서 나열된 동일한 사양을 사용하세요.
  6. Gitaly 사양은 건강한 상태의 사용 패턴 및 리포지터리 크기의 상위 백분위에 기반합니다. 그러나 대형 모노 리포지터리 (수 기가바이트 이상)나 추가 워크로드를 보유하고 있다면 Git 및 Gitaly 성능에 상당한 영향을 미칠 수 있으며 추가 조정이 필요할 수 있습니다.
  7. 구성 데이터를 저장하지 않는 특정 클러스터링 대상 그룹 (ASG)에 배치할 수 있습니다. 그러나 GitLab Rails의 경우 마이그레이션 및 메일룸과 같은 특정 프로세스는 하나의 노드에서만 실행되어야 합니다.
note
인스턴스 구성을 포함하는 모든 PaaS 솔루션의 경우, 견고한 클라우드 아키텍처 기법에 부합하도록 세 가지 노드 이상을 세 가지 다른 가용 영역에 구현하는 것이 강력히 권장됩니다.

요구 사항

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

테스트 방법론

3k 아키텍처는 주요 워크플로 중 대다수를 커버하도록 설계되었으며 정기적으로 풀이 및 성능 테스트가 품질 엔지니어링 팀에 의해 수행되며 다음 엔드포인트 처리량 목표에 대해 검증됩니다:

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

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

위 엔드포인트 목표에 대해 정기적으로 더 높은 처리량을 가지고 있다고 제안할 수 있는 메트릭이 있다면, 대형 모노 레포나 주목할만한 추가 워크로드가 성능 환경에 현저한 영향을 줄 수 있으며, 추가적인 조정이 필요할 수 있다. 이 경우 해당하는 문서를 참조하거나 귀하의 고객 성공 관리자나 지원 팀에 문의하여 추가 지침을 받는 것이 강력히 권장됩니다.

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

테스트에 사용된 로드 밸런서는 리눅스 패키지 환경의 경우 HAProxy를 사용하거나 클라우드 네이티브 하이브리드의 경우 동등한 클라우드 제공 업체 서비스를 사용하였습니다. 이러한 선택들이 특정 요구 사항 또는 권장 사항을 나타내는 것은 아님을 유의하십시오. 거의 모든 신뢰할 수 있는 로드 밸런서가 작동할 것으로 예상됩니다.

구성 컴포넌트

GitLab 및 해당 컴포넌트를 최대 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): 웹 터미널 지원을 위해서는 로드 밸런서가 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 호스트 이름을 구성하는 것이 도움이 될 수 있습니다. 다른 GitLab HTTP 구성과 비교하여 대체 SSH 호스트 이름에는 새로운 가상 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에 구성을 추가해야 합니다. SSL 인증서를 관리하고 NGINX를 구성하는 자세한 내용은 HTTPS 문서를 참조하세요.

내부 로드 밸런서 구성

다중 노드 GitLab 구성의 경우, 구성된 경우 PgBouncer에 대한 연결 및 Praefect에 대한 연결과 같은 일부 내부 컴포넌트에 대한 트래픽을 연결하기 위해 내부 로드 밸런서가 필요합니다. 사용할 로드 밸런서 또는 정확한 구성에 대한 구체적인 내용은 GitLab 문서의 범위를 벗어나지만 일반 요구 사항에 대한 자세한 내용은 로드 밸런서를 참조하세요. 이 섹션은 선택한 로드 밸런서에 대한 구성에 중점을 둡니다.

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

  • 10.6.0.40: 내부 로드 밸런서

다음은 HAProxy를 사용하는 예시입니다: 

global
    log /dev/log local0
    log localhost local1 notice
    log stdout format raw local0

defaults
    log global
    default-server inter 10s fall 3 rise 2
    balance leastconn

frontend internal-pgbouncer-tcp-in
    bind *:6432
    mode tcp
    option tcplog
    
    default_backend pgbouncer

frontend internal-praefect-tcp-in
    bind *:2305
    mode tcp
    option tcplog
    option clitcpka
    
    default_backend praefect

backend pgbouncer
    mode tcp
    option tcp-check
    
    server pgbouncer1 10.6.0.31:6432 check
    server pgbouncer2 10.6.0.32:6432 check
    server pgbouncer3 10.6.0.33:6432 check

backend praefect
    mode tcp
    option tcp-check
    option srvtcpka
    
    server praefect1 10.6.0.131:2305 check
    server praefect2 10.6.0.132:2305 check
    server praefect3 10.6.0.133:2305 check

자세한 안내는 선호하는 로드 밸런서의 문서를 참조하세요.

Redis 구성

확장 가능한 환경에서 Redis를 사용하면 주 복제 (Primary x Replica) 토폴로지를 사용하여 Redis Sentinel 서비스로 장애 조치 절차를 자동으로 감시하고 시작할 수 있습니다.

note
Redis 다중 노드는 Redis Sentinel이 크로럼의 일부로 투표할 수 있도록 3개 이상의 홀수 개수로 배포되어야 합니다. 이는 클라우드 제공업체 서비스 등 외부에서 Redis를 구성하는 경우에는 해당하지 않습니다.
note
Redis는 주로 단일 스레드이며 CPU 코어 증가로부터 혜택을 거의 받지 않습니다. 자세한 정보는 scaling documentation을 참조하십시오.

Redis는 Sentinel과 함께 사용할 경우 인증이 필요합니다. 자세한 내용은 Redis 보안 문서를 참조하십시오. Redis 서비스를 보호하기 위해 Redis 비밀번호와 엄격한 방화벽 규칙을 결합하여 사용하는 것이 좋습니다. Redis를 설정하기 전에 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 클러스터 모드는 특별히 지원되지 않지만 HA(높은 가용성)를 갖춘 Redis 스탠드얼론(예: Redis Sentinel)는 지원됩니다.
  • 설정에 따라 Redis 쫓아내기 모드를 설정해야 합니다.

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

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

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

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

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

주 Redis 노드와 복제 Redis 노드는 redis['password']에 정의된 동일한 암호를 가져야 합니다. 장애 조치 중에 언제든지 Sentinel은 노드를 재구성하고 그 상태를 주 또는 복제로 변경할 수 있습니다.

주 Redis 인스턴스 구성

  1. 주 Redis 서버에 SSH로 로그인합니다.
  2. 선택한 Linux 패키지를 다운로드하고 설치합니다. 페이지에서 installation steps 1 and 2 만을 따르고, 현재 설치와 동일한 버전 및 유형(Community 또는 Enterprise 버전)의 올바른 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_비밀번호_입력'
   
## Prometheus를 위한 서비스 검색 활성화
consul['monitoring_service_discovery'] = true
   
## Consul 서버 노드의 IP
## FQDN을 사용하거나 IP와 혼합하여 사용할 수 있습니다
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
   
# 수출기가 청취할 네트워크 주소를 설정합니다
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'
redis_exporter['flags'] = {
     'redis.addr' => 'redis://10.6.0.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']와 같이 여러 역할을 지정할 수 있습니다. 역할에 대해 자세히 읽어보십시오.

다음 명령을 사용하여 현재 Redis 주, 복제 상태 디렉터리을 볼 수 있습니다. 

/opt/gitlab/embedded/bin/redis-cli -h <host> -a '여기에_레디스_비밀번호_입력' 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. 레플리카 Redis 서버에 SSH로 로그인합니다.
  2. 원하는 리눅스 패키지를 다운로드하고 설치합니다. 페이지에서 설치 단계 1과 2를 따로 따르고, 현재 설치한 것과 동일한 버전 및 유형(Community 또는 Enterprise Edition)의 올바른 리눅스 패키지를 선택해야 합니다.

  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'] = '여기에 레디스 비밀번호를 입력합니다.'
   
# 주 레디스 노드의 IP입니다.
redis['master_ip'] = '10.6.0.61'
   
# 주 레디스 서버의 포트입니다. 기본값은 `6379`입니다.
#redis['master_port'] = 6379
   
## Prometheus용 서비스 검색을 활성화합니다.
consul['monitoring_service_discovery'] =  true
   
## Consul 서버 노드의 IP
## FQDN을 사용하거나 IP와 혼용할 수도 있습니다.
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
   
# 수출기가 수신 대기할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'
redis_exporter['flags'] = {
     'redis.addr' => 'redis://10.6.0.62:6379',
     'redis.password' => '여기에 레디스 비밀번호를 입력합니다.',
}
   
# 업그레이드 시 자동으로 데이터베이스 마이그레이션을 실행하지 않도록 설정
gitlab_rails['auto_migrate'] = false

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

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

  6. 다른 레플리카 노드에 대해 다시 위 단계를 진행하고, IP를 올바르게 설정했는지 확인합니다.

여러 역할을 명시할 수 있습니다. 예를들어 roles(['redis_sentinel_role', 'redis_master_role'])와 같이 말이죠. 역할에 대해 자세히 알아보세요.

이 값들은 장애 조치 후 /etc/gitlab/gitlab.rb에서 다시 변경할 필요가 없습니다. 노드들은 Sentinels에 의해 관리되며, 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. 원하는 리눅스 패키지를 다운로드하고 설치합니다. 페이지에서 설치 단계 1과 2를 따로 따르고, 현재 설치한 것과 동일한 버전 및 유형(Community 또는 Enterprise Edition)의 올바른 리눅스 패키지를 선택해야 합니다.

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

    roles(['redis_sentinel_role', 'consul_role'])
   
# 모든 Sentinel 노드에 동일해야 합니다.
redis['master_name'] = 'gitlab-redis'
   
# 기본 노드에 설정한 Redis 인증용 동일한 비밀번호입니다.
redis['master_password'] = '여기에 레디스 비밀번호를 입력합니다.'
   
# 주 레디스 노드의 IP입니다.
redis['master_ip'] = '10.6.0.61'
   
# Redis가 TCP 요청을 수신하도록 할 수 있는 포트를 정의합니다. 이를 통해 다른 기계가 연결될 수 있습니다.
redis['port'] = 6379
   
# 주 레디스 서버의 포트입니다. 기본값은 `6379`입니다.
#redis['master_port'] = 6379
   
## Sentinel 구성
sentinel['bind'] = '10.6.0.11'
   
# Sentinel이 수신 대기하는 포트입니다. 기본값은 `26379`입니다.
# sentinel['port'] = 26379
   
## 쿼러럼은 장애 조치를 시작하는 데 필요한 투표 수를 반영해야 합니다.
## 값은 반드시 Sentinel의 수보다 커서는 안됩니다.
##
## 쿼러럼은 두 가지 방법으로 Sentinel을 조정하는 데 사용됩니다:
## 1. 쿼러럼이 설치한 대다수의 Sentinel보다 작게 설정되면, 기본적으로 Sentinel을 주요 장애로부터 보호하기 위해 민감하게 만들 수 있습니다.
##    즉, 단지 소수의 Sentinel이 더 이상 주요 노드와 통신하지 못하게 되면 즉시 장애 조치를 발생시킵니다.
## 1. 쿼럼이 설치한 대다수의 Sentinel보다 크게 설정되면, 한 번에 매우 많은 수(최대 다수보다 큰)의 잘 연결된 Sentinel이 주요 노드의 다운에 동의할 때만 Sentinel이 장애 조치를 시작하도록합니다.
sentinel['quorum'] = 2
   
## x 밀리초 후 응답이 없는 서버를 고려합니다.
# sentinel['down_after_milliseconds'] = 10000
   
## x 밀리초의 장애 조치 시간을 지정합니다. 여러 가지 방법으로 사용됩니다:
##
## - 이전 실패 조치에 대한 리스타트 시간은 이 값을 두 배로 합니다.
##
## - 현재 구성에 따라 잘못된 주요 노드에 복제하는 중복본을 강제로 복제해야 하는 장기간은 정확히 장애 조치 시간이 걸립니다.
##
## - 이미 진행 중인 장애 조치를 취소하는 데 필요합니다.
##
## - 모든 복제본이 새로운 주요 노드의 복제본으로 다시 구성되기까지 장애 조치가 진행됩니다. 그러나 이 시간 이후에도 복제본은 결국 Sentinels에 의해 다시 구성되나, 정확한 병렬 동기화 진행 상황은 지정되지 않습니다.
# 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),
}
   
# 수출기가 수신 대기할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'
   
# 업그레이드 시 자동으로 데이터베이스 마이그레이션을 실행하지 않도록 설정
gitlab_rails['auto_migrate'] = false

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

  5. 다른 Consul/Sentinel 노드에 대해 다시 위 단계를 진행하고, 올바른 IP를 설정했는지 확인합니다.

Consul 서버의 3번째 프로비저닝이 완료되면 Consul 리더가 _선출_됩니다. 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. HA Linux 패키지 PostgreSQL 설정에는 PostgreSQL, PgBouncer 및 Consul이 포함됩니다. 이러한 컴포넌트는 모두 서드 파티 외부 서비스를 사용할 때 더 이상 필요하지 않을 수 있습니다.
  2. 데이터베이스 요구 사항 문서에 따라 PostgreSQL을 설정합니다.
  3. 선택한 암호로 gitlab 사용자를 설정합니다. gitlab 사용자는 gitlabhq_production 데이터베이스를 생성할 권한이 필요합니다.
  4. GitLab 응용 프로그램 서버를 적절한 세부 정보로 구성합니다. 이 단계에 대한 내용은 GitLab Rails 응용 프로그램 구성에서 다룹니다.
  5. HA를 달성하기 위해 필요한 노드 수는 Linux 패키지와 비교하여 서비스에 따라 달라질 수 있으며 해당되는 대로 일치시킬 필요가 없습니다.
  6. 그러나 더 나은 성능 향상을 위해 데이터베이스 로드 밸런싱을 통한 읽기 복제본을 사용하려는 경우, 참조 아키텍처의 노드 수를 따르는 것이 권장됩니다.

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

복제와 장애 조치를 위한 PostgreSQL 클러스터에 대한 권장 Linux 패키지 구성은 다음을 필요로 합니다:

  • 최소 세 개의 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 패키지 설치합니다. 이후 단계에서는 1단계에서 필요한 의존성을 설치하고, 2단계에서 GitLab 패키지 리포지터리를 추가합니다. 두 번째 단계에서 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
# 필요한 정보 섹션에서 설명한 실제 값을 설정합니다
#
# 생성된 md5 값을 PGBOUNCER_PASSWORD_HASH로 교체합니다
postgresql['pgbouncer_user_password'] = '<pgbouncer_password_hash>'
# 생성된 md5 값을 POSTGRESQL_REPLICATION_PASSWORD_HASH로 교체합니다
postgresql['sql_replication_password'] = '<postgresql_replication_password_hash>'
# 생성된 md5 값을 POSTGRESQL_PASSWORD_HASH로 교체합니다
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
## IP와 FQDN 모두 사용 가능하며, 혼합하여 사용할 수 있습니다
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
#
# END user configuration

    Patroni가 복제를 관리할 때 PostgreSQL은 기본적으로 pg_rewind를 사용합니다. 대부분의 장애 조치 처리 방법과 마찬가지로, 이는 데이터 손실의 소수 가능성을 가지고 있습니다. 자세한 내용은 Patroni 복제 방법을 참조하세요.

  7. 첫 번째 Linux 패키지 노드를 구성한 내용과 동일한 /etc/gitlab/gitlab-secrets.json 파일을 이 서버에 추가하거나 교체합니다. 이 동작은 처음 구성하는 Linux 패키지 노드인 경우에는 생략 가능합니다.

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

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

PostgreSQL 후 구성

주 서버(primary site) 중 하나의 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         | *               |

‘상태’ 열에서 어떤 노드의 상태가 “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 파일을 편집하고, 이전에 설정한 패스워드 해시와 <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
   
# Exporter가 청취할 네트워크 주소 설정
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 노드에 저장되어 하나는 주(primary)로 지정되며, 주 노드가 다운되면 자동으로 장애 극복(failover)이 발생합니다.

caution
Gitaly 사양은 사용 패턴 및 리포지터리 크기의 높은 백분위에 기반합니다. 그러나, 대형 단일 리포지터리 (몇 기가바이트 이상) 또는 추가 워크로드가 있는 경우, 환경의 성능에 상당한 영향을 미칠 수 있으며 추가적인 조정이 필요할 수 있습니다. 이 경우, 관련 문서를 확인하거나 추가 지침을 위해 고객 성공 담당자나 지원팀에 문의하는 것을 강력히 권장합니다.

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

안내 사항:

추천 클러스터 구성에는 다음 컴포넌트가 포함됩니다:

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

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

Praefect PostgreSQL 구성

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

고가용성 구성을 원하는 경우, Praefect에는 타사 PostgreSQL 데이터베이스가 필요합니다. 내장 솔루션이 진행 중입니다.

Praefect 비고가용성 PostgreSQL 스탠드얼론 리눅스 패키지 사용

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

  • 10.6.0.141: Praefect PostgreSQL

먼저, Praefect PostgreSQL 노드에서 Linux GitLab 패키지를 설치하세요. 그 후, 단계 1에서 필요한 의존성을 설치하고 단계 2에서 GitLab 패키지 리포지터리를 추가하세요. 두 번째 단계에서 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 and 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
# Required Information 섹션에 설명된 대로 실제 값을 설정하세요
#
# PRAEFECT_POSTGRESQL_PASSWORD_HASH를 생성된 md5 값으로 대체
postgresql['sql_user_password'] = "<praefect_postgresql_password_hash>"
   
# XXX.XXX.XXX.XXX/YY를 네트워크 주소로 대체
postgresql['trust_auth_cidr_addresses'] = %w(10.6.0.0/24 127.0.0.1/32)
   
# 모니터링을 위해 익스포터가 수신 대기할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'
postgres_exporter['listen_address'] = '0.0.0.0:9187'
   
## Consul 서버 노드의 IP
## FQDN을 사용하거나 IP와 혼합해서 사용할 수도 있습니다
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
}
#
# END user configuration

  5. 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하고 이 서버의 동일한 이름의 파일에 추가하거나 대체합니다. 이것이 구성할 첫 번째 Linux 패키지 노드라면 이 단계를 건너뛰어도 됩니다.

  6. 변경 사항이 적용되려면 GitLab을 다시 구성하세요.
  7. 변경 사항이 적용되었는지 확인하려면 포스트 구성을 따르세요.

Praefect HA PostgreSQL 서드파티 솔루션

여기에 언급된 대로, Praefect의 데이터베이스에 대한 완전한 고가용성을 원한다면 서드파티 PostgreSQL 솔루션이 권장됩니다.

PostgreSQL HA를 위한 다양한 서드파티 솔루션이 있습니다. Praefect와 함께 작동하려면 선택한 솔루션이 다음을 가져야 합니다:

  • 장애 조치(failover) 시 변경되지 않는 모든 연결을 위한 정적 IP.
  • LISTEN SQL 기능을 지원해야 함.
note
서드파티 설정을 통해 Praefect의 데이터베이스를 메인 GitLab 데이터베이스와 동일한 서버에 편의상 놓을 수 있지만 Geo를 사용하는 경우, 별도의 데이터베이스 인스턴스가 필요합니다. 이러한 설정에서는 주 데이터베이스 설정을 변경할 필요가 없으며 영향은 최소화되어야 합니다.

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

데이터베이스를 설정한 후에는 포스트 구성을 따르세요.

Praefect PostgreSQL 포스트 구성

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

사용자 이름은 praefect이고 데이터베이스 이름은 praefect_production으로 설정하는 것을 권장합니다. 이는 PostgreSQL에서 표준으로 구성할 수 있습니다. 사용자 암호는 이전에 <praefect_postgresql_password>로 구성한 것과 동일해야 합니다.

리눅스 패키지 PostgreSQL 설정을 예로 들면 다음과 같습니다:

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

  2. 관리 권한으로 PostgreSQL 서버에 연결합니다. 리눅스 패키지의 경우 기본적으로 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. 이번에는 praefect 사용자로 PostgreSQL 서버에 다시 연결합니다. 

    /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 클러스터의 라우터 및 트랜잭션 관리자이며, Gitaly로의 모든 연결은 이를 통해 이루어집니다. 이 섹션에서는 이를 구성하는 방법에 대해 설명합니다.

note
Praefect는 3개 이상의 노드에서 홀수 개의 배포가 필요합니다. 이는 퀘러럼(Quorum)의 일부로 투표를 수행할 수 있도록하기 위함입니다.

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

  • <praefect_external_token>: Gitaly 클러스터에 호스팅된 리포지터리에 사용되며 이 토큰을 가진 Gitaly 클라이언트만 접근할 수 있습니다.
  • <praefect_internal_token>: Gitaly 클러스터 내에서 복제 트래픽에 사용됩니다. 이는 praefect_external_token과 구분됩니다. 외부 클라이언트는 Praefect 클러스터의 내부 노드에 직접 액세스해선 안 되기 때문입니다.
  • <praefect_postgresql_password>: 이전 섹션에서 정의한 Praefect PostgreSQL 암호도 이 설정 구성에 필요합니다.

Gitaly 클러스터 노드는 가상 리포지터리(virtual storage)를 통해 Praefect에서 구성됩니다. 각 리포지터리에는 클러스터를 구성하는 각 Gitaly 노드의 세부 정보가 포함되어 있습니다. 각 리포지터리에는 이름이 지정되며, 이 이름은 구성의 여러 영역에서 사용됩니다. 이 가이드에서는 리포지터리의 이름을 default로 지정합니다. 또한 이 가이드는 새로운 설치를 대상으로 하며, 기존 환경을 Gitaly 클러스터를 사용하도록 업그레이드하는 경우 다른 이름을 사용해야 할 수 있습니다. 자세한 정보는 Praefect 문서를 참조하세요.

다음 IP 주소들을 예를 들어 사용합니다:

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

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

  1. Praefect 서버에 SSH로 로그인합니다.
  2. 선택한 리눅스 패키지를 다운로드하고 설치합니다. 페이지에서 installation steps 1 and 2 만 따르도록 합니다.

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

    # Praefect 서버에서 불필요한 서비스 실행 피하기
gitaly['enable'] = false
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
gitlab_exporter['enable'] = false
gitlab_kas['enable'] = false
   
# Praefect 구성
praefect['enable'] = true
   
# 업그레이드 시 자동으로 데이터베이스 마이그레이션 실행하지 않도록 설정
praefect['auto_migrate'] = false
gitlab_rails['auto_migrate'] = false
   
# Consul 에이전트 구성
consul['enable'] = true
## 프로메테우스를 위해 서비스 탐지 가능하도록 설정
consul['monitoring_service_discovery'] = true
   
# 사용자 구성 시작
# 필수 정보 섹션에서 설명된대로 실제 값으로 설정해주세요
#
   
praefect['configuration'] = {
   # ...
   listen_addr: '0.0.0.0:2305',
   auth: {
     # ...
     #
     # Praefect 외부 토큰
     # 이 토큰은 외부 클러스터(예: GitLab Shell)와 통신하기 위해 필요합니다.
     token: '<praefect_external_token>',
   },
   # Praefect 데이터베이스 설정
   database: {
     # ...
     host: '10.6.0.141',
     port: 5432,
     # `no_proxy` 설정은 항상 캐싱을 위해 직접 연결해야 합니다
     session_pooled: {
        # ...
        host: '10.6.0.141',
        port: 5432,
        dbname: 'praefect_production',
        user: 'praefect',
        password: '<praefect_postgresql_password>',
     },
   },
   # Praefect 가상 리포지터리 구성
   # 리포지터리 해시의 이름은 GitLab의 git_data_dirs 서버 ('praefect')와 Gitaly 노드의 gitaly['configuration'][:storage] ('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),
}
#
# 사용자 구성 끝

  4. 이전에 구성한 리눅스 패키지 노드의 /etc/gitlab/gitlab-secrets.json 파일을 복사하거나 해당 서버의 동일한 이름의 파일을 추가하거나 교체하세요. 이것이 구성 중인 첫 번째 리눅스 패키지 노드이면 이 단계는 건너뛸 수 있습니다.

  5. Praefect는 메인 GitLab 애플리케이션과 유사하게 데이터베이스 마이그레이션을 실행해야합니다. 따라서 데이터베이스 마이그레이션은 단 한 대의 Praefect 노드에서만 실행되어야 합니다. 이 노드를 _배포 노드_라고 합니다. 이 노드는 다른 노드보다 먼저 다음과 같이 설정되어야 합니다:

    1. /etc/gitlab/gitlab.rb 파일에서 praefect['auto_migrate'] 설정 값을 false에서 true로 변경합니다.

    2. 업그레이드 시 자동으로 데이터베이스 마이그레이션만 실행되도록 하고, 자동으로 업그레이드되어서는 안 되므로 다음을 실행합니다. 

    sudo touch /etc/gitlab/skip-auto-reconfigure
    1. 변경 사항이 적용되도록 GitLab을 다시 구성합니다(only installation steps 1 and 2)하고 Praefect 데이터베이스 마이그레이션을 실행합니다.
  6. 다른 모든 Praefect 노드에서 GitLab을 재구성합니다(only installation steps 1 and 2)하여 변경 사항이 적용되도록 합니다.

Gitaly 구성

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

caution
Gitaly 사양은 사용 패턴 및 리포지터리 크기의 상위 백분위수에 기반합니다. 그러나 대형 단일 리포지터리(여러 기가바이트 이상)나 추가 작업 부하가 있으면 환경의 성능에 상당한 영향을 미칠 수 있습니다. 이 경우, 링크된 설명서를 참조하고 더 많은 지침을 위해 고객 성공 담당자나 지원팀에 문의하는 것이 강력히 권장됩니다.

Gitaly의 중요한 입력 및 출력 요구 사항으로 모든 Gitaly 노드가 플래시 저장 장치(SSD)를 사용하는 것을 강력히 권장합니다. 이 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`가 실패합니다. 이는 '입구' GitLab URL 또는 내부 로드 밸런서가 될 수 있습니다.
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
   
# Consul 에이전트 구성
consul['enable'] = true
## 프로메테우스를 위한 서비스 검색 활성화
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'
   
gitaly['configuration'] = {
   # ...
   #
   # Gitaly가 모든 네트워크 인터페이스에서의 연결을 수락하도록 설정. 이 주소/포트에 대한 액세스를 제한하려면 방화벽을 사용해야 합니다.
   # TLS 연결만 지원하려면 아래 라인을 주석 처리하세요
   listen_addr: '0.0.0.0:8075',
   # 모니터링을 위해 Gitaly가 수신 대기할 네트워크 주소 설정
   prometheus_listen_addr: '0.0.0.0:9236',
   # Gitaly Auth 토큰
   # 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,
   },
}
   
#
# 사용자 구성 종료
  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. 설정을 저장하고, GitLab을 다시 구성하세요.

Gitaly Cluster TLS 지원

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

  • GitLab 구성에서 해당 리포지터리 엔트리의 gitaly_address에 tls:// URL scheme을 사용합니다.
  • 자체 인증서를 지참해야 합니다. 이는 자동으로 제공되지 않습니다. 각 Praefect 서버에 해당하는 인증서를 설치해야 합니다.

또한 인증서 또는 해당 인증서 기관을 Gitaly 서버와 Praefect 클라이언트 모두에 설치해야 하며, 아래 설명된 프로시저를 따라야 합니다. GitLab 사용자 지정 인증서 구성도 참조하세요.

다음을 유의해야 합니다:

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

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
데이터 객체에 대해 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`가 포함된 Sentinel 디렉터리
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 Cluster
## 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 IPs
   
## 업그레이드시 자동으로 데이터베이스 마이그레이션을 방지합니다.
gitlab_rails['auto_migrate'] = false
   
# Sidekiq
sidekiq['enable'] = true
sidekiq['listen_address'] = "0.0.0.0"
   
## 사용 가능한 CPUs 수와 동일한 수의 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)
}
   
## Exporter가 수신 대기할 네트워크 주소를 설정합니다.
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. 업그레이드시 자동으로 데이터베이스 마이그레이션을 방지하려면 다음 명령을 실행하세요: 

    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 인스턴스에 대한 연결이 필요합니다. 또한 객체 리포지터리에 대한 연결이 권장됩니다.

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

각 노드에서 다음을 수행합니다.

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

  2. /etc/gitlab/gitlab.rb을 만들거나 편집하고 다음 구성을 사용합니다. 링크의 일관성 유지를 위해 응용 프로그램 서버의 external_url은 GitLab에 액세스할 사용자의 외부 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 IP들
    
 # 업그레이드 시 자동으로 데이터베이스 마이그레이션 방지
 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(Fully Qualified Domain Name) 및 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
    
 # 객체 리포지터리
 # 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>'
 }

  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. /etc/gitlab/trusted-certs로 인증서를 복사합니다. 

      sudo cp cert.pem /etc/gitlab/trusted-certs/
  4. 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하고 이 서버의 동일한 이름의 파일을 추가하거나 교체합니다. 이것이 구성 중인 첫 번째 Linux 패키지 노드인 경우 이 단계를 건너뛸 수 있습니다.
  5. 첫 번째 Linux 패키지 노드에서 SSH 호스트 키(모두 /etc/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).

프로메테우스 구성

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

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

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

    roles(['monitoring_role', 'consul_role'])
   
external_url 'http://gitlab.example.com'
   
# 프로메테우스
prometheus['listen_address'] = '0.0.0.0:9090'
prometheus['monitor_kubernetes'] = false
   
# 프로메테우스를 위한 서비스 검색 활성화
consul['monitoring_service_discovery'] =  true
consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}
   
# 프로메테우스에 대한 서비스 스크래핑 구성
prometheus['scrape_configs'] = [
   {
      'job_name': 'pgbouncer',
      'static_configs' => [
         'targets' => [
         "10.6.0.31:9188",
         "10.6.0.32:9188",
         "10.6.0.33:9188",
         ],
      ],
   },
   {
      'job_name': 'praefect',
      'static_configs' => [
         'targets' => [
         "10.6.0.131:9652",
         "10.6.0.132:9652",
         "10.6.0.133:9652",
         ],
      ],
   },
]
   
nginx['enable'] = false
  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에서 객체 리포지터리 구성을 지정하는 두 가지 방법이 있습니다:

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

note
GitLab 14.x 및 이전 버전에서 각 객체 유형에 대한 리포지터리별 형식을 사용하는 경우 직접 업로드 모드를 활성화해야 합니다. 이전에는 14.9에서 사라진 백그라운드 업로드 모드는 NFS와 같은 공유 스토리지가 필요합니다.

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

증분 로깅 활성화

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

NFS를 통해 작업 로그를 공유하는 것은 지원되지만, 인크리멘털 로깅을 활성화하여 NFS 노드를 사용하는 필요를 피하는 것이 권장됩니다(배포된 NFS 노드가 없는 경우 필요함). 인크리멘털 로깅은 작업 로그의 임시 캐싱에 디스크 공간 대신 Redis를 사용합니다.

고급 검색 구성

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

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

하위 사용자 수 (HA)를 위한 지원되는 수정사항

3,000 사용자 GitLab 참조 아키텍처는 고가용성(HA)을 달성하는 데 권장하는 최소 사양입니다. 그러나 더 적은 사용자를 서비스해야 하지만 HA를 유지해야 하는 환경에는 몇 가지 지원되는 수정을 적용할 수 있습니다.

GitLab에서 HA를 달성하려면 3,000 사용자 아키텍처 구성이 최종적으로 필요합니다. 각 컴포넌트에는 따라야 할 다양한 고려 사항과 규칙이 있으며, 3,000 사용자 아키텍처는 이러한 모든 것을 충족합니다. 이 아키텍처의 더 작은 버전도 기본적으로 동일하지만 성능 요구 사항이 작아지면 몇 가지 수정을 고려할 수 있습니다:

  • 노드 사양 줄이기: 사용자 수에 따라 모든 권장 노드 사양을 원하는 대로 낮출 수 있습니다. 그러나 일반 요구 사항보다 낮아서는 안 됩니다.
  • 선택 노드 결합: 일부 노드를 결합하여 성능 일부를 희생하고 복잡성을 줄일 수 있습니다:
    • GitLab Rails 및 Sidekiq: Sidekiq 노드를 제거하고 대신 GitLab Rails 노드에서 활성화할 수 있습니다.
    • PostgreSQL 및 PgBouncer: PgBouncer 노드를 제거하고 대신 내부 로드 밸런서가 그들을 가리키는 PostgreSQL 노드에서 활성화할 수 있지만, 데이터베이스 로드 밸런싱을 가능하게 하려면 별도의 PgBouncer 배열이 여전히 필요합니다.
  • 노드 수 줄이기: 일부 노드 유형은 합의가 필요하지 않고 더 적은 노드로 실행할 수 있습니다(그러나 신뢰성을 위해 한 개 이상 필요). 이로 인해 성능이 저하될 수 있습니다.
    • GitLab Rails 및 Sidekiq: 상태가 없는 서비스에는 최소한의 노드 수가 없습니다. 신뢰성을 위해 두 개가 충분합니다.
    • PostgreSQL 및 PgBouncer: 합의는 엄격하게 필요하지 않습니다. 두 개의 PostgreSQL 노드와 두 개의 PgBouncer 노드는 신뢰성을 위해 충분합니다.
  • 신뢰할 수 있는 클라우드 PaaS 솔루션에서 일부 컴포넌트 실행: GitLab 설정의 일부 컴포넌트를 대신 신뢰할 수 있는 클라우드 PaaS 솔루션에서 실행할 수 있습니다. 이를 통해 종속 컴포넌트를 추가로 제거할 수도 있습니다:
    • PostgreSQL: Google Cloud SQL 또는 Amazon RDS와 같은 신뢰할 수 있는 클라우드 PaaS 솔루션에서 실행할 수 있습니다. 이 설정에서는 PgBouncer 및 Consul 노드가 더 이상 필요하지 않습니다:
      • 요구 사항으로 Prometheus 자동 검색이 필요한 경우, 여전히 Consul이 원하는 경우에만 매뉴얼 추가 스크래핑 구성을 모든 노드에 매뉴얼으로 추가해야 합니다.
        • 이 아키텍처에서 Redis Sentinel이 Consul과 동일한 상자에서 실행되기 때문에 Linux 패키지를 사용하여 여전히 Redis를 실행하는 경우 Redis Sentinel을 별도의 상자에서 실행해야 할 수 있습니다.
    • Redis: Google Memorystore 및 AWS ElastiCache와 같은 신뢰할 수 있는 클라우드 PaaS 솔루션에서 실행할 수 있습니다. 이 설정에서 Redis Sentinel이 더 이상 필요하지 않습니다.

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

Kubernetes에서 클라우드 네이티브 GitLab의 일부 컴포넌트를 GitLab Helm 차트로 실행할 수 있습니다. 이 설정에서는 Kubernetes 클러스터에서 GitLab Rails의 동등한 부분인 Webservice를 실행할 수 있습니다. 또한 Kubernetes 클러스터의 Sidekiq라는 부분에 대응하는 Sidekiq 노드를 실행할 수 있으며, 다음과 같은 다른 지원 서비스도 지원됩니다: NGINX, Toolbox, Migrations, Prometheus.

하이브리드 설치는 클라우드 네이티브 워크로드 관리 장점과 Linux 패키지 설치를 사용하여 계산 VM에 배포된 stateful 컴포넌트의 지속성 증가 장점을 활용합니다.

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

note
이것은 고급 설정입니다. Kubernetes에서 서비스를 실행하는 것은 복잡하다고 알려져 있습니다. 이 설정은 Kubernetes에 대해 강력한 작동지식과 경험이 있는 경우에만 권장됩니다. 이 섹션의 나머지 부분은 이 가정에 기초합니다.
caution
Gitaly Cluster를 Kubernetes에서 실행하는 것은 지원되지 않습니다. 자세한 내용은 epic 6127를 참조하세요.

클러스터 구성도

다음 표 및 다이어그램은 하이브리드 환경을 보여주며 기본 환경과 동일한 형식을 사용합니다.

먼저 Kubernetes에서 실행되는 컴포넌트입니다. 이것들은 최소 CPU 및 Memory 요구 사항을 지켜야 함을 제외하고는 전반적인 구성을 원하는 대로 변경할 수 있습니다.

서비스 노드 그룹 노드 구성 GCP AWS 최소 할당 가능 CPU 및 메모리
Webservice 2 16 vCPU, 14.4 GB 메모리 n1-highcpu-16 c5.4xlarge 31.8 vCPU, 24.8 GB 메모리
Sidekiq 3 4 vCPU, 15 GB 메모리 n1-standard-4 m5.xlarge 11.8 vCPU, 38.9 GB 메모리
지원 서비스 2 2 vCPU, 7.5 GB 메모리 n1-standard-2 m5.large 3.9 vCPU, 11.8 GB 메모리
  • 이 설정에 대해서는 권장하며 정기적으로 테스트를 진행합니다 Google Kubernetes Engine (GKE) 및 Amazon Elastic Kubernetes Service (EKS) 을 시험 해보세요. 다른 Kubernetes 서비스도 작동할 수 있지만 결과는 달라질 수 있습니다.
  • 노드 구성은 성능 테스트 중에 vCPU / 메모리 비율을 강제하기 위해 표시되었습니다.
    • 프로덕션 배포에서는 pod을 특정 노드에 할당할 필요가 없습니다. 서로 다른 가용 영역에 3개의 노드가 최소한으로 권장되며 이는 견고한 클라우드 아키텍처 관행과 일치합니다.

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

서비스 노드 구성 GCP AWS
Redis2 3 2 vCU, 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. 일류한 써드파티 로드 밸런서 또는 HA 기능을 제공할 수 있는 서비스 (LB PaaS)에서 실행하는 것이 권장됩니다. 또한 크기 조정은 선택한 로드 밸런서와 네트워크 대역폭과 같은 추가 요소에 따라 다르며 심지어 선택한 Load Balancer와 관련된 자세한 내용은 로드 밸런서를 참조하세요.
  4. 신뢰할 수 있는 클라우드 제공자 및 Self-managed 솔루션에서 실행해야 합니다. 자세한 내용은 개체 리포지터리 구성를 참조하세요.
  5. Gitaly Cluster는 심사코드 용량에 대한 초고 백분위로 정의된 명세입니다. 그러나 큰 모노 리포지터리 (여러 기가바이트 이상) 또는 추가 작업 부하가 있는 경우 Git 및 Gitaly 성능에 큰 영향을 미칠 수 있으며 추가 조정이 필요할 수 있습니다.
note
인스턴스 구성을 구성하는 PaaS 솔루션의 모든 경우에 대해 세 개의 노드를 세 개의 다른 가용 영역에 구현하는 것이 강력하게 권장됩니다.

리소스 사용량 설정

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

웹 서비스

일반적으로 Webservice 파드는 각각 1 CPU와 1.25 GB의 메모리가 필요합니다. 권장 토폴로지를 사용하면 기본적으로 네 개의 워커 프로세스가 생성되고 각 파드에 다른 작은 프로세스가 실행되기 때문에, 각 Webservice 파드는 대략 4 CPU와 5 GB의 메모리를 소비합니다.

3,000 사용자의 경우 대략 16개의 총 Puma 워커 수를 권장합니다. 제공된 권장 사항에 따르면 이를 이용하여 각각 4개의 워커를 가진 4개의 Webservice 파드 및 노드당 2개의 파드를 배포할 수 있습니다. 추가 Webservice 파드 당 1 CPU당 1.25 GB의 메모리 비율을 사용하여 사용 가능한 리소스를 확장할 수 있습니다.

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

Sidekiq

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

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

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

지원

지원 노드 풀은 Webservice 및 Sidekiq 풀에 필요하지 않은 모든 지원 배포를 운영하는 데 사용됩니다.

이에는 Cloud Provider의 구현 및 NGINX 또는 GitLab Shell과 같은 GitLab 배포에 관련된 다양한 배포가 포함됩니다.

모니터링과 같은 추가 배포를 하려면 가능한 경우 해당 풀에 배포하는 것이 권장되며, 이를 통해 Webservice 또는 Sidekiq 풀이 아닌 해당 풀에 명시적으로 설계된 추가 배포를 수용할 수 있습니다. 그러나 제공된 풀에 맞지 않는 배포가 있는 경우 노드 풀을 적절하게 증가시킬 수 있습니다.