설치 시스템 요구 사항

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

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

하드웨어 요구 사항

리포지터리

필요한 하드 드라이브 공간은 주로 GitLab에 저장하려는 리포지터리의 크기에 따라 달라지지만, 지침으로 모든 리포지터리가 차지하는 공간만큼의 여유 공간을 확보해야 합니다.

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

미래에 하드 드라이브 공간을 확장하기 위해 유연성을 가지려면 논리 볼륨 관리(LVM)을 사용하여 추가 하드 드라이브를 추가할 수 있도록 마운트하는 것을 고려해보세요.

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

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

note
파일 시스템의 성능은 GitLab의 전반적인 성능에 영향을 줄 수 있기 때문에, 저장 공간으로 클라우드 기반 파일 시스템 사용을 권장하지 않습니다.

CPU

CPU 요구 사항은 사용자 수 및 예상 작업량에 따라 다릅니다. 작업량은 사용자의 활동, 자동화 사용량, 미러링 및 리포지터리/변경 크기와 같은 요인에 영향을 받습니다.

다음은 몇 가지 예제 GitLab 사용자 규모를 위한 권장 최소 CPU 하드웨어 안내입니다.

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

메모리

메모리 요구 사항은 사용자 수 및 예상 작업량에 따라 다릅니다. 작업량은 사용자의 활동, 자동화 사용량, 미러링 및 리포지터리/변경 크기와 같은 요인에 영향을 받습니다.

다음은 몇 가지 예제 GitLab 사용자 규모를 위한 권장 최소 메모리 하드웨어 안내입니다.

  • 4GB RAM필수 최소 메모리 크기이며 최대 500명의 사용자를 지원합니다.
  • 8GB RAM은 최대 1000명의 사용자를 지원합니다.
  • 더 많은 사용자인 경우? 참조 아키텍처 페이지를 확인하세요.

작은 설치에서는 다음을 해야 합니다:

  • 사용 가능한 RAM이 충분하더라도 서버에 적어도 2GB의 스왑을 설정해야 합니다. 스왑을 보유하고 있으면 사용 가능한 메모리가 변경되더라도 오류가 발생할 가능성을 줄일 수 있습니다.
  • 스왑을 사용 가능하게 유지하면서 RAM을 최대한 활용하려면 커널의 swappiness 설정을 10과 같이 낮은 값으로 구성해야 합니다.

참조 아키텍처를 따르는 대규모 설치의 경우, 스왑을 구성하지 말아야 합니다.

note
과도한 스왑은 원치 않으며 성능을 저하시키지만, 메모리가 부족한 경우에 매우 중요한 마지노출입니다. OS 업데이트나 동일한 호스트의 다른 서비스와 같은 예상치 못한 시스템 부하 중에는 최대 메모리 부하가 평균보다 훨씬 높을 수 있습니다. 충분한 스왑을 보유하면 Linux OOM 킬러가 잠재적으로 중요한 프로세스(예: PostgreSQL)를 무단으로 종료하는 것을 피할 수 있어 치명적인 결과를 가져올 수 있는 상황에서 도움이 됩니다.

데이터베이스

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

PostgreSQL 요구 사항

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

개발 및 테스트에 사용된 최소 PostgreSQL 버전을 사용하는 것을 강력히 권장합니다. 다음은 최소 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 패키지(옴니버스) 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
GitLab 13.0에서 PostgreSQL 9.6 및 10의 지원이 제거되었습니다. 따라서 GitLab은 분할과 같은 PostgreSQL 11 개선 사항에서 이점을 얻을 수 있습니다.

GitLab Geo의 추가 요구 사항

만약 GitLab Geo를 사용 중이라면, 우리는 Linux 패키지를 사용하거나 검증된 클라우드 관리 인스턴스를 사용하여 설치하는 것을 강력히 권장합니다. 특정한 것을 기반으로 개발 및 테스트하고 있기 때문에, 다른 외부 데이터베이스와의 호환성을 보장할 수 없습니다.

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

운영 체제 로캘 호환성 및 silent index corruption

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

인덱스 손상을 피하려면 다음 경우에 로캘 호환성을 확인하세요.

  • 이진 PostgreSQL 데이터를 서버 간에 이동할 때
  • Linux 배포판을 업그레이드할 때
  • 서드 파티 컨테이너 이미지를 업데이트하거나 변경할 때

Gitaly Cluster 데이터베이스 요구 사항

Gitaly Cluster 문서에서 더 읽기.

GitLab 데이터베이스의 독점적 사용

