본문 바로가기
Infra/Jenkins

[Jenkins] Jenkins를 이용한 CI/CD 자동화 사용

by 진꿈청 2024. 7. 17.

Jenkins

 

우리는 앞선 글에서 Jenkins를 통해 어떻게 빌드하는지를 알아보았다.

 

빌드가 성공적으로 완료되었다면 우리는 Tomcat 서버에 배포하거나 SSH 서버를 이용하여 배포를 할 수 있게 된다.

 

 

1. 빌드 파일을 Tomcat 서버(WAS)에 배포하기

 

우선, Tomcat 서버에 배포하기 위한 플러그인을 설치해주어야 한다.

(Tomcat 서버가 설치되어 있다는 가정)

 

 

Jenkins 관리 -> Plugins -> available -> deploy to container plugin

 위의 순서로 접속하게 되면 우리는 Deploy to container Plugin을 만날 수 있다.

 

해당 플러그인을 설치해주자.

 

 

자, 그런 다음 이제는 새롭게 Maven 프로젝트를 생성해보자.

 

New Item 생성

 

 

 

Maven Project를 받아오는 것과 관련해서는 이전 빌드 작업 때처럼 원하는 깃허브 주소를 담으면 된다. 

(Branch도 적절하게 설정해주어야 한다.)

 

 

 

빌드 유발

 

Item 구성 중 소스 코드 부분을 넘어서 쭉 내리다보면 빌드 유발이라는 파트가 나오게 된다.

여기서 우리가 현재 알아볼 것은 Build Periodically, Poll SCM 이다.

 

Build Periodically

  • cron job

Poll SCM

  • cron job
  • github

 

cron

  • 소프트웨어 유틸리티 cron은 유닉스 계열 컴퓨터 운영 체제의 시간 기반 잡 스케줄러이다.
  • 소프트웨어 환경을 설정하고 관리하는 사람들은 작업을 고정된 시간, 날자, 간격에 주기적으로 실행할 수 있도록 cron을 사용한다.

Build Periodically는 해석 그대로 일정 간격으로 cron 스케줄러 설정에 의해 빌드를 진행한다.

Poll SCM은 SCM. 즉, Git를 일정 간격으로 확인하며 코드가 변경이 되었다면 실행된다.

 

 

여기서 Jenkins에서 사용되는 cron 표현식을 간단하게 알아보자.

 

본래 cron 표현식

 

원래 cron 표현식은 초 | 분 | 시 | 일 | 월 | 요 | 연 이다.

  • 0 0 12 * * ? <- 매일 낮 12시에
  • 0 15 10 ? * * <- 매일 오전 10:15에

이런식으로 표현이 가능하다.

 

 

Jenkins cron 표현식

 

Jekins의 cron 표현식은 분 | 시간 | 날짜 | 월 | 요일 | 명령 순으로 되어있다.

따라서, * * * * * 는 1분마다 확인한다고 생각하면 된다.

  • 15 14 * * *  <- 매일 오후 2시 15분에 실행
  • 00 01 5 * * <- 매월 5일 새벽 한시 실행

 

Build Periodically vs Poll SCM

 

Build Periodically는 소스코드의 변경이 없어도 그냥 빌드를 진행하고,

Poll SCM의 경우 소스코드의 변경이 있으면 빌드한다.

 

 

빌드

빌드 과정은 이전 포스팅에서 알아보았던 것과 같이 빌드를 진행하면 된다.

 

여기서 필자의 블로그를 보고 따라하시는 분에게 유의해야 할 점이 있다.

 

이도원 강사님의 인프런 강의를 따라서 진행되므로 Maven 빌드를 진행하며 war로 패키징한다.

즉, Tomcat 서버와 같이 WAS 서버가 필요하다.

 

따라서, gradle로 빌드하거나 war 파일이 아닌 jar 파일로 빌드할 경우 과정이 조금 다를 수 있다.

하지만, Jenkins에 관한 학습이 목적이기에 관련 내용은 다루지 않고 추후에 기회가 된다면 다루겠다. 

 

 

 

빌드 후 조치

 

Item 구성 중 빌드 유발 파트를 넘어 빌드 후 조치에서

우리가 아까 설치한 Deploy to Container Plugin를 사용할 수  있다.

 

 

빌드 후 조치를 클릭하면 Deploy war/ear to a container라는 것이 보일 것이다.

 

 

