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

Tier: Premium, Ultimate Offering: Self-managed

이 페이지에서는 최대 50,000 사용자에 대한 GitLab 참조 아키텍처를 논합니다.

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

note
이 아키텍처를 배포하기 전에 먼저 주요 문서를 읽는 것이 권장됩니다. 특히 시작하기 전에 및 사용할 아키텍처 결정 섹션을 읽어보세요.
  • 대상 부하: API: 1000 RPS, Web: 100 RPS, Git (Pull): 100 RPS, Git (Push): 20 RPS
  • 고가용성: 예 (HA를 위해 Praefect는 HA를 위해 제 3자 PostgreSQL 솔루션 필요)
  • 예상 비용: 비용 표 참조
  • 클라우드 네이티브 하이브리드 대체 옵션: 예
  • 어떤 참조 아키텍처를 사용할지 확신이 안 들면? 더 많은 정보는 여기로 이동
서비스 노드수 구성 GCP AWS Azure
외부 로드 밸런서3 1 16 vCPU, 14.4 GB 메모리 n1-highcpu-16 c5.4xlarge F16s v2
Consul1 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large F2s v2
PostgreSQL1 3 32 vCPU, 120 GB 메모리 n1-standard-32 m5.8xlarge D32s v3
PgBouncer1 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large F2s v2
내부 로드 밸런서3 1 16 vCPU, 14.4 GB 메모리 n1-highcpu-16 c5.4xlarge F16s v2
Redis/Sentinel - Cache2 3 4 vCPU, 15 GB 메모리 n1-standard-4 m5.xlarge D4s v3
Redis/Sentinel - Persistent2 3 4 vCPU, 15 GB 메모리 n1-standard-4 m5.xlarge D4s v3
Gitaly5 3 64 vCPU, 240 GB 메모리6 n1-standard-64 m5.16xlarge D64s v3
Praefect5 3 4 vCPU, 3.6 GB 메모리 n1-highcpu-4 c5.xlarge F4s v2
Praefect PostgreSQL1 1+ 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large F2s v2
Sidekiq7 4 4 vCPU, 15 GB 메모리 n1-standard-4 m5.xlarge D4s v3
GitLab Rails7 12 32 vCPU, 28.8 GB 메모리 n1-highcpu-32 c5.9xlarge F32s v2
모니터링 노드 1 4 vCPU, 3.6 GB 메모리 n1-highcpu-4 c5.xlarge F4s v2
오브젝트 스토리지4 - - - - -

각주:

  1. 믿을 수 있는 제 3자 외부 PaaS PostgreSQL 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 자체 PostgreSQL 인스턴스 제공를 참조하세요.
  2. 믿을 수 있는 제 3자 외부 PaaS Redis 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 자체 Redis 인스턴스 제공를 참조하세요.
    • Redis는 주로 단일 스레드이며 CPU 코어 증가로 인한 혜택이 뚜렷하지 않습니다. 이런 크기의 아키텍처를 위해서는 최적의 성능을 얻기 위해 별도의 캐시 및 지속적인 인스턴스가 필요합니다.
  3. 믿을 수 있는 제 3자 로드 밸런싱 서비스 (LB PaaS)에서 선택적으로 실행할 수 있습니다. 자세한 내용은 권장 클라우드 제공업체 및 서비스를 참조하세요.
  4. 신뢰할 수 있는 클라우드 제공업체 또는 Self-managed 솔루션에서 실행해야 합니다. 자세한 내용은 오브젝트 스토리지 구성를 참조하세요.
  5. Gitaly 클러스터는 장애 허용성의 이점을 제공하지만 설정 및 관리의 복잡성이 추가됩니다. Gitaly 클러스터를 배포하기 전에 기존 기술적인 제약 사항과 고려 사항을 검토하세요. 만약 sharded Gitaly를 원한다면 Gitaly에 대한 동일한 사양을 사용하세요.
  6. Gitaly 사양은 사용량 패턴 및 리포지터리 크기의 상위 백분위에 기반합니다. 그러나 대형 단일 리포지터리 (수 기가바이트 이상)나 추가 작업 부하가 있다면 Git과 Gitaly 성능에 significant한 영향을 줄 수 있으며 추가적인 조정이 필요할 수 있습니다.
  7. 컴포넌트가 상태 데이터를 저장하지 않기 때문에 Auto Scaling 그룹 (ASG)에 배치할 수 있습니다. 그러나 GitLab Rails의 경우 마이그레이션 및 Mailroom과 같은 특정 프로세스는 하나의 노드에만 실행되어야 합니다.
note
인스턴스를 구성하는 PaaS 솔루션의 경우, 견고한 클라우드 아키텍처 관행에 부합하기 위해 최소한 3개의 노드를 서로 다른 가용 영역에 구현하는 것이 강력히 권장됩니다.

요구 사항

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

테스트 방법론

50k 아키텍처는 대부분의 워크플로를 커버하기 위해 설계되었으며 정기적으로 흡연 및 성능이 검증 및 테스트되며 품질 공학 팀에 의해 다음 엔드포인트 처리량 목표에 대해 테스트됩니다:

  • API: 1000 RPS
  • 웹: 100 RPS
  • Git (풀): 100 RPS
  • Git (푸시): 20 RPS

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

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

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

테스트에 사용된 로드 밸런서는 HAProxy(리눅스 패키지 환경) 또는 클라우드 네이티브 하이브리드를 위해 동등한 클라우드 공급자 서비스를 통한 NGINX Ingress였습니다. 이 선택 사항들은 특정 요구 사항이나 권장 사항을 나타내는 것으로 보지 않아야 합니다. 대부분의 신뢰할 수 있는 로드 밸런서들은 작동할 것으로 예상됩니다.

컴포넌트 설정

