젠킨스(Jenkins)
- 소프트웨어 개발 시 지속적으로 통합 서비스를 제공하는 툴(CI)
- 다수의 개발자들이 하나의 프로그램을 개발할 때 버전 충돌을 방지하기 위해 각자 작업한 내용을 공유영역에 있는 저장소에 빈번히 업로드함으로써 지속적인 통합 가능(CD)
CI(Continuous Integration)
- 여러 개발자들이 코드를 계속해서 통합
CD(Continuous Delivery)
- 개발자들이 코드를 계속 작성하면, 사용자 및 내부 사용자들이 계속 쓸 수 있게 만드는 것
- 지속적으로 배포 가능한 상태를 유지
과거 배포 방식
- 코드 저장소에 코드 PUSH
- 로컬 환경에서 프로젝트 BUILD
- 빌드 파일을 서버에 UPLOAD
- 배포 스크립트를 통해 DEPLOY
과거 배포 방식 단점
- 반복되는 위의 과정(PUSH, BUILD, UPLOAD, DEPLOY)으로 인해 발생하는 불필요한 시간 낭비
- 배포 진행 현황, 배포 시기, 배포 관련 시기 관리 불편
젠킨스 장점
- 코드 변경을 감지하고, 자동화 테스트 수행
CI/CD pipeline 흐름
1. 소스코드를 소스 코드 저장소(github, gitlab)에 PUSH
2. 소스 코드 저장소(github, gitlab)의 WebHook를 통해 Jenkins에 해당 소스 코드 전송
3. Jenkins에서 해당 코드를 테스트, 컨테이너 빌드 등의 배포 관련 과정 수행
4. 해당 서버에 Docker image를 생성 및 컨테이너화
Jenkins의 Item
- 젠킨스에서 하나의 CI/CD 프로젝트를 구축하기 위해서는 아이템을 생성해야함
- 하나의 젠킨스 서버에 다수의 아이템을 만들 수 있고, 각 아이템들은 개발자의 설정에 따라 다르게 동작
- 아이템을 만드는 방식은 대표적으로 2가지(FreeStyle, Pipeline)
FreeStyle
- 웹 기반의 GUI를 통해 여러 플러그인을 쉽게 사용 가능
- CI 파이프라인에 변경 사항을 만들기 위해서는 젠킨스에 접속해서 해당 아이템의 설정을 변경해야 함
Pipeline
- CI/CD 파이프라인 설정을 하나의 스크립트 파일(Jenkinsfile)을 통해 관리할 수 있음
- FreeStyle과 다르게 하나의 스크립트 파일(Jenkinsfile)을 통해 흐름 제어 가능
- GUI를 통해 현재 어떤 과정을 진행 중이고, 평균적으로 얼만큼의 시간이 걸렸는지 통계를 확인 가능
Pipeline script
Declarative vs Scripted Pipeline
- Jenkinsfile은 두 현태의 구분을 사용하여 사용됨
1. Declarative: 쉽게 작성 가능, Groovy를 몰라도 사용 가능
2. Scripted: Groovy 기반, Declarative보다 효율적으로 많은 기능 포함, Groovy를 잘 알아야 함
Pipeline 문법
1. pipeline{..}
- 해당 틀안에서 파이프라인을 사용하겠다는 선언
pipeline {
}2. section
2-1. agent
- 파이프라인 블록 내 최상단에 정의
- agent값을 무엇으로 주는지(any, none...)에 따라 agent를 파이프라인 전체(any)에 쓸 수 있는지, 특정 stage(none)에 쓸 수 있는지 지정
2-2. stage
- pipeline은 하나 이상의 stage를 포함해야 하는데, 각 stage는 보통 진행해야 할 일들을 단위로 잘라서 선언
stage('stage명') {
steps{
할 일
}
}2-3. steps
- stage 내부 block에서 여러 번 호출 가능
stage('stage명') {
steps{
steps{
할 일
}
할 일
}
}
2-4. post
- 특정 스테이지 이전/이후에 실행될 condition 블록
- 특정 단계가 끝나고 할 일 또는 log 남기기 등에 사용됨
- 특정 단계가 어떤 상태인지에 따라 실행문 구분
post{
always {
echo '항상 실행되는 문'
}
changed {
}
failure{
}
success{
}
}
3. Directives
- 파이프라인의 config 결정값
3-1. environment
- 파이프라인 혹은 스테이지 내부에서 쓰일 변수값을 정의
environment {
GIT_URL = "https://github.com/@@@.git"
}3-2. tool
- 자동 설치나 Path에 추가할 도구를 정의
tool{
NodeJS 'Nodejs-bell'
}3-3. parameter
# 선언
parameters {
booleanParam(containername: 'hello', type: 'container')
}
# 사용
script {
if (params.containername=='hello') {
echo 'test'
}
}4. if문
- when, steps
when {
조건문
}
steps {
조건이 맞으면 실행할 내용
}- if문을 사용하기 위해서는 script로 감싸줘야 함
script { // if문 쓰기 위해 선언
if (조건문) {
조건이 맞으면 실행할 내용
}
}
Declartive pipeline 구성도
Pipeline script from SCM 설정 과정
- Jenkinsfile
pipeline {
agent any
environment {
DOCKER = 'sudo docker'
}
stages {
stage('Clone Repository') {
steps {
checkout scm
echo 'Checkout Scm'
}
}
stage('Build image') {
steps {
sh 'ls -al'
dir('back/beauduck-auth'){
sh 'ls -al'
sh 'chmod +x ./gradlew'
sh './gradlew build'
sh 'docker build -t feat-back-auth .'
}
echo 'Build image...'
}
}
stage('Remove Previous image') {
steps {
script {
try {
sh 'docker stop feat-back-auth'
sh 'docker rm feat-back-auth'
} catch (e) {
echo 'fail to stop and remove container'
}
}
}
}
stage('Run New image') {
steps {
sh 'docker run --name feat-back-auth -d -p 8080:8080 feat-back-auth'
echo 'Run New image'
}
}
}
}
Webhook 등록
- 위의 과정을 통해 Jenkins에서 CI/CD 작업을 하는 FreeStyle/Pipeline 이라는 item을 만듬
- 위 작업 내용을 실행하려면, Jenkins에서 직접 수동으로 빌드해서 실행해야 함
- Github/Gitlab의 Webhook을 통해, CI/CD가 자동으로 동작한 개발 환경 구축 가능
