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

Tier: Premium, Ultimate Offering: Self-Managed

이 페이지는 실제 데이터를 기반으로 최대 초당 500개의 요청(500 RPS) 및 최대 25,000명의 사용자(수동 및 자동 모두)를 대상으로하는 GitLab 참조 아키텍처를 설명합니다.

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

참고: 이 아키텍처를 배포하기 전에 먼저 기본 문서를 읽는 것이 좋습니다. 특히 시작하기 전에 및 사용할 아키텍처 결정 섹션을 참조하십시오.

서비스 노드 수 구성 GCP AWS Azure
외부 로드 밸런서3 1 8 vCPU, 7.2 GB 메모리 n1-highcpu-8 c5n.2xlarge F8s v2
Consul1 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large F2s v2
PostgreSQL1 3 16 vCPU, 60 GB 메모리 n1-standard-16 m5.4xlarge D16s v3
PgBouncer1 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large F2s v2
내부 로드 밸런서3 1 8 vCPU, 7.2 GB 메모리 n1-highcpu-8 c5n.2xlarge F8s v2
Redis/Sentinel - 캐시2 3 4 vCPU, 15 GB 메모리 n1-standard-4 m5.xlarge D4s v3
Redis/Sentinel - 지속2 3 4 vCPU, 15 GB 메모리 n1-standard-4 m5.xlarge D4s v3
Gitaly5 3 32 vCPU, 120 GB 메모리6 n1-standard-32 m5.8xlarge D32s 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 5 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. 신뢰할 수 있는 타사 외부 PaaS PostgreSQL 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 자체 PostgreSQL 인스턴스 제공를 참조하십시오.
  2. 신뢰할 수 있는 타사 외부 PaaS Redis 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 자체 Redis 인스턴스 제공를 참조하십시오.
    • Redis는 주로 단일 스레드이며 CPU 코어 증가의 혜택을 크게 받지 않습니다. 이러한 규모의 아키텍처의 경우 최적의 성능을 위해 별도 캐시 및 지속 인스턴스가 필요합니다.
  3. HA 기능을 제공하는 신뢰할 수 있는 타사 로드 밸런서나 서비스 (LB PaaS)에서 실행하는 것이 좋습니다. 또한, 크기 조정은 선택한 로드 밸런서 및 네트워크 대역폭과 같은 추가 요인에 따라 다릅니다. 자세한 내용은 로드 밸런서를 참조하십시오.
  4. 신뢰할 수 있는 클라우드 제공자 또는 자체 관리 솔루션에서 실행하는 것이 좋습니다. 자세한 내용은 객체 저장소 구성를 참조하십시오.
  5. Gitaly 클러스터는 고장 허용의 이점을 제공하지만 추가 설정 및 관리 복잡성이 동반됩니다. Gitaly 클러스터 배포 전에 Gitaly 클러스터 배포 전에 기술적인 제한 사항과 고려 사항을 검토하십시오. 샤드된 Gitaly를 사용하려면 Gitaly에 대한 위에 나열된 사양과 동일한 사양을 사용하십시오.
  6. Gitaly의 사양은 건강한 상태에서의 사용 패턴 및 리포지토리 크기의 상위 백분위수에 기반합니다. 그러나 대형 모노 리포(여러 기가바이트보다 큰) 또는 추가 워크로드를 갖고 있는 경우 Git 및 Gitaly 성능에 상당한 영향을 줄 수 있으며 추가 조정이 필요합니다.
  7. 구성요소에 상태적 데이터를 저장하지 않기 때문에 자동 크기 조정 그룹(ASG)에 배치할 수 있습니다. 그러나 클라우드 네이티브 하이브리드 설정이 상황에 따라 더 선호됩니다. 특히 마이그레이션 및 Mailroom과 같은 일부 구성 요소는 하나의 노드에서만 실행할 수 있으며, 쿠버네티스에서 더 잘 처리됩니다.

참고: PaaS 솔루션을 구성하는 모든 경우 신뢰할 수 있는 타사에서 실제 구현을 위해 3개의 노드를 최소한 3개의 다른 가용 영역에 구현하는 것이 좋습니다.

요구 사항

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

테스트 방법론

25k 아키텍처는 대부분의 워크플로를 커버하도록 설계되었으며, 정기적으로 스모크 및 성능 테스트를 수행하며 테스트 플랫폼 팀에서 다음과 같은 엔드포인트 처리량 목표에 대해 테스트합니다.

  • API: 500 RPS
  • 웹: 50 RPS
  • Git (풀): 50 RPS
  • Git (푸시): 10 RPS

위의 목표는 사용자 수에 해당하는 총 환경 부하에 기초하여 선택되었으며, 이에는 CI 및 기타 워크로드가 포함됩니다.

위 엔드포인트 목표보다 규칙적으로 높은 처리량을 가지고 있다고 제안할 메트릭이 있는 경우, 대형 단일 저장소 또는 주목할만한 추가 워크로드의 영향을 고려하여 성능 환경에 미치는 영향이 상당할 수 있으며, 추가 조정이 필요할 수 있습니다. 이 경우 연결된 문서를 참조하고 고객 성공 관리자나 지원팀에게 지원을 요청하는 것이 강력히 권장됩니다.

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

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

구성 요소 설정

