• GitLab Pages 데몬
• 필수 구성 요소
  • 도메인을 공개 접미어 목록에 추가
  • DNS 구성
    • 와일드카드 DNS가 아닌 URL 경로의 네임스페이스를 위한 URL 경로
    • 사용자 정의 도메인의 DNS 구성
• 구성
  • 와일드카드 도메인
  • 와일드카드 DNS 없는 Pages 도메인
  • TLS 지원이 있는 와일드카드 도메인
  • TLS 지원을 하는 페이지 도메인의 와일드카드 DNS 없음
  • TLS 종료 로드 밸런서가 있는 와일드카드 도메인
  • 글로벌 설정
• 고급 구성
  • 사용자 정의 도메인
  • TLS 지원하는 사용자 정의 도메인
  • 사용자 정의 도메인 검증
  • Let’s Encrypt 통합
  • 접근 제어
    • Pages의 인증 범위 축소 사용
    • 모든 Pages 사이트에 대한 공개 액세스 비활성화
  • 프록시 뒤에서 실행
  • 사용자 정의 인증 기관(CA) 사용
  • GitLab API를 호출할 때 상호 TLS 지원
  • ZIP 서빙 및 캐시 구성
    • ZIP 캐시 새로고침 예시
  • HTTP Strict Transport Security (HSTS) 지원
  • Pages 프로젝트 리디렉션 제한
• 환경 변수 사용
• 데몬의 상세 로깅 활성화
• 상관 ID 전파
• 저장소 경로 변경
• 역방향 프록시 요청을 위한 리스너 구성
• 각 GitLab Pages 사이트의 전역 최대 크기 설정
• 그룹 내 각 GitLab Pages 사이트의 최대 크기 설정
• 프로젝트에서 GitLab Pages 사이트의 최대 크기 설정
• 프로젝트의 GitLab Pages 사용자 정의 도메인의 최대 수 설정
• 병렬 배포에 대한 기본 만료 구성
• GitLab Pages 웹 사이트 당 파일의 최대 수 설정
• 별도의 서버에서 GitLab Pages 실행
• 도메인 소스 구성
  • GitLab API 캐시 구성
• 오브젝트 저장소 설정
  • S3 호환 연결 설정
  • 페이지 배포를 오브젝트 저장소로 이전
  • 페이지 배포를 로컬 저장소로 롤백하기
  • Pages 로컬 저장소 비활성화
• 다중 노드 환경에서 Pages 네트워크 저장소 활성화
• ZIP 저장소
• 백업
• 보안
  • 요금 한도
    • 소스-IP별 HTTP 요청 요금 한도를 활성화합니다.
    • 도메인별 HTTP 요청 요금 한도를 활성화합니다.
    • 소스-IP별 TLS 연결 요금 한도를 활성화합니다.
    • 도메인별 TLS 연결 요금 한도를 활성화합니다.
• 관련 주제

