GitLab Pages는 GitLab 프로젝트와 그룹에 정적 사이트 호스팅을 제공합니다. 사용자가 이 기능을 사용하려면 서버 관리자가 먼저 Pages를 구성해야 합니다. 관리자는 GitLab Pages로 다음을 수행할 수 있습니다.

• 사용자 지정 도메인과 SSL/TLS 인증서로 정적 웹사이트를 안전하게 호스팅합니다.
• 인증을 활성화해 GitLab 권한으로 Pages 사이트 액세스를 제어합니다.
• 다중 노드 환경에서 오브젝트 스토리지나 네트워크 스토리지를 사용해 배포를 확장합니다.
• 속도 제한과 사용자 지정 헤더로 트래픽을 모니터링하고 관리합니다.
• 모든 Pages 사이트에서 IPv4 및 IPv6 주소를 지원합니다.

GitLab Pages 데몬은 별도 프로세스로 실행되며, GitLab과 같은 서버에 구성하거나 전용 인프라에 구성할 수 있습니다. 사용자 문서는 GitLab Pages를 참고합니다.

GitLab Pages 데몬#

GitLab Pages는 Go로 작성된 기본 HTTP 서버인 GitLab Pages 데몬을 사용합니다. 이 데몬은 외부 IP 주소에서 수신 대기하며 사용자 지정 도메인과 사용자 지정 인증서를 지원합니다. Server Name Indication(SNI)으로 동적 인증서를 지원하고, 기본적으로 HTTP2로 페이지를 제공합니다.

자세한 내용은 README를 참고합니다.

사용자 지정 도메인과 함께 사용할 때 Pages 데몬은 포트 80 또는 443에서 수신 대기해야 합니다. 와일드카드 도메인에는 필요하지 않습니다.

Pages 데몬은 다음과 같이 실행할 수 있습니다.

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

다음 섹션은 첫 번째 옵션을 가정합니다. 사용자 지정 도메인을 지원하지 않는다면 보조 IP는 필요하지 않습니다.

사전 요구 사항#

이 섹션은 GitLab Pages 구성의 사전 요구 사항을 설명합니다.

GitLab Pages를 구성하기 전에 다음을 충족해야 합니다.

1. GitLab 인스턴스 도메인의 하위 도메인이 아닌 Pages 용 도메인을 보유합니다.

   [!warning] XSS 공격을 막으려면 GitLab Pages를 GitLab과 다른 호스트 이름으로 실행해야 합니다.

   GitLab 도메인	Pages 도메인	작동 여부
   example.com	example.io	✅
   example.com	pages.example.com	❌1
   gitlab.example.com	pages.example.com	✅

2. 선택 사항이지만 권장합니다. 인스턴스 러너를 활성화해 사용자가 직접 러너를 준비하지 않도록 합니다.

공개 접미사 목록에 도메인 추가#

브라우저는 공개 접미사 목록을 사용해 하위 도메인을 어떻게 다룰지 결정합니다. GitLab 인스턴스가 일반 사용자에게 GitLab Pages 사이트 생성을 허용한다면, 그 사용자가 Pages 도메인(example.io)에 하위 도메인을 만드는 것도 함께 허용하는 셈입니다. 도메인을 공개 접미사 목록에 추가하면 브라우저가 슈퍼쿠키를 수락하는 등의 동작을 막을 수 있습니다.

GitLab Pages 하위 도메인을 제출하려면 공개 접미사 목록에 수정 사항 제출을 참고합니다. 예를 들어 도메인이 example.io 라면 example.io를 공개 접미사 목록에 추가하도록 요청합니다. GitLab.com은 2016년에 gitlab.io를 추가했습니다.

와일드카드 도메인 구성#

