설치 시스템 요구 사항

Tier: Free, Premium, Ultimate Offering: Self-Managed

이 페이지에는 GitLab을 설치하고 사용하기 위해 필요한 최소 요구 사항에 대한 정보가 포함되어 있습니다.

하드웨어 요구 사항

저장 공간

GitLab에 저장하려는 저장소의 크기에 따라 필요한 하드 드라이브 공간이 크게 달라집니다. 하지만 지침으로 모든 저장소의 사용 공간만큼의 충분한 여유 공간을 확보해야 합니다.

Linux 패키지는 설치를 위해 약 2.5GB의 저장 공간을 필요로 합니다.

미래에 하드 드라이브 공간을 유연하게 확장하고 싶다면 논리 볼륨 관리 (LVM)을 사용하여 하드 드라이브를 마운트하여 필요할 때 추가하도록 고려해볼 수 있습니다.

로컬 하드 드라이브 외에도 네트워크 파일 시스템 (NFS) 프로토콜을 지원하는 볼륨을 마운트할 수도 있습니다. 이 볼륨은 파일 서버, 네트워크 부착 저장소 (NAS) 장치, 스토리지 영역 네트워크 (SAN) 또는 Amazon Web Services (AWS) Elastic Block Store (EBS) 볼륨에 위치할 수 있습니다.

충분한 RAM과 최신 CPU가 있다면 GitLab의 속도는 주로 하드 드라이브 탐색 시간에 의해 제한됩니다. 빠른 드라이브(7200 RPM 이상) 또는 솔리드 스테이트 드라이브(SSD)를 사용하면 GitLab의 응답 성능이 향상됩니다.

note
파일 시스템의 성능이 GitLab의 전반적인 성능에 영향을 미칠 수 있으므로 저장 용도로 클라우드 기반 파일 시스템 사용을 권장하지 않습니다.
note
Git 저장소 저장을 위한 NFS는 폐기되었습니다. 자세한 정보는 공식 지원 성명서를 참조하십시오.

CPU

CPU 요구 사항은 사용자 수와 예상 워크로드에 따라 달라집니다. 예상 워크로드에 따라 정확한 요구 사항은 더 높을 수 있습니다. 예상 워크로드는 사용자의 활동 정도, 자동화 사용량, 미러링 및 저장소/변경 크기와 같은 요소에 영향을 받습니다.

다음은 몇 가지 예시 GitLab 사용자 규모에 대한 권장 최소 CPU 하드웨어 가이드라인입니다.

  • 4 코어권장 최소 코어 수이며 최대 500명의 사용자를 지원합니다.
  • 8 코어는 최대 1000명의 사용자를 지원합니다.
  • 더 많은 사용자? 참조 아키텍처 페이지를 참조하십시오.

메모리

메모리 요구 사항은 사용자 수와 예상 워크로드에 따라 달라집니다. 예상 워크로드에 따라 정확한 요구 사항은 더 높을 수 있습니다. 예상 워크로드는 사용자의 활동 정도, 자동화 사용량, 미러링 및 저장소/변경 크기와 같은 요소에 영향을 받습니다.

다음은 몇 가지 예시 GitLab 사용자 규모에 대한 권장 최소 메모리 하드웨어 가이드라인입니다.

  • 4GB RAM필수 최소 메모리이며 최대 500명의 사용자를 지원합니다.
  • 8GB RAM은 최대 1000명의 사용자를 지원합니다.
  • 더 많은 사용자? 참조 아키텍처 페이지를 참조하십시오.

더 작은 설치에서는 다음을 고려해야 합니다: - 충분한 사용 가능한 RAM이 있더라도 서버에 최소 2GB의 스왑을 설정해야 합니다. 스왑을 설정하면 사용 가능한 메모리가 변동되어도 오류가 발생할 가능성을 줄일 수 있습니다. - 스왑을 필요할 때 사용할 수 있도록 커널의 swappiness 설정을 10과 같은 낮은 값으로 구성해야 합니다.

