• 요구 사항
• 테스트 방법론
• 구성 요소 설정
• 외부 로드 밸런서 구성
  • 준비 상태 확인
  • 포트
    • 대체 SSH 포트
  • SSL
    • 애플리케이션 노드가 SSL을 종료
    • 로드 밸런서가 백엔드 SSL 없이 SSL을 종료
    • 로드 밸런서가 백엔드 SSL로 SSL을 종료
• PostgreSQL 구성
  • 본인의 PostgreSQL 인스턴스 제공
  • Linux 패키지 사용한 독립형 PostgreSQL
• Redis 구성
  • 자체 Redis 인스턴스 제공
  • Linux 패키지를 사용한 스탠드얼론 Redis
• Gitaly 구성
  • Gitaly TLS 지원
• Sidekiq 구성
• GitLab Rails 구성
  • GitLab Rails 포스트 구성
• Prometheus 구성
• 객체 저장소 구성
  • 증분 로깅 활성화
• 고급 검색 구성
• Helm 차트를 사용한 클라우드 네이티브 하이브리드 참조 아키텍처 (대안)
  • 클러스터 위상
  • Kubernetes 구성 요소 대상
    • Webservice
      • NGINX
    • Sidekiq
  • Supporting
  • 설정 파일 예제
• 다음 단계

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

이 페이지는 실제 데이터를 기반으로 최대 40 초당 요청(RPS) 및 최대 2,000 사용자, 수동 및 자동화된 사용자를 대상으로 하는 GitLab 참조 아키텍처에 대해 설명합니다.

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

• 대상 부하: API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS
• 고가용성: 아니요. 고가용성 환경을 위해서는 수정된 3K 또는 60 RPS 참조 아키텍처를 따를 수 있습니다.
• 비용 계산기 템플릿: 비용 계산기 템플릿 섹션을 참조하십시오
• 클라우드 네이티브 하이브리드: 예
• 어떤 참조 아키텍처를 사용해야 하는지 확신이 들지 않습니까? 더 많은 정보를 위해이 가이드로 이동.

각주:

1. 신뢰할 수 있는 타사 외부 PaaS PostgreSQL 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 자체 PostgreSQL 인스턴스 제공 및 권장 클라우드 제공 업체 및 서비스를 참조하십시오.
2. 신뢰할 수 있는 타사 외부 PaaS Redis 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 자체 Redis 인스턴스 제공 및 권장 클라우드 제공 업체 및 서비스를 참조하십시오.
3. 권장되는 실행 방법은 신뢰할 수 있는 타사 로드 밸런서 또는 서비스 (LB PaaS)와 함께 실행하는 것입니다. 사이징은 선택한 로드 밸런서 및 네트워크 대역폭과 같은 추가 요소에 따라 다릅니다. 자세한 내용은 로드 밸런서를 참조하십시오.
4. 신뢰할 수 있는 클라우드 제공 업체 또는 Self-Managed 솔루션에서 실행하는 것이 좋습니다. 자세한 내용은 객체 저장소 구성를 참조하십시오.
5. Gitaly 사양은 일반 크기의 리포지토리 사용을 기준으로 합니다. 그러나 대형 모노레포지토리(여러 기가바이트보다 큰 경우)를 보유하고 있는 경우, Git 및 Gitaly 성능에 상당한 영향을 미칠 수 있으며, 사양을 늘리는 것이 필요할 수 있습니다. 자세한 내용은 대형 모노레포를 참조하십시오.
6. 상태 데이터를 저장하지 않는 Auto Scaling 그룹(ASG)에 배치할 수 있습니다. 그러나 Cloud Native Hybrid 설정이 특히 권장되며 특정 구성 요소는 마이그레이션 및 Mailroom과 같은 것들은 Kubernetes에서 더 잘 처리되며 한 노드에서만 실행할 수 있습니다. (hidden) 자세한 내용은(F2s v2) 참조하십시오.

참고: PaaS 솔루션의 모든 구성을 설정하는 경우, 원하는 경우 내구성을 위해 여러 가용 영역 위에 배포하는 것이 좋습니다.

요구 사항

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

테스트 방법론

2k 아키텍처는 대부분의 워크플로를 다루도록 디자인되었으며 정기적으로 스모크 및 성능 테스트가 Test Platform 팀에 의해 다음 엔드포인트 처리량 목표에 대해 수행됩니다:

• API: 40 RPS
• Web: 4 RPS
• Git (Pull): 4 RPS
• Git (Push): 1 RPS

위의 목표는 사용자 수에 해당하는 총 환경 부하의 실제 고객 데이터를 기반으로 선정되었습니다. 이에는 CI 및 기타 워크로드가 포함됩니다.

위 엔드포인트 목표에 대해 정기적으로 더 높은 처리량이 있다는 지표가 있는 경우, 대형 단일 저장소 또는 주목할만한 추가 워크로드가 있는지 여부를 확인할 수 있으며, 이러한 경우 성능 환경에 주목할 만한 영향을 줄 수 있으며 추가 조정이 필요할 수 있습니다. 이 경우 연결된 문서를 참조하고 고객 성공 관리자나 지원팀에 문의하여 추가 지침을 얻는 것이 강력히 권장됩니다.

