GitLab Pages는 GitLab의 저장소에서 직접 정적 웹사이트를 게시합니다.

이 웹사이트는:

• GitLab CI/CD 파이프라인으로 자동 배포됩니다.
• Hugo, Jekyll, Gatsby와 같은 모든 정적 사이트 생성기 또는 일반 HTML, CSS, JavaScript, Wasm을 지원합니다.
• GitLab이 제공하는 인프라에서 추가 비용 없이 실행됩니다.
• 사용자 정의 도메인 및 SSL/TLS 인증서와 연결됩니다.
• 내장 인증을 통해 접근을 제어합니다.
• 개인, 비즈니스 또는 프로젝트 문서 사이트에 대해 안정적으로 확장됩니다.

Pages로 웹사이트를 게시하려면 Gatsby, Jekyll, Hugo, Middleman, Harp, Hexo 또는 Brunch와 같은 정적 사이트 생성기를 사용합니다. Pages는 일반 HTML, CSS, JavaScript, Wasm으로 직접 작성된 웹사이트도 지원합니다. 동적 서버 측 처리(예: .php 및 .asp)는 지원되지 않습니다. 자세한 내용은 정적 vs 동적 웹사이트를 참조하세요.

시작하기#

GitLab Pages 웹사이트를 만들려면:

GitLab Pages 웹사이트를 업데이트하려면:

자세한 내용은 다음을 참조하세요:

GitLab Pages 사용#

GitLab Pages를 사용하려면 웹사이트 파일을 업로드할 GitLab 프로젝트를 만들어야 합니다. 이 프로젝트는 공개, 내부 또는 비공개일 수 있습니다.

기본적으로 GitLab은 저장소의 public이라는 특정 폴더에서 웹사이트를 배포합니다. 또한 Pages로 배포할 사용자 정의 폴더를 설정할 수 있습니다. GitLab에서 새 프로젝트를 만들면 저장소가 자동으로 생성됩니다.

사이트를 배포하기 위해 GitLab은 내장 도구인 GitLab CI/CD를 사용하여 사이트를 빌드하고 GitLab Pages 서버에 게시합니다. GitLab CI/CD가 이 작업을 수행하기 위해 실행하는 스크립트 시퀀스는 .gitlab-ci.yml이라는 파일에서 생성되며, 생성하고 수정할 수 있습니다. 구성 파일에서 pages: true 속성을 가진 사용자 정의 job은 GitLab Pages 웹사이트를 배포 중임을 GitLab에 알립니다.

GitLab Pages 웹사이트에 대한 GitLab 기본 도메인인 *.gitlab.io를 사용하거나, 자체 도메인(example.com)을 사용할 수 있습니다. 후자의 경우 Pages로 설정하려면 도메인 등록자(또는 제어판)의 관리자여야 합니다.

Pages 사이트 접근#

GitLab Pages 기본 도메인(.gitlab.io)을 사용하는 경우, 웹사이트는 HTTPS를 통해 자동으로 보안이 적용되고 사용 가능합니다. 자체 사용자 정의 도메인을 사용하는 경우 선택적으로 SSL/TLS 인증서로 보안을 적용할 수 있습니다.

GitLab.com을 사용하는 경우 웹사이트는 인터넷에 공개적으로 접근 가능합니다. 웹사이트에 대한 접근을 제한하려면 GitLab Pages 접근 제어를 활성화하세요.

GitLab Self-Managed 인스턴스를 사용하는 경우, 웹사이트는 시스템 관리자가 선택한 Pages 설정에 따라 자체 서버에 게시되며, 공개 또는 내부로 설정할 수 있습니다.

Pages 예시#

이 GitLab Pages 웹사이트 예시들은 자신의 필요에 맞게 사용하고 적용할 수 있는 고급 기술을 가르쳐줍니다:

• iOS에서 GitLab Pages 블로그에 게시하기.
• GitLab CI: 순차적으로, 병렬로 작업 실행 또는 사용자 정의 파이프라인 구축.
• GitLab CI: 배포 및 환경.
• Nanoc, GitLab CI, GitLab Pages로 새 GitLab 문서 사이트 구축.
• GitLab Pages로 코드 커버리지 보고서 게시.

GitLab Self-Managed 인스턴스에 대한 GitLab Pages 관리#

GitLab Self-Managed 인스턴스를 실행하는 경우, Pages를 구성하려면 관리 단계를 따르세요.

GitLab Pages 관리를 시작하는 방법에 대한 동영상 튜토리얼을 시청하세요.

Helm 차트(Kubernetes) 인스턴스에서 GitLab Pages 구성#

Helm 차트(Kubernetes)로 배포된 인스턴스에서 GitLab Pages를 구성하려면 다음 중 하나를 사용합니다:

• gitlab-pages 서브차트.
• 외부 GitLab Pages 인스턴스.

GitLab Pages 보안#

.을 포함하는 네임스페이스#

사용자 이름이 example인 경우, GitLab Pages 웹사이트는 example.gitlab.io에 위치합니다. GitLab은 사용자 이름에 .을 포함하는 것을 허용하므로, bar.example이라는 사용자가 bar.example.gitlab.io라는 GitLab Pages 웹사이트를 만들 수 있으며, 이는 실질적으로 example.gitlab.io 웹사이트의 하위 도메인입니다. 웹사이트에 대한 쿠키를 설정하기 위해 JavaScript를 사용하는 경우 주의하세요. JavaScript로 수동으로 쿠키를 안전하게 설정하는 방법은 domain을 전혀 지정하지 않는 것입니다:

// 안전: 이 쿠키는 example.gitlab.io에서만 볼 수 있습니다
document.cookie = "key=value";

// 안전하지 않음: 이 쿠키는 선행 점의 유무에 관계없이 example.gitlab.io와 그 하위 도메인에서 볼 수 있습니다.
document.cookie = "key=value;domain=.example.gitlab.io";
document.cookie = "key=value;domain=example.gitlab.io";

이 문제는 사용자 정의 도메인을 가진 사용자나 JavaScript로 쿠키를 수동으로 설정하지 않는 사용자에게는 영향을 미치지 않습니다.

공유 쿠키#

기본적으로 그룹의 모든 프로젝트는 group.gitlab.io와 같은 동일한 도메인을 공유합니다. 이는 그룹의 모든 프로젝트에 대해 쿠키도 공유된다는 것을 의미합니다.

각 프로젝트가 다른 쿠키를 사용하도록 하려면 프로젝트에 대한 Pages 고유 도메인 기능을 활성화하세요.

고유 도메인#

히스토리

• GitLab 15.9에서 pages_unique_domain이라는 플래그와 함께 도입됨. 기본적으로 비활성화됨.
• GitLab 15.11에서 기본적으로 활성화됨.
• GitLab 16.3에서 기능 플래그 제거됨.
• GitLab 17.4에서 고유 도메인 URL이 더 짧아지도록 변경됨.

기본적으로 모든 새 프로젝트는 동일한 그룹의 프로젝트가 쿠키를 공유하는 것을 방지하기 위해 pages 고유 도메인을 사용합니다.

프로젝트 Maintainer는 다음에서 이 기능을 비활성화할 수 있습니다:

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Deploy > Pages를 선택합니다.
3. Use unique domain 체크박스를 해제합니다.
4. Save changes를 선택합니다.

예시 URL은 GitLab Pages 기본 도메인 이름을 참조하세요.

기본 도메인#

히스토리

• GitLab 17.8에서 도입됨.

사용자 정의 도메인으로 GitLab Pages를 사용할 때 GitLab Pages에 대한 모든 요청을 기본 도메인으로 리디렉션할 수 있습니다. 기본 도메인이 선택되면 사용자는 브라우저를 선택된 기본 도메인으로 리디렉션하는 308 Permanent Redirect 상태를 받습니다. 브라우저는 이 리디렉션을 캐시할 수 있습니다.

