1017 젠킨스(Jenkins): CI/CD 파이프라인 구축
✅ 1. Jenkins 지휘소 건설하기 (설치와 초기 설정)
-
문제점: 소스 코드를 수동으로 빌드, 테스트, 배포하는 작업은 반복적이고, 실수가 잦으며(Human Error), 배포까지 시간이 오래 걸립니다. 개발자가 코드 변경 후 피드백을 받기까지의 사이클이 깁니다.
-
해결책: Jenkins는 이러한 빌드, 테스트, 배포 과정을 자동화하는 대표적인 CI/CD (지속적 통합/지속적 배포) 서버입니다. Jenkins를 설치하여 모든 자동화 작업을 중앙에서 관리하는 "지휘소"를 구축합니다.
➕ 초기 설정 과정
- 설치: Java 기반이므로 JDK가 필요하지만, Docker를 사용하는 것이 가장 간편하고 표준적인 방법입니다.
# Jenkins LTS(Long-Term Support) 버전을 Docker로 실행 # 8080: Jenkins 웹 UI 포트, 50000: Agent 통신 포트 docker run -d -p 8080:8080 -p 50000:50000 --name jenkins jenkins/jenkins:lts - 초기 비밀번호 입력: 설치 후
http://[서버IP]:8080에 접속하면 초기 비밀번호를 요구합니다. Docker 로그에서initialAdminPassword를 찾아 복사하여 입력합니다.docker logs jenkins - 플러그인 설치: 'Install suggested plugins'를 선택하여 CI/CD에 필수적인 기본 플러그인(Git, Pipeline, Credentials 등)을 자동 설치합니다.
- 관리자 계정 생성: 초기 비밀번호 대신 사용할 관리자 계정(ID, PW)을 생성하면 Jenkins 지휘소 구축이 완료됩니다.
✅ 2. Jenkins에게 세상과 통하는 열쇠 주기 (Credentials)
-
문제점: Jenkins가 자동화를 수행하려면 GitHub에서 코드를 가져오거나(Clone), Docker Hub에 이미지를 푸시(Push)하거나, 원격 서버(EC2)에 SSH로 접속하여 배포해야 합니다. 이때 필요한 인증 정보(비밀번호, API 토큰, SSH Private Key)를 파이프라인 스크립트에 직접 작성(하드코딩)하는 것은 심각한 보안 문제입니다.
-
해결책: Jenkins의 Credentials 기능을 사용하여 모든 민감한 정보를 암호화하여 안전하게 저장합니다. Jenkins는 이 정보를 직접 노출하는 대신, 고유한 ID를 발급합니다.
-
위치:
Jenkins 관리>Credentials(v2.x 이후Manage Jenkins>Security>Credentials)
| Credentials 유형 | 목적 | 사용 사례 |
|---|---|---|
| Username with password | ID/PW 인증 | • GitHub, GitLab, Docker Hub 로그인 |
| SSH Username with private key | SSH Key 기반 인증 | • 배포 대상 EC2 서버 접속 |
| Secret text | API 토큰/키 | • AWS API Key, Slack 알림 토큰 |
- 파이프라인에서는 이 Credentials의 ID만 호출하면, Jenkins가 실행 시점에 실제 암호화된 값을 주입해줍니다.
✅ 3. 첫 번째 자동화, Freestyle 프로젝트 맛보기
-
문제점: Jenkins의 기본 기능이나 간단한 자동화 작업을 빠르게 테스트해보고 싶습니다. (예: 특정 Git 브랜치가 변경되면 자동으로 빌드만 수행)
-
해결책: Freestyle Project는 Jenkins 웹 UI의 그래픽 인터페이스(GUI)를 통해 클릭 몇 번으로 CI/CD 작업을 구성할 수 있는 가장 전통적이고 간단한 방법입니다.
➕ Freestyle 프로젝트 핵심 구성
- Source Code Management (SCM): 자동화할 소스 코드의 위치를 지정합니다.
Git선택, Repository URL 입력- (Private 저장소일 경우)
Credentials항목에서 이전에 등록한 GitHub용 Credentials ID를 선택합니다.
- Build Triggers: 이 자동화를 언제 시작할지 정의합니다.
Poll SCM: Git 저장소에 변경 사항이 있는지 주기적으로 검사 (예: 5분마다)Build periodically: 특정 시간마다 실행 (Cron 스케줄링)GitHub hook trigger for GITScm polling: (권장) GitHub Webhook을 통해 Push 이벤트가 발생할 때만 즉시 실행.
- Build: 무엇을 실행할지 실제 명령어를 정의합니다.
Execute shell선택 (예:npm install,mvn clean package,echo "Build Complete")
- Post-build Actions: 빌드 완료 후 수행할 작업을 정의합니다. (예: 이메일 알림, Slack 알림)
- 한계: UI 기반이라 복잡한 배포(Dev/Staging/Prod) 흐름, 조건부 실행, 병렬 처리 등을 구성하기 어렵고, 자동화 설정 변경 이력을 추적하기 어렵습니다.
✅ 4. 진정한 자동화, Jenkinsfile 파이프라인
-
문제점: Freestyle 프로젝트는 CI/CD 설정이 Jenkins 서버에만 저장되어 백업/관리가 어렵고, 복잡한 파이프라인(예: 빌드 -> 테스트 -> 승인 대기 -> 배포)을 구현하기 어렵습니다.
-
해결책: Pipeline 프로젝트를 사용합니다. CI/CD의 모든 단계를
Jenkinsfile이라는 스크립트 파일에 코드로 정의(Pipeline as Code)하고, 이 파일을 소스 코드와 함께 Git 저장소에서 관리합니다. -
Jenkinsfile(Declarative Pipeline): Groovy 언어 기반의 스크립트로, CI/CD의 청사진 역할을 합니다.
➕ Jenkinsfile 기본 구조
pipeline {
agent any // 이 파이프라인을 실행할 작업 환경 (어디서든 실행)
stages {
// 1. 빌드 단계
stage('Build') {
steps {
// 실제 실행할 명령어
sh 'npm install'
sh 'npm run build'
}
}
// 2. 테스트 단계
stage('Test') {
steps {
sh 'npm test'
}
}
// 3. 배포 단계
stage('Deploy') {
steps {
// (예시) SSH로 배포 서버에 접속하여 스크립트 실행
// 'my-server-ssh'는 Credentials에 등록한 ID
withCredentials([sshUserPrivateKey(credentialsId: 'my-server-ssh', keyFileVariable: 'SSH_KEY')]) {
sh 'ssh -i $SSH_KEY user@deploy-server.com /path/to/deploy.sh'
}
}
}
}
}- 작동 방식: Jenkins에서 'Pipeline' 유형의 프로젝트를 생성하고, SCM 설정에서 "Pipeline script from SCM"을 선택한 뒤 Git 저장소와
Jenkinsfile의 경로만 지정해주면 됩니다. Jenkins가 코드를 받아와서Jenkinsfile의 내용을 읽고 그대로 실행합니다. - 핵심 장점:
- Pipeline as Code: CI/CD 설정을 코드로 관리하므로 Git을 통해 버전 관리, 추적, 코드 리뷰가 가능합니다.
- 복잡성/유연성: 조건부 실행(
when), 병렬 처리(parallel), 승인(input) 등 복잡한 워크플로우를 자유롭게 구현할 수 있습니다.
📌 요약
- Jenkins는 빌드/테스트/배포를 자동화하는 CI/CD 서버이며, Docker를 통해 쉽게 설치할 수 있습니다.
- Credentials는 GitHub 비밀번호, SSH 키 등 민감한 정보를 Jenkins에 암호화하여 안전하게 저장하고, 파이프라인에서 고유 ID로 참조하는 핵심 보안 기능입니다.
- Freestyle Project는 UI를 통해 간단한 자동화 작업을 빠르게 구성하는 방법입니다.
- **Pipeline (Jenkinsfile)**은 CI/CD의 모든 절차를 **코드로 정의(Pipeline as Code)**하는 현대적인 방식입니다.
Jenkinsfile을 소스 코드와 함께 Git으로 관리하여, 복잡하고 안정적인 파이프라인을 구축할 수 있습니다.
