영암사는 승경이네

Jenkins sshPublishers의 removePrefix가 뭔지 잘 이해되지 않아 정리합니다. 추가로 remoteDirectory, sourceFiles 설정도 함께 정리하였습니다.

빌드 후 조치의 SSH Publishers 설정 🤗

예제로 사용할 Send build artifacts over SSH의 설정입니다.

Source files

Source files는 로컬 서버에서 원격지 서버로 전송할 파일을 의미합니다. 주의할 점은 위와 같이 /build/libs/*.jar를 입력할 경우 build/libs에 있는 jar 파일만 이동되는게 아닙니다. /build/libs 폴더도 이동됩니다. 😯

remoteDirectory

ssh로 연결한 원격 서버의 작업 디렉토리를 의미합니다. Source files에 입력한 파일들이 이 작업디렉토리로 이동됩니다. 앞서 /build/libs/*.jar 파일들은 Remote directory에 입력한 namevalue 디렉토리 내에 위치한 것을 확인할 수 있습니다. 참고로 작업 디렉토리의 기준이 되는 루트 디렉토리는 Jenkins의 시스템 설정에 추가한 SSH Server 의 Remote Directory 입니다.

만약 /home/sksim/application/namevalue 라는 폴더로 파일들을 복사하고 싶다면 Remote directory에 /application/namevalue를 입력하면 됩니다.

removePrefix

지금은 jar 파일과 build/libs 디렉토리를 함께 전송하고 있습니다. 사실 저는 jar 파일만 이동시키면 됩니다. build/libs라는 디렉토리까지 이동시킬 필요가 없는 것입니다. 즉, Source files 에 포함된 파일들 중 전송시키고 싶지 않는 Prefix 경로를 적어주면 removePrefix에 적어주면 Prefix에 해당하는 파일이나 디렉토리는 이동되지 않습니다. /build/libs를 입력하면 *.jar 에 해당하는 파일만 이동되는 것입니다.

1. 개요

 - Git webhook을 사용하여 배포 자동화 시스템을 구축해보자.

2. 준비

 - Jenkins

 - Git 레포지토리

 - 스프링 부트 / Gradle 프로젝트 (jar파일 배포)

3. webhook이란?

 - webhook이란 원격 저장소의 소스에 push, commit 등의 이벤트가 발생하면 Jenkins와 같은 CI 서버에 해당 이벤트를 전달하는 기능입니다. Jenkins에서 이 이벤트 정보를 받아 리빌드, 배포와 같은 작업을 연계하여 진행해보도록 하겠습니다.

4. Item 생성

 4.1. Freestyle project를 생성합니다. 

 4.2. 설명 및 GitHub project url을 입력합니다. 실제로 여기에 입력한 Git 주소가 연동에 사용되진 않습니다.

 4.3. 소스코드 관리로 Git을 체크한 후, 실제로 연동할 Git 주소를 입력합니다. 그럼 인증을 하라는 에러가 발생하며,  Git 계정 인증 시 'password 방식'이 지원을 하지 않으니 'Token authentication 방식'을 사용하라고 합니다. 그럼 토큰을 만들어야겠죠? 토큰은 깃허브 홈페이지에서 만들 수 있습니다.

 4.4. 하던 작업을 잠깐 멈추고 '깃허브 로그인 / settings / developer settings / Personal access tokens' 탭에 들어가 Generate new token 버튼을 선택합니다.

 4.5. 리포지토리에 대한 전체 접근 권한 및 hook 권한을 체크한 후, Generate Token 버튼을 눌러 토큰을 생성합니다.

  * repo, admin:repo_hook을 체크하면 됩니다.

  * Expiration을 No expiration으로 설정하면 토큰 만료 기간 없이 계속 사용 가능합니다.

 4.6. 생성된 토큰 값을 확인 후 복사합니다.

 * 참고로 해당 페이지를 넘어가게 되면 현재 발급된 토큰 키값을 다시 확인할 수 없으며, 분실 시 재발급 받아야합니다.

 4.7. Jenkins로 돌아가 Credentials / Add를 선택 후 Kind에는 Username with password, UserName에는 GitHub ID, Password에는 복사한 토큰 키를 입력합니다. 아래 ID와 Description은 식별자와 설명입니다. 임의로 입력 후 Add를 누릅니다. 에러가 사라졌다면 인증이 완료된 것입니다.

 4.8. Branch는 Master로 설정합니다.

 4.9. 빌드 유발은 GitHub hook trigger for GITScm polling을 선택합니다. 이 옵션이 있어야 webhook을 통해 Jenkins로 들어온 push 이벤트 정보를 인식하여 빌드를 유발할 수 있습니다. 실제 빌드는 다음 Build 탭에서 설정합니다.

 4.10. 필자의 경우 Gradle SpringBoot 프로젝트이기때문에 Invoke Gradle Script를 선택 후 Tasks에 bootJar를 입력했습니다. build.gradle 파일에는 다음 코드를 입력하여 modu.jar라는 파일명으로 빌드되도록 설정한 상태입니다.

 * jar 파일 빌드가 완료되면 빌드 후 조치 부분에 빌드된 jar 파일을 실행시키도록 하여 스프링 부트에 내장되어 있는 tomcat 서버를 통해 서비스를 기동할 예정입니다.

 * Gradle Version에서는 빌드에 Gradle을 지정해줘야하는데 이는 Global Tool Configuration 탭에서 설정이 가능합니다.

 4.11. 빌드 성공 시 start.sh라는 스크립트를 실행하도록 합니다. 해당 스크립트안에는 현재 실행되고 있는 프로세스가 있다면 kill 후 재시작하는 코드가 작성되어 있습니다. Script에 해당하는 경로에 start.sh 파일을 적절히 커스터마이즈하여 생성해줍시다.

 * start.sh

#!/bin/bash

echo "PID Check..."
CURRENT_PID=$(ps -ef | grep java | grep modu | awk '{print $2}')

echo "Running PID: {$CURRENT_PID}"

if [ -z ${CURRENT_PID} ] ; then
        echo "Project is not running"
else
        echo "Kill Current PID"
        kill -9 $CURRENT_PID
        sleep 10
fi

echo "Deploy Project...."
nohup java -jar /var/lib/jenkins/workspace/practice-project/build/libs/modu.jar >> /home/ec2-user/practice-script/modu.log &

echo "Done"

~

 이걸로 간단한 형태의 Item 생성 및 설정이 끝났습니다. 이제 마스터 브랜치로 push를 하여 자동으로 빌드 및 jar파일을 실행시켜 배포가 되는지 확인해보도록 하겠습니다.

5. Git Push

 5.1. 소스코드 수정 후 GitHub Desktop 프로그램을 사용해 commit / push를 진행합니다.

6. Jenkins 자동 빌드 및 배포 확인

 6.1. Push를 하면 자동으로 Jenkins 빌드가 시작됩니다. Build History에서 확인이 가능합니다.

 6.2. 해당 빌드 선택 후 Console Output을 확인하면 빌드 로그를 확인할 수 있습니다. 확인 결과, 빌드에 성공하여 BUILD SUCCESSFUL를 뿌리고 있습니다. 그에 따라 start.sh 스크립트를 실행하는 로그도 확인되고 있습니다. 스크립트도 정상적으로 실행되었으니 실제로 서비스가 올라갔는지 확인해보도록 하겠습니다.

 6.3. public DNS로 조회하여 서비스 확인 결과, 정상적으로 jar파일이 실행되어 tomcat 서비스가 올라간 것을 확인할 수 있습니다.

7. 마치며...

 Jenkins를 사용하여 정말 간단한 구조의 DevOps 환경을 구성해보았습니다. SpringBoot / Gradle 프로젝트, Git을 통한 소스관리, Jenkins를 통한 자동 빌드 및 배포, Swagger를 통한 REST API Interface를 제공하게 되었네요.. 뿌듯..

 아무래도 프리티어 서버를 통해 작업을 진행하다 보니 중간중간 메모리 부족으로 인한 문제도 발생하였습니다. 간혹가다 빌드 시 OutofMemory가 발생하거나, 서버 자체가 꺼져버리는 현상이었습니다. 그럴때마다 AWS EC2 인스턴스를 재시작했었는데, 현재는 Swap Memory를 0 > 2GB로 늘려주어 해결한 상태입니다. 관련 포스팅 다음에 진행하여 링크를 남겨놓도록 하겠습니다!

1. 개요

 Window10 및 CentOS7 환경에서 Jenkins를 설치해보자.

2. Jenkins란?

 Jenkins는 CI 툴로 지속적 통합 서비스를 제공해준다. 소스관리, 자동배포, 테스트 및 코드 분석까지도 지원한다.

3. Window10 Jenkins 설치

 3.1) Jenkins 설치 파일 다운로드

  - https://www.jenkins.io/download/ 에 접속 및 LTS 버전 중 Windows 를 클릭하여 다운로드 한다.

 3.2) Jenkins 설치 파일 실행

  - Logon Type 체크 부분이 나오기 전까지 Next를 선택한다.

  - Logon Type 선택 항목이 나오면 Run service as LocalSystem을 선택한다.

   Q. this account either does not have the privilege to logon as a service Error가 발생

   A. 시스템 계정의 로그온 권한이 없어서 발생하는 에러이며, 시작메뉴에서 '로컬 보안정책 - 로컬 정책 - 사용자 권한 할당 - 서비스 로그온 - 사용자 또는 그룹 추가' 에서 사용자를 추가하여 해결

 3.3) Jenkins 관리자 비밀번호 설정

  - Jenkins 설치가 완료되면 8080 포트로 Jenkins 서버가 실행되며, Jenkins Starter 페이지가 자동으로 열림

  - 아래 화면의 빨간색으로 표시된 경로 파일을 열어 입력된 비밀번호를 복사한 후 빈칸에 삽입

  - 파일 경로에 파일이 없을 경우 PC 재부팅

 3.4) 플러그인 설치

  - Jenkins에서 사용할 플러그인 설치 페이지

  - 추후에도 설치가 가능하므로 Suggested plugins를 클릭하여 설치

 3.5) 계정 및 URL 설정

  - Jenkins 계정 생성

 3.6) Jenkins URL 설정

  - Jenkins URL을 설정하는 페이지

  - 8080 포트가 사용중이라면 다른 포트로 변경해도 무관

  - 추후에 포트 변경이 가능하니 참고

 3.7) 로그인

  - 로그인 성공 후 메인화면이 출력되면 설치 성공

4. CentOS7 Jenkins 설치

 - CentOS7에서는 yum을 사용하여 Jenkins를 간편하게 설치할 수 있다.

 - 만약 yum이 설치되어있지 않다면 설치 후 아래 명령어들을 입력하면 된다.

 4.1) Jenkins 설치

  # wget –o /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo

  # rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key 

  # yum install jenkins

 4.2) Jenkins 포트 변경

  # vi /etc/sysconfig/Jenkins

  - 위 명령어 실행 후 JENKINS_PORT="PORT" 부분을 찾아 수정

 4.3) 방화벽 오픈

  # firewall-cmd --permanent --add-port=변경한포트/tcp

  # firewall-cmd --reload

 4.4) Jenkins 접속 및 설정

  - localhost:PORT 를 브라우저에 입력하면 Window 설치의 3.3부터 동일하게 따라하면 된다.

1. 개요

 jenkins 자체에서 war파일을 만드는 것은 성공하였으나, 이 war 파일을 tomcat 서버에서 실행 시키는 과정에서 에러가 발생하고 있다. 에러 문구는 다음과 같다.

 Deployed application at context path /context but context failed to start instead of the expected "OK" message

 .....

 Build step 'Deploy war/ear to a container' marked build as failure

 확인결과 war파일을 tomcat container에 Deploy 하는 과정에서 에러가 발생하고 있음을 알 수 있고, 정확한 원인은 톰캣 로그를 확인해야 한다.

2. 확인

 Deploy 과정에서 발생한 로그를 확인해봐야 한다. 배포 과정의 로그가 담긴 tomcat 경로/logs/catalina.log를 확인하여 에러 코드를 확인해보았다.

 확인 결과 다음과 같은 에러 로그를 확인할 수 있었다.

 Unsupported major.minor version 52.0

 오우오우.. 빌드하려는 프로젝트의 컴파일 버전은 1.8(52.0)이나 tomcat에서는 그보다 낮은 jdk 버전으로 빌드를 시도하여 위 에러가 발생하였다. 즉, jdk 1.8은 지원안해요~ 이뜻이다.

3. 해결

 (tomcat마다 뭔가 설정을 해주지 않는 한) tomcat은 일반적으로 시스템 변수의 JAVA_HOME을 사용한다.

 시스템 변수의 JAVA_HOME을 직접 들어가서 확인해보면 낮은 버전의 JDK 버전이 설정되어 있을 것이다.

 이를 jdk 1.8 버전으로 수정하면 된다.

 올바르게 수정됐는지 확인하고 싶다면 pc 재부팅 후 javac -version 명령어를 입력해보면 된다.

1. 개요

 Jenkins와 tomcat 연동 및 빌드 과정에서 다음과 같은 에러가 발생했다.

 Server returned HTTP response code: 401 for URL ~~

2. 확인

 401 에러는 자격인증 실패 에러이다. 쉽게 말게 인증이 실패한건데, 로그를 자세히 보니 The username and password you provided are not correct 라는 문구가 보였다.

3. 해결

 jenkins 설정의 빌드 후 조치 / Deploy war/ear to a container 항목에 Contatiners를 새로 추가해주었다.

add 선택 후 Username와 Password를 설정한다.

Username와 Password를 모르겠다면 tomcat경로의 conf/tomcat-users.xml 파일에 기입된 username과 password를 입력하면 된다. 만약 주석처리 되어 있을 경우 다음과 같이 새로 추가해준다.

4. 결과

 해당 에러는 발생하지 않으며 정상 빌드됨을 확인할 수 있다.

1. 개요

 jenkins 에서 빌드 도중 다음과 같은 경고가 나타났다.

 1) Using platform encoding (MS949 actually) to copy filtered resources, i.e. build is platform dependent!

 2) File encoding has not been set, using platform encoding MS949, i.e. build is platform dependent!

2. 원인

 maven 빌드 시 인코딩 타입을 따로 지정하지 않아 발생한다.

3. 해결

 pom.xml에 노란색으로 표시된 프로퍼티를 추가한다.

1. 개요

 젠킨스와 github 연동 이후 webhook을 통해 자동 build를 테스트하고 있던 도중 다음과 같은 에러가 발생했다.

2. 환경

 jenkins

 window 10

 tomcat 8.0.x

3. 해결

javax.servlet.http 는 tomcat 경로의 lib 폴더 안에 servlet-api.jar 에 존재한다.

tomcat을 설정하는 부분은 있으나 빌드하는 과정에서 해당 jar 파일을 못 읽어온다고 가정하고 maven에 servlet-api.jar 의존성을 추가하였다.

그 후 다시 빌드를 하니 해당 오류가 발생하지 않고 빌드가 성공했다는 메시지를 받을 수 있었다.