GitLab 및 해당 구성 요소를 설정하여 최대 500 RPS 또는 25,000 사용자를 수용하도록 설정하려면 다음을 수행하세요.

  1. 외부 로드 밸런서 구성
    • GitLab 응용 프로그램 서비스 노드의 부하 분산을 처리할 수 있도록 구성합니다.
  2. 내부 로드 밸런서 구성
    • GitLab 응용 프로그램 내부 연결의 부하 분산을 처리할 수 있도록 구성합니다.
  3. 서비스 검색 및 상태 확인을 위한 Consul 구성
  4. GitLab의 데이터베이스 인 PostgreSQL 구성
  5. 데이터베이스 연결 풀링 및 관리를 위한 PgBouncer 구성
  6. 세션 데이터, 임시 캐시 정보 및 백그라운드 작업 대기열을 저장하는 Redis 구성
  7. Git 저장소에 액세스를 제공하는 Gitaly Cluster 구성
  8. 백그라운드 작업 처리를 위한 Sidekiq 구성
  9. Puma, Workhorse, GitLab Shell을 실행하고 모든 프론트엔드 요청 (UI, API 및 Git over HTTP/SSH 포함)을 제공하기 위한 메인 GitLab Rails 애플리케이션 구성
  10. GitLab 환경을 모니터링하기 위한 Prometheus 구성
  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: Praefect 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.151: 프로메테우스

외부 로드 밸런서 구성

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

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

준비 상태 확인

외부 로드 밸런서가 모니터링 엔드포인트를 빌트인한 작동 서비스로만 라우팅되도록 확인하세요. 준비 상태 확인 항목은 이를 위해 노드에 대한 추가 구성을 필요로 합니다. 그렇지 않으면 외부 로드 밸런서가 연결할 수 없습니다.

포트

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

LB 포트 백엔드 포트 프로토콜
80 80 HTTP (1)
443 443 TCP 또는 HTTPS (1) (2)
22 22 TCP
  • (1): Web terminal 지원을 위해서는 로드 밸런서가 WebSocket 연결을 정확히 처리해야 합니다. HTTP 또는 HTTPS 프록시를 사용할 때, 로드 밸런서는 Connection 및 Upgrade hop-by-hop 헤더를 통과시키도록 구성되어야 합니다. 자세한 내용은 web terminal 통합 가이드를 참조하세요.
  • (2): 포트 443에 HTTPS 프로토콜을 사용하는 경우, 로드 밸런서에 SSL 인증서를 추가해야 합니다. SSL을 GitLab 애플리케이션 서버에서 종료시키려면 TCP 프로토콜을 사용하세요.

사용자 정의 도메인 지원이 있는 GitLab Pages를 사용 중이라면 추가 포트 구성이 필요합니다. GitLab Pages는 별도의 가상 IP 주소가 필요합니다. DNS를 구성하여 /etc/gitlab/gitlab.rb의 pages_external_url을 새 가상 IP 주소를 가리키도록 지정하세요. 자세한 내용은 GitLab Pages 문서를 참조하세요.

LB 포트 백엔드 포트 프로토콜
80 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 호스트 이름을 구성하는 것이 도움이 될 수 있습니다. 대체 SSH 호스트 이름은 다른 GitLab HTTP 구성과 달리 새 가상 IP 주소가 필요합니다.

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

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

SSL

다음 질문은 환경에서 SSL을 어떻게 처리할지입니다. 몇 가지 다른 옵션이 있습니다.

응용 프로그램 노드에서 SSL 종료

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

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

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

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

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

백엔드 SSL을 갖는 로드 밸런서에서 SSL 종료

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

이 시나리오에서 로드 밸런서와 NGINX 간의 통신은 안전합니다. 연결이 전체적으로 안전하기 때문에 프록시된 SSL을 추가 구성할 필요가 없습니다. 그러나 SSL 인증서를 구성하기 위해 GitLab에 구성을 추가해야 합니다. SSL 인증서 관리 및 NGINX 구성에 대한 자세한 내용은 HTTPS 문서를 참조하세요.

내부 로드 밸런서 구성

내부 로드 밸런서는 PgBouncer 및 Praefect (Gitaly Cluster)와 같이 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 서버를 설정합니다.

참고: 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 패키지를 다운로드하고 설치합니다. 페이지에서 installation steps 1 및 2 만 따르고, 현재 설치된 패키지와 동일한 버전 및 유형(Community 또는 Enterprise editions)의 올바른 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 서비스를 선택적으로 사용할 수 있습니다.

이를 위해 신뢰할 수 있는 제공자나 솔루션을 사용해야 합니다. 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. 그러나 추가적인 성능을 위해 Read Replicas를 통한 데이터베이스 로드 밸런싱이 원하는 경우 참조 아키텍처의 노드 수를 따르는 것이 권장됩니다.

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

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

  • 최소 세 개의 PostgreSQL 노드
  • 최소 세 개의 Consul 서버 노드
  • 주 데이터베이스 읽기 및 쓰기를 추적하고 처리하는 최소 세 개의 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, 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 사용자 구성
# 필수 정보 섹션에서 설명된대로 실제 값을 설정하세요
#
# PGBOUNCER_PASSWORD_HASH를 생성된 md5 값으로 바꿉니다.
   postgresql['pgbouncer_user_password'] = '<pgbouncer_password_hash>'
# POSTGRESQL_REPLICATION_PASSWORD_HASH를 생성된 md5 값으로 바꿉니다.
   postgresql['sql_replication_password'] = '<postgresql_replication_password_hash>'
