GitLab의 외부 URL 구성
- 설치 시 외부 URL 지정
GitLab의 상대 URL 구성
비루트 사용자로부터 외부 구성 파일 로드하기
파일에서 인증서 읽기
대체 디렉토리에 Git 데이터 저장
Git 사용자 또는 그룹 이름 변경
숫자 사용자 및 그룹 식별자 지정
사용자 및 그룹 계정 관리 비활성화
사용자 홈 디렉토리 이동
스토리지 디렉토리 관리 비활성화
- /etc/gitlab 디렉토리 관리 비활성화
- /var/opt/gitlab 디렉토리 관리 비활성화
주어진 파일 시스템이 마운트된 후에만 Linux 패키지 설치 서비스를 시작하십시오
런타임 디렉터리 구성
실패한 인증 금지 구성
설치 중 자동 캐시 정리 비활성화
Sentry를 통한 오류 보고 및 로깅
콘텐츠 전달 네트워크 URL 설정
콘텐츠 보안 정책 설정
설치 시 초기 루트 비밀번호 설정
호스트 헤더 공격 방지를 위한 허용된 호스트 설정
세션 쿠키 구성
평문 저장소 없이 민감한 구성 제공
- Redis 서버 및 클라이언트 구성 요소에 Redis 비밀번호 제공하기
- GitLab Rails에 PostgreSQL 사용자 비밀번호 제공하기
관련 주제
문제 해결
- 상대 URL 문제 해결
- Mixlib::ShellOut::ShellCommandFailed: linux_user[GitLab user and group]
- GitLab이 Git 사용자 또는 그룹 이름 변경 후 502 응답

리눅스 패키지 설치를 위한 구성 옵션

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

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

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

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

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

GitLab의 외부 URL 구성

사용자에게 올바른 저장소 클론 링크를 표시하려면

사용자가 저장소에 접근하는 URL를 GitLab에 제공해야 합니다.

서버의 IP를 사용할 수 있지만, 정규화된 도메인 이름(FQDN)을 사용하는 것이 좋습니다.

자체 관리형 GitLab 인스턴스에서 DNS 사용에 대한 더 많은 정보는 DNS 문서를 참조하세요.

외부 URL을 변경하려면:

선택 사항. 외부 URL을 변경하기 전에

이전에 사용자 정의 홈 페이지 URL 또는 로그아웃 후 경로를 정의했는지 확인하세요.

이 설정 중 둘 다 새 외부 URL을 구성한 후에 원치 않는 리디렉션을 유발할 수 있습니다.

URL를 정의한 경우에는 완전히 제거하세요.

/etc/gitlab/gitlab.rb를 편집하여

external_url을 선호하는 URL로 변경하세요:

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

또는 서버의 IP 주소를 사용할 수 있습니다:

   external_url "http://10.0.0.1"

이전 예제에서는 일반 HTTP를 사용했습니다. HTTPS를 사용하려면

SSL 구성을 참조하세요.

GitLab을 재구성하세요:
```
sudo gitlab-ctl reconfigure
```
선택 사항. GitLab을 사용한 지 좀 되었다면,

외부 URL을 변경한 후,

Markdown 캐시를 무효화해야 합니다.

설치 시 외부 URL 지정

리눅스 패키지를 사용하는 경우

최소한의 명령으로 GitLab 인스턴스를 설정할 수 있습니다.

EXTERNAL_URL 환경 변수를 사용하는 것입니다.

이 변수가 설정되면 자동으로 감지되며,

gitlab.rb 파일에 external_url로 값이 기록됩니다.

EXTERNAL_URL 환경 변수는

패키지의 설치 및 업그레이드에만 영향을 미칩니다.

정기적인 재구성 실행에는

/etc/gitlab/gitlab.rb의 값이 사용됩니다.

패키지 업데이트의 일환으로,

EXTERNAL_URL 변수가 실수로 설정된 경우

기존 값을 /etc/gitlab/gitlab.rb에서 경고 없이 대체합니다.

따라서 전역적으로 변수를 설정하지 말고,

설치 명령에 특별히 전달하는 것이 좋습니다:

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

GitLab의 상대 URL 구성

자체 컴파일된(소스) 설치에 대해서는 따로 문서가 있습니다.

