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

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

GitLab Pages 데몬은 별도의 프로세스로 실행되며 GitLab과 동일한 서버 또는 전용 인프라에서 구성할 수 있습니다. 사용자 문서는 GitLab Pages를 참조하세요.

GitLab Pages 데몬#

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

자세한 내용은 README를 참조하세요.

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

Pages 데몬을 실행할 수 있는 방법:

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

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

전제 조건#

이 섹션은 GitLab Pages 구성을 위한 전제 조건을 설명합니다.

와일드카드 도메인#

각 사이트는 고유한 하위 도메인을 가집니다(예: <namespace>.example.io/<project_slug>). 이 하위 도메인은 와일드카드 DNS 레코드(*.example.io)를 필요로 하며 대부분의 인스턴스에 권장되는 설정입니다.

와일드카드 도메인용 Pages를 구성하기 전에 다음을 수행해야 합니다:

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

   GitLab 도메인	Pages 도메인	작동 여부
   example.com	example.io	[check-circle] 예
   example.com	pages.example.com	[dotted-circle] 아니오 1
   gitlab.example.com	pages.example.com	[check-circle] 예

   각주:

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

2. 와일드카드 DNS 레코드를 구성합니다.

3. 선택 사항. HTTPS에서 Pages를 제공하기로 결정한 경우 해당 도메인에 대한 와일드카드 인증서를 보유합니다.

4. 선택 사항이지만 권장됩니다. 인스턴스 러너를 활성화하여 사용자가 직접 러너를 제공할 필요가 없도록 합니다.

5. 사용자 지정 도메인의 경우 보조 IP를 보유합니다.

단일 도메인 사이트#

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

단일 도메인 사이트용 Pages를 구성하기 전에 다음을 수행해야 합니다:

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

   GitLab 도메인	Pages 도메인	지원 여부
   example.com	example.io	[check-circle] 예
   example.com	pages.example.com	[dotted-circle] 아니오 1
   gitlab.example.com	pages.example.com	[check-circle] 예

   각주:

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

2. DNS 레코드를 구성합니다.

3. 선택 사항. HTTPS에서 Pages를 제공하기로 결정한 경우 해당 도메인에 대한 TLS 인증서를 보유합니다.

4. 선택 사항이지만 권장됩니다. 인스턴스 러너를 활성화하여 사용자가 직접 러너를 제공할 필요가 없도록 합니다.

5. 사용자 지정 도메인의 경우 보조 IP를 보유합니다.

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

공개 접미사 목록은 브라우저가 하위 도메인을 처리하는 방법을 결정하는 데 사용됩니다. GitLab 인스턴스가 공개 구성원이 GitLab Pages 사이트를 만들 수 있도록 허용하는 경우, 해당 사용자가 Pages 도메인(example.io)에 하위 도메인을 만들 수 있도록 허용하기도 합니다. 도메인을 공개 접미사 목록에 추가하면 다른 것들 중에서 슈퍼쿠키를 수락하는 브라우저를 방지합니다.

GitLab Pages 하위 도메인을 제출하려면 공개 접미사 목록에 수정 사항 제출을 참조하세요. 예를 들어, 도메인이 example.io인 경우 example.io를 공개 접미사 목록에 추가하도록 요청해야 합니다. 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 레코드를 생략할 수 있습니다.

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

히스토리

• GitLab 16.7에서 실험으로 도입.
• GitLab 16.11에서 베타로 이동.
• 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가 제공되는 도메인입니다.

사용자 지정 도메인의 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와 달라야 합니다.

구성#

GitLab Pages를 여러 방법으로 설정할 수 있습니다. 다음 예제는 가장 단순한 설정부터 가장 고급 설정 순으로 나열되어 있습니다.

와일드카드 도메인#

이 구성은 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은 참조용으로만 사용됨
   pages_external_url 'http://example.io' # 중요: external_url의 하위 도메인이 아니어야 합니다. 따라서 http://pages.example.com이 될 수 없음
   

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

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

개요는 GitLab CE 및 EE에서 GitLab Pages 활성화 동영상을 참조하세요.

단일 도메인 사이트#

히스토리

• GitLab 16.7에서 실험으로 도입.
• GitLab 16.11에서 베타로 이동.
• 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" # 이 URL을 자신의 URL로 교체하세요
   pages_external_url 'http://example.io' # 중요: external_url의 하위 도메인이 아니어야 합니다. 따라서 http://pages.example.com이 될 수 없음
   
   # 이 기능을 활성화하려면 이 플래그를 설정하세요
   gitlab_pages['namespace_in_path'] = true
   

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

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

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은 참조용으로만 사용됨
   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. 액세스 제어를 사용하는 경우 GitLab Pages 시스템 OAuth 애플리케이션의 리디렉션 URI를 HTTPS 프로토콜을 사용하도록 업데이트합니다.

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

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

