이 페이지는 초당 60 요청(RPS)의 피크 부하를 목표로 설계된 GitLab 레퍼런스 아키텍처를 설명합니다. 이는 실제 데이터를 기반으로 수동 및 자동화된 최대 3,000명 사용자의 일반적인 피크 부하입니다.

이 아키텍처는 HA가 내장된 가장 작은 아키텍처입니다. HA가 필요하지만 사용자 수나 총 부하가 더 낮은 경우 더 낮은 사용자 수를 위한 지원 수정 사항 섹션에서 HA를 유지하면서 이 아키텍처의 크기를 줄이는 방법을 자세히 설명합니다.

전체 레퍼런스 아키텍처 목록은 사용 가능한 레퍼런스 아키텍처를 참조하세요.

• 목표 부하: API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS
• 고가용성: 예, 다만 Praefect는 서드파티 PostgreSQL 솔루션이 필요합니다
• 클라우드 네이티브 하이브리드 대안: 예
• 어떤 레퍼런스 아키텍처를 사용할지 모르시나요? 자세한 정보는 이 가이드를 참조하세요.

각주:

1. 머신 유형 예시는 설명 목적으로 제공됩니다. 이러한 유형은 검증 및 테스트에 사용되지만 규범적 기본값으로 의도된 것은 아닙니다. 나열된 요구 사항을 충족하는 다른 머신 유형으로 전환하는 것이 지원되며, 가능한 경우 ARM 변형도 포함됩니다. 자세한 정보는 지원되는 머신 유형을 참조하세요.
2. 선택적으로 신뢰할 수 있는 서드파티 외부 PaaS PostgreSQL 솔루션에서 실행할 수 있습니다. 자세한 정보는 자체 PostgreSQL 인스턴스 제공을 참조하세요.
3. 선택적으로 신뢰할 수 있는 서드파티 외부 PaaS Redis 솔루션에서 실행할 수 있습니다. 자세한 정보는 자체 Redis 인스턴스 제공을 참조하세요.
4. HA 기능을 제공할 수 있는 신뢰할 수 있는 서드파티 로드 밸런서 또는 서비스(LB PaaS)와 함께 실행하는 것이 권장됩니다. 크기 조정은 선택한 로드 밸런서 및 네트워크 대역폭과 같은 추가 요소에 따라 달라집니다. 자세한 정보는 로드 밸런서를 참조하세요.
5. 신뢰할 수 있는 클라우드 제공업체 또는 자체 관리 솔루션에서 실행해야 합니다. 자세한 정보는 오브젝트 스토리지 구성을 참조하세요.
6. Gitaly Cluster(Praefect)는 내결함성의 이점을 제공하지만, 설정 및 관리에 추가적인 복잡성이 수반됩니다. Gitaly Cluster(Praefect) 배포 전 기존 기술적 제한 사항 및 고려 사항을 검토하세요. 샤딩된 Gitaly를 원하는 경우 이전 표에서 Gitaly에 대해 나열된 것과 동일한 사양을 사용하세요.
7. Gitaly 사양은 정상 상태에서의 사용 패턴과 저장소 크기의 높은 백분위수를 기반으로 합니다. 그러나 대규모 모노레포(수 기가바이트 이상) 또는 추가 워크로드가 있는 경우 Git 및 Gitaly 성능에 상당한 영향을 미칠 수 있으며 추가 조정이 필요할 수 있습니다.
8. 컴포넌트가 상태 유지 데이터를 저장하지 않으므로 Auto Scaling Groups(ASG)에 배치할 수 있습니다. 그러나 클라우드 네이티브 하이브리드 설정이 일반적으로 선호됩니다. 마이그레이션 및 Mailroom과 같은 특정 컴포넌트는 하나의 노드에서만 실행할 수 있으며, 이는 Kubernetes에서 더 잘 처리됩니다.