# POSTGRESQL_PASSWORD_HASH를 생성된 md5 값으로 바꿉니다.
   postgresql['sql_user_password'] = '<postgresql_password_hash>'

# Patroni API를 위한 기본 인증 설정(모든 노드에서 동일한 사용자 이름/암호를 사용하세요).
patroni['username'] = '<patroni_api_username>'
patroni['password'] = '<patroni_api_password>'

# Network 주소로 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 사용자 구성

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 | 리더   | 실행 중 | 175 |           | *               |
| postgresql-ha | <PostgreSQL secondary 1 hostname> | 10.6.0.22 |        | 실행 중 | 175 | 0         | *               |
| postgresql-ha | <PostgreSQL secondary 2 hostname> | 10.6.0.23 |        | 실행 중 | 175 | 0         | *               |

‘상태’ 열의 어느 노드에 대한 상태가 “실행 중”이 아니면 계속하기 전에 PostgreSQL 복제 및 장애 조치 문제 해결 섹션을 확인하세요.

PgBouncer 구성

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

참고: 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 및 Consul 에이전트 이외의 모든 구성요소를 비활성화합니다
roles(['pgbouncer_role'])

# PgBouncer 구성
pgbouncer['admin_users'] = %w(pgbouncer gitlab-consul)
pgbouncer['users'] = {
   'gitlab-consul': {
      password: '<consul_password_hash>'
   },
   'pgbouncer': {
      password: '<pgbouncer_password_hash>'
   }
}

# Consul 에이전트 구성
consul['watchers'] = %w(postgresql)
consul['configuration'] = {
retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
}

# Prometheus의 서비스 검색을 활성화합니다
consul['monitoring_service_discovery'] = true

# 익스포터가 수신 대기할 네트워크 주소를 설정합니다
node_exporter['listen_address'] = '0.0.0.0:9100'

  2. 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 동일한 이름의 파일에 추가하거나 덮어쓰기합니다. 이것이 처음 구성하는 Linux 패키지 노드라면 이 단계를 건너뛸 수 있습니다.

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

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

  4. .pgpass 파일을 생성하여 Consul이 PgBouncer를 다시 로드할 수 있도록 합니다. 두 번 물어볼 때, PgBouncer 암호를 두 번 입력하십시오: 

    gitlab-ctl write-pgpass --host 127.0.0.1 --database pgbouncer --user pgbouncer --hostuser gitlab-consul
  5. 이전 단계의 잠재적인 오류를 해결하기 위해 GitLab을 다시 구성합니다.

  6. 각 노드가 현재 주 데이터베이스와 통신하는지 확인합니다: 

    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 서비스를 사용하여 장애 조치 프로시저를 자동으로 시작하는 것이 가능합니다.

참고: 각 Redis 클러스터는 홀수 개수인 3개 노드 이상으로 배포되어야 합니다. 이는 Redis Sentinel이 쿼러럼의 일부로 투표를 할 수 있도록 하기 위함입니다. 클라우드 제공자 서비스와 같이 외부에서 Redis를 구성할 때는 해당 사항이 적용되지 않습니다.

참고: Redis는 주로 단일 스레드이며 CPU 코어의 증가로 인한 혜택이 미미합니다. 이러한 크기의 아키텍처에서 최적의 성능을 얻기 위해 별도의 캐시 및 지속적인 인스턴스를 사용하는 것이 강력히 권장됩니다. 자세한 정보는 스케일링 설명서를 참조하십시오.

Redis는 Sentinel과 함께 사용될 경우 인증이 필요합니다. 더 많은 정보는 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 - 캐시 프라이머리
  • 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

자체 Redis 인스턴스 제공

다음 지침에 따라 서드 파티 외부 서비스로 Redis Cache 및 Persistence 인스턴스를 선택적으로 사용할 수 있습니다.

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

추가 정보는 권장되는 클라우드 제공업체 및 서비스를 참조하세요.

Redis Cache 클러스터 구성

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

기본 및 복제 Redis 노드는 모두 redis['password']로 정의된 동일한 암호가 필요합니다. 장애 조치(failover) 중에 Sentinels(Sentinel들)은 노드를 다시 구성하고 상태를 기본에서 복제(또는 그 반대로)로 변경할 수 있습니다.

기본 Redis Cache 노드 구성

  1. 기본 Redis 서버에 SSH로 연결합니다.
  2. 선택한 리눅스 패키지를 다운로드하고 설치하세요. 페이지의 설치 단계 1 및 2를 오직 따르고, 현재 설치와 동일한 버전 및 유형(커뮤니티 또는 엔터프라이즈 에디션)의 올바른 리눅스 패키지를 선택해야 합니다.

  3. /etc/gitlab/gitlab.rb를 편집하고 아래 내용을 추가하세요. 

    # 서버 역할을 'redis_sentinel_role' '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 주소
#모든 인터페이스에 대해 듣도록 bind 값을 '0.0.0.0'로 설정할 수도 있습니다.
#외부 접근 가능한 IP에 바인딩이 필요한 경우
#무단 액세스를 방지하기 위해 추가 방화벽 규칙을 추가하세요.
redis['bind'] = '10.6.0.51'

# TCP 요청에 대해 Redis가 듣도록 포트를 정의하여, 다른 기기들이 이에 연결할 수 있게 합니다.
redis['port'] = 6379

