• 요구 사양
• 테스트 방법론
• 컴포넌트 설정
• 외부 로드 밸런서 구성
  • 준비 상태 확인
  • 포트
    • 대체 SSH 포트
  • SSL
    • Application node terminates SSL
    • Load balancer terminates SSL without backend SSL
    • Load balancer terminates SSL with backend SSL
• PostgreSQL 구성
  • 본인의 PostgreSQL 인스턴스 제공
  • Linux 패키지를 사용하는 독립형 PostgreSQL
• Redis 구성
  • 자체 Redis 인스턴스 제공
  • 리눅스 패키지를 사용한 스탠드얼론 Redis
• Gitaly 구성
  • Gitaly TLS 지원
• Sidekiq 구성
• GitLab Rails 구성
  • GitLab Rails 포스트 구성
• Prometheus 구성
• 객체 리포지터리 구성
  • 증분 로깅 활성화
• 고급 검색 구성
• Helm 차트를 활용한 클라우드 네이티브 하이브리드 참조 아키텍처 (대안)
  • 클러스터 토폴로지
  • 리소스 사용량 설정
    • 웹 서비스
    • Sidekiq
  • 지원

참조 아키텍처: 최대 2,000명의 사용자까지

이 페이지에서는 최대 2,000명의 사용자를 위한 GitLab 참조 아키텍처에 대해 설명합니다(고려할 여지가 있는 HA 제외).

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

• 대상 부하: API: 40 RPS, Web: 4 RPS, Git (Pull): 4 RPS, Git (Push): 1 RPS
• 고가용성: 아니요. 고가용성 환경을 위해서는 수정된 3K 참조 아키텍처를 참고해주세요.
• 예상 비용: 비용 표 참조
• Cloud Native Hybrid: 예
• 사용할 참조 아키텍처를 모르시겠습니까? 더 많은 정보를 위해 이 안내서로 이동.

각주:

1. 명성이 좋은 타사 외부 PaaS PostgreSQL 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 정보는 자체 PostgreSQL 인스턴스 제공 및 권장되는 클라우드 제공업체 및 서비스를 참조하세요.
2. 명성이 좋은 타사 외부 PaaS Redis 솔루션에서 선택적으로 실행할 수 있습니다. 자세한 정보는 자체 Redis 인스턴스 제공 및 권장되는 클라우드 제공업체 및 서비스를 참조하세요.
3. 명성이 좋은 타사 로드 밸런서 또는 서비스(LB PaaS)와 함께 실행하는 것이 권장됩니다. 또한 크기 조정은 선택한 로드 밸런서와 네트워크 대역폭과 같은 추가 요소에 따라 달라집니다. 자세한 정보는 로드 밸런서를 참조하세요.
4. 명성이 좋은 클라우드 제공업체 또는 Self-managed 솔루션에서 실행해야 합니다. 자세한 정보는 객체 리포지터리 구성를 참조하세요.
5. Gitaly 사양은 정상 크기의 리포지터리 사용을 기준으로 합니다. 그러나 큰 모노 리포지터리(몇 기가바이트 이상)를 보유하고 있는 경우, Git 및 Gitaly 성능에 중대한 영향을 미칠 수 있으며 사양을 늘리는 것이 필요할 수 있습니다. 자세한 정보는 큰 모노 리포지터리를 참조하세요.
6. 컴포넌트는 상태 데이터를 저장하지 않기 때문에 Auto Scaling Groups (ASGs)에 배치될 수 있습니다. 그러나 GitLab Rails의 경우 마이그레이션 및 Mailroom와 같은 특정 프로세스는 한 노드에서만 실행해야 합니다.

요구 사양

시작하기 전에 참조 아키텍처를 참조하세요.

테스트 방법론

2k 아키텍처는 대부분의 워크플로를 커버하도록 설계되었으며 정기적으로 품질 엔지니어링 팀에 의해 스모크 및 성능 테스트를 진행합니다. 다음 엔드포인트 처리량 목표에 대해 다음과 같이 테스트됩니다:

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

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

위 엔드포인트 목표에 대해 정기적으로 더 높은 처리량을 갖고 있다는 메트릭이 있다면, 대형 단일 리포지터리 또는 주목할만한 추가 워크로드가 성능 환경에 주목할만한 영향을 미치므로 추가 조정이 필요할 수 있습니다. 해당 경우에는 링크된 문서 및 고객 성공 관리자나 지원팀에 문의하여 추가 지침을 받는 것이 강력히 권장됩니다.

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

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

