GitLab Pages 데몬
사전 조건
- 도메인을 공개 접두어 디렉터리에 추가
- DNS 구성
  - URL 경로에 와일드카드 DNS가 없는 경우의 네임스페이스
  - 사용자 정의 도메인을위한 DNS 구성
설정
- 와일드카드 도메인
- 와일드카드 DNS가없는 Pages 도메인
- TLS 지원을 하는 와일드카드 도메인
- 와일드카드 DNS 없이 TLS 지원을 하는 Pages 도메인
- TLS-종료 로드 밸런서와 와일드카드 도메인
- 전역 설정
고급 구성
- 사용자 정의 도메인
- TLS 지원이 포함된 사용자 정의 도메인
- Let’s Encrypt 통합
- 접근 제어
  - 줄인 인증 범위로 Pages 사용
  - 모든 Pages 사이트의 공개 액세스 비활성화
- 프록시 뒤에서 실행
- 사용자 정의 Certificate Authority (CA) 사용
- ZIP 서빙 및 캐시 구성
  - ZIP 캐시 새로고침 예시
- HTTP Strict Transport Security (HSTS) 지원
- Pages 프로젝트 리디렉트 제한
환경 변수 사용
데몬을 위한 상세 로깅 활성화
상관 ID 전파
저장 경로 변경
역방향 프록시 요청을 위한 리스너 구성
각 GitLab Pages 사이트의 전역 최대 크기 설정
그룹 내 각 GitLab Pages 사이트의 최대 크기 설정
프로젝트의 GitLab Pages 사이트의 최대 크기 설정
프로젝트의 GitLab Pages 사용자 정의 도메인당 최대 수 설정
GitLab Pages 웹사이트당 최대 파일 수 설정
별도의 서버에서 GitLab Pages 실행
도메인 소스 구성
- GitLab API 캐시 구성
객체 리포지터리 설정
- S3 호환 연결 설정
- 페이지 배포를 객체 리포지터리로 이관
- 페이지 배포를 로컬 리포지터리로 롤백
- 로컬 리포지터리 비활성화
멀티노드 환경에서 페이지 네트워크 리포지터리 활성화
ZIP 리포지터리
백업
보안
- 요율 제한
관련 주제

GitLab Pages 관리

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

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

노트: 이 안내서는 Linux 패키지 설치를 위한 것입니다. 자체 컴파일된 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 데몬이 설치된 서버에도 Pages 경로가 있어야 하므로 네트워크를 통해 공유해야 합니다.
Pages 데몬을 GitLab과 동일한 서버에서 동일한 IP에서 다른 포트에서 수신 대기 설정. 이 경우 트래픽을 로드 밸런서로 프록시해야 합니다. 이 경로를 선택하는 경우 HTTPS에 대해 TCP 로드 밸런싱을 사용해야 합니다. TLS 종료(HTTPS 로드 밸런싱)를 사용하는 경우 사용자 제공 인증서로 페이지를 제공할 수 없습니다. HTTP의 경우 HTTP 또는 TCP 로드 밸런싱을 사용해도 됩니다.

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

사전 조건

Pages 구성을 진행하기 전에 다음 사항을 준비해야 합니다.

GitLab 인스턴스 도메인의 하위 도메인이 아닌 Pages용 도메인을 가져야 합니다.

GitLab 도메인 Pages 도메인 작동 여부

example.com example.io 예
example.com pages.example.com 아니요
gitlab.example.com pages.example.com 예
와일드카드 DNS 레코드를 구성해야 합니다.
옵션입니다. HTTPS로 Pages를 제공하려면 해당 도메인에 대한 와일드카드 인증서가 있어야 합니다.
옵션입니다만 권장됩니다. 사용자들이 직접 사용자 제공 인스턴스를 가져 오지 않도록하기 위해 인스턴스 러너를 활성화해야 합니다.
사용자 정의 도메인의 경우 보조 IP를 가져야 합니다.

GitLab 도메인	Pages 도메인	작동 여부
`example.com`	`example.io`	예
`example.com`	`pages.example.com`	아니요
`gitlab.example.com`	`pages.example.com`	예

노트: GitLab 인스턴스 및 Pages 데몬이 사설 네트워크나 방화벽 뒤에 배포된 경우, GitLab Pages 웹 사이트는 해당 사설 네트워크에 액세스 권한이있는 디바이스/사용자만 접근할 수 있습니다.

도메인을 공개 접두어 디렉터리에 추가