GitLab, Geo, Gitaly Cluster 또는 다른 컴포넌트에 대해 생성 또는 사용된 데이터베이스는 GitLab의 독점적 사용을 위해 사용되어야 합니다. GitLab 문서의 절차를 따르거나 GitLab 지원 또는 다른 GitLab 엔지니어들의 지시 사항을 따를 때를 제외하고는 데이터베이스, 스키마, 사용자 또는 기타 속성을 직접 수정하지 마십시오.

  • 기본적으로 GitLab 앱은 세 개의 스키마를 사용합니다:

    • 기본 public 스키마
    • gitlab_partitions_static (자동으로 생성됨)
    • gitlab_partitions_dynamic (자동으로 생성됨)

    다른 스키마는 매뉴얼으로 생성되어서는 안 됩니다.

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

  • GitLab은 업그레이드 프로세스 중에 테이블을 생성하고 수정하며, 또한 파티션 된 테이블을 관리하기 위한 표준 작업의 일환으로 테이블을 만들고 수정합니다.

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

Puma 설정

Puma의 권장 설정은 실행 중인 인프라에 의해 결정됩니다. Linux 패키지의 기본값은 권장 Puma 설정입니다. 설치 방법에 관계 없이 Puma 설정을 조정할 수 있습니다:

  • Linux 패키지를 사용하는 경우 Puma 설정에서 Puma 설정을 변경하는 방법에 대한 지침을 확인하세요.
  • GitLab Helm 차트를 사용하는 경우, webservice 차트를 참조하세요.

Puma 워커들

권장 워커 수는 다음 중 가장 높은 값으로 결정됩니다:

  • 2
  • CPU 및 메모리 리소스 가용성의 조합(이는 Linux 패키지에 자동으로 구성된 방법을 확인하세요).

예를 들어 다음과 같은 상황을 고려해 보세요:

  • 코어가 2 개 / 메모리 용량이 8GB인 노드는 2개의 Puma 워커로 설정되어야 합니다.

    다음과 같이 계산됩니다:

    다음 중에서 가장 높은 수
    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 멀티 스레딩 작동 방식 때문에 이를 더 높게 설정하는 것을 권장하지 않습니다.

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 사용이 필요하며, 이중화 여부에 관계없이 사용할 수 있습니다.
  • Redis에 대한 저장 요구 사항은 평균적으로 사용자당 약 25KB 정도입니다.
  • Redis 대탈출 모드가 적절히 설정되어 있어야 합니다.

Sidekiq

Sidekiq는 멀티 스레드 프로세스로 백그라운드 작업을 처리합니다. 이 프로세스는 전체 Rails 스택(200 MB+)으로 시작하지만 메모리 누수로 인해 시간이 지남에 따라 증가할 수 있습니다. 매우 활발한 서버(청구 가능한 사용자 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 Runner와 함께 쉘 실행기를 사용할 계획이라면 더더욱 그렇습니다.

CI 기능을 사용할 계획이라면 각 GitLab Runner에 별도의 기기를 사용하는 것이 좋습니다. GitLab Runner 서버 요구 사항은 다음에 따라 달라집니다:

  • GitLab Runner에서 구성한 실행기의 유형
  • 빌드 작업을 실행하는 데 필요한 리소스
  • 작업 병렬성 설정

작업의 성격이 각각의 사용 사례에 따라 다르기 때문에 최적의 설정을 얻기 위해 작업 병렬성을 조정하면서 실험해야 합니다.

참고로, Linux용 SaaS 러너는 다음과 같이 구성됩니다:

  • 1 vCPU
  • 3.75GB의 RAM으로 단일 작업단일 인스턴스에서 실행됩니다.

지원되는 웹 브라우저

caution
GitLab 13.0 (2020년 5월)부터는 인터넷 익스플로러 11에 대한 공식 지원이 제거되었습니다.

GitLab은 다음과 같은 웹 브라우저를 지원합니다:

디렉터리에 있는 웹 브라우저에 대해 GitLab은 다음을 지원합니다:

  • 브라우저의 현재 및 이전 주요 버전
  • 지원되는 주요 버전의 현재 부 버전
note
우리는 브라우저에서 JavaScript를 비활성화한 GitLab을 실행하는 것을 지원하지 않으며 앞으로도 그러한 지원 계획이 없습니다. 이는 JavaScript를 광범위하게 사용하는 이슈 보드와 같은 기능이 있기 때문입니다.

보안

설치 후, GitLab 설치의 보안 유지 관리에 대한 지침을 반드시 읽고 따르십시오.