히스토리

• GitLab 16.7에서 실험으로 도입.
• GitLab 16.11에서 베타로 이동.
• 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" # 이 URL을 자신의 URL로 교체하세요
   pages_external_url 'https://example.io' # 중요: external_url의 하위 도메인이 아니어야 합니다. 따라서 https://pages.example.com이 될 수 없음
   
   pages_nginx['redirect_http_to_https'] = true
   
   # 이 기능을 활성화하려면 이 플래그를 설정하세요
   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가 OAuth를 재생성하지 않음을 참조하세요.

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

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

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

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

전제 조건:

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

TLS 종료 로드 밸런서를 사용하여 와일드카드 도메인을 구성하려면:

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을 재구성합니다.

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

전역 설정#

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

이러한 설정의 대부분은 환경에서 Pages 데몬이 실행되고 콘텐츠를 제공하는 방법에 대해 더 세분화된 제어가 필요한 경우가 아니면 수동으로 구성할 필요가 없습니다.

각주:

1. 외부 Sidekiq 노드를 사용하는 경우 구성에 pages_external_url을 추가해야 합니다. 이 설정 없이는 외부 Sidekiq 노드가 배포 잡을 처리할 수 없습니다.

고급 구성#

와일드카드 도메인 외에도 TLS 인증서가 있거나 없는 사용자 지정 도메인으로 작동하도록 GitLab Pages를 구성할 수 있습니다. 어느 경우에나 보조 IP가 필요합니다. IPv6 및 IPv4 주소가 모두 있는 경우 둘 다 사용할 수 있습니다.

사용자 지정 도메인#

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

전제 조건:

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

사용자 지정 도메인을 구성하려면:

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
   gitlab_pages['custom_domain_mode'] = 'http' # 사용자 지정 도메인 활성화
   

   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은 참조용으로만 사용됨
   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
   gitlab_pages['custom_domain_mode'] = 'https' # 사용자 지정 도메인 활성화
   # 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 레코드에 추가하여 소유권을 증명해야 합니다.

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

1. 오른쪽 상단에서 Admin을 선택합니다.
2. Settings > Preferences를 선택합니다.
3. Pages를 확장합니다.
4. 사용자가 사용자 지정 도메인의 소유권을 증명하도록 요구 확인란을 선택 취소합니다. 이 설정은 기본적으로 활성화됩니다.

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를 선택합니다.

액세스 제어#

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 영역에 표시되도록 활성화된 액세스 제어.

모든 Pages 사이트에 대한 공개 액세스를 비활성화하려면:

1. 오른쪽 상단에서 Admin을 선택합니다.
2. Settings > Preferences를 선택합니다.
3. Pages를 확장합니다.
4. Pages 사이트에 대한 공개 액세스 비활성화 확인란을 선택합니다.
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. 기본적으로 고유 도메인 활성화 확인란을 선택 취소합니다.
5. Save changes를 선택합니다.

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

프록시 뒤에서 실행#

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

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를 설치합니다.

GitLab API 호출 시 상호 TLS 지원#

히스토리

• GitLab 17.1에서 도입.

GitLab이 상호 TLS를 요구하도록 구성된 경우 GitLab Pages 구성에 클라이언트 인증서를 추가해야 합니다.

인증서에는 다음 요구 사항이 있습니다:

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

인증서의 공통 이름 필드는 무시됩니다.

전제 조건:

• 인스턴스가 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 디렉터리에 전체 인증서 체인 파일의 복사본을 저장합니다.

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 간격에 제거됩니다.

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

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

환경 변수 사용#

기능 플래그를 활성화하거나 비활성화하기 위해 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 콘텐츠가 저장되는 기본 경로를 변경하려면:

1. Pages는 기본적으로 /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 사이트의 전역 최대 크기 설정#

전제 조건:

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

프로젝트에 대한 전역 최대 Pages 크기를 설정하려면:

1. 오른쪽 상단에서 Admin을 선택합니다.
2. Settings > Preferences를 선택합니다.
3. Pages를 확장합니다.
4. Pages의 최대 크기에서 값을 입력합니다. 기본값은 100입니다.
5. Save changes를 선택합니다.

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

전제 조건:

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

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

1. 상단 표시줄에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. Settings > General을 선택합니다.
3. Pages를 확장합니다.
4. 최대 크기 아래에 MB 단위로 값을 입력합니다.
5. Save changes를 선택합니다.

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

전제 조건:

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

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

