gitlab-runner 설치 및 GitLab CI/CD Pipeline 사용하기

GitLab CI/CD 는 GitLab 에서 제공하는 지속적 통합 (CI) 및 지속적 배포 (CD) 서비스를 의미합니다. 이것은 소프트웨어 개발 프로세스를 자동화하고, 코드의 변경 사항을 지속적으로 통합하고 배포함으로써 개발자 팀이 효율적으로 작업할 수 있도록 도와주는 도구입니다.

 

여기에서 CI (Continuous Integration) 는 개발자들이 작성한 코드의 변경 사항을 지속적으로 통합하고 빌드하는 과정을 의미합니다. 새로운 코드가 저장소에 푸시될 때마다 자동으로 빌드 및 테스트가 수행되어 코드의 품질을 유지하고, 팀 내에서 코드 충돌이나 오류를 미리 발견할 수 있도록 도와줍니다.

 

CD (Continuous Deployment/Delivery) 는 CI 의 확장으로, 빌드 및 테스트를 통과한 코드를 자동으로 배포할 수 있도록 하는 것을 의미합니다. CD 는 애플리케이션을 테스트 환경, 스테이징 환경, 혹은 실제 운영 환경에 자동으로 배포하는 등의 작업을 지원합니다.

본 매뉴얼에 기술된 예제는 아래 포스팅 내용에 이어서 작성하였습니다.

- Ubuntu 22.04 에서 GitLab CE (Community Edition) 설치 및 사용하기 : https://sysdocu.tistory.com/1892

 

 

1. GitLab runner 설치

 

GitLab 이 설치된 서버에서 GitLab runner 설치를 진행합니다.

# curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash

# apt -y install gitlab-runner

 

설치된 버전을 확인합니다.

# gitlab-runner -v
Version:      16.8.0
Git revision: c72a09b6Enter optional 
Git branch:   16-8-stable
GO version:   go1.21.5
Built:        2024-01-18T22:42:25+0000
OS/Arch:      linux/amd64

 

 

2. Runner 생성

 

- 참고 Document : https://docs.gitlab.com/runner/register/

 

Pipeline 을 구성하기 위해서는 프로젝트와 하나 이상의 runner 가 있어야 합니다.

runner 를 등록하기 위해 GitLab 웹페이지에서 아래 메뉴로 이동, runner 를 생성합니다.

저는 runner 설치를 진행하기 전에 GitLab 에 미리 root 사용자로 sample 이라는 프로젝트를 생성했었습니다.

그리고 아래 메뉴를 통해 runner 를 생성하였습니다.

 

1) runner 생성 메뉴 : 프로젝트 (sample) 메인 화면 > Settings > CI/CD > Runners [Expand] > Project runners [New project runner] 클릭

- Platform : Linux 선택

- Tags : test 입력

- Run untagged jobs : 체크

- [Create runner] 클릭하여 생성

 

2) Shell 명령 실행

위 작업을 마치면 Shell 에서 실행하기 위한 명령 예시가 출력됩니다. 내용을 복사하여 Shell 에서 실행합니다.

# gitlab-runner register  --url http://git.sysdocu.kr --token glrt-1DJKxhPcyNk3dTiVWMcX

Runtime platform                                    arch=amd64 os=linux pid=397821 revision=c72a09b6 version=16.8.0
Running in system-mode.                            
                                                   