참조 아키텍처를 따르는 대규모 설치에서는 스왑을 구성하지 않아야 합니다.

note
과도한 스왑은 원치 않으며 성능을 저하시키지만, 메모리 부족 상태에 대한 매우 중요한 마지노선으로 작용합니다. OS 업데이트 또는 동일한 호스트에서 다른 서비스와 같은 예상치 못한 시스템 부하 중에는 최대 메모리 부하가 평균보다 훨씬 높을 수 있습니다. 충분한 스왑 공간이 있다면 Linux OOM 킬러가 잠재적으로 중대할 수 있는 프로세스(예: PostgreSQL)를 안전하게 종료하여 재앙을 피할 수 있습니다.

데이터베이스

PostgreSQL은 Linux 패키지에 번들로 제공되는 유일한 지원되는 데이터베이스입니다. 외부 PostgreSQL 데이터베이스를 사용할 수도 있습니다.

PostgreSQL 요구 사항

PostgreSQL을 실행하는 서버는 최소 5-10GB의 저장 공간을 사용 가능하게 해야 하지만 정확한 요구 사항은 사용자 수에 따라 달라집니다. Ultimate 고객을 위한 서버는 취약점 데이터 1GB를 가져와야 하므로 최소 12GB의 저장 공간을 사용할 수 있어야 합니다.

개발 및 테스트에 사용된 최소 PostgreSQL 버전(다음 표 참조)을 사용하는 것을 권장합니다.

GitLab 버전 최소 PostgreSQL 버전1 최대 PostgreSQL 버전2
13.0 11 2
14.0 12.7 2
15.0 12.10 13.x (14.x3)
16.0 13.6 15.x4
17.0 (planned) 14.9 15.x4
  1. PostgreSQL의 작은 릴리스 업그레이드(예: 14.8에서 14.9)는 버그 및 보안 수정만 포함됩니다. 이 표의 패치 수준은 예의주시적인 것이 아닙니다. 알려진 PostgreSQL 버그를 피하기 위해 항상 최신 패치 수준을 배포해야 합니다.
  2. 지정된 최소 버전보다 나중에 PostgreSQL의 주 버전 업그레이드를 실행하려면 Linux 패키지(Omnibus) GitLab이 제공하는 더 최신 버전을 확인하십시오. postgresql-new는 확실히 지원되는 더 나중 버전입니다.
  3. PostgreSQL 14.x는 GitLab 15.11에 대해서만 테스트되었습니다.
  4. GitLab 16.1 및 이후에 대해 테스트되었습니다.

모든 GitLab 데이터베이스에 다음 확장이 로드되어 있는지 확인해야 합니다. 이 요구 사항에 대한 자세한 내용과 문제 해결 방법은 여기에서 확인할 수 있습니다.

확장 최소 GitLab 버전
pg_trgm 8.6
btree_gist 13.1
plpgsql 11.7

다음의 관리형 PostgreSQL 서비스는 호환되지 않아서 사용하면 안 됩니다:

GitLab 버전 관리형 서비스
14.4+ Amazon Aurora (참조 14.4.0)
note
PostgreSQL 9.6 및 10에 대한 지원이 GitLab 13.0에서 제거되었습니다하여 PostgreSQL 11의 개선 사항(예: 파티셔닝)을 활용할 수 있도록 했습니다.

GitLab Geo의 추가 요구 사항

GitLab Geo를 사용하는 경우, 리눅스 패키지를 사용하거나 검증된 클라우드 관리형 인스턴스를 사용하여 인스턴스를 실행하는 것이 강력히 추천됩니다. 와 함께 개발 및 테스트하고 있기 때문입니다. 다른 외부 데이터베이스와의 호환성을 보장할 수 없습니다.

Geo를 실행하기 위한 요구 사항을 확인하는 것이 좋습니다.