# Sentinel을 위한 기본 Redis 서버의 포트, 디폴트에서 비디폴트(non default)로 변경하려면 주석을 제거하세요.
# 디폴트로 `6379`로 설정됩니다.
# redis['master_port'] = 6379

# Redis 인증을 위해 암호를 설정하세요 (모든 노드에서 동일한 암호를 사용하세요).
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 Cache 인스턴스를 LRU로 설정합니다.
# 사용 가능한 RAM의 90%를 MB 단위로
redis['maxmemory'] = '13500mb'
redis['maxmemory_policy'] = "allkeys-lru"
redis['maxmemory_samples'] = 5

## 프로메테우스를 위한 서비스 디스커버리를 활성화
consul['monitoring_service_discovery'] =  true

## 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),
}

# Exporter가 청취할 네트워크 주소를 설정합니다
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. 처음 리눅스 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하고, 이 서버의 동일한 이름의 파일을 추가하거나 교체하세요. 이것이 구성하는 첫 번째 리눅스 패키지 노드이면 이 단계를 건너뛰십시오.

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

복제 Redis Cache 노드 구성

  1. 복제 Redis 서버에 SSH로 연결합니다.
  2. 선택한 리눅스 패키지를 다운로드하고 설치하세요. 페이지의 설치 단계 1 및 2를 오직 따르고, 현재 설치와 동일한 버전 및 유형(커뮤니티 또는 엔터프라이즈 에디션)의 올바른 리눅스 패키지를 선택해야 합니다.

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

    # 서버 역할을 'redis_replica_role'로 지정 및 Consul agent 활성화
roles ['redis_sentinel_role', 'redis_replica_role', 'consul_role']

# Redis Sentinel 서비스에 대한 IP 바인드 주소 및 Quorum 번호를 설정
sentinel['bind'] = `0.0.0.0`
sentinel['quorum'] = 2

# 다른 기기에서 접근할 수 있는 로컬 IP를 가리키는 IP 주소
# 모든 인터페이스에 대해 듣도록 bind 값을 '0.0.0.0'로 설정할 수도 있습니다.
# 외부 접근 가능한 IP에 바인딩이 필요한 경우
# 무단 액세스를 방지하기 위해 추가 방화벽 규칙을 추가하세요.
redis['bind'] = '10.6.0.52'

# TCP 요청에 대해 Redis가 듣도록 포트를 정의하여, 다른 기기들이 이에 연결할 수 있게 합니다.
redis['port'] = 6379

## Redis Sentinel을 위한 기본 Redis 서버의 포트, 디폴트에서 비디폴트(non default)로 변경하려면 주석을 제거하세요. 디폴트로
## `6379`로 설정됩니다.
#redis['master_port'] = 6379

# Redis 및 복제본을 위해 암호 인증을 설정하세요 (모든 노드에서 동일한 암호를 사용하세요).
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 Cache 인스턴스를 LRU로 설정합니다.
# 사용 가능한 RAM의 90%를 MB 단위로
redis['maxmemory'] = '13500mb'
redis['maxmemory_policy'] = "allkeys-lru"
redis['maxmemory_samples'] = 5

## 프로메테우스를 위한 서비스 디스커버리를 활성화
consul['monitoring_service_discovery'] =  true

## 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),
}

# Exporter가 청취할 네트워크 주소를 설정합니다
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

  4. 처음 리눅스 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하고, 이 서버의 동일한 이름의 파일을 추가하거나 교체하세요. 이것이 구성하는 첫 번째 리눅스 패키지 노드이면 이 단계를 건너뛰십시오.

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

  6. 다른 복제본 노드에 대해서도 위 단계를 모두 반복하고, IP를 올바르게 설정하는지 확인하세요.

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

Redis Persistent 클러스터 구성

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

주 및 복제 Redis 노드는 언제든지 장애 조치(failover) 중에 Sentinels가 노드를 재구성하고 상태를 주(primary)에서 복제(replica)로 변경(또는 그 반대)할 때와 동일한 비밀번호가 필요합니다.

주(primary) Redis Persistent 노드 구성

  1. Primary Redis 서버에 SSH로 로그인합니다.
  2. 원하는 리눅스 패키지를 다운로드하고 설치합니다. 페이지의 설치 단계 1과 2를 따로 따라하기와 현재 설치된 버전 및 유형(커뮤니티 또는 엔터프라이즈 에디션)과 동일한 리눅스 패키지를 선택하세요.

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

    # 서버 역할을 'redis_sentinel_role' 및 'redis_master_role'로 지정
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'

# TCP 요청 수신을 위해 Redis가 듣도록 포트 지정하여 다른 머신이 연결할 수 있도록 합니다.
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'

## 주(primary) Redis 노드의 IP
redis['master_ip'] = '10.6.0.61'

## Prometheus를 위한 서비스 검색 활성화
consul['monitoring_service_discovery'] =  true

## 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),
}

# 내보내기기가 듣도록 할 네트워크 주소 지정
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'

# 업그레이드 시 자동으로 데이터베이스 마이그레이션을 방지하기
gitlab_rails['auto_migrate'] = false

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

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

복제본 Redis Persistent 노드 구성

  1. 복제본 Redis Persistent 서버에 SSH로 로그인합니다.
  2. 원하는 리눅스 패키지를 다운로드하고 설치합니다. 페이지의 설치 단계 1과 2를 따로 따라하기와 현재 설치된 버전 및 유형(커뮤니티 또는 엔터프라이즈 에디션)과 동일한 리눅스 패키지를 선택하세요.

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

    # 서버 역할을 'redis_replica_role'로 지정하고 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'