Enter the GitLab instance URL (for example, https://gitlab.com/):
[http://git.sysdocu.kr]: (그냥 엔터)
Verifying runner... is valid                        runner=1DJKxhPcy
Enter a name for the runner. This is stored only in the local config.toml file:
[localhost]: (그냥 엔터)
Enter an executor: parallels, virtualbox, docker-windows, docker-autoscaler, instance, custom, shell, ssh, docker, docker+machine, kubernetes:
shell
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
 
Configuration (with the authentication token) was saved in "/etc/gitlab-runner/config.toml"

 

 

3. .gitlab-ci.yml 작성 및 Pipeline 실행

 

GitLab 에서 생성된 프로젝트 최상위 디렉토리에 .gitlab-ci.yml 파일 (옵션에서 파일명 변경 가능) 을 생성하고 가장 심플한 내용으로 작성해 보도록 하겠습니다.

Build > Pipeline editor 메뉴에 가면 제공되는 기본 설정값으로 테스트를 해 볼 수도 있지만 모두 삭제하고 더 간단한 아래 내용으로 작성해 봅니다.

키보드로 글자를 입력할 때마다 Edit Box 위에서 자동으로 Pipeline syntax 체크가 이루어 지는것을 볼 수 있습니다.

그리고 이 파일에서 구성한 내용에 따라 Pipeline 이 실행될 예정입니다.

참고로, Pipeline 을 저장하면 설정한 Pipeline 이 자동 실행되고, 업로드 했던 소스 파일이 /home/gitlab-runner/builds/{runner ID}/0/{git 계정}/{프로젝트 이름} 디렉토리에서도 보이게 됩니다.

 

1) 간단한 Pipeline

stages:   - test test-job:    stage: test   script: echo "Running test"   tags:     - test

 

- test : stages: 는 일반적으로 build, test, deploy 의 명칭을 사용하지만 꼭 정해진 명칭은 없습니다.

           아래에 행을 추가해 여러개로 나열 할 수 있으며, 명칭은 하단 stage: 에 꼭 존재해야 합니다.

- test-job : 임의로 정한 작업이름이므로 작업 구분이 가능한 글자로 변경해도 됩니다.

- test : 맨 하단의 test 는 위에서 Project runner 를 생성할때 지정했던 tags 값 입니다.

           tags 는 특정 runner 를 선택하여 작업을 실행할 때 사용됩니다.

           tags 항목이 없다면 'Can run untagged jobs' 옵션이 허용된 모든 runner 가 실행 됩니다.

 

Pipeline 실행은 간단합니다.

해당 프로젝트에 파일을 push 하면 되는데, push 이후의 Pipeline 진행 상황은 'GitLat 프로젝트 > Build > Pipelines' 에서 확인이 가능합니다.

push 방법은 다른 포스팅을 참고해 주세요. (https://sysdocu.tistory.com/1892 에서 '3. 파일 업로드' 부분 참고)

 

설정 내용을 변경해 보겠습니다.

 

2) 다양한 작업의 Pipeline

stages:   - build   - test   - custom variables:   NAME: sysdocu task1:    stage: build   script: echo "Running first build" task2:    stage: build   script: echo "Running second build" task3:    stage: test   script: echo "Running test" task4:    stage: custom   script:     - echo "This is $NAME blog."     - echo "Welcome to server world."

 

- variables: 쉘스크립트나 PHP 등에서처럼 변수를 미리 정의합니다. 이는 하단에서 불러올 수 있습니다.

- stages 의 수는 3개이고, 실행될 작업은 4개인데, 이렇게 개수가 달라도 상관없습니다. stage 가 중복되어도 됩니다.

- script 의 행을 추가하면 하나의 작업에서 여러개의 동작을 실행할 수 있습니다.

- 기본적으로 설정된 각 stage 를 순차적으로 실행하며, 만약 어떤 stage 에서 실패하면 다음 stage 는 실행되지 않습니다.

 

3) 파일 복사

stages:   - copy copy_files:   stage: copy   script:     - mkdir -p destination/     - cp index.php destination/

 

파일 복사는 로컬 개발환경이 아닌 GitLab 프로젝트 내에서 이루어집니다.

GitLab 은 객체와 인덱스로 데이터를 저장하기 때문에, 서버에 원격접속하여 디렉토리 구조를 눈으로 확인할 수 없지만 웹페이지를 이용해 프로젝트에 접근을 하면 일반 파일시스템과 같은 구조로 디렉토리와 파일을 보여주고 있습니다.

그렇게 저장되어 있다고 가정하고, 디렉토리를 만드는 명령어나 복사 명령어를 수행 할 수 있습니다.

위 Pipeline 설정을 처리하기 위해 index.php 파일을 올려놓고 실행하면, destination 디렉토리에도 동일한 파일이 생성됩니다.

 

# find / -name destination
/home/gitlab-runner/builds/-aRx3myd6/0/root/sample/destination

 

