전제 조건
프로젝트 파일 생성
Docker 이미지 선택
Jekyll 설치
출력용 public 디렉터리 지정
아티팩트를 위한 public 디렉터리 지정
웹사이트 배포 및 확인
CI/CD 파일의 다른 옵션
관련 주제

GitLab 페이지 웹사이트 만들기

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

이 튜토리얼은 Jekyll 정적 사이트 생성기(SSG)를 사용하여 빈 프로젝트에서 페이지 사이트를 만드는 방법을 보여줍니다. 당신은 프로젝트를 생성하고 자체 CI/CD 구성 파일을 만들어야 합니다. 이 파일은 runner에게 명령을 제공합니다. 당신의 CI/CD 파이프라인이 실행되면 페이지 사이트가 생성됩니다.

이 예제에서 Jekyll을 사용했지만, 다른 SSG들도 비슷한 단계를 따릅니다. 이 튜토리얼을 완료하려면 Jekyll이나 SSG에 익숙할 필요가 없습니다.

GitLab 페이지 웹사이트를 만드는 방법:

단계 1: 프로젝트 파일 생성
단계 2: Docker 이미지 선택
단계 3: Jekyll 설치
단계 4: public 디렉터리를 위한 출력 지정
단계 5: 아티팩트를 위한 public 디렉터리 지정
단계 6: 웹사이트 배포 및 확인

전제 조건

GitLab에 빈 프로젝트가 있어야 합니다.

프로젝트 파일 생성

루트(최상위) 디렉터리에 다음 세 가지 파일을 생성하세요:

.gitlab-ci.yml: 실행하려는 명령을 담은 YAML 파일입니다. 일단 이 파일의 내용을 비워 둡니다.

index.html: 예를 들어 다음과 같이 HTML 콘텐츠로 채울 수 있는 HTML 파일을 생성하세요:

 <html>
 <head>
   <title>Home</title>
 </head>
 <body>
   <h1>Hello World!</h1>
 </body>
 </html>

Gemfile: Ruby 프로그램의 의존성을 설명하는 파일입니다.
다음 콘텐츠로 채워 넣으세요:
```
source "https://rubygems.org"
  
gem "jekyll"
```

Docker 이미지 선택

이 예에서 runner는 스크립트를 실행하고 사이트를 배포하기 위해 Docker 이미지를 사용합니다.

이 특정 Ruby 이미지는 DockerHub에서 관리됩니다.

.gitlab-ci.yml 파일을 편집하고 다음 텍스트를 첫 번째 줄로 추가하세요:

image: ruby:3.2

만약 당신의 SSG가 빌드하기 위해 NodeJS가 필요하다면 파일 시스템의 일부로 NodeJS를 포함하는 이미지를 지정해야 합니다. 예를 들어, Hexo 사이트의 경우 image: node:12.17.0을 사용할 수 있습니다.

Jekyll 설치

Jekyll을 로컬에서 실행하려면 설치해야 합니다:

터미널을 엽니다.
gem install bundler를 실행하여 Bundler를 설치합니다.
bundle install을 실행하여 Gemfile.lock을 생성합니다.
bundle exec jekyll build를 실행하여 Jekyll을 설치합니다.

프로젝트에서 Jekyll을 실행하려면 .gitlab-ci.yml 파일을 편집하고 설치 명령을 추가하세요:

script:
  - gem install bundler
  - bundle install
  - bundle exec jekyll build

또한, .gitlab-ci.yml 파일에서 각 script는 job으로 구성됩니다. job에는 해당 특정 작업에 적용하려는 스크립트 및 설정이 포함됩니다.

job:
  script:
  - gem install bundler
  - bundle install
  - bundle exec jekyll build

GitLab Pages에서 이 job은 pages라는 특정 이름을 가지고 있으며, 이 설정은 runner에게 당신의 웹사이트를 GitLab Pages로 배포하려고 한다는 것을 알려줍니다:

pages:
  script:
    - gem install bundler
    - bundle install
    - bundle exec jekyll build

출력용 `public` 디렉터리 지정

Jekyll은 생성된 웹사이트를 저장할 위치를 알아야 합니다. GitLab Pages는 public이라는 디렉터리에 있는 파일들만 고려합니다.

