GitLab 설치 요구사항
Offering: GitLab Self-Managed
GitLab에는 특정 설치 요구사항이 있습니다. 필요한 스토리지 공간은 주로 GitLab에 보유할 리포지터리의 크기에 따라 달라집니다. Linux 패키지는 설치를 위해 약 2.5 GB의 스토리지 공간이 필요합니다. 파일 시스템 성능이 GitLab의 전반적인 성능에 영향을 미칠 수 있으므로 스토리지에 클라우드 기반 파일 시스템을 사용하지 않아야 합니다.
GitLab에는 특정 설치 요구사항이 있습니다.
스토리지#
필요한 스토리지 공간은 주로 GitLab에 보유할 리포지터리의 크기에 따라 달라집니다. 지침으로, 모든 리포지터리를 합친 것과 최소한 동일한 여유 공간이 있어야 합니다.
Linux 패키지는 설치를 위해 약 2.5 GB의 스토리지 공간이 필요합니다. PostgreSQL, 로그, 임시 파일, 운영 체제 오버헤드와 결합하면 리포지터리 데이터 없이 기본 GitLab 설치를 위해 최소 40 GB의 디스크 공간을 계획하세요. 스토리지 유연성을 위해 논리 볼륨 관리를 통해 하드 드라이브를 마운트하는 것을 고려하세요. 응답 시간을 줄이기 위해 최소 7,200 RPM 또는 솔리드 스테이트 드라이브가 있는 하드 드라이브를 사용해야 합니다.
파일 시스템 성능이 GitLab의 전반적인 성능에 영향을 미칠 수 있으므로 스토리지에 클라우드 기반 파일 시스템을 사용하지 않아야 합니다.
CPU#
CPU 요구사항은 사용자 수와 예상 워크로드에 따라 달라집니다. 워크로드에는 사용자 활동, 자동화 및 미러링 사용, 리포지터리 크기가 포함됩니다.
초당 최대 20개의 요청 또는 1,000명의 사용자를 위해 8 vCPU가 있어야 합니다. 더 많은 사용자 또는 더 높은 워크로드의 경우 참조 아키텍처를 참조하세요.
메모리#
메모리 요구사항은 사용자 수와 예상 워크로드에 따라 달라집니다. 워크로드에는 사용자 활동, 자동화 및 미러링 사용, 리포지터리 크기가 포함됩니다.
초당 최대 20개의 요청 또는 1,000명의 사용자를 위해 16 GB의 메모리가 있어야 합니다. 더 많은 사용자 또는 더 높은 워크로드의 경우 참조 아키텍처를 참조하세요.
일부 경우에 GitLab은 최소 8 GB의 메모리로 실행될 수 있습니다. 자세한 내용은 메모리 제한 환경에서 GitLab 실행을 참조하세요.
PostgreSQL#
PostgreSQL은 유일하게 지원되는 데이터베이스이며 Linux 패키지와 함께 번들로 제공됩니다. 올바르게 구성되어야 하는 외부 PostgreSQL 데이터베이스를 사용할 수도 있습니다.
사용자 수에 따라 PostgreSQL 서버에는 다음이 있어야 합니다:
- 대부분의 GitLab 인스턴스의 경우 최소 5~10 GB의 스토리지
- GitLab Ultimate의 경우 최소 12 GB의 스토리지 (1 GB의 취약점 데이터를 가져와야 함)
다음 GitLab 버전에 대해 다음 PostgreSQL 버전을 사용합니다:
| GitLab 버전 | Helm 차트 버전 | 최소 PostgreSQL 버전 | 최대 PostgreSQL 버전 |
|---|---|---|---|
| 18.x | 9.x | 16.5 | 17.x (GitLab 17.10 이상에서 테스트됨) |
| 17.x | 8.x | 14.14 | 16.x (GitLab 16.10 이상에서 테스트됨) |
| 16.x | 7.x | 13.6 | 15.x (GitLab 16.1 이상에서 테스트됨) |
| 15.x | 6.x | 12.10 | 14.x (GitLab 15.11에서만 테스트됨), 13.x |
마이너 PostgreSQL 릴리스는 버그 및 보안 수정만 포함합니다. PostgreSQL에서 알려진 문제를 방지하려면 항상 최신 마이너 버전을 사용하세요. 자세한 내용은 이슈 364763을 참조하세요.
지정된 것보다 이후 주요 버전의 PostgreSQL을 사용하려면 이후 버전이 Linux 패키지와 함께 번들로 제공되는지 확인하세요.
또한 일부 확장이 모든 GitLab 데이터베이스에 로드되어 있는지 확인해야 합니다. 자세한 내용은 PostgreSQL 확장 관리를 참조하세요.
GitLab Geo#
GitLab Geo의 경우 GitLab을 설치하기 위해 Linux 패키지 또는 검증된 클라우드 제공업체를 사용해야 합니다. 다른 외부 데이터베이스와의 호환성은 보장되지 않습니다.
자세한 내용은 Geo 실행 요구사항을 참조하세요.
로케일 호환성#
glibc에서 로케일 데이터를 변경하면 PostgreSQL 데이터베이스 파일이
서로 다른 운영 체제 간에 더 이상 완전히 호환되지 않습니다.
인덱스 손상을 방지하려면
다음을 수행할 때 로케일 호환성을 확인하세요:
- 서버 간에 바이너리 PostgreSQL 데이터를 이동합니다.
- Linux 배포판을 업그레이드합니다.
- 타사 컨테이너 이미지를 업데이트하거나 변경합니다.
자세한 내용은 PostgreSQL을 위한 운영 체제 업그레이드를 참조하세요.
GitLab 스키마#
GitLab, Geo, Gitaly Cluster (Praefect) 또는 다른 구성 요소를 위한 데이터베이스를 독점적으로 생성하거나 사용해야 합니다. 다음을 따를 때를 제외하고 데이터베이스, 스키마, 사용자 또는 다른 속성을 생성하거나 수정하지 마세요:
- GitLab 문서의 절차
- GitLab 지원팀 또는 엔지니어의 지침
메인 GitLab 애플리케이션은 세 가지 스키마를 사용합니다:
- 기본
public스키마 gitlab_partitions_static(자동으로 생성됨)gitlab_partitions_dynamic(자동으로 생성됨)
Rails 데이터베이스 마이그레이션 중에 GitLab이 스키마 또는 테이블을 생성하거나 수정할 수 있습니다. 데이터베이스 마이그레이션은 GitLab 코드베이스의 스키마 정의에 대해 테스트됩니다. 스키마를 수정하면 GitLab 업그레이드가 실패할 수 있습니다.
PostgreSQL 설정#
외부에서 관리되는 PostgreSQL 인스턴스에 대한 일부 필수 설정이 있습니다.
| 튜닝 가능 설정 | 필수 값 | 추가 정보 |
|---|---|---|
work_mem |
최소 8 MB |
이 값은 Linux 패키지 기본값입니다. 대규모 배포에서 쿼리가 임시 파일을 생성하는 경우 이 설정을 늘려야 합니다. |
maintenance_work_mem |
최소 64 MB |
더 큰 데이터베이스 서버에는 더 많이 필요합니다. |
max_connections |
최소 400 |
GitLab 구성 요소를 기반으로 계산합니다. 자세한 지침은 PostgreSQL 튜닝 페이지를 참조하세요. |
shared_buffers |
최소 2 GB |
더 큰 데이터베이스 서버에는 더 많이 필요합니다. Linux 패키지 기본값은 서버 RAM의 25%로 설정됩니다. |
statement_timeout |
15000 to 60000 | statement timeout은 잠금 문제를 방지하고 데이터베이스가 새 클라이언트를 거부하는 것을 방지합니다. 15 |
hot_standby_feedback |
on |
여러 노드와 데이터베이스 로드 밸런싱이 구성된 구성에서 지연 빌드업을 방지하려면 모든 복제본 노드에 hot_standby_feedback이 활성화되어 있는지 확인하세요. |
서버의 모든 데이터베이스가 아닌 특정 데이터베이스에 대해 일부 PostgreSQL 설정을 구성할 수 있습니다.
- 동일한 서버에 여러 데이터베이스를 호스팅할 때 특정 데이터베이스로 구성을 제한할 수 있습니다.
- 구성을 적용할 위치에 대한 지침은 데이터베이스 관리자 또는 공급업체에 문의하세요.
- GCP Cloud SQL의 경우
statement_timeout을 특정 데이터베이스 또는 사용자에 설정할 수 있지만 데이터베이스 플래그로는 설정할 수 없습니다. 예:ALTER DATABASE gitlab SET statement_timeout = '60s';
Puma#
권장 Puma 설정은 설치에 따라 다릅니다. 기본적으로 Linux 패키지는 권장 설정을 사용합니다.
Puma 설정을 조정하려면:
- Linux 패키지의 경우 Puma 설정을 참조하세요.
- GitLab Helm 차트의 경우
webservice차트를 참조하세요.
워커#
권장 Puma 워커 수는 주로 CPU 및 메모리 용량에 따라 달라집니다.
기본적으로 Linux 패키지는 권장 워커 수를 사용합니다.
이 수가 계산되는 방법에 대한 자세한 내용은
puma.rb를 참조하세요.
노드는 Puma 워커가 두 개 미만이어서는 안 됩니다. 예를 들어 노드에는 다음이 있어야 합니다:
- 2 CPU 코어 및 8 GB 메모리에 대한 두 개의 워커
- 4 CPU 코어 및 4 GB 메모리에 대한 두 개의 워커
- 4 CPU 코어 및 8 GB 메모리에 대한 네 개의 워커
- 8 CPU 코어 및 8 GB 메모리에 대한 여섯 개의 워커
- 8 CPU 코어 및 16 GB 메모리에 대한 여덟 개의 워커
기본적으로 각 Puma 워커는 1.2 GB의 메모리로 제한됩니다.
/etc/gitlab/gitlab.rb에서 이 설정을 조정할 수 있습니다.
충분한 CPU 및 메모리 용량이 있는 경우 Puma 워커 수를 늘릴 수도 있습니다. 워커가 더 많으면 응답 시간이 줄어들고 병렬 요청 처리 능력이 향상됩니다. 설치에 최적의 워커 수를 확인하기 위해 테스트를 실행합니다.
스레드#
권장 Puma 스레드 수는 전체 시스템 메모리에 따라 달라집니다. 노드는 다음을 사용해야 합니다:
- 최대 2 GB 메모리의 운영 체제에 대한 하나의 스레드
- 2 GB 이상의 메모리의 운영 체제에 대한 네 개의 스레드
스레드가 더 많으면 과도한 스와핑이 발생하고 성능이 저하됩니다.
Redis#
Redis 또는 Valkey는 모든 사용자 세션과 백그라운드 작업을 저장하며 사용자당 평균 약 25 kB가 필요합니다.
Redis 7.2 또는 Valkey 7.2가 필요합니다. 수명 종료 날짜에 대한 자세한 내용은 Redis 문서를 참조하세요.
Redis의 경우:
- 독립형 인스턴스(고가용성 포함 또는 미포함)를 사용합니다. Redis Cluster는 지원되지 않습니다.
- 적절하게 제거 정책을 설정합니다.
Sidekiq#
Sidekiq은 백그라운드 작업에 멀티 스레드 프로세스를 사용합니다. 이 프로세스는 처음에 200 MB 이상의 메모리를 소비하며 메모리 누수로 인해 시간이 지남에 따라 증가할 수 있습니다.
청구 가능 사용자가 10,000명 이상인 매우 활성화된 서버에서 Sidekiq 프로세스는 1 GB 이상의 메모리를 소비할 수 있습니다.
Prometheus#
기본적으로 Prometheus와 관련 내보내기가 GitLab을 모니터링하기 위해 활성화됩니다. 이러한 프로세스는 약 200 MB의 메모리를 소비합니다.
자세한 내용은 Prometheus로 GitLab 모니터링을 참조하세요.
지원되는 웹 브라우저#
GitLab은 다음 웹 브라우저를 지원합니다:
GitLab은 다음을 지원합니다:
- 이러한 브라우저의 최근 두 주요 버전
- 지원되는 주요 버전의 현재 마이너 버전
이러한 브라우저에서 JavaScript를 비활성화하고 GitLab을 실행하는 것은 지원되지 않습니다.