# ll /home/gitlab-runner/builds/-aRx3myd6/0/root/sample/destination/index.php 
-rw-rw-r-- 1 gitlab-runner gitlab-runner 40 Feb 14 10:48 /home/gitlab-runner/builds/-aRx3myd6/0/root/sample/destination/index.php

* 참고 : 업로드 파일 확인

일반적으로 GitLab 에 올려진 데이터는 객체와 인덱스로 저장되어 있어 서버 내에서 사람의 눈으로 찾아볼 수 없는데, gitlab-runner 를 설치하고 Pipeline 을 설정하면, /home/gitlab-runner/builds/{runner ID}/0/{git 계정}/{프로젝트 이름} 디렉토리 내에 업로드 했던 디렉토리 및 파일 목록이 보여지게 됩니다.

추가로 확인된 내용은 아래와 같습니다.

- 이 디렉토리 내의 파일은 파일시스템에 보이는 사본이므로, 수동으로 수정한다고 해도 GitLab 웹페이지 실제 데이터에 반영되지 않습니다.

- script 내에 설정된 cp 명령이 실제로 사본 디렉토리에서 실행되었지만, GitLab 웹페이지에서 보이지 않는것과 같습니다.

- 프로젝트 디렉토리 (/home/gitlab-runner/builds/{runner ID}/0/{git 계정}/{프로젝트 이름}) 를 기준으로 명령이 실행됩니다.

- 때문에 cp 등의 시스템 명령어를 처리할 경우에도 디렉토리의 고유한 식별자 (runner ID : -aRx3myd6) 이름을 알 필요가 없습니다.

 

* 참고 : Cloud Foundry 명령 실행

본 참고 내용은 다른 포스팅과 연결하여 동작이 되는지 실험하였으므로 해당 사항이 없는 분은 건너 뛰어도 됩니다.

- 단일 서버에서 CF + korifi > GitLab > gitlab-runner 순서로 설치하였습니다.

- 포트 충돌을 방지하고자 korifi 는 80번 포트, GitLab 은 1000번 포트를 사용 하였습니다.

- gitlab-runner 계정이 cf 명령어를 관리자 권한으로 실행할 수 있도록 설정 하였습니다.

  # echo 'gitlab-runner ALL=(ALL:ALL) NOPASSWD:/usr/bin/cf' >> /etc/sudoers

 

자동 배포 테스트를 위해 아래와 같이 Pipeline 을 재구성 합니다.

stages:   - test test-job:   stage: test   script:     - sudo cf api https://localhost --skip-ssl-validation     - sudo cf auth cf-admin     - sudo cf target -o org1 -s space1     - sudo cf push php1   tags:     - test

 

push 이후에 아래와 같이 애플리케이션이 확인되었습니다. (사실, Pipeline 저장시 검증을 위해 한 번 실행하게 됨)

같은 이름 (php1) 으로 여러번 배포 해도 됩니다. 소스만 업데이트 하는 속도로 빠르게 배포되어 집니다.

# curl --insecure php1.apps-127-0-0-1.nip.io

Good job !!

Updated.

 

* 참고

script: 내용을 숨기고자 할때 쉘스크립트 파일을 준비하여 인자값으로 데이터를 넣어 실행하도록 하면 처리 내용을 숨길 수 있습니다.

 

4) 기타 설정

다른 방식으로도 Pipeline 구성이 가능합니다.

 

가독성을 높이기 위해 before_script, script, after_script 로 나누어 구조화된 방법으로 작업을 실행합니다.

이는 가독성을 높이고 특정 단계의 실패 시 빠르게 파악할 수 있도록 도움을 주는 것이지, 동작을 위해 필수적인 것은 아닙니다.

test-job:   before_script:     - echo "Welcome"   script:     - echo "to"   after_script:     - echo "sysdocu blog."

 

특정 branch 에서만 실행하도록 합니다.

test-job:   script:     - echo "good"   only:     - newbranch

 

특정 branch 만 제외하고 실행합니다.

test-job:   script:     - echo "good"   except:     - newbranch

 

자동으로 실행하지 않고 GitLab 웹페이지에서 수동으로 실행해줍니다.

test-job:   when: manual   script:     - echo "after work"