별도 문서로 확인하세요.

GitLab을 자신의 (서브) 도메인에 설치하는 것이 좋지만,

때로는 불가능할 수 있습니다.

이 경우, GitLab은 상대 URL 아래에 설치할 수도 있습니다.

예를 들어, https://example.com/gitlab입니다.

URL을 변경하면 모든 원격 URL도 변경되므로,

GitLab 인스턴스를 가리키는 모든 로컬 저장소에서 수동으로 편집해야 합니다.

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

/etc/gitlab/gitlab.rb에서 external_url을 설정하세요:
```
external_url "https://example.com/gitlab"
```
이 예제에서는 GitLab이 제공되는 상대 URL이 /gitlab입니다.

원하는 대로 변경하세요.
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에 의해 코드로 실행되는 구성을 추가할 수 있음을 의미합니다.

일부 조직에서는 루트 사용자로서가 아닌 구성 파일에 접근하는 것이 허용됩니다.

다음과 같이 /etc/gitlab/gitlab.rb 안에 외부 구성 파일을 포함할 수 있습니다:

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

from_file "/home/admin/external_gitlab.rb"

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 상위 디렉토리의 위치를 변경하려면:

/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" }
})

대상 디렉토리 및 그 하위 경로는 심볼릭 링크가 아니어야 합니다.

GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```
선택 사항. /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 구성 문서를 참조하세요.

모든 리포지토리를 이동할 계획이 아니라 특정 프로젝트를 기존 리포지토리 저장소 간에 이동하려는 경우, Edit Project API 엔드포인트를 사용하고 repository_storage 속성을 지정하세요.

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

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

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

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

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

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

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 등의 사용자를 생성합니다.
이 사용자들에 대한 숫자 식별자를 지정하려면:

나중에 필요할 수 있으므로 이전 사용자 및 그룹 식별자를 기록해 둡니다:
```
sudo cat /etc/passwd
```

/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

GitLab를 중지하고, 재구성한 다음 시작합니다:

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

선택 사항: user['uid'] 및 user['gid']를 변경하는 경우,
Linux 패키지에서 직접 관리하지 않는 파일의 uid/guid도 업데이트해야 하며, 예를 들어 로그 파일이 있습니다:

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`
`gitlab-backup`	`gitlab-backup-cli` 사용 시에만 필요	GitLab Backup Cli 사용자	`/var/opt/gitlab/backups`	`/bin/sh`

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

/etc/gitlab/gitlab.rb 파일을 편집합니다:
```
manage_accounts['enable'] = false
```

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

# 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
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
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'

GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

사용자 홈 디렉토리 이동

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

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

GitLab 중지:
```
sudo gitlab-ctl stop
```
runit 서버 중지:
```
sudo systemctl stop gitlab-runsvdir
```
홈 디렉토리 변경:
```
sudo usermod -d /path/to/home <username>
```
기존 데이터가 있는 경우, 수동으로 새로운 위치로 복사/rsync해야 합니다:

/etc/gitlab/gitlab.rb 수정:

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

runit 서버 시작:
```
sudo systemctl start gitlab-runsvdir
```
GitLab 재구성:
```
sudo gitlab-ctl reconfigure
```

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

Linux 패키지는 모든 필요한 디렉토리를 올바른 소유자 및 권한으로 생성하고, 이를 업데이트하는 작업을 처리합니다.

일부 디렉토리는 대량의 데이터를 보유하고 있으므로 특정 설정에서는 이 디렉토리들이 NFS(또는 기타) 공유에 마운트될 가능성이 높습니다.

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

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

/etc/gitlab 디렉토리가 마운트되어 있다면, 해당 디렉토리 관리 기능을 끌 수 있습니다:

/etc/gitlab/gitlab.rb 수정:

manage_storage_directories['manage_etc'] = false

GitLab 재구성:
```
sudo gitlab-ctl reconfigure
```

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

모든 GitLab 스토리지 디렉토리를 각각 다른 마운트에 마운트하고 있다면, 스토리지 디렉토리 관리 기능을 완전히 비활성화해야 합니다.

Linux 패키지 설치는 이러한 디렉토리가 파일 시스템에 존재할 것으로 기대합니다. 이 설정이 활성화되면 디렉토리를 생성하고 올바른 권한을 설정하는 것은 귀하의 몫입니다.