컴포넌트 설정

GitLab 및 해당 컴포넌트를 최대 2,000명의 사용자를 수용하도록 설정하려면 다음을 수행하세요:

1. 외부 로드 밸런싱 노드 구성
   • GitLab 애플리케이션 서비스 노드의 로드 밸런싱을 처리하도록 구성합니다.
2. PostgreSQL 구성, GitLab의 데이터베이스입니다.
3. Redis 구성.
4. Gitaly 구성, Git 리포지터리에 대한 액세스를 제공합니다.
5. 기본 GitLab Rails 애플리케이션 구성
   • Puma, Workhorse, GitLab Shell을 실행하고 UI, API 및 Git을 모두 제공합니다.
6. Prometheus 구성, GitLab 환경을 모니터링합니다.
7. 객체 리포지터리 구성
   • 공유 데이터 객체에 사용됩니다.
8. 고급 검색 구성 (선택 사항)
   • 전체 GitLab 인스턴스에 대해 더 빠르고 고급 검색을 위해 설정됩니다.

외부 로드 밸런서 구성

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

어떤 로드 밸런서를 사용해야 하는지 또는 정확한 구성은 GitLab 문서의 범위를 벗어나지만 자세한 내용은 로드 밸런서를 참조하세요. 이 섹션에서는 사용할 로드 밸런서의 세부 구성에 중점을 둡니다.

준비 상태 확인

외부 로드 밸런서는 내장 모니터링 엔드포인트를 갖는 작동 중인 서비스로 라우팅될 수 있도록 보장해야 합니다. 준비 상태 확인은 추가 구성이 필요합니다. 검사되는 노드에서, 그렇지 않으면 외부 로드 밸런서가 연결할 수 없을 수 있습니다.

포트

사용할 기본 포트는 다음의 표에서 보여집니다.

• (1): 웹 터미널 지원은 웹 소켓 연결을 올바르게 처리하는 로드 밸런서가 있어야 합니다. 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을 종료 하고 로드 밸런서와 애플리케이션 노드 간 통신이 안전합니다.

Application node terminates SSL

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

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

Load balancer terminates SSL without backend SSL

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

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

Load balancer terminates SSL with backend SSL

로드 밸런서를 TCP 대신 HTTP(S) 프로토콜을 사용하도록 구성하십시오. 로드 밸런서가 엔드 유저가 보게 될 SSL 인증서를 관리합니다.

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

PostgreSQL 구성

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

본인의 PostgreSQL 인스턴스 제공

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

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

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

1. PostgreSQL, PgBouncer, 그리고 Consul을 포함하는 HA Linux 패키지 PostgreSQL 설정이 더 이상 필요하지 않음을 참고하십시오.
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. PostgreSQL 노드의 IP 주소 또는 호스트명, 포트, 그리고 일반 텍스트 비밀번호를 참고하십시오. 이는 이후 GitLab 애플리케이션 서버를 구성할 때 필요할 것입니다.

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

Redis 구성

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

자체 Redis 인스턴스 제공

다음 안내에 따라 외부 Redis 인스턴스를 위한 제 3자 서비스를 선택적으로 사용할 수 있습니다.

• Google Memorystore 및 AWS ElastiCache와 같은 신뢰할 수 있는 제공 업체 또는 솔루션을 사용해야 합니다.
• Redis 클러스터 모드는 특별히 지원되지 않지만, Redis 스탠드얼론 및 HA는 지원됩니다.
• 설정 방법에 따라 Redis 유출 모드를 설정해야 합니다.

자세한 내용은 추천 클라우드 제공자 및 서비스를 참조하십시오.

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

리눅스 패키지를 사용하여 스탠드얼론 Redis 서버를 구성할 수 있습니다. 아래 단계는 리눅스 패키지를 사용하여 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'] = '여기에_비밀_암호_입력'
      
   gitlab_rails['enable'] = false
      
   # 모니터링에 사용되는 내부 네트워크 주소 설정
   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' => '여기에_비밀_암호_입력',
   }
   

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

5. 변경 사항이 적용되려면 GitLab 재구성을 수행하십시오.

6. 이후 GitLab 애플리케이션 서버를 구성할 때 Redis 노드의 IP 주소 또는 호스트 이름, 포트 및 Redis 비밀번호를 확인합니다.

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

