안녕하세요 오늘은 Jenkins에 대해서 알아보도록 하겠습니다, 최근 들어 이번 서비스를 만들면서 인프라 관리의 중요성을 많이 느끼게 되었고 하루 빨리 배워보고 싶어 곧 명절임에도 불구하고 Jenkins를 설치 해보고 build까지 해봤습니다, 그럼 지금 부터 한번 Jenkins가 뭔지 알아볼까요 !?

Jenkins..?

왜 필요할까

Jenkins가 뭔지 알기 전에 왜 Jenkins가 필요한지부터 알아야지 배우는데에 있어서 좋은 동기가 될 거 라고 생각하는데요, 먼저 기존에는 어떤식으로 배포가 진행됐는지를 하나씩 살펴보면 불편한 점을 알 수 있게 될 겁니다.. 새삼 느끼게 되는게 개발자라는 사람들은 불편하다 느끼는게 있으면 무조건 자동화 시키는 거 같습니다 ㅋㅋㅋㅋ
(그래서 효율을 중요시하는 저한테는 매우 좋은 거 같습니다)

AWS EC2으로만 배포할 경우

먼저 그 어떠한 인프라 자동화 및 관리 도구가 없이 배포를 할 경우 어떤 과정으로 배포가 진행될까요?

1. Jar파일을 빌드한다.
 1-2. Jar파일을 pem파일이 있는곳으로 옮겨준다
2. AWS에 들어간다.
3. 우분투에 접속한다.
4. 기존에 실행한 Jar파일을 꺼준다.
5. 기존에 Jar파일을 지워준다.
6. Jar파일을 우분투에 넘겨준다.
 6-2. 이때 Scp를 통해서 넘겨줘야 하기에 cmd를 하나 더 켜줘야한다.
7. Jar파일을 다시 실행해준다.

(저가 처음 배포할 떄 이렇게 배포했었습니다)

하지만 주어진 순서로 배포할 경우에 모든 방법이 수동으로 진행되므로 시간이 많이 소요되고 실수가 발생할 가능성도 있습니다, 또한 환경이나 조건에 따라서 이 순서가 최적화된 순서가 아닐 수도 있습니다.. 예를 들어 이 과정대로 배포할 경우에는 애플리케이션에 대한 다운타임이 발생해 사용자가 서비스를 사용하는데에 있어서 문제가 생길 수 있습니다.

Docker도 같이 배포할 경우

자, 그러면 이번엔 Docker도 같이 사용해서 배포할 경우에는 어떤 과정으로 진행되는지도 알아보겠습니다.

1. 도커를 도커허브에 푸시해준다
2. AWS에 들어간다.
3. 우분투에 접속한다
4. 기존에 실행한 도커를 꺼준다
5. 도커허브에서 도커파일을 가져온 후 다시 실행해준다.

이전보다 확실히 과정이 단조로워졌습니다, 기존에는 매번 Jar파일을 빌드하고 Jar파일을 pem키가 있는 폴더로 옮긴 후 cmd나 Git Bash를 하나 더 켜서 넘겨줘야 했었는데 Github과 동일하게 원격으로 파일을 받아올 수 있게 되었고 파일을 받아서 다시 실행하는 과정 역시 조금은 더 단조로워졌습니다,

하지만

여전히 계속해서 우분투 환경에 들어가주어야 하는데요.. 이게 한 두번이면 괜찮지만 계속해서 이렇게 들어갔다가 나왔다가 하기엔 시간이 지날 수록 지치기도 하고 때에 따라서 실수하는 경우도 발생합니다, 그렇기에 이런 문제를 해결하기 위해서 저는 Jenkins를 배워야했습니다.

개념

Jenkins란 소프트웨어 개발시 지속적인 통합(Continuous integration, CI)과 지속적인 배포(Continuous Deployment, CD)를 제공해주는 도구입니다, 앞서 Jenkins를 왜 배워야하는지를 알아봤고 그렇기에 Jenkins 같은 CI/CD 도구가 없었던 시절에는 코드를 변경할 때마다 매번 수동으로 빌드하고 테스트하고 서버에 직접 접속해서 배포해야 했습니다...

