GitLab Pages 관리

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

GitLab Pages는 정적 사이트를 호스팅할 수 있습니다. 관리자가 구성해야합니다. 별도의 사용자 설명서가 있습니다.

note
이 안내서는 Linux 패키지 설치를 위한 것입니다. 소스에서 컴파일된 GitLab 설치인 경우 GitLab Pages administration for self-compiled installations을 참조하세요.

GitLab Pages 데몬

GitLab Pages는 Go로 작성된 기본 HTTP 서버인 GitLab Pages 데몬을 사용하여 외부 IP 주소에서 듣고 사용자 정의 도메인 및 사용자 정의 인증서를 지원합니다. 기본적으로 SNI(Server Name Indication)를 통해 동적 인증서를 지원하며, 기본적으로 HTTP2를 사용하여 페이지를 노출합니다. 그 작동 방식을 완전히 이해하기 위해 README를 읽는 것이 좋습니다.

사용자 정의 도메인(하지만 와일드카드 도메인은 아님)의 경우, Pages 데몬은 80 및/또는 443포트에서 듣고 있어야 합니다. 이러한 이유로 설정할 수 있는 방법에는 유연성이 있습니다.

  • Pages 데몬을 GitLab과 같은 서버에서 보조 IP에서 수신 대기
  • Pages 데몬을 별도의 서버에서 실행합니다. 그 경우, Pages 경로는 Pages 데몬이 설치된 서버에도 있어야 하므로 네트워크를 통해 공유해야 합니다.
  • Pages 데몬을 GitLab과 같은 서버에서 같은 IP에서 수신 대기 but, 다른 포트에서 듣도록 합니다. 이 경우, 트래픽을 프록시해야합니다. 그 경우 HTTPS에 대해 TCP 로드 밸런싱을 해야합니다. 만약 TLS-termination(HTTPS 로드 밸런싱)을 사용하는 경우, 사용자 제공 인증서로 페이지를 제공할 수 없습니다. HTTP의 경우 HTTP 또는 TCP 로드 밸런싱을 사용하는 데에 문제가 없습니다.

이 문서에서는 첫 번째 옵션을 가정하여 진행합니다. 사용자 정의 도메인을 지원하지 않는 경우 보조 IP는 필요하지 않습니다.

사전 요구 사항

Pages 구성을 진행하기 전에, 다음을 수행해야합니다:

  1. GitLab 인스턴스 도메인의 하위 도메인이 아닌 Pages용 도메인이 있어야합니다.

    GitLab 도메인 Pages 도메인 작동 여부?
    example.com example.io 예
    example.com pages.example.com 아니요
    gitlab.example.com pages.example.com 예
  2. 와일드카드 DNS 레코드를 구성해야합니다.
  3. 선택 사항. 해당 도메인에 대한 와일드카드 인증서를 보유하고 있어야합니다. 페이지를 HTTPS로 제공하기로 결정한 경우에만 해당입니다.
  4. 선택 사항이지만 권장됩니다. 인스턴스 러너를 활성화하여 사용자가 자체 러너를 가져오지 않아도되게 합니다.
  5. 사용자 정의 도메인을 위해 보조 IP가 있어야합니다.
note
GitLab 인스턴스 및 Pages 데몬이 사설 네트워크 또는 방화벽 뒤에 배포된 경우, GitLab Pages 웹 사이트는 해당 사설 네트워크에 액세스 권한이있는 장치/사용자에게만 액세스할 수 있습니다.

Public Suffix List에 도메인 추가

Public Suffix List는 브라우저가 하위 도메인을 처리하는 방법을 결정하는 데 사용됩니다. GitLab 인스턴스가 공개 회원이 GitLab Pages 사이트를 만들 수 있도록 허용한다면, 해당 사용자가 페이지 도메인(example.io)에서 하위 도메인을 생성할 수 있도록 허용하고, supercookies 등을 받아 들이지 않도록 하기 위해 도메인을 Public Suffix List에 추가합니다.

이 지침에 따라 GitLab Pages 하위 도메인을 제출하세요. 예를 들어, 도메인이 example.io인 경우 example.io가 Public Suffix List에 추가되도록 요청해야합니다. GitLab.com은 2016년에 gitlab.io를 추가했습니다.

DNS 구성

GitLab Pages는 자체 가상 호스트에서 실행되도록 예상합니다. DNS 서버/공급업체에서 GitLab이 실행되는 호스트를 가리키는 와일드카드 DNS A 레코드를 추가하세요. 예를 들어, 항목은 다음과 같습니다: 

*.example.io. 1800 IN A    192.0.2.1
*.example.io. 1800 IN AAAA 2001:db8::1

여기서 example.io는 GitLab Pages가 서비스되는 도메인이며, 192.0.2.1은 GitLab 인스턴스의 IPv4 주소이고, 2001:db8::1은 IPv6 주소입니다. IPv6가 없는 경우 AAAA 레코드는 생략할 수 있습니다.

URL 경로에 대한 네임 스페이스, 와일드카드 DNS를 사용하지 않는 경우

Status: Beta
Self-Managed GitLab의 경우, 기본적으로이 기능을 사용할 수 있습니다. GitLab.com 및 GitLab Dedicated의 경우,이 기능을 사용할 수 없습니다. 이 기능은 제품으로 사용할 준비가되지 않았습니다.

전제 조건:

  • 인스턴스는 Linux 패키지 설치 방법을 사용해야합니다.
  • 설치에 기본 auth_redirect_uri를 사용해야합니다.

와일드카드 DNS에 대한 요구 사항을 제거하려면 URL 경로의 네임 스페이스를 지원해야하는 경우:

  1. /etc/gitlab/gitlab.rb에 gitlab_pages["namespace_in_path"] = true를 추가하여 이 기능에 대한 GitLab Pages 플래그를 활성화합니다.

  2. DNS 공급업체에서 example.io를 추가합니다. example.io를 도메인 이름으로, 192.0.0.0를 IP 주소의 IPv4 버전으로 대체합니다. 항목은 다음과 같습니다: 

    example.io          1800 IN A    192.0.0.0

  3. 선택 사항입니다. GitLab 인스턴스에 IPv6 주소가 있는 경우 해당 주소에 대한 항목도 추가하세요. example.io를 도메인 이름으로, 2001:db8::1를 IP 주소의 IPv6 버전으로 대체합니다. 항목은 다음과 같습니다: 

    example.io          1800 IN AAAA 2001:db8::1

이 예제에는 다음이 포함되어 있습니다:

  • example.io: GitLab Pages가 서비스되는 도메인.

사용자 정의 도메인을위한 DNS 구성

