GitLab Pages 데몬
전제 조건
- 공개 접미어 목록에 도메인 추가
- DNS 구성
  - URL 경로의 네임스페이스, 와일드카드 DNS 없이
  - 사용자 지정 도메인을 위한 DNS 설정
구성
- 와일드카드 도메인
- 와일드카드 DNS가 없는 Pages 도메인
- TLS 지원을 하는 와일드카드 도메인
- 와일드카드 DNS 없이 TLS 지원을 하는 페이지 도메인
- TLS-terminating Load Balancer와 와일드카드 도메인
- 전역 설정
- 제한사항
고급 구성
- 사용자 정의 도메인
- TLS 지원하는 사용자 정의 도메인
- 사용자 정의 도메인 검증
- Let’s Encrypt 통합
- 접근 제어
  - 사용 범위가 축소된 인증으로 Pages 사용
  - 모든 Pages 사이트에 대한 공개 액세스 비활성화
- 프록시 뒤에서 실행
- 사용자 정의 인증 기관(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 호환 연결 설정
- Pages 배포를 오브젝트 스토리지로 이관
- Pages 배포 롤백하여 로컬 스토리지로 변경
- 로컬 Pages 스토리지 비활성화
멀티 노드 환경에서 Pages 네트워크 스토리지 활성화
ZIP 스토리지
백업
보안
- 요금 한도
관련 주제

GitLab Pages 관리

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

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

이 안내서는 Linux 패키지 설치를 위한 것입니다. 자체 컴파일된 GitLab 설치를 사용하는 경우 자체 컴파일 설치를 위한 GitLab Pages 관리를 참조하세요.

GitLab Pages 데몬

GitLab Pages는 GitLab Pages 데몬을 사용합니다. 이는 Go로 작성된 기본 HTTP 서버로 외부 IP 주소에서 듣고 사용자 정의 도메인과 사용자 정의 인증서를 지원할 수 있습니다. SNI(Server Name Indication)를 통한 동적 인증서를 지원하며 기본적으로 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)에서 서브도메인을 생성할 수도 있게 됩니다. 도메인을 공개 접미어 목록에 추가하면 브라우저가 슈퍼쿠키 등을 수락하지 않도록 합니다.

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

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에 도입. 이 기능은 Experiment입니다.

자체 관리형 GitLab에서는 기본적으로 이 기능을 사용할 수 있습니다. GitLab.com 및 GitLab Dedicated에서는 이 기능을 사용할 수 없습니다. 이 기능은 생산 환경에서 사용할 준비가 되지 않았습니다.

전제 조건:

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

와일드카드 DNS가 필요하지 않도록 URL 경로에서 네임스페이스를 지원하는 지원이 필요한 경우:

다음을 추가하여 이 기능에 대한 GitLab Pages 플래그를 활성화합니다. /etc/gitlab/gitlab.rb에 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 루트 도메인의 모든 하위 도메인이 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와 달리 Pages에 전용된 보조 IP.

참고: GitLab 도메인을 사용하여 사용자 페이지를 제공해서는 안 됩니다. 자세한 정보는 보안 섹션을 참조하세요.

구성

필요에 따라 GitLab Pages를 4가지 다른 방식으로 설정할 수 있습니다.

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

와일드카드 도메인

요구 사항:

와일드카드 DNS 설정

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

다음은 페이지를 사용할 수 있는 최소한의 구성입니다. 이 구성은 설명된 모든 다른 설정의 기초입니다. 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에 도입. 이 기능은 Experiment입니다.

GitLab Pages의 최소 구성입니다. 이 구성은 모든 다른 설정의 기초입니다. 이 구성에서는 NGINX가 모든 요청을 데몬으로 프록시하기 때문에 GitLab Pages 데몬이 외부 환경에서 수신하지 않습니다.

전제 조건:

인스턴스는 Linux 패키지 설치 방법을 사용해야 합니다.
와일드카드 없이 DNS 설정을 구성했어야 합니다. 여기를 참조하세요.

/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는 사용자 지정 프록시 헤더 X-Gitlab-Namespace-In-Path를 사용하여 네임스페이스를 GitLab Pages 데몬으로 전송합니다.

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

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

