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

Linux 패키지 설치에 대한 구성 옵션

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

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

참고: /etc/gitlab/gitlab.rb를 편집할 때 제공된 예제는 경우에 따라 인스턴스의 기본 설정을 항상 반영하지 않을 수 있습니다.

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

GitLab의 외부 URL 구성

사용자에게 올바른 저장소 복제 링크를 표시하려면 GitLab에 사용자가 저장소에 액세스하는 데 사용하는 URL을 제공해야 합니다. 서버 IP를 사용할 수도 있지만 완전히 정규화된 도메인 이름(FQDN)이 선호됩니다. 자체 관리 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. OPTIONAL. GitLab을 사용한 지 한동안이 지났다면, 외부 URL을 변경한 후에도 마크다운 캐시를 무효화해야 합니다.

설치 시 외부 URL 지정

Linux 패키지를 사용하는 경우 EXTERNAL_URL 환경 변수를 사용하여 최소한의 명령으로 GitLab 인스턴스를 설정할 수 있습니다. 이 변수가 설정되면 자동으로 감지되어 해당 값이 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을 /gitlab와 같은 상대 URL에 설치할 수도 있습니다.

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

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 서버 인증서를 직접 파일에서 읽어들입니다.

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. OPTIONAL. 이미 /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 구성에 대한 문서를 참조하세요.

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

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

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

기본적으로 Linux 패키지 설치는 GitLab Shell 로그인을 위해 사용자 이름인 git을 사용하며, Git 데이터 자체의 소유권 및 웹 인터페이스에서 SSH URL 생성에 사용됩니다. 유사하게 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/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 패키지 설치는 다음 사용자 및 그룹이 존재하기를 기대합니다:

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

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

3. GitLab을 다시 구성하십시오:

   sudo gitlab-ctl reconfigure
   

사용자의 홈 디렉터리 이동

GitLab 사용자의 경우 더 나은 성능을 위해 홈 디렉터리를 공유 스토리지(NFS와 같은)가 아닌 로컬 디스크에 설정하는 것이 좋습니다. 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 패키지 설치는 이러한 디렉토리가 파일 시스템에 존재한다고 예상합니다. 이 설정이 설정된 경우 올바른 권한으로 디렉토리를 생성하고 설정하는 것은 여러분에게 달려 있습니다.

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

저장 디렉터리의 관리를 비활성화하려면:

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 Expoorter는 각 Puma 프로세스의 측정값을 수행합니다 (Rails 메트릭). 각 Puma 프로세스는 컨트롤러 요청마다 임시 위치에 메트릭 파일을 작성해야 합니다. 그런 다음 Prometheus는 이러한 파일을 수집하고 값을 처리합니다.

디스크 I/O를 줄이기 위해 Linux 패키지는 런타임 디렉토리를 사용합니다.

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

런타임 디렉터리 '/run'이 tmpfs 마운트되어 있지 않습니다.

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

1. /etc/gitlab/gitlab.rb를 편집하여 tmpfs 마운트를 만듭니다 (구성에서는 =가 없음에 유의):

   runtime_dir '/path/to/tmpfs'
   

2. GitLab 재구성:

   sudo gitlab-ctl reconfigure
   

실패한 인증 금지 구성

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

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

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, # 60초 후에 IP 당 인증 시도 횟수 재설정
     '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>' # Browser 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
   

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

콘텐츠 전달 네트워크(CDN) 또는 자산 호스트를 사용하여 정적 자산을 제공하려면 gitlab_rails['cdn_host']를 구성하세요. 이는 Rails 자산 호스트를 구성합니다.

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

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

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

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

   sudo gitlab-ctl reconfigure
   

공통 서비스를 자산 호스트로 구성하는 방법에 대한 추가 문서는 이 이슈에서 추적됩니다.

콘텐츠 보안 정책 설정

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

CSP 및 인라인 JavaScript용 nonce-source은 GitLab.com에서 사용할 수 있습니다. 자체 호스팅에서는 기본적으로 구성되지 않습니다.

참고: 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"
       }
   }
   

   명시적으로 구성되지 않은 지시어에는 안전한 기본 값을 사용합니다.

   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 호스트 헤더 공격에 대비하여 방어적인 목적으로 권장됩니다.

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

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

세션 쿠키 구성

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

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

   gitlab_rails['session_store_session_cookie_token_prefix'] = 'custom_prefix_'
   

2. GitLab을 재구성하세요:

   sudo gitlab-ctl reconfigure
   

기본값은 빈 문자열 ""입니다.

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

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

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

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

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

Redis 암호를 Redis 서버 및 클라이언트 구성요소에 제공

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

참고: Redis 서버에 암호를 지정할 때, 이 방법은 사용자가 gitlab.rb 파일에서 평문 암호를 갖는 것으로부터 보호하지만, 암호는 /var/opt/gitlab/redis/redis.conf에 존재하는 Redis 서버 구성 파일에서 평문으로 끝나게 됩니다.

1. 아래 스크립트를 /opt/generate-redis-conf로 저장하세요.

   #!/opt/gitlab/embedded/bin/ruby
   
   require 'json'
   require 'yaml'
   
   class RedisConfig
     REDIS_PASSWORD = `echo "toomanysecrets"`.strip # backticks 내부 명령을 변경하여 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 "Supported components are: 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
   

2. 위에서 생성한 스크립트가 실행 가능하도록 합니다.

   chmod +x /opt/generate-redis-conf
   

3. 아래 스니펫을 /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'
   

4. sudo gitlab-ctl reconfigure를 실행하세요.

PostgreSQL 사용자 암호를 GitLab Rails에 제공

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

1. 아래 스크립트를 /opt/generate-db-config로 저장하세요.

   #!/opt/gitlab/embedded/bin/ruby
   
   require 'yaml'
   
   db_password = `echo "toomanysecrets"`.strip # backticks 내부 명령을 변경하여 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를 실행하세요.

관련 주제

• 사용자 위장 비활성화
• LDAP 로그인 설정
• 스마트카드 인증
• NGINX 설정 - 다음과 같은 작업을 위해:
  • HTTPS 설정
  • HTTP 요청을 HTTPS로 리디렉션
  • 기본 포트 및 SSL 인증서 위치 변경
  • NGINX 리스닝 주소 설정
  • GitLab 서버 블록에 사용자 정의 NGINX 설정 추가
  • NGINX 구성에 사용자 정의 설정 추가
  • nginx_status 활성화
• 패키지에 포함되지 않은 웹 서버 사용
• 패키지에 포함되지 않은 PostgreSQL 데이터베이스 관리 서버 사용
• 패키지에 포함되지 않은 Redis 인스턴스 사용
• GitLab 런타임 환경에 ENV 변수 추가하기](environment-variables.md)
• gitlab.yml 및 application.yml 설정 변경
• SMTP를 통한 애플리케이션 이메일 설정
• OmniAuth 설정(Google, Twitter, GitHub 로그인)
• Puma 설정 조정

문제 해결

상대 URL 문제 해결

상대 URL 구성(이미지 누락 또는 응답이 없는 구성 요소와 같은)으로 인해 GitLab 자산에 문제가 발생하는 경우, GitLab에서 Frontend 레이블이 지정된 이슈를 제기해 주세요.

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

사용자의 홈 디렉토리를 이동할 때, runit 서비스가 중지되지 않거나 사용자의 홈 디렉토리가 수동으로 이동되지 않은 경우, GitLab을 재구성하는 중에 오류가 발생할 수 있습니다:

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에서 502 오류 발생시 Git 사용자 또는 그룹 이름을 변경한 후

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

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

gitlab gitlab-ctl tail -f