GitLab 및 해당 컴포넌트를 최대 50,000 사용자까지 수용하도록 설정하기 위해:

  1. 외부 로드 밸런서 구성 GitLab 응용 프로그램 서비스 노드의 부하 분산을 처리합니다.
  2. 내부 로드 밸런서 구성. 부하를 처리
  3. Consul 구성.
  4. GitLab의 데이터베이스인 PostgreSQL 구성.
  5. PgBouncer 구성.
  6. Redis 구성.
  7. Gitaly 클러스터 구성, Git 리포지터리에 대한 액세스를 제공합니다.
  8. Sidekiq 구성.
  9. 메인 GitLab Rails 응용 프로그램(GitLab Rails 구성)을 구성하여 Puma, Workhorse, GitLab Shell을 실행하고 모든 프론트엔드 요청(UI, API, 및 Git over HTTP/SSH 포함)을 제공합니다.
  10. Prometheus 구성을 사용하여 GitLab 환경을 모니터링합니다.
  11. 공유 데이터 오브젝트에 사용되는 객체 리포지터리 구성
  12. 빠르고 더 고급 코드 검색을 위한 고급 검색 구성 (선택 사항).

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

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

  • 10.6.0.10: 외부 로드 밸런서
  • 10.6.0.11: Consul 1
  • 10.6.0.12: Consul 2
  • 10.6.0.13: Consul 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.40: 내부 로드 밸런서
  • 10.6.0.51: Redis - 캐시 프라이머리
  • 10.6.0.52: Redis - 캐시 레플리카 1
  • 10.6.0.53: Redis - 캐시 레플리카 2
  • 10.6.0.61: Redis - 지속적인 프라이머리
  • 10.6.0.62: Redis - 지속적인 레플리카 1
  • 10.6.0.63: Redis - 지속적인 레플리카 2
  • 10.6.0.91: Gitaly 1
  • 10.6.0.92: 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: 프라펙트 PostgreSQL 1 (HA 아님)
  • 10.6.0.101: Sidekiq 1
  • 10.6.0.102: Sidekiq 2
  • 10.6.0.103: Sidekiq 3
  • 10.6.0.104: Sidekiq 4
  • 10.6.0.111: GitLab 응용 프로그램 1
  • 10.6.0.112: GitLab 응용 프로그램 2
  • 10.6.0.113: GitLab 응용 프로그램 3
  • 10.6.0.114: GitLab 응용 프로그램 4
  • 10.6.0.115: GitLab 응용 프로그램 5
  • 10.6.0.116: GitLab 응용 프로그램 6
  • 10.6.0.117: GitLab 응용 프로그램 7
  • 10.6.0.118: GitLab 응용 프로그램 8
  • 10.6.0.119: GitLab 응용 프로그램 9
  • 10.6.0.120: GitLab 응용 프로그램 10
  • 10.6.0.121: GitLab 응용 프로그램 11
  • 10.6.0.122: GitLab 응용 프로그램 12
  • 10.6.0.151: 프로메테우스

외부 로드 밸런서 구성

다중 노드 GitLab 구성에서는 응용 프로그램 서버로의 트래픽을 라우팅하기 위해 외부 로드 밸런서가 필요합니다.

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

준비 확인

외부 로드 밸런서가 모니터링 엔드포인트가 포함된 작동하는 서비스로만 라우팅하도록합니다. 준비 확인은 모두 추가 구성을 요구하며, 그렇지 않으면 외부 로드 밸런서가 연결할 수 없습니다.

포트

사용할 기본 포트는 아래 표에 표시됩니다.

LB Port Backend Port Protocol
80 80 HTTP (1)
443 443 TCP 또는 HTTPS (1) (2)
22 22 TCP
  • (1): 웹 터미널 지원을 위해서는 로드 밸런서가 WebSocket 연결을 올바르게 처리해야 합니다. HTTP 또는 HTTPS 프록시 사용 시 로드 밸런서는 Connection 및 Upgrade hop-by-hop header를 통과시킬 수있도록 구성되어야 합니다. 자세한 내용은 웹 터미널 통합 가이드를 참조하십시오.
  • (2): 포트 443에 HTTPS 프로토콜을 사용하는 경우 로드 밸런서에 SSL 인증서를 추가해야 합니다. GitLab 응용 프로그램 서버에서 SSL을 해제하려면 TCP 프로토콜을 사용하십시오.

커스텀 도메인 지원과 함께 GitLab Pages를 사용하는 경우 몇 가지 추가 포트 구성이 필요합니다. GitLab Pages에는 별도의 가상 IP 주소가 필요합니다. /etc/gitlab/gitlab.rb의 pages_external_url을 새 가상 IP 주소로 지정하기위해 DNS를 구성하십시오. 자세한 내용은 GitLab Pages 문서를 참조하십시오.

LB Port Backend Port Protocol
80 Varies (1) HTTP
443 Varies (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 Port Backend Port Protocol
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 (Gitaly 클러스터)에 대한 연결과 같이 선택한 내부 구성요소를위한 트래픽을 라우팅하기 위해 내부 로드 밸런서가 필요합니다.

사용할 로드 밸런서 또는 정확한 구성에 대한 구체적인 내용은 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

더 많은 지침을 위해서는 선호하는 로드 밸런서의 문서를 참조하십시오.

Consul 구성

다음으로, Consul 서버를 설정합니다.

note
Consul은 홀수 개수인 3개 이상의 노드에 배포되어야 합니다. 이는 노드가 과반수 투표를 할 수 있도록 보장하기 위한 것입니다.

다음 IP들은 예시로 사용됩니다:

  • 10.6.0.11: Consul 1
  • 10.6.0.12: Consul 2
  • 10.6.0.13: Consul 3

Consul을 구성하려면:

  1. Consul을 호스팅할 서버에 SSH로 로그인합니다.
  2. 선택한 Linux 패키지를 다운로드하고 설치합니다. 페이지의 설치 단계 1과 2를 따로 따르고, 현재 설치된 것과 동일한 버전 및 유형(Community 또는 Enterprise 버전)의 올바른 Linux 패키지를 선택해야 합니다.

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

    roles(['consul_role'])
   
## 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'
   
# 업그레이드 시 자동으로 데이터베이스 마이그레이션을 방지합니다
gitlab_rails['auto_migrate'] = false

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

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

  6. 다른 Consul 노드에 대해 동일한 단계를 다시 진행하고, 올바른 IP를 설정했는지 확인합니다.

Consul 리더는 세 번째 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

PostgreSQL 구성

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

자체 PostgreSQL 인스턴스 제공

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

이를 위해서는 신뢰할 수 있는 제공업체나 솔루션이 필요합니다. Google Cloud SQL 및 Amazon RDS는 알려져 있습니다. 그러나 Amazon Aurora는 14.4.0부터 기본적으로 활성화된 로드 밸런싱과 호환되지 않습니다. 더 많은 정보를 원하실 경우 추천되는 클라우드 제공업체 및 서비스를 참조하십시오.

제3자 외부 서비스를 사용하는 경우:

  1. 제3자 외부 서비스를 사용할 때는 HA Linux 패키지 PostgreSQL 설정이 PostgreSQL, PgBouncer 및 Consul을 포함하지 않게 됩니다.
  2. 데이터베이스 요구 사항 문서에 따라 PostgreSQL을 설정합니다.
  3. 선택한 비밀번호로 gitlab 사용자를 설정합니다. gitlab 사용자는 gitlabhq_production 데이터베이스를 생성할 권한이 필요합니다.
  4. GitLab 애플리케이션 서버를 적절한 세부 정보로 구성합니다. 이 단계는 GitLab 레일 애플리케이션 구성에서 다룹니다.
  5. 서비스의 HA를 위해 필요한 노드 수는 Linux 패키지와 비교해서 다를 수 있으며, ‌해당 서비스에 따라 일치할 필요가 없습니다.
  6. 그러나 더 나은 성능을 위해 Read Replicas를 통한 데이터베이스 로드 밸런싱이 필요한 경우, 참조 아키텍처에 대한 노드 수를 따르는 것이 권장됩니다.

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 패키지 리포지터리를 추가합니다. 두 번째 단계에서는 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 외의 모든 컴포넌트 비활성화
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['enable'] = true
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>'
   
# Network Address로 10.6.0.0/24 치환
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 복제 방법을 참조하세요.

  1. 처음에 구성한 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 해당 서버의 동일한 이름의 파일을 추가하거나 바꿉니다. 이것이 처음 구성하는 Linux 패키지 노드이면 이 단계는 건너뛸 수 있습니다.

  2. 변경 사항이 적용되려면 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)
}
   
