Linux 패키지 설치를 위한 구성 옵션

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

GitLab을 구성하려면 /etc/gitlab/gitlab.rb 파일에서 관련 옵션을 설정하세요.

gitlab.rb.template에는 사용 가능한 옵션의 완전한 목록이 포함되어 있습니다. 새로운 설치에는 템플릿의 모든 옵션이 기본적으로 /etc/gitlab/gitlab.rb에 나열됩니다.

note

/etc/gitlab/gitlab.rb를 편집할 때 제공되는 예제는 항상 인스턴스의 기본 설정을 반영하지 않을 수 있습니다.

기본 설정 목록은 패키지 기본값을 참조하세요.

GitLab을 위한 외부 URL 구성

사용자가 올바른 저장소 복제 링크를 표시하려면 GitLab에 사용자가 저장소에 액세스하는 데 사용하는 URL을 제공해야 합니다. 서버의 IP를 사용할 수 있지만 FQDN(완전한 도메인 이름)을 사용하는 것이 좋습니다. Self-Managed GitLab 인스턴스에서 DNS 사용에 대한 자세한 내용은 DNS 문서를 참조하세요.

외부 URL을 변경하려면:

  1. 선택 사항. 외부 URL을 변경하기 전에 이전에 사용자 정의 홈 페이지 URL 또는 로그아웃 후 경로를 정의했는지 확인하세요. 이러한 설정은 새 외부 URL을 구성한 후 의도하지 않은 리디렉션을 일으킬 수 있습니다. URL을 정의했다면 완전히 제거하세요.

  2. /etc/gitlab/gitlab.rb를 편집하고 external_url을 원하는 URL로 변경하세요: 

     external_url "http://gitlab.example.com"

    선택 사항으로 서버의 IP 주소를 사용할 수도 있습니다: 

     external_url "http://10.0.0.1"

    이전 예에서는 일반 HTTP를 사용했습니다. HTTPS를 사용하려면 SSL 구성 방법을 참조하세요.

  3. GitLab을 다시 구성하세요: 

     sudo gitlab-ctl reconfigure

  4. 선택 사항. 오랫동안 GitLab을 사용한 경우 외부 URL을 변경한 후 Markdown 캐시를 무효화해야 합니다.

설치 시 외부 URL 지정

Linux 패키지를 사용하는 경우 EXTERNAL_URL 환경 변수를 사용하여 최소한의 명령을 사용하여 GitLab 인스턴스를 설정할 수 있습니다. 이 변수가 설정된 경우 EXTERNAL_URL의 값을 gitlab.rb 파일에 external_url로 자동으로 작성합니다.

EXTERNAL_URL 환경 변수는 패키지의 설치 및 업그레이드에만 영향을 미칩니다. 정기 reconfigure 실행 시 /etc/gitlab/gitlab.rb의 값이 사용됩니다.

패키지 업데이트의 일환으로 EXTERNAL_URL 변수가 무심코 설정된 경우 기존 값이 경고 없이 /etc/gitlab/gitlab.rb의 기존 값으로 대체됩니다. 따라서 변수를 전역적으로 설정하지 말고 설치 명령에 명시적으로 전달하는 것이 좋습니다: 

sudo EXTERNAL_URL="https://gitlab.example.com" apt-get install gitlab-ee

GitLab을 위한 상대 URL 구성

note

자체 컴파일(소스) 설치의 경우 별도 문서가 있습니다.

일반적으로 GitLab을 자체(하위) 도메인에 설치하는 것이 좋지만 때로는 불가능한 경우도 있습니다. 이 경우 GitLab을 예를 들어 https://example.com/gitlab로 상대 URL에 설치할 수도 있습니다.

URL을 변경하면 모든 원격 URL도 변경되므로 GitLab 인스턴스를 가리키는 로컬 저장소에서 수동으로 편집해야 합니다.

GitLab에서 상대 URL을 활성화하려면:

  1. /etc/gitlab/gitlab.rb에서 external_url를 설정하세요: 

     external_url "https://example.com/gitlab"

    이 예에서 GitLab이 제공되는 상대 URL은 /gitlab입니다. 필요에 따라 변경하세요.

  2. GitLab을 다시 구성하세요: 

     sudo gitlab-ctl reconfigure

문제가 발생한 경우 문제 해결 섹션을 참조하세요.

비루트 사용자로부터 외부 구성 파일 로드

Linux 패키지 설치는 모든 구성을 /etc/gitlab/gitlab.rb 파일에서 로드합니다. 이 파일은 엄격한 파일 권한을 갖고 있으며 root 사용자가 소유하고 있습니다. 이는 /etc/gitlab/gitlab.rb이 gitlab-ctl reconfigure 실행 중 root 사용자에 의해 Ruby 코드로 실행되기 때문입니다. 즉, /etc/gitlab/gitlab.rb에 쓰기 액세스 권한이 있는 사용자는 root에 의해 코드로 실행되는 구성을 추가할 수 있습니다.