Jekyll은 -d 목적지 플래그를 사용하여 구축된 웹사이트를 위한 출력 디렉터리를 지정합니다. .gitlab-ci.yml 파일에 목적지를 추가하세요:

pages:
  script:
    - gem install bundler
    - bundle install
    - bundle exec jekyll build -d public

아티팩트를 위한 `public` 디렉터리 지정

이제 Jekyll이 파일을 public 디렉터리에 출력했으므로, runner는 그 파일을 가져올 위치를 알아야 합니다. 아티팩트는 public 디렉터리에 저장됩니다:

pages:
  script:
    - gem install bundler
    - bundle install
    - bundle exec jekyll build -d public
  artifacts:
    paths:
      - public

당신의 .gitlab-ci.yml 파일은 이제 다음과 같아야 합니다:

image: ruby:3.2

pages:
  script:
    - gem install bundler
    - bundle install
    - bundle exec jekyll build -d public
  artifacts:
    paths:
      - public

웹사이트 배포 및 확인

위의 단계를 완료한 후에 웹사이트를 배포하세요:

.gitlab-ci.yml 파일을 저장하고 커밋합니다.
Build > Pipelines로 이동하여 파이프라인을 확인합니다.
파이프라인이 완료되면, Deploy > Pages로 이동하여 페이지 웹사이트 링크를 찾습니다.

이 pages 작업이 성공적으로 완료되면 파이프라인 뷰에 특별한 pages:deploy 작업이 표시됩니다. 이 작업은 GitLab Pages 데몬을 위한 웹사이트 콘텐츠를 준비합니다. 이 작업은 runner를 사용하지 않고 GitLab이 백그라운드에서 실행합니다.

CI/CD 파일의 다른 옵션

더 고급 작업을 수행하려면, 다른 CI/CD YAML 키워드로 .gitlab-ci.yml 파일을 업데이트할 수 있습니다. GitLab에 포함된 CI Lint 도구를 사용하여 .gitlab-ci.yml 파일을 유효성을 검사할 수 있습니다.

다음 주제들은 CI/CD 파일에 추가할 수 있는 다른 옵션의 예제를 보여줍니다.

특정 브랜치를 Pages 사이트로 배포 지정

특정 브랜치에서만 Pages 사이트로 배포하려는 경우:

먼저, 변경 사항이 브랜치로 푸시될 때만 파이프라인이 실행되도록 workflow 섹션을 추가합니다:

image: ruby:3.2

workflow:
  rules:
    - if: $CI_COMMIT_BRANCH

pages:
  script:
    - gem install bundler
    - bundle install
    - bundle exec jekyll build -d public
  artifacts:
    paths:
      - public

그런 다음, 파이프라인을 기본 브랜치 (여기서 main인 경우)에서만 실행하도록 구성합니다.

image: ruby:3.2

workflow:
  rules:
    - if: $CI_COMMIT_BRANCH

pages:
  script:
    - gem install bundler
    - bundle install
    - bundle exec jekyll build -d public
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

배포할 스테이지 지정

GitLab CI/CD에는 빌드, 테스트 및 배포를 위한 세 가지 기본 스테이지가 있습니다.

프로덕션으로 배포하기 전에 스크립트를 테스트하고 생성된 사이트를 확인하려면 테스트를 기본 브랜치로 푸시할 때와 정확히 같은 방식으로 테스트할 수 있습니다.

작업이 실행될 스테이지를 지정하려면 CI 파일에 stage 줄을 추가하세요:

image: ruby:3.2

workflow:
  rules:
    - if: $CI_COMMIT_BRANCH

pages:
  stage: deploy
  script:
    - gem install bundler
    - bundle install
    - bundle exec jekyll build -d public
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  environment: production

이제 CI 파일에 다른 작업을 추가하여 main 브랜치를 제외한 모든 브랜치로의 모든 푸시마다 테스트하도록 지시하세요:

image: ruby:3.2

workflow:
  rules:
    - if: $CI_COMMIT_BRANCH

pages:
  stage: deploy
  script:
    - gem install bundler
    - bundle install
    - bundle exec jekyll build -d public
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  environment: production