사용자 정의 도메인을 지원해야하는 경우, Pages 루트 도메인의 모든 하위 도메인은 Pages 데몬 전용으로 사용되는 보조 IP(secondary IP)를 가리켜야 합니다. 이 구성 없이 사용자는 자체 사용자 정의 도메인을 사용하여 페이지를 가리킬 수 없습니다.

예를 들어, 항목은 다음과 같습니다: 

example.com   1800 IN A    192.0.2.1
*.example.io. 1800 IN A    192.0.2.2

이 예제에는 다음이 포함되어 있습니다:

  • example.com: GitLab 도메인.
  • example.io: GitLab Pages가 서비스되는 도메인.
  • 192.0.2.1: GitLab 인스턴스의 기본 IP.
  • 192.0.2.2: GitLab Pages 전용 보조 IP. 기본 IP와 달라야합니다.
note
GitLab 도메인을 사용자 페이지를 제공하기 위해 사용하지 않아야합니다. 자세한 정보는 보안 섹션을 참조하세요.

구성

귀하의 요구에 따라 GitLab Pages를 4가지 다른 방식으로 설정할 수 있습니다.

다음 예는 가장 쉬운 설정부터 가장 고급 설정까지 나열되어 있습니다. 절대적인 최소 요구 사항은 모든 구성에서 필요한 와일드카드 DNS를 설정하는 것입니다.

와일드카드 도메인

전제 조건:

URL scheme: http://<namespace>.example.io/<project_slug>

다음은 Pages를 사용할 수 있는 최소한의 설정입니다. 이 설정은 아래에서 설명하는 모든 설정의 기반입니다. NGINX는 모든 요청을 데몬으로 프록시합니다. Pages 데몬은 외부 세계에서 수신하지 않습니다.

  1. /etc/gitlab/gitlab.rb에서 GitLab Pages의 외부 URL을 설정합니다: 

    external_url "http://example.com" # 여기서의 external_url은 참고용입니다
pages_external_url 'http://example.io' # 중요: external_url의 하위 도메인이 아니어야 하며, http://pages.example.com이 아니어야 합니다

  2. GitLab 재구성.

이 구성에 대한 비디오 자습서를 시청하십시오.

와일드카드 도메인 없는 Pages 도메인

상태: 베타

플래그: Self-Managed형 GitLab의 경우, 기본적으로이 기능을 사용할 수 있습니다. GitLab.com 및 GitLab Dedicated의 경우,이 기능을 사용할 수 없습니다. 이 기능은 프로덕션 환경으로 준비되지 않았습니다.

이 구성은 GitLab Pages의 최소한의 설정입니다. 이 설정은 모든 다른 구성의 기반이 됩니다. 이 구성에서는 NGINX가 모든 요청을 데몬으로 프록시하고 있으며, GitLab Pages 데몬은 외부 세계에서 수신하지 않습니다.

전제 조건:

  • 인스턴스는 Linux 패키지 설치 방법을 사용해야 합니다.
  • 와일드카드 없이 DNS 설정를 구성했습니다.

  1. /etc/gitlab/gitlab.rb에서 GitLab Pages의 외부 URL을 설정하고 피처 플래그를 활성화합니다: 

    # 여기서 External_url 필드는 참고용입니다.
external_url "http://example.com"
pages_external_url 'http://example.io'
   
pages_nginx['enable'] = true
   
#이 기능을 활성화하려면이 플래그를 설정하십시오
gitlab_pages["namespace_in_path"] = true

  2. GitLab 재구성.

NGINX는 사용자 정의 프록시 헤더 X-Gitlab-Namespace-In-Path를 사용하여 네임스페이스를 GitLab Pages 데몬에 보냅니다.

생성된 URL scheme은 http://example.io/<namespace>/<project_slug>입니다.

TLS 지원이 있는 와일드카드 도메인

전제 조건:

URL scheme: https://<namespace>.example.io/<project_slug>

NGINX는 모든 요청을 데몬으로 프록시합니다. Pages 데몬은 외부 세계에서 수신하지 않습니다.

  1. *.example.io에 대한 와일드카드 TLS 인증서 및 키를 /etc/gitlab/ssl에 배치합니다.

  2. /etc/gitlab/gitlab.rb에 다음 구성을 지정합니다: 

    external_url "https://example.com" # 여기서의 external_url은 참고용입니다
pages_external_url 'https://example.io' # 중요: external_url의 하위 도메인이 아니어야 하며, https://pages.example.com이 아니어야 합니다
   
pages_nginx['redirect_http_to_https'] = true

  3. 인증서 및 키를 example.io.crt 및 example.io.key와 같이 명명하지 않은 경우, 아래에 표시된 전체 경로도 추가해야 합니다: 

    pages_nginx['ssl_certificate'] = "/etc/gitlab/ssl/pages-nginx.crt"
pages_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/pages-nginx.key"
  4. GitLab 재구성.
  5. Pages Access Control을 사용 중이라면 GitLab Pages의 리디렉션 URI를 업데이트합니다. 시스템 OAuth 애플리케이션의 리디렉션 URI를 HTTPS 프로토콜을 사용하도록 업데이트합니다.
caution
한 인스턴스에 대해 여러 와일드카드를 지원하지 않습니다. 인스턴스 당 하나의 와일드카드만 지정할 수 있습니다.
caution
GitLab Pages는 OAuth 애플리케이션을 업데이트하지 않습니다. 재구성하기 전에/etc/gitlab/gitlab-secrets.json에서gitlab_pages 섹션을 제거하고 gitlab-ctl reconfigure을 실행하십시오. 자세한 내용은 GitLab Pages는 OAuth를 재생성하지 않음을 참조하십시오.

TLS 지원이 있는 와일드카드 도메인 없는 Pages 도메인

상태: 베타

플래그: Self-Managed형 GitLab의 경우, 기본적으로이 기능을 사용할 수 있습니다. GitLab.com 및 GitLab Dedicated의 경우,이 기능을 사용할 수 없습니다. 이 기능은 프로덕션 환경으로 준비되지 않았습니다.

전제 조건:

  • 인스턴스는 Linux 패키지 설치 방법을 사용해야 합니다.
  • 와일드카드 없이 DNS 설정를 구성했습니다.
  • example.io와 같이 도메인을 포함하는 TLS 인증서가 있어야 합니다.

이 구성에서 NGINX는 모든 요청을 데몬으로 프록시합니다. GitLab Pages 데몬은 외부 세계에서 수신하지 않습니다:

  1. 전제 조건으로 언급된 TLS 인증서 및 키를 /etc/gitlab/ssl에 추가하십시오.

  2. /etc/gitlab/gitlab.rb에 다음 구성을 지정합니다: 

    # 이곳에 있는 외부 URL 필드는 참고용입니다.
external_url "https://example.com"
pages_external_url 'https://example.io'
   
pages_nginx['enable'] = true
pages_nginx['redirect_http_to_https'] = true
   