요구 사항:

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

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

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

와일드카드 TLS 인증서를 *.example.io 및 해당 키를 /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이 될 수 없습니다.

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

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

경고: GitLab Pages는 리디렉션 URI에 변경 사항이 있으면 OAuth 애플리케이션을 업데이트하지 않습니다. 재구성하기 전에 /etc/gitlab/gitlab-secrets.json에서 gitlab_pages 섹션을 제거하고, gitlab-ctl reconfigure를 실행하세요. 자세한 정보는 GitLab Pages가 OAuth를 재생성하지 않음을 참조하세요.

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

세부 정보: 상태: 실험

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

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

사전 요구 사항:

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

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

필요 사항을 충족하는 방식으로 TLS 인증서와 키를 /etc/gitlab/ssl에 추가합니다.

/etc/gitlab/gitlab.rb에서 GitLab 페이지용 외부 URL을 설정하고 기능 플래그를 활성화합니다.

# 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가 OAuth를 재생성하지 않음을 참조하세요.
Pages Access Control을 사용 중이라면 GitLab Pages의 시스템 OAuth 애플리케이션에서 리디렉션 URI를 HTTPS 프로토콜을 사용하도록 업데이트합니다.

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

결과적으로 URL 구조는 https://example.io/<namespace>/<project_slug>가 됩니다.

TLS-terminating Load Balancer와 와일드카드 도메인

요구 사항:

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 패키지 설치에서 Pages에 알려진 모든 구성 설정과 해당 기능을 보여주는 표입니다.

구성	설명
`pages_external_url`	GitLab Pages에 액세스할 수 있는 URL로, 프로토콜(HTTP / HTTPS)을 포함합니다. 만약 `https://`를 사용한다면 추가 구성이 필요합니다. 자세한 내용은 와일드카드 도메인과 TLS 지원 및 TLS 지원을 한 사용자 정의 도메인을 참조하세요.
`gitlab_pages[]`
… (이하 동일) …

이 설정들은 공통적으로 페이지 데몬의 실행 및 환경에서 페이지 콘텐츠를 제공하는 방식을 보다 세밀하게 제어해야 하는 경우를 제외하고는 일반적으로 수동으로 구성할 필요가 없습니다.

제한사항

위 설정은 페이지 설치에 대한 모든 제한 사항을 알고 있으며, 어떤 일을 하는지를 알고 있습니다.

고급 구성

와일드카드 도메인 외에도 사용자 정의 도메인과 함께 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> 및 https://custom-domain.com

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

와일드카드 LTS 인증서를 *.example.io와 키를 /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

만약 인증서를 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의 시스템 OAuth 애플리케이션에서 리디렉트 URI를 HTTPS 프로토콜을 사용하도록 업데이트합니다.

사용자 정의 도메인 검증

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

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

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

왼쪽 사이드바에서 맨 아래에서 관리 영역을 선택합니다.
설정 > 기본 설정을 선택합니다.
Pages를 확장합니다.
Custom domains to prove ownership 확인란을 지웁니다. 이 설정은 기본적으로 활성화됩니다.

Let’s Encrypt 통합

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

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

이를 활성화하려면:

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

접근 제어

GitLab Pages 접근 제어는 프로젝트별로 구성할 수 있으며, 해당 프로젝트의 멤버십에 따라 페이지 사이트에 대한 액세스를 제어할 수 있습니다.

액세스 제어는 GitLab에서 Pages 데몬을 OAuth 애플리케이션으로 등록함으로써 작동합니다. 인증되지 않은 사용자가 개인 페이지 사이트에 액세스하려고 할 때, 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 애플리케이션을 수정해야 합니다. 이 작업을 수행하려면 다음 단계를 따르세요:

Access Control을 활성화합니다.
왼쪽 사이드바에서 가장 아래에 관리 영역을 선택합니다.
Applications을 선택합니다.
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 재구성을 수행하십시오.

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

사용자 정의 CA에서 발급된 인증서를 사용하는 경우, 접근 제어 및 HTML 작업 아티팩트의 온라인 보기가 사용되지 않을 수 있습니다.

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

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

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