공개 접두어 디렉터리은 브라우저가 하위 도메인을 처리하는 방법을 결정하는 데 사용됩니다. GitLab 인스턴스가 공개 멤버가 GitLab Pages 사이트를 생성하도록 허용하면, 그 사용자가 페이지 도메인(example.io)의 하위 도메인을 만드는 것도 허용하므로 수퍼쿠키(supercookies)를 포함하여 브라우저가 수락하지 않도록 하는 것 등을 방지합니다.

이 지침을 따라 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 레코드를 생략할 수 있습니다.

URL 경로에 와일드카드 DNS가 없는 경우의 네임스페이스

Status: Experiment

GitLab 16.7에서 소개되었습니다. 이 기능은 실험 중입니다.

Self-managed GitLab의 경우, 기본적으로이 기능을 사용할 수 있습니다. GitLab.com 및 전용 GitLab에서는이 기능을 사용할 수 없습니다. 이 기능은 프로덕션 환경에서 사용할 준비가되지 않았습니다.

전제 조건:

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

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

/etc/gitlab/gitlab.rb에 다음과 같이이 기능을위한 GitLab Pages 플래그를 활성화하여이 기능을 사용합니다. gitlab_pages ["namespace_in_path"] = true
DNS 공급 업체에서 example.com 및 projects.example.com 항목을 추가하십시오. 두 줄 모두 example.com을 도메인 이름으로, 192.0.0.0을 IP 주소의 IPv4 버전으로 변경하십시오. 항목은 다음과 같습니다:
```
example.com          1800 IN A    192.0.0.0
projects.example.com 1800 IN A    192.0.0.0
```
선택 사항. GitLab 인스턴스에 IPv6 주소가있는 경우 해당 주소에 대한 항목을 추가하십시오. 두 줄 모두 example.com을 도메인 이름으로, 2001: db8 :: 1을 IP 주소의 IPv6 버전으로 변경하십시오. 항목은 다음과 같습니다:
```
example.com          1800 IN AAAA 2001:db8::1
projects.example.com 1800 IN AAAA 2001:db8::1
```

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

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

GitLab 도메인을 사용하여 사용자 페이지를 제공하면 안됩니다. 자세한 정보는 security section을 참조하십시오.

설정

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

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

와일드카드 도메인

요구 사항:

와일드카드 DNS 설정

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

위는 Pages를 사용할 수있는 최소 구성입니다. 다른 모든 설정을 위한 기본입니다. NGINX는 모든 요청을 데몬으로 프록시합니다. Pages 데몬은 외부 세계로 듣지 않습니다.

/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이 될 수 없습니다

GitLab 재구성을 수행하십시오.

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

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

Status: Experiment

GitLab 16.7에서 소개되었습니다. 이 기능은 실험 중입니다.

GitLab Pages에 대한 최소 설정은이 구성입니다. 다른 모든 구성의 기본입니다. 이 설정에서 NGINX는 모든 요청을 데몬으로 프록시합니다. 외부 세계로 듣지 않기 때문에 GitLab Pages 데몬이.

전제 조건:

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

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

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

GitLab 재구성을 수행하십시오.

NGINX는 사용자가 네임 스페이스를 GitLab Pages 데몬에 전달하기 위해 사용자 정의 프록시 헤더 X-Gitlab-Namespace-In-Path을 사용합니다.

결과적인 URL 스키마는 http://example.io/<namespace>/<project_slug>입니다.

TLS 지원을 하는 와일드카드 도메인

요구 사항:

와일드카드 DNS 설정
TLS 인증서. 와일드카드거나, 요구 사항을 충족하는 다른 유형일 수 있습니다.

URL 구조: https://<namespace>.example.io/<project_slug>

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

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

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

external_url "https://example.com" # external_url here is only for reference
pages_external_url 'https://example.io' # 중요: external_url의 서브도메인이 아니므로 https://pages.example.com이 될 수 없습니다.
   
pages_nginx['redirect_http_to_https'] = true

인증서와 키를 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"

GitLab을 다시 구성.
Pages Access Control을 사용 중인 경우, GitLab Pages의 리디렉션 URI를 업데이트하여 System OAuth application이 HTTPS 프로토콜을 사용하도록 합니다.

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

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

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

상태: 실험

GitLab 16.7에서 소개됨. 이 기능은 실험 상태입니다.