# 프로메테우스를 위한 서비스 디스커버리 활성화
consul['monitoring_service_discovery'] = true
   
# 익스포터가 수신 대기할 네트워크 주소 설정
node_exporter['listen_address'] = '0.0.0.0:9100'

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

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

    execute[generate databases.ini] 오류가 발생하면, 이는 기존의 알려진 문제로 인합니다. 다음 단계 이후에 두 번째 reconfigure를 실행하면 이 문제가 해결될 것입니다.

  4. Consul이 PgBouncer를 리로드할 수 있도록 .pgpass 파일을 생성하세요. 두 번 물어보면 PgBouncer 패스워드를 입력하세요: 

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

  5. 이전 단계에서 발생한 잠재적 오류를 해결하기 위해 GitLab을 다시 구성하세요.

  6. 각 노드가 현재 주(primary)에 연결되어 있는지 확인하세요: 

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

  7. 콘솔 프롬프트가 사용 가능한 상태가 되면, 다음 쿼리를 실행하세요: 

    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)

Redis 구성

확장 가능한 환경에서 Redis를 사용하기 위해 Primary x Replica 형태의 토폴로지와 Redis Sentinel 서비스를 사용하여 자동으로 장애 조치 프로시저를 시작할 수 있습니다.

note
Redis 클러스터는 각각 홀수 개의 3 개 이상의 노드로 배포되어야 합니다. 이는 Redis Sentinel이 쿼럼의 일부로 투표를 할 수 있도록 보장하기 위함입니다. 클라우드 제공 업체 서비스와 같이 외부에서 Redis를 구성하는 경우에는 해당되지 않습니다.
note
Redis는 주로 단일 스레드이며 CPU 코어 수가 증가함으로써 크게 이점을 얻지 못합니다. 이런 크기의 아키텍처에 대해서는 최적의 성능을 얻기 위해 별도의 캐시 및 지속적인 인스턴스를 갖는 것이 강력히 권장됩니다. 자세한 정보는 스케일링 문서를 참조하세요.

Sentinel을 사용하는 경우, Redis에는 인증이 필요합니다. 더 많은 정보를 원하신다면 Redis 보안 문서를 살펴보세요. Redis 서비스를 보호하기 위해 Redis 패스워드와 엄격한 방화벽 규칙의 조합을 사용하는 것을 권장합니다. Redis를 GitLab과 구성하기 전에 Redis Sentinel 문서를 자세히 읽는 것을 강력히 권장합니다.

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

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

이번 섹션에서는 GitLab과 함께 사용할 두 개의 외부 Redis 클러스터를 구성하는 방법에 대해 안내하겠습니다. 다음 IP 주소들은 예시로 사용됩니다:

  • 10.6.0.51: Redis - Cache Primary
  • 10.6.0.52: Redis - Cache Replica 1
  • 10.6.0.53: Redis - Cache Replica 2
  • 10.6.0.61: Redis - Persistent Primary
  • 10.6.0.62: Redis - Persistent Replica 1
  • 10.6.0.63: Redis - Persistent Replica 2

자체 Redis 인스턴스 제공

다음 안내를 따라 외부에서 관리되는 서드파티 Redis 캐시 및 지속성 인스턴스를 선택적으로 사용할 수 있습니다.

  • 신뢰할 수 있는 제공업체 또는 솔루션을 사용해야 합니다. Google Memorystore 및 AWS ElastiCache가 작동하는 것으로 알려져 있습니다.
  • Redis 클러스터 모드는 특별히 지원되지 않지만, Redis 스탠드얼론 및 HA(High Availability)가 지원됩니다.
  • 설정에 따라 Redis 제거 모드를 설정해야 합니다.

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

Redis Cache 클러스터 구성

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

기본 및 복제 Redis 노드는 동일한 비밀번호를 redis['password']로 정의해야 합니다. 장애 조치(failover) 중에 언제든지 Sentinels가 노드를 다시 구성하고 해당 상태를 기본 또는 복제(그 반대도)로 변경할 수 있습니다.

기본 Redis 캐시 노드 구성

  1. 기본 Redis 서버에 SSH로 접속합니다.
  2. Linux 패키지를 다운로드 및 설치합니다. 페이지의 설치 단계 1과 2를 따르고, 현재 설치와 동일한 버전 및 유형(커뮤니티 또는 엔터프라이즈 에디션)을 선택해야 합니다.

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

    # Sentinel과 Consul 에이전트를 활성화하여 서버 역할을 'redis_master_role'로 지정합니다.
roles(['redis_sentinel_role', 'redis_master_role', 'consul_role'])
   
# Redis Sentinel 서비스에 대한 IP 바인드 주소 및 Quorum 번호를 설정합니다.
sentinel['bind'] = '0.0.0.0'
sentinel['quorum'] = 2
   
# 다른 컴퓨터에서 접속할 수 있는 로컬 IP를 가리키는 IP 주소입니다.
redis['bind'] = '10.6.0.51'
   
# Redis가 TCP 요청을 수신하도록 포트를 정의합니다.
redis['port'] = 6379
   
## Sentinel을 위한 기본 Redis 서버의 포트, 기본값에서 변경하려면 주석 처리합니다. 기본 값은 `6379`입니다.
#redis['master_port'] = 6379
   
# Redis 및 복제본에 대한 비밀번호 인증 설정(모든 노드에서 동일한 비밀번호를 사용합니다).
redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'
   
## 각 Redis 노드에서 동일해야 합니다.
redis['master_name'] = 'gitlab-redis-cache'
   
## 이 기본 Redis 노드의 IP
redis['master_ip'] = '10.6.0.51'
   