클릭하게 되면 아래와 같이 작성이 가능하다. 

  • WAR/EAR files
    • 배포할 WAR 파일을 선택하는 것으로, 현재 우리 Jenkins Item은 깃허브로부터 Maven Project를 받아와 빌드했다.
    • 빌드를 통해 생긴 WAR 파일을 선택할 때 사용하는 부분으로 **/*.war(전체 경로에서 war 파일을 한 개만 존재하기에) 설정한다.
  • Add Container
    • 클릭하게 되면 아래와 같이 나오는데 본인의 OS에 설치된 Tomcat 버전에 맞게 진행하면 된다.

 

  • Credentials/Tomcat URL
    • Tomcat URL
      • 톰캣 URL의 경우 Jenkins를 도커로 실행했는지, 직접 설치를 했는지에 따라 달라질 것이다.
        • 직접 설치의 경우
          • Jenkins가 직접 설치가 되어있기 때문에 localhost를 사용하여도 문제는 없다.
        • 도커 설치의 경우
          • Jenkins가 도커에 설치되어 있길래 컨테이너 안에서 독립적인(?) 네트워크를 갖기에 localhost 사용이 불가하다.
          • 따라서, ifconfig(MacOS)를 사용하여 본인의 IP를 확인한 뒤 등록해준다.
    • Credentials
      • 이 부분은 이도원 강사님의 Jenkins 강의에서 사용된 부분으로 간략히 설명하겠다.
        • 우리는 톰캣 서버에 접속할 때 접속할 수 있는 권한을 지정할 수 있다.
          • manager-gui
          • manager-script
          • manager-jmx
          • manager-status
        • apache tomcat 디렉토리에 들어가서 tomcat-users.xml이라는 파일에 developer 설정을 넣어준다.
        • 해당 developer Credentials를 활용하여 우리는 Tomcat 서버에 배포가 가능하다.

 

tomcat-users.xml 설정 추가

  <user username="admin" password="admin" roles="manager-gui, manager-script, manager-jmx, manager-status"/>
  <user username="deployer" password="deployer" roles="manager-script"/>
  <user username="tomcat" password="tomcat" roles="manager-gui"/>

 

 

직접 빌드

 

모든 설정을 마쳤다면 직접 빌드를 실행한다. 이 때, 아래와 같이 빌드에 성공하면 올바른 작업이 진행된 것이다.

 

2. 빌드 파일을 Docker Container에 배포

 

빌드 파일Docker Container로 배포하기 위해서는 DockerSSH가 설치되어 있는 서버가 필요하다.

(필자는 이도원 강사님의 인프런 강의를 참고하였기에 Docker, SSH 구성이 되어있는 리눅스 이미지를 받을 수 있었다.)

(해당 리눅스 서버를 직접 생성하는 방법은 다음 포스팅에서 다루도록 하겠다.)

 

물론, Jenkins에서 SSH를 통해 빌드 파일을 전송하기 위한 Plugin도 필요하다.

 

 

Publish Over SSH 플러그인 설치

 

SSH Server 설정

 

Publish Over SSH 플러그인을 설치하게 된 후 우리는 아래 경로에서 SSH 서버 설정을 할 수 있다.

  • Jenkins 관리 -> System -> 맨 아래로 드래그

 

여기서 추가를 클릭하게 되면 우리는 SSH Server를 추가할 수 있다. 

  • Hostname
    • 접속할 IP 주소
  • Username
    • 접속할 계정
  • Remote Directory
    • 접속할 원격 디렉토리 경로

 

그 후, 고급을 클릭한 후 Use password authentication, or use a different key를 클릭한 후 Password를 등록한다.

(RSA키를 사용해도 가능하다.)

 

Port 및 Timeout은 본인에 맞게 적절하게 설정하면 될 것 같다.

 

자, 이제 우리는 SSH Server 설정까지 마쳤기 때문에,

이제는 Tomcat 서버에 배포한 것처럼 도커 컨테이너에 배포해보자.

 

 

New Item 생성

 

도커 컨테이너 배포를 위한 프로젝트를 생성한다.

 

 

빌드, 빌드 유발은 기존의 Tomcat 서버로 배포하는 과정과 크게 다를 것이 없다.

다른 점은 빌드 후 조치 부분이다.

 

 

빌드 후 조치 

 

기존에 빌드 후 조치 파트에서는 Deploy to Container Plugin를 사용했었다.

하지만, SSH Server를 이용하는 경우는 Send build artifacts over SSH를 사용한다.

 

  • SSH Server
    • Name
      • 사전에 System에서 설정했던 SSH Server의 이름을 넣는다.
    • Source files
      • SSH 서버로 전송할 파일을 지정한다.
    • Remove prefix
      • target를 지워주지 않으면 이름에 target이 포함되기에 지워준다.
    • Remote directory
      • 작업할 원격 디렉토리를 지정한다.
    • Exec Command
      • 타겟이 되는 SSH Server에서 실행할 명령어를 입력한다.

 

Exec Command 자세히

docker build --tag=cicd-project -f Dockerfile .
docker run -p 8080:8080 --name mytomcat cicd-project:latest

 

Remote Directory에 있는 Dockerfile를 활용하여 빌드된 WAR 파일을 이미지로 빌드한다.

그 후, 해당 이미지를 활용하여 도커 컨테이너를 실행시킨다.

 

 

Dockerfile

도커 파일의 내용을 살펴보면 다음과 같다.

  • LABEL
    • 이 이미지의 저자를 밝히기 위해 사용되는 도커 파일 문법으로, 이도원 강사님이다.
  • COPY
    • /webapp.war 파일을 tomcat 이미지의 /usr/local/tomcat/webapps 경로로 복사한다.

 

 

도커 컨테이너 실행

 

젠킨스로부터 전달받은 WAR 파일을 --tag 명령어를 활용하여 cicd-project 이미지로 빌드한 뒤

해당 이미지 이름을 사용하여 8080포트로 /webapp.war이 담긴 톰캣 컨테이너를 구동시켰다.

 

 

결과

UNSTABLE이라는 오류가 발생할 수 있다.

그 이유는 이미 컨테이너가 띄워져 있는 경우 같은 이름의 컨테이너를 띄우는 과정에서 오류가 발생한다.

따라서, 적절하게 기존의 이미지, 컨테이너 등을 제거해줘야 한다.

 

이 부분은 장차 설명할 Ansible를 통해 해결해볼 것이다.

 

 

참고

이도원 강사님의 Jenkins 강의