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

GitLab Pages 관리

GitLab Pages는 정적 사이트 호스팅을 허용합니다. 관리자가 설정해야 합니다. 별도의 사용자 문서가 제공됩니다.

GitLab Pages 데몬

GitLab Pages는 외부 IP 주소에서 수신을 할 수 있는 Go로 작성된 기본 HTTP 서버인 GitLab Pages daemon을 사용하며, 맞춤 도메인 및 맞춤 인증서 지원을 제공합니다. 서버 이름 표시(SNI)를 통해 동적 인증서를 지원하며, 기본적으로 HTTP2를 사용하여 페이지를 노출합니다. 작동 방식을 완전히 이해하려면 README를 읽는 것이 좋습니다.

맞춤 도메인 (다만 와일드카드 도메인은 제외) 의 경우, Pages 데몬은 포트 80 및/또는 443에서 수신해야 합니다. 이러한 이유로 구성을 설정하는 방법에 대해 약간의 유연성이 있습니다:

• GitLab과 같은 서버에서 Pages 데몬을 실행하고, 보조 IP에서 수신합니다.
• 별도의 서버에서 Pages 데몬을 실행합니다. 이 경우, Pages 데몬이 설치된 서버에 페이지 경로도 존재해야 하므로, 네트워크를 통해 공유해야 합니다.
• GitLab과 같은 서버에서 Pages 데몬을 실행하고, 같은 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. 선택 사항. Pages를 HTTPS를 통해 제공하기로 결정한 경우 해당 도메인에 대한 와일드카드 인증서가 있어야 합니다.
4. 선택 사항이지만 권장 사항. 인스턴스 러너를 활성화하여 사용자가 자신의 러너를 가져오지 않도록 합니다.
5. 맞춤 도메인의 경우, 보조 IP가 있어야 합니다.

Public Suffix List에 도메인 추가하기

Public Suffix List는 브라우저가 서브 도메인을 처리하는 방법을 결정하는 데 사용됩니다. GitLab 인스턴스가 일반 사용자가 GitLab Pages 사이트를 생성할 수 있도록 허용하면, 해당 사용자가 페이지 도메인(example.io)에 서브 도메인을 생성할 수 있도록 허용합니다. 도메인을 Public Suffix List에 추가하면 브라우저가 슈퍼쿠키를 수용하는 것을 방지합니다.

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

DNS 구성

GitLab Pages는 자체 가상 호스트에서 실행될 것으로 예상됩니다. DNS 서버/제공자에서 와일드카드 DNS A 레코드를 추가하여 GitLab이 실행되는 호스트를 가리키게 하세요. 예를 들어, 항목은 다음과 같이 보입니다:

*.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 경로의 네임스페이스 지원

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

URL 경로의 네임스페이스에 대한 요구 사항을 제거하기 위해 와일드카드 DNS에 대한 지원이 필요하면:

1. 다음 기능의 GitLab Pages 플래그를 활성화하려면 /etc/gitlab/gitlab.rb에 gitlab_pages["namespace_in_path"] = true를 추가하세요.

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로 포인팅해야 합니다. 이 구성이 없으면 사용자는 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 도메인을 사용해서는 안 됩니다. 자세한 내용은 보안 섹션을 참조하세요.

구성

필요에 따라 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은 참고용입니다.
   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가 있는 경우 또는 없는 경우.

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

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

경고: GitLab Pages는 리디렉션 URI를 변경하더라도 OAuth 애플리케이션을 업데이트하지 않습니다.

재구성하기 전에 /etc/gitlab/gitlab-secrets.json에서 gitlab_pages 섹션을 제거한 다음 gitlab-ctl reconfigure를 실행하세요. 자세한 내용은 GitLab Pages는 OAuth를 재생성하지 않습니다를 참조하세요.

와일드카드 DNS 없이 TLS 지원을 포함한 Pages 도메인

• GitLab 16.7에서 실험으로 도입되었습니다.
• GitLab 16.11에서 베타로 이동했습니다.
• GitLab 17.2에서 구현이 NGINX에서 GitLab Pages 코드베이스로 변경되었습니다.
• GitLab 17.4에서 일반적으로 사용 가능해졌습니다.

필수 조건:

• 와일드카드가 없는 DNS 설정을 구성해야 합니다. URL 경로의 네임스페이스가 없는 경우.
• 도메인을 포함하는 TLS 인증서가 필요합니다 (예: example.io).

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