# 이 기능을 활성화하려면이 플래그를 설정하십시오
gitlab_pages["namespace_in_path"] = true

  3. TLS 인증서 및 키가 example.io.crt 및 exmaple.io.key와 같은 도메인 이름과 일치하지 않은 경우, 인증서 및 키 파일의 전체 경로를 /etc/gitlab/gitlab.rb에 추가해야 합니다: 

    pages_nginx['ssl_certificate'] = "/etc/gitlab/ssl/pages-nginx.crt"
pages_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/pages-nginx.key"
  4. GitLab 재구성.

  5. Pages Access Control을 사용 중이라면 GitLab Pages의 리디렉션 URI를 업데이트합니다. 시스템 OAuth 애플리케이션의 리디렉션 URI를 HTTPS 프로토콜을 사용하도록 업데이트합니다.

    caution
    GitLab Pages는 OAuth 응용프로그램을 업데이트하지 않으며 기본 auth_redirect_uri가 https://example.io/projects/auth로 업데이트됩니다. 재구성하기 전에/etc/gitlab/gitlab-secrets.json에서gitlab_pages 섹션을 제거하고 gitlab-ctl reconfigure을 실행하십시오. 자세한 내용은 GitLab Pages는 OAuth를 재생성하지 않음을 참조하십시오.

TLS-terminating Load Balancer와 와일드카드 도메인

전제 조건:

URL 스키마: https://<namespace>.example.io/<project_slug>

이 설정은 기본적으로 Amazon Web Services에 GitLab POC를 설치할 때 사용할 수 있도록 의도되었습니다. 이는 HTTPS 연결을 수신하고 TLS 인증서를 관리하며 HTTP 트래픽을 해당 인스턴스로 전달하는 TLS-terminating clasic 로드 밸런서를 포함합니다.

  1. /etc/gitlab/gitlab.rb에서 다음 구성을 지정하세요. 

    external_url "https://example.com" # 여기에 있는 external_url은 참조용입니다.
pages_external_url 'https://example.io' # 중요: external_url의 하위 도메인이 아니므로 https://pages.example.com이 될 수 없음
   
pages_nginx['enable'] = true
pages_nginx['listen_port'] = 80
pages_nginx['listen_https'] = false
pages_nginx['redirect_http_to_https'] = true

  2. GitLab을 재구성하세요.

전역 설정

아래 표는 리눅스 패키지 설치에 있는 페이지에서 알고 있는 모든 구성 설정과 그 기능을 보여줍니다. 이러한 옵션은 /etc/gitlab/gitlab.rb에서 조정할 수 있으며 GitLab을 재구성한 후 적용됩니다. 이러한 설정 중 대부분은 환경에서 페이지 데몬이 실행되는 방식 및 콘텐츠를 제공하는 데 관리되지 않는 한 매뉴얼으로 구성할 필요가 없습니다.

| 설정 | 설명 | |—————————-|——————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————| | pages_external_url | GitLab Pages에 액세스 가능한 URL로, 프로토콜(HTTP/HTTPS)을 포함합니다. https://를 사용하는 경우 추가 구성이 필요합니다. 자세한 내용은 TLS 지원 와일드카드 도메인 및 TLS 지원 사용자 정의 도메인을 참조하세요. | | gitlab_pages[] | | | access_control | 액세스 제어를 활성화할지 여부를 나타냅니다. | | api_secret_key | GitLab API의 인증에 사용되는 비밀 키가 있는 파일의 전체 경로입니다. 설정되지 않은 경우 자동으로 생성됩니다. | | artifacts_server | GitLab Pages에서 artifacts를 보이도록 설정합니다. | | artifacts_server_timeout | 프록시된 요청에 대한 타임아웃(초)입니다. | | artifacts_server_url | 아티팩트 요청을 프록시하기 위한 API URL입니다. 기본값은 GitLab external URL + /api/v4로, 예를 들어 https://gitlab.com/api/v4입니다. 별도의 Pages 서버를 실행할 때, 이 URL은 주로 GitLab 서버의 API를 가리켜야 합니다. | …

[고려대상 디렉터리 계속]

고급 구성

와일드카드 도메인 외에도 사용자 정의 도메인과 함께 GitLab Pages를 구성할 수 있는 옵션이 있습니다. 다시 말하지만, 여기에는 두 가지 옵션이 있습니다: TLS 인증서가 있는 경우와 없는 경우입니다. 가장 간단한 설정은 TLS 인증서가 없는 경우입니다. 어떤 경우에도보조 IP가 필요합니다. IPv6와 IPv4 주소를 모두 가지고 있다면 두 주소를 모두 사용할 수 있습니다.

사용자 정의 도메인

전제 조건:

URL 구조: http://<namespace>.example.io/<project_slug> 및 http://custom-domain.com

이 경우에는 페이지 데몬이 실행되고 NGINX는 여전히 데몬으로의 요청을 프록시하지만, 데몬 역시 외부에서의 요청을 받을 수 있습니다. 사용자 정의 도메인은 지원되지만 TLS는 지원되지 않습니다.

  1. /etc/gitlab/gitlab.rb에서 다음 구성을 지정합니다. 

    external_url "http://example.com" # 여기서의 external_url은 참조용입니다.
pages_external_url 'http://example.io' # 중요: external_url의 하위 도메인이 아니므로 http://pages.example.com이 될 수 없습니다
nginx['listen_addresses'] = ['192.0.2.1'] # GitLab 인스턴스의 기본 IP
pages_nginx['enable'] = false
gitlab_pages['external_http'] = ['192.0.2.2:80', '[2001:db8::2]:80'] # GitLab Pages 데몬의 보조 IP

    만약 IPv6가 없다면 IPv6 주소를 생략할 수 있습니다.

  2. GitLab 재구성.

TLS 지원이 포함된 사용자 정의 도메인

전제 조건:

URL 구조: https://<namespace>.example.io/<project_slug> 및 https://custom-domain.com

이 경우에는 페이지 데몬이 실행되고 NGINX는 여전히 데몬으로의 요청을 프록시하지만, 데몬 역시 외부에서의 요청을 받을 수 있습니다. 사용자 정의 도메인 및 TLS가 지원됩니다.

  1. *.example.io의 와일드카드 LTS 인증서와 키를 /etc/gitlab/ssl에 배치합니다.

  2. /etc/gitlab/gitlab.rb에서 다음 구성을 지정합니다. 

    external_url "https://example.com" # 여기서의 external_url은 참조용입니다.
