나는 이때까지 배포를 진행하면서 Github Actions를 활용해서 CI/CD 파이프라인을 구축해서 S3나 Cloudfront에 배포를 진행해왔다. 하지만, 보통 회사에서는 Github Actions는 무료가 아니고, AWS 의 EC2 와 같은 서버를 활용하는 것이 아니라 자체 서버를 활용하는 경우가 많다고 한다. 그래서 보통 이런 배포 환경을 구축할때 Jenkins 라는 친구를 많이 활용한다고 한다.
관련 영상을 찾다가 JJenkins를 활용한 CI/CD 1강 - 젠킨스(Jenkins) 이해 | T아카데미 라는 영상을 발견했고, 이 영상을 보면서 Jenkins 에 대해서 공부를 진행했다.
1. 기본 개념 및 목적
Jenkins?
- Java Runtime Environment 위에서 동작하는 오픈소스 자동화 서버이다.
CI/CD의 정의
- CI (Continuous Integration): 여러 개발자의 코드를 자동으로 통합하고 테스트하여 배포 가능한 상태를 유지하는 것.
- CD (Continuous Delivery/Deployment): 통합된 코드를 내부 사용자나 실제 서비스 환경에 지속적으로 전달 및 배포하는 과정.
핵심 가치
개발자가 코드 작성에만 집중할 수 있도록 "코드를 짜면 이미 서비스되고 있는 상태"인 자동화된 흐름을 만드는 것이 목적이다.
단순 배포를 넘어 QA, 프론트/백엔드 협업자에게 가치를 지속적으로 전달하는 협업 도구라고 볼 수 있다.
2. 플러그인
젠킨스는 수많은 플러그인을 통해 기능을 확장하며, 기본적으로 권장(Recommend) 플러그인만 설치해도 실무에 필요한 대부분의 기능을 갖출 수 있다.
대표적인 플러그인
Credentials Plugin
AWS 토큰, Git Access Token, SSH 키 등 배포에 필요한 민감한 정보를 안전하게 저장하고 관리한다.
Git Plugin
소스 코드 저장소(GitHub 등)와 연동하여 코드를 가져온다.
Pipeline (핵심 기능인 파이프라인 마저도 플러그인!)
Jenkins의 핵심 기능으로, 일련의 자동화 작업들을 코드로 정의할 수 있게 한다.
플러그인 살펴보기
1. Credentials Plugin
https://plugins.jenkins.io/credentials/
Jenkins는 그냥 단지 서버일 뿐이기 때문에 배포에 필요한 각종 리소스 (가령 클라우드 리소스 혹은 베어메탈에 ssh 접근 등)에 접근하기 위해서는 여러가지 중요 정보들을 저장하고 있어야한다.
이런 중요한 정보 (AWS token, Git access token, etc..) 들을 저장해주는 플러그인
2. Docker plugin and Docker Pipeline
Docker agent 를 사용하고 jenkins 에서 도커를 사용하기 위함
3. Pipeline
파이프라인은 CI/CD를 구현하기 위한 플러그인들의 집합이자 구성방식이다. UI 설정 방식이 아닌 코드로 관리 되므로 재사용과 이력 관리에 용이하다.
즉, 여러 플러그인들을 이 파이프라인에서 용도에 맞게 사용하고 정의함으로써 파이프라인을 통해 서비스가 배포된다.
Pipeline의 구조
Pipeline > Agent > Stages > Steps 순서로 구성된다.
- Agent: 작업을 수행할 주체(Slave Node, Docker 컨테이너 등)를 지정한다.
- Stages: 빌드, 테스트, 배포 등 논리적인 작업 단계를 정의한다.
- Steps: 각 Stage 안에서 실제로 실행할 최소 작업 단위이다. 플러그인 설치에 따라 사용할 수 있는 스텝(Git 클론, S3 업로드 등)이 확장된다.
Pipeline 을 구성하는 요소
Declarative Pipeline 과 Scripted Pipeline 이라는 두가지 형태의 Pipeline syntax가 존재한다.
Declaratives
Environment, stage, options, parameters, triggers, when 등의 Declarative 가 있다.
- Environment : 어떤 Pipeline 이나 stage scope 의 환경 변수 설정
- Parameter : 파이프라인 실행시 파라미터 받음
- Triggers : 어떤 형태로 트리거 되는가
- When : 언제 실행되는가
Pipline syntax
pipeline {
agent any
environment {
DEPLOY_TARGET = 'production'
}
triggers {
pollSCM('H/3 * * * *') // 3분마다 변경 사항 확인
}
stages {
stage('Prepare') {
steps {
// Git에서 브랜치 코드를 가져옴
git url: 'https://github.com/dobbymin/my-work.git',
branch: 'main',
credentialsId: 'jenkinsgit'
sh 'ls -al'
}
}
stage('Deploy to S3') {
steps {
dir('./docs') {
// AWS CLI를 사용해 S3 동기화
sh 'aws s3 sync ./ s3://jenkinstest'
}
}
post {
success {
echo 'S3 Deployment Successful'
}
}
}
stage('Only for Production') {
when {
branch 'production'
environment name: 'APP_ENV', value: 'prod'
}
steps {
echo 'Deploying to production environment...'
}
}
}
post {
always {
echo 'Pipeline execution finished.'
}
failure {
echo 'Pipeline failed. Please check the logs.'
}
}
}
Agent section
젠킨스는 많은 일들을 해야 하기 때문에 혼자하기 버겁다.
여러 slave node를 두고 일을 시킬 수 있는데, 이처럼 어떤 젠킨스가 일을 하게 될 것인지를 지정한다.
젠킨스 노드 관리에서 새로 노드를 띄우거나 혹은 docker 이미지 등을 통해서 처리할 수 있다.
Post section
스테이지가 끝난 이후의 결과에 따라서 후속 조치를 취할 수 있다.
ex) success, failure, always, cleanup
ex) 성공시에 성공 이메일, 실패하면 중단 혹은 건너뛰기 등등..
post {
// If Maven was able to run the Tests, even if some of the test
// failed, record the test result and archive the jar file.
success {
echo 'success'
}
}
Stages section
- 어떤 일들을 처리할 건지 일련의 stage를 정의함
Step section
-
한 스테이지 안에서의 단계로 일련의 스텝을 보여줌
-
steps 내부는 여러가지 스텝들로 구성되어 있음
-
여러 작업들 실행 가능
-
플러그인을 설치하면 사용할 수 있는 스텝들이 생겨남
-
플러그인별 스텝 종류들