개요
DevOps 상에서 지속적인 통합과 배포라 일컬어지는 CI/CD는 다음과 같은 의미를 가지고 있다.
CI (Continuous Integration)
코드 저장소에 변경이 발생할 때마다 자동으로 응용 프로그램을 빌드하고 테스트함으로써 애플리케이션 오류 가능성을 감소시킨다.
CD (Continuous Delivery/Deployment)
코드 저장소에 변경이 발생할 때마다 자동으로 빌드한 애플리케이션을 배포한다.
대표적인 CI/CD 도구로는 이 글에서 몇 번 다뤘던 Jenkins가 있지만, GitLab 또한 존재한다. 이번 글에서는 GitLab에서 CI/CD를 위한 기능 중 파이프라인에 대해서 알아보려고 한다.
GitLab CI/CD 파이프라인
GitLab CI/CD는 다양한 개념과 용어를 사용해 빌드, 배포를 수행한다.
Pipelines
파이프라인은 지속적 통합 및 배포의 최상위 구성 요소로, 파이프라인은 Jobs과 Stages로 구성된다. Jobs은 코드 컴파일, 코드 테스트와 같이 수행할 작업을 정의하며, Stages는 작업을 실행할 시기를 정의한다.
일반적으로 파이프라인은 자동으로 실행된다. 하지만 수동으로 파이프라인을 처리할 수도 있다.
Jobs
Job은 파이프라인의 구성 요소로, 파이프라인 정의 파일인 .gitlab-ci.yml의 기본적인 요소이다. 러너(Runner(에 의해 실행되기 때문에 러너가 실행해야 하는 명령의 모음이라고 할 수 있다.
한 단계의 모든 Job이 성공하면 다음 단계로 넘어가고, 한 단계의 임의 Job이 실패하면 대체로 파이프라인은 종료된다. 한 단계의 여러 Job은 병렬로 실행될 수 있다.
Job 자체는 실행 조건과 이름, 실행할 스크립트 등을 포함하고 있어야 하며, 개수 제한 없이 정의할 수 있다. 아래 예시는 서로 다른 명령을 실행하는 두 개의 Job으로 구성된 파이프라인이다.
job1:
script: "execute-script-for-job1"
job2:
script: "execute-script-for-job2"
Variables
일종의 환경 변수로, Job 또는 파이프라인의 동작을 제어하는 데 사용한다. .gitlab-ci.yml에 값을 하드 코딩하는 것을 방지하고 값을 재사용하기 위해 사용된다.
gitlab 자체에서 미리 정의한 변수도 존재한다.
( 참고 :https://docs.gitlab.com/ee/ci/variables/predefined_variables.html )
Environments
코드가 배포되는 위치를 설명한다. GitLab CI/CD가 코드 버전을 배포할 때마다 Deployment가 생성되는데, 이를 통해 각 환경에 대한 배포 이력을 추적할 수 있게 된다.
Artifacts
저장 또는 업로드를 위해 Job에 의해 생성되는 파일로, Stage 간에 전달할 수 있는 결과 파일이라고 할 수 있다. 특정 Stage의 Artifact는 다음 Stage에서 사용할 수 있다. 단, 같은 Stage의 다른 Job에서는 사용할 수 없다.
Cache
프로젝트 의존성(Dependencies)을 저장하는 데 사용한다. Cache는 다운로드한 npm 패키지 등을 저장하여 후속 파이프라인에서 다시 가져올 필요가 없도록 하여 Job의 속도를 높일 수 있다.
Runners
러너는 .gitlab-ci,yml에 정의한 코드를 실행한다. GitLab CI/CD의 API를 통해 CI Job을 선택하고, 실행한 다음 결과를 GitLab에 전달한다.
러너는 관리자가 생성하겨 GitLab UI로 확인할 수 있다. 또한 유형에 따라 특정 프로젝트 전용으로 사용하거나 여러 프로젝트에서 공유하여 사용할 수 있다.
참고 문서
https://docs.gitlab.com/ee/ci/
https://insight.infograb.net/blog/2021/04/08/gitlab-cicd-pipeline/
https://insight.infograb.net/docs/user/quick_start_ci_cd/
https://workshop.infograb.io/gitlab-ci/11_introduction-to-gitlab-cicd/3_gitlab_ci_cd_terms_concepts/