특정 기관에서는 구성 파일에 액세스할 수 있지만 root 사용자로는 접근하지 못할 수 있습니다. 해당 파일의 경로를 지정하여 /etc/gitlab/gitlab.rb에 외부 구성 파일을 포함할 수 있습니다:

  1. /etc/gitlab/gitlab.rb를 편집하세요: 

     from_file "/home/admin/external_gitlab.rb"

  2. GitLab을 다시 구성하세요: 

     sudo gitlab-ctl reconfigure

from_file을 사용할 때:

  • from_file를 사용하여 /etc/gitlab/gitlab.rb에 포함된 코드는 GitLab을 다시 구성할 때 root 권한으로 실행됩니다.
  • from_file 이후에 /etc/gitlab/gitlab.rb에 설정된 모든 구성은 포함된 파일의 구성보다 우선합니다.

파일에서 인증서 읽기

인증서는 별도의 파일로 저장되어 sudo gitlab-ctl reconfigure를 실행할 때 메모리로 로드될 수 있습니다. 인증서를 포함하는 파일은 평문이어야 합니다.

이 예에서는 PostgreSQL 서버 인증서가 /etc/gitlab/gitlab.rb에 직접 복사 및 붙여넣기 대신 파일에서 직접 읽힙니다. 

postgresql['internal_certificate'] = File.read('/path/to/server.crt')

Git 데이터를 대체 디렉터리에 저장하기

기본적으로 Linux 패키지 설치는 Git 저장소 데이터를 /var/opt/gitlab/git-data 아래에 저장합니다. 저장소는 repositories라는 하위 폴더에 저장됩니다.

git-data 상위 디렉터리의 위치를 변경하려면:

  1. /etc/gitlab/gitlab.rb을 편집합니다. 

    git_data_dirs({ "default" => { "path" => "/mnt/nas/git-data" } })

    하나 이상의 Git 데이터 디렉토리를 추가할 수도 있습니다. 

    git_data_dirs({
  "default" => { "path" => "/var/opt/gitlab/git-data" },
  "alternative" => { "path" => "/mnt/nas/git-data" }
})

    대상 디렉터리와 해당 하위 경로 중 어느 것도 심볼릭 링크일 수 없습니다.

  2. GitLab을 다시 구성합니다. 

    sudo gitlab-ctl reconfigure

  3. 선택 사항. /var/opt/gitlab/git-data에 기존의 Git 저장소가 이미 있는 경우, 이를 새 위치로 이동할 수 있습니다.

    1. 이동하는 동안 사용자가 저장소에 쓰지 못하도록 합니다. 

      sudo gitlab-ctl stop

    2. 저장소를 새 위치로 동기화합니다. repositories 뒤에는 슬래시가 아닌 주의합니다. 하지만 git-data 뒤에는 슬래시가 있습니다. 

      sudo rsync -av --delete /var/opt/gitlab/git-data/repositories /mnt/nas/git-data/

    3. 필요한 프로세스를 시작하고 잘못된 권한을 수정하기 위해 구성을 다시 합니다. 

      sudo gitlab-ctl reconfigure

    4. /mnt/nas/git-data/에서 디렉터리 레이아웃을 두 번 확인합니다. 예상되는 출력은 ‘repositories’여야 합니다. 

      sudo ls /mnt/nas/git-data/

    5. GitLab을 시작하고 웹 인터페이스에서 저장소를 탐색할 수 있는지 확인하세요. 

      sudo gitlab-ctl start

Gitaly를 별도의 서버에서 실행 중인 경우 각 Git 데이터 디렉터리에 gitaly_address를 포함하는 것을 잊지 마세요. Gitaly 구성에 대한 자세한 내용은 Gitaly 구성 문서를 참조하세요.

모든 저장소를 이동하려는 것이 아니라 기존 저장소 저장 공간 간에 특정 프로젝트를 이동하려는 경우, 프로젝트 API 편집 엔드포인트를 사용하고 repository_storage 속성을 지정하십시오.

Git 사용자 또는 그룹 이름 변경

경고: 기존 설치의 사용자 또는 그룹을 변경하는 것은 예측할 수 없는 부작용을 일으킬 수 있으므로 권장하지 않습니다.

기본적으로 Linux 패키지 설치는 GitLab Shell 로그인을 위해 사용자 이름인 git, Git 데이터 자체의 소유권, 그리고 웹 인터페이스에서 SSH URL 생성을 위해 git 그룹을 사용합니다. 마찬가지로 git 그룹은 Git 데이터의 그룹 소유권에 사용됩니다.