이 설정을 활성화하면 다음 디렉토리의 생성이 방지됩니다:

기본 위치	권한	소유자	목적
`/var/opt/gitlab/git-data`	`2770`	`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 아티팩트를 보유
`/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`	테라폼 상태를 보유
`/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`	승인된 키를 보유

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

/etc/gitlab/gitlab.rb 수정:

manage_storage_directories['enable'] = false

GitLab 재구성:
```
sudo gitlab-ctl reconfigure
```

주어진 파일 시스템이 마운트된 후에만 Linux 패키지 설치 서비스를 시작하십시오

주어진 파일 시스템이 마운트되기 전에 Linux 패키지 설치 서비스(NGINX, Redis, Puma 등)가 시작되는 것을 방지하려면

high_availability['mountpoint'] 설정을 할 수 있습니다:

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

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

GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```
주의: 마운트 지점이 존재하지 않으면 GitLab 재구성이 실패합니다.

런타임 디렉터리 구성

Prometheus 모니터링이 활성화되면 GitLab Exporter는 각 Puma 프로세스(Rails 메트릭)의 측정을 수행합니다.

각 Puma 프로세스는 각 컨트롤러 요청에 대해 메트릭 파일을 임시 위치에 기록해야 합니다.

Prometheus는 이러한 모든 파일을 수집하고 그 값을 처리합니다.

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

reconfigure 중에 패키지는 /run이 tmpfs 마운트인지 확인합니다.

그렇지 않을 경우 다음 경고가 표시되며 Rails 메트릭이 비활성화됩니다:

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

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

/etc/gitlab/gitlab.rb를 편집하여 tmpfs 마운트를 생성합니다 (구성에서 =가 없습니다):
```
runtime_dir '/path/to/tmpfs'
```
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 및 컨테이너 레지스트리 인증 금지를 구성하려면:

/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, # 60초 후 IP당 인증 시도 카운터를 재설정합니다.
  'bantime' => 3600 # 너무 많은 인증 시도 후 한 시간(3600초) 동안 IP를 차단합니다.
}

GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

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

대규모 GitLab 설치를 사용하는 경우, 완료하는 데 오랜 시간이 걸릴 수 있는 rake cache:clear 작업을 실행하고 싶지 않을 수 있습니다. 기본적으로 캐시 정리 작업은 재구성 중에 자동으로 실행됩니다.

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

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

# 이는 전체 RAILS 환경 로딩에 오랜 시간이 걸리는 대규모 gitlab 배포에서 사용되는 고급 기능입니다.
gitlab_rails['rake_cache_clear'] = false

GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

Sentry를 통한 오류 보고 및 로깅

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

