GitLab 페이지 웹 사이트 생성 예제
이 예제에서는 처음 페이지 사이트를 만드는 방법부터 보여드리겠습니다. 빈 프로젝트부터 시작해서 GitLab Runner에게 지시하는 자신만의 CI 파일을 만들 것입니다. CI/CD 파이프라인이 실행되면 페이지 사이트가 생성됩니다.
이 예에서는 Jekyll Static Site Generator(SSG)를 사용합니다. 다른 SSG도 유사한 단계를 따르므로, 이 예제를 완료하기 위해 Jekyll 또는 SSG에 익숙해야 할 필요는 없습니다.
전제조건
이 예제와 함께 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"
도커 이미지 선택
이 예에서 Runner는 도커 이미지를 사용하여 스크립트를 실행하고 사이트를 배포합니다.
이 루비 이미지는 DockerHub에서 배포됩니다.
.gitlab-ci.yml을 편집하고 이 텍스트를 첫 번째 줄로 추가합니다.
image: ruby:2.7
SSG에서 작성할 NodeJS가 필요한 경우, 파일 시스템의 일부로 NodeJS가 포함된 이미지를 지정합니다. 예를 들어 Hexo 사이트의 경우 image: node:12.17.0
을 지정합니다.
Jekyll 설치
Jekyll을 로컬에서 실행하려면 터미널을 열고 다음을 수행합니다.
gem install bundler를 실행하여 Bundler 설치
bundle install을 실행하여 Gemfile.lock 생성
bundle exec jekyll build를 실행하여 Jekyll 설치
.gitlab-ci.yml 파일에 다음과 같이 기록됩니다.
또한 .gitlab-ci.yml 파일에서 각 스크립트를 작업별로 구성합니다. 작업에는 특정 태스크에 적용할 스크립트 및 설정이 포함됩니다.
GitLab 페이지의 경우 이 작업에는 Pages라는 특정 이름이 있습니다. 이 설정은 작업자가 GitLab 페이지를 사용하여 웹 사이트를 배포하도록 지시합니다.
Output에 대한 Public 디렉터리 지정
Jekyll은 어디서 아웃풋을 발생시킬지 알아야 합니다. GitLab 페이지는 public이라고 불리는 디렉토리의 파일만 고려합니다.
Jekyll은 destination(-d) 옵션을 사용하여 빌드된 웹 사이트의 출력 디렉터리를 지정합니다.
아티팩트에 대한 Public 디렉터리 지정
Jekyll이 파일을 public 디렉토리에 출력했으므로, Runner는 그것들을 어디서 구해야 하는지 알아야 합니다. 아티팩트는 다음 public 디렉터리에 저장됩니다.
지금까지의 내용을 .gitlab-ci.yml 파일에 붙여넣기 하면, 다음과 같이 보일 것입니다.
이제 .gitlab-ci.yml 파일을 저장하고 커밋합니다. CI / CD > Pipelines로 가면 파이프라인을 볼 수 있습니다.
성공했으면 Settings > Pages로 이동하여 현재 사이트에 접속할 수 있는 URL을 확인합니다.
다음 항목에서는 CI/CD 파일에 추가할 수 있는 다른 옵션의 예를 보여 드리 겠습니다.
페이지 사이트에 특정 브랜치 배포
특정 브랜치에서만 페이지 사이트로 배포할 수 있습니다.
.gitlab-ci.yml에 다른 줄을 추가할 수 있으며, 이 행은 Runner에게 마스터 브랜치의 페이지라는 작업만 수행하도록 지시합니다.
배포할 단계 지정
GitLab CI/CD에는 빌드, 테스트 및 배포의 세 가지 기본 단계가 있습니다.
프로덕션에 배포하기 전에 스크립트를 테스트하고 빌드된 사이트를 확인하려면, 마스터로 푸시할 때 테스트를 정확하게 실행할 수 있습니다.
작업이 실행될 단계를 지정하려면 단계라인을 CI 파일에 추가합니다.
이제 CI 파일에 다른 작업을 추가하여 마스터 브랜치를 제외한 다른 브랜치에 대한 모든 푸시를 테스트하도록 합니다.
테스트 작업이 테스트 단계에서 실행되면 Jekyll은 테스트라는 디렉토리에 사이트를 구축합니다. 이 작업은 마스터를 제외한 모든 브랜치에 영향을 미칩니다.
단계를 다른 작업에 적용하면 같은 단계의 모든 작업이 병렬로 구축됩니다. 웹 애플리케이션을 배포하기 전에 둘 이상의 테스트가 필요한 경우 모든 테스트를 동시에 실행할 수 있습니다.
중복 명령 제거
각 작업에 대해 동일한 스크립트가 실행되지 않도록 before_script 매개 변수를 추가합니다. 이 섹션에서는 모든 작업에 대해 실행할 명령을 지정합니다.
이 예에서는 pages 및 test 작업 모두에 대해 gem install bundler
와 bundle install
가 실행되고 있었습니다.
다음 명령을 before_script 섹션으로 이동:
캐시된 종속성으로 더 빠르게 빌드
더 빠른 빌드를 위해서는, 캐시 매개 변수를 사용하여 프로젝트의 종속성에 대한 설치 파일을 캐시합니다.
예를 들어 bundle install
을 실행할 때 vendor 디렉토리에 Jekyll 종속성을 캐시하려면:
이 경우 Jekyll이 빌드하는 폴더 목록에서 vendor 디렉토리를 제외해야 합니다. 그렇지 않으면 Jekyll은 사이트와 함께 디렉토리 내용을 빌드하려고 할 것입니다.
루트 디렉터리에서 _config.yml
이라는 파일을 만들고 다음 내용을 추가합니다.
이제 GitLab CI / CD는 웹 사이트를 구축 할뿐만 아니라 기능 브랜치에 대한 지속적인 테스트와, Bundler와 함께 설치된 종속성을 캐시하고, 모든 푸시를 마스터 브랜치에 지속적으로 배포합니다.