새 Linux 패키지 설치에서 사용자와 그룹을 변경하려면:

  1. /etc/gitlab/gitlab.rb을 편집합니다. 

    user['username'] = "gitlab"
user['group'] = "gitlab"

  2. GitLab을 다시 구성합니다. 

    sudo gitlab-ctl reconfigure

기존 설치의 사용자 이름을 변경하는 경우 구성 실행은 중첩된 디렉터리의 소유권을 변경하지 않으므로 수동으로 수행해야 합니다.

적어도 저장소와 업로드 디렉터리의 소유권을 변경해야 합니다. 

sudo chown -R gitlab:gitlab /var/opt/gitlab/git-data/repositories
sudo chown -R gitlab:gitlab /var/opt/gitlab/gitlab-rails/uploads

숫자 사용자 및 그룹 식별자 지정

Linux 패키지 설치는 GitLab, PostgreSQL, Redis, NGINX 등의 사용자를 생성합니다. 이러한 사용자의 숫자 식별자를 지정하려면:

  1. 이전 사용자 및 그룹 식별자를 필요한 경우 나중에 사용할 수 있도록 기록합니다. 

    sudo cat /etc/passwd

  2. /etc/gitlab/gitlab.rb을 편집하고 원하는 식별자를 변경합니다. 

    user['uid'] = 1234
user['gid'] = 1234
postgresql['uid'] = 1235
postgresql['gid'] = 1235
redis['uid'] = 1236
redis['gid'] = 1236
web_server['uid'] = 1237
web_server['gid'] = 1237
registry['uid'] = 1238
registry['gid'] = 1238
mattermost['uid'] = 1239
mattermost['gid'] = 1239
prometheus['uid'] = 1240
prometheus['gid'] = 1240

  3. GitLab을 중지한 다음 다시 구성하고 시작합니다. 

    sudo gitlab-ctl stop
sudo gitlab-ctl reconfigure
sudo gitlab-ctl start

  4. 선택 사항. user['uid'] 및 user['gid']를 변경하는 경우, Linux 패키지에서 직접 관리되지 않는 파일(예: 로그)의 uid/gid를 업데이트해야 합니다. 

    find /var/log/gitlab -uid <old_uid> | xargs -I:: chown git ::
find /var/log/gitlab -gid <old_uid> | xargs -I:: chgrp git ::
find /var/opt/gitlab -uid <old_uid> | xargs -I:: chown git ::
find /var/opt/gitlab -gid <old_uid> | xargs -I:: chgrp git ::

사용자 및 그룹 계정 관리 비활성화

기본적으로 Linux 패키지 설치는 시스템 사용자 및 그룹 계정을 생성하고 정보를 최신 상태로 유지합니다. 이러한 시스템 계정은 패키지의 다양한 구성 요소를 실행합니다. 대부분의 사용자는 이 동작을 변경할 필요가 없습니다. 그러나 시스템 계정이 LDAP 등 다른 소프트웨어에 의해 관리되는 경우 GitLab 패키지에 의한 계정 관리를 비활성화해야 할 수 있습니다.

기본적으로 Linux 패키지 설치는 다음 사용자 및 그룹이 존재하는 것으로 예상합니다:

Linux 사용자 및 그룹 필수 여부 설명 기본 홈 디렉토리 기본 셸
git 예 GitLab 사용자/그룹 /var/opt/gitlab bin/sh
gitlab-www 예 웹 서버 사용자/그룹 /var/opt/gitlab/nginx /bin/false
gitlab-prometheus 예 Prometheus 모니터링 및 여러 수출용 Prometheus 사용자/그룹 /var/opt/gitlab/prometheus /bin/sh
gitlab-redis 패키지화된 Redis 사용 시에만 GitLab을 위한 Redis 사용자/그룹 /var/opt/gitlab/redis /bin/false
gitlab-psql 패키지화된 PostgreSQL 사용 시에만 PostgreSQL 사용자/그룹 /var/opt/gitlab/postgresql /bin/sh
gitlab-consul GitLab Consul 사용 시에만 GitLab Consul 사용자/그룹 /var/opt/gitlab/consul /bin/sh
registry GitLab Registry 사용 시에만 GitLab Registry 사용자/그룹 /var/opt/gitlab/registry /bin/sh
mattermost GitLab Mattermost 사용 시에만 GitLab Mattermost 사용자/그룹 /var/opt/gitlab/mattermost /bin/sh

사용자 및 그룹 계정 관리를 비활성화하려면:

  1. /etc/gitlab/gitlab.rb 파일 편집: 

    manage_accounts['enable'] = false

  2. 선택 사항. 다른 사용자/그룹 이름을 사용할 수도 있지만, 사용자/그룹 세부 정보를 지정해야 합니다: 

    # GitLab
