CI/CD 구축 - Jenkins 환경 구성, 파이프라인 구성

CI/CD 란?

CI/CD (Continuous Integration/Continuous Delivery)는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법

 

CI는 지속적인 통합이며, 새로운 변경 사항이 정기적으로 빌드, 테스트 되어 공유 레포지토리(GitHub)에 통합하는 것

서비스와 프로젝트가 잘게 나뉘어져 있는 MSA환경에서 빌드 및 테스트가 늘어나므로 효과가 좋다.

 

빌드를 하는데 드는 프로그래머의 수작업을 줄이는 것이 핵심이다.

 

CD는 지속적인 배포이며, 정기적으로 개발자의 변경 사항이 client 단에 제공 되는 것. 즉, 릴리즈 되는 것을 의미한다.

쿠버네티스를 이용한다면..? CI이후 외부에 External IP로 노출되는 ingress, nodeport 작업만 완료해준다면 그것이 CD가 될 듯 하다. 

혹은 쿠버네티스에 apply하여 파드나 워크로드 리소스를 띄우는 것 자체가 CD 일 수도 있다.

 

아무튼.

 

환경구성

1) jenkins를 설치할 서버, 클라우드 사용

GCP에서  서버 인스턴스를 하나 생성하고, 원활한 jenkins UI이용과 이후 작업할 Web Hook을 위해 외부 접속 용 고정 IP를 할당한다.

 

물론 jenkins 환경은 로컬도 가능하지만, 젠킨스 CI 속도 꼬라지를 보아하니 따로 서버 컴퓨터가 필요할 것 같다.

 

 

2) jenkins 설치 후 접속

jenkins 어플리케이션을 서버 환경에 직접 설치하는 것은 꽤나 귀찮은 과정을 동반한다.

 

따라서, 컨테이너 이미지를 통해 설치한다.

# GCP의 고정 IP를 통한 ssh 연결

ssh -i ~/.ssh/jenkins-key choiyt3465@23.11.66.51

# Jenkins 컨테이너 사용을 위한 Docker 설치
# apt update가 권장됨

sudo apt update
sudo apt install docker

# Jenkins 컨테이너 생성
# jenkins_home은 mkdir을 통해 생성

sudo docker run --name jenkins -d -p 8888:8080 -p 50000:50000 \
-v /home/choiyt3465/jenkins:/var/jenkins_home \
-v /var/run/docker.sock:/var/run/docker.sock \
-u root jenkins/jenkins:latest

 

3) jenkins 내 쿠버네티스 환경 구성

# Jenkins 컨테이너 실행 후, 컨테이너 안에(Bash) 도커 설치

docker exec -it jenkins-docker bash
curl https://get.docker.com/ > dockerinstall && chmod 777 dockerinstall && ./dockerinstall
apt install docker-compose​

# 컨테이너 안에(Bash) kubectl 설치

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x kubectl
mv kubectl /usr/local/bin/

jenkins 배포 파이프라인 구성

1) CI/CD 시나리오

Githube repository에서 git push가 일어날 때 도커 이미지 생성과 동시에 빌드 후 repository 등록, 미리 세팅된 Kubenetes config를 적용하고, 구성요소를 repository 통해 이미지를 가져온다. 이후 이미지 안의 구성요소 yaml파일을 통해 컨테이너 실행(배포) 

 

이로 인한 이점은, 변경사항이 일어날 때 배포 서버에서 일일이 git pull, build ./gradlew, java -jar ~.jar 등의 CLI 작업을 해줄 필요가 없다는 것이다.

 

2) credential 구성

파이프라인에는 환경변수도 정의할 수 있는데, 환경변수의 출처를 credential로 정의할 수 있다. 

 

젠킨스 메인 페이지에서 Jenkins관리 -> Credentials를 클릭한다

Jenkins Page

 

Domain 범위에 한해서 credential을 정의할 수 있는데, 전범위에 해당하는 global 도메인으로 해본다.

 

global 옆에 꺾새를 누르면 Add Credential로 진행할 수 있다.

Global Scope Credentials

Add Credential

Credential Kind

 

 

다양한 용도로 쓰이는 것 같다.

 

Username with password는 git login 할 때 쓰인다. 그런데 이걸 활용하는 것 같진 않다.

(username : 0-tae, password. : Git-Hub Token)

 

Secret file은 환경변수로 파일을 설정할 수 있게 해준다. 정확히는 젠킨스의 Secret file의 경로가 저장되어 있는 듯 하다.

 

Secret text는 단순한 key/value 형태의 값이다. 여기서 Value는 password 형식의 String이다.

 

파이프라인에 사용되는 Credentials

나중에 환경변수에 대입해서 파이프라인 수행 시 중요하게 쓰일 것이다.

 

3) 파이프라인 구성

새 PipeLine 생성

새 파이프라인을 작성하려면 다음과 같은 페이지가 나온다.

 

파이프라인 설정

 

깃허브 레포지토리와 훅 트리거(push 감지)를 체크 해준다.

 

SCM에 깃 레포지토리 등록

스크립트를 SCM(Supply Chain Management)에서 가져온다.

 

파이프라인과 깃 레포지토리 등록.. 아마 레포지토리 내의 파이프라인 스크립트 파일을 실행하기 위해 존재하는 듯하다.

빌드 대상의 브랜치

빌드 대상의 브랜치를 명시한다.

 

프로젝트 내의 Jenkinsfile

/Users/0tae1/IdeaProjects/LB_Assignment-2(내 로컬)

 

아마 기준이 되는 path는 git init이 되어있는 곳으로 보인다.

따라서, 해당 위치의 Jenkinsfile이라는 파일을 기준으로 Jenkins PipeLine을 수행한다.

 

Jenkinsfile은 파이프라인의 스크립트인데, 다음 글에서 살펴보자.