• 시작하기
• 작동 방식
• Pages 사이트 접속
• Pages 예시
• Self-Managed형 인스턴스의 GitLab Pages 관리
  • Helm Chart(Kubernetes) 인스턴스에서 GitLab Pages 구성
• GitLab Pages 보안
  • .를 포함하는 네임스페이스
  • 공유 쿠키
• 고유 도메인
• 여러 배포 생성
  • 구성 예
  • 여러 배포 활성화
  • 제한 사항
  • 경로 충돌
  • 배포 삭제
    • 자동 정리

GitLab Pages

GitLab Pages를 사용하면 GitLab의 리포지터리에서 정적 웹사이트를 직접 게시할 수 있습니다.

• 개인 또는 비즈니스 웹사이트에 사용 가능
• 정적 사이트 생성기(SSG) 또는 일반 HTML 사용 가능
• 프로젝트, 그룹 또는 사용자 계정용 웹사이트 생성 가능
• 당신의 사이트를 무료로 자체 GitLab 인스턴스나 GitLab.com에 호스팅 가능
• 사용자 정의 도메인 및 TLS 인증서 연결 가능
• 콘텐츠에 라이선스 부여 가능

Pages를 사용하여 웹사이트를 게시하려면 Gatsby, Jekyll, Hugo, Middleman, Harp, Hexo, 또는 Brunch와 같은 정적 사이트 생성기 또는 일반 HTML로 작성된 웹사이트를 게시할 수 있습니다.

Pages는 .php 및 .asp와 같은 동적 서버 측 처리를 지원하지 않습니다. 자세한 정보는 정적 대 동적 웹사이트를 참조하세요.

시작하기

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

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

더 많은 정보는 아래에서 확인하세요:

작동 방식

GitLab Pages를 사용하려면 GitLab에서 웹사이트 파일을 업로드할 프로젝트를 생성해야 합니다. 이러한 프로젝트는 공개, 내부 또는 비공개일 수 있습니다.

GitLab은 항상 리포지터리의 public라는 특정 폴더에서 웹사이트를 배포합니다. GitLab에서 새 프로젝트를 만들면 리포지터리가 자동으로 사용 가능해집니다.

사이트를 배포하기 위해 GitLab은 내장 도구인 GitLab CI/CD를 사용하여 사이트를 빌드하고 GitLab Pages 서버에 게시합니다. 이 작업을 수행하기 위해 GitLab CI/CD가 실행하는 스크립트 시퀀스는 .gitlab-ci.yml이라는 파일에서 생성됩니다. 이 파일은 만들고 수정할 수 있습니다. 구성 파일 내 특정 job인 pages는 GitLab이 GitLab Pages 웹사이트를 배포하고 있다는 것을 인지하게 합니다.

GitLab Pages 웹사이트에는 GitLab 기본 도메인인 *.gitlab.io 또는 고유 도메인(example.com)을 사용할 수 있습니다. 이 경우 도메인의 등록기(또는 제어판)에서 Pages로 설정을 해줄 필요가 있습니다.

아래의 다이어그램은 Pages 사용을 시작하는 데 따를 수 있는 워크플로우를 보여줍니다.

Pages 사이트 접속

GitLab Pages 기본 도메인(.gitlab.io)을 사용 중이라면 웹사이트는 자동으로 안전하게 HTTPS로 사용할 수 있습니다. 사용자 고유의 사용자 정의 도메인을 사용 중이라면 선택적으로 SSL/TLS 인증서로 보안 설정할 수 있습니다.

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

Self-Managed형 인스턴스를 사용 중이라면, 웹사이트는 시스템 관리자가 공개 또는 내부로 구성할 수 있도록 Pages 설정에 따라 자체 서버에 게시됩니다.

Pages 예시

다음 GitLab Pages 웹사이트 예시는 고급 기술을 학습하고 사용자 요구에 맞게 적용하는 데 도움이 됩니다:

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

Self-Managed형 인스턴스의 GitLab Pages 관리

Self-Managed형되는 경우, GitLab 관리 단계를 따라 Pages를 구성하세요.

비디오 튜토리얼을 시청하여 GitLab Pages 시작 방법 알아보세요.