Gitaly 구성

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

Gitaly의 중요한 입력 및 출력 요구 사항을 고려하여, 모든 Gitaly 노드가 SSD (고성능)를 사용하는 것이 좋습니다. 이러한 SSD는 읽기 작업에 대해 최소 8,000 IOPS, 쓰기 작업에 대해 2,000 IOPS의 처리량이 있어야 합니다. 환경을 클라우드 제공업체에서 실행 중인 경우 해당 업체의 문서를 참조하여 IOPS를 올바르게 구성해야 합니다.

다음 사항을 반드시 확인하십시오.

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

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

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

1. 원하는 Linux 패키지를 다운로드하고 설치합니다. 페이지에서 설치 단계 1과 2만을 따라하기만 하고 EXTERNAL_URL 값을 제공하지 마십시오.

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

   GitLab은 필요합니다 ‘gitaly[‘configuration’][:storage]’에서 ‘default’ 항목을 제거할 수 없습니다.

   # 불필요한 서비스가 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
      
   # 시크릿 토큰은 Gitaly에서 GitLab 내부 API로의 인증 콜백에 사용됩니다.
   # 이것은 GitLab Rails 애플리케이션 설정에서 해당 값과 일치해야 합니다.
   gitlab_shell['secret_token'] = 'shellsecret'
      
   # 모니터링에 사용되는 내부 네트워크 주소 설정
   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 /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml을 실행합니다.
   • GitLab 15.2 이하의 경우 sudo /opt/gitlab/embedded/bin/gitaly-hooks check /var/opt/gitlab/gitaly/config.toml을 실행합니다.

Gitaly TLS 지원

Gitaly는 TLS 암호화를 지원합니다. 안전한 연결을 위해 Gitaly 인스턴스가 수신 대기하는 경우 해당 리포지터리 항목의 gitaly_address에서 tls:// URL scheme을 사용해야 합니다.

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

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. 인증서를 /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 서버를 구성하려면 Sidekiq를 사용할 서버 노드에서 다음을 수행하세요:

1. Sidekiq 서버에 SSH로 연결합니다.
2. 사용할 Linux 패키지를 다운로드 및 설치합니다. 페이지에서 설치 단계 1 및 2만 따르도록 합니다.

3. /etc/gitlab/gitlab.rb를 생성 또는 편집하고 다음 구성을 사용합니다:

   # https://docs.gitlab.com/omnibus/roles/#sidekiq-roles
   roles(["sidekiq_role"])
      
   # 외부 URL
   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'
   gitlab_shell['secret_token'] = 'shellsecret'
      
   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'] = '데이터베이스 패스워드'
      
   ## 업그레이드 시 자동으로 데이터베이스 마이그레이션을 실행하지 않도록 설정
   gitlab_rails['auto_migrate'] = false
      
   # Sidekiq
   sidekiq['enable'] = true
   sidekiq['listen_address'] = "0.0.0.0"
      
   ## 사용 가능한 CPU 수와 동일한 Sidekiq 큐 프로세스 수로 설정
   sidekiq['queue_groups'] = ['*'] * 4
      
   ## 내보내기가 수신할 네트워크 주소 설정
   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>'
   }
   

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

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

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

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

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

7. 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. 선택한 Linux 패키지를 다운로드하고 설치하세요. 페이지의 설치 단계 1 및 2만 따르도록 합니다.