ZIP 서빙 및 캐시 구성

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

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

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

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

ZIP 캐시 확장 예시

아카이브가 zip_cache_expiration 이전에 액세스되고 만료되기 전까지 남은 시간이 zip_cache_refresh보다 작거나 같으면 캐시에서 아카이브가 새로고침됩니다(메모리에 저장된 시간이 연장됨). 예를 들어, archive.zip이 0초에 액세스된 경우, zip_cache_expiration의 기본값인 60초 후에 만료됩니다. 아래 예시에서, 아카이브가 15초 후에 다시 열리면 (45초) zip_cache_refresh의 기본값인 30초보다 크기 때문에 새로고침되지 않습니다. 그러나 아카이브가 최초로 열린 후 45초 후에 다시 액세스되면 새로고침됩니다. 이를 통해 아카이브는 총 45초 + zip_cache_expiration(60초)으로 메모리에 유지됩니다.

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

HTTP Strict Transport Security (HSTS) 지원

HTTP Strict Transport Security (HSTS)는 gitlab_pages['headers'] 구성 옵션을 통해 활성화할 수 있습니다. 이를 통해 브라우저에게 방문 중인 웹사이트가 항상 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 데몬에 환경 변수를 전달할 수 있습니다(예: 기능 플래그의 활성화 또는 비활성화).

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

/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 재구성.

저장 경로 변경

기본적으로 GitLab Pages 콘텐츠는 /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

필수 구성 요소:

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

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

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

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

세부 정보: Tier: Premium, Ultimate Offering: Self-managed

필수 구성 요소:

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

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

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

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

세부 정보: Tier: Premium, Ultimate Offering: Self-managed

필수 구성 요소:

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

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

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

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

필수 구성 요소:

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

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

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

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

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

자체 관리 인스턴스에서 제한을 업데이트할 수 있으며, 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 서버에서, Pages를 활성화하려면 /etc/gitlab/gitlab.rb에 다음을 추가하세요:
```
pages_external_url "http://<pages_server_URL>"
```
선택적으로, 액세스 제어를 활성화하려면 /etc/gitlab/gitlab.rb에 다음을 추가하세요:
```
gitlab_pages['access_control'] = true
```
객체 저장소를 설정하려면 다음 중 하나를 수행하세요:
- 객체 저장소 구성 및 GitLab Pages 데이터 마이그레이션, 또는
- 네트워크 저장소 구성.
변경 사항이 적용되려면 GitLab 서버를 재구성하세요. gitlab-secrets.json 파일은 새 구성으로 업데이트됩니다.
새 서버를 설정하세요. 이것이 Pages 서버가 됩니다.

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

## 단계 3에서 액세스 제어를 활성화한 경우
gitlab_pages['access_control'] = true

GitLab 서버에서 사용자 정의 UID/GID 설정이 있는 경우, 해당 설정을 Pages 서버 /etc/gitlab/gitlab.rb에도 추가하고, 그렇지 않으면 GitLab 서버에서 실행중인 gitlab-ctl reconfigure가 파일 소유권을 변경하고 Pages 요청이 실패할 수 있습니다.

Pages 서버에서 비밀 파일을 백업하세요:

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

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

변경 사항이 적용되려면 Pages 서버를 재구성하세요.

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를 여러 서버에 설정할 수 있습니다. 복수의 서버에 GitLab Pages를 설정하려면 각 Pages 서버에 대해 위의 절차를 수행하세요.

도메인 소스 구성

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

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

이 접근 방식은 여러 가지 단점이 있었고, 새 도메인이 요청될 때마다 내부 GitLab API를 사용하여 GitLab Pages로 교체되었습니다. Pages 데몬은 이 도메인 정보도 캐시에 저장하여 이후 요청을 가속화합니다.

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

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

GitLab API 캐시 구성

도입됨 : GitLab 13.10에서.

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