Helm Chart(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에서 피처 플래그가 제거되었습니다.

기본적으로 모든 새 프로젝트가 고유 도메인을 사용합니다. 이는 동일 그룹의 프로젝트가 쿠키를 공유하지 않도록하기 위함입니다.

프로젝트 관리자는 다음에 대해이 기능을 비활성화할 수 있습니다:

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 배포 > Pages를 선택합니다.
3. 고유 도메인 사용 확인란을 해제합니다.
4. 변경 사항 저장을 선택합니다.

여러 배포 생성

• GitLab 16.7에서 Experiment로 플래그가 비활성화 된 채로 소개되었습니다.

pages.path_prefix CI/CD 옵션을 사용하여 GitLab Pages URL에 접두어를 구성하세요. 접두어를 통해 여러 GitLab Pages 배포를 구분할 수 있습니다:

• 주 페이지 배포 : 빈 path_prefix로 생성된 Pages 배포.
• 추가 페이지 배포 : 비어 있지 않은 path_prefix로 생성된 Pages 배포

구성 예

예를 들어 https://gitlab.example.com/namespace/project와 같은 프로젝트를 고려해 보겠습니다. 기본적으로 해당 메인 Pages 배포는 다음을 통해 액세스 할 수 있습니다:

• 고유 도메인 사용시: https://project-namespace-uniqueid.gitlab.io/.
• 고유 도메인을 사용하지 않는 경우: https://namespace.gitlab.io/project.

pages.path_prefix가 프로젝트 브랜치 이름으로 구성되고 staging이라는 브랜치가 있는 경우, 이 추가 Pages 배포는 다음을 통해 액세스 할 수 있습니다:

• 고유 도메인 사용시: https://project-namespace-uniqueid.gitlab.io/staging.
• 고유 도메인을 사용하지 않는 경우: https://namespace.gitlab.io/project/staging.

여러 배포 활성화

여러 GitLab Pages 배포를 활성화하려면:

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 배포 > Pages를 선택합니다.
3. 여러 배포 사용을 선택합니다.

제한 사항

추가 배포 수는 루트 수준 네임스페이스에 의해 제한됩니다. 구체적인 제한 사항은 다음을 참조하십시오:

• GitLab.com의 경우 기타 제한 사항을 참조하십시오.
• Self-Managed GitLab 인스턴스의 경우 여러 배포 사용시 추가 Pages 배포 수를 참조하십시오.

경로 충돌

pages.path_prefix는 CI/CD 변수에서 동적 값을 취할 수 있으며이는 사이트의 기존 경로와 충돌을 일으킬 수있는 페이지 배포를 만들 수 있습니다. 예를 들어 다음과 같은 기존 GitLab Pages 사이트가 있는 경우:

/index.html
/documents/index.html

pages.path_prefix가 documents이면 해당 버전은 기존 경로를 무시합니다. 즉, https://namespace.gitlab.io/project/documents/index.html은 사이트의 main 배포의 documents/index.html이 아닌 사이트의 documents 배포의/index.html을 가리킵니다.

CI/CD 변수를 다른 문자열과 혼합하면 경로 충돌 가능성이 줄어듭니다. 예를 들어:

pages:
  stage: deploy
  script:
    - echo "${CI_PAGES_URL}/${PAGES_PREFIX}"를 통해 접근 가능한 페이지
  variables:
    PAGES_PREFIX: "" # 기본적으로 접두어 없음 (master)
  pages:
    path_prefix: "$PAGES_PREFIX"
  artifacts:
    paths:
    - public
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH # 기본 브랜치에서 실행 (기본 PAGES_PREFIX로)
    - if: $CI_COMMIT_BRANCH == "staging" # 마스터에서 실행 (기본 PAGES_PREFIX로)
      variables:
        PAGES_PREFIX: '_stg' # 스테이징 브랜치에 _stg 접두사 추가
    - if: $CI_PIPELINE_SOURCE == "merge_request_event" # Merge Request의 경우 접두사 조건부로 변경
      when: manual # 매뉴얼으로 Merge Request에서 페이지 실행
      variables:
        PAGES_PREFIX: 'mr$CI_MERGE_REQUEST_IID' # mr<iid>와 같이 프리픽스 지정, `mr123`처럼

동적 접두사를 사용하여 변수를 다른 문자열과 혼합하는 몇 가지 예는 다음과 같습니다:

• pages.path_prefix: '__$CI_COMMIT_REF_SLUG': __로 시작하는 브랜치 또는 태그 이름, __branch-name과 같이
• pages.path_prefix: '-${CI_MERGE_REQUEST_IID}-': Merge Request 번호로 시작하고 끝나는 접두사 및 접미사, -123-과 같이

배포 삭제

자동 정리

path_prefix를 사용하여 생성된 추가 페이지 배포는 Merge Request이 닫히거나 Merge될 때 자동으로 삭제됩니다.