테스트는 정기적으로 저희의 GitLab 성능 도구 (GPT) 및 해당 데이터셋을 활용하여 수행됩니다. 이 테스트의 결과는 GPT 위키에서 공개적으로 확인할 수 있습니다. 테스트 전략에 대한 자세한 정보는 문서의 이 부분을 참조하세요.

테스트에 사용된 로드 밸런서는 Linux 패키지 환경의 경우 HAProxy를 사용하였거나 Cloud 네이티브 하이브리드의 경우 동등한 Cloud 공급자 서비스의 NGINX Ingress를 사용했습니다. 이러한 선택은 특정 요구 사항 또는 권장 사항을 나타내지는 않으며, 대부분의 신뢰할 수 있는 로드 밸런서가 작동할 것으로 예상됩니다.

구성 요소 설정

GitLab 및 해당 구성 요소를 40 RPS 또는 2,000 사용자까지 수용할 수 있도록 설정하는 방법:

1. 외부 로드 밸런싱 노드 구성
   • GitLab 애플리케이션 서비스 노드의 로드 밸런싱을 처리하도록 구성합니다.
2. PostgreSQL 구성
   • GitLab의 데이터베이스인 PostgreSQL을 구성합니다.
3. Redis 구성
   • 세션 데이터, 임시 캐시 정보 및 백그라운드 작업 큐를 저장하는 Redis를 구성합니다.
4. Gitaly 구성
   • Git 리포지토리에 대한 액세스를 제공하는 Gitaly를 구성합니다.
5. Sidekiq 구성
   • 백그라운드 작업 처리를 위해 Sidekiq를 구성합니다.
6. GitLab 메인 Rails 애플리케이션 구성
   • Puma, Workhorse, GitLab Shell을 실행하고 UI, API 및 Git over HTTP/SSH를 제공하는 모든 프론트엔드 요청을 처리할 수 있도록 GitLab Rails 애플리케이션을 구성합니다.
7. Prometheus 구성
   • GitLab 환경을 모니터링하기 위해 Prometheus를 구성합니다.
8. 객체 저장소 구성
   • 공유 데이터 객체에 사용되는 객체 저장소를 구성합니다.
9. 고급 검색 구성 (옵션)
   • 전체 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. 랫 파일의 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을 종료

로드 밸런서를 구성하여 포트 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에 대한 구성 추가가 필요하지 않습니다. 그러나 GitLab에 SSL 인증서를 구성하는 데 구성을 추가해야 합니다. SSL 인증서 관리 및 NGINX 구성에 대한 자세한 내용은 HTTPS 문서를 참조하십시오.

PostgreSQL 구성

이 섹션에서는 GitLab에서 사용할 외부 PostgreSQL 데이터베이스를 구성하는 방법에 대해 안내합니다.

본인의 PostgreSQL 인스턴스 제공

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

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

자세한 정보는 권장되는 클라우드 프로바이더 및 서비스를 참조하십시오.

타사 외부 서비스를 사용하는 경우:

1. HA Linux 패키지 PostgreSQL 설정에는 PostgreSQL, PgBouncer 및 Consul이 모두 필요하지 않습니다. 이러한 구성 요소는 필요하지 않습니다.
2. 데이터베이스 요구 사항 문서에 따라 PostgreSQL을 설정합니다.
3. 사용자가 선택한 비밀번호로 gitlab 사용자를 설정합니다. gitlab 사용자는 gitlabhq_production 데이터베이스를 만들 권한이 있어야 합니다.
4. GitLab 애플리케이션 서버에 적절한 세부 정보를 구성합니다. 이 단계에 대해서는 GitLab Rails 애플리케이션 구성에서 다룹니다.

Linux 패키지 사용한 독립형 PostgreSQL

1. PostgreSQL 서버에 SSH로 접속합니다.
2. 사용하려는 Linux 패키지를 다운로드하고 설치합니다. 페이지에서 오직 설치 단계 1과 2만 따르도록 주의하십시오.

3. PostgreSQL용 비밀번호 해시를 생성합니다. 이는 기본 gitlab 사용자를 사용할 것으로 가정합니다(권장됨). 이 명령은 비밀번호 및 확인을 요청합니다. 이 명령에서 출력된 값으로 다음 단계에서 POSTGRESQL_PASSWORD_HASH의 값으로 사용하십시오.

   sudo gitlab-ctl pg-password-md5 gitlab
   

4. /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)

   # PostgreSQL 관련 구성 요소 이외의 모든 컴포넌트를 비활성화합니다.
   roles(['postgres_role'])
   
   # 모니터링에 사용되는 수출자가 청취할 네트워크 주소를 설정합니다
   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'
   
   # PostgreSQL 주소와 포트를 설정합니다
   postgresql['listen_address'] = '0.0.0.0'
   postgresql['port'] = 5432
   
   # POSTGRESQL_PASSWORD_HASH를 생성된 md5 값으로 교체합니다
   postgresql['sql_user_password'] = 'POSTGRESQL_PASSWORD_HASH'
   
   # APPLICATION_SERVER_IP_BLOCK을 애플리케이션 노드의 CIDR 주소로 교체합니다
   postgresql['trust_auth_cidr_addresses'] = %w(127.0.0.1/32 APPLICATION_SERVER_IP_BLOCK)
   
   # 업그레이드 시 자동으로 데이터베이스 마이그레이션을 실행하지 않도록 설정합니다
   gitlab_rails['auto_migrate'] = false
   

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