@startuml 3k
skinparam linetype ortho
card "External Load Balancer" as elb #6a9be7
card "Internal Load Balancer" as ilb #9370DB
together {
collections "GitLab Rails x3" as gitlab #32CD32
collections "Sidekiq x2" as sidekiq #ff8dd1
}
together {
card "Prometheus" as monitor #7FFFD4
collections "Consul x3" as consul #e76a9b
}
card "Gitaly Cluster" as gitaly_cluster {
collections "Praefect x3" as praefect #FF8C00
collections "Gitaly x3" as gitaly #FF8C00
card "Praefect PostgreSQL*\n//Non fault-tolerant//" as praefect_postgres #FF8C00
praefect -[#FF8C00]-> gitaly
praefect -[#FF8C00]> praefect_postgres
}
card "Database" as database {
collections "PGBouncer x3" as pgbouncer #4EA7FF
card "PostgreSQL //Primary//" as postgres_primary #4EA7FF
collections "PostgreSQL //Secondary// x2" as postgres_secondary #4EA7FF
pgbouncer -[#4EA7FF]-> postgres_primary
postgres_primary .[#4EA7FF]> postgres_secondary
}
card "Redis" as redis {
collections "Redis x3" as redis_nodes #FF6347
}
cloud "Object Storage" as object_storage #white
elb -[#6a9be7]-> gitlab
elb -[#6a9be7,norank]--> monitor
gitlab -[#32CD32,norank]--> ilb
gitlab -[#32CD32]r-> object_storage
gitlab -[#32CD32]----> redis
gitlab .[#32CD32]----> database
gitlab -[hidden]-> monitor
gitlab -[hidden]-> consul
sidekiq -[#ff8dd1,norank]--> ilb
sidekiq -[#ff8dd1]r-> object_storage
sidekiq -[#ff8dd1]----> redis
sidekiq .[#ff8dd1]----> database
sidekiq -[hidden]-> monitor
sidekiq -[hidden]-> consul
ilb -[#9370DB]--> gitaly_cluster
ilb -[#9370DB]--> database
ilb -[hidden]--> redis
ilb -[hidden]u-> consul
ilb -[hidden]u-> monitor
consul .[#e76a9b]u-> gitlab
consul .[#e76a9b]u-> sidekiq
consul .[#e76a9b]r-> monitor
consul .[#e76a9b]-> database
consul .[#e76a9b]-> gitaly_cluster
consul .[#e76a9b,norank]--> redis
monitor .[#7FFFD4]u-> gitlab
monitor .[#7FFFD4]u-> sidekiq
monitor .[#7FFFD4]> consul
monitor .[#7FFFD4]-> database
monitor .[#7FFFD4]-> gitaly_cluster
monitor .[#7FFFD4,norank]--> redis
monitor .[#7FFFD4]> ilb
monitor .[#7FFFD4,norank]u--> elb
@enduml

요구 사항#

진행하기 전에 레퍼런스 아키텍처의 요구 사항을 검토하세요.

테스트 방법론#

60 RPS / 3k 사용자 레퍼런스 아키텍처는 가장 일반적인 워크플로를 수용하도록 설계되었습니다. GitLab은 다음 엔드포인트 처리량 목표에 대해 정기적으로 스모크 및 성능 테스트를 수행합니다:

이러한 목표는 CI 파이프라인 및 기타 워크로드를 포함하여 지정된 사용자 수에 대한 총 환경 부하를 반영하는 실제 고객 데이터를 기반으로 합니다. 이는 일반적인 워크로드 구성을 나타냅니다. 비정형 워크로드 패턴에 대한 지침은 RPS 구성 이해를 참조하세요.

테스트 방법론에 대한 자세한 정보는 검증 및 테스트 결과 섹션을 참조하세요.

성능 고려 사항#

환경에 다음이 있는 경우 추가 조정이 필요할 수 있습니다:

• 나열된 목표보다 지속적으로 높은 처리량
• 대규모 모노레포
• 상당한 추가 워크로드

이러한 경우 자세한 정보는 환경 스케일링을 참조하세요. 이러한 고려 사항이 적용될 수 있다고 생각되면 필요에 따라 추가 지침을 위해 문의하세요.

로드 밸런서 구성#

테스트 환경에서는 다음을 사용합니다:

• Linux 패키지 환경용 HAProxy
• 클라우드 네이티브 하이브리드용 Gateway API 또는 Ingress 구현이 포함된 클라우드 제공업체 동등 제품

컴포넌트 설정#

GitLab 및 해당 컴포넌트를 최대 60 RPS 또는 3,000명 사용자를 수용하도록 설정하려면:

1. 외부 로드 밸런서 구성을 통해 GitLab 애플리케이션 서비스 노드의 로드 밸런싱을 처리합니다.
2. 내부 로드 밸런서 구성을 통해 GitLab 애플리케이션 내부 연결의 로드 밸런싱을 처리합니다.
3. Consul 구성으로 서비스 디스커버리 및 상태 확인을 수행합니다.
4. PostgreSQL 구성으로 GitLab의 데이터베이스를 설정합니다.
5. PgBouncer 구성으로 데이터베이스 연결 풀링 및 관리를 설정합니다.
6. Redis 구성으로 세션 데이터, 임시 캐시 정보 및 백그라운드 작업 큐를 저장합니다.
7. Gitaly Cluster(Praefect) 구성으로 Git 저장소에 대한 액세스를 제공합니다.
8. Sidekiq 구성으로 백그라운드 작업 처리를 설정합니다.
9. 메인 GitLab Rails 애플리케이션 구성으로 Puma, Workhorse, GitLab Shell을 실행하고 모든 프론트엔드 요청(UI, API, Git over HTTP/SSH 포함)을 처리합니다.
10. Prometheus 구성으로 GitLab 환경을 모니터링합니다.
11. 오브젝트 스토리지 구성으로 공유 데이터 오브젝트에 사용됩니다.
12. 고급 검색 구성(선택 사항)으로 전체 GitLab 인스턴스에서 더 빠르고 고급 코드 검색을 수행합니다.

서버는 동일한 10.6.0.0/24 프라이빗 네트워크 범위에서 시작하며, 이 주소에서 서로 자유롭게 연결할 수 있습니다.

다음 목록은 각 서버의 설명과 할당된 IP를 포함합니다:

• 10.6.0.10: 외부 로드 밸런서
• 10.6.0.11: Consul/Sentinel 1
• 10.6.0.12: Consul/Sentinel 2
• 10.6.0.13: Consul/Sentinel 3
• 10.6.0.21: PostgreSQL 프라이머리
• 10.6.0.22: PostgreSQL 세컨더리 1
• 10.6.0.23: PostgreSQL 세컨더리 2
• 10.6.0.31: PgBouncer 1
• 10.6.0.32: PgBouncer 2
• 10.6.0.33: PgBouncer 3
• 10.6.0.20: 내부 로드 밸런서
• 10.6.0.61: Redis 프라이머리
• 10.6.0.62: Redis 레플리카 1
• 10.6.0.63: Redis 레플리카 2
• 10.6.0.51: Gitaly 1
• 10.6.0.52: Gitaly 2
• 10.6.0.93: Gitaly 3
• 10.6.0.131: Praefect 1
• 10.6.0.132: Praefect 2
• 10.6.0.133: Praefect 3
• 10.6.0.141: Praefect PostgreSQL 1 (비 HA)
• 10.6.0.71: Sidekiq 1
• 10.6.0.72: Sidekiq 2
• 10.6.0.41: GitLab 애플리케이션 1
• 10.6.0.42: GitLab 애플리케이션 2
• 10.6.0.43: GitLab 애플리케이션 3
• 10.6.0.81: Prometheus

외부 로드 밸런서 구성#

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

어떤 로드 밸런서를 사용할지 또는 정확한 구성은 GitLab 문서의 범위를 벗어나지만, 일반적인 요구 사항에 대한 자세한 정보는 로드 밸런서를 참조하세요. 이 섹션에서는 선택한 로드 밸런서에 대해 구성할 내용의 세부 사항에 초점을 맞춥니다.

준비 상태 확인#

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

포트#

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

• (1): 웹 터미널 지원을 위해서는 로드 밸런서가 WebSocket 연결을 올바르게 처리할 수 있어야 합니다. HTTP 또는 HTTPS 프록시를 사용할 때 로드 밸런서가 Connection 및 Upgrade 홉 바이 홉 헤더를 통과하도록 구성해야 합니다. 자세한 내용은 웹 터미널 통합 가이드를 참조하세요.
• (2): 포트 443에 HTTPS 프로토콜을 사용할 때는 로드 밸런서에 SSL 인증서를 추가해야 합니다. GitLab 애플리케이션 서버에서 SSL을 종료하려면 TCP 프로토콜을 사용하세요.

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

• (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를 구성합니다.

SSL#

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

• 애플리케이션 노드에서 SSL 종료.
• 백엔드 SSL 없이 로드 밸런서에서 SSL 종료
  • 로드 밸런서와 애플리케이션 노드 간 통신이 안전하지 않습니다.
• 백엔드 SSL이 있는 로드 밸런서에서 SSL 종료
  • 로드 밸런서와 애플리케이션 노드 간 통신이 안전합니다.

애플리케이션 노드에서 SSL 종료#

로드 밸런서가 포트 443에서의 연결을 HTTP(S) 프로토콜이 아닌 TCP로 전달하도록 구성합니다. 이렇게 하면 연결이 애플리케이션 노드의 NGINX 서비스로 그대로 전달됩니다. NGINX가 SSL 인증서를 가지고 포트 443에서 수신 대기합니다.

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

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

로드 밸런서가 TCP가 아닌 HTTP(S) 프로토콜을 사용하도록 구성합니다. 그러면 로드 밸런서가 SSL 인증서 관리 및 SSL 종료를 담당합니다.

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

백엔드 SSL이 있는 로드 밸런서에서 SSL 종료#

로드 밸런서가 'TCP'가 아닌 'HTTP(S)' 프로토콜을 사용하도록 구성합니다. 로드 밸런서가 최종 사용자가 보는 SSL 인증서를 관리합니다.

이 시나리오에서는 로드 밸런서와 NGINX 간의 트래픽도 안전합니다. 연결이 끝까지 안전하므로 프록시 SSL에 대한 구성을 추가할 필요가 없습니다. 그러나 SSL 인증서를 구성하기 위해 GitLab에 구성을 추가해야 합니다. SSL 인증서 관리 및 NGINX 구성에 대한 자세한 내용은 HTTPS 문서를 참조하세요.

내부 로드 밸런서 구성#

멀티 노드 GitLab 구성에서는 PgBouncer 및 Gitaly Cluster(Praefect)와 같은 선택된 내부 컴포넌트에 대한 트래픽을 라우팅하기 위해 내부 로드 밸런서가 필요합니다.

어떤 로드 밸런서를 사용할지 또는 정확한 구성은 GitLab 문서의 범위를 벗어나지만, 일반적인 요구 사항에 대한 자세한 정보는 로드 밸런서를 참조하세요. 이 섹션에서는 선택한 로드 밸런서에 대해 구성할 내용의 세부 사항에 초점을 맞춥니다.

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

• 10.6.0.40: 내부 로드 밸런서

다음은 HAProxy로 수행하는 방법입니다:

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

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

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

    default_backend pgbouncer

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

    default_backend praefect

backend pgbouncer
    mode tcp
    option tcp-check

    server pgbouncer1 10.6.0.31:6432 check
    server pgbouncer2 10.6.0.32:6432 check
    server pgbouncer3 10.6.0.33:6432 check

backend praefect
    mode tcp
    option tcp-check
    option srvtcpka

    server praefect1 10.6.0.131:2305 check
    server praefect2 10.6.0.132:2305 check
    server praefect3 10.6.0.133:2305 check

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

Consul 구성#

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

다음 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 패키지를 다운로드하고 설치합니다. GitLab 패키지 저장소만 추가하고 선택한 운영 체제에 맞는 GitLab을 설치하세요. 현재 설치와 동일한 버전 및 유형(Community 또는 Enterprise 에디션)을 선택하세요.

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

   roles(['consul_role'])
   
   ## Enable service discovery for Prometheus
   consul['monitoring_service_discovery'] =  true
   
   ## The IPs of the Consul server nodes
   ## You can also use FQDNs and intermix them with IPs
   consul['configuration'] = {
      server: true,
      retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
   }
   
   # Set the network addresses that the exporters will listen on
   node_exporter['listen_address'] = '0.0.0.0:9100'
   
   # Prevent database migrations from running on upgrade automatically
   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 인스턴스 제공#

Linux 패키지에 번들된 PostgreSQL, PgBouncer 및 Consul 서비스 디스커버리 컴포넌트 대신 서드파티 외부 PostgreSQL 서비스를 사용할 수 있습니다.

지원되는 PostgreSQL 버전을 실행하는 신뢰할 수 있는 제공업체를 사용하세요. 다음 서비스가 잘 작동하는 것으로 알려져 있습니다:

• Google Cloud SQL.
• Amazon RDS.

고가용성 및 데이터베이스 로드 밸런싱에 대한 지침을 포함한 자세한 정보는 다음을 참조하세요:

• 인프라 및 서비스.
• 데이터베이스 서비스 모범 사례.

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

1. 데이터베이스 요구 사항 문서에 따라 PostgreSQL을 설정합니다.
2. 필요한 사용자 및 데이터베이스를 구성합니다.
3. GitLab Rails 구성에 따라 적절한 연결 세부 정보로 GitLab 애플리케이션 서버를 구성합니다.

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

복제 및 장애 조치가 포함된 PostgreSQL 클러스터에 권장되는 Linux 패키지 구성에는 다음이 필요합니다:

• 최소 세 개의 PostgreSQL 노드.

• 최소 세 개의 Consul 서버 노드.

• 프라이머리 데이터베이스 읽기 및 쓰기를 추적하고 처리하는 최소 세 개의 PgBouncer 노드.

  • PgBouncer 노드 간 요청을 분산하기 위한 내부 로드 밸런서(TCP).

• 데이터베이스 로드 밸런싱 활성화.

  각 PostgreSQL 노드에 로컬 PgBouncer 서비스가 구성되어야 합니다. 이는 프라이머리를 추적하는 메인 PgBouncer 클러스터와 별개입니다.

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

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

먼저 각 노드에 Linux GitLab 패키지를 설치했는지 확인하세요. GitLab 패키지 저장소만 추가하고 선택한 운영 체제에 맞는 GitLab을 설치하되, EXTERNAL_URL 값은 제공하지 마세요.

PostgreSQL 노드#

1. PostgreSQL 노드 중 하나에 SSH로 접속합니다.

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

   sudo gitlab-ctl pg-password-md5 gitlab
   

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

   sudo gitlab-ctl pg-password-md5 pgbouncer
   

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

   sudo gitlab-ctl pg-password-md5 gitlab_replicator
   

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

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

6. 모든 데이터베이스 노드에서 /etc/gitlab/gitlab.rb를 편집하여 # START user configuration 섹션에 표시된 값을 교체합니다:

   # Disable all components except Patroni, PgBouncer and Consul
   roles(['patroni_role', 'pgbouncer_role'])
   
   # PostgreSQL configuration
   postgresql['listen_address'] = '0.0.0.0'
   
   # Sets `max_replication_slots` to double the number of database nodes.
   # Patroni uses one extra slot per node when initiating the replication.
   patroni['postgresql']['max_replication_slots'] = 6
   
   # Set `max_wal_senders` to one more than the number of replication slots in the cluster.
   # This is used to prevent replication from using up all of the
   # available database connections.
   patroni['postgresql']['max_wal_senders'] = 7
   
   # Prevent database migrations from running on upgrade automatically
   gitlab_rails['auto_migrate'] = false
   
   # Configure the Consul agent
   consul['services'] = %w(postgresql)
   ## Enable service discovery for Prometheus
   consul['monitoring_service_discovery'] =  true
   
   # START user configuration
   # Please set the real values as explained in Required Information section
   #
   # Replace PGBOUNCER_PASSWORD_HASH with a generated md5 value
   postgresql['pgbouncer_user_password'] = '<pgbouncer_password_hash>'
   # Replace POSTGRESQL_REPLICATION_PASSWORD_HASH with a generated md5 value
   postgresql['sql_replication_password'] = '<postgresql_replication_password_hash>'
   # Replace POSTGRESQL_PASSWORD_HASH with a generated md5 value
   postgresql['sql_user_password'] = '<postgresql_password_hash>'
   
   # Set up basic authentication for the Patroni API (use the same username/password in all nodes).
   patroni['username'] = '<patroni_api_username>'
   patroni['password'] = '<patroni_api_password>'
   
   # Replace 10.6.0.0/24 with Network Address
   postgresql['trust_auth_cidr_addresses'] = %w(10.6.0.0/24 127.0.0.1/32)
   
   # Local PgBouncer service for Database Load Balancing
   pgbouncer['databases'] = {
      gitlabhq_production: {
         host: "127.0.0.1",
         user: "pgbouncer",
         password: '<pgbouncer_password_hash>'
      }
   }
   
   # Set the network addresses that the exporters will listen on for monitoring
   node_exporter['listen_address'] = '0.0.0.0:9100'
   postgres_exporter['listen_address'] = '0.0.0.0:9187'
   
   ## The IPs of the Consul server nodes
   ## You can also use FQDNs and intermix them with IPs
   consul['configuration'] = {
      retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
   }
   #
   # END user configuration
   

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

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 |      | 10.6.0.21 | Leader | running | 175 |           | *               |
   | postgresql-ha |  | 10.6.0.22 |        | running | 175 | 0         | *               |
   | postgresql-ha |  | 10.6.0.23 |        | running | 175 | 0         | *               |
   

어떤 노드의 'State' 열이 "running"이라고 표시되지 않으면 계속 진행하기 전에 PostgreSQL 복제 및 장애 조치 문제 해결 섹션을 확인하세요.

PgBouncer 구성#

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

다음 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>를 이전에 설정한 비밀번호 해시로 교체합니다:

   # Disable all components except Pgbouncer and Consul agent
   roles(['pgbouncer_role'])
   
   # Configure PgBouncer
   pgbouncer['admin_users'] = %w(pgbouncer gitlab-consul)
   pgbouncer['users'] = {
      'gitlab-consul': {
         password: '<consul_password_hash>'
      },
      'pgbouncer': {
         password: '<pgbouncer_password_hash>'
      }
   }
   
   # Configure Consul agent
   consul['watchers'] = %w(postgresql)
   consul['configuration'] = {
   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
   }
   
   # Enable service discovery for Prometheus
   consul['monitoring_service_discovery'] = true
   
   # Set the network addresses that the exporters will listen on
   node_exporter['listen_address'] = '0.0.0.0:9100'
   pgbouncer_exporter['listen_address'] = '0.0.0.0:9188'
   

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

3. 변경 사항을 적용하기 위해 GitLab을 재구성합니다.

4. Consul이 PgBouncer를 다시 로드할 수 있도록 .pgpass 파일을 생성합니다. 요청 시 PgBouncer 비밀번호를 두 번 입력합니다:

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

5. 각 노드가 현재 마스터와 통신하는지 확인합니다:

   gitlab-ctl pgb-console # You will be prompted for PGBOUNCER_PASSWORD
   

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

6. 콘솔 프롬프트가 사용 가능해지면 다음 쿼리를 실행합니다:

   show databases ; show clients ;
   

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

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

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

   sudo gitlab-ctl status
   

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

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

Redis 구성#

확장 가능한 환경에서 Redis를 사용하는 것은 프라이머리 x 레플리카 토폴로지와 장애 조치 절차를 감시하고 자동으로 시작하는 Redis Sentinel 서비스를 사용하여 가능합니다.

Redis는 Sentinel과 함께 사용할 경우 인증이 필요합니다. 자세한 정보는 Redis 보안 문서를 참조하세요. Redis 서비스를 보호하기 위해 Redis 비밀번호와 엄격한 방화벽 규칙을 조합하여 사용하는 것을 권장합니다. 토폴로지와 아키텍처를 완전히 이해하기 위해 GitLab과 함께 Redis를 구성하기 전에 Redis Sentinel 문서를 읽는 것을 강력히 권장합니다.

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

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

이 섹션에서는 GitLab과 함께 사용할 두 개의 외부 Redis 클러스터를 구성하는 방법을 안내합니다. 다음 IP가 예시로 사용됩니다:

• 10.6.0.61: Redis 프라이머리
• 10.6.0.62: Redis 레플리카 1
• 10.6.0.63: Redis 레플리카 2

자체 Redis 인스턴스 제공#

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

• 이를 위해 신뢰할 수 있는 제공업체 또는 솔루션을 사용해야 합니다. Google Memorystore 및 AWS ElastiCache가 작동하는 것으로 알려져 있습니다.
• Redis Cluster 모드는 특별히 지원되지 않지만, HA가 포함된 Redis Standalone은 지원됩니다.
• 설정에 따라 Redis 퇴거 모드를 설정해야 합니다.

자세한 정보는 인프라 및 서비스를 참조하세요.

Redis 클러스터 구성#

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

프라이머리 및 레플리카 Redis 노드 모두 redis['password']에 동일한 비밀번호가 정의되어야 합니다. 장애 조치 중 언제든지 Sentinel이 노드를 재구성하고 프라이머리에서 레플리카로(또는 그 반대로) 상태를 변경할 수 있습니다.

프라이머리 Redis 노드 구성#

1. 프라이머리 Redis 서버에 SSH로 접속합니다.

2. 선택한 Linux 패키지를 다운로드하고 설치합니다. GitLab 패키지 저장소만 추가하고 선택한 운영 체제에 맞는 GitLab을 설치하세요. 현재 설치와 동일한 버전 및 유형(Community 또는 Enterprise 에디션)을 선택하세요.

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

   # Specify server roles as 'redis_master_role' with Sentinel and the Consul agent
   roles ['redis_sentinel_role', 'redis_master_role', 'consul_role']
   
   # Set IP bind address and Quorum number for Redis Sentinel service
   sentinel['bind'] = '0.0.0.0'
   sentinel['quorum'] = 2
   
   # IP address pointing to a local IP that the other machines can reach to.
   # You can also set bind to '0.0.0.0' which listen in all interfaces.
   # If you really must bind to an external accessible IP, make
   # sure you add extra firewall rules to prevent unauthorized access.
   redis['bind'] = '10.6.0.61'
   
   # Define a port so Redis can listen for TCP requests which will allow other
   # machines to connect to it.
   redis['port'] = 6379
   
   ## Port of primary Redis server for Sentinel, uncomment to change to non default. Defaults
   ## to `6379`.
   #redis['master_port'] = 6379
   
   # Set up password authentication for Redis and replicas (use the same password in all nodes).
   redis['password'] = 'REDIS_PRIMARY_PASSWORD'
   redis['master_password'] = 'REDIS_PRIMARY_PASSWORD'
   
   ## Must be the same in every Redis node
   redis['master_name'] = 'gitlab-redis'
   
   ## The IP of this primary Redis node.
   redis['master_ip'] = '10.6.0.61'
   
   ## Enable service discovery for Prometheus
   consul['monitoring_service_discovery'] =  true
   
   ## The IPs of the Consul server nodes
   ## You can also use FQDNs and intermix them with IPs
   consul['configuration'] = {
      retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
   }
   
   # Set the network addresses that the exporters will listen on
   node_exporter['listen_address'] = '0.0.0.0:9100'
   redis_exporter['listen_address'] = '0.0.0.0:9121'
   
   # Prevent database migrations from running on upgrade automatically
   gitlab_rails['auto_migrate'] = false
   

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

5. 변경 사항을 적용하기 위해 GitLab을 재구성합니다.

레플리카 Redis 노드 구성#

1. 레플리카 Redis 서버에 SSH로 접속합니다.

2. 선택한 Linux 패키지를 다운로드하고 설치합니다. GitLab 패키지 저장소만 추가하고 선택한 운영 체제에 맞는 GitLab을 설치하세요. 현재 설치와 동일한 버전 및 유형(Community 또는 Enterprise 에디션)을 선택하세요.

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

   # Specify server roles as 'redis_sentinel_role' and 'redis_replica_role'
   roles ['redis_sentinel_role', 'redis_replica_role', 'consul_role']
   
   # Set IP bind address and Quorum number for Redis Sentinel service
   sentinel['bind'] = '0.0.0.0'
   sentinel['quorum'] = 2
   
   # IP address pointing to a local IP that the other machines can reach to.
   # You can also set bind to '0.0.0.0' which listen in all interfaces.
   # If you really must bind to an external accessible IP, make
   # sure you add extra firewall rules to prevent unauthorized access.
   redis['bind'] = '10.6.0.62'
   
   # Define a port so Redis can listen for TCP requests which will allow other
   # machines to connect to it.
   redis['port'] = 6379
   
   ## Port of primary Redis server for Sentinel, uncomment to change to non default. Defaults
   ## to `6379`.
   #redis['master_port'] = 6379
   
   # The same password for Redis authentication you set up for the primary node.
   redis['password'] = 'REDIS_PRIMARY_PASSWORD'
   redis['master_password'] = 'REDIS_PRIMARY_PASSWORD'
   
   ## Must be the same in every Redis node
   redis['master_name'] = 'gitlab-redis'
   
   # The IP of the primary Redis node.
   redis['master_ip'] = '10.6.0.61'
   
   ## Enable service discovery for Prometheus
   consul['monitoring_service_discovery'] =  true
   
   ## The IPs of the Consul server nodes
   ## You can also use FQDNs and intermix them with IPs
   consul['configuration'] = {
      retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
   }
   
   # Set the network addresses that the exporters will listen on
   node_exporter['listen_address'] = '0.0.0.0:9100'
   redis_exporter['listen_address'] = '0.0.0.0:9121'
   
   # Prevent database migrations from running on upgrade automatically
   gitlab_rails['auto_migrate'] = false
   

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

5. 변경 사항을 적용하기 위해 GitLab을 재구성합니다.

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

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

Gitaly Cluster(Praefect) 구성#

Gitaly Cluster(Praefect)는 Git 저장소를 저장하기 위한 GitLab 제공 및 권장 내결함성 솔루션입니다. 이 구성에서는 모든 Git 저장소가 클러스터의 모든 Gitaly 노드에 저장되며, 하나가 프라이머리로 지정되고, 프라이머리 노드가 다운되면 자동으로 장애 조치가 발생합니다.

Gitaly Cluster(Praefect)는 내결함성의 이점을 제공하지만, 설정 및 관리에 추가적인 복잡성이 수반됩니다. Gitaly Cluster(Praefect) 배포 전 기존 기술적 제한 사항 및 고려 사항을 검토하세요.

다음에 대한 지침:

• 대신 샤딩된 Gitaly를 구현하려면 이 섹션 대신 별도의 Gitaly 문서를 따르세요. 동일한 Gitaly 사양을 사용하세요.
• Gitaly Cluster(Praefect)에서 관리하지 않는 기존 저장소를 마이그레이션하려면 Gitaly Cluster(Praefect)로 마이그레이션을 참조하세요.

권장 클러스터 설정에는 다음 컴포넌트가 포함됩니다:

• 3개의 Gitaly 노드: Git 저장소의 복제 스토리지.
• 3개의 Praefect 노드: Gitaly Cluster(Praefect)의 라우터 및 트랜잭션 관리자.
• 1개의 Praefect PostgreSQL 노드: Praefect의 데이터베이스 서버. Praefect 데이터베이스 연결을 고가용성으로 만들기 위해 서드파티 솔루션이 필요합니다.
• 서비스 디스커버리: Praefect 노드로의 트래픽 균등 분배. 자세한 정보는 서비스 디스커버리 vs TCP 로드 밸런서를 참조하세요.

이 섹션에서는 권장 표준 설정을 순서대로 구성하는 방법을 자세히 설명합니다. 더 고급 설정은 독립형 Gitaly Cluster(Praefect) 문서를 참조하세요.

서비스 디스커버리 vs TCP 로드 밸런서#

TCP 로드 밸런서는 권장하지 않습니다. TCP 로드 밸런서는 요청 수준이 아닌 연결 수준에서 밸런싱하기 때문입니다. gRPC의 HTTP/2 연결에서는 여러 요청이 수명이 긴 연결을 통해 다중화됩니다. 즉, 연결이 설정될 때 한 번 이루어진 로드 밸런서의 라우팅 결정이 해당 연결의 모든 후속 요청에 적용되며, 이는 다음과 같은 문제를 초래할 수 있습니다:

• 일부 연결이 다른 연결보다 더 많은 요청을 처리하면 트래픽 불균형이 발생합니다.
• Praefect 노드가 다운되면 클라이언트가 다른 Praefect 노드와 연결을 재설정합니다. 다운된 노드가 복구되더라도 다른 노드만큼의 트래픽을 수신하지 않게 됩니다.

서비스 디스커버리는 Praefect 노드 간의 gRPC 요청 수준 라운드 로빈 밸런싱을 가능하게 하여 균등한 트래픽 분배를 보장합니다.

Praefect PostgreSQL 구성#

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

고가용성 설정을 원하는 경우 Praefect에는 서드파티 PostgreSQL 데이터베이스가 필요합니다. 내장 솔루션이 개발 중입니다.

Linux 패키지를 사용한 Praefect 비 HA PostgreSQL 독립형#

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

• 10.6.0.141: Praefect PostgreSQL

먼저 Praefect PostgreSQL 노드에 Linux 패키지를 설치했는지 확인하세요. 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 섹션에 표시된 값을 교체합니다:

   # Disable all components except PostgreSQL and Consul
   roles(['postgres_role', 'consul_role'])
   
   # PostgreSQL configuration
   postgresql['listen_address'] = '0.0.0.0'
   
   # Prevent database migrations from running on upgrade automatically
   gitlab_rails['auto_migrate'] = false
   
   # Configure the Consul agent
   ## Enable service discovery for Prometheus
   consul['monitoring_service_discovery'] =  true
   
   # START user configuration
   # Please set the real values as explained in Required Information section
   #
   # Replace PRAEFECT_POSTGRESQL_PASSWORD_HASH with a generated md5 value
   postgresql['sql_user_password'] = "<praefect_postgresql_password_hash>"
   
   # Replace XXX.XXX.XXX.XXX/YY with Network Address
   postgresql['trust_auth_cidr_addresses'] = %w(10.6.0.0/24 127.0.0.1/32)
   
   # Set the network addresses that the exporters will listen on for monitoring
   node_exporter['listen_address'] = '0.0.0.0:9100'
   postgres_exporter['listen_address'] = '0.0.0.0:9187'
   
   ## The IPs of the Consul server nodes
   ## You can also use FQDNs and intermix them with IPs
   consul['configuration'] = {
      retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
   }
   #
   # END user configuration
   

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

6. 변경 사항을 적용하기 위해 GitLab을 재구성합니다.

7. 사후 구성을 따릅니다.

Praefect HA PostgreSQL 서드파티 솔루션#

앞서 언급한 바와 같이, 완전한 고가용성을 목표로 하는 경우 Praefect 데이터베이스에 서드파티 PostgreSQL 솔루션이 권장됩니다.

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

• 장애 조치 시 변경되지 않는 모든 연결에 대한 고정 IP.
• LISTEN SQL 기능이 지원되어야 합니다.

이를 위해 신뢰할 수 있는 제공업체 또는 솔루션을 사용해야 합니다. Google Cloud SQL과 Amazon RDS가 작동하는 것으로 알려져 있습니다. 그러나 Amazon Aurora는 14.4.0부터 기본으로 활성화된 로드 밸런싱과 호환되지 않습니다.

자세한 정보는 인프라 및 서비스를 참조하세요.

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

Praefect PostgreSQL 사후 구성#

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

사용자 이름을 praefect로, 데이터베이스를 praefect_production으로 하는 것이 권장되며, 이는 PostgreSQL에서 표준으로 구성할 수 있습니다. 사용자의 비밀번호는 이전에 <praefect_postgresql_password>로 구성한 것과 동일합니다.

Linux 패키지 PostgreSQL 설정으로 수행하는 방법은 다음과 같습니다:

1. Praefect PostgreSQL 노드에 SSH로 접속합니다.

2. 관리 권한으로 PostgreSQL 서버에 연결합니다. gitlab-psql 사용자는 Linux 패키지에서 기본으로 추가되므로 이 용도로 사용해야 합니다. 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(Praefect)의 라우터 및 트랜잭션 관리자이며 Gitaly에 대한 모든 연결이 이를 통해 이루어집니다. 이 섹션에서는 구성 방법을 자세히 설명합니다.

Praefect는 클러스터 전체에서 통신을 보호하기 위해 여러 비밀 토큰이 필요합니다:

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

Gitaly Cluster(Praefect) 노드는 virtual storage를 통해 Praefect에서 구성됩니다. 각 스토리지에는 클러스터를 구성하는 각 Gitaly 노드의 세부 정보가 포함되어 있습니다. 각 스토리지에는 이름도 부여되며 이 이름은 구성의 여러 영역에서 사용됩니다. 이 가이드에서 스토리지 이름은 default입니다. 또한 이 가이드는 새 설치를 위한 것으로, 기존 환경을 Gitaly Cluster(Praefect)를 사용하도록 업그레이드하는 경우 다른 이름을 사용해야 할 수 있습니다. 자세한 정보는 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 패키지를 다운로드하고 설치합니다. GitLab 패키지 저장소만 추가하고 선택한 운영 체제에 맞는 GitLab을 설치하세요.

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

   [!note] GitLab에서 필요로 하므로 virtual_storages에서 default 항목을 제거할 수 없습니다.

   # Avoid running unnecessary services on the Praefect server
   gitaly['enable'] = false
   postgresql['enable'] = false
   redis['enable'] = false
   nginx['enable'] = false
   puma['enable'] = false
   sidekiq['enable'] = false
   gitlab_workhorse['enable'] = false
   prometheus['enable'] = false
   alertmanager['enable'] = false
   gitlab_exporter['enable'] = false
   gitlab_kas['enable'] = false
   
   # Praefect Configuration
   praefect['enable'] = true
   
   # Prevent database migrations from running on upgrade automatically
   praefect['auto_migrate'] = false
   gitlab_rails['auto_migrate'] = false
   
   # Configure the Consul agent
   consul['enable'] = true
   ## Enable service discovery for Prometheus
   consul['monitoring_service_discovery'] = true
   
   # START user configuration
   # Please set the real values as explained in Required Information section
   #
   
   praefect['configuration'] = {
      # ...
      listen_addr: '0.0.0.0:2305',
      auth: {
         # ...
         #
         # Praefect External Token
         # This is needed by clients outside the cluster (like GitLab Shell) to communicate with the Praefect cluster
         token: '<praefect_external_token>',
      },
      # Praefect Database Settings
      database: {
         # ...
         host: '10.6.0.141',
         port: 5432,
         dbname: 'praefect_production',
         user: 'praefect',
         password: '<praefect_postgresql_password>',
      },
      # Praefect Virtual Storage config
      # Name of storage hash must match storage name in gitlab_rails['repositories_storages'] on the GitLab
      # server ('praefect') and in gitaly['configuration'][:storage] on Gitaly nodes ('gitaly-1')
      virtual_storage: [
         {
            # ...
            name: 'default',
            node: [
               {
                  storage: 'gitaly-1',
                  address: 'tcp://10.6.0.91:8075',
                  token: '<praefect_internal_token>'
               },
               {
                  storage: 'gitaly-2',
                  address: 'tcp://10.6.0.92:8075',
                  token: '<praefect_internal_token>'
               },
               {
                  storage: 'gitaly-3',
                  address: 'tcp://10.6.0.93:8075',
                  token: '<praefect_internal_token>'
               },
            ],
         },
      ],
      # Set the network address Praefect will listen on for monitoring
      prometheus_listen_addr: '0.0.0.0:9652',
   }
   
   # Set the network address the node exporter will listen on for monitoring
   node_exporter['listen_address'] = '0.0.0.0:9100'
   
   ## The IPs of the Consul server nodes
   ## You can also use FQDNs and intermix them with IPs
   consul['configuration'] = {
      retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
   }
   #
   # END user configuration
   

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

5. Praefect는 메인 GitLab 애플리케이션과 마찬가지로 일부 데이터베이스 마이그레이션을 실행해야 합니다. 이를 위해 마이그레이션을 실행할 하나의 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 서버 노드는 데이터 및 부하에 따라 달라지는 요구 사항이 있습니다.

Gitaly에는 Gitaly 스토리지에 대한 특정 디스크 요구 사항이 있습니다.

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

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

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

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

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

각 노드에서:

1. 선택한 Linux 패키지를 다운로드하고 설치합니다. GitLab 패키지 저장소만 추가하고 선택한 운영 체제에 맞는 GitLab을 설치하되, EXTERNAL_URL 값은 제공하지 마세요.

2. Gitaly 서버 노드의 /etc/gitlab/gitlab.rb 파일을 편집하여 스토리지 경로를 구성하고 네트워크 리스너를 활성화하며 토큰을 구성합니다:

   # https://docs.gitlab.com/omnibus/roles/#gitaly-roles
   roles(["gitaly_role"])
   
   # Prevent database migrations from running on upgrade automatically
   gitlab_rails['auto_migrate'] = false
   
   # Configure the gitlab-shell API callback URL. Without this, `git push` will
   # fail. This can be your 'front door' GitLab URL or an internal load
   # balancer.
   gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
   
   # Configure the Consul agent
   consul['enable'] = true
   ## Enable service discovery for Prometheus
   consul['monitoring_service_discovery'] = true
   
   # START user configuration
   # Please set the real values as explained in Required Information section
   #
   ## The IPs of the Consul server nodes
   ## You can also use FQDNs and intermix them with IPs
   consul['configuration'] = {
      retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
   }
   
   # Set the network address that the node exporter will listen on for monitoring
   node_exporter['listen_address'] = '0.0.0.0:9100'
   
   gitaly['configuration'] = {
      # ...
      #
      # Make Gitaly accept connections on all network interfaces. You must use
      # firewalls to restrict access to this address/port.
      # Comment out following line if you only want to support TLS connections
      listen_addr: '0.0.0.0:8075',
      # Set the network address that Gitaly will listen on for monitoring
      prometheus_listen_addr: '0.0.0.0:9236',
      # Gitaly Auth Token
      # Should be the same as praefect_internal_token
      auth: {
         # ...
         token: '<praefect_internal_token>',
      },
      # Gitaly Pack-objects cache
      # Recommended to be enabled for improved performance but can notably increase disk I/O
      # Refer to https://docs.gitlab.com/administration/gitaly/configure_gitaly/#pack-objects-cache for more info
      pack_objects_cache: {
         # ...
         enabled: true,
      },
   }
   
   #
   # END user configuration
   

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(Praefect) TLS 지원#

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

• 해당 스토리지 항목의 gitaly_address에서 tls:// URL 스키마를 GitLab 구성에 사용합니다.
• 자동으로 제공되지 않으므로 자체 인증서를 준비합니다. 각 Praefect 서버에 해당하는 인증서를 해당 Praefect 서버에 설치해야 합니다.

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

다음에 유의하세요:

• 인증서는 Praefect 서버에 액세스하는 데 사용하는 주소를 지정해야 합니다. 호스트 이름 또는 IP 주소를 인증서의 Subject Alternative Name에 추가해야 합니다.
• 동시에 암호화되지 않은 수신 주소 listen_addr와 암호화된 수신 주소 tls_listen_addr를 모두 구성할 수 있습니다. 필요한 경우 암호화되지 않은 트래픽에서 암호화된 트래픽으로 점진적으로 전환할 수 있습니다. 암호화되지 않은 리스너를 비활성화하려면 praefect['configuration'][:listen_addr] = nil로 설정합니다.
• 내부 로드 밸런서는 TLS 연결을 처리하도록 구성해야 합니다. 로드 밸런서가 TLS 패스스루를 지원하도록 구성합니다. 이는 로드 밸런서가 암호화된 트래픽을 종료하지 않고 백엔드로 전달하는 것입니다. 패스스루/직접 서버 반환(DSR) 로드 밸런서를 사용하지 마세요. 로드 밸런서는 적절한 로드 밸런싱 및 상태 확인을 유지하기 위해 연결을 적극적으로 프록시해야 합니다.

TLS로 Praefect를 구성하려면:

1. Praefect 서버에 대한 인증서를 생성합니다.

2. Praefect 서버에서 /etc/gitlab/ssl 디렉터리를 생성하고 키와 인증서를 복사합니다:

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

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

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

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

5. Praefect 클라이언트(각 Gitaly 서버 포함)에서 인증서 또는 인증 기관을 /etc/gitlab/trusted-certs에 복사합니다:

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

6. Praefect 클라이언트(Gitaly 서버 제외)에서 /etc/gitlab/gitlab.rb의 gitlab_rails['repositories_storages']를 다음과 같이 편집합니다:

   gitlab_rails['repositories_storages'] = {
     "default" => {
       "gitaly_address" => 'tls://LOAD_BALANCER_SERVER_ADDRESS:3305',
       "gitaly_token" => 'PRAEFECT_EXTERNAL_TOKEN'
     }
   }
   

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

Sidekiq 구성#

Sidekiq에는 Redis, PostgreSQL 및 Gitaly 인스턴스에 대한 연결이 필요합니다. 또한 권장 사항에 따라 오브젝트 스토리지에 대한 연결도 필요합니다.

데이터 오브젝트에 NFS 대신 오브젝트 스토리지를 사용하는 것이 권장되므로 다음 예시에는 오브젝트 스토리지 구성이 포함되어 있습니다.

환경의 Sidekiq 작업 처리가 긴 큐로 인해 느린 경우 그에 맞게 스케일링할 수 있습니다. 자세한 정보는 스케일링 문서를 참조하세요.

Container Registry, SAML 또는 LDAP와 같은 추가 GitLab 기능을 구성할 때 Rails 구성 외에도 Sidekiq 구성을 업데이트하세요. 자세한 정보는 외부 Sidekiq 문서를 참조하세요.

다음 Sidekiq 노드가 예시로 사용됩니다:

• 10.6.0.71: Sidekiq 1
• 10.6.0.72: Sidekiq 2

Sidekiq 노드를 구성하려면 각 노드에서:

1. Sidekiq 서버에 SSH로 접속합니다.

2. PostgreSQL, Gitaly 및 Redis 포트에 액세스할 수 있는지 확인합니다:

   telnet  5432 # PostgreSQL
   telnet  8075 # Gitaly
   telnet  6379 # Redis
   

3. 선택한 Linux 패키지를 다운로드하고 설치합니다. GitLab 패키지 저장소만 추가하고 선택한 운영 체제에 맞는 GitLab을 설치하세요.

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

   # https://docs.gitlab.com/omnibus/roles/#sidekiq-roles
   roles(["sidekiq_role"])
   
   # External URL
   ## This should match the URL of the external load balancer
   external_url 'https://gitlab.example.com'
   
   # Redis
   redis['master_name'] = 'gitlab-redis'
   
   ## The same password for Redis authentication you set up for the master node.
   redis['master_password'] = '<redis_primary_password>'
   
   ## A list of sentinels with `host` and `port`
   gitlab_rails['redis_sentinels'] = [
      {'host' => '10.6.0.11', 'port' => 26379},
      {'host' => '10.6.0.12', 'port' => 26379},
      {'host' => '10.6.0.13', 'port' => 26379},
   ]
   
   # Gitaly Cluster
   ## repositories_storages gets configured for the Praefect virtual storage
   ## Address is the Internal Load Balancer for Praefect
   ## Token is the praefect_external_token
   gitlab_rails['repositories_storages'] = {
     "default" => {
       "gitaly_address" => "tcp://10.6.0.40:2305", # internal load balancer IP
       "gitaly_token" => '<praefect_external_token>'
     }
   }
   
   # PostgreSQL
   gitlab_rails['db_host'] = '10.6.0.40' # internal load balancer 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
   
   ## Prevent database migrations from running on upgrade automatically
   gitlab_rails['auto_migrate'] = false
   
   # Sidekiq
   sidekiq['listen_address'] = "0.0.0.0"
   
   ## Set number of Sidekiq queue processes to the same number as available CPUs
   sidekiq['queue_groups'] = ['*'] * 4
   
   # Monitoring
   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)
   }
   
   ## Set the network addresses that the exporters will listen on
   node_exporter['listen_address'] = '0.0.0.0:9100'
   
   ## Add the monitoring node's IP address to the monitoring whitelist
   gitlab_rails['monitoring_whitelist'] = ['10.6.0.81/32', '127.0.0.0/8']
   gitlab_rails['prometheus_address'] = '10.6.0.81:9090'
   
   # Object Storage
   ## This is an example for configuring Object Storage on GCP
   ## Replace this config with your chosen Object Storage provider as desired
   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을 재구성합니다.

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

   sudo gitlab-ctl status
   

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

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

GitLab Rails 구성#

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

Rails에는 Redis, PostgreSQL 및 Gitaly 인스턴스에 대한 연결이 필요합니다. 또한 권장 사항에 따라 오브젝트 스토리지에 대한 연결도 필요합니다.

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

1. 선택한 Linux 패키지를 다운로드하고 설치합니다. GitLab 패키지 저장소만 추가하고 선택한 운영 체제에 맞는 GitLab을 설치하세요.

2. /etc/gitlab/gitlab.rb를 생성하거나 편집하고 다음 구성을 사용합니다. 노드 간 링크의 균일성을 유지하기 위해 애플리케이션 서버의 external_url은 사용자가 GitLab에 액세스하는 데 사용할 외부 URL을 가리켜야 합니다. 이는 GitLab 애플리케이션 서버로 트래픽을 라우팅하는 외부 로드 밸런서의 URL입니다:

   external_url 'https://gitlab.example.com'
   
   # gitlab_rails['repositories_storages'] gets configured for the Praefect virtual storage
   # Address is the Internal Load Balancer for Praefect
   # Token is the praefect_external_token
   gitlab_rails['repositories_storages'] = {
     "default" => {
       "gitaly_address" => "tcp://10.6.0.40:2305", # internal load balancer IP
       "gitaly_token" => '<praefect_external_token>'
     }
   }
   
   ## Disable components that will not be on the GitLab application server
   roles(['application_role'])
   gitaly['enable'] = false
   sidekiq['enable'] = false
   
   ## PostgreSQL connection details
   # Disable PostgreSQL on the application node
   postgresql['enable'] = false
   gitlab_rails['db_host'] = '10.6.0.20' # internal load balancer 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
   
   # Prevent database migrations from running on upgrade automatically
   gitlab_rails['auto_migrate'] = false
   
   ## Redis connection details
   ## Must be the same in every sentinel node
   redis['master_name'] = 'gitlab-redis'
   
   ## The same password for Redis authentication you set up for the Redis primary node.
   redis['master_password'] = '<redis_primary_password>'
   
   ## A list of sentinels with `host` and `port`
   gitlab_rails['redis_sentinels'] = [
     {'host' => '10.6.0.11', 'port' => 26379},
     {'host' => '10.6.0.12', 'port' => 26379},
     {'host' => '10.6.0.13', 'port' => 26379}
   ]
   
   ## Enable service discovery for Prometheus
   consul['enable'] = true
   consul['monitoring_service_discovery'] =  true
   
   # Set the network addresses that the exporters used for monitoring will listen on
   node_exporter['listen_address'] = '0.0.0.0:9100'
   gitlab_workhorse['prometheus_listen_addr'] = '0.0.0.0:9229'
   sidekiq['listen_address'] = "0.0.0.0"
   puma['listen'] = '0.0.0.0'
   
   ## The IPs of the Consul server nodes
   ## You can also use FQDNs and intermix them with IPs
   consul['configuration'] = {
      retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
   }
   
   # Add the monitoring node's IP address to the monitoring whitelist and allow it to
   # scrape the NGINX metrics
   gitlab_rails['monitoring_whitelist'] = ['10.6.0.81/32', '127.0.0.0/8']
   nginx['status']['options']['allow'] = ['10.6.0.81/32', '127.0.0.0/8']
   gitlab_rails['prometheus_address'] = '10.6.0.81:9090'
   
   ## Uncomment and edit the following options if you have set up NFS
   ##
   ## Prevent GitLab from starting if NFS data mounts are not available
   ##
   #high_availability['mountpoint'] = '/var/opt/gitlab/git-data'
   ##
   ## Ensure UIDs and GIDs match between servers for permissions via NFS
   ##
   #user['uid'] = 9000
   #user['gid'] = 9000
   #web_server['uid'] = 9001
   #web_server['gid'] = 9001
   #registry['uid'] = 9002
   #registry['gid'] = 9002
   
   # Object storage
   # This is an example for configuring Object Storage on GCP
   # Replace this config with your chosen Object Storage provider as desired
   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를 사용하는 경우 gitlab_rails['repositories_storages'] 항목이 tcp 대신 tls로 구성되어 있는지 확인합니다:

   gitlab_rails['repositories_storages'] = {
     "default" => {
       "gitaly_address" => "tls://10.6.0.40:2305", # internal load balancer 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. 처음 구성한 Rails 노드에서 SSH 호스트 키(이름 형식이 /etc/ssh/ssh_host_*_key*인 모든 파일)를 복사하여 이 서버의 동일한 이름의 파일에 추가하거나 교체합니다. 이렇게 하면 사용자가 로드 밸런싱된 Rails 노드에 접속할 때 호스트 불일치 오류가 발생하지 않습니다. 이것이 구성하는 첫 번째 Linux 패키지 노드인 경우 이 단계를 건너뛸 수 있습니다.

6. 데이터베이스 마이그레이션이 업그레이드 시 자동이 아닌 재구성 중에만 실행되도록 하려면 다음을 실행합니다:

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

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

7. 변경 사항을 적용하기 위해 GitLab을 재구성합니다.

8. 증분 로깅을 활성화합니다.

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

10. 로그를 확인하여 요청을 봅니다:

    sudo gitlab-ctl tail gitaly
    

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

    sudo gitlab-ctl status
    

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

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

이전 예시와 같이 external_url에 https를 지정하면 GitLab은 SSL 인증서가 /etc/gitlab/ssl/에 있을 것으로 예상합니다. 인증서가 없으면 NGINX가 시작에 실패합니다. 자세한 정보는 HTTPS 문서를 참조하세요.

GitLab Rails 사후 구성#

1. 모든 마이그레이션이 실행되었는지 확인합니다:

   gitlab-rake gitlab:db:configure
   

   이 작업을 수행하려면 Rails 노드가 PgBouncer를 우회하여 프라이머리 데이터베이스에 직접 연결하도록 구성해야 합니다. 마이그레이션이 완료되면 PgBouncer를 통과하도록 노드를 다시 구성해야 합니다.

2. 데이터베이스에서 인증된 SSH 키의 빠른 조회를 구성합니다.

Prometheus 구성#

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

1. 모니터링 노드에 SSH로 접속합니다.

2. 선택한 Linux 패키지를 다운로드하고 설치합니다. GitLab 패키지 저장소만 추가하고 선택한 운영 체제에 맞는 GitLab을 설치하세요.

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

   roles(['monitoring_role', 'consul_role'])
   
   external_url 'http://gitlab.example.com'
   
   # Prometheus
   prometheus['listen_address'] = '0.0.0.0:9090'
   prometheus['monitor_kubernetes'] = false
   
   # Enable service discovery for Prometheus
   consul['monitoring_service_discovery'] =  true
   consul['configuration'] = {
      retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
   }
   
   # Configure Prometheus to scrape services not covered by discovery
   prometheus['scrape_configs'] = [
      {
         'job_name': 'pgbouncer',
         'static_configs' => [
            'targets' => [
            "10.6.0.31:9188",
            "10.6.0.32:9188",
            "10.6.0.33:9188",
            ],
         ],
      },
      {
         'job_name': 'praefect',
         'static_configs' => [
            'targets' => [
            "10.6.0.131:9652",
            "10.6.0.132:9652",
            "10.6.0.133:9652",
            ],
         ],
      },
   ]
   
   nginx['enable'] = false
   

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

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

   sudo gitlab-ctl status
   

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

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

오브젝트 스토리지 구성#

GitLab은 다양한 유형의 데이터를 보관하기 위해 오브젝트 스토리지 서비스 사용을 지원합니다. 데이터 오브젝트에 NFS 대신 권장되며 일반적으로 오브젝트 스토리지가 훨씬 더 성능이 좋고 안정적이며 확장 가능하므로 더 큰 설정에서 더 좋습니다. 자세한 정보는 인프라 및 서비스를 참조하세요.

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

• 통합 형식: 지원되는 모든 오브젝트 유형에서 단일 자격 증명이 공유됩니다.
• 스토리지별 형식: 모든 오브젝트가 자체 오브젝트 스토리지 연결 및 구성을 정의합니다.

사용 가능한 경우 다음 예시에서는 통합 형식이 사용됩니다.

각 데이터 유형에 대해 별도의 버킷을 사용하는 것이 GitLab에 권장되는 접근 방식입니다. 이렇게 하면 GitLab이 저장하는 다양한 유형의 데이터 간에 충돌이 발생하지 않습니다. 향후 단일 버킷 사용을 활성화할 계획이 있습니다.

증분 로깅 활성화#

GitLab Runner는 작업 로그를 청크 단위로 반환하며, Linux 패키지는 통합 오브젝트 스토리지를 사용하는 경우에도 기본적으로 /var/opt/gitlab/gitlab-ci/builds에 디스크에 임시로 캐시합니다. 기본 구성에서는 모든 GitLab Rails 및 Sidekiq 노드에서 NFS를 통해 이 디렉터리를 공유해야 합니다.

NFS를 통한 작업 로그 공유가 지원되지만, 증분 로깅을 활성화하여(NFS 노드가 배포되지 않은 경우 필수) NFS를 사용할 필요를 피하세요. 증분 로깅은 작업 로그의 임시 캐싱에 디스크 공간 대신 Redis를 사용합니다.

고급 검색 구성#

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

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

더 낮은 사용자 수를 위한 지원 수정 사항 (HA)#

60 RPS 또는 3,000명 사용자 GitLab 레퍼런스 아키텍처는 고가용성(HA)을 달성하는 가장 작은 권장 아키텍처입니다. 그러나 더 적은 사용자 또는 더 낮은 RPS를 처리해야 하지만 HA를 유지해야 하는 환경의 경우, 복잡성과 비용을 줄이기 위해 이 아키텍처에 대한 여러 지원 수정 사항이 있습니다.

GitLab으로 HA를 달성하기 위해서는 60 RPS 또는 3,000명 사용자 아키텍처의 구성이 궁극적으로 필요합니다. 각 컴포넌트에는 따라야 할 다양한 고려 사항과 규칙이 있으며, 아키텍처는 이 모든 것을 충족합니다. 이 아키텍처의 더 작은 버전은 근본적으로 동일하지만, 더 작은 성능 요구 사항으로 다음 수정 사항이 지원됩니다:

• 노드 사양 낮추기: 사용자 수에 따라 원하는 대로 모든 제안 노드 사양을 낮출 수 있습니다. 그러나 일반 요구 사항보다 낮추지 않는 것이 권장됩니다.
• 특정 노드 결합: 성능 저하를 감수하고 복잡성을 줄이기 위해 다음 특정 컴포넌트를 동일한 노드에 결합할 수 있습니다:
  • GitLab Rails와 Sidekiq: Sidekiq 노드를 제거하고 대신 GitLab Rails 노드에서 컴포넌트를 활성화할 수 있습니다.
  • PostgreSQL과 PgBouncer: PgBouncer 노드를 제거하고 내부 로드 밸런서가 이를 가리키도록 PostgreSQL 노드에서 활성화할 수 있습니다. 그러나 데이터베이스 로드 밸런싱을 활성화하려면 별도의 PgBouncer 어레이가 여전히 필요합니다.
• 노드 수 줄이기: 일부 노드 유형은 합의가 필요하지 않으며 더 적은 노드(그러나 중복성을 위해 하나 이상)로 실행할 수 있습니다:
  • GitLab Rails 및 Sidekiq: 상태 비저장 서비스는 최소 노드 수가 없습니다. 두 개이면 중복성이 충분합니다.
  • PostgreSQL 및 PgBouncer: 쿼럼이 엄격히 필요하지 않습니다. 두 개의 PostgreSQL 노드와 두 개의 PgBouncer 노드이면 중복성이 충분합니다.
  • Consul, Redis Sentinel 및 Praefect: 투표 쿼럼을 위해 홀수가 필요하며 최소 세 개의 노드가 필요합니다.
• 신뢰할 수 있는 클라우드 PaaS 솔루션에서 특정 컴포넌트 실행: 다음 특정 컴포넌트는 신뢰할 수 있는 클라우드 제공업체 PaaS 솔루션에서 실행할 수 있습니다. 이렇게 하면 추가 종속 컴포넌트도 제거할 수 있습니다:
  • PostgreSQL: Google Cloud SQL 또는 Amazon RDS와 같은 신뢰할 수 있는 클라우드 PaaS 솔루션에서 실행할 수 있습니다. 이 설정에서는 PgBouncer 및 Consul 노드가 더 이상 필요하지 않습니다:
    • Prometheus 자동 검색이 요구 사항인 경우 Consul이 여전히 필요할 수 있으며, 그렇지 않으면 모든 노드에 대해 수동으로 스크레이프 구성을 추가해야 합니다.
  • Redis: Google Memorystore 및 AWS ElastiCache와 같은 신뢰할 수 있는 클라우드 PaaS 솔루션에서 실행할 수 있습니다. 이 설정에서는 Redis Sentinel이 더 이상 필요하지 않습니다.

Helm Charts를 사용한 클라우드 네이티브 하이브리드 레퍼런스 아키텍처 (대안)#

대안적 접근 방식은 Kubernetes에서 특정 GitLab 컴포넌트를 실행하는 것입니다. 다음 서비스가 지원됩니다:

• GitLab Rails
• Sidekiq
• NGINX
• Toolbox
• Migrations
• Prometheus

하이브리드 설치는 클라우드 네이티브와 기존 컴퓨팅 배포의 이점을 모두 활용합니다. 이를 통해 상태 비저장 컴포넌트는 클라우드 네이티브 워크로드 관리 이점을 활용할 수 있고, 상태 유지 컴포넌트는 Linux 패키지 설치가 포함된 컴퓨팅 VM에 배포되어 영속성 증가의 이점을 얻을 수 있습니다.

설정 지침(Kubernetes와 백엔드 컴포넌트 간에 동기화할 GitLab 시크릿에 대한 지침 포함)은 Helm Charts 고급 구성 문서를 참조하세요.

Kubernetes에서의 Gitaly 가용성, 제한 사항 및 배포 고려 사항에 대한 정보는 Kubernetes에서의 Gitaly를 참조하세요.

클러스터 토폴로지#

다음 표와 다이어그램은 이전에 문서화된 일반 환경과 동일한 형식을 사용하여 하이브리드 환경을 자세히 설명합니다.

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

• 이 설정에서는 Google Kubernetes Engine(GKE) 및 Amazon Elastic Kubernetes Service(EKS)를 정기적으로 테스트하고 권장합니다. 다른 Kubernetes 서비스도 작동할 수 있지만 결과가 다를 수 있습니다.
• 머신 유형 예시는 설명 목적으로 제공됩니다. 이러한 유형은 검증 및 테스트에 사용되지만 규범적 기본값으로 의도된 것은 아닙니다. 나열된 요구 사항을 충족하는 다른 머신 유형으로 전환하는 것이 지원됩니다. 자세한 정보는 지원되는 머신 유형을 참조하세요.
• Webservice 및 Sidekiq 대상 노드 풀 합계는 GitLab 컴포넌트에만 해당됩니다. 선택한 Kubernetes 제공업체의 시스템 프로세스에 추가 리소스가 필요합니다. 주어진 예시는 이를 고려합니다.
• 지원 대상 노드 풀 합계는 GitLab 배포를 지원하기 위한 여러 리소스와 요구 사항에 따라 추가 배포를 수용하기 위해 일반적으로 제공됩니다. 다른 노드 풀과 마찬가지로 선택한 Kubernetes 제공업체의 시스템 프로세스에도 리소스가 필요합니다. 주어진 예시는 이를 고려합니다.
• 프로덕션 배포에서는 특정 노드에 파드를 할당할 필요가 없습니다. 그러나 복원력 있는 클라우드 아키텍처 관행에 맞추어 각 풀에 서로 다른 가용 영역에 분산된 여러 노드를 갖는 것이 권장됩니다.
• 효율성을 위해 Cluster Autoscaler와 같은 자동 스케일링을 활성화하는 것이 권장되지만, 지속적인 성능을 보장하기 위해 일반적으로 Webservice 및 Sidekiq 파드에 대해 75% 바닥선을 목표로 하는 것이 권장됩니다.

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

각주:

1. 머신 유형 예시는 설명 목적으로 제공됩니다. 이러한 유형은 검증 및 테스트에 사용되지만 규범적 기본값으로 의도된 것은 아닙니다. 나열된 요구 사항을 충족하는 다른 머신 유형으로 전환하는 것이 지원되며, 가능한 경우 ARM 변형도 포함됩니다. 자세한 정보는 지원되는 머신 유형을 참조하세요.
2. 선택적으로 신뢰할 수 있는 서드파티 외부 PaaS PostgreSQL 솔루션에서 실행할 수 있습니다. 자세한 정보는 자체 PostgreSQL 인스턴스 제공을 참조하세요.
3. 선택적으로 신뢰할 수 있는 서드파티 외부 PaaS Redis 솔루션에서 실행할 수 있습니다. 자세한 정보는 자체 Redis 인스턴스 제공을 참조하세요.
4. HA 기능을 제공할 수 있는 신뢰할 수 있는 서드파티 로드 밸런서 또는 서비스(LB PaaS)와 함께 실행하는 것이 권장됩니다. 크기 조정은 선택한 로드 밸런서 및 네트워크 대역폭과 같은 추가 요소에 따라 달라집니다. 자세한 정보는 로드 밸런서를 참조하세요.
5. 신뢰할 수 있는 클라우드 제공업체 또는 자체 관리 솔루션에서 실행해야 합니다. 자세한 정보는 오브젝트 스토리지 구성을 참조하세요.
6. Gitaly Cluster(Praefect)는 내결함성의 이점을 제공하지만, 설정 및 관리에 추가적인 복잡성이 수반됩니다. Gitaly Cluster(Praefect) 배포 전 기존 기술적 제한 사항 및 고려 사항을 검토하세요. 샤딩된 Gitaly를 원하는 경우 이전 표에서 Gitaly에 대해 나열된 것과 동일한 사양을 사용하세요.
7. Gitaly 사양은 정상 상태에서의 사용 패턴과 저장소 크기의 높은 백분위수를 기반으로 합니다. 그러나 대규모 모노레포(수 기가바이트 이상) 또는 추가 워크로드가 있는 경우 Git 및 Gitaly 성능에 상당한 영향을 미칠 수 있으며 추가 조정이 필요할 수 있습니다.

@startuml 3k
skinparam linetype ortho
card "Kubernetes via Helm Charts" as kubernetes {
card "External Load Balancer" as elb #6a9be7
together {
collections "Webservice" as gitlab #32CD32
collections "Sidekiq" as sidekiq #ff8dd1
}
card "Supporting Services" as support
}
card "Internal Load Balancer" as ilb #9370DB
collections "Consul x3" as consul #e76a9b
card "Gitaly Cluster" as gitaly_cluster {
collections "Praefect x3" as praefect #FF8C00
collections "Gitaly x3" as gitaly #FF8C00
card "Praefect PostgreSQL*\n//Non fault-tolerant//" as praefect_postgres #FF8C00
praefect -[#FF8C00]-> gitaly
praefect -[#FF8C00]> praefect_postgres
}
card "Database" as database {
collections "PGBouncer x3" as pgbouncer #4EA7FF
card "PostgreSQL (Primary)" as postgres_primary #4EA7FF
collections "PostgreSQL (Secondary) x2" as postgres_secondary #4EA7FF
pgbouncer -[#4EA7FF]-> postgres_primary
postgres_primary .[#4EA7FF]> postgres_secondary
}
card "redis" as redis {
collections "Redis x3" as redis_nodes #FF6347
}
cloud "Object Storage" as object_storage #white
elb -[#6a9be7]-> gitlab
elb -[hidden]-> sidekiq
elb -[hidden]-> support
gitlab -[#32CD32]--> ilb
gitlab -[#32CD32]r--> object_storage
gitlab -[#32CD32,norank]----> redis
gitlab -[#32CD32]----> database
sidekiq -[#ff8dd1]--> ilb
sidekiq -[#ff8dd1]r--> object_storage
sidekiq -[#ff8dd1,norank]----> redis
sidekiq .[#ff8dd1]----> database
ilb -[#9370DB]--> gitaly_cluster
ilb -[#9370DB]--> database
ilb -[hidden,norank]--> redis
consul .[#e76a9b]--> database
consul .[#e76a9b,norank]--> gitaly_cluster
consul .[#e76a9b]--> redis
@enduml

Kubernetes 컴포넌트 목표#

다음 섹션에서는 Kubernetes에 배포된 GitLab 컴포넌트에 사용되는 목표를 자세히 설명합니다.

Webservice#

각 Webservice 파드(Puma 및 Workhorse)는 다음 구성으로 실행하는 것이 권장됩니다:

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

60 RPS 또는 3,000명 사용자의 경우 총 Puma worker 수를 약 16개로 권장하므로 최소 4개의 Webservice 파드를 실행하는 것이 권장됩니다.

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

Gateway API / Ingress#

Gateway API 또는 Ingress 컨트롤러 파드를 Webservice 노드 전체에 DaemonSet으로 배포하는 것도 권장됩니다. 이를 통해 컨트롤러가 서비스하는 Webservice 파드와 함께 동적으로 스케일링할 수 있으며, 일반적으로 더 큰 머신 유형이 가지는 높은 네트워크 대역폭을 활용할 수 있습니다.

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

Sidekiq#

각 Sidekiq 파드는 다음 구성으로 실행하는 것이 권장됩니다:

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

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

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

지원#

지원 노드 풀은 Webservice 및 Sidekiq 풀에 필요하지 않은 모든 지원 배포를 수용하도록 설계되었습니다.

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

Container Registry, Pages 또는 모니터링과 같은 추가 배포를 수행하려면 Webservice 또는 Sidekiq 풀이 아닌 가능한 경우 지원 노드 풀에 배포하세요. 지원 노드 풀은 여러 추가 배포를 수용하도록 설계되었습니다. 그러나 배포가 주어진 풀에 맞지 않으면 노드 풀을 그에 맞게 늘릴 수 있습니다. 반대로, 사용 사례에서 풀이 과다 프로비저닝된 경우 그에 맞게 줄일 수 있습니다.

예시 구성 파일#

60 RPS 또는 3,000명 사용자 레퍼런스 아키텍처 구성에 대한 GitLab Helm Charts 예시는 Charts 프로젝트에서 찾을 수 있습니다.

다음 단계#

이 가이드를 따른 후 핵심 기능이 적절히 구성된 새 GitLab 환경이 준비되어야 합니다.

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