2. /etc/gitlab/gitlab.rb 파일을 생성하거나 편집하고 다음 구성을 사용하세요. 노드 간의 링크를 일관되게 유지하려면 응용 프로그램 서버의 external_url은 사용자가 GitLab에 액세스하는 데 사용할 외부 URL을 가리켜야 합니다. 이는 트래픽을 GitLab 응용 프로그램 서버로 라우팅할 로드 밸런서의 URL일 것입니다.

   external_url 'https://gitlab.example.com'
      
   # Gitaly와 GitLab은 gRPC 요청을 인증하기 위해 2개의 공유 비밀을 사용하며,
   # 또한 GitLab-Shell에서 GitLab 내부 API로의 인증 콜백을 위해 두 번째 비밀을 사용합니다. 
   # 다음 두 값은 Gitaly 설정의 해당 값과 동일해야 합니다.
   gitlab_rails['gitaly_token'] = 'gitalysecret'
   gitlab_shell['secret_token'] = 'shellsecret'
      
   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
   nginx['enable'] = true
   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'] = 'DB password'
      
   ## Redis 연결 세부 정보
   gitlab_rails['redis_port'] = '6379'
   gitlab_rails['redis_host'] = '10.1.0.6' # Redis 서버의 IP/호스트명
   gitlab_rails['redis_password'] = 'Redis Password'
      
   # 모니터링에 사용되는 수출자가 청취할 네트워크 주소 설정
   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 메트릭의 수집을 허용
   # 모니터링 노드에서 얻은 주소 및/또는 서브넷으로 플레이스홀더 `monitoring.gitlab.example.com`를 대체하세요
   gitlab_rails['monitoring_whitelist'] = ['<MONITOR NODE IP>/32', '127.0.0.0/8']
   nginx['status']['options']['allow'] = ['<MONITOR NODE 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>'
   }
   

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. 이미 구성한 첫 번째 Linux 패키지 노드로부터 /etc/gitlab/gitlab-secrets.json 파일을 복사하고 이 서버의 동일한 이름의 파일을 추가하거나 대체하세요. 이게 당신이 구성하는 첫 번째 Linux 패키지 노드라면, 이 단계를 생략할 수 있습니다.

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

   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 키를 빠르게 조회하도록 구성합니다(../operations/fast_ssh_key_lookup.md).

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
   

   다음을 /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.4:8082', '1.1.1.5:8082'],
        ],
     },
     {
        'job_name': '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'],
        ],
     },
   ]
   

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

객체 리포지터리 구성

GitLab은 다양한 유형의 데이터를 보유하기 위한 객체 리포지터리 서비스를 지원합니다. 일반적으로 대규모 구성에서 NFS에 비해 성능이 우수하고 신뢰성이 높으며 확장 가능한 객체 리포지터리를 사용하는 것이 권장됩니다. 자세한 내용은 권장되는 클라우드 제공업체 및 서비스를 참조하세요.

GitLab에서 객체 리포지터리 구성을 지정하는 두 가지 방법이 있습니다:

• 통합형 양식: 모든 지원되는 객체 유형이 공유 자격 증명을 사용합니다.
• 리포지터리별 양식: 모든 객체가 자체 객체 리포지터리 연결 및 구성을 정의합니다.

일반적으로 사용 가능한 경우 통합형 양식을 사용합니다.

각 데이터 유형에 별도의 버킷을 사용하는 것이 GitLab에서 권장하는 방법입니다. 이렇게 하면 GitLab이 저장하는 다양한 유형의 데이터 간에 충돌이 없도록 보장됩니다. 앞으로 하나의 버킷을 사용하는 것도 계획 중에 있습니다.

증분 로깅 활성화

기본적으로 GitLab Runner는 작업 로그를 청크(chunk)로 반환하며, 리눅스 패키지는 일시적으로 /var/opt/gitlab/gitlab-ci/builds 디렉터리에 캐시합니다. 기본 구성에서 심층화된 객체 스토리지를 사용할 때에도 해당 디렉터리는 모든 GitLab Rails 및 Sidekiq 노드에 걸쳐 NFS를 통해 공유되어야 합니다.

작업 로그를 NFS를 통해 공유하는 것은 지원되지만, NFS를 사용할 필요가 없도록 증분 로깅을 활성화하는 것이 권장됩니다(NFS 노드가 배포되지 않은 경우 필수). 증분 로깅은 작업 로그의 일시적인 캐싱을 위해 디스크 공간 대신 Redis를 사용합니다.

고급 검색 구성

Elasticsearch 및 고급 검색을 활성화하여 전체 GitLab 인스턴스에서 더 빠르고 더 고급스러운 코드 검색을 실시할 수 있습니다.

Elasticsearch 클러스터 설계 및 요구 사항은 당신의 특정 데이터에 종속적입니다. Elasticsearch 클러스터 구성을 최적으로 선택하는 것에 대한 권장 사항에 대해서는 최적의 클러스터 구성 선택에 대한 지침을 읽어보세요.

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

클라우드 네이티브 GitLab의 일부 컴포넌트를 GitLab Helm 차트를 활용하여 Kubernetes에서 실행하세요. 이 설정에서는 Kubernetes 클러스터 내에서 GitLab Rails의 동등한 가치를 가진 Webservice와 Kubernetes 클러스터 내에서 Sidekiq의 동등한 가치를 가진 노드를 실행할 수 있습니다. 또한, NGINX, Toolbox, Migration, Prometheus와 같은 지원 서비스를 지원할 수 있습니다.

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

