• 시작하기
• 작동 방식
• 페이지 사이트 액세스
• 페이지 예시
• 자체 관리형 인스턴스용 GitLab Pages 관리
  • Helm 차트(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, CSS, JavaScript로 직접 작성된 웹사이트도 게시할 수 있습니다.

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를 시작하는 데 따를 수 있는 워크플로를 보여줍니다.

페이지 사이트 액세스

GitLab Pages 기본 도메인(.gitlab.io)을 사용하는 경우 웹사이트는 자동으로 안전하며 HTTPS로 사용할 수 있습니다. 사용자 지정 도메인을 사용하는 경우 SSL/TLS 인증서로 안전하게 설정할 수 있습니다.

GitLab.com을 사용하는 경우 웹사이트는 인터넷에 공개적으로 이용할 수 있습니다. 웹사이트 접근을 제한하려면 GitLab Pages 액세스 제어를 활성화하세요.

자체 관리형 인스턴스를 사용하는 경우 시스템 관리자가 선택한 페이지 설정에 따라 웹사이트가 해당 서버에 게시됩니다. 시스템 관리자는 이를 공개 또는 내부적으로 설정할 수 있습니다.

페이지 예시

이 GitLab Pages 웹사이트 예시는 고급 기술을 익히고 자신의 필요에 맞게 활용할 수 있는 방법을 가르쳐줍니다:

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

자체 관리형 인스턴스용 GitLab Pages 관리

GitLab의 자체 관리형 인스턴스를 실행 중인 경우, 페이지를 구성하려면 관리 단계에 따르세요.

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라는 사용자가 example.gitlab.io 웹사이트의 하위 도메인인 bar.example.gitlab.io 웹사이트를 생성할 수 있습니다. 웹사이트에 수동으로 쿠키를 설정하는 경우 주의하십시오. JavaScript를 사용하여 안전하게 쿠키를 수동으로 설정하는 방법은 도메인을 전혀 지정하지 않는 것입니다:

// 안전함: 이 쿠키는 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 16.7에 도입되었으며 실험으로 flag인 pages_multiple_versions_setting으로 기본값이 비활성화되어 있습니다.

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

여러 GitLab Pages 배포( path_prefix로 생성한 페이지)는 저장소 사용량에 포함됩니다.

여러 배포 활성화

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

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

경로 충돌

pages.path_prefix는 CI/CD 변수에서 동적 값들을 가져올 수 있습니다. 이는 사이트의 기존 경로와 충돌을 일으킬 수 있는 페이지 배포를 만들어낼 수 있습니다. 예를 들어, 다음과 같은 경로를 갖는 기존의 GitLab Pages 사이트가 있다고 가정해 봅시다:

/index.html
/documents/index.html

만약 pages.path_prefix가 documents라면, 해당 버전은 기존 경로를 덮어쓸 것입니다. 다시 말해, https://namespace.gitlab.io/project/documents/index.html은 사이트의 documents 배포의/index.html을 가리키게 되며, main 배포의 documents/index.html을 가리키지 않게 됩니다.

다른 문자열과 CI/CD 변수를 섞는 것은 경로 충돌 가능성을 줄일 수 있습니다. 예를 들면:

pages：
  stage: deploy
  script:
    - "Pages accessible through ${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'  # staging 브랜치에 _stg를 접두사로 붙입니다
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"  # 병합 요청시 접두사를 조건부로 변경합니다
      when: manual  # 병합 요청시 수동으로 페이지를 실행합니다
      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}-': 병합 요청 번호를 가운데에 삽입한 -로 둘러싼 것, 예: -123-.

여러 배포 사용하여 페이지 환경 생성

여러 GitLab Pages 배포를 사용하여 새로운 환경을 만들 수 있습니다. 예를 들어:

pages：
  stage: deploy
  script:
    - "Pages accessible through ${CI_PAGES_URL}/${PAGES_PREFIX}로 접근 가능합니다."
  variables:
    PAGES_PREFIX: ""  # 기본적으로 접두사가 없습니다 (master)
  pages:
    path_prefix: "$PAGES_PREFIX"
  environment:
    name: "Pages ${PAGES_PREFIX}"
    url: "${CI_PAGES_URL}/${PAGES_PREFIX}"
  artifacts:
    paths:
    - public
  rules:
    - if: $CI_COMMIT_BRANCH == "staging" # 마스터에서 실행하는지 확인 (기본 PAGES_PREFIX로)
      variables:
        PAGES_PREFIX: '_stg' # staging 브랜치에 _stg를 접두사로 붙입니다
    - if: $CI_PIPELINE_SOURCE == "merge_request_event" # 병합 요청시 접두사를 조건부로 변경합니다
      when: manual # 병합 요청시 수동으로 페이지를 실행합니다
      variables:
        PAGES_PREFIX: 'mr$CI_MERGE_REQUEST_IID' # mr<iid>와 같이 접두사를 붙입니다, 예: `mr123`

이 설정을 사용하면 사용자들은 UI를 통해 각 GitLab Pages 배포에 액세스할 수 있습니다. pages에 환경을 사용하면 모든 페이지 환경이 프로젝트 환경 목록에 나열됩니다.