pages_external_url 'https://example.io' # 중요: external_url의 하위 도메인이 아니므로 https://pages.example.com이 될 수 없습니다
nginx['listen_addresses'] = ['192.0.2.1'] # GitLab 인스턴스의 기본 IP
pages_nginx['enable'] = false
gitlab_pages['external_http'] = ['192.0.2.2:80', '[2001:db8::2]:80'] # GitLab Pages 데몬의 보조 IP
gitlab_pages['external_https'] = ['192.0.2.2:443', '[2001:db8::2]:443'] # GitLab Pages 데몬의 보조 IP
# 페이지를 HTTP에서 HTTPS로 리다이렉션
gitlab_pages['redirect_http'] = true

    만약 IPv6가 없다면 IPv6 주소를 생략할 수 있습니다.

  3. 만약 인증서를 example.io.crt 및 키를 example.io.key로 명명하지 않았다면, 아래와 같이 전체 경로를 추가해야 합니다. 

    gitlab_pages['cert'] = "/etc/gitlab/ssl/example.io.crt"
gitlab_pages['cert_key'] = "/etc/gitlab/ssl/example.io.key"
  4. GitLab 재구성.
  5. 페이지 액세스 제어를 사용 중이라면, GitLab Pages 시스템 OAuth 애플리케이션의 리디렉션 URI를 HTTPS 프로토콜을 사용하도록 업데이트합니다.

사용자 정의 도메인 확인

악의적인 사용자가 해당 도메인에 속하지 않는 도메인을 탈취하는 것을 방지하기 위해, GitLab은 사용자 정의 도메인 확인을 지원합니다. 사용자가 사용자 정의 도메인을 추가할 때는 GitLab이 제어하는 확인 코드를 그 도메인의 DNS 레코드에 추가하여 소유권을 증명해야 합니다.

caution
도메인 확인을 해제하는 것은 안전하지 않으며 다양한 취약점으로 이어질 수 있습니다. 만약 이를 사용하지 않도록 설정한다면, 페이지 루트 도메인 자체가 보조 IP를 가리키지 않도록 하거나 루트 도메인을 프로젝트의 사용자 정의 도메인으로 추가해야 합니다. 그렇지 않으면 어떤 사용자든 해당 도메인을 자신의 프로젝트에 사용자 정의 도메인으로 추가할 수 있습니다.

사용자 기반이 비공개이거나 신뢰할 수 있다면 확인 요구 사항을 비활성화할 수 있습니다:

  1. 왼쪽 사이드바에서 맨 아래쪽에 있는 관리 영역을 선택합니다.
  2. 설정 > 환경 설정을 선택합니다.
  3. Pages를 확장합니다.
  4. 사용자가 사용자 정의 도메인의 소유권을 증명하도록 요구 확인란을 지웁니다. 이 설정은 기본적으로 활성화되어 있습니다.

Let’s Encrypt 통합

GitLab Pages의 Let’s Encrypt 통합을 사용하면 사용자는 사용자 정의 도메인으로 제공되는 GitLab Pages 사이트에 Let’s Encrypt SSL 인증서를 추가할 수 있습니다.

이를 활성화하려면:

  1. 도메인 만료에 대한 알림을 받고 싶은 이메일 주소를 선택합니다.
  2. 왼쪽 사이드바에서 맨 아래쪽에 있는 관리 영역을 선택합니다.
  3. 설정 > 환경 설정을 선택합니다.
  4. Pages를 확장합니다.
  5. 알림을 받을 이메일 주소를 입력하고 Let’s Encrypt의 서비스 약관에 동의합니다.
  6. 변경 사항 저장을 선택합니다.

액세스 제어

GitLab Pages 액세스 제어는 프로젝트별로 구성할 수 있으며, 사용자의 프로젝트 멤버십에 기반하여 페이지 사이트에 액세스할 수 있도록 제어합니다.

액세스 제어는 페이지가 OAuth 애플리케이션으로 등록되는 방식으로 동작합니다. 인증되지 않은 사용자가 비공개 페이지 사이트에 액세스를 요청하면 페이지 데몬이 사용자를 GitLab으로 리디렉션합니다. 인증이 성공하면 사용자는 토큰이 포함된 쿠키에서 올바른 페이지로 리디렉션됩니다. 이 쿠키는 비밀 키로 서명되어 있어 변경이 감지될 수 있습니다.

비공개 사이트의 리소스에 대한 각 요청은 해당 토큰을 사용하여 페이지에서 인증됩니다. 페이지는 요청을 받을 때마다 사용자가 해당 사이트를 읽을 수 있는지 확인하기 위해 GitLab API에 요청을 수행합니다.

Pages 액세스 제어는 기본적으로 비활성화되어 있습니다. 이를 활성화하려면:

  1. /etc/gitlab/gitlab.rb에 활성화합니다. 

    gitlab_pages['access_control'] = true
  2. GitLab 재구성.
  3. 사용자는 이제 프로젝트 설정에서 이를 구성할 수 있습니다.
note
이 설정이 여러 노드로 구성된 설정에서 효과적으로 작동하려면 모든 App 노드 및 Sidekiq 노드에 적용해야 합니다.

인증 범위가 줄어든 Pages 사용하기

기본적으로 Pages 데몬은 api 범위를 사용하여 인증합니다. 이를 구성 가능합니다. 예를 들어, /etc/gitlab/gitlab.rb에서 범위를 read_api로 줄일 수 있습니다. 

gitlab_pages['auth_scope'] = 'read_api'

인증에 사용할 범위는 GitLab Pages OAuth 애플리케이션 설정과 일치해야 합니다. 기존 애플리케이션의 사용자는 GitLab Pages OAuth 애플리케이션을 수정해야 합니다. 이를 위해 다음 단계를 따릅니다:

  1. 액세스 제어를 활성화합니다.
  2. 왼쪽 사이드바에서 맨 아래쪽에 있는 관리 영역을 선택합니다.
  3. 애플리케이션을 선택합니다.
  4. GitLab Pages를 확장합니다.
  5. api 범위의 확인란을 지우고 원하는 범위의 확인란을 선택합니다 (예: read_api).
  6. 변경 사항 저장을 선택합니다.

모든 페이지 사이트의 공개 액세스 비활성화

귀하의 GitLab 인스턴스에서 호스팅되는 모든 GitLab Pages 웹 사이트에 대해 액세스 제어를 집행할 수 있습니다. 이렇게 하면 인증된 사용자만 액세스할 수 있습니다. 이 설정은 개별 프로젝트의 사용자가 설정한 액세스 제어를 재정의합니다.

이렇게 함으로써 페이지 웹사이트에 게시된 정보를 인스턴스의 사용자들에게만 제한하는 데 도움이 될 수 있습니다.

다음과 같이 수행할 수 있습니다:

  1. 왼쪽 사이드바에서 맨 아래에서 관리 영역(Admin Area)을 선택합니다.
  2. 설정 > 환경설정을 선택합니다.
  3. Pages를 확장합니다.
  4. 페이지 사이트의 공개 액세스 비활성화 확인란을 선택합니다.
  5. 변경 사항 저장을 선택합니다.