# TCP 요청 수신을 위해 Redis가 듣도록 포트 지정하여 다른 머신이 연결할 수 있도록 합니다.
redis['port'] = 6379

## Sentinel용 주 Redis 서버의 포트, 비 기본 설정으로 변경하려면 주석 해제. 기본값은 `6379`입니다.
#redis['master_port'] = 6379

# 주 노드용으로 설정한 Redis 인증 비밀번호와 동일한 비밀번호를 사용하세요.
redis['master_password'] = 'REDIS_PRIMARY_PASSWORD_OF_SECOND_CLUSTER'

## 모든 Redis 노드에서 동일해야 함
redis['master_name'] = 'gitlab-redis-persistent'

# 주(primary) Redis 노드의 IP
redis['master_ip'] = '10.6.0.61'

## Prometheus를 위한 서비스 검색 활성화
consul['monitoring_service_discovery'] =  true

## 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),
}

# 내보내기기가 듣도록 할 네트워크 주소 지정
node_exporter['listen_address'] = '0.0.0.0:9100'
redis_exporter['listen_address'] = '0.0.0.0:9121'
redis_exporter['flags'] = {
     'redis.addr' => 'redis://10.6.0.62:6379',
     'redis.password' => 'redis-password-goes-here',
}

# 업그레이드 시 자동으로 데이터베이스 마이그레이션을 방지하기
gitlab_rails['auto_migrate'] = false

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

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

  6. 다른 복제본 노드에 대해 위의 단계를 모두 다시 진행하고 IP를 올바르게 설정했는지 확인하세요.

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

Gitaly 클러스터 구성

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

경고: 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과 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

# 사용자 구성 시작
# 필수 정보 섹션에 설명 된대로 실제 값으로 설정합니다
#
# 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),
}
#
# 사용자 구성 끝

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

  6. 변경 사항이 적용되도록 GitLab을 재구성하세요.

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

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

  9. 구성 변경 후 작업을 따르세요.

Praefect HA PostgreSQL 타사 솔루션

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

PostgreSQL HA를 위한 여러 타사 솔루션이 있습니다. 선택한 솔루션은 Praefect와 함께 작동하려면 다음이 있어야 합니다:

  • 장애 조치(failover) 시 변경되지 않는 모든 연결에 대한 정적 IP.
  • LISTEN SQL 기능을 지원해야 함.

참고: 타사 설정으로는 편리를 위해 Praefect의 데이터베이스를 기본 GitLab 데이터베이스와 동일한 서버에 둘 수 있지만, Geo를 사용하는 경우 별도의 데이터베이스 인스턴스가 필요합니다. 이 설정에서는 주 데이터베이스 설정이 변경될 필요가 없어야 하며 영향은 최소화되어야 합니다.

이를 위해 신뢰할 수 있는 공급업체나 솔루션을 사용해야 합니다. Google Cloud SQL 및 Amazon RDS는 작동하는 것으로 알려져 있습니다. 그러나 Amazon Aurora는 14.4.0부터 기본적으로 로드 밸런싱이 호환되지 않음을 주의해야 합니다. 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 Cluster의 라우터 및 트랜잭션 관리자이며 모든 Gitaly 연결은 이를 거칩니다. 이 섹션에서는 Praefect를 구성하는 방법에 대해 설명합니다.

참고: Praefect는 노드 당 홀수로 3개 이상 배포되어야 합니다. 이는 노드가 과반수를 차지할 수 있도록 하는 것입니다.

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

  • <praefect_external_token>: Gitaly 클러스터에 호스팅된 저장소에 사용되며 이 토큰을 지닌 Gitaly 클라이언트만 액세스할 수 있습니다.
  • <praefect_internal_token>: Gitaly 클러스터 내부의 복제 트래픽에 사용됩니다. 이는 praefect_external_token과 별도이며 Gitaly 클라이언트가 Praefect 클러스터의 내부 노드에 직접 액세스할 수 없어야 하기 때문입니다.
  • <praefect_postgresql_password>: 이전 섹션에서 정의한 Praefect PostgreSQL 비밀번호가 이 설정의 일부로 필요합니다.

Gitaly Cluster 노드는 각 가상 스토리지를 통해 Praefect에 구성됩니다. 각 스토리지에는 클러스터를 구성하는 각 Gitaly 노드의 세부 정보가 포함되어 있습니다. 각 스토리지에는 이름도 되며이 이름은 구성의 여러 영역에 사용됩니다. 이 가이드에서 저장소의 이름은 default로 설정됩니다. 또한, 이 가이드는 새 설치를 대상으로 하며 기존 환경을 Gitaly Cluster를 사용하도록 업그레이드하는 경우 다른 이름을 사용해야 할 수 있습니다. 자세한 내용은 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. 선택한 Linux 패키지를 다운로드하여 설치합니다. 페이지에서 단계 1 및 2의 설치 단계에만 따르도록 하세요.

  3. Praefect를 구성하려면 /etc/gitlab/gitlab.rb 파일을 편집하세요:

    참고: 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
## Prometheus를 위한 서비스 검색 활성화
consul['monitoring_service_discovery'] = true

# 사용자 구성 시작
# 필수 정보 섹션에서 설명한대로 실제 값을 설정하세요
#

