LostCatBox

Gitlab-CI/CD 구축하기(withSpring)

Word count: 1.3kReading time: 8 min
2023/02/23 Share

gitlab CICD 구축

Created Time: February 21, 2023 3:12 PM
Last Edited Time: February 23, 2023 8:37 PM
Status: In progress

참고

왜?

회사에서 svn → gitlab으로 옮기는 과정을 거친후

jenkins를 모두 각자 쓰는 것보다 gitlab으로 한번에 CI/CD를 구축하는것이 어떻냐는 제안에 수긍하였고, 환경을 구축하게되었다.

다른 서버 개발자와 클라이언트 개발자 등 다양한 환경에서 협업하면, 지속적인 코드 수정이 이뤄지며, 지속적인 통합, 지속적인 배포가 반드시 필요하니까!

예시기준

  • GitLab Community Edition 14.2.1
  • 프로젝트: spring 4.3
  • 사내 프레임워크

사전지식

전체 워크 플로우

Untitled

GitLab runner 컨셉

Untitled 1

초기 구성도

  • gitlab 및 gitlab-runner는 다음과같이 각 jobs가 필요한 서버당 runner한대 등록한다.

Untitled

실 서버 구성도

  • 추후 수정된 구성도
  • 사유: gitlab-runner 의 인증서 관리 편의 및 보안 이슈

Untitled

간단 용어 정리

Pipelines

파이프라인은 지속적 통합, 전달 및 배포의 최상위 구성 요소입니다.

Job은 runner에 의해 실행됩니다. 동시(concurrent) 러너가 충분한 경우, 동일한 단계의 여러 Job이 병렬로 실행됩니다.

한 단계의 모든 Job이 성공하면, 파이프라인은 다음 단계로 넘어갑니다.

Jobs

파이프라인 구성은 Job으로 시작됩니다.

Job은 .gitlab-ci.yml파일의 가장 기본적인 요소

Job은 Runner가 실행해야 하는 명령 모음

Job은 :

  • 어떤 조건에서 실행되어야 하는지를 명시하는 제약 조건으로 정의됩니다.
  • 임의의 이름을 가진 최상위 요소이며 최소한 script 절을 포함해야 합니다.
  • 정의할 수 있는 수에는 제한이 없습니다.
1
2
3
4
5
job1:
script: "execute-script-for-job1"

job2:
script: "execute-script-for-job2"

각 Job이 서로 다른 명령을 실행하는 두 개의 개별 Job이 있는 가장 간단한 CI/CD 구성입니다

Variables

CI/CD 변수는 환경 변수의 한 유형

  • Jobs 및 파이프라인의 동작을 제어
  • 재사용하려는 값을 저장
  • .gitlab-ci.yml 파일에 값을 하드 코딩하는 것을 방지

Environments

환경은 코드가 배포되는 위치를 설명합니다.

Runners

GitLab CI/CD에서 러너는 .gitlab-ci.yml에 정의된 코드를 실행합니다. 러너는 GitLab CI/CD의 코디네이터 API를 통해 CI Job을 선택하고, Job을 실행한 다음, 결과를 GitLab 인스턴스로 다시 보내는 경량의 확장성이 뛰어난 에이전트입니다.

GitLab UI에는 액세스 할 사용자에 따라 세 가지 유형의 러너가 있습니다.

  • 공유 러너(Shared runners)는 GitLab 인스턴스의 모든 그룹 및 프로젝트에서 사용할 수 있습니다.
  • 그룹 러너(Group runners)는 그룹의 모든 프로젝트와 하위 그룹에서 사용할 수 있습니다.
  • 특정 러너(Specific runners)는 특정 프로젝트와 연결됩니다. 일반적으로 특정 러너는 한 번에 하나의 프로젝트에 사용됩니다.

설치 및 설정

여기서부터는 구조도와 환경에 따라 차이가 발생할수있다.

runner 설치

  • gitlab에 있는 서버에 직접 설치
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash
$ yum install gitlab-runner
$ chmod +x /usr/local/bin/gitlab-runner
$ systemctl status gitlab-runner

# root 유저로 설치
$ gitlab-runner install --user=root --working-directory=/home/gitlab-runner

# 만약 install 명령시 이미 실행중이라고 뜬다면 service 파일에서 사용자를 직접 수정
$ cd /etc/systemd/system
$ vi gitlab-runner.service

ExecStart=/usr/bin/gitlab-runner .... "--user" "root"

# gitlab-runner 서비스 재시작
$ systemctl daemon-reload
$ systemctl restart gitlab-runner