6. 변경 사항이 적용되도록 GitLab 구성을 다시 설정합니다.
7. 나중에 GitLab 애플리케이션 서버를 구성할 때 PostgreSQL 노드의 IP 주소, 호스트 이름, 포트 및 평문 비밀번호를 기록해 둡니다.

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

Redis 구성

이 섹션에서는 GitLab에서 사용할 외부 Redis 인스턴스를 구성하는 방법에 대해 안내받게 됩니다.

참고: Redis는 주로 단일 스레드이며 CPU 코어 증가로 인한 혜택이 크지 않습니다. 자세한 정보는 확장 문서를 참조하십시오.

자체 Redis 인스턴스 제공

다음 지침을 사용하여 Redis 인스턴스에 대한 타사 외부 서비스를 선택적으로 사용할 수 있습니다:

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

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

Linux 패키지를 사용한 스탠드얼론 Redis

Linux 패키지를 사용하여 스탠드얼론 Redis 서버를 구성할 수 있습니다. 아래 단계는 Linux 패키지를 사용하여 Redis 서버를 구성하는 데 필요한 최소한의 단계입니다.

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

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

    ## Redis 활성화
    roles(["redis_master_role"])
   
    redis['bind'] = '0.0.0.0'
    redis['port'] = 6379
    redis['password'] = '여기에 비밀번호 입력'
   
    # 모니터링에 사용되는 내부 주소 설정
    node_exporter['listen_address'] = '0.0.0.0:9100'
    redis_exporter['listen_address'] = '0.0.0.0:9121'
    redis_exporter['flags'] = {
          'redis.addr' => 'redis://0.0.0.0:6379',
          'redis.password' => '여기에 비밀번호 입력',
    }
   
    # 업그레이드 시 자동으로 데이터베이스 마이그레이션 작업을 방지
    gitlab_rails['auto_migrate'] = false
   

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

5. 변경 내용이 적용되려면 GitLab의 재구성을 해야 합니다.

6. Redis 노드의 IP 주소 또는 호스트 이름, 포트 및 Redis 비밀번호를 메모해 두세요. 이 정보는 나중에 GitLab 애플리케이션 서버를 구성할 때 필요합니다.

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

Gitaly 구성

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

경고: Gitaly 사양은 사용 패턴과 리포지토리 크기의 높은 백분위수에 기반합니다. 그러나 큰 모노 리포 (여러 기가바이트보다 큰)나 추가 작업 부하가 있는 경우 이것들은 환경의 성능에 *관련된 조정이 필요할 수 있습니다. 이 경우 연결된 문서와 고객 성공 관리자 또는 지원 팀에 문의하는 것이 강력히 권장됩니다.

Gitaly의 중요한 입·출력 요구 사항으로, 모든 Gitaly 노드가 SSD(Solid-State Drive)를 사용하는 것을 강력히 권장합니다. 이 SSD는 읽기 작업에 대한 초당 최소 8,000회의 입력/출력 작업(IOPS) 및 쓰기 작업에 대한 2,000회의 IOPS를 가져야 합니다. 클라우드 제공업체에서 환경을 실행 중이라면 올바른 IOPS를 구성하는 방법에 대해 문서를 참조하십시오.

다음 사항을 반드시 주의하십시오:

• GitLab Rails 애플리케이션은 리포지토리 저장 경로에 리포지토리를 샤딩합니다.
• Gitaly 서버는 하나 이상의 저장 경로를 호스트할 수 있습니다.
• GitLab 서버는 하나 이상의 Gitaly 서버 노드를 사용할 수 있습니다.
• Gitaly 주소는 모든 Gitaly 클라이언트에서 올바르게 해석될 수 있도록 명시되어야 합니다.
• Gitaly 서버는 기본적으로 네트워크 트래픽이 암호화되지 않으므로 공개 인터넷에 노출되어서는 안 됩니다. 방화벽 사용이 강력히 권장됩니다. 또 다른 옵션은 TLS를 사용하는 것입니다.

참고: Gitaly 문서에서 언급된 토큰은 관리자가 선택한 임의의 비밀번호입니다. 이 토큰은 GitLab API나 같은 웹 API 토큰과는 무관합니다.

다음 절차는 gitaly1.internal이라는 단일 Gitaly 서버를 gitalysecret라는 시크릿 토큰과 함께 구성하는 방법을 설명합니다. GitLab 설치에서 default 및 storage1이라는 두 개의 리포지토리 저장소를 사용한다고 가정합니다.

Gitaly 서버를 구성하려면 Gitaly를 사용할 서버 노드에서 다음을 수행합니다:

1. Linux 패키지를 다운로드하고 설치합니다. 페이지의 설치 단계 1과 2만 따르도록 합니다. 그리고 EXTERNAL_URL 값을 제공하지 않도록 합니다.