1. 필수 조건에서 언급한 TLS 인증서와 키를 /etc/gitlab/ssl에 추가합니다.

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

   # external_url 필드는 참조용입니다.
   external_url "https://example.com"
   pages_external_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. Pages 액세스 제어를 사용하는 경우, GitLab Pages의 리디렉션 URI를 시스템 OAuth 애플리케이션에서 HTTPS 프로토콜을 사용하도록 업데이트합니다.

   경고: 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>입니다.

경고: GitLab Pages는 한 번에 하나의 URL 스킴만 지원합니다: 와일드카드 DNS 사용 시 또는 와일드카드 DNS 미사용 시.

namespace_in_path를 활성화하면 기존 GitLab Pages 웹사이트는 와일드카드 DNS가 없는 도메인에서만 접근할 수 있습니다.

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

사전 요구 사항:

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

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

이 설정은 주로 Amazon Web Services에 GitLab POC를 설치할 때 사용됩니다. 여기에는 HTTPS 연결을 수신하고, TLS 인증서를 관리하고, 인스턴스로 HTTP 트래픽을 전달하는 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 재구성하기.

전역 설정

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

대부분의 이러한 설정은 Pages 데몬이 귀하의 환경에서 어떻게 실행되고 콘텐츠를 제공할지를 보다 세밀하게 제어할 필요가 없는 한 수동으로 구성할 필요가 없습니다.

고급 구성

와일드카드 도메인 외에, GitLab Pages를 사용자 정의 도메인과 함께 작동하도록 구성할 수 있는 옵션도 있습니다. 여기에는 TLS 인증서가 있는 사용자 정의 도메인과 TLS 인증서가 없는 사용자 정의 도메인의 두 가지 옵션이 있습니다. 가장 쉬운 설정은 TLS 인증서가 없는 것입니다. 두 경우 모두 보조 IP가 필요합니다. IPv4 주소와 함께 IPv6 주소가 있는 경우 두 가지 모두 사용할 수 있습니다.

사용자 정의 도메인

전제 조건:

• 와일드카드 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
   

   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. Pages 액세스 제어를 사용하고 있는 경우, GitLab Pages의 시스템 OAuth 애플리케이션에서 리디렉션 URI를 HTTPS 프로토콜을 사용하도록 업데이트하십시오.

사용자 지정 도메인 검증

악의적인 사용자가 자신에게 속하지 않는 도메인을 탈취하지 못하도록, GitLab은 사용자 지정 도메인 검증을 지원합니다.
사용자 지정 도메인을 추가할 때, 사용자는 해당 도메인에 대한 DNS 레코드에
GitLab에서 제어하는 검증 코드를 추가하여 소유권을 증명해야 합니다.

경고:
도메인 검증을 비활성화하는 것은 안전하지 않으며 다양한 취약점으로 이어질 수 있습니다.
비활성화할 경우, Pages 루트 도메인 자체가 보조 IP를 가리키지 않도록 하거나
루트 도메인을 프로젝트의 사용자 지정 도메인으로 추가해야 합니다; 그렇지 않으면,
모든 사용자가 이 도메인을 자신의 프로젝트에 사용자 지정 도메인으로 추가할 수 있습니다.

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

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

접근 제어

GitLab Pages 접근 제어는 프로젝트별로 구성할 수 있으며,
사용자의 프로젝트에 대한 구성원을 기반으로 Pages 사이트에 대한 접근을 제어할 수 있습니다.

접근 제어는 Pages 데몬을 GitLab의 OAuth 애플리케이션으로 등록하여 작동합니다.
인증되지 않은 사용자가 비공개 Pages 사이트에 접근 요청을 할 때마다,
Pages 데몬은 사용자를 GitLab으로 리디렉션합니다.
인증이 성공하면, 사용자는 토큰과 함께 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 애플리케이션을 수정해야 합니다.
이를 수행하기 위한 단계는 다음과 같습니다:

1. 접근 제어를 활성화합니다.
2. 왼쪽 사이드바에서 맨 아래 Admin을 선택합니다.
3. Applications를 선택합니다.
4. GitLab Pages를 확장합니다.
5. api 범위의 체크박스를 지우고 원하는 범위의 체크박스를 선택합니다 (예: read_api).
6. Save changes를 선택합니다.

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

