Gitlab CI/CD Pipeline

오래전 타이틀만 만들어둔 글을 이제야 완성시키네요. 

Gitlab 사용자 그리고 CI/CD에 관심 있으신 분들께 도움이 될 수 있으면 합니다.

# CI/CD

CI(Continuous Integration), 지속적인 통합은 애플리케이션에 대한 새로운 코드와 같은 변경사항이 일어났을 때, 정기적으로 테스트, 빌드 과정을 거쳐 공유 리퍼지토리에 통합되는 과정을 의미합니다. 다수의 개발자가 같은 시기에 작업을 하여 발생할 수 있는 충돌을 해결하는데 도움을 줍니다.

 

CD(Continuous Delivery/Deployment), 지속적인 제공/배포는 CI 과정을 거친 애플리케이션을 리퍼지토리에 자동 업로드 또는 서비스 환경까지 바로 배포하는 것을 의미합니다.

 

 

## Gitlab CI/CD

Gitlab은 on-premise git을 제공하는 업체입니다. Gitlab은 Commit / Merge/ Release 등의 이벤트가 발생하는 것을 감지하고 이로부터 CI/CD 파이프라인이 동작할 수 있는 환경을 제공하고 있습니다.

 

# CI/CD 파이프라인 실행 장소

Gitlab Runner라고 하는 서비스를 제공하여 CI/CD 파이프라인을 실행합니다. Gitlab Runner는 이벤트가 발생 시, 사전에 등록되어 있는 파이프라인 설정을 참고하여 CI/CD를 동작시킵니다.

 

Gitlab Runner의 설치는 다양한 방법으로 할 수 있겠지만, 저는 Gitlab에서 공식적으로 제공하는 Helm chart를 이용하여 Kubernetes 클러스터에 Gitlab runner 환경을 구축하였습니다.

 

## Gitlab runner install with k8s

Gitlab Docs를 참고하여 설치를 진행하였습니다.

GitLab Runner Helm Chart | GitLab

Gitlab Runner 구성은 Helm3 기준으로 작성되었습니다.

 

---

만약, Helm 사용법을 모르신다면, 이야기박스 블로그의 [Kubernetes. Helm3] 포스팅을 참조해주세요.

Kubernetes. Helm3

---

 

만약 Helm3 설치가 완료되었다면, 아래와 같이 Gitlab helm chart repository 등록을 진행합니다.

helm repo add gitlab https://charts.gitlab.io
helm init

Repository 등록이 완료되었다면, Helm 설치에 사용될 values.yaml을 구성해봅시다. [values.yaml]의 템플릿은 공식 git에서 받으실 수 있습니다.

 

다른 기타 설정들은 굳이 해주지 않아도 됩니다. 다만 Gitlab runner와 Gitlab Group or Project가 통신할 수 있는 token의 설정은 반드시 해줘야 합니다.

토큰의 키 값은 [ Gitlab group/project page --> Settings --> CI/CD --> Runners ]에 입력되어 있는 토큰 키 값을 복사해오면 됩니다.

위에서 가져온 토큰 값을 values.yaml의 `runnerRegistrationToken` 에 넣어줍니다.

## The registration token for adding new Runners to the GitLab server. This must
## be retrieved from your GitLab instance.
## ref: https://docs.gitlab.com/ee/ci/runners/
##
runnerRegistrationToken: {토큰 키}

위 세팅이 완료되었다면, Helm을 통하여 gitlab runner를 설치해 줍니다.

helm upgrade --install --namespace <NAMESPACE> -f <CONFIG_VALUES_FILE> <RELEASE-NAME> gitlab/gitlab-runner

ex.
helm upgrade --namespace default -f values.yml gitlab-runner gitlab/gitlab-runner

설치하고 나면 [ Gitlab group/project page --> Settings --> CI/CD --> Runners ] 탭에서 아래와 같이 불이 들어와 있는 것을 확인할 수 있습니다.

Gitlab Runner 설치가 이제 완료되었습니다!

 

## Gitlab CI/CD 파이프라인 실행 설정

Gitlab의 CI/CD 파이프라인 실행 설정은 `.gitlab-ci.yml` 파일을 통해서 할 수 있습니다. yml 형식을 기반으로 하다 보니 자유도는 매우 높은 편입니다. 저는 이번 포스팅에서 제가 겪었던 이슈 위주로 정리해보았습니다. 그렇기에 기초적인 작성 방법은 `gitlab-ci 공식문서`에서 별도로 참조 부탁드립니다.

GitLab CI: Run jobs sequentially, in parallel or build a custom pipeline

# .gitlab-ci.yml 설정 노하우 공유

