이전 글에서 로컬(Winodws) 환경에서 젠킨스를 설치하고 실행해보고 배포까지 해보았으니,
이번 글에서는 리눅스 환경에서 젠킨스를 실행해보겠습니다.
해당 글에서는 EC2 인스턴스가 2개 사용했습니다.(젠킨스 EC2, 스프링 EC2)
메모리 스왑
free -h 명령어를 통해 RAM의 용량을 확인할 수 있다.
프리티어에서 젠킨스를 통해 배포 자동화를 하기에는 1GB의 용량은 부족하다.
현재 나는 프리티어를 사용하고 있기 때문에 1GB의 램을 사용하고 있다.
리눅스에서는 메모리 스왑시에 1GB의 2배인 2GB 메모리 스왑을 권장하고 있다.
다음 명령어를 실행해서 메모리 스왑을 하자.
# Swap 메모리를 Swap 파일로 포멧
sudo dd if=/dev/zero of=/swapfile bs=128M count=16
sudo mkswap /swapfile
--
# 스왑 파일의 읽기 및 쓰기 권한 업데이트
sudo chmod 600 /swapfile
--
#스왑 공간에 스왑 파일을 추가하여 스왑 파일을 즉시 사용
sudo swapon /swapfile
--
# 파일시스템 설정
sudo vi /etc/fstab
# 맨 아래에 다음 라인 추가 (시스템이 재시작되더라도 활성화)
/swapfile swap swap defaults 0 0Q. Spring 서버는 다른 EC2에서 실행하니까 빌드만 하면 메모리가 1GB여도 괜찮지 않을까?
A. 빌드만 해도 다음과 같이 메모리가 넘친다. 또한 테스트 까지 실행할 것이니 EC2를 강제로 재시작하기 싫다면 메모리 스왑을 하거나, EC2의 메모리를 늘리자.
젠킨스 설치
EC2에서 젠킨스 실행해보기
해당 글을 통해서 젠킨스를 설치하자.
젠킨스 설정
로컬(Windows) 환경에 Jenkins 설치하고 빌드해보기 (1)
이 부분은 Windows OS인 로컬 PC에서 설치한 것이기 때문에
Amazon Linux에서 다른 부분만 여기에 쓰겠습니다.
ngrok로 외부 IP를 만들기
링크의 글에서도 말하고 있지만 해당 부분은 도메인이 설정되어 있다면 생략해도 된다.
로컬의 ngrok.exe를 실행하고 다음 명령어를 실행하자.
바뀐 부분은 ec2의 퍼블릭 IP를 사용한다는 것이다.
ngrok authtoken 발급받은authtoken
ngrok http {EC2 의 퍼블릭 IP}:8080파이프라인 생성
이 부분이 Windows 환경과 달라지는 부분이 꽤 있다.
파이프라인을 다음과 같이 구성할 것이다.
GitHub Clone : GitHub의 Repository에 코드를 Clone해 온다.
Build : 기존 jar 파일을 지운 뒤 빌드한다.
Test : 테스트 코드를 실행한다.
Deploy : 운영 환경 EC2에 배포한다.
Git 관련 오류 발생
The recommended git tool is: NONE
using credential Gaja-Jenkins-Admin
Cloning the remote Git repository
Cloning repository https://github.com/GaJaMap/backend/
> git init /var/lib/jenkins/workspace/Gaja-Dev # timeout=10
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not init /var/lib/jenkins/workspace/Gaja-Dev별다른 문제는 아니였다.
이전에 EC2 인스턴스를 제거했다가 새롭게 실행하면서 Git을 설치하는 것을 까먹었다.
다음 명령어로 git을 설치하고 버전을 확인해주자.
sudo yum install git
git --version/gradlew 권한 문제
빌드를 시키려고하니까 이런 권한 문제가 발생해서 파이프라인이 정상적으로 동작하지 않았다.
Window 환경에서 파일 생성 시 기본 권한이 644로 설정되기 때문에 리눅스 환경에서는 755로 변경이 필요하다고 한다.
젠킨스의 아이템 위치로 이동한 후 다음 명령어를 통해서 권한을 확인해보자.
# 기본위치 - /var/lib/jenkins/workspace
cd /var/lib/jenkins/workspace/{파이프라인 아이템 이름}
git ls-tree HEAD
644로 설정되어 있는 것을 확인할 수 있다.
만약 이런 화면이 나외 않는다면 다음과 같은 명령어를 실행하고, 다시 앞에 명령어를 실행해서 확인해보자.
git config --global user.name "사용자이름"
git config --global user.mail "이메일"
git config --global --add safe.directory clone한파일경로이 문제는 젠킨스 파이프라인에서 빌드하기 전에 다음 명령어를 실행하도록 만들어서 해결할 수 있다.
// 권한 windows -> linux (gradle 644 -> 755)
sh 'chmod +x ./gradlew'빌드 전에 설정파일 넣기
현재 프로젝트의 yml 파일을 깃허브에 올라가지 않도록 설정했다.
그래서 GitHub에서 그대로 가져와도 yml 파일이 없다.
그렇기 때문에 빌드전에 yml 파일을 넣어주어야 한다.
여기에는 AWS의 Parameters Store를 사용할 수 있지만, 지금은 단순하게 yml 파일을 넣어주는 방식으로 처리한다.
앞서 깃허브 토큰을 등록할 때와 마찬가지로 젠킨스에 Global Credentials을 추가해주자.
Kind : Secret file
File : yml 또는 properties 파일 등록
ID : 파이프라인에서 쓸 임의의 이름(알아서 정하면 된다.)
그리고 젠킨스 파이프라인에 빌드 전에 다음 명령어를 등록해주면 된다.
withCredentials([file(credentialsId: '방금 정한 ID', variable: '변수명')]) {
script {
// 위치와 파일명은 알아서 정해주면 됩니다.
sh 'cp -f $변수명 ./src/main/resources/application.yml'
}
}ssh 설정
Jenkins를 통해 빌드 결과물을 EC2에 업로드하고 실행하기 (2)
이 부분은 결국 EC2에 배포를 위한 부분이기 때문에 해당 글의 내용과 크게 다른 점이 없다.
최종 파이프라인 코드
pipeline {
agent any
stages {
stage('GitHub Clone') {
steps {
// GitHub 레포지토리에서 코드 Clone하기
git branch: 'Clone할 브랜치명',
credentialsId: '젠킨스에 설정한 Git 토큰 ID',
url: 'Clone할 Repository 위치'
withCredentials([file(credentialsId: '젠킨스에 설정한 파일 ID', variable: '임의변수명(마음대로적기)')]) {
script {
// -f는 덮어쓰기 옵션 | 위치와 파일명은 알아서 정해주면 됩니다.
sh 'cp -f $임의변수명(마음대로적기) ./src/main/resources/application.yml'
}
}
}
}
stage('Build') {
steps {
// 권한 windows -> linux (gradle 644 -> 755)
sh 'chmod +x ./gradlew'
// 테스트 코드는 여기서 실행 안시킴
sh './gradlew clean build --exclude-task test'
echo 'Build Success!'
}
}
stage('Test') {
steps {
// Gradle로 테스트하는 단계
sh 'gradlew test'
echo 'Test Success!'
}
}
stage('Deploy') {
steps {
sshPublisher(...)
echo 'Deploy Success!'
}
}
}
}