praefect['configuration'] = {
   # ...
   listen_addr: '0.0.0.0:2305',
   auth: {
      # ...
      #
      # Praefect 외부 토큰
      # GitLab Shell과 같은 클러스터 외부의 클라이언트에서 Praefect 클러스터와 통신하는 데 사용됩니다
      token: '<praefect_external_token>',
   },
   # Praefect 데이터베이스 설정
   database: {
      # ...
      host: '10.6.0.141',
      port: 5432,
      dbname: 'praefect_production',
      user: 'praefect',
      password: '<praefect_postgresql_password>',
   },
   # Praefect 가상 스토리지 구성
   # 스토리지 이름과 저장소에서 사용하는 이름이 일치해야합니다
   # on GitLab server ('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. 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하여 이 서버의 동일한 이름 파일에 추가 또는 교체합니다. 이게 첫 번째 Linux 패키지 노드를 구성하는 경우에는 이 단계를 건너뛸 수 있습니다.

  5. Praefect는 주 데이터베이스 애플리케이션과 마찬가지로 데이터베이스 마이그레이션을 실행해야 합니다. 이를 위해 데이터베이스 마이그레이션을 실행할 Praefect 노드를 1대만 선택해야 합니다. 이 노드는 _배포 노드_라고도 합니다. 이 노드는 다른 노드보다 먼저 구성되어야 하며 다음과 같은 방법으로 설정해야 합니다:

    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 서버 노드는 데이터 및 부하에 따라 요구 사항이 달라집니다.

경고: 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. 선택한 리눅스 패키지를 다운로드하고 설치합니다. 페이지의 설치 단계 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-shell API 콜백 URL을 구성합니다. 이렇게 하지 않으면 `git push`가 실패합니다. 이것은 'front door' GitLab URL이거나 내부 로드 밸런서가 될 수 있습니다.
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'

# Gitaly
gitaly['enable'] = true

# Consul 에이전트 구성
consul['enable'] = true
## 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'

gitaly['configuration'] = {
   # Gitaly가 모든 네트워크 인터페이스에서 연결을 수락하도록합니다. 이 주소/포트로의 접속을 지원하려면 방화벽을 사용해야 합니다.
   # TLS 연결만 지원하고 싶으면 다음 줄을 주석 처리합니다
   listen_addr: '0.0.0.0:8075',
   # Gitaly가 모니터링을 위해 청취할 네트워크 주소를 설정합니다
   prometheus_listen_addr: '0.0.0.0:9236',
   auth: {
      # Gitaly Auth Token
      # praefect_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. 이미 구성한 첫 번째 리눅스 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 복사하고 이 서버의 같은 이름의 파일을 추가하거나 교체합니다. 이것이 구성하려는 첫 번째 리눅스 패키지 노드라면, 이 단계는 건너 뛰어도 됩니다.

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

Gitaly 클러스터 TLS 지원

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

  • GitLab 구성 파일의 해당 저장소 항목의 gitaly_address에서 tls:// URL 스키마를 사용해야 합니다.
  • 자체 인증서를 가져와야 합니다. 이는 자동으로 제공되지 않습니다. 각 Praefect 서버에 해당하는 인증서를 설치해야 합니다.

또한 인증서 또는 해당 인증 기관은 모든 Gitaly 서버와 Praefect 클라이언트에 설치되어야 하며 다음에서 설명된 절차에 따라 통신해야 합니다.   GitLab 사용자 정의 인증서 구성에서 설명된 절차에 따라 진행해야 합니다.

다음 사항을 참고하세요:

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

Praefect를 TLS로 구성하려면 다음을 수행하세요:

  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://로드_밸런서_서버_주소:3305',
    "gitaly_token" => 'PRAEFECT_EXTERNAL_TOKEN'
  }
})

  7. 파일을 저장하고 GitLab을 다시 구성하세요.

Sidekiq 구성

Sidekiq는 Redis, PostgreSQL 및 Gitaly 인스턴스에 연결해야 합니다. 또한 권장 사항에 따라 Object Storage에 연결해야 합니다.

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

주의: 환경의 Sidekiq 작업 처리가 대기열이 길어 처리가 느리다고 판단되면 해당 Sidekiq를 확장할 수 있습니다. 자세한 내용은 확장 설명서를 참조하세요.

주의: Container Registry, SAML 또는 LDAP와 같은 추가 GitLab 기능을 구성하는 경우 Sidekiq 구성 뿐만 아니라 Rails 구성도 업데이트해야 합니다. 자세한 내용은 외부 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. PostgreSQL, Gitaly 및 Redis 포트에 액세스할 수 있는지 확인하세요: 

    telnet <GitLab 호스트> 5432 # PostgreSQL
telnet <GitLab 호스트> 8075 # Gitaly
telnet <GitLab 호스트> 6379 # Redis
  3. 설치 및 설치 페인지를 사용하여 Linux 패키지를 다운로드하고 설치하세요. 페이지의 설치 단계 1과 2만 따르도록 주의하세요.

  4. /etc/gitlab/gitlab.rb을 만들거나 편집하고 다음 구성을 사용하세요: 

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

# External URL
## 외부 로드 밸런서 URL과 일치해야 합니다
external_url 'https://gitlab.example.com'

# Redis
## Redis 연결 세부 정보
## 캐시 데이터를 보관할 첫 번째 클러스터
gitlab_rails['redis_cache_instance'] = 'redis://:<첫_클러스터_REDIS_주_비밀번호>@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_주_비밀번호>'

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 IPs