# Redis 캐시 인스턴스를 LRU로 설정합니다.
# 사용 가능한 RAM의 90%를 MB 단위로 지정합니다.
redis['maxmemory'] = '13500mb'
redis['maxmemory_policy'] = "allkeys-lru"
redis['maxmemory_samples'] = 5
   
## 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.51:6379',
     'redis.password' => 'redis-password-goes-here',
}
   
# 업그레이드 시 자동으로 데이터베이스 마이그레이션을 실행하지 않도록 설정합니다.
gitlab_rails['auto_migrate'] = false

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

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

복제본 Redis 캐시 노드 구성

  1. 복제본 Redis 서버에 SSH로 접속합니다.
  2. Linux 패키지를 다운로드 및 설치합니다. 페이지의 설치 단계 1과 2를 따르고, 현재 설치와 동일한 버전 및 유형(커뮤니티 또는 엔터프라이즈 에디션)을 선택해야 합니다.

  3. /etc/gitlab/gitlab.rb를 편집하고 이전 섹션의 기본 노드와 동일한 내용을 추가합니다. 다만, redis_master_node를 redis_replica_node로 대체합니다. 

    # Sentinel 및 Consul 에이전트를 활성화하여 서버 역할을 'redis_replica_role'로 지정합니다.
roles(['roles_sentinel_role', 'redis_replica_role', 'consul_role'])
   
# Redis Sentinel 서비스에 대한 IP 바인드 주소 및 Quorum 번호를 설정합니다.
sentinel['bind'] = '0.0.0.0'
sentinel['quorum'] = 2
   
# 다른 컴퓨터에서 접속할 수 있는 로컬 IP를 가리키는 IP 주소입니다.
redis['bind'] = '10.6.0.52'
   
# Redis가 TCP 요청을 수신하도록 포트를 정의합니다.
redis['port'] = 6379
   
## Sentinel을 위한 기본 Redis 서버의 포트, 기본값에서 변경하려면 주석 처리합니다. 기본 값은 `6379`입니다.
#redis['master_port'] = 6379
   
# Redis 및 복제본에 대한 비밀번호 인증 설정(모든 노드에서 동일한 비밀번호를 사용합니다).
redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER'
   
## 각 Redis 노드에서 동일해야 합니다.
redis['master_name'] = 'gitlab-redis-cache'
   
## 기본 Redis 노드의 IP
redis['master_ip'] = '10.6.0.51'
   
# Redis 캐시 인스턴스를 LRU로 설정합니다.
# 사용 가능한 RAM의 90%를 MB 단위로 지정합니다.
redis['maxmemory'] = '13500mb'
redis['maxmemory_policy'] = "allkeys-lru"
redis['maxmemory_samples'] = 5
   
## 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.52:6379',
     'redis.password' => 'redis-password-goes-here',
}
   
# 업그레이드 시 자동으로 데이터베이스 마이그레이션을 실행하지 않도록 설정합니다.
gitlab_rails['auto_migrate'] = false

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

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

    3. 다른 복제본 노드에 대해 위 단계를 모두 다시 실행하고, IP를 올바르게 설정해야 합니다.

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

Redis Persistent 클러스터 구성

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

기본 및 레플리카 Redis 노드는 언제든지 장애 조치(failover) 중에 Sentinels가 노드를 다시 구성하고 해당 노드의 상태를 기본에서 레플리카로 변경(또는 그 반대)할 수 있도록 동일한 redis['password']를 필요로 합니다.

기본 Redis Persistent 노드 구성

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

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

    # 'redis_master_role'로 서버 역할 지정 및 Sentinel과 Consul 에이전트 활성화
roles ['redis_sentinel_role', 'redis_master_role', 'consul_role']
   
# Redis Sentinel 서비스에 대한 IP 바인드 주소 및 쿼러럼 번호 지정
sentinel['bind'] = '0.0.0.0'
sentinel['quorum'] = 2
   
# 다른 기계에서 접근할 수 있는 로컬 IP를 가리키는 IP 주소 지정
# '0.0.0.0'을 바인드할 수도 있으며 모든 인터페이스에서 수신 대기를 활성화합니다.
# 외부 접근 가능한 IP에 바인드해야 하는 경우,
# 무단 접근을 방지하기 위해 추가 방화벽 규칙을 추가해야 합니다.
redis['bind'] = '10.6.0.61'
   
# 다른 기계에서 연결할 수 있도록 Redis가 TCP 요청을 수신할 수 있는 포트 지정
redis['port'] = 6379
   
## Sentinel을 위한 기본 Redis 서버 포트, 기본값을 변경하려면 주석 해제. 기본값은 `6379`입니다.
#redis['master_port'] = 6379
   
# Redis 및 레플리카에 대한 패스워드 인증 설정(모든 노드에서 동일한 패스워드 사용)
redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
   
## 각 Redis 노드에서 동일해야 합니다
redis['master_name'] = 'gitlab-redis-persistent'
   
## 이 기본 Redis 노드의 IP
redis['master_ip'] = '10.6.0.61'
   
## 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'
   
# 업그레이드 시 자동으로 데이터베이스 마이그레이션 실행 방지
gitlab_rails['auto_migrate'] = false

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

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

레플리카 Redis Persistent 노드 구성

  1. 레플리카 Redis Persistent 서버에 SSH로 로그인합니다.
  2. 선택한 Linux 패키지를 다운로드하고 설치합니다. 페이지에서 설치 단계 1과 2만 따르고 현재 설치된 버전 및 유형(Community 또는 Enterprise Edition)과 동일한 Linux 패키지를 선택해야 합니다.

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

    # 'redis_replica_role'로 서버 역할 지정 및 Sentinel과 Consul 에이전트 활성화
roles ['redis_sentinel_role', 'redis_replica_role', 'consul_role']
   
# Redis Sentinel 서비스에 대한 IP 바인드 주소 및 쿼러럼 번호 지정
sentinel['bind'] = '0.0.0.0'
sentinel['quorum'] = 2
   
# 다른 기계에서 접근할 수 있는 로컬 IP를 가리키는 IP 주소 지정
# '0.0.0.0'을 바인드할 수도 있으며 모든 인터페이스에서 수신 대기를 활성화합니다.
# 외부 접근 가능한 IP에 바인드해야 하는 경우,
# 무단 접근을 방지하기 위해 추가 방화벽 규칙을 추가해야 합니다.
redis['bind'] = '10.6.0.62'
   
# 다른 기계에서 연결할 수 있도록 Redis가 TCP 요청을 수신할 수 있는 포트 지정
redis['port'] = 6379
   
## Sentinel을 위한 기본 Redis 서버 포트, 기본값을 변경하려면 주석 해제. 기본값은 `6379`입니다.
#redis['master_port'] = 6379
   