GitLab Pages 관리

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 데몬을 설치한 서버에 페이지 경로도 있어야 하므로 네트워크를 통해 공유해야 합니다.
• Pages 데몬을 GitLab과 동일한 서버에서 같은 IP에서 다른 포트에 수신시킵니다. 이 경우 교통을 로드 밸런서로 프록시해야 합니다. 이 경로를 선택하는 경우 HTTPS에 대해 TCP 로드 밸런싱을 사용해야 합니다. TLS 종료(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가 있어야 합니다.

도메인을 공개 접미어 목록에 추가

공개 접미어 목록(Public Suffix List)은 브라우저가 하위 도메인을 처리하는 방법을 결정하는 데 사용됩니다. GitLab 인스턴스에서 GitLab 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가 아닌 URL 경로의 네임스페이스를 위한 URL 경로

• GitLab 16.7에서 실험으로 도입됨.
• GitLab 16.11에서 베타로 이동됨.
• GitLab 17.2에서 NGINX에서 GitLab Pages 코드베이스로 구현 변경.
• GitLab 17.4에서 일반적으로 이용 가능함.

와일드카드 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을 IPv6 주소의 버전으로 바꿉니다. 항목은 다음과 같습니다:

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

이 예제에는 다음이 포함됩니다:

• example.io: GitLab Pages를 제공하는 도메인

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

사용자 정의 도메인 지원이 필요한 경우, 페이지 루트 도메인의 모든 하위 도메인은 페이지 데몬을 위해 할당된 보조 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: 페이지 데몬에 할당된 보조 IP. 기본 IP와 달라야 합니다.

참고: GitLab 도메인은 사용자 페이지를 제공하는 데 사용해서는 안 됩니다. 자세한 내용은 보안 섹션을 참조하십시오.

구성

사용 사례에 따라 GitLab Pages를 4가지 다른 방법으로 설정할 수 있습니다.

다음 예제는 가장 쉬운 설정에서 가장 고급 설정까지 나열되어 있습니다. 모든 구성에게 필요한 것은 와일드카드 DNS를 설정하는 것입니다.

와일드카드 도메인

전제 조건:

• 와일드카드 DNS 설정

URL 체계: 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 재구성을 수행합니다.

이 구성에 대한 비디오 튜토리얼을 시청하세요.

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

• GitLab 16.7에서 실험으로 소개됨.
• GitLab 16.11에서 베타로 이동됨.
• GitLab 17.2에서 NGINX에서 GitLab Pages 코드베이스로 구현이 변경됨.
• GitLab 17.4에서 일반적으로 사용 가능.

이 구성은 GitLab Pages의 최소 설정입니다. 모든 다른 구성의 기초가 됩니다. 이 구성에서는 NGINX가 모든 요청을 데몬으로 프록시합니다. 외부 세계에서 GitLab Pages 데몬이 응답하지 않습니다.

전제 조건:

• 와일드카드 없이 DNS 설정을 구성했습니다.

1. /etc/gitlab/gitlab.rb에서 GitLab Pages를 위한 외부 URL을 설정하고 기능을 활성화하세요:

   # External_url here is only for reference
   external_url "http://example.com"
   pages_external_url 'http://example.io'
   
   # 이 기능을 활성화하려면 이 플래그를 설정하세요
   gitlab_pages["namespace_in_path"] = true
   

2. GitLab 재구성을 수행합니다.

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

경고: GitLab Pages는 한 번에 하나의 URL 체계만 지원합니다: 와일드카드 DNS로 제공하는 경우, 또는 와일드카드 DNS를 사용하지 않는 경우. namespace_in_path를 활성화하면 기존의 GitLab Pages 웹사이트는 와일드카드 DNS가 없는 도메인에서만 접근할 수 있습니다.

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

전제 조건:

• 와일드카드 DNS 설정
• TLS 인증서. 와일드카드 또는 요구 사항을 충족하는 다른 유형의 인증서가 있어야 합니다.

URL 체계: 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를 HTTPS 프로토콜로 업데이트하세요. System OAuth application내에서 리디렉션 URI를 업데이트해야 합니다.

경고: 하나의 인스턴스에 대해 여러 와일드카드는 지원되지 않습니다. 인스턴스당 하나의 와일드카드만 할당할 수 있습니다.

경고: GitLab Pages는 리디렉션 URI에 변경이 생기면 OAuth 애플리케이션을 업데이트하지 않습니다. 재구성하기 전에 /etc/gitlab/gitlab-secrets.json에서 gitlab_pages 섹션을 제거하고 gitlab-ctl reconfigure를 실행하세요. 자세한 내용은 GitLab Pages does not regenerate OAuth를 참조하세요.

TLS 지원을 하는 페이지 도메인의 와일드카드 DNS 없음

• 이슈 실험으로 GitLab 16.7에 도입되었습니다.
• 베타로 이동되었습니다. GitLab 16.11에서.
• 구현을 NGINX에서 GitLab Pages 코드베이스로 바꾸었습니다. GitLab 17.2에서.
• GitLab 17.4에 일반적으로 사용 가능하게 되었습니다. (출처)

필수 조건:

• 와일드카드 없이 DNS 설정을 구성했습니다 와일드카드 DNS가없는 URL 경로에서.
• 도메인을 포함하는 TLS 인증서가 있습니다(example.io와 같은).

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

1. TLS 인증서와 키를 /etc/gitlab/ssl에 언급된대로 추가합니다.

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

   # 외부_url 필드는 여기에 참고용으로 남겨두었습니다.
   외부_url "https://example.com"
   페이지_외부_url 'https://example.io'
   
   Pages_nginx['redirect_http_to_https'] = true
   
   # 이 기능을 활성화하려면이 플래그를 설정합니다
   gitlab_pages["namespace_in_path"] = true
   

3. TLS 인증서와 키가 도메인 이름과 일치하지 않는 경우, example.io.crt 및 example.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 Pages 시스템 OAuth 애플리케이션 에서 리디렉션 URI를 업데이트하여 HTTPS 프로토콜을 사용합니다.

   경고: 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는 한 번에 하나의 URL 스킴만 지원합니다: 와일드카드 DNS가 있는 경우 또는 와일드카드 DNS가없는 도메인에서만 기존의 GitLab Pages 웹 사이의 이용이 가능합니다.

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

필수 조건:

• 와일드카드 DNS 설정
• TLS 종료 로드 밸런서

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

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

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

   외부_url "https://example.com" # 외부_url은 여기에 참조용으로만 있습니다
   페이지_외부_url 'https://example.io' # 중요: 외부_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을 다시 구성합니다.

글로벌 설정

아래는 리눅스 패키지 설치 중에 Pages에서 알려진 모든 구성 설정과 그에 대한 설명입니다. 이러한 옵션은 재구성한 후에 /etc/gitlab/gitlab.rb에서 조정할 수 있으며 환경에서 Pages 데몬이 실행되고 콘텐츠를 제공하는 방식에 대해 더 정확한 제어가 필요하지 않는 한 수동으로 구성할 필요는 없습니다.

고급 구성

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

사용자 정의 도메인

필수 사항:

• 와일드카드 DNS 설정
• 보조 IP

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

이 경우 Pages 데몬이 실행 중이며, 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 지원하는 사용자 정의 도메인

필수 사항:

• 와일드카드 DNS 설정
• TLS 인증서. 와일드카드이거나 요구 사양을 충족하는 다른 유형의 인증서일 수 있습니다.
• 보조 IP

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

이 경우 Pages 데몬이 실행 중이며, 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
   

   만약 인증서를 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"
   

3. GitLab 재구성.
4. Pages Access Control을 사용 중이라면 GitLab Pages의 redirect URI를 HTTPS 프로토콜로 업데이트하세요.

사용자 정의 도메인 검증

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

경고: 도메인 검증을 비활성화하는 것은 안전하지 않으며 여러 취약점으로 이어질 수 있습니다. 만약 비활성화한다면, Pages 루트 도메인 자체가 보조 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 접근 제어는 프로젝트별로 구성할 수 있으며 사용자의 프로젝트 멤버십에 기반하여 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. 사용자는 이제 프로젝트 설정에서 이를 구성할 수 있습니다.

참고: 이 설정이 멀티 노드 배포에서 유효하려면 모든 애플리케이션 노드와 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. 변경 사항 저장을 선택합니다.

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

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

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

다음을 수행하려면:

1. 왼쪽 사이드바에서 아래쪽으로 스크롤하여 관리자를 선택합니다.
2. 설정 > 기본 환경설정을 선택합니다.
3. Pages를 확장합니다.
4. Pages 사이트에 대한 공개 액세스 비활성화 확인란을 선택합니다.
5. 변경 사항 저장을 선택합니다.

참고: 관리자 영역에 설정이 표시되려면 먼저 액세스 제어를 활성화해야합니다.

프록시 뒤에서 실행

GitLab의 나머지 부분처럼, Pages도 외부 인터넷 연결이 프록시로 게이트되는 환경에서 사용할 수 있습니다. GitLab Pages에 프록시를 사용하려면:

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

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

2. 변경 사항이 적용되려면 GitLab 재구성을 해야합니다.

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

사용자 지정 CA에서 발급된 인증서를 사용할 때, 액세스 제어 및 HTML 작업 자료의 온라인 보기 에서 작동하지 않을 수 있습니다.

이는 보통 다음 오류로 나타납니다: Post /oauth/token: x509: certificate signed by unknown authority.

리눅스 패키지 설치의 경우, 사용자 정의 CA 설치를 통해 수정할 수 있습니다.

자체 컴파일 설치의 경우, 시스템 인증서 저장소에 사용자 정의 인증 기관(CA)을 설치하여 수정할 수 있습니다.

GitLab API를 호출할 때 상호 TLS 지원

• GitLab 17.1에 도입됨.

전제 조건:

• 인스턴스에서 리눅스 패키지 설치 방법을 사용해야합니다.

만약 GitLab이 상호 TLS를 요구하도록 설정됐다면, GitLab Pages 구성에 클라이언트 인증서를 추가해야합니다.

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

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

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

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

   여러 사용자 지정 인증 기관(CA)에 대한 파일 경로는 쉼표로 구분됩니다.

4. 다중 노드 GitLab Pages 설치가 있는 경우, 모든 노드에서 이러한 단계를 반복합니다.
5. GitLab 노드의 /etc/gitlab/trusted-certs 디렉토리에 전체 인증서 체인 파일 사본을 저장하세요.

ZIP 서빙 및 캐시 구성

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

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

ZIP 캐시 새로고침 예시

아카이브는 zip_cache_expiration 이전에 접근되고 만료까지 남은 시간이 zip_cache_refresh 이하인 경우 캐시에서 새로 고쳐집니다(메모리에 보관되는 시간이 연장됨). 예를 들어, archive.zip이 시간 0초에 접근되면 zip_cache_expiration의 기본값인 60초 후에 만료됩니다. 아래 예시에서는 archive가 15초 후에 다시 열리면 (zip_cache_expiration인 60초보다 작기 때문에) 새로 고쳐지지 않습니다. 그러나, archive가 처음으로 열린 후 45초 후에 다시 열리면 새로 고쳐집니다. 이는 메모리에 남아 있는 아카이브의 시간을 45초 + zip_cache_expiration(60초), 총 105초까지 연장합니다.

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

HTTP Strict Transport Security (HSTS) 지원

HTTP Strict Transport Security (HSTS)는 gitlab_pages['headers'] 구성 옵션을 통해 활성화할 수 있습니다. HSTS는 브라우저에게 방문 중인 웹 사이트가 후속 연결을 암호화되지 않은 상태로 강제할 수 없도록 항상 HTTPS를 통해 콘텐츠를 제공해야 함을 알려줍니다. 또한, 암호화되지 않은 HTTP 채널을 통해 연결을 시도하는 것을 방지하여 페이지 로드 속도를 향상시킬 수 있습니다.

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

Pages 프로젝트 리디렉션 제한

• 도입된 내용 (GitLab 15.2에서.)

GitLab Pages에는 성능에 미치는 영향을 최소화하기 위한 기본 제한이 포함되어 있습니다. 원하는 경우 이러한 제한을 구성하여 늘리거나 줄일 수 있습니다.

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 사이트의 전역 최대 크기 설정

필수 사전 조건:

• 인스턴스에 대한 관리자 액세스해야 합니다.

프로젝트의 전역 최대 페이지 크기를 설정하려면:

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

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

필수 사전 조건:

• 인스턴스에 대한 관리자 액세스해야 합니다.

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

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

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

필수 조건:

• 인스턴스에 관리자 액세스해야 합니다.

프로젝트에서 GitLab Pages 사이트의 최대 크기를 설정하려면 상속된 설정을 재정의해야 합니다:

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

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

필수 조건:

• 인스턴스에 관리자 액세스해야 합니다.

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

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

병렬 배포에 대한 기본 만료 구성

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

필수 조건:

• 인스턴스에 관리자 액세스해야 합니다.

병렬 배포가 삭제되기 전에 인스턴스의 기본 기간을 구성하려면 병렬 배포 의 기본 만료 기간을 입력합니다:

1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
2. 설정 > 기본 설정을 선택합니다.
3. Pages를 확장합니다.
4. 병렬 배포에 대한 기본 만료 기간(초)에 값을 입력합니다. 기본적으로 병렬 배포가 만료되지 않도록 하려면 0을 사용합니다.
5. 변경 사항 저장을 선택합니다.

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

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

GitLab Rails 콘솔 를 사용하여 자체 관리 인스턴스에서 이 제한을 업데이트할 수 있습니다.

더 많은 정보는 GitLab 응용 프로그램 제한 사항 을 참조하세요.

별도의 서버에서 GitLab Pages 실행

GitLab Pages 데몬을 별도의 서버에서 실행하여 주 애플리케이션 서버의 부하를 줄일 수 있습니다. 이 구성은 상호 TLS(mTLS)를 지원하지 않습니다. 자세한 정보는 해당 기능 제안을 참조하세요.

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

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

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

   gitlab_pages['access_control'] = true
   

   경고: 액세스 제어를 사용할 계획이라면 gitlab-secrets.json을 복사하기 전에 첫 번째 GitLab 서버에서 활성화해야 합니다. 액세스 제어를 활성화하면 새로운 OAuth 애플리케이션이 생성되며, 관련 정보가 gitlab-secrets.json으로 전파됩니다. 순서를 잘못 지키면 액세스 제어에 문제가 발생할 수 있습니다.

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 서버에서 GitLab를 Linux 패키지를 사용하여 설치하고 /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. Pages 서버로부터 /etc/gitlab/gitlab-secrets.json 파일을 복사해 GitLab 서버에서 실행하십시오.

    # 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 서버를 재구성하십시오.

12. GitLab 서버에서 /etc/gitlab/gitlab.rb를 다음과 같이 수정하십시오:

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

13. 변경 사항이 적용되도록 GitLab 서버를 재구성하십시오.

원하는 경우 GitLab Pages를 여러 서버에서 실행할 수 있습니다. 이를 위해 DNS 서버를 구성하여 페이지 서버에 대해 여러 IP를 반환하거나 IP 수준에서 작동하는 로드 밸런서를 구성하는 등 표준 로드 밸런싱 방법을 통해 부하를 분산할 수 있습니다. 여러 서버에서 GitLab Pages를 설정하려면 각 Pages 서버에 대해 위의 절차를 수행하십시오.

도메인 소스 구성

GitLab Pages 데몬이 페이지 요청을 제공할 때, 먼저 요청된 URL을 제공할 프로젝트와 해당 컨텐츠가 어떻게 저장되는지 식별해야 합니다.

기본적으로 GitLab Pages는 새 도메인이 요청될 때마다 내부 GitLab API를 사용합니다. Pages는 API에 연결할 수 없는 경우 시작하지 못합니다. 또한 도메인 정보는 Pages 데몬에 의해 캐시되어 이후 요청의 속도를 높입니다.

일반적인 문제의 경우 문제 해결을 참조하세요.

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

GitLab API 캐시 구성

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

참고: 만료, 간격 및 시간 제한 플래그는 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를 줄이면 오류 보고 전에 자동으로 도메인의 구성을 해결한 시도 횟수를 줄입니다.

오브젝트 저장소 설정

다음 오브젝트 저장소 설정은 다음과 같습니다:

• Self-compiled 설치에서 pages: 아래와 object_store: 아래에 중첩됩니다.
• Linux 패키지 설치에서는 pages_object_store_로 접두어가 붙습니다.

참고: NFS 서버를 사용 중지하고 연결을 끊고 싶은 경우 명시적으로 로컬 저장소를 비활성화해야 합니다.

S3 호환 연결 설정

통합된 오브젝트 저장소 설정을 사용해야 합니다.

다른 공급업체에 대한 사용 가능한 연결 설정을 확인하세요.

페이지 배포를 오브젝트 저장소로 이전

기존 페이지 배포 오브젝트(ZIP 아카이브)는 다음에 저장될 수 있습니다:

• 로컬 저장소
• 오브젝트 저장소

기존 페이지 배포를 로컬 저장소에서 오브젝트 저장소로 이전하세요:

sudo gitlab-rake gitlab:pages:deployments:migrate_to_object_storage

모든 페이지 배포가 성공적으로 마이그레이션되었는지 진행상황을 확인하고 확인할 수 있습니다 PostgreSQL 콘솔을 사용하여:

• Linux 패키지 설치의 경우 sudo gitlab-rails dbconsole --database main.
• Self-compiled 설치의 경우 sudo -u git -H psql -d gitlabhq_production.

다음 코드를 사용하여 objectstg 아래(여기서 store=2) 전체 페이지 배포를 확인하세요:

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 로컬 저장소를 비활성화하세요.

페이지 배포를 로컬 저장소로 롤백하기

오브젝트 저장소로의 마이그레이션이 완료된 후, 페이지 배포를 로컬 저장소로 이전할 수 있습니다:

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 아카이브입니다.

이 ZIP 아카이브는 구성되었다면 디스크 저장소에 지역적으로 또는 객체 저장소에 저장될 수 있습니다.

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

백업

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

보안

XSS 공격을 방지하려면 GitLab Pages를 GitLab과는 다른 호스트명에서 실행하는 것이 좋습니다.

요금 한도

• GitLab 17.3에서 변경됨: 페이지 요금 한도에서 서브넷을 제외할 수 있습니다.

건의나 TLS 연결을 초과하는 요청들은 기본적으로 보고되고 거부됩니다.

GitLab Pages는 다음 유형의 요금 한도를 지원합니다:

• source_ip 당. 단일 클라이언트 IP 주소에서 허용되는 요청 또는 TLS 연결의 수를 제한합니다.
• 도메인 당. 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 연결의 최대 임계 값을 설정합니다.
• rate_limit_tls_domain: 호스팅된 페이지 도메인당 초당 TLS 연결의 최대 임계 값을 설정합니다. 이 기능을 비활성화하려면 0으로 설정하십시오.
• rate_limit_tls_domain_burst: 호스팅된 페이지 도메인당 초기 터불림 TLS 연결의 최대 임계 값을 설정합니다.

특정 IP 범위(서브넷)를 모든 요금 한도에서 제외하게하려면:

• rate_limit_subnets_allow_list: 모든 요금 한도를 우회해야 하는 IP 범위(서브넷)를 허용 목록으로 설정합니다. 예를 들어, ['1.2.3.4/24', '2001:db8::1/32']입니다. 차트 예를 참조하십시오.

IPv6 주소는 128비트 주소 공간에서 큰 접두어를받습니다. 일반적으로 접두어는 최소한 /64의 크기입니다. 가능한 주소가 많기 때문에 클라이언트의 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 재구성을 합니다.

관련 주제

• GitLab Pages 관리를 위한 문제 해결