1. 상단 표시줄에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. Deploy > Pages를 선택합니다.
3. Pages의 최대 크기에 MB 단위로 크기를 입력합니다.
4. Save changes를 선택합니다.

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

전제 조건:

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

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

1. 오른쪽 상단에서 Admin을 선택합니다.
2. Settings > Preferences를 선택합니다.
3. Pages를 확장합니다.
4. 프로젝트당 최대 사용자 지정 도메인 수에 대한 값을 입력합니다. 무제한 도메인에는 0을 사용합니다.
5. Save changes를 선택합니다.

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

히스토리

• GitLab 17.4에서 도입.

전제 조건:

• 인스턴스에 대한 관리자 액세스.

병렬 배포가 삭제된 후 기본 기간을 구성하려면:

1. 오른쪽 상단에서 Admin을 선택합니다.
2. Settings > Preferences를 선택합니다.
3. Pages를 확장합니다.
4. **병렬 배포의 기본 만료 시간(초)**에 대한 값을 입력합니다. 병렬 배포가 기본적으로 만료되지 않아야 하는 경우 0을 사용합니다.
5. Save changes를 선택합니다.

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

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

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

자세한 내용은 GitLab Pages 웹사이트당 파일 수에 대한 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>'
   
   ## 액세스 제어가 활성화된 경우
   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 지원이 있는 사용자 지정 도메인.

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

    # 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
    

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 사이의 통신이 안정적이지 않은 경우 이 설정을 사용합니다.
• 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를 줄이면 오류를 보고하기 전에 도메인 구성을 재시도하는 횟수가 줄어듭니다.

오브젝트 스토리지 설정#

다음 오브젝트 스토리지 설정은:

• 소스 컴파일 설치에서 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" # 네트워크 스토리지 경로
   

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

별도의 서버에서 Pages를 성공적으로 구성한 후에는 해당 서버만 공유 스토리지 볼륨에 액세스해야 합니다. 단일 노드 환경으로 다시 마이그레이션해야 하는 경우에 대비하여 기본 서버에 공유 스토리지 볼륨을 마운트한 상태로 유지하는 것을 고려하세요.

ZIP 스토리지#

GitLab Pages의 기본 스토리지 형식은 프로젝트당 단일 ZIP 아카이브입니다. 이러한 아카이브는 로컬 또는 오브젝트 스토리지에 저장할 수 있습니다. Pages 사이트가 업데이트될 때마다 새 아카이브가 저장됩니다.

백업#

GitLab Pages는 정기 백업의 일부이므로 별도로 구성할 백업이 없습니다.

보안#

XSS 공격을 방지하기 위해 GitLab과 다른 호스트 이름으로 GitLab Pages를 실행하는 것을 강력히 고려해야 합니다.

속도 제한#

히스토리

• GitLab 17.3에서 변경: Pages 속도 제한에서 서브넷을 제외할 수 있습니다.

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: 호스팅된 Pages 도메인당 초당 최대 요청 수. 비활성화하려면 0으로 설정합니다.
• rate_limit_domain_burst: 호스팅된 Pages 도메인당 초기 버스트에서 허용되는 최대 요청 수.

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

• rate_limit_tls_source_ip: 클라이언트 IP당 초당 최대 TLS 연결 수. 비활성화하려면 0으로 설정합니다.
• rate_limit_tls_source_ip_burst: 클라이언트 IP당 초기 버스트에서 허용되는 최대 TLS 연결 수.
• rate_limit_tls_domain: 호스팅된 Pages 도메인당 초당 최대 TLS 연결 수. 비활성화하려면 0으로 설정합니다.
• rate_limit_tls_domain_burst: 호스팅된 Pages 도메인당 초기 버스트에서 허용되는 최대 TLS 연결 수.

특정 IP 범위(서브넷)가 모든 속도 제한을 우회하도록 허용하려면 rate_limit_subnets_allow_list를 사용합니다. 예: ['1.2.3.4/24', '2001:db8::1/32']. GitLab Pages 차트 예제가 있습니다.

클라이언트의 IP 주소가 IPv6인 경우 전체 주소가 아닌 길이 64의 IPv6 접두사에 제한이 적용됩니다.

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

/etc/gitlab/gitlab.rb에서 속도 제한을 설정하려면:

1. 다음을 추가합니다:

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

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

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

/etc/gitlab/gitlab.rb에서 속도 제한을 설정하려면:

1. 다음을 추가합니다:

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

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

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

/etc/gitlab/gitlab.rb에서 속도 제한을 설정하려면:

1. 다음을 추가합니다:

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

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

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

/etc/gitlab/gitlab.rb에서 속도 제한을 설정하려면:

1. 다음을 추가합니다:

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

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

관련 주제#

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