test:
  stage: test
  script:
    - gem install bundler
    - bundle install
    - bundle exec jekyll build -d test
  artifacts:
    paths:
      - test
  rules:
    - if: $CI_COMMIT_BRANCH != "main"

test 작업이 test 스테이지에서 실행될 때, Jekyll은 test라는 디렉터리에 사이트를 빌드합니다. 이 작업은 main을 제외한 모든 브랜치에 영향을 미칩니다.

다른 작업에 스테이지를 적용하면 같은 스테이지에 있는 각 작업이 병렬로 빌드됩니다. 웹 애플리케이션이 배포되기 전에 둘 이상의 테스트가 필요한 경우 동시에 모든 테스트를 실행할 수 있습니다.

중복 명령 제거

각 작업에서 동일한 스크립트를 중복해서 작성하지 않으려면 해당 스크립트를 before_script 섹션에 추가할 수 있습니다.

다음 예시에서 gem install bundler 및 bundle install 명령은 pages와 test 작업에서 모두 실행되었습니다.

이 명령들을 before_script 섹션으로 이동하세요:

image: ruby:3.2

workflow:
  rules:
    - if: $CI_COMMIT_BRANCH

before_script:
  - gem install bundler
  - bundle install

pages:
  stage: deploy
  script:
    - bundle exec jekyll build -d public
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  environment: production

test:
  stage: test
  script:
    - bundle exec jekyll build -d test
  artifacts:
    paths:
      - test
  rules:
    - if: $CI_COMMIT_BRANCH != "main"

캐시된 의존성으로 더 빠르게 빌드하기

빌드 속도를 높이기 위해, cache 매개변수를 사용하여 프로젝트의 의존성을 설치하는 파일을 캐시할 수 있습니다.

다음 예시에서는 bundle install을 실행할 때 Jekyll 의존성을 vendor 디렉터리에 캐시합니다:

image: ruby:3.2

workflow:
  rules:
    - if: $CI_COMMIT_BRANCH

cache:
  paths:
    - vendor/

before_script:
  - gem install bundler
  - bundle install --path vendor

pages:
  stage: deploy
  script:
    - bundle exec jekyll build -d public
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  environment: production

test:
  stage: test
  script:
    - bundle exec jekyll build -d test
  artifacts:
    paths:
      - test
  rules:
    - if: $CI_COMMIT_BRANCH != "main"

이 경우, Jekyll이 디렉터리를 사이트와 함께 빌드하려고 시도하지 않도록 /vendor 디렉터리를 제외해야 합니다.

루트 디렉터리에 _config.yml 파일을 생성하고 다음 내용을 추가하세요:

exclude:
  - vendor

이제 GitLab CI/CD는 웹사이트를 빌드하는 것뿐만 아니라 다음을 수행합니다:

피처 브랜치로 지속적인 테스트를 푸시합니다.
Bundler로 설치된 캐시된 의존성을 유지합니다.
main 브랜치로의 모든 푸시를 지속적으로 배포합니다.

사이트를 위해 생성된 HTML 및 기타 에셋을 확인하려면, 작업 아티팩트를 다운로드하세요.

GitLab 페이지 웹사이트 만들기

전제 조건

프로젝트 파일 생성

Docker 이미지 선택

Jekyll 설치

출력용 `public` 디렉터리 지정

아티팩트를 위한 `public` 디렉터리 지정

웹사이트 배포 및 확인

CI/CD 파일의 다른 옵션

특정 브랜치를 Pages 사이트로 배포 지정

배포할 스테이지 지정

중복 명령 제거

캐시된 의존성으로 더 빠르게 빌드하기

관련 주제

도움말

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

도움받기

GitLab 페이지 웹사이트 만들기

전제 조건

프로젝트 파일 생성

Docker 이미지 선택

Jekyll 설치

출력용 public 디렉터리 지정

아티팩트를 위한 public 디렉터리 지정

웹사이트 배포 및 확인

CI/CD 파일의 다른 옵션

특정 브랜치를 Pages 사이트로 배포 지정

배포할 스테이지 지정

중복 명령 제거

캐시된 의존성으로 더 빠르게 빌드하기

관련 주제

도움말

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

도움받기

출력용 `public` 디렉터리 지정

아티팩트를 위한 `public` 디렉터리 지정