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

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

• 타깃 부하: API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS

• 고가용성: 없음. 고가용성 환경을 원하는 경우 수정된 3K 또는 60 RPS 레퍼런스 아키텍처를 따를 수 있습니다.

• 클라우드 네이티브 하이브리드: 예

• 어떤 레퍼런스 아키텍처를 사용해야 할지 모르시나요? 자세한 내용은 이 가이드를 참조하세요.

각주:

• 머신 유형 예시는 예시 목적으로 제공됩니다. 이러한 유형은 유효성 검사 및 테스트에서 사용되지만 규범적인 기본값으로 의도된 것은 아닙니다. 사용 가능한 경우 ARM 변형을 포함하여 나열된 요구 사항을 충족하는 다른 머신 유형으로 전환하는 것이 지원됩니다. 자세한 내용은 지원되는 머신 유형을 참조하세요.

• 선택적으로 평판 있는 서드파티 외부 PaaS PostgreSQL 솔루션에서 실행할 수 있습니다. 자세한 내용은 자체 PostgreSQL 인스턴스 제공 및 인프라 및 서비스를 참조하세요.

• 선택적으로 평판 있는 서드파티 외부 PaaS Redis 솔루션에서 실행할 수 있습니다. 자세한 내용은 자체 Redis 인스턴스 제공 및 인프라 및 서비스를 참조하세요.

• 평판 있는 서드파티 로드 밸런서 또는 서비스(LB PaaS)와 함께 실행하는 것이 권장됩니다. 크기는 선택한 로드 밸런서 및 네트워크 대역폭과 같은 추가 요소에 따라 다릅니다. 자세한 내용은 로드 밸런서를 참조하세요.

• 평판 있는 클라우드 공급자 또는 Self-Managed 솔루션에서 실행해야 합니다. 자세한 내용은 오브젝트 스토리지 구성을 참조하세요.

• Gitaly 사양은 정상 상태의 일반 크기 리포지터리 사용을 기반으로 합니다. 그러나 대형 모노레포(수 기가바이트 이상)가 있는 경우 Git 및 Gitaly 성능에 상당한 영향을 미칠 수 있으며 사양 증가가 필요할 수 있습니다. 자세한 내용은 대형 모노레포를 참조하세요.

• 컴포넌트가 상태 저장 데이터를 저장하지 않으므로 Auto Scaling Groups(ASGs)에 배치할 수 있습니다. 그러나 마이그레이션 및 Mailroom과 같은 특정 컴포넌트는 하나의 노드에서만 실행할 수 있어 Kubernetes에서 더 잘 처리되므로 일반적으로 클라우드 네이티브 하이브리드 설정이 더 선호됩니다.

  인스턴스 구성과 관련된 모든 PaaS 솔루션의 경우, 원하는 경우 복원력을 위해 여러 가용 영역에 배포하는 것이 권장됩니다.

@startuml 2k skinparam linetype ortho

card "External Load Balancer" as elb #6a9be7