user['username'] = "git"
user['group'] = "git"
user['shell'] = "/bin/sh"
user['home'] = "/var/opt/custom-gitlab"

# 웹 서버
web_server['username'] = 'webserver-gitlab'
web_server['group'] = 'webserver-gitlab'
web_server['shell'] = '/bin/false'
web_server['home'] = '/var/opt/gitlab/webserver'

# 프로메테우스
prometheus['username'] = 'gitlab-prometheus'
prometheus['group'] = 'gitlab-prometheus'
prometheus['shell'] = '/bin/sh'
prometheus['home'] = '/var/opt/gitlab/prometheus'

# Redis (외부 Redis 사용 시 불필요)
redis['username'] = "redis-gitlab"
redis['group'] = "redis-gitlab"
redis['shell'] = "/bin/false"
redis['home'] = "/var/opt/redis-gitlab"

# PostgreSQL (외부 PostgreSQL 사용 시 불필요)
postgresql['username'] = "postgres-gitlab"
postgresql['group'] = "postgres-gitlab"
postgresql['shell'] = "/bin/sh"
postgresql['home'] = "/var/opt/postgres-gitlab"

# Consul
consul['username'] = 'gitlab-consul'
consul['group'] = 'gitlab-consul'
consul['dir'] = "/var/opt/gitlab/registry"

# 레지스트리
registry['username'] = "registry"
registry['group'] = "registry"
registry['dir'] = "/var/opt/gitlab/registry"

# Mattermost
mattermost['username'] = 'mattermost'
mattermost['group'] = 'mattermost'
mattermost['home'] = '/var/opt/gitlab/mattermost'

  3. GitLab 다시 구성: 

    sudo gitlab-ctl reconfigure

사용자의 홈 디렉토리 이동

GitLab 사용자의 경우, 성능을 위해 홈 디렉토리를 로컬 디스크에 설정하는 것이 좋습니다. NFS와 같은 공유 스토리지에 설정하면 Git 요청이 Git 구성을 읽기 위해 다른 네트워크 요청을 수행해야 하며, 이는 Git 작업의 지연을 증가시킵니다.

기존 홈 디렉토리를 이동하려면 GitLab 서비스를 중지해야 하며 일시적인 다운타임이 필요합니다:

  1. GitLab 중지: 

    sudo gitlab-ctl stop

  2. runit 서버 중지: 

    sudo systemctl stop gitlab-runsvdir

  3. 홈 디렉토리 변경: 

    sudo usermod -d /path/to/home <username>

    기존 데이터가 있는 경우 새 위치로 수동으로 복사하거나 rsync해야 합니다:

  4. /etc/gitlab/gitlab.rb 파일 편집: 

    user['home'] = "/var/opt/custom-gitlab"

  5. runit 서버 시작: 

    sudo systemctl start gitlab-runsvdir

  6. GitLab 다시 구성: 

    sudo gitlab-ctl reconfigure

스토리지 디렉터리 관리 비활성화

Linux 패키지는 올바른 소유권 및 권한으로 모든 필요한 디렉터리를 만들고 최신 상태를 유지합니다.

일부 디렉터리에는 많은 양의 데이터가 저장되어 있으므로 특정 설정에서는 해당 디렉터리가 NFS(또는 기타) 공유에 마운트되어 있을 수 있습니다.

일부 유형의 마운트는 루트 사용자(초기 설정의 기본 사용자)에 의한 디렉터리의 자동 생성을 허용하지 않습니다. 예를 들어 root_squash가 공유에 활성화된 NFS입니다. 이를 해결하기 위해 Linux 패키지는 해당 디렉터리를 소유자 사용자로 생성하려고 시도합니다.

/etc/gitlab 디렉토리 관리 비활성화

만약 /etc/gitlab 디렉토리를 마운트했다면 해당 디렉토리의 관리를 중지할 수 있습니다:

  1. /etc/gitlab/gitlab.rb를 편집합니다: 

    manage_storage_directories['manage_etc'] = false

  2. GitLab을 재구성합니다: 

    sudo gitlab-ctl reconfigure

/var/opt/gitlab 디렉토리 관리 비활성화

모든 GitLab 스토리지 디렉터리를 개별적인 마운트로 마운트하는 경우 스토리지 디렉터리의 관리를 완전히 비활성화해야 합니다.

Linux 패키지 설치는 이러한 디렉터리가 파일 시스템에 존재할 것으로 예상합니다. 이러한 설정이 설정된 경우 올바른 권한을 가진 디렉터리를 생성하는 것은 사용자에게 달려 있습니다.

이 설정을 활성화하면 다음 디렉터리가 생성되지 않습니다:

기본 위치 권한 소유권 용도
/var/opt/gitlab/git-data 0700 git:git 저장소 디렉터리 보유
/var/opt/gitlab/git-data/repositories 2770 git:git Git 저장소 보유
/var/opt/gitlab/gitlab-rails/shared 0751 git:gitlab-www 대규모 오브젝트 디렉터리 보유
/var/opt/gitlab/gitlab-rails/shared/artifacts 0700 git:git CI artifacts 보유
/var/opt/gitlab/gitlab-rails/shared/external-diffs 0700 git:git 외부 병합 요청 차이점 보유
/var/opt/gitlab/gitlab-rails/shared/lfs-objects 0700 git:git LFS 오브젝트 보유
/var/opt/gitlab/gitlab-rails/shared/packages 0700 git:git 패키지 저장소 보유
/var/opt/gitlab/gitlab-rails/shared/dependency_proxy 0700 git:git 의존성 프록시 보유
/var/opt/gitlab/gitlab-rails/shared/terraform_state 0700 git:git Terraform 상태 보유
/var/opt/gitlab/gitlab-rails/shared/ci_secure_files 0700 git:git 업로드된 보안 파일 보유
/var/opt/gitlab/gitlab-rails/shared/pages 0750 git:gitlab-www 사용자 페이지 보유
/var/opt/gitlab/gitlab-rails/uploads 0700 git:git 사용자 첨부 파일 보유
/var/opt/gitlab/gitlab-ci/builds 0700 git:git CI 빌드 로그 보유
/var/opt/gitlab/.ssh 0700 git:git 인증키 보유

스토리지 디렉터리 관리를 비활성화하려면:

  1. /etc/gitlab/gitlab.rb를 편집합니다: 

    manage_storage_directories['enable'] = false

  2. GitLab을 재구성합니다: 

    sudo gitlab-ctl reconfigure

특정 파일 시스템이 마운트된 후에 Linux 패키지 설치 서비스 시작

특정 파일 시스템이 마운트되기 전에 Linux 패키지 설치 서비스(NGINX, Redis, Puma 등)를 시작하지 않으려면 high_availability['mountpoint'] 설정을 지정할 수 있습니다:

  1. /etc/gitlab/gitlab.rb를 편집합니다: 

    # /var/opt/gitlab이 마운트될 때까지 기다립니다
high_availability['mountpoint'] = '/var/opt/gitlab'

  2. GitLab을 재구성합니다: 

    sudo gitlab-ctl reconfigure

    참고: 마운트 지점이 존재하지 않으면 GitLab이 재구성에 실패합니다.

런타임 디렉터리 구성

Prometheus 모니터링이 활성화되면 GitLab Exporter는 각 Puma 프로세스(Rails 메트릭)를 측정합니다. 각 Puma 프로세스는 컨트롤러 요청마다 메트릭 파일을 임시 위치에 기록해야 합니다. 그런 다음 Prometheus는 이러한 파일을 수집하고 그 값들을 처리합니다.

디스크 I/O를 생성하지 않기 위해 Linux 패키지는 런타임 디렉터리를 사용합니다.

reconfigure 중, 패키지는 /run이 tmpfs 마운트인지 확인합니다. 그렇지 않으면 다음 경고가 표시되고 Rails 메트릭이 비활성화됩니다: 

런타임 디렉터리 '/run'은(는) tmpfs 마운트가 아닙니다.

다시 Rails 메트릭을 활성화하려면:

  1. /etc/gitlab/gitlab.rb를 편집하여 tmpfs 마운트를 생성합니다 (구성에 =이 없음에 유의): 

    runtime_dir '/tmpfs/경로'

  2. GitLab을 재구성합니다: 

    sudo gitlab-ctl reconfigure

실패한 인증 금지 구성

Git 및 컨테이너 레지스트리에 대해 실패한 인증 금지를 구성할 수 있습니다. 클라이언트가 금지되면 403 오류 코드가 반환됩니다.

다음 설정을 구성할 수 있습니다:

설정 설명
enabled 기본적으로 false입니다. Git 및 레지스트리 인증 금지를 활성화하려면 이 값을 true로 설정하세요.
ip_whitelist 차단하지 말아야 하는 IP입니다. Ruby 배열의 문자열로 포맷해야 합니다. 단일 IP 또는 CIDR 표기법을 사용할 수 있습니다. 예를 들어, ["127.0.0.1", "127.0.0.2", "127.0.0.3", "192.168.0.1/24"].
maxretry 지정된 시간 내에 요청을 할 수 있는 최대 횟수입니다.
findtime IP에 대한 실패한 요청이 거부 목록에 추가되기 전에 카운트될 수 있는 최대 시간(초)입니다.
bantime IP가 차단되는 총 시간(초)입니다.

