- 서비스별 NGINX 설정
- HTTPS 사용
- 기본 프록시 헤더 변경
- GitLab 신뢰하는 프록시 및 NGINX
real_ip모듈 구성 - PROXY 프로토콜 구성
- 번들되지 않은 웹 서버 사용
- NGINX 구성 옵션
NGINX 설정
이 페이지는 GitLab 설치를 위해 NGINX를 구성하는 관리자 및 DevOps 엔지니어를 위한 구성 정보를 제공합니다. 이 페이지에는 Linux 패키지, Helm 차트 또는 사용자 정의 설정에 대한 성능 및 보안을 최적화하기 위한 필수 지침이 포함되어 있습니다.
서비스별 NGINX 설정
다양한 서비스에 대한 NGINX 설정을 구성하려면 gitlab.rb 파일을 편집하세요.
경고: 올바르지 않거나 호환되지 않는 구성은 서비스를 사용할 수 없게 할 수 있습니다.
nginx['<setting>'] 키를 사용하여 GitLab Rails 애플리케이션의 설정을 구성하세요. GitLab은 pages_nginx, mattermost_nginx, registry_nginx와 같은 다른 서비스에 대한 유사한 키를 제공합니다. nginx에 대한 설정은 이러한 <service_nginx> 설정에도 사용할 수 있으며, GitLab NGINX와 동일한 기본값을 공유합니다.
Mattermost와 같은 격리된 서비스에 대해 NGINX를 사용하려면 nginx['enable'] = false 대신에 gitlab_rails['enable'] = false을 사용하세요. 자세한 내용은 독립적인 서버에서 GitLab Mattermost 실행을 참조하세요.
gitlab.rb 파일을 수정하면 각 서비스에 대한 NGINX 설정을 별도로 구성해야 합니다. nginx['foo']로 지정된 설정은 서비스별 NGINX 구성(registry_nginx['foo'] 또는 mattermost_nginx['foo'])에 복제되지 않습니다. 예를 들어 GitLab, Mattermost 및 Registry에 대한 HTTP에서 HTTPS로의 리다이렉션을 구성하려면 다음 설정을 gitlab.rb에 추가하세요.
nginx['redirect_http_to_https'] = true
registry_nginx['redirect_http_to_https'] = true
mattermost_nginx['redirect_http_to_https'] = true
HTTPS 사용
기본적으로 Linux 패키지 설치는 HTTPS를 사용하지 않습니다. gitlab.example.com에 대해 HTTPS를 활성화하려면 다음을 참조하세요.
프록시, 로드 밸런서 또는 기타 외부 장치를 사용하여 GitLab 호스트 이름의 SSL을 종료하는 경우 외부, 프록시 및 로드 밸런서 SSL 종료 설정을 참조하세요.
기본 프록시 헤더 변경
기본적으로 external_url을 지정하면 Linux 패키지 설치가 대부분의 환경에 적합한 NGINX 프록시 헤더를 설정합니다.
예를 들어, external_url에서 https 스키마를 지정하면 Linux 패키지 설치가 다음과 같이 설정합니다.
"X-Forwarded-Proto" => "https",
"X-Forwarded-Ssl" => "on"
GitLab 인스턴스가 반대 프록시 뒤와 같이 더 복잡한 환경에 있는 경우 The change you wanted was rejected, Can't verify CSRF token authenticity Completed 422 Unprocessable와 같은 오류를 피하려면 프록시 헤더를 조정해야 할 수 있습니다.
기본 헤더를 재정의하려면:
-
/etc/gitlab/gitlab.rb파일을 편집합니다.nginx['proxy_set_headers'] = { "X-Forwarded-Proto" => "http", "CUSTOM_HEADER" => "VALUE" } -
파일을 저장하고 변경 사항이 적용되도록 GitLab을 다시 구성합니다.
NGINX에서 지원하는 임의의 헤더를 지정할 수 있습니다.
GitLab 신뢰하는 프록시 및 NGINX real_ip 모듈 구성
기본적으로 NGINX와 GitLab은 연결된 클라이언트의 IP 주소를 기록합니다.
GitLab이 반대 프록시 뒤에 있는 경우 프록시의 IP 주소가 클라이언트 주소로 표시되지 않길 원할 수 있습니다.
NGINX를 다른 주소를 사용하도록 구성하려면 반대 프록시를 real_ip_trusted_addresses 목록에 추가하세요.
# 각 주소가 NGINX 설정에 'set_real_ip_from <address>;'로 추가됩니다.
nginx['real_ip_trusted_addresses'] = [ '192.168.1.0/24', '192.168.2.1', '2001:0db8::/32' ]
# 다른 real_ip 구성 옵션
nginx['real_ip_header'] = 'X-Forwarded-For'
nginx['real_ip_recursive'] = 'on'
이러한 옵션에 대한 설명은 NGINX realip 모듈 설명서에서 참조하세요.
기본적으로 Linux 패키지 설치는 real_ip_trusted_addresses의 IP 주소를 GitLab의 신뢰하는 프록시로 사용합니다. 신뢰하는 프록시 구성을 통해 사용자가 해당 IP 주소에서 로그인한 것으로 되지 않도록합니다.
파일을 저장하고 변경 사항이 적용되도록 GitLab을 다시 구성합니다.
PROXY 프로토콜 구성
GitLab 앞에 HAProxy와 같은 프록시를 사용하여 PROXY 프로토콜을 사용하려면 다음을 수행하세요.
-
/etc/gitlab/gitlab.rb파일을 편집합니다.# NGINX에 의한 ProxyProtocol 종료 활성화 nginx['proxy_protocol'] = true # `proxy_protocol`이 활성화된 경우 필요한 신뢰하는 상위 프록시 구성 nginx['real_ip_trusted_addresses'] = [ "127.0.0.0/8", "IP_OF_THE_PROXY/32"] -
파일을 저장하고 변경 사항이 적용되도록 GitLab을 다시 구성합니다.
이 설정을 활성화한 후에는 NGINX가 이러한 리스너에서만 PROXY 프로토콜 트래픽을 수락합니다. 감시 확인과 같은 기타 환경을 조정하세요.
번들되지 않은 웹 서버 사용
기본적으로 Linux 패키지는 번들된 NGINX로 GitLab을 설치합니다. Linux 패키지 설치를 통해 외부 웹 서버에 gitlab-www 사용자로부터 접근을 허용합니다. 외부 웹 서버가 GitLab에 액세스하려면 외부 웹 서버 사용자를 gitlab-www 그룹에 추가하세요.
Apache 또는 기존 NGINX 설치에 대해 다른 웹 서버를 사용하려면:
-
번들된 NGINX를 비활성화합니다.
/etc/gitlab/gitlab.rb에서 다음과 같이 설정하세요.nginx['enable'] = false -
번들되지 않은 웹 서버 사용자의 사용자 이름 설정:
Linux 패키지 설치는 외부 웹 서버 사용자에 대한 기본 설정이 없습니다. 설정에서 지정해야 합니다. 예를 들어:
- Debian/Ubuntu: Apache 및 NGINX에 대해 기본 사용자는 둘 다
www-data입니다. - RHEL/CentOS: NGINX 사용자는
nginx입니다.
프로필이 제한된 SELinux 프로필하에 웹 서버가 실행되는 경우 웹 서버 제한 완화가 필요할 수 있습니다.
외부 웹 서버 사용자가 외부 웹 서버에서 사용하는 모든 디렉토리에 대한 올바른 권한이 있는지 확인하세요. 그렇지 않으면
failed (XX: Permission denied) while reading upstream오류를 받게 될 수 있습니다. - Debian/Ubuntu: Apache 및 NGINX에 대해 기본 사용자는 둘 다
-
번들되지 않은 웹 서버를 신뢰하는 프록시 목록에 추가합니다.
Linux 패키지 설치는 일반적으로
real_ip모듈에 대한 구성을 기본적으로real_ip모듈에 구성합니다.번들되지 않은 웹 서버의 경우 목록을 직접 구성하세요. 외부 웹 서버가 GitLab과 동일한 시스템이 아니라면 외부 웹 서버의 IP 주소를 포함하세요. 그렇지 않으면 사용자가 외부 웹 서버의 IP 주소에서 로그인한 것처럼 보일 수 있습니다.
gitlab_rails['trusted_proxies'] = [ '192.168.1.0/24', '192.168.2.1', '2001:0db8::/32' ] -
선택 사항. Apache를 사용하는 경우 GitLab Workhorse 설정을 설정하세요.
Apache는 UNIX 소켓에 연결할 수 없으며 TCP 포트에 연결해야 합니다. GitLab Workhorse가 기본적으로 8181 포트로 수신하도록 허용하려면
/etc/gitlab/gitlab.rb에서 다음을 편집하세요.gitlab_workhorse['listen_network'] = "tcp" gitlab_workhorse['listen_addr'] = "127.0.0.1:8181"변경 사항이 적용되도록
sudo gitlab-ctl reconfigure를 실행하세요. -
올바른 웹 서버 구성 다운로드:
GitLab 저장소로 이동하여 필요한 구성을 다운로드하세요. SSL을 사용하여 GitLab을 제공하는 경우 또는 SSL을 사용하지 않고 제공하는 경우 올바른 구성 파일을 선택하세요.
-
YOUR_SERVER_FQDN의 값을 FQDN으로 변경해야 합니다. - SSL을 사용하는 경우 SSL 키의 위치를 변경해야 합니다.
- 로그 파일의 위치를 변경해야 할 수 있습니다.
-
NGINX 구성 옵션
GitLab은 특정 요구에 맞게 NGINX 동작을 사용자 정의할 수 있는 다양한 구성 옵션을 제공합니다. GitLab의 성능과 보안을 최적화하고 NGINX 설정을 세밀하게 조정하기 위해 이 참조 항목을 활용하세요.
NGINX 리스닝 주소 설정
기본적으로 NGINX는 모든 로컬 IPv4 주소에서 들어오는 연결을 수락합니다.
주소 목록을 변경하려면:
-
/etc/gitlab/gitlab.rb을 편집하세요:# 모든 IPv4와 IPv6 주소에서 수신 nginx['listen_addresses'] = ["0.0.0.0", "[::]"] registry_nginx['listen_addresses'] = ['*', '[::]'] mattermost_nginx['listen_addresses'] = ['*', '[::]'] pages_nginx['listen_addresses'] = ['*', '[::]'] -
파일을 저장하고 변경 사항이 적용되도록 GitLab을 다시 구성하세요.
NGINX 리스닝 포트 설정
기본적으로 NGINX는 external_url에 지정된 포트에서 듣거나
표준 포트(80은 HTTP, 443은 HTTPS)를 사용합니다. 역방향 프록시 뒤에서
GitLab을 실행 중이라면 리스닝 포트를 재정의할 수 있습니다.
리스닝 포트를 변경하려면:
-
/etc/gitlab/gitlab.rb을 편집하세요. 예를 들어, 포트 8081을 사용하려면:nginx['listen_port'] = 8081 -
파일을 저장하고 변경 사항이 적용되도록 GitLab을 다시 구성하세요.
NGINX 로그의 상세 수준 변경
기본적으로 NGINX는 error 상세 수준에서 로그를 남깁니다.
로그 수준을 변경하려면:
-
/etc/gitlab/gitlab.rb을 편집하세요:nginx['error_log_level'] = "debug" -
파일을 저장하고 변경 사항이 적용되도록 GitLab을 다시 구성하세요.
유효한 로그 수준 값은 NGINX 문서를 참조하세요.
Referrer-Policy 헤더 설정
기본적으로 GitLab은 모든 응답에 대해 Referrer-Policy 헤더를 strict-origin-when-cross-origin으로 설정합니다.
이 설정은 클라이언트로 하여금:
- 동일 출처 요청에 대해 전체 URL을 참조로 보내도록 합니다.
- 교차 출처 요청에 대해 원산지만 보내도록 합니다.
이 헤더를 변경하려면:
-
/etc/gitlab/gitlab.rb을 편집하세요:nginx['referrer_policy'] = 'same-origin'이 헤더를 비활성화하고 클라이언트의 기본 설정을 사용하려면:
nginx['referrer_policy'] = false -
파일을 저장하고 변경 사항이 적용되도록 GitLab을 다시 구성하세요.
경고:
이를 origin이나 no-referrer로 설정하면 전체 참조 URL을 필요로 하는 GitLab 기능이 손상됩니다.
자세한 내용은 Referrer Policy specification를 참조하세요.
Gzip 압축 비활성화
기본적으로 GitLab은 10240바이트 이상의 텍스트 데이터에 대해 Gzip 압축을 활성화합니다. Gzip 압축을 비활성화하려면:
-
/etc/gitlab/gitlab.rb을 편집하세요:nginx['gzip_enabled'] = false -
파일을 저장하고 변경 사항이 적용되도록 GitLab을 다시 구성하세요.
참고:
gzip 설정은 GitLab의 주 어플리케이션에만 적용됩니다.
프록시 요청 버퍼링 비활성화
특정 위치에 대해 요청 버퍼링을 비활성화하려면:
-
/etc/gitlab/gitlab.rb을 편집하세요:nginx['request_buffering_off_path_regex'] = "/api/v\\d/jobs/\\d+/artifacts$|/import/gitlab_project$|\\.git/git-receive-pack$|\\.git/ssh-receive-pack$|\\.git/ssh-upload-pack$|\\.git/gitlab-lfs/objects|\\.git/info/lfs/objects/batch$" - 파일을 저장하고 변경 사항이 적용되도록 GitLab을 다시 구성하세요.
-
NGINX 설정을 안전하게 다시로드하세요:
sudo gitlab-ctl hup nginx
hup 명령에 대한 자세한 내용은 NGINX 문서를 참조하세요.
robots.txt 구성
인스턴스의 사용자 정의 robots.txt 파일을 구성하려면:
-
사용자 정의
robots.txt파일을 생성하고 해당 경로를 메모하세요. -
/etc/gitlab/gitlab.rb을 편집하세요:nginx['custom_gitlab_server_config'] = "\nlocation =/robots.txt { alias /path/to/custom/robots.txt; }\n"/path/to/custom/robots.txt를 사용자 정의robots.txt파일의 실제 경로로 대체하세요. -
파일을 저장하고 변경 사항이 적용되도록 GitLab을 다시 구성하세요.
이 구성은 사용자 정의 robots.txt 파일을 제공하기 위해 custom NGINX 설정을 추가합니다.
GitLab 서버 블록에 사용자 정의 NGINX 설정 삽입
GitLab의 NGINX server 블록에 사용자 정의 설정을 추가하려면:
-
/etc/gitlab/gitlab.rb을 편집하세요:# 예: 특정 리포지토리의 원시 파일 다운로드 차단 nginx['custom_gitlab_server_config'] = "location ^~ /foo-namespace/bar-project/raw/ {\n deny all;\n}\n" -
파일을 저장하고 변경 사항이 적용되도록 GitLab을 다시 구성하세요.
이 작업은 /var/opt/gitlab/nginx/conf/gitlab-http.conf 파일의 server 블록 끝에 지정된 문자열을 삽입합니다.
경고:
사용자 정의 설정은 gitlab.rb 파일의 다른 위치에서 정의된 설정과 충돌할 수 있습니다.
노트
-
새 위치를 추가하는 경우 다음과 같은 설정이 필요할 수 있습니다.
proxy_cache off; proxy_http_version 1.1; proxy_pass http://gitlab-workhorse;이러한 설정이 없으면 하위 위치가 404 오류를 반환할 수 있습니다.
-
루트
/위치나/assets위치는gitlab-http.conf에 이미 존재하기 때문에 추가할 수 없습니다.
NGINX 구성에 사용자 정의 설정 삽입
NGINX 구성에 사용자 정의 설정을 추가하려면 다음을 수행하세요:
-
/etc/gitlab/gitlab.rb를 편집합니다.# 예시: 추가 구성 파일을 스캔할 디렉터리 추가 nginx['custom_nginx_config'] = "include /etc/gitlab/nginx/sites-enabled/*.conf;" -
파일을 저장한 후 변경 내용이 적용되도록 GitLab을 재구성합니다.
이렇게 하면 정의된 문자열이 /var/opt/gitlab/nginx/conf/nginx.conf의 http 블록 끝에 삽입됩니다.
예를 들어 사용자 정의 서버 블록을 생성하고 활성화하려면:
-
/etc/gitlab/nginx/sites-available디렉터리에 사용자 정의 서버 블록을 만듭니다. -
리눅스 - gitlab.conf에 이미 존재하지 않은 경우/etc/gitlab/nginx/sites-enabled디렉터리를 만듭니다. -
사용자 정의 서버 블록을 활성화하려면 심볼릭 링크를 만듭니다:
sudo ln -s /etc/gitlab/nginx/sites-available/example.conf /etc/gitlab/nginx/sites-enabled/example.conf -
NGINX 구성을 다시로드합니다:
sudo gitlab-ctl hup nginx또는 NGINX를 다시 시작할 수도 있습니다:
sudo gitlab-ctl restart nginx
서버 블록에 대체 도메인을 추가할 수도 있습니다. 인증서에 대체 도메인 추가는 옵션입니다.
/etc/gitlab/ 디렉터리 내의 사용자 정의 NGINX 설정은 업그레이드 시 /etc/gitlab/config_backup/에 백업되며, 수동으로 sudo gitlab-ctl backup-etc를 실행할 경우에도 백업됩니다.
사용자 정의 오류 페이지 구성
기본 GitLab 오류 페이지의 텍스트를 수정하려면 다음을 수행하세요:
-
/etc/gitlab/gitlab.rb를 편집합니다.nginx['custom_error_pages'] = { '404' => { 'title' => '예시 제목', 'header' => '예시 헤더', 'message' => '예시 메시지' } }이 예시에서는 기본 404 오류 페이지를 수정합니다. 404 또는 502와 같은 유효한 HTTP 오류 코드에 대해 이 형식을 사용할 수 있습니다.
-
파일을 저장한 후 변경 내용이 적용되도록 GitLab을 재구성합니다.
404 오류 페이지의 결과는 다음과 같습니다:
기존 Passenger 및 NGINX 설치 사용
기존의 Passenger 및 NGINX 설치로 GitLab을 호스팅하고 업데이트 및 설치에는 Linux 패키지를 그대로 사용하려면 다음을 수행할 수 있습니다.
NGINX를 비활성화하는 경우 nginx.conf에 수동으로 추가하지 않는 한 Mattermost와 같은 Linux 패키지 설치에 포함된 다른 서비스에 액세스할 수 없습니다.
구성
기존의 Passenger 및 NGINX 설치로 GitLab을 설정하려면 다음을 수행하세요:
-
/etc/gitlab/gitlab.rb를 편집합니다.# 외부 URL 정의 external_url 'http://git.example.com' # 기본 NGINX 비활성화 nginx['enable'] = false # 기본 Puma 비활성화 puma['enable'] = false # 내부 API URL 정의 gitlab_rails['internal_api_url'] = 'http://git.example.com' # 웹 서버 프로세스 사용자 정의 (ubuntu/nginx) web_server['external_users'] = ['www-data'] -
파일을 저장한 후 변경 내용이 적용되도록 GitLab을 재구성합니다.
가상 호스트(서버 블록) 구성
사용자 정의 Passenger/NGINX 설치에서 다음과 같은 내용으로 새 사이트 구성 파일을 만듭니다:
upstream gitlab-workhorse {
server unix://var/opt/gitlab/gitlab-workhorse/sockets/socket fail_timeout=0;
}
server {
listen *:80;
server_name git.example.com;
server_tokens off;
root /opt/gitlab/embedded/service/gitlab-rails/public;
client_max_body_size 250m;
access_log /var/log/gitlab/nginx/gitlab_access.log;
error_log /var/log/gitlab/nginx/gitlab_error.log;
# Passenger가 번들된 Ruby 버전을 사용하도록 보장
passenger_ruby /opt/gitlab/embedded/bin/ruby;
# 패키지화된 실행 파일이 포함된 PATH 변수 수정
passenger_env_var PATH "/opt/gitlab/bin:/opt/gitlab/embedded/bin:/usr/local/bin:/usr/bin:/bin";
# 권한 문제를 방지하기 위해 Passenger가 올바른 사용자와 그룹으로 실행되도록 함
passenger_user git;
passenger_group git;
# Passenger 활성화 및 항상 최소한 하나의 인스턴스 실행
passenger_enabled on;
passenger_min_instances 1;
location ~ ^/[\w\.-]+/[\w\.-]+/(info/refs|git-upload-pack|git-receive-pack)$ {
# '오류' 418은 @gitlab-workhorse 블록을 다시 사용하기 위한 해킹입니다
error_page 418 = @gitlab-workhorse;
return 418;
}
location ~ ^/[\w\.-]+/[\w\.-]+/repository/archive {
# '오류' 418은 @gitlab-workhorse 블록을 다시 사용하기 위한 해킹입니다
error_page 418 = @gitlab-workhorse;
return 418;
}
location ~ ^/api/v3/projects/.*/repository/archive {
# '오류' 418은 @gitlab-workhorse 블록을 다시 사용하기 위한 해킹입니다
error_page 418 = @gitlab-workhorse;
return 418;
}
# 빌드 아티팩트는 이 위치로 제출되어야 함
location ~ ^/[\w\.-]+/[\w\.-]+/builds/download {
client_max_body_size 0;
# '오류' 418은 @gitlab-workhorse 블록을 다시 사용하기 위한 해킹입니다
error_page 418 = @gitlab-workhorse;
return 418;
}
# 빌드 아티팩트는 이 위치로 제출되어야 함
location ~ /ci/api/v1/builds/[0-9]+/artifacts {
client_max_body_size 0;
# '오류' 418은 @gitlab-workhorse 블록을 다시 사용하기 위한 해킹입니다
error_page 418 = @gitlab-workhorse;
return 418;
}
# 빌드 아티팩트는 이 위치로 제출되어야 함
location ~ /api/v4/jobs/[0-9]+/artifacts {
client_max_body_size 0;
# '오류' 418은 @gitlab-workhorse 블록을 다시 사용하기 위한 해킹입니다
error_page 418 = @gitlab-workhorse;
return 418;
}
# HTTP/1.0에서 HTTP/1.1로의 프로토콜 업그레이드시 Host 헤더가 없는 경우 제공해야 함
if ($http_host = "") {
# server_name에 정의된 값 중 하나 사용
set $http_host_with_default "git.example.com";
}
if ($http_host != "") {
set $http_host_with_default $http_host;
}
location @gitlab-workhorse {
## https://github.com/gitlabhq/gitlabhq/issues/694
## 일부 요청이 30초 이상 걸릴 수 있음
proxy_read_timeout 3600;
proxy_connect_timeout 300;
proxy_redirect off;
# Git HTTP 응답을 버퍼링하지 않음
proxy_buffering off;
proxy_set_header Host $http_host_with_default;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_http_version 1.1;
proxy_pass http://gitlab-workhorse;
## 아래 설정은 NGINX 1.7.11 이상에서만 작동
#
## 청크 형식의 요청 본문을 그대로 gitlab-workhorse에 전달
# proxy_request_buffering off;
# proxy_http_version 1.1;
}
## gzip 압축을 활성화(레일스 가이드 참조)
## http://guides.rubyonrails.org/asset_pipeline.html#gzip-compression
## 경고: 상대 URL을 사용하는 경우 아래 블록 제거
## 상대 URL 지원에 대한 자세한 내용은 config/application.rb의 "Relative url support" 참조
location ~ ^/(assets)/ {
root /opt/gitlab/embedded/service/gitlab-rails/public;
gzip_static on; # 사전 압축된 버전 제공
expires max;
add_header Cache-Control public;
}
error_page 502 /502.html;
}
git.example.com을 서버 URL로 바꿔야 합니다.
403 금지 오류를 받은 경우 /etc/nginx/nginx.conf에서 Passenger가 활성화되어 있는지 확인하세요:
-
다음 줄의 주석 해제:
# include /etc/nginx/passenger.conf; -
NGINX 구성을 다시로드합니다:
sudo service nginx reload
NGINX 상태 모니터링 구성
기본적으로 GitLab은 NGINX 상태 확인용 엔드포인트를 127.0.0.1:8060/nginx_status에 구성하여 NGINX 서버 상태를 모니터링합니다.
이 엔드포인트는 다음과 같은 정보를 표시합니다:
활성 연결: 1
서버가 처리한 연결 수
18 18 36
읽기: 0 쓰기: 1 대기: 0
- 활성 연결: 총 열린 연결.
- 모든 수치는 다음을 표시:
- 수락된 모든 연결.
- 처리된 모든 연결.
- 총 처리된 요청 수.
- 읽기: NGINX가 요청 헤더를 읽음.
- 쓰기: NGINX가 요청 본문을 읽고, 요청을 처리하거나 클라이언트에 응답을 작성함.
- 대기: Keep-alive 연결. 이 수치는
keepalive_timeout지시문에 따라 달라짐.
NGINX 상태 옵션 구성
NGINX 상태 옵션을 구성하려면 다음을 수행하세요:
-
/etc/gitlab/gitlab.rb파일을 편집합니다.nginx['status'] = { "listen_addresses" => ["127.0.0.1"], "fqdn" => "dev.example.com", "port" => 9999, "options" => { "access_log" => "on", # 통계를 위한 로그 비활성화 "allow" => "127.0.0.1", # 로컬호스트에서만 접근 허용 "deny" => "all" # 다른 모든 사용자 접근 차단 } }NGINX 상태 엔드포인트를 비활성화하려면:
nginx['status'] = { 'enable' => false } -
파일을 저장하고 변경 사항이 적용되도록 GitLab 재구성을 수행합니다.
업로드를 위한 사용자 권한 구성
사용자 업로드에 접근할 수 있도록 하려면 NGINX 사용자(보통 www-data)를 gitlab-www 그룹에 추가합니다:
sudo usermod -aG gitlab-www www-data
템플릿
구성 파일은 묶여진 GitLab NGINX 구성과 유사하지만 다음과 같은 차이점이 있습니다:
- Puma 대신 Passenger 구성을 사용합니다.
- 기본적으로 HTTPS가 활성화되어 있지 않지만 활성화할 수 있습니다.
NGINX 구성을 변경한 후:
-
데비안 기반 시스템의 경우, NGINX를 다시 시작하세요:
sudo service nginx restart -
다른 시스템의 경우, NGINX를 올바르게 다시 시작할 명령에 대해 운영 체제 설명서를 참조하세요.
도움말