- 필수 조건
- 프로젝트 파일 생성
- Docker 이미지 선택
- Jekyll 설치
- 출력용
public디렉터리 지정 - 아티팩트를 위한
public디렉터리 지정 - 웹사이트 배포 및 보기
- CI/CD 파일에 대한 기타 옵션
- 관련 주제
튜토리얼: GitLab Pages 웹사이트를 처음부터 만들기
Offering: GitLab.com, Self-managed, GitLab Dedicated
이 튜토리얼은 Jekyll 정적 사이트 생성기(SSG)를 사용하여 처음부터 Pages 사이트를 만드는 방법을 보여줍니다.
빈 프로젝트로 시작하여 CI/CD 구성 파일을 생성하는데, 이는 러너에 지침을 제공합니다.
당신의 CI/CD 파이프라인이 실행되면, Pages 사이트가 생성됩니다.
이 예제는 Jekyll을 사용하지만 다른 SSG도 유사한 단계를 따릅니다.
이 튜토리얼을 완료하기 위해 Jekyll이나 SSG에 대한 이해가 필요하지 않습니다.
GitLab Pages 웹사이트를 만들려면:
- 1단계: 프로젝트 파일 생성
- 2단계: Docker 이미지 선택
- 3단계: Jekyll 설치
- 4단계: 출력용
public디렉터리 지정 - 5단계: 아티팩트용
public디렉터리 지정 - 6단계: 웹사이트 배포 및 보기
필수 조건
GitLab에 빈 프로젝트가 있어야 합니다.
프로젝트 파일 생성
루트(최상위) 디렉터리에 세 개의 파일을 생성합니다:
-
.gitlab-ci.yml: 실행할 명령을 포함하는 YAML 파일입니다.지금은 파일의 내용을 비워두세요.
-
index.html: 원하는 HTML 내용으로 채울 수 있는 HTML 파일입니다.예를 들어:
<html> <head> <title>홈</title> </head> <body> <h1>안녕하세요, 세계!</h1> </body> </html> -
Gemfile: Ruby 프로그램의 종속성을 설명하는 파일입니다.다음 내용을 채워 넣으세요:
source "https://rubygems.org" gem "jekyll"
Docker 이미지 선택
이 예제에서 러너는 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라는 특정 이름을 가집니다.
이 설정은 러너에게 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 디렉터리에 출력했으므로,
러너는 파일을 가져올 위치를 알아야 합니다. 아티팩트는
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 데몬을 위해 웹사이트의 콘텐츠를 준비합니다.
GitLab은 이를 백그라운드에서 실행하며 러너를 사용하지 않습니다.
CI/CD 파일에 대한 기타 옵션
보다 고급 작업을 수행하려면, .gitlab-ci.yml 파일을
다른 CI/CD YAML 키워드로 업데이트할 수 있습니다.
GitLab에 포함된 CI Lint 도구로
.gitlab-ci.yml 파일을 검증할 수 있습니다.
다음 주제는 CI/CD 파일에 추가할 수 있는
기타 옵션의 다른 예를 보여줍니다.
특정 브랜치를 페이지 사이트에 배포
특정 브랜치에서만 페이지 사이트에 배포하고 싶을 수 있습니다.
먼저, 변경사항이 브랜치에 푸시될 때만
파이프라인이 실행되도록 하려면 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의 기본 단계는 빌드, 테스트,
배포의 세 가지입니다.
스크립트를 테스트하고 배포 전에
구축된 사이트를 확인하려면,
기본 브랜치 (여기서는 main)에
푸시할 때와 동일하게 테스트할 수 있습니다.
작업이 실행될 단계를 지정하려면,
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 디렉터리를 제외해야 합니다. 그렇지 않으면, Jekyll이 사이트와 함께 디렉터리 내용을 빌드하려고 시도합니다.
루트 디렉터리에 _config.yml이라는 파일을 만들고 이 내용을 추가하세요:
exclude:
- vendor
이제 GitLab CI/CD는 웹사이트를 빌드할 뿐만 아니라:
-
기능 브랜치에 지속적 테스트를 푸시합니다.
-
Bundler로 설치된 의존성을 캐시합니다.
-
main브랜치로의 모든 푸시를 지속적으로 배포합니다.
사이트를 위해 생성된 HTML 및 기타 자산을 보려면, 작업 아티팩트 다운로드를 클릭하세요.
도움말