GitLab 인스턴스에서 호스팅되는 모든 GitLab Pages 웹사이트에 대해 액세스 제어를 적용할 수 있습니다.

이렇게 하면 인증된 사용자만이 해당 웹사이트에 접근할 수 있습니다.

이 설정은 개별 프로젝트에서 사용자가 설정한 액세스 제어를 무시합니다.

이것은 Pages 웹사이트에 게시된 정보를 인스턴스의 사용자에게만 제한하는 데 도움이 될 수 있습니다.

이를 위해 다음과 같이 진행하세요:

1. 왼쪽 사이드바에서 맨 아래에 있는 Admin을 선택합니다.

2. Settings > Preferences를 선택합니다.

3. Pages를 확장합니다.

4. Disable public access to Pages sites 체크박스를 선택합니다.

5. Save changes를 선택합니다.

프록시 뒤에서 실행

GitLab의 나머지와 마찬가지로, Pages는 외부 인터넷 연결이 프록시로 제한된 환경에서도 사용할 수 있습니다.

GitLab Pages에 프록시를 사용하려면:

1. /etc/gitlab/gitlab.rb에서 구성합니다:

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

2. 변경 사항을 적용하려면 GitLab 재구성을 수행합니다.

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

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

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

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

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

GitLab API 호출 시 상호 TLS 지원

• GitLab 17.1에 도입됨.

전제 조건:

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

GitLab이 상호 TLS를 요구하도록 구성된 경우,

클라이언트 인증서를 GitLab Pages 구성에 추가해야 합니다.

인증서는 다음 요구 사항을 충족해야 합니다:

• 인증서에는 주체 대체 이름(Subject Alternative Name)으로 호스트 이름 또는 IP 주소가 지정되어야 합니다.
• 전체 인증서 체인이 필요하며, 끝 사용자 인증서, 중간 인증서 및 루트 인증서를 해당 순서로 포함해야 합니다.

인증서의 일반 이름(Common Name) 필드는 무시됩니다.

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에 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 강제 전송 보안 (HSTS) 지원

HTTP 강제 전송 보안 (HSTS)는 gitlab_pages['headers'] 구성 옵션을 통해 활성화할 수 있습니다. HSTS는 브라우저에 방문하는 웹사이트가 항상 HTTPS를 통해 콘텐츠를 제공해야 함을 알립니다. 이로 인해 공격자가 후속 연결을 암호화되지 않은 상태로 강제하는 것을 방지할 수 있습니다. 또한 브라우저가 HTTPS로 리디렉션되기 전에 암호화되지 않은 HTTP 채널을 통해 연결을 시도하는 것을 방지하여 페이지 로딩 속도를 개선할 수 있습니다.

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

Pages 프로젝트 리디렉션 제한

• 도입됨 GitLab 15.2에서.

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

전제 조건:

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

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

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

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

Offering: Self-managed

선행 조건:

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

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

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.

2. 설정 > 일반을 선택합니다.

3. Pages를 확장합니다.

4. 최대 크기 아래에 MB 단위로 값을 입력합니다.

5. 변경 사항 저장을 선택합니다.

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

Offering: Self-managed

선행 조건:

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

프로젝트 내 GitLab Pages 사이트의 최대 크기를 설정하려면, 상속된 설정을 무시하고:

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.

2. 배포 > Pages를 선택합니다.

3. Pages의 최대 크기에서 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 Pages를 사용하려면 먼저 첫 번째 GitLab 서버에서 이를 활성화해야 합니다. gitlab-secrets.json을 복사하기 전에 액세스 제어를 활성화해야 합니다. 액세스 제어를 활성화하면 새로운 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. 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 서버를 재구성하여 변경 사항이 적용되도록 합니다.

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 서버를 구성하여 Pages 서버에 대한 여러 IP를 반환하거나, IP 수준에서 작동하는 로드 밸런서를 구성하는 등의 표준 로드 밸런싱 방식을 통해 이를 수행할 수 있습니다. 여러 서버에서 GitLab Pages를 설정하려면, 각 Pages 서버에 대해 위 절차를 수행하십시오.

도메인 소스 구성

GitLab Pages 데몬이 페이지 요청을 서비스할 때, 우선 어떤 프로젝트를 사용하여 요청된 URL을 제공할 것인지와 그 콘텐츠가 어떻게 저장되는지를 식별해야 합니다.