runner 등록

  • gitlab의 push를 감지하고 event가 일어나면 입력해놓은 커맨드를 실행하는 것을 runner라고 한다
  • 한 서버에 여러개의 runner를 등록 할 수도 있다
  • 서버주소와 토큰은 Gitlab > project > Settings > CI/CD > Runners에서 확인 가능하다
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ gitlab-runner register

# 1. gitlab 서버주소 (gitlab project runner에서 확인)
https://gitlab.com/

# 2. token (gitlab project runner에서 확인)
yboVk-t_P.......So

# 3. descrption - name 설정
dev-runner

# 4. tag (매우중요!!) - gitlab-ci.yml에서 해당 tag를 참조하여 실행함
dev-runner

# 5. executor
shell

4번의 태그는 gitlab-ci.yml에서의 tag와 일치해야한다.

gitlab-ci.yml(CI/CD 파일설정)

  • 하위로 먼저 테스트해보기
  • 이스케이프(#,: 등등 필요 시) ⇒전체를 '' 로 묶음
    이때 변수 사용 시 "" 로 반드시 변수를 묶어줘야한다.
    (예시: "${DEV_PROJECT_DIR}")
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
stages:
- test
- build
- deploy
unit-test:
stage: test
tags: # runner tags와 매칭
- dev-runner
only:
- dev # dev branch만!
script: echo 'Testing...'
unity-build:
stage: build
tags: # runner tags와 매칭
- dev-runner
only:
- dev # dev branch만!
script: echo 'Building...'
playstore:
stage: deploy
tags: # runner tags와 매칭
- dev-runner
only:
- dev # dev branch만!
script: echo 'Deploying...'
  • gitlab-runner 프로젝트 서버 내부에있을경우
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
stages:
- build
- test
- deploy

build-project:
stage: build
tags:
- dev-runner
except:
- dev
variables:
PROJECT_PATH: '/app/projectname'
script:
- cd ${PROJECT_PATH}
- mvn package

deploy-to-dev:
stage: deploy
tags: # runner tags와 매칭
- dev-runner
only:
- dev
variables:
PROJECT_PATH: '/app/projectname'
script:
- sh ${PROJECT_PATH}/tomcat8.0.52/bin/shutdown.sh
- echo "tomcat shutdown..."
- sleep 2

- 'rm -rf /app/projectname/tomcat8.0.52/webapps/ROOT'
- echo "removing past ROOT.war success"
- sleep 2

- cp ${PROJECT_PATH}/target/ROOT.war ${PROJECT_PATH}/tomcat8.0.52/webapps/
- sh ${PROJECT_PATH}/tomcat8.0.52/bin/startup.sh
- echo "Finish..!"
  • gitlab-runner 프로젝트 외부에 존재하여 ip접속시 scp, ssh 원격 접속
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
stages:
- build
- deploy

build-project:
stage: build
tags:
- dev-runner
variables:
GIT_STRATEGY: clone
GIT_CHECKOUT: dev
only:
- dev
script:
- pwd
- mvn build

deploy-to-dev:
stage: deploy
tags:
- dev-runner
only:
- dev
variables:
GIT_STRATEGY: none
PROJECT_PATH: '/app/projectname'
script:
- echo $CI_PROJECT_DIR
- echo "Start Deploy.."
- ssh [id]@[ip] ${DEV_PROJECT_DIR}/tomcat8.0.52/bin/shutdown.sh
- echo "tomcat shutdown..."
- ssh [id]@[ip] "rm -rf ${DEV_PROJECT_DIR}/tomcat8.0.52/webapps/ROOT.war"
- scp ${CI_PROJECT_DIR}/target/ROOT.war [id]@[ip]:${DEV_PROJECT_DIR}/tomcat8.0.52/webapps
- ssh [id]@[ip] ${DEV_PROJECT_DIR}/tomcat8.0.52/bin/startup.sh
- echo "Finish Deploy"

gitlab-runner 관련 정보

GIT_STRATEGY

  • clone
    • 해당 job때, clone을 실행하여, worktree이전에 작업내용 다 날리고,
      항상 깨끗한 local working 유지
  • fetch(default)
    • 해당 job때, git clean 실행하여 undo any changes하고, 그리고 git fetch 한다.
  • nono
    • 아무것도 하지않는다. 따라서 이전에 했던 job파일들이 로컬에 그대로 남아있다.

GIT_CLEAN_FLAGS

  • 각각의 CI job에 대해 git clean 에 대한 동의 여부
  • none: git clean 비활성화

에러

unable to access : problem with the SSL

참조

https://docs.gitlab.com/runner/configuration/tls-self-signed.html

문제

Gitlab Runner > Runner 등록하기(Ofiicial Documentation)

gitlab-runner 등록시 해당 https:// 로 접근시, ssl인증서가 필요할텐데,

기존 로컬 10.0.1.X로 접속할 때는 ssl인증서가 필요 없었지만,

gitlab runner 는 등록 시 https:// 활용 따라서 ssl problem이 발생하였다.

해결

Self-signed certificate

이 방법은 인증 기관을 거치지 않고 SSL 인증을 하여 GitLab Runner 를 등록하는 방법이다.

필요 사항

GitLab 서버에서

OpenSSL을 이용해 인증서를 만든다. 주의할 점은 Common Name(CN)에 gitlab.com 도메인 혹은 192.168.12.23 IP 주소를 입력해야 한다.

자세한 사항은 IBM OpenSSL 문서 참조

1
2
3
4
5
6
7
$ cd /etc/gitlab/ssl/
$ openssl genrsa -out ./gitlab.key 2048
$ openssl req -new -key gitlab.key -out gitlab.csr
$ openssl x509 -req -days 1000 -in gitlab.csr -signkey gitlab.key -out gitlab.crt
$ cp gitlab.crt gitlab.pem

$ sudo gitlab-ctl restart

GitLab Runner 서버에서

GitLab Runner 에서는 앞서 생성한 gitlab.pem 인증서를 사용한다. 앞서 생성된 gitlab.pem 파일을 /etc/ssl/certs 에 복사한다. 그리고 gitlab.pem 의 데이터를 ca-certificates.crt 마지막 줄에 삽입하면 인증 기관을 거치지 않아도 GitLab Runner를 등록할 수 있다.

1
2
$ cd /etc/ssl/certs
$ cat gitlab.pem >> ca-certificates.crt

Register

프로젝트의 Settings > CI/CD > Runners settings 에서 URL과 registration token을 확인한다.

gitlab-runner register 명령어를 이용해 URL과 registration token을 차례로 입력한 후 runner 이름과 실행 방법을 선택하면 등록 완료.

인증서란?

pem, crt, csr 형식파일
pem: 주로 인증서나 개인키를 담고있다.
****crt: 인증서를 의미, 보통 pem형식의 인증서를 의미
csr: 인증기관(CA)에 인증서 발급 요청을 하는 형식의 파일이며, 그안에는 내 공개키 정보와 사용하는 알고리즘 정보들이있다.

인증서 특징

  • public key에 대한 sign 파일
  • private key로 서명요청파일(CSR)을 생성하여 인증서 생성시 public키가 포함된 인증서 파일이 생성됨
  • 해당 public키를 이용하여 통신을 하며 해당 키가 정상적인 public key인지 인증할수있다.
  • 이 public key에 대한 보증하는 단체 CA임
  • 인증기관없이 자기 자신을 인증된 것을 self sign 인증서

인증서 생성 순서

  1. 개인키(Private Key) 생성
  2. 서명 요청 파일(CSR) 파일생성
  3. 인증서 생성

fatal: git fetch-pack: expected shallow list

해당 서버에서 gitlab-runner에서 git version 낮아서 발생

git —version 확인후 update 진행

CATALOG
  1. 1. gitlab CICD 구축
  2. 2. 참고
  3. 3. 왜?
  4. 4. 예시기준
  5. 5. 사전지식
    1. 5.1. 전체 워크 플로우
    2. 5.2. GitLab runner 컨셉
    3. 5.3. 초기 구성도
    4. 5.4. 실 서버 구성도
    5. 5.5. 간단 용어 정리
      1. 5.5.1. Pipelines
    6. 5.6. Jobs
      1. 5.6.1. Variables
      2. 5.6.2. Environments
      3. 5.6.3. Runners
  6. 6. 설치 및 설정
    1. 6.1. runner 설치
    2. 6.2. runner 등록
  7. 7. gitlab-ci.yml(CI/CD 파일설정)
  8. 8. gitlab-runner 관련 정보
    1. 8.1. GIT_STRATEGY
    2. 8.2. GIT_CLEAN_FLAGS
  9. 9. 에러
    1. 9.1. unable to access : problem with the SSL
      1. 9.1.1. 참조
      2. 9.1.2. 문제
      3. 9.1.3. 해결
      4. 9.1.4. 인증서란?
    2. 9.2. fatal: git fetch-pack: expected shallow list