Git 및 컨테이너 레지스트리 인증 금지를 구성하려면:

  1. /etc/gitlab/gitlab.rb를 편집하세요: 

    gitlab_rails['rack_attack_git_basic_auth'] = {
  'enabled' => true,
  'ip_whitelist' => ["127.0.0.1"],
  'maxretry' => 10, # IP 당 Git HTTP 인증 시도 횟수 제한
  'findtime' => 60, # IP 당 인증 시도 카운터를 60초 후에 재설정
  'bantime' => 3600 # 너무 많은 인증 시도 후 IP를 1시간(3600초) 동안 차단
}

  2. GitLab을 다시 구성하세요: 

    sudo gitlab-ctl reconfigure

설치 중 자동 캐시 정리 비활성화

대규모 GitLab 설치의 경우 rake cache:clear 작업을 실행하지 않아도 되는 경우가 있습니다. 이 작업은 오랜 시간이 걸릴 수 있습니다. 기본적으로 캐시 정리 작업은 자동으로 재구성 중에 실행됩니다.

설치 중 자동 캐시 정리를 비활성화하려면:

  1. /etc/gitlab/gitlab.rb를 편집하세요: 

    # 이 기능은 RAILS 환경을 로딩하는 데 많은 시간이 소요되는 대규모 gitlab 배포에서 사용되는 고급 기능입니다.
gitlab_rails['rake_cache_clear'] = false

  2. GitLab을 다시 구성하세요: 

    sudo gitlab-ctl reconfigure

Sentry를 사용한 오류 보고 및 로깅

경고: GitLab 17.0부터 Sentry 버전 21.5.0 이상만 지원됩니다. 호스팅하는 Sentry 인스턴스의 이전 버전을 사용하는 경우 GitLab 환경에서 계속 오류를 수집하려면 Sentry를 업그레이드해야 합니다.