## 업그레이드 시 자동으로 데이터베이스 마이그레이션을 방지합니다
gitlab_rails['auto_migrate'] = false

# Sidekiq
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']

# 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>'
}

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

  6. 업데이트에 자동으로 실행되지 않고 다시 구성 중에만 데이터베이스 마이그레이션을 실행하지 않도록 하려면 다음을 실행하세요: 

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

    지정된 하나의 노드만 GitLab Rails 후구성 섹션에서 자세히 설명된 바와 같이 마이그레이션을 처리해야 합니다.

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

GitLab Rails 구성

이 섹션에서는 GitLab 애플리케이션 (Rails) 구성 요소의 구성 방법을 설명합니다.

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

참고: 데이터 객체에 대해 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

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

  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
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

# upgrade 시 자동으로 실행되는 데이터베이스 마이그레이션을 방지합니다
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},
]

# 모니터링에 사용되는 내부 API는 어느 주소에서 수신할지 설정합니다
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']

#############################
###     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>'
}

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

    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. 노드가 Gitaly에 연결할 수 있는지 확인하세요: 

    sudo gitlab-rake gitlab:gitaly:check

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

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

앞의 예와 같이 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에서 객체 저장소 구성을 지정하는 두 가지 방법이 있습니다:

통합된 형식은 다음 예시에 사용됩니다.

GitLab에서 각 데이터 유형에 대해 별도 버킷을 사용하는 것이 권장됩니다. 이렇게 하면 GitLab이 저장하는 다양한 유형의 데이터 사이에 충돌이 없음이 보장됩니다. 미래에 단일 버킷 사용을 가능하게 하는 계획이 있습니다.

증분 로깅 활성화

기본 구성에서 GitLab Runner는 일시적으로 /var/opt/gitlab/gitlab-ci/builds 디렉터리에 작업 로그를 청크 단위로 반환합니다. 기본값으로, 이 디렉터리는 NFS를 통해 GitLab Rails 및 Sidekiq 노드에서 공유되어야 합니다. NFS를 통해 작업 로그를 공유하는 것은 지원되지만, NFS 노드를 배포하지 않더라도 증분 로깅을 가능하도록 하는 것이 좋습니다. 증분 로깅은 임시적으로 작업 로그를 캐시하는 데 디스크 공간 대신 Redis를 사용합니다.

고급 검색 구성

Elasticsearch를 활용하고 전체 GitLab 인스턴스에 걸쳐 더 빠르고 더 고급 코드 검색을 활성화할 수 있습니다. 자세한 내용은 고급 검색 실행을 참조하세요.

Elasticsearch 클러스터 디자인 및 요구 사항은 특정 데이터에 따라 다릅니다. Elasticsearch 클러스터 구성에 대한 권장 사항은 최적의 클러스터 구성 선택 방법을 읽어보세요.

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

Kubernetes에서 GitLab Helm 차트를 사용하여 클라우드 네이티브 GitLab의 일부 구성 요소를 실행할 수 있습니다. 이러한 설정에서는 Kubernetes 클러스터 내에서 GitLab Rails에 해당하는 Webservice와 Sidekiq 노드에 해당하는 일부 구성 요소를 실행할 수 있습니다. 또한 다음과 같은 기타 지원 서비스가 지원됩니다: NGINX, Toolbox, 마이그레이션, 프로메테우스 및 Grafana.

혼합 설치는 클라우드 네이티브 및 전통적인 컴퓨팅 배포의 이점을 모두 활용합니다. 이를 통해 무상태 구성 요소는 클라우드 네이티브 워크로드 관리 장점을 활용하고 비무상태 구성 요소는 Linux 패키지 설치를 통해 증가된 영속성 장점을 활용합니다.

Kubernetes 및 백엔드 구성 요소 간의 GitLab 시크릿을 동기화하는 데 관한 지침을 포함하여 고급 구성 문서의 Helm 차트를 참조하세요.

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

경고: Gitaly 클러스터를 Kubernetes에서 실행하는 것은 지원되지 않습니다. 자세한 내용은 epic 6127 항목을 참조하세요.

클러스터 토폴로지

아래 표와 다이어그램은 전형적인 환경과 동일한 형식을 사용하여 하이브리드 환경을 자세히 설명합니다.

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