기본적으로, GitLab Pages는 새 도메인이 요청될 때마다 내부 GitLab API를 사용합니다.

API에 연결할 수 없는 경우 Pages는 시작되지 않습니다.

도메인 정보는 Pages 데몬에 의해 캐시되어, 후속 요청의 속도를 높입니다.

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

자세한 내용은 이 블로그 게시물을 참조하세요.

GitLab API 캐시 구성

API 기반 구성은 Pages 제공의 성능과 신뢰성을 개선하기 위해 캐싱 메커니즘을 사용합니다.

캐시 동작은 캐시 설정을 변경하여 수정할 수 있지만, 권장되는 값이 설정되어 있으므로 필요한 경우에만 수정해야 합니다.

이 값들을 잘못 구성하면 간헐적이거나 지속적인 오류가 발생하거나, Pages Daemon이 오래된 콘텐츠를 제공할 수 있습니다.

예시:

• 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에 대한 요청이
  더 자주 발생하며, 예를 들어 연결 타임아웃과 같은 오류 응답이 있을 때만 요청이 발생합니다.

• gitlab_retrieval_retries를 감소시키면 도메인의
  구성을 자동으로 해결하는 시도가 오류를 보고하기 전에 줄어듭니다.

오브젝트 스토리지 설정

다음 오브젝트 스토리지 설정은 다음과 같습니다:

• 자가 컴파일된 설치에서는 pages: 아래와 object_store: 아래에 중첩됩니다.

• 리눅스 패키지 설치에서는 pages_object_store_로 접두어가 붙습니다.

S3 호환 연결 설정

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

다양한 공급자를 위한 사용 가능한 연결 설정을 참조하세요.

페이지 배포를 개체 저장소로 마이그레이션하기

기존 페이지 배포 객체(압축 파일)는 다음의 두 곳에 저장될 수 있습니다:

• 로컬 저장소
• 개체 저장소

기존 페이지 배포를 로컬 저장소에서 개체 저장소로 마이그레이션하세요:

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.

아래의 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

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

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

개체 저장소로의 마이그레이션이 완료된 후, 페이지 배포를 로컬 저장소로 다시 이동할 수 있습니다:

sudo gitlab-rake gitlab:pages:deployments:migrate_to_local

페이지 로컬 저장소 비활성화

개체 저장소를 사용하는 경우, 불필요한 디스크 사용/작성을 피하기 위해 로컬 저장소를 비활성화할 수 있습니다:

1. /etc/gitlab/gitlab.rb 파일을 편집하세요:

   gitlab_rails['pages_local_store_enabled'] = false
   

2. 변경 사항을 적용하기 위해 GitLab 재구성하세요.

다중 노드 환경에서 페이지 네트워크 저장소 활성화

개체 저장소는 대부분의 환경에서 선호되는 구성입니다. 그러나 네트워크 저장소가 필요하고 페이지를 별도의 서버에서 실행하도록 구성하려면 다음을 수행해야 합니다:

1. 사용하려는 공유 저장소 볼륨이 이미 마운트되고 기본 서버와 페이지 서버 모두에서 사용 가능한지 확인하세요.

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

   gitlab_pages['enable_disk'] = true
   gitlab_rails['pages_path'] = "/var/opt/gitlab/gitlab-rails/shared/pages" # 네트워크 저장소의 경로
   

3. 페이지를 별도의 서버로 전환하세요.

별도의 서버에서 페이지가 성공적으로 구성되면, 해당 서버만 공유 저장소 볼륨에 접근할 수 있습니다. 다시 단일 노드 환경으로 마이그레이션해야 할 경우를 대비하여 기본 서버에 공유 저장소 볼륨을 마운트 상태로 유지하는 것이 좋습니다.

ZIP 저장소

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

이 ZIP 아카이브는 디스크 저장소에 로컬로 저장되거나 개체 저장소에 저장될 수 있습니다.

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

백업

GitLab 페이지는 정기 백업의 일부이므로 별도의 백업을 구성할 필요가 없습니다.

보안

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

요청 제한

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

서비스 거부(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 연결 수의 최대 임계값을 설정합니다. 예를 들어, 동시에 다양한 웹 브라우저에서 웹 페이지를 열 때입니다.
• 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 관리 문제 해결