note
관리 영역에 이 설정이 표시되려면 먼저 액세스 제어를 활성화해야 합니다.

프록시 뒤에서 실행

GitLab의 나머지 부분과 마찬가지로, 페이지는 외부 인터넷 연결이 프록시로 제한되는 환경에서 사용할 수 있습니다. GitLab Pages에 프록시를 사용하려면 다음을 수행하세요:

  1. /etc/gitlab/gitlab.rb에서 구성: 

    gitlab_pages['env']['http_proxy'] = 'http://example:8080'

  2. 변경 사항이 적용되려면 GitLab을 다시 구성하세요.

사용자 정의 인증기관(CA) 사용

사용자 지정 CA가 발급한 인증서를 사용할 때, 사용자 지정 CA가 인식되지 않으면 액세스 제어 및 HTML 작업 아티팩트의 온라인 보기가 작동하지 않습니다.

이로 인해 일반적으로 다음과 같은 오류가 발생합니다: Post /oauth/token: x509: certificate signed by unknown authority.

Linux 패키지 설치의 경우, 사용자 정의 CA 설치를 통해 이 문제를 해결할 수 있습니다.

자체 컴파일된 설치의 경우 시스템 인증서 리포지터리에 사용자 정의 인증기관(CA)을 설치하여 이 문제를 해결할 수 있습니다.

ZIP 서비스 및 캐시 구성

caution
이 지침은 GitLab 인스턴스의 일부 고급 설정에 관련되어 있습니다. 권장되는 기본값은 GitLab Pages에 이미 설정되어 있습니다. 이러한 설정을 변경해야 하는 경우에만 변경하세요. 극도의 주의를 기울여 사용하세요.

GitLab Pages는 객체 리포지터리를 통해 ZIP 아카이브에서 콘텐츠를 제공할 수 있습니다 (디스크 리포지터리 지원에 대한 이슈가 존재). ZIP 아카이브에서 콘텐츠를 제공할 때 성능을 향상시키기 위해 인메모리 캐시를 사용합니다. 다음 구성 플래그를 변경하여 캐시 동작을 수정할 수 있습니다.

설정 설명
zip_cache_expiration ZIP 아카이브의 캐시 만료 간격. 유효하지 않은 콘텐츠를 제공하지 않도록 하려면 0보다 커야 합니다. 기본값은 60초입니다.
zip_cache_cleanup 아카이브가 이미 만료된 경우 메모리에서 정리되는 간격. 기본값은 30초입니다.
zip_cache_refresh zip_cache_expiration 이전에 아카이브가 액세스되면 메모리에서 확장되는 시간 간격입니다. 이는 아카이브가 메모리에서 확장되는지 여부를 결정하는 데 zip_cache_expiration과 함께 작동합니다. 중요한 세부 정보에 대한 자세한 내용은 아래 예제를 참조하세요. 기본값은 30초입니다.
zip_open_timeout ZIP 아카이브를 열 수 있는 최대 시간. 큰 아카이브나 느린 네트워크 연결의 경우 이 시간을 늘릴 수 있으며, 이는 페이지를 제공하는 데 대기 시간에 영향을 줄 수 있습니다. 기본값은 30초입니다.
zip_http_client_timeout ZIP HTTP 클라이언트의 최대 시간. 기본값은 30분입니다.

ZIP 캐시 갱신 예시

아카이브가 zip_cache_expiration 이전에 액세스되고 남은 시간이 zip_cache_refresh와 같거나 작으면 (디폴트 30초), 캐시에서 아카이브가 새로 고쳐집니다. 예를 들어, archive.zip가 시간 0초에서 액세스되면 60초 이후에 만료됩니다 (zip_cache_expiration의 기본값). 아래 예제에서 15초 후에 아카이브가 다시 열리면 (45초) 갱신되지 않습니다, 남은 만료 시간이 (45초)이 zip_cache_refresh (기본값 30초)보다 크기 때문입니다. 그러나 아카이브가 45초 후에 다시 접근되면 (처음 열린 시간부터) 갱신됩니다. 이로써 아카이브가 zip_cache_expiration (60초)에 이르기 전에 메모리에서 유지되는 시간이 45초 + zip_cache_expiration (60초) 총 105초가 됩니다.

아카이브가 zip_cache_expiration에 도달하면 만료됩니다. 그리고 그 다음 zip_cache_cleanup 간격에 삭제됩니다.

ZIP 캐시 구성

HTTP Strict Transport Security (HSTS) 지원

HTTP Strict Transport Security (HSTS)는 gitlab_pages['headers'] 설정 옵션을 통해 활성화할 수 있습니다. HSTS는 브라우저에게 방문 중인 웹 사이트가 항상 HTTPS를 통해 콘텐츠를 제공해야 함을 알려 공격자가 후속 연결을 암호화되지 않은 상태로 발생시키지 못하도록합니다. 또한 HTTPS로 리디렉션되기 전에 브라우저가 암호화되지 않은 HTTP 채널을 시도하지 않도록하여 페이지 로딩 속도를 향상시킬 수 있습니다. 

gitlab_pages['headers'] = ['Strict-Transport-Security: max-age=63072000']

페이지 프로젝트 리디렉트 제한

GitLab Pages에는 성능에 미치는 영향을 최소화하기 위해 _redirects 파일의 기본 제한이 기본 제공됩니다. 이러한 제한을 증가 또는 감소시키고 싶다면 이러한 제한을 구성할 수 있습니다. 

gitlab_pages['redirects_max_config_size'] = 131072
gitlab_pages['redirects_max_path_segments'] = 50
gitlab_pages['redirects_max_rule_count'] = 2000

환경 변수 사용

Pages 데몬에 환경 변수를 전달할 수 있습니다 (예: 피처 플래그를 활성화 또는 비활성화).

구성 가능한 디렉터리 기능을 비활성화하려면:

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

    gitlab_pages['env'] = {
  'FF_CONFIGURABLE_ROOT_DIR' => "false"
}

  2. 파일을 저장하고 GitLab을 다시 구성하세요: 

    sudo gitlab-ctl reconfigure

데몬의 상세 로깅 활성화

GitLab Pages 데몬의 세부 로깅을 설정하려면 다음 단계를 따르세요.

  1. 기본적으로 데몬은 INFO 수준으로만 기록합니다. DEBUG 수준의 이벤트를 기록하도록 변경하려면 /etc/gitlab/gitlab.rb에서 설정해야 합니다: 

    gitlab_pages['log_verbose'] = true

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

상관 ID 전파