전제 조건:

• 프로젝트에 대한 Maintainer 또는 Owner 역할이 있어야 합니다.
• 사용자 정의 도메인이 설정되어 있어야 합니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Deploy > Pages를 선택합니다.
3. Primary domain 드롭다운 목록에서 리디렉션할 도메인을 선택합니다.
4. Save changes를 선택합니다.

만료 배포#

히스토리

• GitLab 17.4에서 도입됨.
• GitLab 17.11에서 변수에 대한 지원이 도입됨.

pages.expire_in에 기간을 지정하여 Pages 배포가 일정 시간이 지난 후 자동으로 삭제되도록 구성할 수 있습니다:

create-pages:
  stage: deploy
  script:
    - ...
  pages:  # 이것이 Pages 작업임을 지정하고 기본 public 디렉토리를 게시합니다
    expire_in: 1 week

만료된 배포는 10분마다 실행되는 cron 작업에 의해 중지됩니다. 중지된 배포는 10분마다 실행되는 또 다른 cron 작업에 의해 이후에 삭제됩니다. 복구하려면 중지된 배포 복구에 설명된 단계를 따르세요.

중지되거나 삭제된 배포는 더 이상 웹에서 사용할 수 없습니다. 동일한 URL 구성으로 다른 배포가 생성될 때까지 해당 URL에서 404 Not found 오류 페이지가 표시됩니다.

이전 YAML 예시는 사용자 정의 작업 이름을 사용합니다.

중지된 배포 복구#

전제 조건:

• 프로젝트에 대한 Maintainer 또는 Owner 역할이 있어야 합니다.

아직 삭제되지 않은 중지된 배포를 복구하려면:

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Deploy > Pages를 선택합니다.
3. Deployments 근처에서 Include stopped deployments 토글을 켭니다. 배포가 아직 삭제되지 않은 경우 목록에 포함됩니다.
4. 복구할 배포를 펼치고 Restore를 선택합니다.

배포 삭제#

배포를 삭제하려면:

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Deploy > Pages를 선택합니다.
3. Deployments 아래에서 삭제할 배포의 아무 곳이나 선택합니다. 배포 세부 정보가 펼쳐집니다.
4. Delete를 선택합니다.

Delete를 선택하면 배포가 즉시 중지됩니다. 중지된 배포는 10분마다 실행되는 cron 작업에 의해 삭제됩니다.

아직 삭제되지 않은 중지된 배포를 복원하려면 중지된 배포 복구를 참조하세요.

사용자 정의 작업 이름#

히스토리

• GitLab 17.5에서 customizable_pages_job_name 플래그와 함께 도입됨. 기본적으로 비활성화됨.
• GitLab 17.6에서 일반 공개됨. 기능 플래그 customizable_pages_job_name 제거됨.

모든 작업에서 Pages 배포를 트리거하려면 작업 정의에 pages 속성을 포함합니다. true로 설정된 Boolean이거나 해시일 수 있습니다.

예를 들어, true 사용:

deploy-my-pages-site:
  stage: deploy
  script:
    - npm run build
  pages: true  # 이것이 Pages 작업임을 지정하고 기본 public 디렉토리를 게시합니다

예를 들어, 해시 사용:

deploy-pages-review-app:
  stage: deploy
  script:
    - npm run build
  pages:  # 이것이 Pages 작업임을 지정하고 기본 public 디렉토리를 게시합니다
    path_prefix: '_staging'

pages라는 이름의 작업의 pages 속성이 false로 설정된 경우 배포가 트리거되지 않습니다:

pages:
  pages: false

병렬 배포#

프로젝트에 대해 동시에 여러 배포를 생성하려면, 예를 들어 리뷰 앱을 생성하려면 병렬 배포에 대한 문서를 참조하세요.