Sentry는 SaaS(https://sentry.io)로 사용하거나 직접 호스팅할 수 있는 오픈 소스 오류 보고 및 로깅 도구입니다.

Sentry를 구성하려면:

Sentry에서 프로젝트를 생성합니다.
생성한 프로젝트의 데이터 소스 이름(DSN)을 찾습니다.

/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 환경(예: lab, development, staging 및 production)에서 오류 및 문제를 추적하는 데 사용할 수 있습니다.

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

예를 들어, 다음과 같이 설정하면:
```
gitlab_rails['env'] = {
  'GITLAB_SENTRY_EXTRA_TAGS' => '{"stage": "main"}'
}
```
stage 태그에 main 값을 추가합니다.
GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

콘텐츠 전달 네트워크 URL 설정

정적 자산을 서비스하기 위해 콘텐츠 배달 네트워크(CDN) 또는 자산 호스트를 사용하여 gitlab_rails['cdn_host']를 설정합니다. 이는 Rails 자산 호스트를 구성합니다.

CDN/자산 호스트를 설정하려면:

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

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

GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

자산 호스트로 작동하도록 일반 서비스를 구성하는 추가 문서는 이 이슈에서 확인할 수 있습니다.

콘텐츠 보안 정책 설정

콘텐츠 보안 정책(CSP)을 설정하면 자바스크립트 크로스 사이트 스크립팅(XSS) 공격을 차단하는 데 도움이 될 수 있습니다. 더 자세한 내용은 CSP에 대한 Mozilla 문서를 참조하세요.

CSP 및 인라인 자바스크립트의 nonce-source는 GitLab.com에서 사용할 수 있습니다.

셀프 호스팅에서는 기본적으로 구성되지 않습니다.

참고: CSP 규칙을 잘못 구성하면 GitLab이 제대로 작동하지 않을 수 있습니다. 정책을 배포하기 전에 report_only를 true로 변경하여 구성을 테스트하는 것이 좋습니다.

CSP를 추가하려면:

/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"
    }
}
```
명시적으로 구성되지 않은 지시문에는 안전한 기본값이 사용됩니다.

CSP 지시문을 비활성화하려면 false 값을 설정합니다.
GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

설치 시 초기 루트 비밀번호 설정

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

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

GitLab이 의도한 호스트 헤더 외의 호스트 헤더를 수락하지 않도록 하려면:

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

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

GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

allowed_hosts를 구성하지 않더라도 GitLab에서 발생하는 보안 문제는 알려져 있지 않지만, 잠재적인 HTTP 호스트 헤더 공격에 대해 심층 방어를 위해 권장됩니다.

Apache와 같은 사용자 지정 외부 프록시를 사용하는 경우 로컬호스트 주소나 이름(localhost 또는 127.0.0.1)을 추가해야 할 수 있습니다. 프록시를 통해 작업자에게 전달되는 잠재적인 HTTP 호스트 헤더 공격을 완화하기 위해 외부 프록시에 필터를 추가해야 합니다.

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

세션 쿠키 구성

생성된 웹 세션 쿠키 값의 접두사를 변경하려면:

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

gitlab_rails['session_store_session_cookie_token_prefix'] = 'custom_prefix_'

GitLab을 재구성합니다:
```
sudo gitlab-ctl reconfigure
```

기본값은 비어 있는 문자열 ""입니다.

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

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

사용 가능한 옵션은 다음과 같습니다:

`gitlab.rb` 설정	책임
`redis['extra_config_command']`	Redis 서버 구성 파일에 추가 구성을 제공합니다.
`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(KAS)를 위한 GitLab 에이전트 서버에 추가 구성을 제공합니다.
`gitlab_workhorse['extra_config_command']`	GitLab Workhorse에 추가 구성을 제공합니다.
`gitlab_exporter['extra_config_command']`	GitLab Exporter에 추가 구성을 제공합니다.

이러한 옵션 중 어느 것에 할당된 값은 민감한 구성을 STDOUT에 필요한 형식으로 작성하는 실행 가능한 스크립트의 절대 경로여야 합니다. 구성 요소는 다음과 같은 작업을 수행합니다:

제공된 스크립트를 실행합니다.
사용자 및 기본 구성 파일에 의해 설정된 값을 스크립트에서 방출된 값으로 대체합니다.

Redis 서버 및 클라이언트 구성 요소에 Redis 비밀번호 제공하기

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

참고: Redis 서버에 비밀번호를 지정할 때, 이 방법은 사용자가 gitlab.rb 파일에 평문 비밀번호를 저장하는 것을 방지합니다. 비밀번호는 /var/opt/gitlab/redis/redis.conf에 있는 Redis 서버 구성 파일에 평문으로 저장됩니다.

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

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

require 'json'
require 'yaml'

class RedisConfig
  REDIS_PASSWORD = `echo "toomanysecrets"`.strip # Redis 비밀번호를 가져오는 백틱 내의 명령어를 변경하세요.

  class << self
    def server
      puts "requirepass '#{REDIS_PASSWORD}'"
      puts "masterauth '#{REDIS_PASSWORD}'"
    end

    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: generate-redis-conf <COMPONENT>"
  $stderr.puts "지원되는 구성 요소: server, 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

위에서 생성한 스크립트가 실행 가능하도록 합니다:
```
chmod +x /opt/generate-redis-conf
```

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

redis['extra_config_command'] = '/opt/generate-redis-conf server'

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'

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

GitLab Rails에 PostgreSQL 사용자 비밀번호 제공하기

예를 들어, 아래의 스크립트와 구성을 사용하여 GitLab Rails가 PostgreSQL 서버에 연결할 때 사용할 비밀번호를 제공할 수 있습니다.

아래 스크립트를 /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
 }
})