Sentry는 오픈 소스 오류 보고 및 로깅 도구로, SaaS(https://sentry.io) 또는 셀프 호스팅으로 사용할 수 있습니다.

Sentry를 구성하려면:

  1. Sentry에서 프로젝트를 만듭니다.
  2. 만든 프로젝트의 데이터 소스 이름(DSN)을 찾습니다.

  3. /etc/gitlab/gitlab.rb를 편집하세요: 

    gitlab_rails['sentry_enabled'] = true
gitlab_rails['sentry_dsn'] = 'https://<public_key>@<host>/<project_id>'            # Rails SDK에서 사용하는 값
gitlab_rails['sentry_clientside_dsn'] = 'https://<public_key>@<host>/<project_id>' # 브라우저 JavaScript SDK에서 사용하는 값
gitlab_rails['sentry_environment'] = 'production'

    Sentry 환경은 예를 들어 랩, 개발, 스테이징 및 프로덕션과 같은 여러 배포된 GitLab 환경에서 오류 및 이슈를 추적하는 데 사용할 수 있습니다.

  4. 선택 사항. 특정 서버에서 보낸 모든 이벤트에 사용자 지정 Sentry 태그를 설정하려면 GITLAB_SENTRY_EXTRA_TAGS 환경 변수를 설정할 수 있습니다. 이 변수는 그 서버의 모든 예외에 대해 Sentry로 전달될 태그를 나타내는 JSON으로 인코딩된 해시입니다.

    예를 들어, 다음을 설정하면: 

    gitlab_rails['env'] = {
  'GITLAB_SENTRY_EXTRA_TAGS' => '{"stage": "main"}'
}

    stage 태그를 값 main과 함께 추가할 것입니다.

  5. GitLab을 다시 구성하세요: 

    sudo gitlab-ctl reconfigure

콘텐츠 전송 네트워크(포괄적)

콘텐츠 전송 네트워크(CDN) 또는 에셋 호스트를 사용하여 정적 에셋을 서비스합니다. gitlab_rails['cdn_host']를 사용합니다. 이것은 레일즈 에셋 호스트를 구성합니다.

CDN/에셋 호스트를 설정하려면:

  1. /etc/gitlab/gitlab.rb을 편집합니다: 

    gitlab_rails['cdn_host'] = 'https://mycdnsubdomain.fictional-cdn.com'

  2. GitLab을 다시 구성합니다: 

    sudo gitlab-ctl reconfigure

공통 서비스를 에셋 호스트로 구성하는 추가 문서는 이 이슈에서 추적됩니다.

컨텐츠 보안 정책 설정

콘텐츠 보안 정책(CSP)을 설정하면 JavaScript 교차 사이트 스크립팅(XSS) 공격을 방지할 수 있습니다. 자세한 내용은 모질라 CSP 문서를 참조하세요.

GitLab 12.2에서 CSP 및 인라인 JavaScript를 사용한 nonce-source를 지원하도록 추가되었습니다. 이것은 아직 기본으로 구성되지는 않았습니다.

참고: CSP 규칙을 부적절하게 구성하면 GitLab의 올바른 작동을 방해할 수 있습니다. 정책을 전파하기 전에 report_only를 true로 변경하여 구성을 테스트하는 것이 좋습니다.

CSP를 추가하려면:

  1. /etc/gitlab/gitlab.rb을 편집합니다: 

    gitlab_rails['content_security_policy'] = {
    enabled: true,
    report_only: false
}

    GitLab은 CSP에 대해 안전한 기본값을 자동으로 제공합니다. 지시어에 대해 <default_value> 값을 명시적으로 설정하는 것은 값을 설정하지 않는 것과 동등하며 기본값을 사용합니다.

    사용자 정의 CSP를 추가하려면: 

    gitlab_rails['content_security_policy'] = {
    enabled: true,
    report_only: false,
    directives: {
      default_src: "'none'",
      script_src: "https://example.com"
    }
}

    GitLab 14.9 이상에서는, 명시적으로 구성되지 않은 지시어에 대해 안전한 기본값이 사용됩니다.

    CSP 지시어를 해제하려면 값을 false로 설정합니다.

  2. GitLab을 다시 구성합니다: 

    sudo gitlab-ctl reconfigure

설치 시 초기 루트 암호 설정

관리자 사용자 root의 초기 암호는 설치 시 설정할 수 있습니다. 자세한 내용은 초기 암호 설정을 참조하세요.

호스트 헤더 공격 방지를 위한 허용된 호스트 설정

의도된 것과 다른 호스트 헤더를 GitLab이 받아들이는 것을 방지하려면:

  1. /etc/gitlab/gitlab.rb을 편집합니다: 

    gitlab_rails['allowed_hosts'] = ['gitlab.example.com']

  2. GitLab을 다시 구성합니다: 

    sudo gitlab-ctl reconfigure

allowed_hosts를 구성하지 않는 것으로 인해 GitLab에서 발생하는 알려진 보안 문제는 없지만 잠재적인 HTTP Host 헤더 공격에 대한 방어를 위해 권장됩니다.

Apache와 같은 사용자 정의 외부 프록시를 사용하는 경우, 외부 프록시에 로컬호스트 주소 또는 이름(localhost 또는 127.0.0.1)를 추가해야 할 수 있습니다. 외부 프록시에 HTTP Host 헤더 공격을 완화하기 위한 필터를 추가해야 합니다. 

gitlab_rails['allowed_hosts'] = ['gitlab.example.com', '127.0.0.1', 'localhost']

평문 저장소 없이 구성 요소에 민감한 구성 제공

일부 구성 요소는 gitlab.rb에서 extra_config_command 옵션을 노출합니다. 이를 통해 평문 저장소에서 가져오는 대신 외부 스크립트가 비밀을 동적으로 제공할 수 있습니다.

사용 가능한 옵션은:

gitlab.rb 설정 책임
gitlab_rails['redis_extra_config_command'] GitLab Rails 애플리케이션이 사용하는 Redis 구성 파일(resque.yml, redis.yml, redis.<redis_instance>.yml 파일)에 추가 구성을 제공합니다.
gitlab_rails['db_extra_config_command'] GitLab Rails 애플리케이션이 사용하는 DB 구성 파일(database.yml)에 추가 구성을 제공합니다.
gitlab_kas['extra_config_command'] Kubernetes용 GitLab 에이전트 서버에 추가 구성을 제공합니다 (KAS).
gitlab_workhorse['extra_config_command'] GitLab Workhorse에 추가 구성을 제공합니다.
gitlab_exporter['extra_config_command'] GitLab Exporter에 추가 구성을 제공합니다.

이러한 옵션 중 하나에 할당된 값은 표준 출력으로 필요한 형식에 민감한 구성을 쓰는 실행 가능한 스크립트의 절대 경로여야 합니다. 구성 요소는:

  1. 제공된 스크립트를 실행합니다.
  2. 사용자 및 기본 구성 파일이 설정한 값을 제공된 스크립트가 내보낸 값으로 바꿉니다.

클라이언트 구성 요소에 Redis 암호 제공

예를 들어, 아래 스크립트 및 gitlab.rb 스니펫을 사용하여 Redis에 연결해야 하는 구성 요소에 대한 Redis 서버의 암호를 지정할 수 있습니다.

  1. 다음 스크립트를 /opt/generate-redis-conf로 저장합니다. 

    #!/opt/gitlab/embedded/bin/ruby

require 'json'
require 'yaml'

class RedisConfig
  REDIS_PASSWORD = `echo "toomanysecrets"`.strip # Redis 암호를 가져오기 위해 역따옴표 안에 있는 명령을 변경하세요

  class << self
    def rails
      puts YAML.dump({
        'password' => REDIS_PASSWORD
      })
    end

    def kas
      puts YAML.dump({
        'redis' => {
          'password' => REDIS_PASSWORD
        }
      })
    end

    def workhorse
      puts JSON.dump({
        redis: {
          password: REDIS_PASSWORD
        }
      })
    end

    def gitlab_exporter
      puts YAML.dump({
        'probes' => {
          'sidekiq' => {
            'opts' => {
              'redis_password' => REDIS_PASSWORD
            }
          }
        }
      })
    end
  end
end

def print_error_and_exit
  $stdout.puts "Usage: redis_credentials <COMPONENT>"
  $stderr.puts "Supported components are: rails, kas, workhorse, gitlab_exporter"

  exit 1
end

print_error_and_exit if ARGV.length != 1

component = ARGV.shift
begin
  RedisConfig.send(component.to_sym)
rescue NoMethodError
  print_error_and_exit
end

  2. 위에 생성한 스크립트가 실행 가능한지 확인합니다. 

    chmod +x /opt/generate-redis-conf

  3. 아래 스니펫을 /etc/gitlab/gitlab.rb에 추가합니다. 

    gitlab_rails['redis_extra_config_command'] = '/opt/generate-redis-conf rails'
gitlab_workhorse['extra_config_command'] = '/opt/generate-redis-conf workhorse'
gitlab_kas['extra_config_command'] = '/opt/generate-redis-conf kas'
gitlab_exporter['extra_config_command'] = '/opt/generate-redis-conf gitlab_exporter'

  4. sudo gitlab-ctl reconfigure를 실행합니다.

GitLab Rails에 PostgreSQL 사용자 암호 제공

예를 들어, 아래 스크립트 및 구성을 사용하여 GitLab Rails가 PostgreSQL 서버에 연결할 때 사용해야 하는 암호를 제공할 수 있습니다.

  1. 다음 스크립트를 /opt/generate-db-config로 저장합니다. 

    #!/opt/gitlab/embedded/bin/ruby

require 'yaml'

db_password = `echo "toomanysecrets"`.strip # 역따옴표 안에 있는 명령을 변경하여 DB 암호를 가져옵니다.

puts YAML.dump({
 'main' => {
   'password' => db_password
 },
 'ci' => {
   'password' => db_password
 }
})

  2. 위에 생성한 스크립트가 실행 가능한지 확인합니다. 

    chmod +x /opt/generate-db-config

  3. 아래 스니펫을 /etc/gitlab/gitlab.rb에 추가합니다. 

    gitlab_rails['db_extra_config_command'] = '/opt/generate-db-config'

  4. sudo gitlab-ctl reconfigure를 실행합니다.

관련 주제

문제 해결

상대 URL 문제 해결

상대 URL 구성으로 이동한 후 GitLab 자산에 문제가 있음을 알게 되면(예: 이미지가 없거나 응답이 없는 구성 요소), Fronend 라벨이 붙은 이슈를 GitLab에 등록해 주세요.

Mixlib::ShellOut::ShellCommandFailed: linux_user[GitLab 사용자 및 그룹]

사용자의 홈 디렉터리를 이동할 때 runit 서비스가 중지되지 않았거나 사용자의 홈 디렉터리가 수동으로 이동되지 않으면 GitLab이 재구성하는 동안 오류가 발생할 수 있습니다: 

account[GitLab 사용자 및 그룹] (gitlab::users line 28)에 오류가 발생했습니다: Mixlib::ShellOut::ShellCommandFailed: linux_user[GitLab 사용자 및 그룹] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/package/resources/account.rb line 51)에 오류가 발생했습니다: Mixlib::ShellOut::ShellCommandFailed: [0]으로 종료하는 것을 예상했지만 '8'을 받았습니다
---- ["usermod", "-d", "/var/opt/gitlab", "git"]를 실행하는 도중 출력 ----
STDOUT:
STDERR: 사용자 git 현재 프로세스 1234에서 사용 중
---- ["usermod", "-d", "/var/opt/gitlab", "git"]를 실행한 결과는 8입니다

홈 디렉터리를 이동하기 전에 runit을 중지해야 합니다.

GitLab은 Git 사용자 또는 그룹 이름을 변경한 후 502로 응답함

기존 설치에서 Git 사용자 또는 그룹 이름을 변경한 경우 여러 부작용을 일으킬 수 있습니다.

파일에 액세스할 수 없는 오류를 확인하고 권한을 수정하려면: 

gitlab gitlab-ctl tail -f