- 선행 조건
- 프로젝트 파일 생성
- Docker 이미지 선택
- Jekyll 설치
- 출력용
public
디렉토리 지정 - artifacts을 위한
public
디렉토리 지정 - 웹사이트 배포 및 보기
- .gitlab-ci.yml 파일의 다른 옵션
- 관련 주제
튜토리얼: GitLab Pages 웹사이트를 처음부터 만들기
이 튜토리얼에서는 Jekyll 정적 사이트 생성기(SSG)를 사용하여 처음부터 페이지 사이트를 만드는 방법을 보여줍니다. 빈 프로젝트에서 시작하여 자체 CI/CD 구성 파일을 만들고, 해당 파일은 runner에게 지시를 제공합니다. CI/CD 파이프라인이 실행되면 페이지 사이트가 생성됩니다.
이 예시는 Jekyll을 사용하지만, 다른 SSG도 비슷한 단계를 따릅니다. Jekyll이나 SSG에 익숙할 필요는 없습니다.
GitLab Pages 웹사이트를 만들려면 다음을 수행하세요:
- 단계 1: 프로젝트 파일 생성
- 단계 2: Docker 이미지 선택
- 단계 3: Jekyll 설치
- 단계 4: 출력용
public
디렉토리 지정 - 단계 5: artifacts을 위한
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에게 해당 job을 사용하여 GitLab Pages로 웹사이트를 배포하고자 한다는 것을 알려줍니다.
pages:
script:
- gem install bundler
- bundle install
- bundle exec jekyll build
출력용 public
디렉토리 지정
Jekyll은 생성된 웹사이트의 출력 위치를 알아야 합니다. GitLab Pages는 public
이라는 디렉토리에 있는 파일만을 고려합니다.
Jekyll은 구축된 웹사이트의 출력 디렉토리를 지정하기 위해 destination flag(-d
)를 사용합니다. .gitlab-ci.yml
파일에 destination을 추가하세요:
pages:
script:
- gem install bundler
- bundle install
- bundle exec jekyll build -d public
artifacts을 위한 public
디렉토리 지정
이제 Jekyll은 파일을 public
디렉토리에 출력했으므로 runner는 어디에서 가져올지 알아야 합니다. artifacts는 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
job이 성공적으로 완료되면 파이프라인 보기에서 특별한 pages:deploy
job이 나타납니다. 이 job은 웹사이트 내용을 GitLab Pages 데몬용으로 준비합니다. GitLab은 이를 백그라운드에서 실행하며 runner를 사용하지 않습니다.
.gitlab-ci.yml 파일의 다른 옵션
더 고급 작업을 수행하려면 다른 CI/CD YAML 키워드로 .gitlab-ci.yml
파일을 업데이트할 수 있습니다. GitLab과 함께 제공되는 CI Lint 도구로 .gitlab-ci.yml
파일을 유효성 검사할 수 있습니다.
다음 주제에서는 .gitlab-ci.yml
파일에 추가할 수 있는 다른 옵션의 예제를 보여줍니다.
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에는 빌드, 테스트, 배포의 세 가지 기본 단계가 있습니다.
프로덕션으로 배포하기 전에 스크립트를 테스트하고 빌드된 사이트를 확인하려면, 테스트를 바로 실행할 수 있도록 기본 브랜치 (여기서 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
이제 test
브랜치를 제외한 모든 브랜치에 대해 매 푸시 시 test
작업을 실행하도록 CI 파일에 다른 작업을 추가합니다:
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"
이 경우, /vendor
디렉토리를 Jekyll이 빌드 목록에서 제외해야 합니다. 그렇지 않으면 Jekyll은 사이트와 함께 디렉토리 내용을 빌드하려고 시도합니다.
루트 디렉토리에 _config.yml
이라는 파일을 만들고 다음 내용을 추가합니다:
exclude:
- vendor
이제 GitLab CI/CD는 웹 사이트를 빌드하는 것뿐만 아니라:
- 기능 브랜치로 지속적인 테스트를 푸시합니다.
- Bundler로 설치된 캐시된 종속성을 캐시합니다.
-
main
브랜치로 푸시할 때 지속적으로 배포합니다.
사이트를 생성하는 데 사용된 HTML 및 기타 에셋을 보려면 작업 아티팩트를 다운로드하세요.