플래그: 온프레미스 GitLab의 경우, 기본적으로 이 기능을 사용할 수 있습니다. GitLab.com 및 GitLab Dedicated의 경우, 이 기능을 사용할 수 없습니다. 이 기능은 프로덕션 환경에 사용할 수 없습니다.

전제 조건:

인스턴스는 Linux 패키지 설치 방법을 사용해야 합니다.
와일드카드 없이 DNS 설정을 구성했습니다.
도메인(예: example.com)과 도메인의 projects.* 버전(예: projects.example.com)을 모두 포함하는 단일 TLS 인증서가 있어야 합니다.

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

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

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

# external_url 필드는 여기에 참고용으로 표시되었습니다.
external_url "https://example.com"
pages_external_url 'https://example.io'
   
pages_nginx['enable'] = true
pages_nginx['redirect_http_to_https'] = true
   
# 이 플래그를 설정하여 이 기능을 활성화합니다
gitlab_pages["namespace_in_path"] = true

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"
```
GitLab을 다시 구성.

GitLab Pages는 리디렉션 URI에 변경 내용이 있는 경우 OAuth 애플리케이션을 업데이트하지 않습니다. 재구성하기 전 /etc/gitlab/gitlab-secrets.json에서 gitlab_pages 섹션을 제거한 후 gitlab-ctl reconfigure를 실행합니다. 자세한 내용은 GitLab Pages does not regenerate OAuth를 참조하세요.
Pages Access Control을 사용 중인 경우, GitLab Pages의 리디렉션 URI를 업데이트하여 System OAuth application이 HTTPS 프로토콜을 사용하도록 합니다.

NGINX는 네임스페이스를 GitLab Pages 데몬으로 보내기 위해 커스텀 프록시 헤더 X-Gitlab-Namespace-In-Path를 사용합니다.

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

TLS-종료 로드 밸런서와 와일드카드 도메인

요구 사항:

URL 구성: https://<namespace>.example.io/<project_slug>

이 설정은 주로 Amazon Web Services에 GitLab POC를 설치할 때 사용될 목적으로 되어 있습니다. 이것은 HTTPS 연결을 수신하고 TLS 인증서를 관리하며 HTTP 트래픽을 인스턴스로 전달하는 TLS-종료 클래식 로드 밸런서를 포함합니다.

/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

GitLab 다시 구성.

전역 설정

다음은 Linux 패키지 설치에서 페이지에 알려진 모든 구성 설정의 표입니다. 그리고 그들이 하는 일입니다. 이러한 옵션은 /etc/gitlab/gitlab.rb에서 조정할 수 있으며, GitLab 다시 구성 후에 효과가 있습니다. 이러한 설정 중 대부분은 환경에서 페이지 데몬이 실행되고 콘텐츠를 제공하는 방식에 대한 더 세부적인 제어가 필요하지 않은 한 매뉴얼으로 구성할 필요가 없습니다.

설정	설명
`pages_external_url`	GitLab 페이지에 액세스할 수 있는 URL로, 프로토콜(HTTP/HTTPS)을 포함합니다. `https://`을 사용하는 경우 추가적인 구성이 필요합니다. 자세한 내용은 TLS 지원 와일드카드 도메인 및 TLS 지원 사용자 정의 도메인을 참조하십시오.
`gitlab_pages[]`
`access_control`	액세스 제어을 활성화할지 여부입니다.
… (이하 생략) …

[중략]

고급 구성

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

사용자 정의 도메인

요구 사항:

와일드카드 DNS 설정
보조 IP

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

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

/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 주소는 생략할 수 있습니다.

GitLab 재구성.

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

요구 사항:

와일드카드 DNS 설정
TLS 인증서. 와일드카드일 수도 있고, 요구 사항을 충족하는 다른 유형일 수도 있습니다.
보조 IP

URL 체계: https://<namespace>.example.io/<project_slug> and https://custom-domain.com

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

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

/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 주소는 생략할 수 있습니다.

