• 시작하기
• 작동 방식
• Pages 사이트 액세스
• 페이지 예시
• Self-managed 인스턴스를 위한 GitLab Pages 관리
  • Helm Chart (Kubernetes) 인스턴스에 대한 GitLab Pages 구성
• GitLab Pages의 보안
  • .를 포함하는 네임스페이스
  • 공유된 쿠키
• 다중 배포 생성
  • 다중 배포 활성화
  • 경로 충돌
  • 다중 배포 사용하여 페이지 환경 생성

GitLab Pages

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

• 모든 개인 또는 비즈니스 웹사이트에 사용할 수 있습니다.
• 정적 사이트 생성기(Static Site Generator, 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.io를 사용하거나 자체 도메인(example.com)를 사용할 수 있습니다. 이 경우 도메인의 등록기(또는 제어판)에서 페이지를 설정하려면 도메인의 관리자이어야 합니다.

다음 다이어그램은 Pages를 시작하는 데 사용할 수 있는 워크플로우를 보여줍니다.

Pages 사이트 액세스

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

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

Self-managed 인스턴스를 사용하는 경우 웹사이트는 시스템 관리자에 의해 선택한 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라는 사용자는 example.gitlab.io 웹사이트의 하위 도메인인 bar.example.gitlab.io를 만들 수 있습니다. 당신의 웹사이트에 대해 JavaScript를 사용하여 쿠키를 설정하는 경우 주의하세요. JavaScript로 매뉴얼으로 쿠키를 설정하는 안전한 방법은 domain을 전혀 지정하지 않는 것입니다:

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

// 불안전: ina leading dot의 유무와 상관없이, 이 쿠키는 example.gitlab.io 및 하위 도메인에서 볼 수 있습니다.
document.cookie = "key=value;domain=.example.gitlab.io";
document.cookie = "key=value;domain=example.gitlab.io";

이 문제는 사용자 정의 도메인을 사용하는 사용자나 JavaScript로 매뉴얼으로 어떠한 쿠키도 설정하지 않는 사용자에게는 영향을 주지 않습니다.

공유된 쿠키

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

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

다중 배포 생성

• GitLab 16.7에 도입된 실험으로 pages_multiple_versions_setting이라는 플래그와 함께 기본값으로 꺼져 있습니다.

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

여러 GitLab Pages 배포 (path_prefix로 생성된 pages)는 저장 용량 사용량에 반영됩니다.

다중 배포 활성화

다중 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은 사이트의 main 배포의 documents/index.html 대신에 documents 배포의 /index.html을 가리키게 됩니다.

다른 문자열과 CI/CD 변수를 섞는 것은 충돌 가능성을 줄입니다. 예를 들어:

pages:
  stage: deploy
  script:
    - echo "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'  # 스테이징 브랜치에 _stg를 붙임
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"  # MR을 위해 접두사를 조건부로 변경
      when: manual  # MR에서 필요에 따라 매뉴얼으로 페이지 실행
      variables:
        PAGES_PREFIX: 'mr$CI_MERGE_REQUEST_IID' # MR을 위해 mr<iid>와 같이 접두사를 붙임

동적 접두사를 위한 변수와 문자열을 섞는 몇 가지 예시:

• pages.path_prefix: '__$CI_COMMIT_REF_SLUG': __로 시작하는 브랜치 또는 태그 이름. __branch-name과 같은 형태
• pages.path_prefix: '-${CI_MERGE_REQUEST_IID}-': Merge Request 번호의 접두사와 접미사로 -으로 둘러싼 형태. -123-과 같은 형태

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

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

pages:
  stage: deploy
  script:
    - echo "${CI_PAGES_URL}/${PAGES_PREFIX}"을 통해 페이지에 접근 가능
  variables:
    PAGES_PREFIX: "" # 기본적으로 접두사 없음 (마스터)
  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' # 스테이징 브랜치에 _stg 접두사 추가
    - if: $CI_PIPELINE_SOURCE == "merge_request_event" # 머지 요청에서 접두사를 조건부로 변경
      when: manual # 머지 요청에서 매뉴얼으로 페이지 실행
      variables:
        PAGES_PREFIX: 'mr$CI_MERGE_REQUEST_IID' # 머지 요청 번호와 함께 접두사 추가, 예: `mr123`

이 구성을 통해 사용자는 UI를 통해 각 GitLab Pages 배포에 액세스할 수 있습니다. 환경을 사용하여 페이지를 배포할 때, 모든 페이지 환경이 프로젝트 환경 디렉터리에 나열됩니다.