위에서 생성한 스크립트가 실행 가능하도록 합니다:
```
chmod +x /opt/generate-db-config
```

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

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

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

문제 해결

상대 URL 문제 해결

상대 URL 구성으로 이동한 후 GitLab 자산이 깨져 보이는 문제가 발생하면(예: 이미지 누락 또는 비응답 구성 요소)

GitLab에서 Frontend 레이블로 문제를 제기하세요.

`Mixlib::ShellOut::ShellCommandFailed: linux_user[GitLab user and group]`

사용자의 홈 디렉토리 이동 시

runit 서비스가 중지되지 않고 홈 디렉토리가 수동으로 이동되지 않으면 GitLab reconfiguring 중 오류가 발생합니다:

account[GitLab user and group] (gitlab::users line 28) had an error: Mixlib::ShellOut::ShellCommandFailed: linux_user[GitLab user and group] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/package/resources/account.rb line 51) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '8'
---- Begin output of ["usermod", "-d", "/var/opt/gitlab", "git"] ----
STDOUT:
STDERR: usermod: user git is currently used by process 1234
---- End output of ["usermod", "-d", "/var/opt/gitlab", "git"] ----
Ran ["usermod", "-d", "/var/opt/gitlab", "git"] returned 8

홈 디렉토리를 이동하기 전에 runit를 중지하세요.

GitLab이 Git 사용자 또는 그룹 이름 변경 후 502 응답

기존 설치에서 Git 사용자 또는 그룹 이름을 변경하면 여러 부작용이 발생할 수 있습니다.

접근할 수 없는 파일과 관련된 오류를 확인하고 권한을 수정해 보세요:

gitlab gitlab-ctl tail -f

리눅스 패키지 설치를 위한 구성 옵션

GitLab의 외부 URL 구성

설치 시 외부 URL 지정

GitLab의 상대 URL 구성

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

파일에서 인증서 읽기

대체 디렉토리에 Git 데이터 저장

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

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

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

사용자 홈 디렉토리 이동

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

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

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

주어진 파일 시스템이 마운트된 후에만 Linux 패키지 설치 서비스를 시작하십시오

런타임 디렉터리 구성

실패한 인증 금지 구성

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

Sentry를 통한 오류 보고 및 로깅

콘텐츠 전달 네트워크 URL 설정

콘텐츠 보안 정책 설정

설치 시 초기 루트 비밀번호 설정

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

세션 쿠키 구성

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

Redis 서버 및 클라이언트 구성 요소에 Redis 비밀번호 제공하기

GitLab Rails에 PostgreSQL 사용자 비밀번호 제공하기

관련 주제

문제 해결

상대 URL 문제 해결

`Mixlib::ShellOut::ShellCommandFailed: linux_user[GitLab user and group]`

GitLab이 Git 사용자 또는 그룹 이름 변경 후 502 응답

도움말

기능 사용 가능성과 제품 평가판

도움받기

리눅스 패키지 설치를 위한 구성 옵션

GitLab의 외부 URL 구성

설치 시 외부 URL 지정

GitLab의 상대 URL 구성

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

파일에서 인증서 읽기

대체 디렉토리에 Git 데이터 저장

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

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

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

사용자 홈 디렉토리 이동

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

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

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

주어진 파일 시스템이 마운트된 후에만 Linux 패키지 설치 서비스를 시작하십시오

런타임 디렉터리 구성

실패한 인증 금지 구성

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

Sentry를 통한 오류 보고 및 로깅

콘텐츠 전달 네트워크 URL 설정

콘텐츠 보안 정책 설정

설치 시 초기 루트 비밀번호 설정

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

세션 쿠키 구성

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

Redis 서버 및 클라이언트 구성 요소에 Redis 비밀번호 제공하기

GitLab Rails에 PostgreSQL 사용자 비밀번호 제공하기

관련 주제

문제 해결

상대 URL 문제 해결

Mixlib::ShellOut::ShellCommandFailed: linux_user[GitLab user and group]

GitLab이 Git 사용자 또는 그룹 이름 변경 후 502 응답

도움말

기능 사용 가능성과 제품 평가판

도움받기

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

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

`Mixlib::ShellOut::ShellCommandFailed: linux_user[GitLab user and group]`