propagate_correlation_id를 true로 설정하면 역방향 프록시 뒤에 설치된 경우 GitLab Pages에 전송된 요청에 상관 ID를 생성 및 설정할 수 있습니다. 역방향 프록시가 X-Request-ID 헤더 값을 설정하면 해당값이 요청 체인으로 전파됩니다. 사용자는 로그에서 상관 ID를 찾을 수 있습니다.

상관 ID 전파를 활성화하려면:

  1. /etc/gitlab/gitlab.rb 파일에서 매개변수를 true로 설정하세요: 

    gitlab_pages['propagate_correlation_id'] = true

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

저장 경로 변경

GitLab Pages 콘텐츠의 기본 경로를 변경하려면 다음 단계를 따르세요.

  1. 페이지는 기본적으로 /var/opt/gitlab/gitlab-rails/shared/pages에 저장됩니다. 다른 위치에 저장하려면 /etc/gitlab/gitlab.rb에서 설정하세요: 

    gitlab_rails['pages_path'] = "/mnt/storage/pages"

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

역방향 프록시 요청을위한 리스너 구성

GitLab Pages의 프록시 리스너를 구성하려면 아래 단계를 따르세요.

  1. 기본적으로 리스너는 localhost:8090에서 요청을 수신하도록 구성됩니다.

    비활성화하려면 /etc/gitlab/gitlab.rb에서 구성해야 합니다: 

    gitlab_pages['listen_proxy'] = nil

    다른 포트에서도 수신하도록하려면 /etc/gitlab/gitlab.rb에서 다음과 같이 구성해야 합니다: 

    gitlab_pages['listen_proxy'] = "localhost:10080"

  2. GitLab을 다시 구성.

각 GitLab Pages 사이트의 전역 최대 크기 설정

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

사전 요구 사항:

  • 인스턴스에 대한 관리자 액세스가 필요합니다.

프로젝트의 전역 최대 페이지 크기를 설정하려면 다음을 수행하세요:

  1. 왼쪽 사이드바에서 가장 아래에서 관리자 영역을 선택합니다.
  2. 설정 > 기본설정을 선택합니다.
  3. 페이지를 확장합니다.
  4. 페이지의 최대 크기에 값을 입력합니다. 기본값은 100입니다.
  5. 변경 사항 저장을 선택합니다.

그룹의 각 GitLab Pages 사이트의 최대 크기 설정

Tier: Premium, Ultimate Offering: Self-Managed

사전 요구 사항:

  • 인스턴스에 대한 관리자 액세스가 필요합니다.

상속된 설정을 재정의하여 그룹 내 각 GitLab Pages 사이트의 최대 크기를 설정하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 그룹을 찾습니다.
  2. 설정 > 일반을 선택합니다.
  3. 페이지를 확장합니다.
  4. 최대 크기 아래에 MB 단위로 값을 입력합니다.
  5. 변경 사항 저장을 선택합니다.

프로젝트의 GitLab Pages 사이트의 최대 크기 설정

Tier: Premium, Ultimate Offering: Self-Managed

사전 요구 사항:

  • 인스턴스에 대한 관리자 액세스가 필요합니다.

상속된 설정을 재정의하여 프로젝트의 GitLab Pages 사이트의 최대 크기를 설정하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
  2. 배포 > Pages를 선택합니다.
  3. 페이지의 최대 크기에 크기(MB)를 입력합니다.
  4. 변경 사항 저장을 선택합니다.

프로젝트당 GitLab Pages 사용자 정의 도메인의 최대 수 설정

사전 요구 사항:

  • 인스턴스에 대한 관리자 액세스가 필요합니다.

프로젝트당 GitLab Pages 사용자 정의 도메인의 최대 수를 설정하려면:

  1. 왼쪽 사이드바에서 가장 아래에서 관리자 영역을 선택합니다.
  2. 설정 > 기본설정을 선택합니다.
  3. 페이지를 확장합니다.
  4. 프로젝트 당 사용자 정의 도메인의 최대 수에 값을 입력합니다. 무제한 도메인의 경우 0을 사용합니다.
  5. 변경 사항 저장을 선택합니다.

GitLab Pages 웹 사이트당 파일의 최대 수 설정

GitLab Pages 웹 사이트당 파일 항목(디렉터리 및 심볼릭 링크 포함)의 총 수는 웹 사이트당 200,000개로 제한됩니다.

Self-Managed형 인스턴스에서 제한을 업데이트할 수 있습니다. GitLab Rails 콘솔을 사용하세요.

자세한 내용은 GitLab 애플리케이션 한도를 참조하세요.

별도의 서버에서 GitLab Pages 실행

GitLab Pages 데몬을 별도의 서버에서 실행하여 주요 응용 프로그램 서버의 부하를 줄일 수 있습니다. 이 구성은 상호 TLS(mTLS)를 지원하지 않습니다. 자세한 내용은 해당 기능 제안을 참조하세요.

별도의 서버에서 GitLab Pages를 구성하려면:

caution
다음 프로시저에는 gitlab-secrets.json 파일을 백업하고 편집하는 단계가 포함됩니다. 이 파일에는 데이터베이스 암호화를 제어하는 비밀이 포함되어 있습니다. 주의하여 진행하십시오.

  1. GitLab 서버에서 비밀 파일을 백업합니다: 

    cp /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.bak

  2. GitLab 서버에서 Pages를 사용하도록 하려면 /etc/gitlab/gitlab.rb에 다음을 추가합니다: 

    pages_external_url "http://<pages_server_URL>"

  3. 선택적으로 접근 제어를 활성화하려면 /etc/gitlab/gitlab.rb에 다음을 추가합니다: 

    gitlab_pages['access_control'] = true
  4. 개체 리포지터리를 설정하려면 다음 중 하나를 수행하세요:

  5. 변경 사항이 적용되려면 GitLab 서버를 다시 구성합니다(../restart_gitlab.md#reconfigure-a-linux-package-installation). gitlab-secrets.json 파일은 새 구성으로 업데이트됩니다.

  6. 새 서버를 설정합니다. 이것이 Pages 서버가 됩니다.

  7. Pages 서버에서 Linux 패키지를 사용하여 GitLab을 설치하고 /etc/gitlab/gitlab.rb를 수정하여 다음을 포함합니다: 

    roles ['pages_role']
   
pages_external_url "http://<pages_server_URL>"
   
gitlab_pages['gitlab_server'] = 'http://<gitlab_server_IP_or_URL>'
   
## 3단계에서 접근 제어를 활성화한 경우
gitlab_pages['access_control'] = true

  8. GitLab 서버에서 사용자 정의 UID/GID 설정이 있는 경우 해당 설정을 Pages 서버 /etc/gitlab/gitlab.rb에 추가해야 합니다. 그렇지 않을 경우 GitLab 서버에서 실행 중인 gitlab-ctl reconfigure 명령이 파일 소유권을 변경하고 Pages 요청이 실패할 수 있습니다.

  9. Pages 서버에서 비밀 파일을 백업합니다: 

    cp /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.bak

  10. GitLab 서버의 /etc/gitlab/gitlab-secrets.json 파일을 Pages 서버로 복사합니다. 

    # GitLab 서버에서
cp /etc/gitlab/gitlab-secrets.json /mnt/pages/gitlab-secrets.json
   
# Pages 서버에서
mv /var/opt/gitlab/gitlab-rails/shared/pages/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json

  11. 변경 사항이 적용되려면 Pages 서버를 다시 구성합니다(../restart_gitlab.md#reconfigure-a-linux-package-installation).

  12. GitLab 서버에서 /etc/gitlab/gitlab.rb를 수정하여 다음을 수행합니다: 

    pages_external_url "http://<pages_server_URL>"
gitlab_pages['enable'] = false
pages_nginx['enable'] = false
  13. 변경 사항이 적용되려면 GitLab 서버를 다시 구성합니다(../restart_gitlab.md#reconfigure-a-linux-package-installation).

부하를 분산하려면 여러 서버에서 GitLab Pages를 실행할 수 있습니다. DNS 서버를 구성하여 페이지 서버에 대해 여러 IP를 반환하거나 로드 밸런서를 구성하여 IP 수준에서 작동하도록 할 수 있습니다. 여러 서버에서 GitLab Pages를 설정하려면 각 페이지 서버에 대해 위의 프로시저를 수행하십시오.

도메인 소스 구성

GitLab Pages 데몬이 페이지 요청을 서빙할 때 먼저 요청된 URL을 서빙하는 데 사용해야 하는 프로젝트를 식별하고 해당 내용을 어떻게 저장했는지를 식별해야 합니다.

기본적으로 GitLab Pages는 새로운 도메인이 요청될 때마다 내부 GitLab API를 사용합니다. Pages는 API에 연결할 수 없으면 시작하지 못합니다. 도메인 정보도 응답 요청을 가속화하기 위해 Pages 데몬에 캐시됩니다.

일반적인 문제에 대해서는 문제 해결을 참조하세요.

더 자세한 내용은 이 블로그 포스트를 참조하세요.

GitLab API 캐시 구성

API 기반 구성은 페이지 제공의 성능과 신뢰성을 향상시키기 위해 캐싱 메커니즘을 사용합니다. 캐시 동작은 캐시 설정을 변경하여 수정할 수 있지만, 권장되는 값이 이미 설정되어 있으며 필요한 경우에만 수정해야 합니다. 이러한 값을 잘못 구성하면 일시적 또는 지속적 오류 또는 이전 콘텐츠를 제공하는 Pages Daemon이 발생할 수 있습니다.

note
만료, 간격 및 시간 초과 플래그는 Go 기간 형식을 사용합니다. 기간 문자열은 부호가있는 십진수 순서도와 선택적 소수 및 단위 접미사로 구성된 것으로, 300ms, 1.5h, 2h45m과 같습니다. 유효한 시간 단위는 ns, us (또는 µs), ms, s, m, h 입니다.

예시:

  • gitlab_cache_expiry를 증가시키면 캐시에 항목을 더 오래 유지할 수 있습니다. 이 설정은 GitLab Pages와 GitLab Rails 간 통신이 안정적이지 않을 때 유용할 수 있습니다.
  • gitlab_cache_refresh를 증가시키면 GitLab Pages가 도메인의 구성을 GitLab Rails에서 요청하는 빈도가 낮아집니다. 이 설정은 GitLab Pages가 GitLab API에 너무 많은 요청을 생성하고 콘텐츠가 자주 변경되지 않을 때 유용할 수 있습니다.
  • gitlab_cache_cleanup을 감소시키면 캐시에서 만료된 항목을 더 자주 제거하여 페이지 노드의 메모리 사용량을 줄일 수 있습니다.
  • gitlab_retrieval_timeout을 감소시키면 GitLab Rails에 대한 요청을 더 빨리 중지할 수 있습니다. 증가시키면 API로부터 응답을 받을 시간이 더 많이 소요되어 느린 네트워킹 환경에서 유용합니다.
  • gitlab_retrieval_interval을 감소시키면 API에 대한 요청을 더 자주 수행합니다. 예를 들어, 연결 시간 초과와 같이 API에서 오류 응답을 받을 때 유용합니다.
  • gitlab_retrieval_retries을 감소시키면 도메인의 구성이 오류를 보고하기 전에 자동으로 해결을 시도하는 횟수를 줄일 수 있습니다.

객체 리포지터리 설정

다음 객체 리포지터리 설정은 다음과 같습니다:

  • 자체 컴파일된 설치에서 pages: 및 object_store: 하위에 중첩됨.
  • Linux 패키지 설치에서는 pages_object_store_로 접두어가 붙습니다.
설정 설명 기본값
enabled 객체 리포지터리가 활성화되었는지 여부 false
remote_directory 페이지 사이트 콘텐츠가 저장된 버킷의 이름  
connection 설명된 여러 연결 옵션  
note
NFS 서버를 중지하고 연결을 해제하려면 명시적으로 로컬 리포지터리를 비활성화해야 합니다.

S3 호환 연결 설정

통합된 객체 리포지터리 설정을 사용해야 합니다.

다양한 제공업체에 대한 연결 설정을 보려면 다양한 제공업체에 대한 연결 설정 구성을 참조하세요.

페이지 배포를 객체 리포지터리로 마이그레이션

기존 페이지 배포 개체 (zip 아카이브)는 다음 중 하나에 저장될 수 있습니다:

기존 페이지 배포를 로컬 리포지터리에서 객체 리포지터리로 마이그레이션: 

sudo gitlab-rake gitlab:pages:deployments:migrate_to_object_storage

모든 페이지 배포가 성공적으로 마이그레이션되었는지 추적하고 확인하려면 PostgreSQL 콘솔을 사용합니다:

  • Linux 패키지 설치의 경우 sudo gitlab-rails dbconsole --database main.
  • 자체 컴파일된 설치의 경우 sudo -u git -H psql -d gitlabhq_production.

아래 코드에서 store=2인 objectstg (전체 store=1에 대한 개수)가 모든 페이지 배포 개체 개수임을 확인합니다. 

gitlabhq_production=# SELECT count(*) AS total, sum(case when file_store = '1' then 1 else 0 end) AS filesystem, sum(case when file_store = '2' then 1 else 0 end) AS objectstg FROM pages_deployments;

total | filesystem | objectstg
------+------------+-----------
   10 |          0 |        10

모든 것이 올바르게 작동하는지 확인한 후, 페이지 로컬 리포지터리를 비활성화하세요.

페이지 배포를 롤백하여 로컬 리포지터리로 돌아가기

객체 리포지터리로의 마이그레이션이 수행된 후, 페이지 배포를 로컬 리포지터리로 이동할 수 있습니다: 

sudo gitlab-rake gitlab:pages:deployments:migrate_to_local

페이지 로컬 리포지터리 비활성화

객체 리포지터리를 사용하는 경우 불필요한 디스크 사용량/쓰기를 피하기 위해 로컬 리포지터리를 비활성화할 수 있습니다:

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

    gitlab_rails['pages_local_store_enabled'] = false

  2. 변경 사항이 적용되려면 GitLab을 다시 구성하십시오.

다중 노드 환경에서 페이지 네트워크 리포지터리 활성화

대부분의 환경에 대한 우선적인 설정은 객체 리포지터리입니다. 그러나 귀하의 요구 사항에 따라 네트워크 리포지터리를 원하는 경우 별도 서버에서 GitLab Pages 실행를 구성하려면 다음을 수행해야 합니다:

  1. 사용하려는 공유 리포지터리 볼륨이 기본 서버와 목표 Pages 서버 모두에 이미 장착 및 사용 가능한지 확인합니다.

  2. 각 노드의 /etc/gitlab/gitlab.rb를 업데이트하여 다음을 포함합니다: 

    gitlab_pages['enable_disk'] = true
gitlab_rails['pages_path'] = "/var/opt/gitlab/gitlab-rails/shared/pages" # 네트워크 리포지터리의 경로
  3. Pages를 별도 서버로 전환하세요.

별도 서버에서 Pages를 성공적으로 구성하면 공유 리포지터리 볼륨에 대한 접근 권한이 해당 서버만 필요합니다. 단일 노드 환경으로 다시 마이그레이션해야 하는 경우를 대비하여 기본 서버에 공유 리포지터리 볼륨을 유지하는 것을 고려해보세요.

ZIP 리포지터리

GitLab Pages의 기본 저장 형식은 프로젝트 당 단일 ZIP 아카이브입니다.

이러한 ZIP 아카이브는 로컬 디스크 리포지터리 또는 객체 리포지터리에 저장할 수 있습니다 (구성된 경우).

ZIP 아카이브는 페이지 사이트가 업데이트될 때마다 저장됩니다.

백업

GitLab Pages는 정기 백업의 일부이므로 별도의 백업 설정이 필요하지 않습니다.

보안

XSS 공격을 방지하기 위해 GitLab Pages를 GitLab과는 다른 호스트명에서 실행하는 것을 강력히 권장합니다.

속도 제한

서비스 거부 공격 (DoS)의 위험을 최소화하기 위해 속도 제한을 강제할 수 있습니다. GitLab Pages는 토큰 버킷 알고리즘을 사용하여 속도 제한을 적용합니다. 기본적으로 지정한 한도를 초과하는 요청 또는 TLS 연결은 보고되지만 거부되지는 않습니다.

GitLab Pages는 다음 유형의 속도 제한을 지원합니다:

  • source_ip 당 속도 제한: 단일 클라이언트 IP 주소로부터 허용되는 요청이나 TLS 연결 횟수를 제한합니다.
  • domain 당 속도 제한: GitLab Pages에 호스팅된 도메인별로 허용되는 요청 또는 TLS 연결 횟수를 제한합니다. 사용자 정의 도메인 (예: example.com) 또는 그룹 도메인 (예: group.gitlab.io)일 수 있습니다.

HTTP 요청 기반의 속도 제한은 다음을 사용하여 강제됩니다:

  • rate_limit_source_ip: 클라이언트 IP 당 초당 요청 최대 임계값을 설정합니다. 이 기능을 비활성화하려면 0으로 설정합니다.
  • rate_limit_source_ip_burst: 클라이언트 IP 당 최초의 요청으로 허용되는 요청 수 최대 임계값을 설정하십시오. 예를 들어, 웹 페이지를로드할 때 동시에 여러 리소스를로드하는 경우입니다.
  • rate_limit_domain: 페이지 도메인 당 초당 요청 최대 임계값을 설정합니다. 이 기능을 비활성화하려면 0으로 설정합니다.
  • rate_limit_domain_burst: 페이지 도메인당 최초의 요청으로 허용되는 요청 수 최대 임계값을 설정합니다.

TLS 연결 기반의 속도 제한은 다음을 사용하여 강제됩니다:

  • rate_limit_tls_source_ip: 클라이언트 IP 당 초당 TLS 연결 최대 임계값을 설정합니다. 이 기능을 비활성화하려면 0으로 설정합니다.
  • rate_limit_tls_source_ip_burst: 클라이언트 IP 당 최초의 TLS 연결으로 허용되는 TLS 연결 수 최대 임계값을 설정하십시오. 예를 들어, 서로 다른 웹 브라우저에서 동시에 웹 페이지를로드하는 경우입니다.
  • rate_limit_tls_domain: 페이지 도메인 당 초당 TLS 연결 최대 임계값을 설정합니다. 이 기능을 비활성화하려면 0으로 설정합니다.
  • rate_limit_tls_domain_burst: 페이지 도메인당 최초의 TLS 연결으로 허용되는 TLS 연결 수 최대 임계값을 설정합니다.

IPv6 주소는 일반적으로 큰 접두어가 포함됩니다. 클라이언트의 IP 주소가 IPv6 인 경우, 전체 IPv6 주소가 아닌 길이 64의 IPv6 접두어에 한도가 적용됩니다.

소스 IP별 HTTP 요청 속도 제한 활성화

  1. /etc/gitlab/gitlab.rb에서 속도 제한 설정: 

    gitlab_pages['rate_limit_source_ip'] = 20.0
gitlab_pages['rate_limit_source_ip_burst'] = 600

  2. GitLab 재구성.

도메인별 HTTP 요청 속도 제한 활성화

  1. /etc/gitlab/gitlab.rb에서 속도 제한 설정: 

    gitlab_pages['rate_limit_domain'] = 1000
gitlab_pages['rate_limit_domain_burst'] = 5000

  2. GitLab 재구성.

소스 IP별 TLS 연결 속도 제한 활성화

  1. /etc/gitlab/gitlab.rb에서 속도 제한 설정: 

    gitlab_pages['rate_limit_tls_source_ip'] = 20.0
gitlab_pages['rate_limit_tls_source_ip_burst'] = 600

  2. GitLab 재구성.

도메인별 TLS 연결 속도 제한 활성화

  1. /etc/gitlab/gitlab.rb에서 속도 제한 설정: 

    gitlab_pages['rate_limit_tls_domain'] = 1000
gitlab_pages['rate_limit_tls_domain_burst'] = 5000

  2. GitLab 재구성.

관련 주제