# 기본 노드에 대해 설정한 Redis를 위한 동일한 패스워드 사용
redis['password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'
   
## 각 Redis 노드에서 동일해야 합니다
redis['master_name'] = 'gitlab-redis-persistent'
   
# 기본 Redis 노드의 IP
redis['master_ip'] = '10.6.0.61'
   
## 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'
   
# 업그레이드 시 자동으로 데이터베이스 마이그레이션 실행 방지
gitlab_rails['auto_migrate'] = false

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

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

  6. 다른 레플리카 노드에 대해 다시 단계를 거쳐 올바른 IP를 설정하는지 확인합니다.

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

Gitaly 클러스터 구성

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

caution
Gitaly 사양은 사용 패턴 및 리포지터리 크기의 높은 백분위 수에 기반합니다. 그러나 대형 모노레포 (여러 기가바이트보다 큰)나 추가 작업량이 있는 경우 환경의 성능에 중대한 영향을 미칠 수 있으며 추가 조정이 필요할 수 있습니다. 해당되는 경우 링크된 설명서를 참조하고 추가 지침을 위해 고객 성공 관리자나 지원팀에 문의하는 것이 강력히 권장됩니다.

Gitaly 클러스터는 고장 허용의 장점을 제공하지만, 설정 및 관리의 복잡성이 추가됩니다. Gitaly 클러스터를 배포하기 전에 기술적 제한 사항과 고려 사항을 검토하십시오.

안내: - Sharded Gitaly로 구현하려면, 별도의 Gitaly 설명서 대신 이 섹션을 사용하십시오. 동일한 Gitaly 사양을 사용하세요. - Gitaly 클러스터에서 관리되지 않는 기존 리포지터리를 마이그레이션하려면 Gitaly 클러스터로 이동을 참조하십시오.

권장 클러스터 구성은 다음 컴포넌트를 포함합니다:

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

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

Praefect PostgreSQL 구성

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

고가용성 환경을 갖추고 싶다면, Praefect에는 제3자 PostgreSQL 데이터베이스가 필요합니다. 내장 솔루션이 진행 중입니다.

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

다음 IP를 예시로 사용합니다:

  • 10.6.0.141: Praefect PostgreSQL

먼저, Praefect PostgreSQL 노드에 Linux GitLab 패키지를 설치하십시오. 1단계의 스텝에 따라 필요한 의존성을 설치하고 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
# 필요한 정보 섹션에 설명된대로 실제 값으로 설정하십시오
#
# 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 설정 에서 보듯이, 완전한 고가용성을 위해 Praefect의 데이터베이스에 대한 타사 PostgreSQL 솔루션이 권장됩니다.

PostgreSQL HA를 위한 여러 타사 솔루션이 있습니다. Praefect와 함께 사용하려면 다음이 지원되어야 합니다:

  • 장애 조치(failover) 시 변경되지 않는 모든 연결을 위한 정적 IP.
  • LISTEN SQL 기능이 지원되어야 함.
note
타사 설정에서 편리성을 위해 본 GitLab 데이터베이스와 Praefect 데이터베이스를 동일한 서버에 함께 두는 것이 가능합니다. 그러나 복제를 올바르게 처리하기 위해 별도의 데이터베이스 인스턴스가 필요한 Geo를 사용하는 경우를 제외하고는, 본 데이터베이스 세팅의 영향은 최소화되어서 그대로 유지됩니다.

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

위 내용에 해당하는 예로 Google의 Cloud SQL 또는 Amazon RDS를 들 수 있습니다.

데이터베이스가 설정되면 포스트 구성을 따르세요.

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. 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에 대한 모든 연결은 이를 통해 이루어집니다. 이 섹션에서는 Praefect의 구성 방법에 대해 자세히 설명합니다.

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

Praefect에는 클러스터 전체 통신을 보안하는 데 필요한 여러 비밀 토큰이 필요합니다:

  • <praefect_external_token>: Gitaly 클러스터에 호스팅된 리포지터리에 사용되며, 이 토큰을 보유한 Gitaly 클라이언트만 접근할 수 있습니다.
  • <praefect_internal_token>: Gitaly 클러스터 내부의 복제 트래픽에 사용됩니다. 이 토큰은 praefect_external_token과 구분되어야 하며, Gitaly 클라이언트가 Praefect 클러스터의 내부 노드에 직접 액세스하지 못하게 해야 합니다.

Gitaly 클러스터 노드는 가상 스토리지를 통해 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. 선택한 리눅스 패키지를 다운로드하고 설치합니다. 페이지의 설치 단계 1과 2만을 따르도록 하세요.

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

    note
    GitLab에서 요구하는 대로 virtual_storages의 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 구성
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 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 구성
   # 스토리지 이름의 해시는 GitLab의 git_data_dirs('praefect')에서와 Gitaly 노드('gitaly-1')에서 gitaly['configuration'][:storage]와 일치해야 합니다
   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는 본 데이터베이스 응용프로그램과 마찬가지로 일부 데이터베이스 마이그레이션을 실행해야 합니다. 이를 위해 데이터베이스 마이그레이션이 하나의 Praefect 노드에서만 실행되어야 합니다. 이 노드는 _배포 노드_로 설정되어야 하며, 다음과 같이 구성해야 합니다:

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

    2. 업그레이드 중에 데이터베이스 마이그레이션이 자동으로 실행되지 않도록 하려면 다음을 실행하세요: 

    sudo touch /etc/gitlab/skip-auto-reconfigure
    1. 변경 사항이 적용되고 Praefect 데이터베이스 마이그레이션을 실행하려면 GitLab을 재구성하세요.
  6. 변경 사항이 적용되도록 다른 Praefect 노드에 대해 GitLab을 다시 구성합니다.

Gitaly 구성

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

caution
Gitaly 사양은 사용 패턴과 리포지터리 크기의 높은 백분위수에 기반합니다. 그러나 대형 단일 리포지터리 (수 기가바이트보다 큰) 또는 추가 작업 부하가 있는 경우 환경의 성능에 상당한 영향을 미칠 수 있으며 추가 조정이 필요할 수 있습니다. 이 경우 연결된 설명서를 참조하고 추가 지침을 위해 고객 성공 관리자 또는 지원 팀에 문의하는 것이 매우 권장됩니다.

Gitaly는 상당한 입력 및 출력 요구 사항이 있기 때문에 모든 Gitaly 노드에서는 SSD(Solid-State Drive)를 사용하는 것이 강력히 권장됩니다. 이러한 SSD는 읽기 작업에 대해 최소 8,000 IOPS, 쓰기 작업에 대해 최소 2,000 IOPS의 처리량이 있어야 합니다. 클라우드 제공 업체에서 환경을 실행 중인 경우 올바른 IOPS 구성 방법에 대해 그들의 설명서를 참조하세요.

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
   
# Gitlab Rails 내부 API 콜백 URL을 구성합니다. 이렇게 하지 않으면 `git push`가 실패합니다. 이것은 '전면 문' GitLab URL 또는 내부 로드 밸런서가 될 수 있습니다.
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
   
# Gitaly
gitaly['enable'] = true
   
# 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',
   auth: {
      # Gitaly 인증 토큰
      # prafect_internal_token과 동일해야 합니다
      token: '<praefect_internal_token>',
   },
   pack_objects_cache: {
      # Gitaly Pack-objects 캐시
      # 성능을 향상시키기 위해 활성화하는 것이 권장되지만 디스크 I/O를 상당히 증가시킬 수 있습니다
      # 자세한 내용은 https://docs.gitlab.com/ee/administration/gitaly/configure_gitaly.html#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. 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 같은 이름의 파일을 추가하거나 교체하세요. 이것이 구성하는 첫 번째 Linux 패키지 노드인 경우 이 단계는 건너뛰어도 됩니다.

  5. 파일을 저장한 후 GitLab을 다시 구성합니다.

Gitaly Cluster TLS 지원

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

  • GitLab 구성에서 해당 리포지터리 항목의 gitaly_address에 tls:// URL 스킴을 사용합니다.
  • 자체 인증서를 제공하지 않기 때문에 인증서를 직접 가져와야 합니다. 각 Praefect 서버에 해당하는 인증서를 설치해야 합니다.

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

다음 사항에 유의하세요:

  • 인증서는 Praefect 서버에 액세스하는 데 사용하는 주소를 지정해야 합니다. 호스트 이름 또는 IP 주소를 인증서의 대체 이름으로 추가해야 합니다.
  • 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. 파일을 저장하고 GitLab을 다시 구성하세요.

  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 대신 객체 리포지터리를 사용하는 것이 권장되므로, 다음 예제에는 객체 리포지터리 구성이 포함됩니다.
note
환경의 Sidekiq 작업 처리가 큐가 길고 느리게 진행된다고 판명되면 적절하게 확장할 수 있습니다. 자세한 내용은 확장 문서를 참조하세요.
  • 10.6.0.101: Sidekiq 1
  • 10.6.0.102: Sidekiq 2
  • 10.6.0.103: Sidekiq 3
  • 10.6.0.104: Sidekiq 4

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 연결 세부 정보
## 캐시 데이터를 호스팅할 첫 번째 클러스터
gitlab_rails['redis_cache_instance'] = 'redis://:<REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER>@gitlab-redis-cache'
   
gitlab_rails['redis_cache_sentinels'] = [
  {host: '10.6.0.51', port: 26379},
  {host: '10.6.0.52', port: 26379},
  {host: '10.6.0.53', port: 26379},
]
   
## 모든 다른 지속 데이터를 호스팅할 두 번째 클러스터
redis['master_name'] = 'gitlab-redis-persistent'
redis['master_password'] = '<REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER>'
   
gitlab_rails['redis_sentinels'] = [
  {host: '10.6.0.61', port: 26379},
  {host: '10.6.0.62', port: 26379},
  {host: '10.6.0.63', 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.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
   
# 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.151/32', '127.0.0.0/8']
   
# 객체 리포지터리
## 이것은 GCP에서 객체 리포지터리를 구성하는 예시입니다.
## 지정한 객체 리포지터리 제공자로 이 구성을 바꿔치기하세요.
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['object_store']['objects']['artifacts']['bucket'] = "<gcp-artifacts-bucket-name>"
gitlab_rails['object_store']['objects']['external_diffs']['bucket'] = "<gcp-external-diffs-bucket-name>"
gitlab_rails['object_store']['objects']['lfs']['bucket'] = "<gcp-lfs-bucket-name>"
gitlab_rails['object_store']['objects']['uploads']['bucket'] = "<gcp-uploads-bucket-name>"
gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
   
gitlab_rails['backup_upload_connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
   
gitlab_rails['ci_secure_files_object_store_enabled'] = true
gitlab_rails['ci_secure_files_object_store_remote_directory'] = "gcp-ci_secure_files-bucket-name"
   
gitlab_rails['ci_secure_files_object_store_connection'] = {
   'provider' => 'Google',
   'google_project' => '<gcp-project-name>',
   'google_json_key_location' => '<path-to-gcp-service-account-key>'
}

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

  5. 업그레이드 시에 자동으로 데이터베이스 마이그레이션이 실행되지 않도록 하려면 다음을 실행하세요: 

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

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

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

GitLab Rails 구성

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

Rails는 Redis, PostgreSQL, Gitaly 인스턴스에 대한 연결을 필요로 합니다. 또한 권장 사항으로 Object Storage에 대한 연결도 필요합니다.

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

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

  • 10.6.0.111: GitLab 애플리케이션 1
  • 10.6.0.112: GitLab 애플리케이션 2
  • 10.6.0.113: GitLab 애플리케이션 3
  • 10.6.0.114: GitLab 애플리케이션 4
  • 10.6.0.115: GitLab 애플리케이션 5
  • 10.6.0.116: GitLab 애플리케이션 6
  • 10.6.0.117: GitLab 애플리케이션 7
  • 10.6.0.118: GitLab 애플리케이션 8
  • 10.6.0.119: GitLab 애플리케이션 9
  • 10.6.0.120: GitLab 애플리케이션 10
  • 10.6.0.121: GitLab 애플리케이션 11
  • 10.6.0.122: GitLab 애플리케이션 12

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

  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 연결 세부 정보
## 캐시 데이터를 호스팅하는 첫 번째 클러스터
gitlab_rails['redis_cache_instance'] = 'redis://:<REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER>@gitlab-redis-cache'
   
gitlab_rails['redis_cache_sentinels'] = [
  {host: '10.6.0.51', port: 26379},
  {host: '10.6.0.52', port: 26379},
  {host: '10.6.0.53', port: 26379},
]
   
## 모든 기타 영구 데이터를 호스팅하는 두 번째 클러스터
redis['master_name'] = 'gitlab-redis-persistent'
redis['master_password'] = '<REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER>'
   
gitlab_rails['redis_sentinels'] = [
  {host: '10.6.0.61', port: 26379},
  {host: '10.6.0.62', port: 26379},
  {host: '10.6.0.63', port: 26379},
]
   
# 모니터링에 사용되는 수출기가 청취할 네트워크 주소를 설정합니다.
node_exporter['listen_address'] = '0.0.0.0:9100'
gitlab_workhorse['prometheus_listen_addr'] = '0.0.0.0:9229'
puma['listen'] = '0.0.0.0'
   
# 모니터링 노드의 IP 주소를 모니터링 화이트리스트에 추가하고
# NGINX 메트릭을 수집할 수 있도록 허용합니다.
gitlab_rails['monitoring_whitelist'] = ['10.6.0.151/32', '127.0.0.0/8']
nginx['status']['options']['allow'] = ['10.6.0.151/32', '127.0.0.0/8']
   
#############################
###     객체 리포지터리      ###
#############################
   
# 이것은 GCP에 대한 객체 리포지터리를 설정하는 예제입니다
# 원하는 객체 리포지터리 제공업체로 이 구성을 교체합니다
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
gitlab_rails['object_store']['objects']['artifacts']['bucket'] = "<gcp-artifacts-bucket-name>"
gitlab_rails['object_store']['objects']['external_diffs']['bucket'] = "<gcp-external-diffs-bucket-name>"
gitlab_rails['object_store']['objects']['lfs']['bucket'] = "<gcp-lfs-bucket-name>"
gitlab_rails['object_store']['objects']['uploads']['bucket'] = "<gcp-uploads-bucket-name>"
gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
   
gitlab_rails['backup_upload_connection'] = {
  'provider' => 'Google',
  'google_project' => '<gcp-project-name>',
  'google_json_key_location' => '<path-to-gcp-service-account-key>'
}
   
gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
gitlab_rails['ci_secure_files_object_store_enabled'] = true
gitlab_rails['ci_secure_files_object_store_remote_directory'] = "gcp-ci_secure_files-bucket-name"
   
gitlab_rails['ci_secure_files_object_store_connection'] = {
   'provider' => 'Google',
   'google_project' => '<gcp-project-name>',
   'google_json_key_location' => '<path-to-gcp-service-account-key>'
}

  3. TLS 서포트를 사용하는 Gitaly를 사용 중이라면 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. 데이터베이스 마이그레이션이 업그레이드시 자동으로 실행되지 않도록 하려면 다음을 실행합니다: 

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

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

  6. 변경 사항이 적용되려면 GitLab 재구성을 수행합니다.
  7. Incremental 로깅을 활성화합니다.

  8. 노드가 Gitaly에 연결할 수 있는지 확인합니다: 

    sudo gitlab-rake gitlab:gitaly:check

    그런 다음 요청을 보기 위해 로그를 확인합니다: 

    sudo gitlab-ctl tail gitaly
  9. 선택적으로 Gitaly 서버에서 Gitaly가 내부 API로 콜백을 수행할 수 있는지 확인합니다:
    • GitLab 15.3 이상의 경우 sudo /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml 실행
    • GitLab 15.2 및 이전의 경우 sudo /opt/gitlab/embedded/bin/gitaly-hooks check /var/opt/gitlab/gitaly/config.toml 실행

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

GitLab Rails 포스트 구성

  1. 설치 및 업데이트 중 데이터베이스 마이그레이션을 실행할 응용 프로그램 노드를 지정합니다. GitLab 데이터베이스를 초기화하고 모든 마이그레이션이 실행되었는지 확인하세요: 

    sudo gitlab-rake gitlab:db:configure

    레일스 노드가 주 데이터베이스에 직접 연결하도록 구성되어 있어야 합니다. 마이그레이션이 완료되면 노드를 다시 PgBouncer를 통과하도록 구성해야 합니다. PgBouncer 우회에 관한 정보입니다.

  2. 데이터베이스에서 인증된 SSH 키를 빠르게 조회하도록 구성합니다.(링크 참조)

프로메테우스 구성

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

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

  • 10.6.0.151: 프로메테우스

모니터링 노드를 구성하려면:

  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을 다시 구성합니다.

오브젝트 스토리지 구성

GitLab은 다양한 유형의 데이터를 보관하기 위해 오브젝트 스토리지 서비스를 사용할 수 있습니다. 대규모 설정에서는 일반적으로 오브젝트 스토리지이 NFS에 비해 성능이 우수하고 신뢰성이 있으며 확장 가능하기 때문에 이를 권장합니다. 자세한 정보는 추천 클라우드 공급자 및 서비스를 참조하세요.

GitLab에서 오브젝트 스토리지 구성을 지정하는 두 가지 방법이 있습니다:

가능한 경우 통합된 형식이 사용됩니다.

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

각 데이터 유형에 대해 별도의 버킷을 사용하는 것이 GitLab에서 권장하는 접근 방식입니다. 이를 통해 GitLab이 저장하는 다양한 유형의 데이터 간에 충돌이 없도록 보장할 수 있습니다. 앞으로 단일 버킷의 사용을 허용할 계획이 있습니다.

점진적 로깅 활성화

GitLab Runner는 작업 로그를 청크 단위로 반환하며, 기본적으로 Linux 패키지는 이를 일시적으로 /var/opt/gitlab/gitlab-ci/builds에 캐시합니다. NFS를 사용하지 않더라도 작업 로그를 공유하기 위해 디렉터리를 NFS를 통해 공유하는 것이 지원됩니다. 그러나 NFS 사용을 피하기 위해 점진적 로깅을 활성화하는 것이 좋습니다(NFS 노드가 배포되지 않았을 때 필요). 점진적 로깅은 임시적인 작업 로그 캐싱을 위해 디스크 공간 대신 Redis를 사용합니다.

고급 검색 구성

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

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

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

GitLab Helm chart를 사용하여 Kubernetes에서 클라우드 네이티브 GitLab의 일부 컴포넌트를 실행합니다. 이 설정에서는 Webservice라는 Kubernetes 클러스터에서 GitLab Rails의 동등한 구성을 실행할 수 있습니다. 또한 Sidekiq 노드의 동등한 구성을 Sidekiq이라는 Kubernetes 클러스터에서 실행할 수 있습니다. 추가로 다음과 같은 여러 지원 서비스가 지원됩니다: NGINX, Toolbox, Migrations, Prometheus.

하이브리드 설치는 클라우드 네이티브 및 전통적인 컴퓨팅 배포의 이점을 모두 활용합니다. 이를 통해 상태를 유지하지 않는(stateless) 컴포넌트는 클라우드 네이티브 워크로드 관리 이점을 얻을 수 있지만, 상태를 유지하는(stateful) 컴포넌트는 Linux 패키지 설치를 통해 컴퓨팅 VM에 배포되어 증가된 영속성 이점을 얻을 수 있습니다.

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

caution
이것은 고급 설정입니다. Kubernetes에서 서비스를 실행하는 것은 복잡하다는 것이 잘 알려져 있습니다. 이 설정은 오직 Kubernetes에 대해 강력한 근로 지식과 경험이 있는 경우에만 권장됩니다. 이 섹션의 나머지 부분은 이를 전제로 합니다.
caution
Gitaly 클러스터를 Kubernetes에서 실행하는 것은 지원되지 않습니다. 자세한 내용은 epic 6127를 참조하세요.

클러스터 토폴로지

다음 таблиц과 다이어그램은 일반적인 환경과 동일한 형식을 사용하여 하이브리드 환경을 설명합니다.

먼저 Kubernetes에서 실행되는 컴포넌트입니다. 이러한 컴포넌트는 여러 노드 그룹에서 실행되지만, 전체 메이크업을 원하는 대로 변경할 수 있지만 최소 CPU 및 메모리 요구 사항을 준수해야 합니다.

서비스 노드 그룹 노드 구성 GCP AWS 할당 가능한 최소 CPU 및 메모리
Webservice 16 32 vCPU, 28.8 GB 메모리 n1-highcpu-32 c5.9xlarge 510 vCPU, 472 GB 메모리
Sidekiq 4 4 vCPU, 15 GB 메모리 n1-standard-4 m5.xlarge 15.5 vCPU, 50 GB 메모리
지원 서비스 2 4 vCPU, 15 GB 메모리 n1-standard-4 m5.xlarge 7.75 vCPU, 25 GB 메모리
  • 이 설정에서는 권장하며 정기적으로 테스트를 진행합니다. Google Kubernetes Engine (GKE) 및 Amazon Elastic Kubernetes Service (EKS)를 권장합니다. 다른 Kubernetes 서비스들도 작동할 수 있지만, 결과는 달라질 수 있습니다.
  • 노드 구성은 Pod vCPU/메모리 비율을 보장하고 성능 테스트 중에 스케일링을 피하기 위해 표시됩니다.
    • 프로덕션 배포에서는 특정 노드에 Pod를 할당할 필요가 없습니다. 각 노드 그룹당 세 개 이상의 노드를 서로 다른 가용 영역에 권장하여 오류 내성 클라우드 아키텍처 관행과 일치시키는 것이 강력히 권장됩니다.

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

서비스 노드 구성 GCP AWS
Consul1 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large
PostgreSQL1 3 32 vCPU, 120 GB 메모리 n1-standard-32 m5.8xlarge
PgBouncer1 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large
내부 로드 밸런서3 1 16 vCPU, 14.4 GB 메모리 n1-highcpu-16 c5.4xlarge
Redis/Sentinel - 캐시2 3 4 vCPU, 15 GB 메모리 n1-standard-4 m5.xlarge
Redis/Sentinel - 지속2 3 4 vCPU, 15 GB 메모리 n1-standard-4 m5.xlarge
Gitaly5 3 64 vCPU, 240 GB 메모리6 n1-standard-64 m5.16xlarge
Praefect5 3 4 vCPU, 3.6 GB 메모리 n1-highcpu-4 c5.xlarge
Praefect PostgreSQL1 1+ 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large
객체 리포지터리4 - - - -

각주:

  1. 신뢰할 수 있는 타사 외부 PaaS PostgreSQL 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 Provide your own PostgreSQL instance를 참조하세요.
  2. 신뢰할 수 있는 타사 외부 PaaS Redis 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 Provide your own Redis instances를 참조하세요.
    • Redis는 주로 단일 스레드이며 CPU 코어 증가로 인한 혜택이 크지 않습니다. 이러한 규모의 아키텍처에 대해 최적의 성능을 얻기 위해 별도의 Cache 및 Persistent 인스턴스를 구별하여 권장됩니다.
  3. 신뢰할 수 있는 타사 로드 밸런싱 서비스 (LB PaaS)에서 선택적으로 실행할 수 있습니다. 자세한 내용은 Recommended cloud providers and services를 참조하세요.
  4. 신뢰할 수 있는 클라우드 제공업체 또는 Self-managed 솔루션에서 실행해야 합니다. 자세한 내용은 Configure the object storage를 참조하세요.
  5. Gitaly 클러스터는 장애 허용성의 이점을 제공하지만 설정 및 관리에 추가 복잡성이 따릅니다. Gitaly 클러스터를 배포하기 전에 기존의 Gitaly Cluster를 배포하기 전에 기술적인 한계와 고려 사항을 검토하세요. Sharded Gitaly를 원한다면 Gitaly에 대한 동일한 사양을 사용하세요.
  6. Gitaly 사양은 건강한 상태 및 리포지터리 크기에서의 높은 백분위수를 기반으로 합니다. 그러나 큰 모노 리포지터리 (여러 기가바이트보다 큰)나 추가 작업 부하가 있다면 Git 및 Gitaly 성능에 상당한 영향을 미칠 수 있으며 추가 조정이 필요할 수 있습니다.
note
인스턴스 구성에 관련된 모든 PaaS 솔루션에 대해 오류 내성 클라우드 아키텍처 관행과 일치시키는 것이 강력히 권장됩니다.

자원 사용량 설정

다음 공식은 자원 제한 내에서 배포할 수 있는 파드 수를 계산하는 데 도움이 됩니다. 50k 참조 아키텍처 예제 값 파일은 계산된 구성을 Helm 차트에 적용하는 방법에 대해 설명합니다.

웹서비스

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

5만 명의 사용자를 대상으로 할 때, 약 320개의 총 Puma 작업자 수를 권장합니다. 제공된 권장 사항에 따라, 이를 통해 각각 4 개의 작업자가 있는 80개의 웹서비스 파드 및 노드당 5개의 파드를 배포할 수 있습니다. 추가 웹서비스 파드 당, 각각 1 CPU에 대한 1.25 GB의 메모리 비율을 사용하여 사용 가능한 자원을 확장할 수 있습니다.

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

Sidekiq

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

제공된 시작점에 따라, 최대 14개의 Sidekiq 파드를 배포할 수 있습니다. 추가 파드 당, 0.9 CPU에 대한 2 GB의 메모리 비율을 사용하여 사용 가능한 자원을 확장할 수 있습니다.

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

지원

지원 노드 풀은 Webservice 및 Sidekiq 풀에 있을 필요가 없는 모든 지원 배포를 수용하기 위해 설계되었습니다.

이에는 클라우드 제공 업체의 구현 및 지원 GitLab 배포와 관련된 다양한 배포물이 포함되며, NGINX나 GitLab Shell과 같은 것들이 포함됩니다.

모니터링과 같은 추가 배포를 하려면 가능한 경우 이 풀에 배포하는 것이 좋으며, 웹서비스나 Sidekiq 풀이 아닌 곳에 배포하는 것이 좋습니다. 지원 풀은 여러 추가 배포물을 수용할 수 있도록 특별히 설계되었습니다. 그러나 제공된 풀에 맞지 않는 경우에는 노드 풀을 해당 배포에 맞게 증가시킬 수 있습니다.