2. Gitaly 서버 노드의 /etc/gitlab/gitlab.rb 파일을 편집하여 저장 경로를 구성하고 네트워크 수신기를 활성화하고 토큰을 구성합니다:

   참고: [gitaly[‘configuration’][:storage]]에서 default` 항목을 제거할 수 없습니다. 왜냐하면 GitLab에서 필요하기 때문입니다.

   # Gitaly 서버에서 불필요한 서비스들이 실행되지 않도록 설정
   postgresql['enable'] = false
   redis['enable'] = false
   nginx['enable'] = false
   puma['enable'] = false
   sidekiq['enable'] = false
   gitlab_workhorse['enable'] = false
   prometheus['enable'] = false
   alertmanager['enable'] = false
   gitlab_exporter['enable'] = false
   gitlab_kas['enable'] = false
   
   # 업그레이드 시 자동으로 데이터베이스 마이그레이션 작업을 방지
   gitlab_rails['auto_migrate'] = false
   
   # gitlab-shell API 콜백 URL 구성. 이것이 없을 경우 `git push`가 실패합니다. 이것은 'front door' GitLab URL이거나 내부 로드 밸런서일 수 있습니다.
   gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
   
   # Gitaly
   gitaly['enable'] = true
   
   # 모니터링에 사용되는 내부 주소 설정
   node_exporter['listen_address'] = '0.0.0.0:9100'
   
   gitaly['configuration'] = {
      # ...
      #
      # Gitaly를 모든 네트워크 인터페이스에서 연결을 수락하도록 만듭니다. 이 주소/포트에 대한 액세스를 제한하기 위해 방화벽을 사용해야 합니다.
      # TLS 연결만 지원하려면 다음줄을 주석 처리합니다.
      listen_addr: '0.0.0.0:8075',
      prometheus_listen_addr: '0.0.0.0:9236',
      # Gitaly 인증 토큰
      # praefect_internal_token과 일치해야 합니다.
      auth: {
         # ...
         #
         # Gitaly의 인증 토큰은 gRPC 요청을 Gitaly에 인증하는 데 사용됩니다. 이것은 GitLab Rails 애플리케이션 설정에서 해당하는 값과 일치해야 합니다.
         token: 'gitalysecret',
      },
      # Gitaly Pack-objects 캐시
      # 성능 향상을 위해 사용하는 것이 좋지만 디스크 I/O를 현저히 높일 수 있습니다.
      # 자세한 내용은 https://docs.gitlab.com/ee/administration/gitaly/configure_gitaly.html#pack-objects-cache를 참조하십시오
      pack_objects_cache: {
         # ...
         enabled: true,
      },
      storage: [
         {
            name: 'default',
            path: '/var/opt/gitlab/git-data',
         },
         {
            name: 'storage1',
            path: '/mnt/gitlab/git-data',
         },
      ],
   }
   

3. 변경 내용이 적용되려면 GitLab의 재구성을 해야 합니다.

4. 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 인스턴스와 통신하려면 해당 스토리지 항목의 gitaly_address에서 tls:// URL scheme을 사용해야 합니다.

자체 인증서를 가져와야 합니다. 이 기능은 자동으로 제공되지 않습니다. 인증서 또는 인증서 기관은 모든 Gitaly 노드(인증서를 사용하는 Gitaly 노드 포함) 및 해당 노드와 통신하는 모든 클라이언트 노드에 설치되어야 하며, 이에 대한 절차는 GitLab 사용자 정의 인증서 구성에 설명되어 있습니다.

참고: 자체 서명된 인증서는 Gitaly 서버에 액세스하는 데 사용하는 주소를 지정해야 합니다. Gitaly 서버에 호스트 이름으로 접근하는 경우 동일한 이름을 대체 주제 이름으로 추가해야 합니다. Gitaly 서버에 IP 주소로 접근하는 경우, 해당 IP 주소를 인증서의 대체 주제 이름으로 추가해야 합니다.

Gitaly 서버는 암호화되지 않은 수신 대기 주소(listen_addr) 및 암호화된 수신 대기 주소(tls_listen_addr)를 동시에 구성하는 것이 가능합니다. 필요에 따라 암호화되지 않은 트래픽에서 암호화된 트래픽으로 점진적으로 전환할 수 있도록 합니다.

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

1. /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
   

2. cert를 /etc/gitlab/trusted-certs로 복사하여 Gitaly에서 자체 인증서 사용할 수 있게 합니다:

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

3. /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',
      },
   }
   

4. 암호화된 연결만 허용하려면 gitaly['listen_addr']를 삭제합니다.
5. 파일을 저장하고 GitLab 재구성을 수행합니다.

Sidekiq 구성

Sidekiq는 Redis, PostgreSQL, Gitaly 인스턴스에 연결하면서 권장하는 방법으로 Object Storage에도 연결해야 합니다.

참고: 환경의 Sidekiq 작업 처리가 오래 걸리거나 큰 대기열이 있는 경우 해당 작업 처리를 스케일링할 수 있습니다. 자세한 내용은 스케일링 설명서를 참조하세요.

참고: Container Registry, SAML 또는 LDAP와 같은 추가 GitLab 기능을 구성할 때에는 Rails 구성과 함께 Sidekiq 구성도 업데이트해야 합니다. 자세한 내용은 외부 Sidekiq 문서를 참조하세요.

Sidekiq 서버를 구성하려면 Sidekiq를 사용하려는 서버 노드에서 다음을 수행하십시오:

1. Sidekiq 서버에 SSH로 로그인합니다.

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

   telnet <GitLab host> 5432 # PostgreSQL
   telnet <GitLab host> 8075 # Gitaly
   telnet <GitLab host> 6379 # Redis
   

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

4. /etc/gitlab/gitlab.rb를 만들거나 편집하고 다음 설정을 사용합니다:

   # https://docs.gitlab.com/omnibus/roles/#sidekiq-roles
   roles(["sidekiq_role"])
   
   # 외부 URL
   external_url 'https://gitlab.example.com'
   
   ## Redis 연결 세부 정보
   gitlab_rails['redis_port'] = '6379'
   gitlab_rails['redis_host'] = '10.1.0.6' # Redis 서버의 IP/호스트 이름
   gitlab_rails['redis_password'] = 'Redis 암호'
   
   # Gitaly 및 GitLab은 gRPC 요청을 인증하거나 GitLab-Shell에서 GitLab 내부 API로의 인증 콜백에 사용할 두 개의 공유된 비밀을 사용합니다.
   # 다음은 Gitaly 설정의 해당 값과 동일해야 합니다.
   gitlab_rails['gitaly_token'] = 'gitalysecret'
   
   git_data_dirs({
     'default' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
     'storage1' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
     'storage2' => { 'gitaly_address' => 'tcp://gitaly2.internal:8075' },
   })
   
   ## PostgreSQL 연결 세부 정보
   gitlab_rails['db_adapter'] = 'postgresql'
   gitlab_rails['db_encoding'] = 'unicode'
   gitlab_rails['db_host'] = '10.1.0.5' # 데이터베이스 서버의 IP/호스트 이름
   gitlab_rails['db_password'] = 'DB 암호'
   
   ## 업그레이드시 자동으로 데이터베이스 마이그레이션을 방지합니다.
   gitlab_rails['auto_migrate'] = false
   
   # Sidekiq
   sidekiq['listen_address'] = "0.0.0.0"
   
   ## 사용 가능한 CPU 수와 동일한 수의 Sidekiq 큐 프로세스 수를 설정합니다.
   sidekiq['queue_groups'] = ['*'] * 4
   
   ## Exporter가 청취할 네트워크 주소를 설정합니다.
   node_exporter['listen_address'] = '0.0.0.0:9100'
   
   # Object Storage
   ## 이 구성은 GCP에서 Object Storage를 구성하는 예시입니다.
   ## 선택한 Object Storage 공급업체에 맞게 이 구성을 교체합니다.
   gitlab_rails['object_store']['enabled'] = true
   gitlab_rails['object_store']['connection'] = {
     'provider' => 'Google',
     'google_project' => '<gcp-project-name>',
     'google_json_key_location' => '<path-to-gcp-service-account-key>'
   }
   gitlab_rails['object_store']['objects']['artifacts']['bucket'] = "<gcp-artifacts-bucket-name>"
   gitlab_rails['object_store']['objects']['external_diffs']['bucket'] = "<gcp-external-diffs-bucket-name>"
   gitlab_rails['object_store']['objects']['lfs']['bucket'] = "<gcp-lfs-bucket-name>"
   gitlab_rails['object_store']['objects']['uploads']['bucket'] = "<gcp-uploads-bucket-name>"
   gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
   gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
   gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
   
   gitlab_rails['backup_upload_connection'] = {
     'provider' => 'Google',
     'google_project' => '<gcp-project-name>',
     'google_json_key_location' => '<path-to-gcp-service-account-key>'
   }
   gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
   gitlab_rails['ci_secure_files_object_store_enabled'] = true
   gitlab_rails['ci_secure_files_object_store_remote_directory'] = "gcp-ci_secure_files-bucket-name"
   
   gitlab_rails['ci_secure_files_object_store_connection'] = {
      'provider' => 'Google',
      'google_project' => '<gcp-project-name>',
      'google_json_key_location' => '<path-to-gcp-service-account-key>'
   }
   

5. 처음 구성하는 경우, 첫 번째 Linux 패키지 노드에서 /etc/gitlab/gitlab-secrets.json 파일을 가져와 해당 서버에 동일한 이름의 파일을 추가하거나 교체합니다. 이를 수행하지 않아도 되는 경우, 첫 번째 Linux 패키지 노드를 구성 중인 경우 이 단계를 건너뛰시기 바랍니다.

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

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

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

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

8. 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) 구성 방법에 대해 설명합니다.

우리의 아키텍처에서는 Puma 웹 서버를 사용하여 각 GitLab Rails 노드를 실행하고 있으며, 사용 가능한 CPU의 90%에 해당하는 작업자 수를 4개의 스레드로 설정하고 있습니다. 다른 구성 요소를 사용하여 Rails를 실행 중인 노드의 경우 작업자 값은 그에 따라 적절하게 감소해야 합니다. 작업자 값이 50%의 균형을 이룬다고 판단하여 좋은 균형을 유지할 수 있다고 결정했지만, 이는 작업 부하에 따라 다를 수 있습니다.

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

1. 선택한 리눅스 패키지를 다운로드하고 설치하십시오. 페이지에서 installation 단계 1과 2 만 따르도록 주의하십시오.

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

   external_url 'https://gitlab.example.com'
   
   # Gitaly 및 GitLab은 gRPC 요청 인증을 위해 두 개의 공유 비밀키를 사용하며,
   # 하나는 Gitaly로의 gRPC 요청을 인증하는 데 사용되고, 두 번째는
   # GitLab-Shell에서 GitLab 내부 API로의 인증 콜백에 사용되며 /etc/gitlab/gitlab-secrets.json에 저장됩니다. 
   # 다음은 Gitaly 설정의 해당 값과 동일해야 합니다.
   gitlab_rails['gitaly_token'] = 'gitalysecret'
   
   git_data_dirs({
     'default' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
     'storage1' => { 'gitaly_address' => 'tcp://gitaly1.internal:8075' },
     'storage2' => { 'gitaly_address' => 'tcp://gitaly2.internal:8075' },
   })
   
   ## GitLab 애플리케이션 서버에 없는 구성 요소를 비활성화합니다
   roles(['application_role'])
   gitaly['enable'] = false
   sidekiq['enable'] = false
   
   ## PostgreSQL 연결 세부 정보
   gitlab_rails['db_adapter'] = 'postgresql'
   gitlab_rails['db_encoding'] = 'unicode'
   gitlab_rails['db_host'] = '10.1.0.5' # 데이터베이스 서버의 IP/호스트 이름
   gitlab_rails['db_password'] = '데이터베이스 암호'
   
   ## Redis 연결 세부 정보
   gitlab_rails['redis_port'] = '6379'
   gitlab_rails['redis_host'] = '10.1.0.6' # Redis 서버의 IP/호스트 이름
   gitlab_rails['redis_password'] = 'Redis 암호'
   
   # 모니터링에 사용되는 수출 프로그램이 청취할 네트워크 주소를 설정합니다
   node_exporter['listen_address'] = '0.0.0.0:9100'
   gitlab_workhorse['prometheus_listen_addr'] = '0.0.0.0:9229'
   puma['listen'] = '0.0.0.0'
   
   # 모니터링 노드의 IP 주소를 모니터링 화이트리스트에 추가하고
   # 해당 주소 및/또는 서브넷을 기술 모니터링 노드로부터 수집한 값으로 교체하여
   # NGINX 메트릭스 수집 업데이트에 대한 허용 목록을 활성화합니다
   gitlab_rails['monitoring_whitelist'] = ['<모니터링 노드 IP>/32', '127.0.0.0/8']
   nginx['status']['options']['allow'] = ['<모니터링 노드 IP>/32', '127.0.0.0/8']
   
   # 오브젝트 스토리지
   # GCP에 대한 오브젝트 스토리지 구성 예제입니다
   # 귀하의 선택한 오브젝트 스토리지 공급자로 이 구성을 교체하십시오
   gitlab_rails['object_store']['enabled'] = true
   gitlab_rails['object_store']['connection'] = {
     'provider' => 'Google',
     'google_project' => '<gcp-project-name>',
     'google_json_key_location' => '<path-to-gcp-service-account-key>'
   }
   gitlab_rails['object_store']['objects']['artifacts']['bucket'] = "<gcp-artifacts-bucket-name>"
   gitlab_rails['object_store']['objects']['external_diffs']['bucket'] = "<gcp-external-diffs-bucket-name>"
   gitlab_rails['object_store']['objects']['lfs']['bucket'] = "<gcp-lfs-bucket-name>"
   gitlab_rails['object_store']['objects']['uploads']['bucket'] = "<gcp-uploads-bucket-name>"
   gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
   gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
   gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
   
   gitlab_rails['backup_upload_connection'] = {
     'provider' => 'Google',
     'google_project' => '<gcp-project-name>',
     'google_json_key_location' => '<path-to-gcp-service-account-key>'
   }
   gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
   
   gitlab_rails['ci_secure_files_object_store_enabled'] = true
   gitlab_rails['ci_secure_files_object_store_remote_directory'] = "gcp-ci_secure_files-bucket-name"
   
   gitlab_rails['ci_secure_files_object_store_connection'] = {
      'provider' => 'Google',
      'google_project' => '<gcp-project-name>',
      'google_json_key_location' => '<path-to-gcp-service-account-key>'
   }
   
   ## 다음 옵션의 주석 처리를 해제하고 설정을 수정하십시오(NFS를 설정한 경우)
   ##
   ## GitLab이 NFS 데이터 마운트를 사용할 수 없을 경우 시작하지 않도록 합니다
   ##
   #high_availability['mountpoint'] = '/var/opt/gitlab/git-data'
   ##
   ## NFS를 통한 권한을 위해 서버 간에 UID 및 GID가 일치하는지 확인합니다
   ##
   #user['uid'] = 9000
   #user['gid'] = 9000
   #web_server['uid'] = 9001
   #web_server['gid'] = 9001
   #registry['uid'] = 9002
   #registry['gid'] = 9002
   

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

   git_data_dirs({
     'default' => { 'gitaly_address' => 'tls://gitaly1.internal:9999' },
     'storage1' => { 'gitaly_address' => 'tls://gitaly1.internal:9999' },
     'storage2' => { 'gitaly_address' => 'tls://gitaly2.internal:9999' },
   })
   

   1. 다음과 같이 인증서를 /etc/gitlab/trusted-certs에 복사하십시오:

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

4. 첫 번째 리눅스 패키지 노드를 구성할 때 /etc/gitlab/gitlab-secrets.json 파일을 복사한 다음, 해당 서버의 동일한 이름의 파일에 추가하거나 교체하십시오. 이것이 구성 중인 첫 번째 리눅스 패키지 노드이면 이 단계를 건너뛰어도 됩니다.

5. 데이터베이스 마이그레이션이 업그레이드 시 자동으로 실행되지 않고 reconfigure 중에만 실행되도록 하기 위해 다음을 실행하십시오:

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

   GitLab Rails 구성 후처리 섹션에 기술된 대로 마이그레이션을 처리해야 할 단일 지정된 노드만 처리해야 합니다.

6. 변경 사항이 적용되려면 GitLab을 다시 구성하십시오.
7. 증분 로깅을 활성화하십시오.

8. sudo gitlab-rake gitlab:gitaly:check를 실행하여 노드가 Gitaly에 연결할 수 있는지 확인하십시오.

9. 요청을 볼러로그로 확인하려면 다음을 실행하십시오:

   sudo gitlab-ctl tail gitaly
   

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

GitLab Rails 포스트 구성

1. 설치 및 업데이트 중에 데이터베이스 마이그레이션을 실행할 애플리케이션 노드를 지정하세요. GitLab 데이터베이스를 초기화하고 모든 마이그레이션이 실행되었는지 확인하세요:

   sudo gitlab-rake gitlab:db:configure
   

   이 작업은 레일스 노드가 기본 데이터베이스에 직접 연결하도록 구성해야 하며 PgBouncer를 우회해야 합니다. 마이그레이션이 완료되면 노드를 다시 PgBouncer로 전환해야 합니다.

2. 데이터베이스에서 SSH 키를 빠르게 찾을 수 있도록 구성하세요.

Prometheus 구성

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

1. 모니터링 노드에 SSH로 접속하세요.
2. 원하는 Linux 패키지를 다운로드 및 설치하세요. 페이지에서 단계 1 및 2만 따르도록 하세요.

3. /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
   

4. 또한 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'],
        ],
     },
   ]
   

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

객체 저장소 구성

GitLab은 다양한 유형의 데이터를 보관하기 위해 객체 저장소 서비스를 사용할 수 있습니다. 대규모 구성에서는 일반적으로 더 성능이 좋고 신뢰성이 있으며 확장 가능하기 때문에 NFS보다 객체 저장소를 사용하는 것이 좋습니다. 자세한 내용은 추천 클라우드 제공업체 및 서비스를 참조하세요.

GitLab에서 객체 저장소 구성을 지정하는 두 가지 방법이 있습니다:

• 통합된 형식: 모든 지원되는 객체 유형에서 사용하는 단일 자격 증명입니다.
• 저장소별 형식: 각 객체가 자체 객체 저장소 연결 및 구성을 정의합니다.

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

각 데이터 유형에 대해 별도의 버킷을 사용하는 것이 권장됩니다. 이렇게 하면 GitLab이 저장하는 다양한 유형의 데이터 간에 충돌이 발생하지 않도록 보장할 수 있습니다. 미래에는 단일 버킷 사용을 활성화할 계획이 있습니다.

증분 로깅 활성화

기본적으로 GitLab Runner는 작업 로그를 조각으로 반환하며, 통합된 객체 저장소를 사용할 때도 임시로 /var/opt/gitlab/gitlab-ci/builds에 디스크에 캐시합니다. 기본 구성으로는 이 디렉토리를 모든 GitLab Rails 및 Sidekiq 노드에서 NFS를 통해 공유해야 합니다.

NFS를 통해 작업 로그를 공유할 수 있지만, NFS 사용을 피하고자 할 때는 증분 로깅(NFS 노드를 배포하지 않은 경우 필요)을 활성화하는 것이 권장됩니다. 증분 로깅은 작업 로그의 임시 캐싱을 위해 디스크 공간 대신 Redis를 사용합니다.

고급 검색 구성

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

Elasticsearch 클러스터 설계 및 요구 사항은 특정 데이터에 따라 다릅니다. 인스턴스와 함께 Elasticsearch 클러스터를 설정하는 권장 사항 및 최상의 방법은 최적의 클러스터 구성 선택을 읽어보세요.

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

클라우드 네이티브 GitLab의 선택 요소를 쿠버네티스에서 GitLab Helm 차트를 활용하여 실행할 수 있습니다. 이 설정에서는 쿠버네티스 클러스터 내에서 GitLab Rails의 동등한 기능을 하는 Webservice와 쿠버네티스 클러스터 내에서 Sidekiq의 동등한 기능을 하는 노드를 실행할 수 있습니다. 또한, NGINX, Toolbox, Migrations, Prometheus와 같은 다른 서비스도 지원됩니다.

하이브리드 설치는 클라우드 네이티브 및 전통적인 컴퓨팅 배포의 이점을 활용합니다. 이를 통해 상태를 유지하지 않는 구성 요소는 클라우드 네이티브 워크로드 관리 이점을 누리는 반면, 상태를 유지하는 구성 요소는 Linux 패키지 설치된 컴퓨팅 VM에서 배포하여 증가한 영구성을 누릅니다.

백엔드 구성에 대한 자세한 내용 및 쿠버네티스 백엔드 구성 방법 설명을 포함한 Helm 차트 고급 구성 문서를 참조하세요.

클러스터 위상

다음 표 및 다이어그램은 일반적인 환경과 동일한 형식을 사용하여 하이브리드 환경을 보여줍니다.

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

• 이 설정에서는 권장되며 정기적으로 테스트를 진행합니다. Google Kubernetes Engine (GKE) 및 Amazon Elastic Kubernetes Service (EKS)를 참조하세요. 다른 쿠버네티스 서비스도 작동할 수는 있지만, 상황에 따라 다를 수 있습니다.
• GCP 및 AWS 예제는 대상 노드 풀 총계에 도달하는 방법을 편리하게 보여줍니다. 이러한 크기는 성능 테스트에 사용되지만, 예제를 따를 필요는 없습니다. 다른 노드 풀 디자인을 원하는 대로 사용할 수 있지만 대상을 충족하고 모든 파드를 배포할 수 있는지 확인해야 합니다.
• 웹 서비스 및 Sidekiq 대상 노드 풀 총계는 GitLab 구성요소만을 대상으로 합니다. 추가적인 리소스는 선택된 쿠버네티스 제공 업체의 시스템 프로세스를 위한 것입니다. 제공된 예제는 이를 고려에 들여놓은 것입니다.
• 지원 서비스 대상 노드 풀 총계는 주로 GitLab 배포 및 요구 사항에 따라 추가적인 배포를 위한 여러 리소스를 수용하기 위한 것입니다. 기존의 다른 노드 풀과 마찬가지로 선택된 쿠버네티스 제공 업체의 시스템 프로세스도 리소스가 필요합니다. 제공된 예제는 이를 고려에 들여놓은 것입니다.
• 프로덕션 배포에는 특정 노드에 파드 할당이 필요하지 않지만, 복원력 있는 클라우드 아키텍처 관행을 준수하기 위해 여러 가용 영역에 걸쳐 다양한 노드를 가지길 권장합니다.
• Webservice 및 Sidekiq 파드의 효율성을 위해 Cluster Autoscaler와 같은 오토스케일링을 활성화하는 것이 권장됩니다. 그러나 보통의 경우 Webservice 및 Sidekiq 파드는 계속해서 성능이 유지되도록 75%를 타겟으로 하는 것이 권장됩니다.

다음으로 리눅스 패키지를 사용하여 정적 컴퓨팅 VM에서 실행되는 백엔드 구성에 대하여 아래를 참조하세요:

각주:

1. 신뢰할만한 타사 외부 PaaS PostgreSQL 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 자체 PostgreSQL 인스턴스 제공 및 권장되는 클라우드 제공 업체 및 서비스에서 확인하세요.
2. 신뢰할만한 타사 외부 PaaS Redis 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 내용은 자체 Redis 인스턴스 제공 및 권장되는 클라우드 제공 업체 및 서비스에서 확인하세요.
3. 신뢰할만한 클라우드 제공자 또는 Self-Managed 솔루션에서 실행해야 합니다. 자세한 정보는 객체 저장소 구성에서 확인하세요.

Kubernetes 구성 요소 대상

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

Webservice

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

• 4개의 Puma 워커
• 4 vCPU
• 5GB 메모리 (요청)
• 7GB 메모리 (한도)

40 RPS 또는 2,000 사용자를 대상으로 할 경우, 총 Puma 워커 수를 약 12개로 권장하며, 이에 따라 최소 3개의 Webservice 파드를 실행하는 것이 좋습니다.

Webservice 리소스 사용에 대한 자세한 정보는 Webservice resources의 차트 설명서를 참조하십시오.

NGINX

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

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

Sidekiq

각 Sidekiq 파드는 다음 구성으로 실행하는 것이 좋습니다:

• 1개의 Sidekiq 워커
• 900m vCPU
• 2GB 메모리 (요청)
• 4GB 메모리 (한도)

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

Sidekiq 리소스 사용에 대한 자세한 정보는 Sidekiq resources의 차트 설명서를 참조하십시오.

Supporting

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

Cloud Provider의 구현 및 GitLab Shell과 같은 GitLab 배포와 관련된 다양한 배포물을 포함합니다.

컨테이너 레지스트리, 페이지 또는 모니터링과 같은 추가 배포물을 원하는 경우, 가능한 경우 Webservice 또는 Sidekiq 풀이 아닌이 풀에 배포하는 것이 좋습니다. Supporting 풀은 몇 가지 추가 배포물을 수용할 수 있도록 설계되었기 때문입니다. 그러나 사용 사례에 맞지 않는 배포물이 있다면 노드 풀을 적절히 늘릴 수 있습니다. 반대로 사용 사례에 맞게 오버 프로비저닝된 경우 노드 풀을 줄일 수 있습니다.

설정 파일 예제

상기 40 RPS 또는 2,000 참조 아키텍처 구성에 대한 GitLab Helm 차트 예제는 Charts 프로젝트에서 찾을 수 있습니다.

다음 단계

본 안내를 따른 후에는 핵심 기능이 구성된 새로운 GitLab 환경을 보유하게 될 것입니다.

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

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