각 사이트는 고유한 하위 도메인을 갖습니다(예: <namespace>.example.io/<project_slug>). 이 하위 도메인에는 와일드카드 DNS 레코드(*.example.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 레코드를 생략할 수 있습니다.

TLS 없는 와일드카드 도메인#

이 구성은 GitLab Pages를 사용하기 위한 최소 설정이며, 다른 모든 설정의 기반이 됩니다. 이 구성에서는 다음과 같이 동작합니다.

• NGINX가 모든 요청을 GitLab Pages 데몬으로 프록시합니다.
• GitLab Pages 데몬은 공용 인터넷을 직접 수신 대기하지 않습니다.

사전 요구 사항:

• 와일드카드 DNS를 구성했습니다.

와일드카드 도메인을 사용하도록 GitLab Pages를 구성하는 방법은 다음과 같습니다.

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

   external_url "http://example.com" # external_url here is only for reference
   pages_external_url 'http://example.io' # Important: not a subdomain of external_url, so cannot be http://pages.example.com
   

2. 파일을 저장하고 변경 사항을 적용하려면 GitLab을 재구성합니다.

결과 URL 체계는 http://<namespace>.example.io/<project_slug> 입니다.

개요는 GitLab CE 및 EE에서 GitLab Pages 활성화 동영상을 참고합니다.

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

NGINX가 모든 요청을 데몬으로 프록시합니다. Pages 데몬은 공용 인터넷을 수신 대기하지 않습니다.

인스턴스에는 와일드카드를 하나만 할당할 수 있습니다.

사전 요구 사항:

• 와일드카드 DNS를 구성했습니다.
• TLS 인증서를 보유했습니다. 와일드카드 인증서이거나 요구 사항을 충족하는 다른 유형이면 됩니다.

TLS 지원이 있는 와일드카드 도메인을 구성하는 방법은 다음과 같습니다.

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

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

   external_url "https://example.com" # external_url here is only for reference
   pages_external_url 'https://example.io' # Important: not a subdomain of external_url, so cannot be 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. 액세스 제어를 사용한다면 GitLab Pages 시스템 OAuth 애플리케이션의 리디렉션 URI를 HTTPS 프로토콜을 쓰도록 갱신합니다.

결과 URL 체계는 https://<namespace>.example.io/<project_slug> 입니다.

TLS 종료 로드 밸런서가 있는 와일드카드 도메인#

Amazon Web Services의 GitLab POC를 설치할 때 이 설정을 사용합니다. 이 설정에는 HTTPS 연결을 수신 대기하고 TLS 인증서를 관리하며 HTTP 트래픽을 인스턴스로 전달하는 TLS 종료 classic load balancer가 포함됩니다.

사전 요구 사항:

• 와일드카드 DNS를 구성했습니다.
• TLS 종료 로드 밸런서를 준비했습니다.

TLS 종료 로드 밸런서가 있는 와일드카드 도메인을 구성하는 방법은 다음과 같습니다.

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

   external_url "https://example.com" # external_url here is only for reference
   pages_external_url 'https://example.io' # Important: not a subdomain of external_url, so cannot be 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을 재구성합니다.

결과 URL 체계는 https://<namespace>.example.io/<project_slug> 입니다.

단일 도메인 사이트 구성#

모든 사이트가 하나의 도메인을 공유하며, 네임스페이스와 프로젝트 슬러그가 경로 세그먼트가 됩니다 (예: example.io/<namespace>/<project_slug>). 이 도메인에는 단일 DNS A 레코드만 필요합니다.

단일 도메인 사이트의 DNS 구성#

히스토리

• GitLab 17.2에서 구현이 NGINX에서 GitLab Pages 코드베이스로 변경되었습니다.
• GitLab 17.4에서 일반 제공으로 전환되었습니다.

와일드카드 DNS 없이 단일 도메인 사이트용 GitLab Pages DNS를 구성하는 방법은 다음과 같습니다.

1. /etc/gitlab/gitlab.rb에 gitlab_pages['namespace_in_path'] = true를 추가해 이 기능의 GitLab Pages 플래그를 활성화합니다.

2. DNS 공급자에서 example.io 항목을 추가합니다. example.io는 사용하는 도메인 이름으로, 192.0.0.0은 인스턴스의 IPv4 주소로 바꿉니다.

   example.io          1800 IN A    192.0.0.0
   

3. 선택 사항. GitLab 인스턴스에 IPv6 주소가 있다면 해당 항목을 추가합니다. example.io는 사용하는 도메인 이름으로, 2001:db8::1은 인스턴스의 IPv6 주소로 바꿉니다.

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

   example.io는 GitLab Pages를 제공하는 도메인입니다.

TLS 없는 단일 도메인 사이트#

히스토리

• GitLab 17.2에서 구현이 NGINX에서 GitLab Pages 코드베이스로 변경되었습니다.
• GitLab 17.4에서 일반 제공으로 전환되었습니다.

이 구성은 단일 도메인 사이트를 사용하기 위한 최소 설정이며, 다른 모든 단일 도메인 설정의 기반이 됩니다. 이 구성에서는 다음과 같이 동작합니다.

• NGINX가 모든 요청을 GitLab Pages 데몬으로 프록시합니다.
• GitLab Pages 데몬은 공용 인터넷을 직접 수신 대기하지 않습니다.

사전 요구 사항:

• 단일 도메인 사이트용 DNS를 구성했습니다.

단일 도메인 사이트를 사용하도록 GitLab Pages를 구성하는 방법은 다음과 같습니다.

1. /etc/gitlab/gitlab.rb에서 GitLab Pages의 외부 URL을 설정하고 기능을 활성화합니다.

   external_url "http://example.com" # Swap out this URL for your own
   pages_external_url 'http://example.io' # Important: not a subdomain of external_url, so cannot be http://pages.example.com
   
   # Set this flag to turn on this feature
   gitlab_pages['namespace_in_path'] = true
   

2. 파일을 저장하고 변경 사항을 적용하려면 GitLab을 재구성합니다.

결과 URL 체계는 http://example.io/<namespace>/<project_slug> 입니다.

TLS 지원이 있는 단일 도메인 사이트#

히스토리

• GitLab 17.2에서 구현이 NGINX에서 GitLab Pages 코드베이스로 변경되었습니다.
• GitLab 17.4에서 일반 제공으로 전환되었습니다.

이 구성에서는 NGINX가 모든 요청을 데몬으로 프록시합니다. GitLab Pages 데몬은 공용 인터넷을 수신 대기하지 않습니다.

사전 요구 사항:

• 단일 도메인 사이트용 DNS를 구성했습니다.
• 도메인(예: example.io)을 포함하는 TLS 인증서를 보유했습니다.

TLS 지원이 있는 단일 도메인 사이트를 구성하는 방법은 다음과 같습니다.

1. TLS 인증서와 키를 /etc/gitlab/ssl에 추가합니다.

2. /etc/gitlab/gitlab.rb에서 GitLab Pages의 외부 URL을 설정하고 기능을 활성화합니다.

   external_url "https://example.com" # Swap out this URL for your own
   pages_external_url 'https://example.io' # Important: not a subdomain of external_url, so cannot be https://pages.example.com
   
   pages_nginx['redirect_http_to_https'] = true
   
   # Set this flag to turn on this feature
   gitlab_pages['namespace_in_path'] = true
   

3. TLS 인증서나 키 파일 이름이 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 Pages 시스템 OAuth 애플리케이션의 리디렉션 URI를 HTTPS 프로토콜을 쓰도록 갱신합니다.

   [!note] GitLab Pages는 OAuth 애플리케이션을 갱신하지 않으며, 기본 auth_redirect_uri는 https://example.io/projects/auth로 갱신됩니다. 재구성하기 전에 /etc/gitlab/gitlab-secrets.json에서 gitlab_pages 섹션을 제거한 다음 gitlab-ctl reconfigure를 실행합니다. 자세한 내용은 GitLab Pages does not regenerate OAuth를 참고합니다.

5. 파일을 저장하고 변경 사항을 적용하려면 GitLab을 재구성합니다.

결과 URL 체계는 https://example.io/<namespace>/<project_slug> 입니다.

사용자 지정 도메인 구성#

기본적으로 GitLab Pages 사이트는 Pages 루트 도메인의 하위 도메인에서 제공됩니다(예: namespace.example.io/project). Pages 사이트에 사용자 지정 도메인을 구성하려면 보유한 도메인(예: example-custom-site-here.com)을 GitLab Pages로 연결하는 CNAME DNS 레코드를 추가합니다.

기본 *.example.io 하위 도메인 URL만 필요하다면 사용자 지정 도메인 지원을 구성하지 않아도 됩니다.

TLS 인증서를 사용하거나 사용하지 않는 사용자 지정 도메인을 구성할 수 있습니다. 어느 경우든 보조 IP가 필요합니다. IPv6 주소와 IPv4 주소를 모두 보유했다면 둘 다 사용할 수 있습니다.

사용자 지정 도메인의 DNS 구성#

사용자 지정 도메인을 지원해야 한다면, Pages 루트 도메인의 모든 하위 도메인이 Pages 데몬 전용 보조 IP를 가리켜야 합니다. 이 구성이 없으면 사용자가 CNAME 레코드로 사용자 지정 도메인을 GitLab Pages에 연결할 수 없습니다.

예를 들면 다음과 같습니다.

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와 달라야 합니다.

TLS 없는 사용자 지정 도메인#

이 구성에서는 Pages 데몬이 실행되고 NGINX가 요청을 데몬으로 프록시하지만, 데몬이 공용 인터넷에서 직접 요청을 받을 수도 있습니다. 사용자 지정 도메인은 TLS 없이 지원됩니다.

사전 요구 사항:

• 와일드카드 DNS를 구성했습니다.
• 보조 IP를 보유했습니다.

사용자 지정 도메인을 구성하는 방법은 다음과 같습니다.

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

   external_url "http://example.com" # external_url here is only for reference
   pages_external_url 'http://example.io' # Important: not a subdomain of external_url, so cannot be http://pages.example.com
   nginx['listen_addresses'] = ['192.0.2.1'] # The primary IP of the GitLab instance
   pages_nginx['enable'] = false
   gitlab_pages['external_http'] = ['192.0.2.2:80', '[2001:db8::2]:80'] # The secondary IPs for the GitLab Pages daemon
   gitlab_pages['custom_domain_mode'] = 'http' # Enable custom domain
   

   IPv6가 없다면 IPv6 주소를 생략합니다.

2. 파일을 저장하고 변경 사항을 적용하려면 GitLab을 재구성합니다.

결과 URL 체계는 http://<namespace>.example.io/<project_slug>와 http://custom-domain.com 입니다.

TLS 지원이 있는 사용자 지정 도메인#

이 구성에서는 Pages 데몬이 실행되고 NGINX가 요청을 데몬으로 프록시하지만, 데몬이 공용 인터넷에서 직접 요청을 받을 수도 있습니다. 사용자 지정 도메인과 TLS를 지원합니다.

사전 요구 사항:

• 와일드카드 DNS를 구성했습니다.
• TLS 인증서를 보유했습니다. 와일드카드 인증서이거나 요구 사항을 충족하는 다른 유형이면 됩니다.
• 보조 IP를 보유했습니다.

TLS 지원이 있는 사용자 지정 도메인을 구성하는 방법은 다음과 같습니다.

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

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

   external_url "https://example.com" # external_url here is only for reference
   pages_external_url 'https://example.io' # Important: not a subdomain of external_url, so cannot be https://pages.example.com
   nginx['listen_addresses'] = ['192.0.2.1'] # The primary IP of the GitLab instance
   pages_nginx['enable'] = false
   gitlab_pages['external_http'] = ['192.0.2.2:80', '[2001:db8::2]:80'] # The secondary IPs for the GitLab Pages daemon
   gitlab_pages['external_https'] = ['192.0.2.2:443', '[2001:db8::2]:443'] # The secondary IPs for the GitLab Pages daemon
   gitlab_pages['custom_domain_mode'] = 'https' # Enable custom domain
   # Redirect pages from HTTP to 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 레코드에 추가해 소유권을 증명해야 합니다.

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

1. 오른쪽 위에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > Preferences를 선택합니다.
3. Pages를 확장합니다.
4. Require users to prove ownership of custom domains 체크박스를 선택 해제합니다. 이 설정은 기본적으로 활성화되어 있습니다.

Let's Encrypt 통합#

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

켜는 방법은 다음과 같습니다.

1. 도메인 만료 알림을 받을 이메일 주소를 정합니다.
2. 오른쪽 위에서 Admin을 선택합니다.
3. 왼쪽 사이드바에서 Settings > Preferences를 선택합니다.
4. Pages를 확장합니다.
5. 알림을 받을 이메일 주소를 입력하고 Let's Encrypt 서비스 약관에 동의합니다.
6. Save changes를 선택합니다.

전역 설정#

다음 표는 Linux 패키지 설치에서 Pages가 인식하는 모든 구성 설정을 설명합니다. 이 옵션들은 /etc/gitlab/gitlab.rb에서 조정할 수 있으며, GitLab을 재구성한 뒤에 적용됩니다.

Pages 데몬이 환경에서 실행되고 콘텐츠를 제공하는 방식을 세밀하게 제어해야 하는 경우가 아니라면 대부분의 설정은 수동으로 구성하지 않아도 됩니다.

자세한 내용은 GitLab Pages 속도 제한을 참고합니다.

액세스 제어#

GitLab Pages 액세스 제어는 프로젝트별로 구성할 수 있으며, 해당 프로젝트의 멤버십을 기준으로 Pages 사이트 접근을 제어합니다.

액세스 제어는 Pages 데몬을 GitLab의 OAuth 애플리케이션으로 등록해 동작합니다. 인증되지 않은 사용자가 비공개 Pages 사이트에 접근을 요청하면 Pages 데몬은 사용자를 GitLab으로 리디렉션합니다. 인증에 성공하면 사용자는 토큰과 함께 Pages로 되돌아오고, 이 토큰은 쿠키에 저장됩니다. 쿠키는 시크릿 키로 서명되므로 변조를 감지할 수 있습니다.

비공개 사이트의 리소스를 보는 각 요청은 Pages가 이 토큰으로 인증합니다. Pages는 받은 요청마다 GitLab API에 요청을 보내 사용자가 해당 사이트를 읽을 권한이 있는지 확인합니다.

Pages 액세스 제어는 기본적으로 꺼져 있습니다. 켜는 방법은 다음과 같습니다.

1. /etc/gitlab/gitlab.rb에 다음을 추가합니다.

   gitlab_pages['access_control'] = true
   

2. 파일을 저장하고 변경 사항을 적용하려면 GitLab을 재구성합니다.

3. 이제 사용자가 프로젝트 설정에서 이를 구성할 수 있습니다.

축소된 인증 범위로 Pages 사용#

Pages 데몬이 인증에 사용하는 범위를 구성할 수 있습니다. 기본적으로 api 범위를 사용합니다.

예를 들어 /etc/gitlab/gitlab.rb에서 다음과 같이 범위를 read_api로 축소합니다.

gitlab_pages['auth_scope'] = 'read_api'

인증에 사용하는 범위는 GitLab Pages OAuth 애플리케이션 설정과 일치해야 합니다. 기존 애플리케이션을 쓰던 사용자는 GitLab Pages OAuth 애플리케이션을 수정해야 합니다.

사전 요구 사항:

• 액세스 제어를 활성화했습니다.

Pages가 사용하는 범위를 변경하는 방법은 다음과 같습니다.

1. 오른쪽 위에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Applications를 선택합니다.
3. GitLab Pages를 확장합니다.
4. api 범위의 체크박스를 선택 해제하고 원하는 범위의 체크박스를 선택합니다(예: read_api).
5. Save changes를 선택합니다.

모든 Pages 사이트에 대한 공개 액세스 비활성화#

GitLab 인스턴스에서 호스팅하는 모든 GitLab Pages 웹사이트에 액세스 제어를 적용할 수 있습니다. 이 설정을 활성화하면 인증된 사용자만 Pages 웹사이트에 접근할 수 있습니다. 모든 프로젝트에서 Everyone 가시성 수준 옵션이 사라지고, 프로젝트의 가시성 설정에 따라 프로젝트 멤버 또는 접근 권한이 있는 모든 사용자로 제한됩니다.

Pages로 게시한 정보를 인스턴스 사용자에게만 공개하려면 이 설정을 사용합니다.

사전 요구 사항:

• 인스턴스의 관리자 액세스 권한이 있습니다.
• Admin area에 설정이 표시되도록 액세스 제어를 활성화했습니다.

모든 Pages 사이트에 대한 공개 액세스를 비활성화하는 방법은 다음과 같습니다.

1. 오른쪽 위에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > Preferences를 선택합니다.
3. Pages를 확장합니다.
4. Disable public access to Pages sites 체크박스를 선택합니다.
5. Save changes를 선택합니다.

기본적으로 고유 도메인 비활성화#

히스토리

• GitLab 18.3에서 도입되었습니다.

기본적으로 새로 만든 모든 GitLab Pages 사이트는 고유 도메인 URL (예: my-project-1a2b3c.example.com)을 사용하며, 같은 네임스페이스에 속한 사이트끼리 쿠키를 공유하지 않도록 막습니다.

이 기본 동작을 비활성화하면 새 Pages 사이트가 경로 기반 URL (예: my-namespace.example.com/my-project)을 사용합니다. 다만 이 방식은 같은 네임스페이스에 속한 사이트끼리 쿠키가 공유될 위험이 있습니다.

이 설정은 새 사이트의 기본 동작만 제어합니다. 사용자는 개별 프로젝트에서 이 설정을 재정의할 수 있습니다.

사전 요구 사항:

• 인스턴스의 관리자 액세스 권한이 있어야 합니다.

기본적으로 고유 도메인을 비활성화하는 방법은 다음과 같습니다.

1. 오른쪽 위에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > Preferences를 선택합니다.
3. Pages를 확장합니다.
4. Enable unique domains by default 체크박스를 선택 해제합니다.
5. Save changes를 선택합니다.

이 설정은 새 Pages 사이트에만 영향을 줍니다. 기존 사이트는 현재의 고유 도메인 구성을 유지합니다.

네트워킹 및 인증서#

GitLab Pages 데몬이 네트워크 연결, 인증서, 보안 헤더를 처리하는 방식을 구성합니다.

프록시 뒤에서 실행#

외부 인터넷 연결이 프록시로 통제되는 환경에서도 GitLab Pages를 사용할 수 있습니다.

GitLab Pages에 프록시를 사용하는 방법은 다음과 같습니다.

1. /etc/gitlab/gitlab.rb에 다음을 추가합니다.

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

2. 파일을 저장하고 변경 사항을 적용하려면 GitLab을 재구성합니다.

사용자 지정 인증 기관(CA) 사용#

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

대개 다음 오류가 발생합니다.

Post /oauth/token: x509: certificate signed by unknown authority

해결 방법은 다음과 같습니다.

• Linux 패키지 설치는 사용자 지정 CA를 설치합니다.
• 소스 컴파일 설치는 시스템 인증서 저장소에 사용자 지정 CA를 설치합니다.

GitLab API 호출 시 상호 TLS 지원#

히스토리

• GitLab 17.1에서 도입되었습니다.

GitLab 이 상호 TLS를 요구하도록 구성되어 있다면, GitLab Pages 구성에 클라이언트 인증서를 추가해야 합니다.

인증서의 요구 사항은 다음과 같습니다.

• 인증서는 호스트 이름이나 IP 주소를 Subject Alternative Name으로 지정해야 합니다.
• 최종 사용자 인증서, 중간 인증서, 루트 인증서를 이 순서대로 포함한 전체 인증서 체인이 필요합니다.

인증서의 Common Name 필드는 무시됩니다.

사전 요구 사항:

• 인스턴스가 Linux 패키지 설치 방식을 사용합니다.

GitLab Pages 서버에서 인증서를 구성하는 방법은 다음과 같습니다.

1. GitLab Pages 노드에서 /etc/gitlab/ssl 디렉터리를 만들고 키와 전체 인증서 체인을 그곳에 복사합니다.

   sudo mkdir -p /etc/gitlab/ssl
   sudo chmod 755 /etc/gitlab/ssl
   sudo cp key.pem cert.pem /etc/gitlab/ssl/
   sudo chmod 644 key.pem cert.pem
   

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

   gitlab_pages['client_cert'] = ['/etc/gitlab/ssl/cert.pem']
   gitlab_pages['client_key'] = ['/etc/gitlab/ssl/key.pem']
   

3. 사용자 지정 CA를 사용했다면 루트 CA 인증서를 /etc/gitlab/ssl에 복사하고 /etc/gitlab/gitlab.rb를 편집합니다.

   gitlab_pages['client_ca_certs'] = ['/etc/gitlab/ssl/ca.pem']
   

   사용자 지정 인증 기관이 여러 개라면 파일 경로를 쉼표로 구분합니다.

4. 다중 노드 GitLab Pages 설치라면 모든 노드에서 이 단계를 반복합니다.

5. 모든 GitLab 노드의 /etc/gitlab/trusted-certs 디렉터리에 전체 인증서 체인 파일의 사본을 저장합니다.

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의 프록시 리스너를 구성하는 방법은 다음과 같습니다.

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 사이트의 제한을 설정합니다. 병렬 배포의 기본 만료 시점도 설정할 수 있습니다.

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

사전 요구 사항:

• 인스턴스의 관리자 액세스 권한이 있어야 합니다.

프로젝트의 전역 최대 pages 크기를 설정하는 방법은 다음과 같습니다.

1. 오른쪽 위에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > Preferences를 선택합니다.
3. Pages를 확장합니다.
4. Maximum size of pages에 값을 입력합니다. 기본값은 100 입니다.
5. Save changes를 선택합니다.

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

사전 요구 사항:

• 인스턴스의 관리자 액세스 권한이 있어야 합니다.

상속된 설정을 재정의해 그룹에서 각 GitLab Pages 사이트의 최대 크기를 설정하는 방법은 다음과 같습니다.

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Pages를 확장합니다.
4. Maximum size 아래에 MB 단위로 값을 입력합니다.
5. Save changes를 선택합니다.

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

사전 요구 사항:

• 인스턴스의 관리자 액세스 권한이 있어야 합니다.

상속된 설정을 재정의해 프로젝트에서 GitLab Pages 사이트의 최대 크기를 설정하는 방법은 다음과 같습니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Deploy > Pages를 선택합니다.
3. Maximum size of pages에 MB 단위로 크기를 입력합니다.
4. Save changes를 선택합니다.

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

사전 요구 사항:

• 인스턴스의 관리자 액세스 권한이 있어야 합니다.

프로젝트당 GitLab Pages 사용자 지정 도메인의 최대 수를 설정하는 방법은 다음과 같습니다.

1. 오른쪽 위에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > Preferences를 선택합니다.
3. Pages를 확장합니다.
4. Maximum number of custom domains per project에 값을 입력합니다. 도메인 수를 제한하지 않으려면 0을 사용합니다.
5. Save changes를 선택합니다.

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

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

GitLab Rails 콘솔을 사용해 GitLab Self-Managed 인스턴스에서 이 제한을 변경할 수 있습니다.

자세한 내용은 GitLab 애플리케이션 제한을 참고합니다.

Pages 프로젝트 리디렉션 제한#

GitLab Pages는 성능 영향을 줄이기 위해 _redirects 파일에 기본 제한을 둡니다.

제한을 조정하는 방법은 다음과 같습니다.

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

병렬 배포의 기본 만료 구성#

히스토리

• GitLab 17.4에서 도입되었습니다.

사전 요구 사항:

• 인스턴스의 관리자 액세스 권한이 있습니다.

병렬 배포가 삭제되기까지의 기본 기간을 구성하는 방법은 다음과 같습니다.

1. 오른쪽 위에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > Preferences를 선택합니다.
3. Pages를 확장합니다.
4. Default expiration for parallel deployments in seconds에 값을 입력합니다. 병렬 배포가 기본적으로 만료되지 않게 하려면 0을 사용합니다.
5. Save changes를 선택합니다.

스토리지#

GitLab Pages가 배포된 사이트를 저장하는 위치와 Pages 데몬이 ZIP 아카이브에서 제공하는 콘텐츠를 캐시하는 방식을 구성합니다.

스토리지 경로 변경#

GitLab Pages 콘텐츠가 저장되는 기본 경로를 변경하는 방법은 다음과 같습니다.

1. 페이지는 기본적으로 /var/opt/gitlab/gitlab-rails/shared/pages에 저장됩니다. 다른 위치를 사용하려면 /etc/gitlab/gitlab.rb를 편집합니다.

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

2. 파일을 저장하고 변경 사항을 적용하려면 GitLab을 재구성합니다.

오브젝트 스토리지 설정#

다음 오브젝트 스토리지 설정은 이렇게 적용됩니다.

• 소스 컴파일 설치에서는 pages: 아래의 object_store:에 중첩됩니다.
• Linux 패키지 설치에서는 앞에 pages_object_store_가 붙습니다.

S3 호환 연결 설정#

통합 오브젝트 스토리지 설정을 사용합니다.

공급자별로 사용할 수 있는 연결 설정을 참고합니다.

Pages 배포를 오브젝트 스토리지로 마이그레이션#

기존 Pages 배포 오브젝트(ZIP 아카이브)는 로컬 스토리지나 오브젝트 스토리지에 저장할 수 있습니다.

기존 Pages 배포를 로컬 스토리지에서 오브젝트 스토리지로 마이그레이션하는 방법은 다음과 같습니다.

sudo gitlab-rake gitlab:pages:deployments:migrate_to_object_storage

PostgreSQL 콘솔을 사용해 진행 상황을 추적하고 모든 Pages 배포가 정상적으로 마이그레이션됐는지 확인할 수 있습니다.

• Linux 패키지 설치는 sudo gitlab-rails dbconsole --database main을 사용합니다.
• 소스 컴파일 설치는 sudo -u git -H psql -d gitlabhq_production을 사용합니다.

objectstg(store=2 인 경우)의 개수가 전체 Pages 배포 수와 같은지 확인합니다.

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

모든 것이 정상 동작하는지 확인한 뒤 Pages 로컬 스토리지를 비활성화합니다.

Pages 배포를 로컬 스토리지로 롤백#

오브젝트 스토리지로 마이그레이션한 뒤에도 Pages 배포를 로컬 스토리지로 되돌릴 수 있습니다.

sudo gitlab-rake gitlab:pages:deployments:migrate_to_local

Pages 로컬 스토리지 비활성화#

오브젝트 스토리지를 사용한다면 불필요한 디스크 사용과 쓰기를 피하도록 로컬 스토리지를 비활성화할 수 있습니다.

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

   gitlab_rails['pages_local_store_enabled'] = false
   

2. 파일을 저장하고 변경 사항을 적용하려면 GitLab을 재구성합니다.

다중 노드 환경에서 Pages 네트워크 스토리지 활성화#

대부분의 환경에서는 오브젝트 스토리지 구성을 권장합니다. 다만 요구 사항상 네트워크 스토리지를 사용해야 하고 Pages를 별도의 서버에서 실행하려면 다음과 같이 진행합니다.

1. 공유 스토리지 볼륨이 기본 서버와 사용할 Pages 서버 양쪽에 이미 마운트되어 사용 가능한지 확인합니다.

2. 각 노드의 /etc/gitlab/gitlab.rb를 갱신해 다음을 포함시킵니다.

   gitlab_pages['enable_disk'] = true
   gitlab_rails['pages_path'] = "/var/opt/gitlab/gitlab-rails/shared/pages" # Path to your network storage
   

3. Pages를 별도의 서버로 전환합니다.

별도의 서버에 Pages를 성공적으로 구성한 뒤에는 그 서버만 공유 스토리지 볼륨에 접근하면 됩니다. 단일 노드 환경으로 되돌려야 할 경우를 대비해 기본 서버에도 공유 스토리지 볼륨을 마운트한 채로 두는 방안을 고려합니다.

ZIP 스토리지#

GitLab Pages의 기본 저장 형식은 프로젝트당 하나의 ZIP 아카이브입니다. 이 아카이브는 로컬이나 오브젝트 스토리지에 저장할 수 있습니다. Pages 사이트가 갱신될 때마다 새 아카이브가 저장됩니다.

ZIP 제공 및 캐시 구성#

GitLab Pages는 오브젝트 스토리지의 ZIP 아카이브에서 콘텐츠를 제공할 수 있습니다. ZIP 아카이브에서 콘텐츠를 제공할 때 성능을 높이기 위해 인메모리 캐시를 사용합니다. 다음 구성 플래그를 변경해 캐시 동작을 조정할 수 있습니다.

ZIP 캐시 새로 고침 예제#

zip_cache_expiration 이전에 아카이브에 접근했고 만료까지 남은 시간이 zip_cache_refresh 이하이면 아카이브가 캐시에서 새로 고쳐집니다(메모리에 유지되는 시간이 연장됩니다). 예를 들어 archive.zip에 0s 시점에 접근하면 60s(zip_cache_expiration의 기본값) 뒤에 만료됩니다. 15s 뒤에 아카이브를 다시 열면, 만료까지 남은 시간(45s)이 zip_cache_refresh(기본값 30s)보다 크므로 새로 고쳐지지 않습니다. 반면 (처음 연 시점부터) 45s 뒤에 다시 접근하면 새로 고쳐집니다. 이때 아카이브가 메모리에 남는 시간은 45s + zip_cache_expiration (60s) 만큼 연장되어 총 105s가 됩니다.

아카이브가 zip_cache_expiration에 도달하면 만료로 표시되고 다음 zip_cache_cleanup 간격에 제거됩니다.

백업#

GitLab Pages는 정기 백업에 포함되므로 별도로 구성할 백업은 없습니다.

로깅 및 환경#

GitLab Pages 데몬에 환경 변수를 전달하고, 데몬이 로그에 추가하는 세부 정보를 구성합니다.

환경 변수 사용#

Pages 데몬에 환경 변수를 전달해 기능 플래그를 켜거나 끌 수 있습니다.

구성 가능한 디렉터리 기능을 비활성화하는 방법은 다음과 같습니다.

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

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

2. 파일을 저장하고 변경 사항을 적용하려면 GitLab을 재구성합니다.

데몬의 자세한 로깅 활성화#

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에 다음을 추가합니다.

   gitlab_pages['propagate_correlation_id'] = true
   

2. 파일을 저장하고 변경 사항을 적용하려면 GitLab을 재구성합니다.

별도의 서버에서 GitLab Pages 실행#

GitLab Pages 데몬을 별도의 서버에서 실행하면 기본 애플리케이션 서버의 부하를 줄일 수 있습니다.

별도의 서버에서 GitLab Pages를 구성하는 방법은 다음과 같습니다.

1. 선택 사항. 액세스 제어를 활성화하려면 다음을 /etc/gitlab/gitlab.rb에 추가하고 GitLab 서버를 재구성합니다.

   [!warning] 액세스 제어와 함께 GitLab Pages를 사용할 계획이라면 gitlab-secrets.json을 복사하기 전에 GitLab 서버에서 액세스 제어를 켭니다. 액세스 제어를 켜면 새 OAuth 애플리케이션이 생성되고 그 정보가 gitlab-secrets.json에 반영됩니다. 이 순서를 지키지 않으면 액세스 제어에서 문제가 생길 수 있습니다.

   gitlab_pages['access_control'] = true
   

2. GitLab 서버에서 시크릿 파일의 백업을 만듭니다.

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

3. GitLab 서버에서 Pages를 활성화하려면 다음을 /etc/gitlab/gitlab.rb에 추가합니다.

   pages_external_url "http://<pages_server_URL>"
   

4. 다음 중 한 방법으로 오브젝트 스토리지를 설정합니다.

   • 오브젝트 스토리지를 구성하고 GitLab Pages 데이터를 마이그레이션합니다.
   • 네트워크 스토리지를 구성합니다.

5. 변경 사항을 적용하려면 GitLab 서버를 재구성합니다. 이제 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>'
   
   ## If access control was enabled
   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 Pages 사이트에 사용자 지정 도메인을 활성화하려면 다음 중 한 방법으로 Pages 서버를 설정합니다.

    • TLS 없는 사용자 지정 도메인.
    • TLS 지원이 있는 사용자 지정 도메인.

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

    # On the GitLab server
    cp /etc/gitlab/gitlab-secrets.json /mnt/pages/gitlab-secrets.json
    
    # On the Pages server
    mv /var/opt/gitlab/gitlab-rails/shared/pages/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json
    

12. 변경 사항을 적용하려면 Pages 서버를 재구성합니다.

13. GitLab 서버에서 /etc/gitlab/gitlab.rb를 다음과 같이 변경합니다.

    pages_external_url "http://<pages_server_URL>"
    gitlab_pages['enable'] = false
    pages_nginx['enable'] = false
    

14. 개별 GitLab Pages 사이트에 사용자 지정 도메인을 활성화하려면 GitLab 서버에서 /etc/gitlab/gitlab.rb를 다음과 같이 변경합니다.

    • 사용자 지정 도메인:

         gitlab_pages['custom_domain_mode'] = 'http'
      

    • TLS 지원이 있는 사용자 지정 도메인:

         gitlab_pages['custom_domain_mode'] = 'https'
      

15. 변경 사항을 적용하려면 GitLab 서버를 재구성합니다.

부하를 분산하려면 DNS 서버가 여러 IP를 반환하도록 구성하거나 IP 수준 로드 밸런서를 사용하는 등 표준 로드 밸런싱 방식으로 여러 서버에서 GitLab Pages를 실행할 수 있습니다. 여러 서버에 GitLab Pages를 설정하려면 각 Pages 서버마다 앞의 절차를 반복합니다.

도메인 소스 구성#

GitLab Pages 데몬은 요청을 처리할 때 먼저 어떤 프로젝트가 요청된 URL을 제공해야 하는지와 그 콘텐츠가 어떻게 저장되는지를 확인합니다.

기본적으로 GitLab Pages는 새 도메인이 요청될 때마다 내부 GitLab API를 사용합니다. API에 연결하지 못하면 Pages가 시작되지 않습니다. 이후 요청 속도를 높이기 위해 Pages 데몬이 도메인 정보를 캐시하기도 합니다.

자주 발생하는 문제는 문제 해결 섹션을 참고합니다.

GitLab API 캐시 구성#

API 기반 구성은 성능과 안정성을 높이기 위해 캐시 메커니즘을 사용합니다. 다음 설정을 변경해 캐시 동작을 조정할 수 있지만, 권장 기본값은 필요한 경우에만 변경합니다. 잘못 구성하면 간헐적이거나 지속적인 오류가 발생하거나 Pages 데몬이 오래된 콘텐츠를 제공할 수 있습니다.

예시:

• gitlab_cache_expiry를 늘리면 항목이 캐시에 더 오래 남습니다. GitLab Pages와 GitLab Rails 사이의 통신이 안정적이지 않을 때 이 설정을 사용합니다. Pages 오브젝트 스토리지에 Amazon 인스턴스 프로파일을 사용하면서 이 값을 14분보다 크게 올린다면 연결 설정에서 aws_credentials_refresh_threshold_seconds도 새 만료 시간에 60초를 더한 값 이상으로 설정합니다. 그렇지 않으면 GitLab Pages가 임시 자격 증명이 이미 만료된 캐시된 URL을 제공할 수 있습니다.
• gitlab_cache_refresh를 늘리면 GitLab Pages가 GitLab Rails에 도메인 구성을 요청하는 빈도가 줄어듭니다. GitLab Pages가 GitLab API에 요청을 너무 많이 보내고 콘텐츠가 자주 바뀌지 않을 때 이 설정을 사용합니다.
• gitlab_cache_cleanup을 줄이면 만료된 항목이 캐시에서 더 자주 제거되어 Pages 노드의 메모리 사용량이 줄어듭니다.
• gitlab_retrieval_timeout을 줄이면 GitLab Rails로 보내는 요청이 더 빨리 중단됩니다. 늘리면 API 응답을 받을 시간이 더 길어집니다. 네트워크가 느린 환경에서 이 설정을 사용합니다.
• gitlab_retrieval_interval을 줄이면 연결 제한 시간 초과처럼 API에서 오류 응답이 왔을 때에만 API 요청 빈도가 높아집니다.
• gitlab_retrieval_retries를 줄이면 오류를 보고하기 전에 도메인 구성을 재시도하는 횟수가 줄어듭니다.

관련 주제#

• GitLab Pages 관리 문제 해결
• GitLab Pages 사용자 문서
• 사용자 지정 도메인과 SSL/TLS 인증서
• Pages 액세스 제어
• job 아티팩트
• OAuth 공급자 통합
• GitLab 애플리케이션 제한
• 오브젝트 스토리지
• 병렬 배포
• 기본 폴더 사용자 지정
• Pages 리디렉션

Footnotes

1. Pages 도메인이 GitLab 인스턴스 도메인의 하위 도메인이면, 배포된 모든 Pages 사이트가 GitLab 세션 쿠키에 접근할 수 있습니다. ↩

2. 외부 Sidekiq 노드를 사용한다면 구성에 pages_external_url을 추가해야 합니다. 이 설정이 없으면 외부 Sidekiq 노드가 배포 job을 처리할 수 없습니다. ↩