together { collections "GitLab Rails x2" as gitlab #32CD32 card "Sidekiq" as sidekiq #ff8dd1 }

card "Prometheus" as monitor #7FFFD4 card "Gitaly" as gitaly #FF8C00 card "PostgreSQL" as postgres #4EA7FF card "Redis" as redis #FF6347 cloud "Object Storage" as object_storage #white

elb -[#6a9be7]-> gitlab elb -[#6a9be7,norank]--> monitor

gitlab -[#32CD32]--> gitaly gitlab -[#32CD32]--> postgres gitlab -[#32CD32]> object_storage gitlab -[#32CD32]--> redis

sidekiq -[#ff8dd1]> object_storage sidekiq -[#ff8dd1]--> redis sidekiq .[#ff8dd1]--> postgres sidekiq -[hidden]-> monitor

monitor .[#7FFFD4]u-> gitlab monitor .[#7FFFD4]-> gitaly monitor .[#7FFFD4]-> postgres monitor .[#7FFFD4,norank]--> redis monitor .[#7FFFD4,norank]u--> elb monitor .[#7FFFD4]u-> sidekiq

@enduml

요구 사항#

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

테스트 방법론#

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

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

테스트 방법론에 대한 자세한 내용은 유효성 검사 및 테스트 결과 섹션을 참조하세요.

성능 고려 사항#

다음과 같은 경우 추가 조정이 필요할 수 있습니다:

• 나열된 목표보다 지속적으로 높은 처리량

• 대형 모노레포

• 상당한 추가 워크로드

이러한 경우 자세한 내용은 환경 확장을 참조하세요. 이러한 고려 사항이 귀하에게 해당될 수 있다고 생각되면 필요에 따라 추가 지침을 위해 당사에 문의하세요.

로드 밸런서 구성#

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

• Linux 패키지 환경용 HAProxy

• 클라우드 네이티브 하이브리드용 Gateway API 또는 Ingress 구현을 갖춘 클라우드 공급자 동등 제품

컴포넌트 설정#

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

• GitLab 애플리케이션 서비스 노드의 부하 분산을 처리하기 위해 외부 로드 밸런싱 노드를 구성합니다.

• GitLab의 데이터베이스인 PostgreSQL을 구성합니다.

• 세션 데이터, 임시 캐시 정보 및 백그라운드 작업 큐를 저장하는 Redis를 구성합니다.

• Git 리포지터리에 대한 액세스를 제공하는 Gitaly를 구성합니다.

• 백그라운드 작업 처리를 위해 Sidekiq을 구성합니다.

• Puma, Workhorse, GitLab Shell을 실행하고 모든 프론트엔드 요청(UI, API, HTTP/SSH를 통한 Git 포함)을 처리하기 위해 메인 GitLab Rails 애플리케이션을 구성합니다.

• GitLab 환경을 모니터링하기 위해 Prometheus를 구성합니다.

• 공유 데이터 오브젝트에 사용되는 오브젝트 스토리지를 구성합니다.

• 전체 GitLab 인스턴스에서 더 빠르고 고급화된 코드 검색을 위해 고급 검색을 구성합니다(선택 사항).

외부 로드 밸런서 구성#

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

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

준비 상태 확인#

외부 로드 밸런서가 기본 제공 모니터링 엔드포인트를 통해 작동 중인 서비스로만 라우팅되도록 합니다. 준비 상태 확인은 모두 확인 중인 노드에서 추가 구성이 필요하며, 그렇지 않으면 외부 로드 밸런서가 연결할 수 없습니다.

포트#

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

• (1): 웹 터미널 지원을 위해서는 로드 밸런서가 WebSocket 연결을 올바르게 처리해야 합니다. HTTP 또는 HTTPS 프록시를 사용할 때 로드 밸런서는 Connection 및 Upgrade hop-by-hop 헤더를 통과하도록 구성해야 합니다. 자세한 내용은 웹 터미널 통합 가이드를 참조하세요.

• (2): 포트 443에 HTTPS 프로토콜을 사용할 때 로드 밸런서에 SSL 인증서를 추가해야 합니다. SSL을 GitLab 애플리케이션 서버에서 종료하려면 TCP 프로토콜을 사용하세요.

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

• (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을 종료하는 경우#

HTTP(S) 프로토콜 대신 TCP로 포트 443의 연결을 통과하도록 로드 밸런서를 구성하세요. 이렇게 하면 연결이 애플리케이션 노드의 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 문서를 참조하세요.

컴포넌트 설정으로 돌아가기

PostgreSQL 구성#

이 섹션에서는 GitLab에서 사용할 외부 PostgreSQL 데이터베이스를 구성하는 과정을 안내합니다.

자체 PostgreSQL 인스턴스 제공#

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

지원되는 PostgreSQL 버전을 실행하는 평판 있는 공급자를 사용하세요. 다음 서비스들이 잘 작동하는 것으로 알려져 있습니다:

• Google Cloud SQL.

• Amazon RDS.

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

• 인프라 및 서비스.

• 데이터베이스 서비스 모범 사례.

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

• 데이터베이스 요구 사항 문서에 따라 PostgreSQL을 설정하세요.

• 필요한 사용자 및 데이터베이스를 구성하세요.

• GitLab Rails 구성을 따라 적절한 연결 세부 정보로 GitLab 애플리케이션 서버를 구성하세요.

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

PostgreSQL 서버에 SSH로 접속합니다.

선택한 Linux 패키지를 다운로드하고 설치합니다. GitLab 패키지 리포지터리만 추가하고 선택한 운영 체제에 GitLab을 설치해야 합니다.

PostgreSQL의 비밀번호 해시를 생성합니다. 기본 사용자 이름 gitlab(권장)을 사용한다고 가정합니다. 명령이 비밀번호와 확인을 요청합니다. 다음 단계에서 이 명령의 출력 값을 POSTGRESQL_PASSWORD_HASH 값으로 사용합니다.

sudo gitlab-ctl pg-password-md5 gitlab

/etc/gitlab/gitlab.rb를 편집하고 아래 내용을 추가하여 플레이스홀더 값을 적절하게 업데이트합니다.

POSTGRESQL_PASSWORD_HASH - 이전 단계의 출력 값

• APPLICATION_SERVER_IP_BLOCKS - 데이터베이스에 연결할 GitLab Rails 및 Sidekiq 서버의 IP 서브넷 또는 IP 주소의 공백으로 구분된 목록. 예: %w(123.123.123.123/32 123.123.123.234/32)

# Disable all components except PostgreSQL related ones
roles(['postgres_role'])

# Set the network addresses that the exporters used for monitoring will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'
postgres_exporter['listen_address'] = '0.0.0.0:9187'
postgres_exporter['dbname'] = 'gitlabhq_production'
postgres_exporter['password'] = 'POSTGRESQL_PASSWORD_HASH'

# Set the PostgreSQL address and port
postgresql['listen_address'] = '0.0.0.0'
postgresql['port'] = 5432

# Replace POSTGRESQL_PASSWORD_HASH with a generated md5 value
postgresql['sql_user_password'] = 'POSTGRESQL_PASSWORD_HASH'

# Replace APPLICATION_SERVER_IP_BLOCK with the CIDR address of the application node
postgresql['trust_auth_cidr_addresses'] = %w(127.0.0.1/32 APPLICATION_SERVER_IP_BLOCK)

# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false

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

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

나중에 GitLab 애플리케이션 서버를 구성할 때 필요하므로 PostgreSQL 노드의 IP 주소 또는 호스트명, 포트 및 일반 텍스트 비밀번호를 기록해 두세요.

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

컴포넌트 설정으로 돌아가기

Redis 구성#

이 섹션에서는 GitLab에서 사용할 외부 Redis 인스턴스를 구성하는 과정을 안내합니다.

Redis는 주로 단일 스레드이며 CPU 코어 수 증가로 인해 크게 이점을 얻지 못합니다. 자세한 내용은 확장 문서를 참조하세요.

자체 Redis 인스턴스 제공#

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

• 이를 위해 평판 있는 공급자 또는 솔루션을 사용해야 합니다. Google Memorystore 및 AWS ElastiCache가 잘 작동하는 것으로 알려져 있습니다.

• Redis Cluster 모드는 특별히 지원되지 않지만, HA를 갖춘 Redis Standalone은 지원됩니다.

• 설정에 따라 Redis 제거 정책을 설정해야 합니다.

자세한 내용은 인프라 및 서비스를 참조하세요.

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

Linux 패키지를 사용하여 독립형 Redis 서버를 구성할 수 있습니다. 아래 단계는 Linux 패키지로 Redis 서버를 구성하는 데 필요한 최소한의 단계입니다:

Redis 서버에 SSH로 접속합니다.

선택한 Linux 패키지를 다운로드하고 설치합니다. GitLab 패키지 리포지터리만 추가하고 선택한 운영 체제에 GitLab을 설치해야 합니다.

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

## Enable Redis
roles(["redis_master_role"])

redis['bind'] = '0.0.0.0'
redis['port'] = 6379
redis['password'] = 'SECRET_PASSWORD_HERE'

# Set the network addresses that the exporters used for monitoring 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

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

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

나중에 GitLab 애플리케이션 서버를 구성할 때 필요하므로 Redis 노드의 IP 주소 또는 호스트명, 포트 및 Redis 비밀번호를 기록해 두세요.

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

컴포넌트 설정으로 돌아가기

Gitaly 구성#

Gitaly 서버 노드 요구 사항은 특히 프로젝트 수와 해당 프로젝트의 크기와 같은 데이터 크기에 따라 다릅니다.

Gitaly 사양은 정상 상태의 사용 패턴과 리포지터리 크기의 높은 백분위수를 기반으로 합니다. 그러나 대형 모노레포(수 기가바이트 이상)나 추가 워크로드가 있는 경우 환경 성능에 상당한 영향을 미칠 수 있으며 추가 조정이 필요할 수 있습니다. 이것이 귀하에게 해당된다고 생각되면 필요에 따라 추가 지침을 위해 당사에 문의하세요.

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

다음 사항을 반드시 확인하세요:

• GitLab Rails 애플리케이션은 리포지터리를 리포지터리 스토리지 경로로 분할합니다.

• Gitaly 서버는 하나 이상의 스토리지 경로를 호스팅할 수 있습니다.

• GitLab 서버는 하나 이상의 Gitaly 서버 노드를 사용할 수 있습니다.

• Gitaly 주소는 모든 Gitaly 클라이언트에 대해 올바르게 확인 가능하도록 지정해야 합니다.

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

Gitaly 문서 전반에 걸쳐 언급되는 토큰은 관리자가 선택한 임의의 비밀번호입니다. 이 토큰은 GitLab API 또는 기타 유사한 웹 API 토큰용으로 생성된 토큰과는 관련이 없습니다.

다음 절차는 시크릿 토큰 gitalysecret으로 gitaly1.internal이라는 단일 Gitaly 서버를 구성하는 방법을 설명합니다. GitLab 설치에 두 개의 리포지터리 스토리지 default와 storage1이 있다고 가정합니다.

Gitaly에 사용할 서버 노드에서 Gitaly 서버를 구성하려면:

선택한 Linux 패키지를 다운로드하고 설치합니다. GitLab 패키지 리포지터리만 추가하고 선택한 운영 체제에 GitLab을 설치해야 하지만 EXTERNAL_URL 값은 제공하지 마세요.

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

GitLab에 기본 리포지터리 스토리지가 필요하므로 gitaly['configuration'][:storage]에서 default 항목을 제거할 수 없습니다.

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

# Set the network addresses that the exporters used for monitoring will listen on
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',
   prometheus_listen_addr: '0.0.0.0:9236',
   # Gitaly Auth Token
   # Should be the same as praefect_internal_token
   auth: {
      # ...
      #
      # Gitaly's authentication token is used to authenticate gRPC requests to Gitaly. This must match
      # the respective value in GitLab Rails application setup.
      token: 'gitalysecret',
   },
   # 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,
   },
   storage: [
      {
         name: 'default',
         path: '/var/opt/gitlab/git-data/repositories',
      },
      {
         name: 'storage1',
         path: '/mnt/gitlab/git-data',
      },
   ],
}

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

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

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을 실행합니다.

Gitaly TLS 지원#

Gitaly는 TLS 암호화를 지원합니다. 보안 연결을 수신하는 Gitaly 인스턴스와 통신하려면 GitLab 구성의 해당 스토리지 항목의 gitaly_address에서 tls:// URL 스키마를 사용해야 합니다.

이것은 자동으로 제공되지 않으므로 자체 인증서를 가져와야 합니다. 인증서 또는 해당 인증 기관은 모든 Gitaly 노드(인증서를 사용하는 Gitaly 노드 포함)와 GitLab 커스텀 인증서 구성에 설명된 절차에 따라 통신하는 모든 클라이언트 노드에 설치해야 합니다.

자체 서명 인증서는 Gitaly 서버에 액세스하는 데 사용하는 주소를 지정해야 합니다. 호스트명으로 Gitaly 서버를 주소 지정하는 경우 Subject Alternative Name으로 추가합니다. IP 주소로 Gitaly 서버를 주소 지정하는 경우 인증서에 Subject Alternative Name으로 추가해야 합니다.

필요한 경우 Gitaly 서버에 암호화되지 않은 수신 주소(listen_addr)와 암호화된 수신 주소(tls_listen_addr)를 동시에 구성할 수 있습니다. 이를 통해 암호화되지 않은 트래픽에서 암호화된 트래픽으로 점진적으로 전환할 수 있습니다.

TLS로 Gitaly를 구성하려면:

/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

Gitaly가 자체 호출 시 인증서를 신뢰할 수 있도록 인증서를 /etc/gitlab/trusted-certs에 복사합니다:

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

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

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

암호화된 연결만 허용하려면 gitaly['listen_addr']를 삭제합니다.

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

컴포넌트 설정으로 돌아가기

Sidekiq 구성#

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

환경의 Sidekiq 작업 처리가 긴 큐로 인해 느린 경우 적절히 확장할 수 있습니다. 자세한 내용은 확장 문서를 참조하세요.

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

Sidekiq에 사용할 서버 노드에서 Sidekiq 서버를 구성하려면:

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

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

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

선택한 Linux 패키지를 다운로드하고 설치합니다. GitLab 패키지 리포지터리만 추가하고 선택한 운영 체제에 GitLab을 설치해야 합니다.

다음 구성을 사용하여 /etc/gitlab/gitlab.rb를 만들거나 편집합니다:

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

# External URL
external_url 'https://gitlab.example.com'

## Redis connection details
gitlab_rails['redis_port'] = '6379'
gitlab_rails['redis_host'] = '10.1.0.6' # IP/hostname of Redis server
gitlab_rails['redis_password'] = 'Redis Password'

# Gitaly and GitLab use two shared secrets for authentication, one to authenticate gRPC requests
# to Gitaly, and a second stored in /etc/gitlab/gitlab-secrets.json for authentication callbacks from GitLab-Shell to the GitLab internal API.
# The following must be the same as their respective values
# of the Gitaly setup
gitlab_rails['gitaly_token'] = 'gitalysecret'

gitlab_rails['repositories_storages'] = {
  'default' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
  'storage1' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
  'storage2' => { 'gitaly_address' => 'tcp://gitaly2.internal:8075' },
}

## PostgreSQL connection details
gitlab_rails['db_adapter'] = 'postgresql'
gitlab_rails['db_encoding'] = 'unicode'
gitlab_rails['db_host'] = '10.1.0.5' # IP/hostname of database server
gitlab_rails['db_password'] = 'DB password'

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

## Set the network addresses that the exporters will listen on
node_exporter['listen_address'] = '0.0.0.0:9100'

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

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

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

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

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

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

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

sudo gitlab-ctl status

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

run: logrotate: (pid 192292) 2990s; run: log: (pid 26374) 93048s
run: node-exporter: (pid 26864) 92997s; run: log: (pid 26446) 93036s
run: sidekiq: (pid 26870) 92996s; run: log: (pid 26391) 93042s

컴포넌트 설정으로 돌아가기

GitLab Rails 구성#

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

아키텍처에서 각 GitLab Rails 노드는 Puma 웹 서버를 사용하여 실행하며, 워커 수는 사용 가능한 CPU의 90%로 설정하고 네 개의 스레드를 사용합니다. 다른 컴포넌트와 함께 Rails를 실행하는 노드의 경우 워커 값을 적절히 줄여야 합니다. 워커 값 50%가 좋은 균형을 이룬다고 판단했지만 이는 워크로드에 따라 다릅니다.

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

선택한 Linux 패키지를 다운로드하고 설치합니다. GitLab 패키지 리포지터리만 추가하고 선택한 운영 체제에 GitLab을 설치해야 합니다.

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

external_url 'https://gitlab.example.com'

# Gitaly and GitLab use two shared secrets for authentication, one to authenticate gRPC requests
# to Gitaly, and a second stored in /etc/gitlab/gitlab-secrets.json for authentication callbacks from GitLab-Shell to the GitLab internal API.
# The following must be the same as their respective values
# of the Gitaly setup
gitlab_rails['gitaly_token'] = 'gitalysecret'

gitlab_rails['repositories_storages'] = {
  'default' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
  'storage1' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
  'storage2' => { 'gitaly_address' => 'tcp://gitaly2.internal:8075' },
}

## Disable components that will not be on the GitLab application server
roles(['application_role'])
gitaly['enable'] = false
sidekiq['enable'] = false

## PostgreSQL connection details
gitlab_rails['db_adapter'] = 'postgresql'
gitlab_rails['db_encoding'] = 'unicode'
gitlab_rails['db_host'] = '10.1.0.5' # IP/hostname of database server
gitlab_rails['db_password'] = 'DB password'

## Redis connection details
gitlab_rails['redis_port'] = '6379'
gitlab_rails['redis_host'] = '10.1.0.6' # IP/hostname of Redis server
gitlab_rails['redis_password'] = 'Redis Password'

# 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'
puma['listen'] = '0.0.0.0'

# Add the monitoring node's IP address to the monitoring whitelist and allow it to
# scrape the NGINX metrics. Replace placeholder `monitoring.gitlab.example.com` with
# the address and/or subnets gathered from the monitoring node
gitlab_rails['monitoring_whitelist'] = ['/32', '127.0.0.0/8']
nginx['status']['options']['allow'] = ['/32', '127.0.0.0/8']

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

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

TLS 지원이 있는 Gitaly를 사용하는 경우 gitlab_rails['repositories_storages'] 항목이 tcp 대신 tls로 구성되어 있는지 확인합니다:

gitlab_rails['repositories_storages'] = {
  'default' => { 'gitaly_address' => 'tls://gitaly1.internal:9999' },
  'storage1' => { 'gitaly_address' => 'tls://gitaly1.internal:9999' },
  'storage2' => { 'gitaly_address' => 'tls://gitaly2.internal:9999' },
}

인증서를 /etc/gitlab/trusted-certs에 복사합니다:

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

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

처음 구성한 Rails 노드에서 SSH 호스트 키(이름 형식이 /etc/ssh/ssh_host_*_key*인 모든 키)를 복사하고 이 서버에서 같은 이름의 파일을 추가하거나 교체합니다. 이렇게 하면 사용자가 로드 밸런싱된 Rails 노드에 접속할 때 호스트 불일치 오류가 발생하지 않습니다. 이것이 처음 구성하는 Linux 패키지 노드인 경우 이 단계를 건너뛸 수 있습니다.

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

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

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

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

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

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

로그를 테일링하여 요청을 확인합니다:

sudo gitlab-ctl tail gitaly

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

GitLab Rails 사후 구성#

설치 및 업데이트 중 데이터베이스 마이그레이션을 실행하기 위해 하나의 애플리케이션 노드를 지정합니다. GitLab 데이터베이스를 초기화하고 모든 마이그레이션이 실행되었는지 확인합니다:

sudo gitlab-rake gitlab:db:configure

이 작업은 Rails 노드가 PgBouncer를 우회하여 기본 데이터베이스에 직접 연결하도록 구성해야 합니다. 마이그레이션이 완료된 후 노드가 PgBouncer를 통해 다시 통과하도록 구성해야 합니다.

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

컴포넌트 설정으로 돌아가기

Prometheus 구성#

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

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

선택한 Linux 패키지를 다운로드하고 설치합니다. GitLab 패키지 리포지터리만 추가하고 선택한 운영 체제에 GitLab을 설치해야 합니다.

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

roles(['monitoring_role'])
nginx['enable'] = false

external_url 'http://gitlab.example.com'

# Prometheus
prometheus['listen_address'] = '0.0.0.0:9090'
prometheus['monitor_kubernetes'] = false

Prometheus는 또한 내보내기를 구성한 다양한 노드에서 모든 데이터를 가져오기 위한 일부 스크레이프 구성이 필요합니다. 노드의 IP가 다음과 같다고 가정합니다:

1.1.1.1: postgres
1.1.1.2: redis
1.1.1.3: gitaly1
1.1.1.4: rails1
1.1.1.5: rails2
1.1.1.6: sidekiq

/etc/gitlab/gitlab.rb에 다음을 추가합니다:

prometheus['scrape_configs'] = [
  {
     'job_name': 'postgres',
     'static_configs' => [
     'targets' => ['1.1.1.1:9187'],
     ],
  },
  {
     'job_name': 'redis',
     'static_configs' => [
     'targets' => ['1.1.1.2:9121'],
     ],
  },
  {
     'job_name': 'gitaly',
     'static_configs' => [
     'targets' => ['1.1.1.3:9236'],
     ],
  },
  {
     'job_name': 'gitlab-nginx',
     'static_configs' => [
     'targets' => ['1.1.1.4:8060', '1.1.1.5:8060'],
     ],
  },
  {
     'job_name': 'gitlab-workhorse',
     'static_configs' => [
     'targets' => ['1.1.1.4:9229', '1.1.1.5:9229'],
     ],
  },
  {
     'job_name': 'gitlab-rails',
     'metrics_path': '/-/metrics',
     'static_configs' => [
     'targets' => ['1.1.1.4:8080', '1.1.1.5:8080'],
     ],
  },
  {
     'job_name': 'gitlab-sidekiq',
     'static_configs' => [
     'targets' => ['1.1.1.6:8082'],
     ],
  },
  {
     'job_name': 'static-node',
     'static_configs' => [
     'targets' => ['1.1.1.1:9100', '1.1.1.2:9100', '1.1.1.3:9100', '1.1.1.4:9100', '1.1.1.5:9100', '1.1.1.6:9100'],
     ],
  },
]

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

컴포넌트 설정으로 돌아가기

오브젝트 스토리지 구성#

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 클러스터를 설정하는 방법에 대한 권장 모범 사례는 최적의 클러스터 구성 선택 방법을 참조하세요.

컴포넌트 설정으로 돌아가기

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

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

• GitLab Rails

• Sidekiq

• NGINX

• Toolbox

• Migrations

• Prometheus

하이브리드 설치는 클라우드 네이티브 및 전통적인 컴퓨팅 배포 모두의 이점을 활용합니다. 이를 통해 상태 비저장 컴포넌트는 클라우드 네이티브 워크로드 관리 이점을 누릴 수 있고, 상태 저장 컴포넌트는 Linux 패키지 설치와 함께 컴퓨팅 VM에 배포되어 영속성 향상의 이점을 누릴 수 있습니다.

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

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

• 2,000 레퍼런스 아키텍처는 고가용성 설정이 아닙니다. HA를 달성하려면 수정된 3K 또는 60 RPS 레퍼런스 아키텍처를 따를 수 있습니다.

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

클러스터 토폴로지#

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

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

• 이 설정에서 정기적으로 테스트하고 Google Kubernetes Engine(GKE) 및 Amazon Elastic Kubernetes Service(EKS)를 권장합니다. 다른 쿠버네티스 서비스도 작동할 수 있지만 결과는 다를 수 있습니다.

• 머신 유형 예시는 예시 목적으로 제공됩니다. 이러한 유형은 유효성 검사 및 테스트에서 사용되지만 규범적인 기본값으로 의도된 것은 아닙니다. 나열된 요구 사항을 충족하는 다른 머신 유형으로 전환하는 것이 지원됩니다. 자세한 내용은 지원되는 머신 유형을 참조하세요.

• Webservice 및 Sidekiq 타깃 노드 풀 합계는 GitLab 컴포넌트에만 해당합니다. 선택한 쿠버네티스 공급자의 시스템 프로세스에 추가 리소스가 필요합니다. 제공된 예시는 이를 고려합니다.

• 지원 타깃 노드 풀 합계는 일반적으로 GitLab 배포를 지원하고 요구 사항에 따라 추가 배포를 수행할 수 있는 여러 리소스를 수용하기 위해 제공됩니다. 다른 노드 풀과 마찬가지로 선택한 쿠버네티스 공급자의 시스템 프로세스에도 리소스가 필요합니다. 제공된 예시는 이를 고려합니다.

• 프로덕션 배포에서는 특정 노드에 Pod를 할당할 필요가 없습니다. 그러나 복원력 있는 클라우드 아키텍처 관행에 맞게 여러 가용 영역에 걸쳐 각 풀에 여러 노드를 두는 것이 권장됩니다.

• 효율성을 위해 Cluster Autoscaler와 같은 자동 스케일링을 활성화하는 것이 권장되지만, 지속적인 성능을 보장하기 위해 Webservice 및 Sidekiq Pod의 최솟값을 75%로 설정하는 것이 일반적으로 권장됩니다.

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

각주:

• 머신 유형 예시는 예시 목적으로 제공됩니다. 이러한 유형은 유효성 검사 및 테스트에서 사용되지만 규범적인 기본값으로 의도된 것은 아닙니다. 사용 가능한 경우 ARM 변형을 포함하여 나열된 요구 사항을 충족하는 다른 머신 유형으로 전환하는 것이 지원됩니다. 자세한 내용은 지원되는 머신 유형을 참조하세요.

• 선택적으로 평판 있는 서드파티 외부 PaaS PostgreSQL 솔루션에서 실행할 수 있습니다. 자세한 내용은 자체 PostgreSQL 인스턴스 제공 및 인프라 및 서비스를 참조하세요.

• 선택적으로 평판 있는 서드파티 외부 PaaS Redis 솔루션에서 실행할 수 있습니다. 자세한 내용은 자체 Redis 인스턴스 제공 및 인프라 및 서비스를 참조하세요.

• 평판 있는 클라우드 공급자 또는 Self-Managed 솔루션에서 실행해야 합니다. 자세한 내용은 오브젝트 스토리지 구성을 참조하세요.

• Gitaly 사양은 정상 상태의 일반 크기 리포지터리 사용을 기반으로 합니다. 그러나 대형 모노레포(수 기가바이트 이상)가 있는 경우 Git 및 Gitaly 성능에 상당한 영향을 미칠 수 있으며 사양 증가가 필요할 수 있습니다. 자세한 내용은 대형 모노레포를 참조하세요.

  인스턴스 구성과 관련된 모든 PaaS 솔루션의 경우, 복원력 있는 클라우드 아키텍처 관행에 맞게 세 개의 서로 다른 가용 영역에 최소 세 개의 노드를 구현하는 것이 권장됩니다.

@startuml 2k 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 }

collections "Supporting Services" as support }

card "Gitaly" as gitaly #FF8C00 card "PostgreSQL" as postgres #4EA7FF card "Redis" as redis #FF6347 cloud "Object Storage" as object_storage #white

elb -[#6a9be7]-> gitlab

gitlab -[#32CD32]--> gitaly gitlab -[#32CD32]--> postgres gitlab -[#32CD32]-> object_storage gitlab -[#32CD32]--> redis

sidekiq -[#ff8dd1]--> gitaly sidekiq -[#ff8dd1]-> object_storage sidekiq -[#ff8dd1]--> postgres sidekiq -[#ff8dd1]--> redis

@enduml

쿠버네티스 컴포넌트 타깃#

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

Webservice#

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

• 4 Puma Workers

• 4 vCPU

• 5 GB 메모리 (request)

• 7 GB 메모리 (limit)

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

Webservice 리소스 사용에 대한 자세한 내용은 Webservice 리소스에 대한 Charts 문서를 참조하세요.

Gateway API / Ingress#

또한 DaemonSet으로 Webservice 노드에 Gateway API 또는 Ingress 컨트롤러 Pod를 배포하는 것이 권장됩니다. 이를 통해 컨트롤러가 서비스하는 Webservice Pod와 동적으로 확장할 수 있으며, 더 큰 머신 유형이 일반적으로 갖는 더 높은 네트워크 대역폭의 이점을 활용합니다.

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

Sidekiq#

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

• 1 Sidekiq worker

• 900m vCPU

• 2 GB 메모리 (request)

• 4 GB 메모리 (limit)

앞서 문서화된 표준 배포와 유사하게, 초기 타깃으로 4개의 Sidekiq worker가 사용됩니다. 특정 워크플로에 따라 추가 worker가 필요할 수 있습니다.

Sidekiq 리소스 사용에 대한 자세한 내용은 Sidekiq 리소스에 대한 Charts 문서를 참조하세요.

지원#

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

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

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

예시 구성 파일#

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

컴포넌트 설정으로 돌아가기

다음 단계#

이 가이드를 따른 후 핵심 기능이 적절하게 구성된 새로운 GitLab 환경이 구축됩니다.

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

환경 및 요구 사항에 따라 원하는 추가 기능을 설정하기 위해 추가 하드웨어 요구 사항이나 조정이 필요할 수 있습니다. 자세한 내용은 개별 페이지를 참조하세요.