백엔드 컴포넌트에 대한 Helm 차트 고급 구성 문서에서는 Kubernetes와 백엔드 컴포넌트 간에 동기화해야 하는 GitLab 비밀 정보에 대한 지침을 포함하여 설정 지침을 제공합니다.

클러스터 토폴로지

다음 표와 다이어그램은 전형적인 환경과 같은 포맷을 사용하여 하이브리드 환경을 상세하게 설명합니다.

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

• 이 설정에서는 권장되며 정기적으로 테스트합니다 Google Kubernetes Engine (GKE) 및 Amazon Elastic Kubernetes Service (EKS)을 사용합니다. 다른 Kubernetes 서비스도 작동할 수 있지만 상황에 따라 다를 수 있습니다.
• 노드 구성은 pod vCPU/메모리 비율을 확실히 하고 성능 테스트 중에 스케일링을 피하기 위해 표시됩니다.
  • 프로덕션 배포에서는 특정 노드에 pod를 할당할 필요가 없습니다. 서로 다른 가용 영역에 3개 이상의 노드로 구성하는 것이 견고한 클라우드 아키텍처 관행을 준수하는 데 강력히 권장됩니다.

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

주석:

1. 신뢰할 만한 제3자 외부 PaaS PostgreSQL 솔루션에서 선택 사항으로 실행할 수 있습니다. 자세한 내용은 자체 PostgreSQL 인스턴스 제공 및 권장 클라우드 제공업체 및 서비스를 참조하세요.
2. 신뢰할 만한 제3자 외부 PaaS Redis 솔루션에서 선택 사항으로 실행할 수 있습니다. 자세한 내용은 자체 Redis 인스턴스 제공 및 권장 클라우드 제공업체 및 서비스를 참조하세요.
3. 신뢰할 만한 클라우드 제공자 또는 Self-managed 솔루션에서 실행해야 합니다. 자세한 내용은 객체 스토리지 구성를 참조하세요.

리소스 사용량 설정

다음 공식은 리소스 제약 조건 내에서 배포될 수 있는 Pod 수를 계산하는 데 도움이 됩니다. 2k 레퍼런스 아키텍처 예제 값 파일에서는 계산된 구성을 Helm 차트에 적용하는 방법에 대해 문서화되어 있습니다.

웹 서비스

웹 서비스 Pod는 일반적으로 각 사업자 당 약 1 CPU와 1.25 GB의 메모리가 필요합니다. 각 웹 서비스 Pod는 기본적으로 두 개의 워커 프로세스가 생성되며 각 Pod에는 다른 작은 프로세스가 실행되기 때문에 권장 토폴로지를 사용할 경우 대략적으로 4 CPU와 5 GB의 메모리를 소비합니다.

2,000명의 사용자를 위해서는 대략 12개의 총 Puma 워커 카운트를 권장합니다. 제공된 권장 사항에 따라, 이를 통해 각 웹 서비스 Pod 당 4개의 워커와 노드당 1개의 Pod를 최대 3개까지 배포할 수 있습니다. 추가 웹 서비스 Pod당 1 CPU 당 1.25 GB의 메모리 비율을 사용하여 사용 가능한 리소스를 확장할 수 있습니다.

리소스 사용에 대한 자세한 내용은 웹 서비스 리소스를 참조하세요.

Sidekiq

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

제공된 시작점은 최대 4개의 Sidekiq Pod를 배포할 수 있도록 합니다. 추가된 Pod당 0.9 CPU에서 2GB 메모리의 비율을 사용하여 사용 가능한 리소스를 확장할 수 있습니다.

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

지원

지원 노드 풀은 웹 서비스 및 Sidekiq 풀에 있을 필요가 없는 모든 지원 배포를 수용할 수 있도록 설계되었습니다.

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

모니터링과 같은 추가 배포를 원한다면 가능한 경우 이 풀에 배포하는 것이 좋으며 웹 서비스나 Sidekiq 풀에 배포하지 않는 것이 좋습니다. 이는 지원 풀이 여러 추가 배포를 수용할 수 있도록 특별히 설계되었기 때문입니다. 그러나 제공된 풀에 배치하지 못하거나 제공된 풀에 맞지 않는 배포를 하는 경우에는 노드 풀을 적절하게 늘릴 수 있습니다.