하지만, Jenkins는 이러한 빌드, 테스트, 배포 프로세스를 자동화하여 개발자의 시간 절약, 배포 과정에서의 실수, 개발의 생산성을 높일 수 있었고 Git과 같은 버전관리 시스템과 연동하여 만약 커밋을 감지할 경우에 빌드가 자동으로 되고 배포역시 자동으로 되도록 도움을 주었습니다.

즉, Jenkins는 Git에 커밋하면 알아서 배포해주는 도구입니다..!

(Netlify나 Vercel로 배포한 것과 똑같은 느낌이라 매우 좋음..)

장점

• 자동화와 표준화
  : Jenkins를 사용하면 빌드, 테스트 및 배포 프로세스를 자동화하여 일관된 방식으로 작업할 수 있습니다,
• 피드백 루프 단축 : Jenkins를 통해 더 빠르게 피드백을 받고 오류를 조기에 발견할 수 있기에 실제로 개발 및 테스트 주기를 단축할 수 있습니다. (빌드 과정에서 테스트도 함께 합니다)
• 확장성
  : jenkins는 다양한 플러그인을 제공하며 사용자 정의 가능한 작업 및 플로우로 확장이 가능합니다.
• 비용 효율적
  : 오픈 소스이기에 라이선스 비용이 들지 않습니다.

실습

자, 그러면은 이제 Jenkins가 무엇인지, 왜 필요한지, 어떤 장점이 있는지까지 알아봤으니 실제로 Jenkins를 어떻게 사용할 수 있는지 그리고 어떤 흐름으로 Jenkins가 작동되는지도 한번 알아보도록 하겠습니다.

Jenkins의 CI/CD 과정

1. 개발자가 커밋
  : 로컬에서 개발한 코드를 Git에 커밋하고 푸시합니다.
  
2. Jenkins의 감지 및 빌드/테스트
  : Jenkins는 공유 레포지토리에서 변경된 소스 코드를 
  감지한 후 빌드 및 테스트를 자동으로 시작합니다, 빌드와 테스트가 성공하면
  빌드한 파일을 배포할 준비가 됩니다.
  
3. 빌드 파일의 배포
  : 성공적으로 빌드된 파일은 배포 서버로 전송됩니다,
  배포서버에서의 필요한 추가 작업을 수행한 후 애플리케이션을 배포 합니다.
  
4. 실패 시 로그 기록
  : 만약 빌드 또는 테스트가 실패할 경우에는 로그를 기록하고
  해당 내용을 개발자 또는 관리자에게 알립니다.

Jenkins 설치 & 회원가입

먼저 Jenkins 공식 홈페이지에서 자신의 서버 운영체제와 일치하는 설치 메뉴얼을 그대로 따라해서 설치해주시면 되겠습니다, 하지만 이는 개발 또는 테스트 환경에서 사용하는 방법이고 실제 운영 환경에서 Jenkins를 배포하고 사용할 때는 Docker를 사용하여 설치하는 것이 일반적입니다.

https://get.jenkins.io/war-stable/
근데 오늘은 로컬에서 사용하는 방법에 대한 포스팅이니 공식 사이트에서 다운 받아봅시다 ~ !

1. 공식 홈페이지에서 적절한 버전 다운
2. jenkins.war 파일을 원하는 위치에 놔두기
3. cmd 켜서 jenkins.war 파일이 있는 위치로 간 후
   3-1. "java -jar jenkins.war" 입력 후 실행

위 과정을 다 한 후 8080포트로 이동하면 Jenkins가 실행된 걸 확인할 수 있는데요, 최초 로그인시에는 cmd 에 비밀번호가 적혀있으니 이 비밀번호를 입력하시고 로그인 하시면 될 거 같습니다.

