- 전제 조건
- 프로젝트 파일 생성
- Docker 이미지 선택
- Jekyll 설치
- 출력용
public
디렉터리 지정 - 아티팩트를 위한
public
디렉터리 지정 - 웹사이트 배포 및 확인
- CI/CD 파일의 다른 옵션
- 관련 주제
GitLab 페이지 웹사이트 만들기
이 튜토리얼은 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 및 기타 에셋을 확인하려면, 작업 아티팩트를 다운로드하세요.