운영 체제 로캘 호환성 및 은밀한 인덱스 손상

glibc의 로캘 데이터 변경으로 인해 PostgreSQL 데이터베이스 파일은 서로 다른 운영 체제 릴리스 간에 완전히 호환되지 않습니다.

인덱스 손상을 피하려면 다음 경우에 로캘 호환성을 확인하십시오. - 서버 간에 바이너리 PostgreSQL 데이터를 이동하는 경우. - Linux 배포판을 업그레이드하는 경우. - 제3자 컨테이너 이미지를 업데이트 또는 변경하는 경우.

Gitaly 클러스터 데이터베이스 요구 사항

Gitaly 클러스터 문서에서 더 읽기.

GitLab 데이터베이스 전용 사용

GitLab, Geo, Gitaly 클러스터 또는 다른 구성 요소에 사용되거나 생성된 데이터베이스는 GitLab의 전용으로 사용되어야 합니다. 데이터베이스, 스키마, 사용자 또는 기타 속성에 직접 변경을 가하지 마십시오. GitLab 문서의 절차를 따르거나 GitLab 지원팀 또는 다른 GitLab 엔지니어의 지시를 따를 때를 제외하고요.

  • 기본 GitLab 애플리케이션은 세 개의 스키마를 사용합니다:
    • 기본 public 스키마
    • gitlab_partitions_static (자동으로 생성됨)
    • gitlab_partitions_dynamic (자동으로 생성됨)

    다른 스키마는 수동으로 생성해서는 안 됩니다.

  • GitLab은 Rails 데이터베이스 마이그레이션의 일환으로 새로운 스키마를 생성할 수 있습니다. 이는 GitLab 업그레이드를 수행할 때 발생합니다. GitLab 데이터베이스 계정은 이 작업을 수행하기 위한 액세스가 필요합니다.

  • GitLab은 업그레이드 프로세스 중에 테이블을 생성하고 수정하며, 파티션 된 테이블을 관리하는 표준 운영의 일환으로도 테이블을 생성하고 수정합니다.

  • GitLab 스키마를 수정해서는 안 됩니다(예: 트리거 추가 또는 테이블 수정). 데이터베이스 마이그레이션은 GitLab 코드베이스의 스키마 정의에 따라 테스트됩니다. 스키마가 수정된 경우 GitLab 버전 업그레이드가 실패할 수 있습니다.

Puma 설정

Puma의 권장 설정은 실행되는 인프라에 따라 결정됩니다. 리눅스 패키지는 권장 Puma 설정을 기본값으로 제공합니다. 설치 방법에 관계없이 Puma 설정을 조정할 수 있습니다.

  • 리눅스 패키지를 사용하는 경우, Puma 설정을 변경하는 방법은 Puma 설정을 참조하십시오.
  • GitLab Helm 차트를 사용하는 경우, 웹서비스 차트를 참조하십시오.

Puma 워커

추천하는 워커 수는 다음 중 가장 높은 값으로 계산됩니다:

  • 2
  • CPU 및 메모리 리소스 가용성의 조합(이는 리눅스 패키지에 대해 자동으로 구성됩니다).

예를 들어 다음과 같은 시나리오가 있습니다.

  • 2 코어 / 8GB 메모리를 가진 노드는 2 Puma 워커로 구성되어야 합니다.

    계산 방법: plaintext 다음 중 가장 높은 숫자 2 과 [ 다음 중 가장 낮은 숫자 - 코어 수: 2 - 메모리 제한: (8 - 1.5) = 6.5 ]

    따라서 2와 2 중에서 가장 높은 값은 2입니다.

  • 4 코어 / 4GB 메모리를 가진 노드는 2 Puma 워커로 구성되어야 합니다.

    다음 중 가장 높은 숫자
    2
    과
    [
      다음 중 가장 낮은 숫자
        - 코어 수: 4
        - 메모리 제한: (4 - 1.5) = 2.5
    ]
    

    따라서 2와 2 중에서 가장 높은 값은 2입니다.

  • 4 코어 / 8GB 메모리를 가진 노드는 4 Puma 워커로 구성되어야 합니다.

    다음 중 가장 높은 숫자
    2
    과
    [
      다음 중 가장 낮은 숫자
        - 코어 수: 4
        - 메모리 제한: (8 - 1.5) = 6.5
    ]
    

    따라서 2와 4 중에서 가장 높은 값은 4입니다.

