젠킨스 교육 정리 한마당..

아래의 그림이 내가 이틀간 진행한 실습의 요약본이다…

실습은 Jenkins를 이용한 Spring Boot 애플리케이션의 CI/CD(Continuous Integration / Continuous Deployment) 환경을 AWS에서 구축해 보는 과정이었다.

먼저 AWS에서 EC2 인스턴스(AWS 제공 가상 서버 서비스)를 두 대 생성했다. 하나는 Jenkins 서버 용도이고, 다른 하나는 실제 Spring Boot 애플리케이션이 실행될 서버 용도이다. 외부에서 안정적으로 접근하기 위해 두 서버 모두 탄력적 IP(Elastic IP)를 연결하였다. 탄력적 IP는 AWS에서 제공하는 고정 공인 IP로, 인스턴스를 재시작해도 IP가 변경되지 않기 때문에 Jenkins, GitHub Webhook, SSH 연결 등에 활용할 수 있다.

Jenkins 서버에는 Docker를 이용하여 Jenkins를 실행하였다. Jenkins는 CI/CD 도구로서 GitHub 저장소의 코드를 가져오고(Build), Maven을 이용해 Spring Boot 프로젝트를 빌드한 후 생성된 JAR 파일을 배포 서버로 전달하는 역할을 담당한다.

개발자는 VS Code에서 코드를 작성한 후 GitHub 저장소에 Commit 및 Push를 수행한다. GitHub에는 Webhook이 설정되어 있어 Push 이벤트가 발생하면 Jenkins 서버에 이를 즉시 알린다. Jenkins는 Webhook 요청을 수신하면 자동으로 빌드 파이프라인을 실행한다.

빌드 과정에서는 먼저 GitHub 저장소를 Checkout하여 최신 소스 코드를 가져온 뒤 Maven Build를 수행한다. Maven은 프로젝트의 의존성을 관리하고 컴파일을 수행하며, 최종적으로 실행 가능한 Spring Boot JAR 파일을 생성한다.

빌드가 완료되면 Jenkins는 생성된 JAR 파일과 Dockerfile을 SSH/SCP를 이용해 Spring Server로 전송한다. 이후 Jenkins는 SSH를 통해 Spring Server에 원격 접속하여 Docker 명령어를 실행한다. 이 과정에서 기존 컨테이너를 제거하고 새로운 Docker 이미지를 생성한 뒤 새로운 컨테이너를 실행한다.

Docker를 사용하는 이유는 실행 환경을 표준화하기 위해서이다. 개발 PC와 서버의 Java 버전이나 운영체제 환경이 달라도 Docker 이미지를 사용하면 항상 동일한 환경에서 애플리케이션을 실행할 수 있다. 따라서 “내 컴퓨터에서는 되는데 서버에서는 안 된다”와 같은 문제를 크게 줄일 수 있다.

전체적인 자동화 흐름은 다음과 같다.

즉, 개발자가 코드를 Push하는 것만으로도 빌드와 배포가 자동으로 수행되는 CI/CD 환경을 구축한 것이다.

cf. SSH(Secure Shell)
원격 서버에 안전하게 접속하기 위한 프로토콜
ssh ec2-user@13.125.189.5
실행 시

내 PC
    ↓ SSH
AWS EC2

구조로 연결되어 마치 그 서버 앞에 앉아있는 것처럼 명령어를 실행할 수 있다.

- Jenkins가 GitHub와 SSH 통신
- Jenkins가 Spring 서버와 SSH/SCP 통신

cf2. SCP
SSH를 이용해서 파일을 복사하는 기능

ex. 젠킨스가 빌드한 jar 파일을 스프링 서버로 보내기

scp app.jar ec2-user@13.125.189.5:/home/ec2-user/deploy

cf3.
파일 전송
Jenkins
  app.jar
      ↓
      SCP
      ↓
Spring Server
——————
원격명령어 실행
Jenkins
      ↓ SSH
Spring Server

docker build
docker run

cf4. 웹훅 없이도 젠킨스 설정을 통해 깃허브 변경을 알 수 있다.

Jenkins Job 설정에 Git Repository URL에 git@github.com:user/project.git 같은걸 넣어둔다.

Jenkins에서 빌드를 시작하면

git fetch
git checkout
작업을 실행해서 변경을 알아온다

시간 설정으로도 가능하다
젠킨스 설정에서 Poll SCM을 H/5 * * * * 같은것으로 해두면

5분마다 GitHub 확인
↓
변경 있으면 빌드
↓
변경 없으면 종료
루틴을 반복하게 된다

cf5. Poll SCM vs Webhook

<Poll SVM>
Jenkins → GitHub

"변경됐어?"
"변경됐어?"
"변경됐어?"

<Webhook>
GitHub → Jenkins

"야 변경됐어!"

서버 자원을 덜 쓰고 반응도 즉시 일어나기 때문에 웹훅을 많이 쓰는 것

cf6. GitHub Webhook 종류도 당연히 여러개 있음

Push
Pull Request
Issue
Release
Fork
Create
Delete
Workflow