구성 요소 노드 그룹 대상 노드 풀 총계 GCP 예시 AWS 예시
웹 서비스 140 vCPU
175 GB 메모리 (요청)
245 GB 메모리 (제한) 		5 x n1-standard-32 5 x c5.9xlarge
Sidekiq 12.6 vCPU
28 GB 메모리 (요청)
56 GB 메모리 (제한) 		4 x n1-standard-4 4 x m5.xlarge
지원 서비스 8 vCPU
30 GB 메모리 		2 x n1-standard-4 2 x m5.xlarge
  • 이 설정에서는 우리는 권장되며 정기적으로 테스트를 권장합니다. Google Kubernetes Engine (GKE) 및 Amazon Elastic Kubernetes Service (EKS)를 권장합니다. 다른 Kubernetes 서비스도 작동할 수 있지만 실제 결과는 상이할 수 있습니다.
  • 대상 노드 풀 총계에 도달하는 GCP 및 AWS 예시는 편리함을 위해 제공됩니다. 이러한 크기는 성능 테스트에 사용되지만 예시를 따를 필요는 없습니다. 다른 노드 풀 설계는 대상을 충족하고 모든 파드를 배포할 수 있는 경우 원하는 대로 사용할 수 있습니다.
  • 웹 서비스 및 Sidekiq 대상 노드 풀 총계는 GitLab 구성 요소에만 적용됩니다. 추가 리소스는 선택한 Kubernetes 제공 업체의 시스템 프로세스에 필요합니다. 제공된 예시는 이를 고려합니다.
  • 지원 대상 노드 풀 총계는 GitLab 배포를 지원하는 여러 리소스를 수용하기 위해 일반적으로 제공되며 귀하의 요구에 따라 추가 배포가 필요할 수 있습니다. 다른 노드 풀과 마찬가지로 선택한 Kubernetes 제공 업체의 시스템 프로세스도 리소스가 필요합니다. 제공된 예시는 이를 고려합니다.
  • 프로덕션 배포에서는 파드를 특정 노드에 할당할 필요가 없습니다. 그러나 강한 클라우드 아키텍처 관행에 따라 각 풀에 여러 노드가 여러 가용 영역에 걸쳐 분산되는 것이 권장됩니다.
  • Cluster Autoscaler와 같은 오토 스케일링을 활성화하는 것은 효율성을 위해 권장되지만, 지속적인 성능을 보장하기 위해 웹 서비스 및 Sidekiq 파드의 최소값을 대상으로 하는 것이 일반적으로 권장됩니다.

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

서비스 노드 구성 GCP AWS
Consul1 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large
PostgreSQL1 3 16 vCPU, 60 GB 메모리 n1-standard-16 m5.4xlarge
PgBouncer1 3 2 vCPU, 1.8 GB 메모리 n1-highcpu-2 c5.large
내부 로드 밸런서3 1 8 vCPU, 7.2 GB 메모리 n1-highcpu-8 c5.2xlarge
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 32 vCPU, 120 GB 메모리6 n1-standard-32 m5.8xlarge
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 코어 증가로 인한 혜택이 크지 않습니다. 이러한 구성의 경우 최적의 성능을 위해 별도의 캐시 및 지속적 인스턴스를 구분하는 것이 강력히 권장됩니다.
  3. 추천되는 클라우드 제공 업체 및 서비스에 대한 자세한 내용은 Recommended cloud providers and services를 참조하세요.
  4. 신뢰할 수 있는 클라우드 제공 업체 또는 자체 관리 솔루션에서 실행할 수 있습니다. 자세한 내용은 Configure the object storage를 참조하세요.
  5. Gitaly 클러스터는 결함 허용의 혜택을 제공하지만 추가적인 설정 및 관리 복잡성을 동반합니다. Gitaly Cluster를 배포하기 전에 기존 기술적 한계 및 고려 사항을 검토하세요. 샤드된 Gitaly를 사용하려면 위에서 나열한 사양을 사용하세요.
  6. Gitaly 사양은 좋은 상태의 높은 백분위 사용 패턴 및 저장소 크기에 기초합니다. 그러나 대형 단일 저장소 (수 기가바이트보다 큰)나 추가 작업 부하가 있는 경우 이러한 요소는 Git 및 Gitaly 성능에 중대하게 영향을 미칠 수 있으며 추가적인 조정이 필요할 수 있습니다.

참고: PaaS 솔루션의 모든 구성에는 각각의 인스턴스를 구성하는 것이 권장되며, 이를 위해 각각 다른 가용 영역에 있는 최소 3개의 노드를 구현하는 것이 권장됩니다.

Kubernetes 구성 요소 대상

다음 섹션에서는 Kubernetes에 배포된 GitLab 구성 요소에 사용되는 대상을 상세히 설명합니다.

Webservice

각 Webservice pod(Puma 및 Workhorse)은 다음 구성으로 실행하는 것이 추천됩니다:

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

500 RPS 또는 25,000 사용자를 위해 총 Puma worker 개수를 약 140 정도로 권장합니다. 여기에서는 최소 35개의 Webservice pod를 실행하는 것이 권장됩니다.

Webservice 리소스 사용에 대한 자세한 정보는 Webservice 리소스를 참조하세요.

NGINX

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

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

Sidekiq

각 Sidekiq pod는 다음 구성으로 실행하는 것이 추천됩니다:

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

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

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

지원

지원 노드 풀은 Webservice 및 Sidekiq 풀에 있을 필요가 없는 모든 지원 배포를 보관하는 데 사용됩니다.

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

컨테이너 레지스트리, 페이지 또는 모니터링과 같은 추가 배포를 원하는 경우 가능한 경우 이러한 배포를 이 풀에 배포하는 것이 좋으며, 배포를 Webservice 또는 Sidekiq 풀이 아닌 경우 지원 풀이 여러 추가적인 배포를 수용하도록 특별히 설계되었기 때문입니다. 그러나 사용 사례에 풀이 맞지 않으면 노드 풀을 적절히 늘릴 수 있습니다. 반대로, 사용 사례에 따라 과다 설정된 경우 노드 풀을 줄일 수 있습니다.

예시 구성 파일

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

다음 단계

본 안내를 따라 진행한 후에는 핵심 기능이 구성된 새로운 GitLab 환경을 갖게 될 것입니다.

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

참고: 환경 및 요구 사항에 따라 추가 하드웨어 요구 사항 또는 원하는 대로 추가 기능을 구성하려면 추가로 실시해야 할 조정이 필요할 수 있습니다. 자세한 정보는 개별 페이지를 참조하세요.