충분한 CPU 및 메모리 용량이 제공되면 Puma 워커 수를 늘릴 수 있습니다. 더 많은 Puma 워커는 일반적으로 응용 프로그램의 응답 시간을 줄이고 병렬 요청을 처리하는 능력을 높이는 데 도움이 됩니다. 인프라에 대한 최적의 설정을 검증하기 위해 테스트를 수행해야 합니다.

Puma 스레드

권장하는 스레드 수는 총 메모리를 포함한 여러 요소에 따라 달라집니다.

  • 운영 체제의 최대 메모리가 2GB인 경우, 권장하는 스레드 수는 1입니다. 더 높은 값은 과도한 스왑 및 성능 저하로 이어집니다.
  • 다른 모든 경우에, 권장하는 스레드 수는 4입니다. Ruby MRI multi-threading 작동 방식 때문에 더 높게 설정하는 것을 권장하지 않습니다.

Puma 당 워커 최대 메모리

기본적으로, 각 Puma 워커는 1.2GB의 메모리로 제한됩니다. Puma 워커의 수를 늘려아 할 경우, 이 메모리 설정을 조정해야 합니다.

Redis

Redis는 모든 사용자 세션과 백그라운드 작업 대기열을 저장합니다.

Redis의 요구 사항은 다음과 같습니다:

  • GitLab 16.0 이후에는 Redis 6.x 또는 7.x가 필요합니다. 그러나 Redis 6.0은 더 이상 지원되지 않으므로 Redis 6.2 이상으로 업그레이드해야 합니다.
  • Redis 클러스터 모드는 지원되지 않습니다. Redis Standalone을 사용해야 하며, HA(고가용성) 여부에 관계없이 사용할 수 있습니다.
  • Redis의 저장 요구 사항은 평균적으로 사용자당 약 25KB 정도입니다.
  • Redis의 방출 모드를 적절하게 설정합니다.

Sidekiq

Sidekiq는 멀티 스레드 프로세스로 백그라운드 작업을 처리합니다. 이 프로세스는 전체 Rails 스택(200MB+)으로 시작하지만 메모리 누수로 인해 시간이 지남에 따라 증가할 수 있습니다. 매우 활발한 서버(청구 가능 사용자 10,000명)의 경우 Sidekiq 프로세스는 1GB 이상의 메모리를 사용할 수 있습니다.

Prometheus 및 해당 익스포터

Prometheus와 그와 관련된 익스포터는 기본적으로 GitLab의 심층 모니터링을 가능하게합니다. 기본 설정으로 이러한 프로세스는 약 200MB의 메모리를 사용합니다.

Prometheus 및 해당 익스포터를 비활성화하거나 자세히 알아보려면 Prometheus 문서를 확인하세요.

GitLab Runner

GitLab Runner를 GitLab을 설치할 예정인 동일한 머신에 설치하는 것을 강력히 권장하지 않습니다. GitLab Runner를 구성하고 CI 환경에서 애플리케이션을 테스트하는 데 사용할 도구에 따라 GitLab Runner는 사용 가능한 메모리의 상당한 양을 소비할 수 있습니다.

이러한 모든 메모리 소비 계산은 GitLab Runner와 GitLab Rails 애플리케이션을 동일한 머신에서 실행하려는 경우 유효하지 않습니다.

참고:
애플리케이션 설치 이후, 안전한 GitLab 설치 유지에 관한 지침을 반드시 읽고 따르세요.