카테고리 없음

GitLab CI/CD PipeLine 세팅 (이전 완료)

ㅈ현 2022. 6. 18. 20:46

GitLab에서 제공하는 PipeLnie 기능을 활용해보자. 

Pipeline은 gitlab의 CI/CD를 위한 기능으로써, 본 포스팅에서는 on-promise환경이 아닌 gitlab 자체 서버상에서 동작을 다룸.

Introduction to CI/CD with GitLab | GitLab

 

CI/CD concepts | GitLab

An overview of Continuous Integration, Continuous Delivery, and Continuous Deployment, as well as an introduction to GitLab CI/CD.

docs.gitlab.com

 

Gitlab에서 CI/CD를 활성화 하려면 루트 경로에 .gitlab-ci.yml 파일을 작성해 놓으면 자동으로 활성화 된다.

.gitlab-ci.yml 파일


이 파일에서는 실행할 스크립트 정의, 포함 및 캐시종속성정의, 순서대로 또는 병렬로 실행할 명령을 선택하고 앱을 배포할 위치를 정의하고 스크립트의 자동/수동 실행등을 정의할 수 있다. 
추가적인 설정을 하지 않으면 CI/CD 파이프 라인은 원격 저장소로 PUSH하게되면 트리거 된다. 
파이프 라인이 끝나고 만족하게 된다면 분기를 merge하거나, 승인할 수 있고 문제가 생긴다면 쉽게 롤백 할 수 있다.

1. Pipeline


PipeLine은 CI/CD 메뉴에 있고 누르게되면

실행시킨 파이프라인 목록


다음과 같이 내가 실행 파이프라인 목록들을 볼 수 있다.

파이프라인은 CI/CD의 최상위 구성 요소다.

Pipeline Example

 

위 그림에서 Test Stage에는 appbuildtest job과, pythontest job이 존재하고,
Build Stage에는 build job이 존재하고,
Deploy Stage에는 deploy job이 존재한다.
또한 build job은 두개의 test에 대해 의존성을 가지고, deploy는 build에 의존성을 가진다.

2. 파이프라인 구성 

github actions와는 용어가 다름.

  • work, job : 기본 구성 요소로, 위 그림에서는 appbuildtest, pythontest, build, deploy가 job에 해당된다.
  • stage : 파이프 라인동안 거쳐야 하는 단계이며 위 그림에서는 test, build, deploy 세 stage가 존재한다.

해당 파이프 라인은 각 stage들로 구성되어 있으며 이 stage들은 사용자가 임의로 설정할 수 있다. 

하지만 진행 순서에 따라 진행하므로, 별도의 설정이 없다면 이전 stage에서 pass되지 않으면 다음 단계로 진행되지 않는다.

3. gitlab-ci.yml

파이프 라인을 진행시키려면 root에 .gitlab-ci.yml이라는 파일이 필요하다. 

위 파일은 파이프 라인을 정의한 파일로 예시는 다음과 같다.

stages:
  - build
  - test

build-code-job:
  stage: build
  image: ubuntu:18.04
  script:
    - echo "Check the ruby version, then build some Ruby project files:"
    - ruby -v
    - rake

test-code-job1:
  stage: test
  script:
    - echo "If the files are built successfully, test some files with one command:"
    - rake test1

test-code-job2:
  stage: test
  script:
    - echo "If the files are built successfully, test other files with a different command:"
    - rake test2
 

예시로 쓰인 파일의 설명은 다음과 같다.

  • stages : 파이프라인에서 실시할 단계들을 의미한다. 위 예시에서는 build, test 두 단계를 실시했다.
  • build-code-job, test-code-job1, test-code-job2 : 이 세개는 job으로써 각 stage에서 수행될 작업이다. build-code-job는 build Stage이고, test-code-job1, test-code-job2세션 는 test Stage이다.
  • stage : 해당 job이 수행될 stage다.

  • image : 파이프 라인은 기본적으로 gitlab runner를 통해 테스트 및 빌드를 진행하고 gitlab runner 는 기본적으로 Docker image를 사용한다.
    때문에 사용할 이미지를 선택해 해당 이미지로 만든 컨테이너 위에서 단계들이 실행된다고 생각하면 된다.
  • services : docker 이미지중 위 예시에서는 docker 안에서 docker를 빌드 및 push하는 docker in docker 서비스가 필요하기 때문에 명시를 해준 것이다.
  • script : 해당 컨테이너에서 실행할 스크립트들이다. 
  • ${variable} : 해당 변수들은 프로젝트페이지에서 마스터만 설정이 가능하다.


해당 페이지에 들어가면 variables라는 섹션이 있고 여기서 yml 파일에 필요한 변수들을 세팅하면 된다.

 

 

4. 수동으로 동작


프로젝트 -> CI/CD -> RUN PIPELINE -> 변수설정 -> RUN! 로 파이프라인을 수동으로 작동시킬 수 있다.

 

5. parents - chile PipeLine

파이프 라인이 복잡해 짐에 따라 한 프로젝트에서 실행되는 하위 파이프 라인을 실행시킬수 있다.

stages:
  - triggers
build_a:
  stage: triggers
  trigger:
    include: .win-gitlab-ci.yml
  rules:
    - changes:
      - cpp_app/* 
build_b:
  stage: triggers
  trigger:
    include: .linux-gitlab-ci.yml
  • trigger : 가장 중요한 값으로 실행시킬 하위 구성 파일을 정의하는 key이다. 상위 파이프 라인은 트리거 한 후에도 계속 실행
    • include : 최대 3개의 하위 파이프 라인까지 템플릿 구성 파일을 사용(말그대로 실행할 파일 지정)
  • rules : 특정 조건에서 파이프 라인을 트리거 한다.
    • changes : cpp_app하위 디렉토리가 변경될 경우에만 트리거 된다는 의미이다.

6. merge시 pipeline 동작

setting -> general -> merge request -> pipeline must successed 


::SAVE::
해당 설정을 해주면

 

merge requests에서 요로코롬 뜨게 된다.

7. 변수설정

수동 실행시 미리 .gitlab-ci.yml 파일에 작성되어있는 변수의 값을 세팅해줄 수 있다.
.gitlab-ci.yml파일에서 ${변수명} 형식으로 사용

 Variables에서 변수명 : values값을 세팅해주면 .gitlab-ci.yml에서 사용한 변수에 설정한 값이 들어간다.