만약 인증서를 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"
```
GitLab 재구성.
접근 제어를 사용 중이라면, GitLab Pages의 리디렉션 URI를 HTTPS 프로토콜을 사용하도록 업데이트합니다.

Let’s Encrypt 통합

GitLab 12.1에서 소개되었습니다.

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

이를 활성화하려면:

만료되는 도메인에 대한 알림을 받길 원하는 이메일 주소를 선택하세요.
왼쪽 사이드바에서 맨 아래에 있는 관리 영역을 선택하세요.
설정 > 기본 설정을 선택하세요.
Pages를 확장하세요.
알림을 받을 이메일 주소를 입력하고 Let’s Encrypt의 서비스 약관을 동의하세요.
변경 사항 저장을 선택하세요.

접근 제어

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

접근 제어는 Pages 데몬을 GitLab OAuth 애플리케이션으로 등록함으로써 동작합니다. 인증되지 않은 사용자가 비공개 Pages 사이트에 액세스를 요청하면, Pages 데몬은 사용자를 GitLab로 리디렉션합니다. 인증이 성공하면 사용자는 페이지로 토큰이 포함된 쿠키와 함께 리디렉션됩니다. 쿠키는 비밀 키로 서명되므로 조작이 감지될 수 있습니다.

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

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

/etc/gitlab/gitlab.rb에서 활성화하세요:
```
gitlab_pages['access_control'] = true
```
GitLab 재구성하세요.
사용자들은 이제 프로젝트 설정에서 구성할 수 있습니다.

이 설정이 다중 노드 설정에서 올바르게 작동하려면 모든 App 노드 및 Sidekiq 노드에 적용되어야 합니다.

줄인 인증 범위로 Pages 사용

GitLab 13.10에서 소개되었습니다.

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

gitlab_pages['auth_scope'] = 'read_api'

인증에 사용할 범위는 GitLab Pages OAuth 애플리케이션 설정과 일치해야 합니다. 기존 애플리케이션 사용자는 GitLab Pages OAuth 애플리케이션을 수정해야 합니다. 이 작업을 수행하려면 다음 단계를 따르세요:

접근 제어를 활성화하세요.
왼쪽 사이드바에서 맨 아래에 있는 관리 영역을 선택하세요.
애플리케이션을 선택하세요.
GitLab Pages를 확장하세요.
api 범위의 확인란을 해제하고 원하는 범위의 확인란을 선택하세요(예: read_api).
변경 사항 저장을 선택하세요.

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

GitLab 12.7에서 소개되었습니다.

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

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

왼쪽 사이드바에서 맨 아래에 있는 관리 영역을 선택하세요.
설정 > 기본 설정을 선택하세요.
Pages를 확장하세요.
Pages 사이트의 공개 액세스 비활성화 확인란을 선택하세요.
변경 사항 저장을 선택하세요.

관리 영역에서 설정이 표시되려면 먼저 접근 제어를 활성화해야 합니다.

프록시 뒤에서 실행

GitLab과 마찬가지로, Pages는 외부 인터넷 연결이 프록시에 의해 제한되는 환경에서 사용할 수 있습니다. GitLab Pages를 사용하려면 프록시를 구성해야 합니다:

/etc/gitlab/gitlab.rb에서 구성하세요:

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

변경 사항이 적용되려면 GitLab 재구성하세요.

사용자 정의 Certificate Authority (CA) 사용

사용자 정의 CA가 발급한 인증서를 사용할 때, 접근 제어 및 HTML 작업 artifact의 온라인 보기가 사용되지 않을 수 있습니다.

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

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

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

ZIP 서빙 및 캐시 구성

GitLab 13.7에 도입되었습니다.

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

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

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

ZIP 캐시 새로고침 예시

아카이브가 zip_cache_expiration 이전에 액세스되고 남아있는 시간이 zip_cache_refresh보다 작거나 같은 경우(확장되는 메모리에 보유되는 시간), 캐시에서 아카이브가 새로 고쳐집니다. 예를 들어, archive.zip이 0초에 액세스된 경우 (zip_cache_expiration의 기본값인 60초) 의 시간에 만료됩니다. 아래의 예시에서 15초 후에 아카이브가 다시 열리면 (zip_cache_refresh의 기본값인 30초) 아카이브는 새로 고쳐지지 않습니다. 왜냐하면 만료까지 남은 시간(45초)이 zip_cache_refresh (기본값 30초)보다 크기 때문입니다. 그러나 아카이브가 처음 열린 후 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는 페이지 제공의 영향을 최소화하기 위해 _redirects 파일에 대한 기본 제한 세트로 제공됩니다. 이러한 제한을 늘리거나 줄이고 싶다면 이러한 제한을 구성할 수 있습니다.

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

환경 변수 사용

페이지 데몬에 환경 변수를 전달할 수 있습니다 (예를 들어, 피처 플래그를 활성화 또는 비활성화 하는 등).

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

/etc/gitlab/gitlab.rb를 편집하십시오:

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

파일을 저장하고 GitLab을 재구성하십시오:
```
sudo gitlab-ctl reconfigure
```

데몬을 위한 상세 로깅 활성화

다음 단계를 따라 GitLab Pages 데몬의 상세 로깅을 구성할 수 있습니다.

기본적으로 데몬은 INFO 레벨로만 로그를 기록합니다. DEBUG 레벨의 이벤트를 로깅하고 싶을 경우, /etc/gitlab/gitlab.rb에서 이를 구성해야 합니다:
```
gitlab_pages['log_verbose'] = true
```
GitLab 재구성을 수행하십시오.

상관 ID 전파

GitLab 13.10에서 도입되었습니다.

propagate_correlation_id를 true로 설정하면 역방향 프록시를 통해 설치된 항목이 GitLab Pages에 전송된 요청에 대한 상관 ID를 생성하고 설정합니다. 역방향 프록시가 헤더 값을 X-Request-ID로 설정하면 해당 값은 요청 체인으로 전파됩니다. 사용자들은 로그에서 상관 ID를 찾을 수 있습니다.

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

/etc/gitlab/gitlab.rb에서 매개변수를 true로 설정하세요:
```
gitlab_pages['propagate_correlation_id'] = true
```
GitLab을 재구성하세요.

저장 경로 변경

기본 경로를 변경하려면 다음 단계를 따르세요.

페이지는 기본적으로 /var/opt/gitlab/gitlab-rails/shared/pages에 저장됩니다. 다른 위치에 저장하려는 경우 /etc/gitlab/gitlab.rb에서 설정해야 합니다:
```
gitlab_rails['pages_path'] = "/mnt/storage/pages"
```
GitLab을 재구성하세요.

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

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

기본적으로 리스너는 localhost:8090에서 요청을 수신하도록 구성됩니다.
비활성화하려는 경우 /etc/gitlab/gitlab.rb에서 이를 구성해야 합니다:
```
gitlab_pages['listen_proxy'] = nil
```
다른 포트에서 수신하고 싶을 경우 또한 /etc/gitlab/gitlab.rb에서 구성해야 합니다:
```
gitlab_pages['listen_proxy'] = "localhost:10080"
```
GitLab을 재구성하세요.

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

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

전제 조건:

해당 인스턴스에 대한 관리자 액세스가 있어야 합니다.

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

왼쪽 사이드바에서 관리자 영역을 선택하세요.
설정 > 환경 설정을 선택하세요.
Pages를 확장하세요.
페이지 최대 크기에 값을 입력하세요. 기본값은 100입니다.
변경 사항 저장을 선택하세요.

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

Tier: Premium, Ultimate Offering: Self-managed

전제 조건:

해당 인스턴스에 대한 관리자 액세스가 있어야 합니다.

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

왼쪽 사이드바에서 검색 또는 이동을 선택하여 그룹을 찾으세요.
설정 > 일반을 선택하세요.
Pages를 확장하세요.
최대 크기 아래에 MB 단위로 값을 입력하세요.
변경 사항 저장을 선택하세요.

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

Tier: Premium, Ultimate Offering: Self-managed

전제 조건:

해당 인스턴스에 대한 관리자 액세스가 있어야 합니다.

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

왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾으세요.
배포 > 페이지를 선택하세요.
페이지 최대 크기에 MB 단위로 크기를 입력하세요.
변경 사항 저장을 선택하세요.

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

전제 조건:

해당 인스턴스에 대한 관리자 액세스가 있어야 합니다.

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

왼쪽 사이드바에서 맨 아래에서 관리자 영역을 선택하세요.
설정 > 환경 설정을 선택하세요.
Pages를 확장하세요.
프로젝트당 사용자 정의 도메인의 최대 수에 값을 입력하세요. 무제한 도메인을 원할 경우 0을 사용하세요.
변경 사항 저장을 선택하세요.

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

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

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

자세한 정보는 GitLab 애플리케이션 제한을 참조하세요.

별도의 서버에서 GitLab Pages 실행

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

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

다음 절차에는 gitlab-secrets.json 파일의 백업 및 편집 단계가 포함되어 있습니다. 이 파일에는 데이터베이스 암호화를 제어하는 비밀이 포함되어 있습니다. 신중하게 진행하세요.

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

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

GitLab 서버에서 페이지를 활성화하려면 /etc/gitlab/gitlab.rb에 다음을 추가하세요:
```
pages_external_url "http://<pages_server_URL>"
```
선택적으로 액세스 제어를 활성화하려면 /etc/gitlab/gitlab.rb에 다음을 추가하세요:
```
gitlab_pages['access_control'] = true
```
객체 리포지터리를 설정하고 GitLab Pages 데이터를 마이그레이션하는 방법은 다음 중 하나를 선택하여 수행하십시오:
- 객체 리포지터리를 구성하고 GitLab Pages 데이터를 마이그레이션, 또는
- 네트워크 리포지터리를 구성.
변경 내용이 적용되려면 GitLab 서버를 재구성하세요. gitlab-secrets.json 파일이 새 구성으로 업데이트됩니다.
새 서버를 설정하세요. 이것이 페이지 서버가 됩니다.

페이지 서버에서 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

GitLab 서버에서 사용자 지정 UID/GID 설정이 있으면 해당 설정을 페이지 서버 /etc/gitlab/gitlab.rb에 추가하십시오. 그렇지 않으면 GitLab 서버에서 gitlab-ctl reconfigure를 실행하면 파일 소유권이 변경되어 페이지 요청이 실패할 수 있습니다.

페이지 서버에서 비밀 파일을 백업합니다:

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

GitLab 서버의 /etc/gitlab/gitlab-secrets.json 파일을 페이지 서버로 복사하세요.

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

변경 내용이 적용되려면 페이지 서버를 재구성하세요.

GitLab 서버에서 /etc/gitlab/gitlab.rb를 다음과 같이 변경하세요:

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

변경 내용이 적용되려면 GitLab 서버를 재구성하세요.

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

도메인 소스 구성

GitLab Pages 데몬이 페이지 요청을 처리할 때, 먼저 어떤 프로젝트를 사용하여 요청된 URL을 제공해야 하는지와 해당 내용이 어떻게 저장되어 있는지를 식별해야 합니다.

GitLab 13.3 이전에는 모든 페이지 내용이 특별한 공유 디렉터리로 추출되었으며, 각 프로젝트에는 특별한 구성 파일이 있었습니다. Pages 데몬은 이러한 구성 파일을 읽고 그 내용을 메모리에 저장하였습니다.

이 접근 방식에는 몇 가지 단점이 있었고, 새 도메인이 요청될 때마다 내부 GitLab API를 사용하여 GitLab Pages로 대체되었습니다. 또한, 도메인 정보는 Pages 데몬에 의해 캐시되어 후속 요청의 속도를 높였습니다.

GitLab 14.0부터 GitLab Pages는 기본적으로 API를 사용하며, API에 연결할 수 없는 경우 시작하지 못합니다. 일반적인 문제에 대해서는 문제 해결을 참조하십시오.

자세한 내용은 이 블로그 포스트를 참조하십시오.

GitLab API 캐시 구성

GitLab 13.10에 도입됨.

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

만료, 간격 및 시간 초과 플래그는 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 API에서 도메인의 구성을 요청하는 빈도가 줄어듭니다. 이 설정은 GitLab Pages가 너무 많은 요청을 생성하고 콘텐츠가 자주 변경되지 않는 경우 유용할 수 있습니다.
gitlab_cache_cleanup을 줄이면 캐시에서 만료된 항목을 더 자주 제거하여 페이지 노드의 메모리 사용량을 줄일 수 있습니다.
gitlab_retrieval_timeout을 줄이면 GitLab Rails에 대한 요청을 더 빨리 중지할 수 있습니다. 시간을 늘리면 API에서 응답을 받는데 더 많은 시간이 걸리므로, 느린 네트워크 환경에서 유용합니다.
gitlab_retrieval_interval을 줄이면 API로의 요청을 더 자주 수행하며, 예를 들어 연결 시간이 초과된 경우에만 유용합니다.
gitlab_retrieval_retries을 줄이면 자동적으로 도메인의 구성을 해결하기 전에 시도하는 횟수를 줄여 오류를 보고하기 전에 도메인에 대한 시도를 줄일 수 있습니다.

객체 리포지터리 설정

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

자체 컴파일된 설치의 pages: 아래에 있는 object_store:에 중첩됩니다.
Linux 패키지 설치의 경우 pages_object_store_로 접두어가 붙습니다.

설정	설명	기본값
`enabled`	객체 리포지터리가 활성화되었는지 여부	`false`
`remote_directory`	페이지 사이트 콘텐츠가 저장된 버킷의 이름
`connection`	다양한 연결 옵션

NFS 서버를 사용 중지하고 연결을 해제하려면, GitLab 13.11로 업그레이드한 후에 명시적으로 로컬 리포지터리를 비활성화해야 합니다.

S3 호환 연결 설정

GitLab 13.2 이상에서는 객체 리포지터리 설정을 통합한 형식을 사용해야 합니다. 이 섹션에서는 이전 구성 형식을 설명합니다.

다양한 공급자에 대한 사용 가능한 연결 설정에 대해서는 다른 공급자에 대한 사용 가능한 연결 설정을 참조하십시오.

Linux 패키지 (Omnibus)

/etc/gitlab/gitlab.rb에 다음 줄을 추가하고 원하는 값으로 대체합니다:

gitlab_rails['pages_object_store_enabled'] = true
gitlab_rails['pages_object_store_remote_directory'] = "pages"
gitlab_rails['pages_object_store_connection'] = {
  'provider' => 'AWS',
  'region' => 'eu-central-1',
  'aws_access_key_id' => 'AWS_ACCESS_KEY_ID',
  'aws_secret_access_key' => 'AWS_SECRET_ACCESS_KEY'
}

AWS IAM 프로파일을 사용하는 경우, AWS 액세스 키 및 시크릿 액세스 키/값을 생략해야 합니다.

gitlab_rails['pages_object_store_connection'] = {
  'provider' => 'AWS',
  'region' => 'eu-central-1',
  'use_iam_profile' => true
}

파일을 저장하고 변경 사항이 적용되도록 GitLab을 다시 구성하십시오.
객체 리포지터리로 기존 Pages 배포 마이그레이션을 수행하십시오.

자체 컴파일 (소스)

/home/git/gitlab/config/gitlab.yml을 편집하고 다음의 행을 추가하거나 수정하십시오:

pages:
  object_store:
    enabled: true
    remote_directory: "pages" # 버킷 이름
    connection:
      provider: AWS # 현재 AWS만 지원됩니다
      aws_access_key_id: AWS_ACCESS_KEY_ID
      aws_secret_access_key: AWS_SECRET_ACCESS_KEY
      region: eu-central-1

파일을 저장하고 변경 사항이 적용되도록 GitLab을 다시 시작하십시오.
객체 리포지터리로 기존 Pages 배포 마이그레이션을 수행하십시오.

페이지 배포를 객체 리포지터리로 이관

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

로컬 리포지터리
객체 리포지터리

기존 페이지 배포를 로컬 리포지터리에서 객체 리포지터리로 이관하세요.

sudo gitlab-rake gitlab:pages:deployments:migrate_to_object_storage

모든 페이지 배포가 성공적으로 이관되었는지 추적하고 확인하려면 PostgreSQL 콘솔을 사용하세요.

GitLab 14.1 및 이전 버전의 Linux 패키지 설치에서는 sudo gitlab-rails dbconsole 실행
14.2 이후 버전의 Linux 패키지 설치에서는 sudo gitlab-rails dbconsole --database main 실행
컴파일된 설치에서는 sudo -u git -H psql -d gitlabhq_production 실행

아래 store=2 (여기서 store=2로 표시됨)의 objectstg가 모든 페이지 배포의 개수를 갖고 있는지 확인하세요.

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

로컬 리포지터리 비활성화

GitLab 13.11에서 도입됨.

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

/etc/gitlab/gitlab.rb 파일을 수정하십시오:

gitlab_rails['pages_local_store_enabled'] = false

변경사항이 적용되려면 GitLab 재구성을 수행하세요.

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

객체 리포지터리는 대부분의 환경에서 기본 구성입니다. 그러나 요구 사항에 따라 네트워크 리포지터리가 필요하고 페이지를 별도의 서버에서 실행하려는 경우 다음을 수행해야 합니다.

사용할 공유 리포지터리 볼륨이 기본 서버와 지정한 페이지 서버 양쪽에 이미 마운트되어 있고 사용 가능한지 확인합니다.

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

gitlab_pages['enable_disk'] = true
gitlab_rails['pages_path'] = "/var/opt/gitlab/gitlab-rails/shared/pages" # 사용하는 네트워크 리포지터리의 경로

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

별도의 서버에서 페이지를 성공적으로 구성한 후에는 해당 서버에만 공유 리포지터리 볼륨에 액세스해야 합니다. 단일 노드 환경으로 다시 이전해야 하는 경우를 대비하여 기본 서버에 공유 리포지터리 볼륨을 여전히 마운트해 두는 것이 좋습니다.

ZIP 리포지터리

GitLab 14.0에서 GitLab Pages의 기본 리포지터리 형식이 디스크에 직접 저장된 파일에서 프로젝트당 단일 ZIP 아카이브로 변경되었습니다.

이 ZIP 아카이브는 로컬 디스크 리포지터리나 객체 리포지터리에 저장될 수 있습니다.

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

백업

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

보안

XSS(크로스 사이트 스크립팅) 공격을 방지하기 위해 GitLab Pages를 GitLab과는 다른 호스트명에서 실행하는 것을 강력히 고려해야 합니다.

요율 제한

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

GitLab Pages는 다음 유형의 요율 제한을 지원합니다.

source_ip당으로. 단일 클라이언트 IP 주소에서 허용되는 요청 또는 TLS 연결의 수를 제한합니다.
domain당으로. GitLab Pages에서 호스팅되는 도메인 당 허용되는 요청 또는 TLS 연결의 수를 제한합니다. example.com과 같은 사용자 정의 도메인이나 group.gitlab.io와 같은 그룹 도메인일 수 있습니다.

HTTP 요청 기반의 요율 제한은 다음과 같이 시행됩니다.

rate_limit_source_ip: 클라이언트 IP당 초당 요청 수의 최대 임계값을 설정하십시오. 이 기능을 사용하지 않으려면 0으로 설정하십시오.
rate_limit_source_ip_burst: 클라이언트 IP당 초기 폭주하는 요청의 최대 임계값을 설정하십시오. 예를 들어, 여러 리소스를 동시에 로드하는 웹 페이지를로드할 때
rate_limit_domain: 호스팅된 페이지 도메인당 초당 요청 수의 최대 임계값을 설정하십시오. 이 기능을 사용하지 않으려면 0으로 설정하십시오.
rate_limit_domain_burst: 호스팅된 페이지 도메인당 초기 폭주하는 요청의 최대 임계값을 설정하십시오.

TLS 연결 기반의 요율 제한은 다음과 같이 시행됩니다.

rate_limit_tls_source_ip: 클라이언트 IP당 초당 TLS 연결 수의 최대 임계값을 설정하십시오. 이 기능을 사용하지 않으려면 0으로 설정하십시오.
rate_limit_tls_source_ip_burst: 클라이언트 IP당 초기 폭주하는 TLS 연결의 최대 임계값을 설정하십시오. 예를 들어, 여러 웹 브라우저에서 동시에 웹 페이지를로드할 때
rate_limit_tls_domain: 호스팅된 페이지 도메인당 초당 TLS 연결 수의 최대 임계값을 설정하십시오. 이 기능을 사용하지 않으려면 0으로 설정하십시오.
rate_limit_tls_domain_burst: 호스팅된 페이지 도메인당 초기 폭주하는 TLS 연결의 최대 임계값을 설정하십시오.

IPv6 주소는 128비트 주소 공간에서 큰 접두어를 받습니다. 일반적으로 접두어는 적어도 크기 /64입니다. 많은 가능한 주소로 인해 클라이언트의 IP 주소가 IPv6인 경우 전체 IPv6 주소 대신 64길이의 IPv6 접두어에 한계가 적용됩니다.

소스-IP에 의한 HTTP 요청 속도 제한 활성화

GitLab 14.5에서 도입됨.

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

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

GitLab 재구성.

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

GitLab 14.7에서 도입됨.

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

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

GitLab 재구성.

소스-IP에 의한 TLS 연결 속도 제한 활성화

GitLab 14.9에서 도입됨.

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

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

GitLab 재구성.

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

GitLab 14.9에서 도입됨.

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

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

GitLab 재구성.

GitLab Pages 관리

GitLab Pages 데몬

사전 조건

도메인을 공개 접두어 디렉터리에 추가

DNS 구성

URL 경로에 와일드카드 DNS가 없는 경우의 네임스페이스

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

설정

와일드카드 도메인

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

TLS 지원을 하는 와일드카드 도메인

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

TLS-종료 로드 밸런서와 와일드카드 도메인

전역 설정

고급 구성

사용자 정의 도메인

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

Let’s Encrypt 통합

접근 제어

줄인 인증 범위로 Pages 사용

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

프록시 뒤에서 실행

사용자 정의 Certificate Authority (CA) 사용

ZIP 서빙 및 캐시 구성

ZIP 캐시 새로고침 예시

HTTP Strict Transport Security (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 연결 속도 제한 활성화

관련 주제

도움말

기능 사용 가능성과 제품 평가판

도움받기