참고: 만료, 간격 및 타임아웃 플래그는 Go 기간 형식을 사용합니다. 기간 문자열은 옵션으로 부호가 있는 10진수 숫자의 순서이며 각각은 단위 접미사가 있는 소수점이 올 수 있습니다. 예: 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 API에 지나치게 많은 요청을 생성하고 내용이 빈번하게 변경되지 않는 경우에 유용할 수 있습니다. - gitlab_cache_cleanup을 줄이면 캐시에서 만료된 항목이 더 자주 제거되어 페이지 노드의 메모리 사용량이 줄어듭니다. - gitlab_retrieval_timeout을 줄이면 GitLab Rails에 대한 요청을 빨리 중지시킬 수 있습니다. 이를 늘리면 API로부터 응답을 받는 데 더 많은 시간이 소요되며, 느린 네트워크 환경에서 유용합니다. - gitlab_retrieval_interval을 줄이면 API로의 요청이 더 자주 이뤄지며, 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을 다시 구성하세요.
기존 페이지 배포를 객체 저장소로 이전하세요.

자체 컴파일 (소스)

/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 배포를 오브젝트 스토리지로 이관

기존 Pages 배포 오브젝트(압축 아카이브)는 다음 중 하나에 저장할 수 있습니다:

로컬 스토리지
오브젝트 스토리지

기존 Pages 배포를 로컬 스토리지에서 오브젝트 스토리지로 이관하세요:

sudo gitlab-rake gitlab:pages:deployments:migrate_to_object_storage

모든 Pages 배포가 성공적으로 이관되었는지 추적하고 확인하려면 PostgreSQL 콘솔을 사용할 수 있습니다:

Linux 패키지 설치로 실행 중인 GitLab 14.1 및 이전 버전의 경우: sudo gitlab-rails dbconsole
Linux 패키지 설치로 실행 중인 14.2 이후 버전의 경우: sudo gitlab-rails dbconsole --database main
본인이 컴파일한 설치의 경우: sudo -u git -H psql -d gitlabhq_production

아래 store=2 (여기서 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 배포를 다시 로컬 스토리지로 이동할 수 있습니다:

sudo gitlab-rake gitlab:pages:deployments:migrate_to_local

로컬 Pages 스토리지 비활성화

GitLab 13.11에서 도입됨.

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

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

gitlab_rails['pages_local_store_enabled'] = false

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

멀티 노드 환경에서 Pages 네트워크 스토리지 활성화

오브젝트 스토리지는 대부분의 환경에서 선호되는 구성입니다. 그러나 요구 사항에 따라 네트워크 스토리지가 필요하고 Pages를 별도의 서버에서 실행하려는 경우 다음을 수행해야 합니다:

사용하려는 공유 스토리지 볼륨이 기본 서버와 목표 Pages 서버 양쪽에 이미 마운트되어 있고 사용 가능한지 확인하세요.

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

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

Pages를 별도의 서버로 전환하세요.

별도의 서버에서 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 연결 중 허용되는 TLS 연결 수의 최대 임계값을 설정합니다. 예: 동시에 다른 웹 브라우저로부터 웹 페이지를로드할 때.
rate_limit_tls_domain: 호스팅된 페이지 도메인 당 초당 TLS 연결 수의 최대 임계값을 설정합니다. 이 기능을 비활성화하려면 0으로 설정하세요.
rate_limit_tls_domain_burst: 호스팅된 페이지 도메인 당 초기 폭발적 TLS 연결 중 허용되는 TLS 연결 수의 최대 임계값을 설정합니다.

IPv6 주소는 128비트 주소 공간에서 큰 접두어를받습니다. 클라이언트의 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 지원을 하는 페이지 도메인

TLS-terminating Load Balancer와 와일드카드 도메인

전역 설정

제한사항

고급 구성

사용자 정의 도메인

TLS 지원하는 사용자 정의 도메인

사용자 정의 도메인 검증

Let’s Encrypt 통합

접근 제어

사용 범위가 축소된 인증으로 Pages 사용

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

프록시 뒤에서 실행

사용자 정의 인증 기관(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 호환 연결 설정

Pages 배포를 오브젝트 스토리지로 이관

Pages 배포 롤백하여 로컬 스토리지로 변경

로컬 Pages 스토리지 비활성화

멀티 노드 환경에서 Pages 네트워크 스토리지 활성화

ZIP 스토리지

백업

보안

요금 한도

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

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

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

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

관련 주제

도움말

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

도움받기