(로컬인 경우 localhost:8080, 로컬이 아닌 경우 서버IP or 도메인 + 8080)

로그인을 완료하시고 나면 플러그인을 어떻게 설치할지에 대해서 물어보는 페이지가 나옵니다, 이떄는 install suggested plugins를 눌러 추천해주는걸로 설치해주시면 됩니다.

이후에 추천해준 플러그인을 다 설치가 되면 기본적인 계정 설정 페이지와 Jenkins URL를 정하는 페이지가 나오는데 이것은 원하시는대로 입력하시면 되겠습니다, 그리고 모든 기본 설정이 완료되면 위 사진과 같은 창이 뜨고 이때부터 Jenkins를 사용하실 수 있습니다.

Jenkins Job

처음으로 Jenkins에 들어가게 될 경우 어떠한 Job도 없기에 매인 대시보드쪽에 Job을 생성하는 버튼이 있을겁니다, 그 버튼을 클릭하면 아래와 같은 페이지로 이동하실 수 있습니다.

(이때 JDK 버전 또는 Gradle 버전과 같은 실행할 파일의 버전에 맞게 Jenkins 역시 버전을 설정해주어야 합니다..!)

이후 item의 이름을 정할 수 있는 페이지로 넘어오는데 'Freestyle project'로 생성해주었습니다.

그러면 다음으로 구성설정을 하는 페이지로 넘어올 수 있게 됩니다,
저 같은 경우에는 이번 포스팅에서 제 Github와 연동을 할 예정이기에
옛날에 만든 recipe 레포지토리를 연결해주도록 하겠습니다.

소스 코드 관리 역시 Git으로 설정하도록 하겠습니다,
이때 Credentials같은 경우에는 아래의 Add를 클릭한 후
Github 토큰을 이용하면 추가하실 수 있습니다.

그리고 빌드 과정에서는 Gradle을 사용할 수 있도록
'Invoke Gradle script'를 사용하도록 해주었습니다.

마지막으로 언제 빌드가 이루어지는지 트리거를 지정하는 부분에서는 Github hook trigger for GITScm polling으로 설정해주었습니다, 이 옵션의 경우 Github 저장소에서 발생하는 특정 이벤트(예:push. pull request)를 감지하여 Jenkins 빌드를 자동으로 트리거할 수 있도록 도움을 줍니다.

그렇게 모든 구성을 마친 후 빌드를 해주면, 위 사진과 같이 성공적으로 빌드가 된 모습을 확인하실 수 있습니다, 이때 앞서 얘기드린 것과 같이 JDK버전과 Gradle버전을 잘 확인하시길 바랍니다, 저 같은 경우에도 처음에 한 두번 빌드에 실패했었는데 JDK버전을 제대로 설정해주지 못해서 발생한 문제였습니다

그리고 빌드가 완료되었다면 빌드 이후에 추가로 조치를 취할 수 있습니다, 이때 위에 Jenkins의 CI/CD 흐름과 동일하게 빌드된 파일을 도커헙에 보낸 후 스프링 서버로 접속하고 거기서 다시 도커헙에서 가져온 후 서버를 자동으로 배포해주는 과정을 빌드 후 조치 부분에서 적절하게 스크립트를 작성해주시면 되겠습니다.

끝으로

이번 포스팅에서는 Jenkins가 무엇이고, 왜 써야하고, 어떻게 쓰는지 등등.. 기본적인 내용을 위주로 구성되어 있었는데요, 아무래도 저번 서비스에 다시 적용하기엔 너무 늦은 감도 있고 사실 더 이상 그 서비스는 배포를 더 할일도 없을 거 같아 다음 서비스에서 더 활용해서 사용하는 부분을 포스팅해보고자 합니다, 더군다나 저번 서비스에서 배포의 불편함을 뼈저리게 느꼈기에 이번 포스팅을 통해 좋은 경험을 할 수 있었던 거 같습니다,

감사합니다.