이번 단락에서는 Gitlab CI/CD 파이프라인 작업하면서 겪었던 이슈들을 하나씩 정리해보려고 합니다. Gitlab Runner가 CI/CD를 실행하는 모습은 다음과 같습니다. 클러스터에 Runner 파드가 생성되어 있고, 이벤트가 들어오면 .gitlab-ci.yml 파일을 읽어 CI/CD Pipeline을 실행시키는 거죠.

때문에 .gitlab-ci.yml 설정 파일이 Dockerfile과 비슷하다 생각하시면 조금 더 친숙하게 보이게 됩니다.

각 파이프라인 파드의 베이스로 사용된 이미지에 적합한 문법을 작성해주시면 됩니다.

 

## 환경 변수 설정

[ Settings --> CI/CD --> Environment variables ]에 들어가서 CI/CD에 사용될 환경 변수를 사전에 등록할 수 있습니다.

 

## No `.gitlab-ci.yaml`

당황스럽게도 `yml`은 지원하면서 `yaml` 포맷은 지원하지 않습니다. 주의 바랍니다.

 

## 특정 브런치, Tags에서 실행하기

코드 커버리지, 테스트를 모든 이벤트에서 실행한다면 Git 통합 과정이 매우 오래 걸리겠죠? 그래서 특정 브런치, Tags를 지정하는 방법을 Gitlab CI/CD에서 지원하고 있습니다.

  only:
    - develop
    - master

위와 같이 `only` 필드를 사용하면 `develop`, `master` 브런치에 커밋되는 이벤트에서만 파이프라인인 동작 합니다.

  only:
    - tags

만약, 특정 태그(release)에서만 동작하게 하고 싶으시다면 위와 같은 설정을 해주시면 됩니다.

추가로 Tag명을 변수로 파이프라인 변수로 사용하고 싶으시다면 아래 옵션을 추가해주시면 됩니다.

  variables:
    IMAGE_TAG: $CI_COMMIT_REF_NAME

그리고 정규 표현식도 지원하기 때문에 아래와 같은 표현도 가능합니다.

  only:
    - /^release/.*$/

위와 같이 표현하면 `release/**` 의 모든 브런치에서 이벤트가 동작하게 됩니다.

 

## Artifacts 관리

CI/CD를 통하여 생성된 결과물을 일정 기간만 보관하려고 한다면, 다음과 같이 만료기간을 설정해주면 됩니다.

  artifacts:
    paths:
      - target/checkstyle-result.xml
    expire_in: 2 week

 

## 필요 라이브러리 설치

Gitlab Runner로 동작하는 Pod는 아주 기본적인 기능만 가지고 있기 때문에, 필요하신 라이브러리는 직접 설치하는 게 필요합니다. 아래는 ubuntu 이미지에 zip 라이브러리를 설치하는 예제입니다.

  before_script:
    - apt-get update
    - apt-get install zip -qy

 

## Docker Image 빌드

저는 회사 작업 환경상, 서버에서 직접 빌드가 불가능하여 kaniko라고 하는 서비스를 사용하였습니다.

latest-docker-build:
  stage: image-deploy
  image:
    name: gcr.io/kaniko-project/executor:debug
    entrypoint: [""]
  variables:
    IMAGE_NAME: storyparks-app
    IMAGE_TAG: latest
  script:
    - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
    - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $CI_REGISTRY_IMAGE/$IMAGE_NAME:$IMAGE_TAG
  only:
    - master

만약에 직접 빌드가 가능하다고 하시면, 사전에 도커를 설치하는 것도 하나의 방법일 것이라 생각됩니다.

 

## Maven settings.xml 사전 등록

사설 Maven repository를 이용하는 경우, 설정 정보는 다음과 같이 넘겨줄 수 있습니다.

variables:
  MAVEN_CLI_OPTS: "-s .m2/settings.xml --batch-mode"

cache:
  paths:
    - ./.m2/repository

 

 

# 파이프라인 동작 화면

[ Gitlab Project --> CI/CD --> Pipelines ] 탭에서 확인 가능합니다.

 

# 후기

정말 만족하고 있는 Gitlab의 기능 중 하나입니다.

다른 분들은 Jenkins와 같은 다른 CI/CD 툴에 연동하여 쓰기도 한다는군요. 저는 여러 툴을 쓰는게 싫어서.. 이거 하나를 잘 꾸려보자 하는 마인드로 지내고 있습니다. 아무튼 오래된 숙제같은 글을 마무리 지으니 기분이 좋군요.

 

만약 Gitlab CI/CD에 대하여 질문이 있으시다면 댓글 부탁 드립니다.