SpringBoot & React AWS 배포 테스트 7) git clone을 통해 사전 테스트 이후 Jenkins Job 설정과 Build 테스트

정리 목적

이번에 AWS에 배포 테스트를 하며 UI가 변경된 부분도 좀 있었고 이전에는 도메인 구매 후 접근 테스트만 해본 반면 이번에는 여러 환경을 설정하고 처리했기 때문에 이전 정리 내용을 지우고 새로 다시 정리.

 

처리 환경 정리

Project

• BackEnd - Spring Boot 3
• FrontEnd - React
• 빌드 방식 - 통합빌드

AWS

• EC2 t2.micro
  • ubuntu 22.0.4
• Application Load Balancer
• AWS Certificate Manager(ACM)
• Route53
• S3
• RDS(MySQL)
• ElastiCache(Redis)

CI / CD

• Jenkins
• Git Webhook

WebServer

• Nginx

Domain Register

• Gabia

 

정리 순서

1. S3 Bucket 생성 후 Local에서 테스트
2. RDS MySQL Database Instance 생성 후 Local Workbench와 연결 테스트 및 프로젝트 연결 테스트
3. EC2 Instance 생성 후 설정
   1. swap 메모리 설정
   2. JDK 17 설치
   3. nvm 설치 및 node 21.7.1 설치
   4. Nginx 설치 및 설정
   5. Jenkins 설치 및 빌드 Job 설정을 제외한 나머지 처리
   6. ElasiCache Redis OSS Cache 생성 및 Redis 설치
4. Gabia 도메인 구매 후 Route53, ACM 처리
5. Load Balancer 대상 그룹 생성 및 ALB 생성 후 대상 그룹 설정
6. A레코드 생성 및 도메인 접근 테스트
7. git clone을 통해 사전 테스트 이후 Jenkins Job 설정과 Build 테스트
8. Git Webhook 연동 및 테스트

---

git clone 후 서버 실행 및 테스트

Jenkins를 통해 CI / CD 를 수행하기 전에 프로젝트가 정상적으로 배포되는지 확인하기 위해 테스트했다.

 

EC2에서 프로젝트를 clone 받았다.

# root 위치에서 디렉토리 생성
sudo mkdir testBuild

# 이동
cd testBuild

# git clone
git clone https://github.com/~

 

그리고 바로 프로젝트 빌드 후 실행했다.

# 프로젝트 경로에서 명령어 실행
./gradlew build

# jar 파일 실행
java -jar build/libs/project.jar

 

이렇게 실행 후 도메인으로 접근했을 때 정상적인 결과를 얻을 수 있었다.

 

Jenkins Provide Configuration files 사용을 위한 처리

이걸 뭐라고 불러야 할지 몰라서 부제를 이렇게 정하긴 했다.

이후 Jenkins Job 설정을 하면서 Provide Configuration files라는 기능을 체크해 사용할 것이다.

이 기능은 빌드 환경에서 선택할 수 있는데 Spring을 기준으로 application.yml 같은 설정 파일은 공개가 되면 안되는 내용들이 작성되기도 하므로 git에 올라가지 않도록 ignore에 걸어둔다.

그럼 단순하게 application.yml 하나만 ignore에 걸어두었다고 가정하고 이걸 처리하기 위해서는 두가지 방법이 있었다.

첫번째 방법은 EC2에 shell script를 작성해두고 Jenkins Job 설정 시 빌드 과정에 해당 스크립트를 실행하도록 해 application.yml 파일을 추가하는 방법.

두번째 방법은 Provide Configuration files를 체크해 Jenkins에서 작성해둔 application.yml 파일을 생성하도록 하는 방법.

 

두 방법 모두 사용해봤는데 개인적으로는 Provide Configuration files를 통해 처리하는게 더 쉬웠던 것 같다.

하지만 이것도 Job 설정 시 어떻게 처리하느냐에 따라 장단점이 존재할 것 같다.

 

일단 shell script 를 통해 처리하는 방법.

echo "application.yml 내용" > /var/lib/jenkins/project/src/main/resources/application.yml

 

이런식의 내용을 EC2 내부에서 000.sh 이런 식의 파일을 생성해준다.

그리고 Job 설정 중 Build Step에서 빌드 과정에 대한 스크립트를 작성하면서 해당 스크립트를 실행하는 명령어를 사용해주면 된다.

 

Provide Configuration Files를 처리하는 방법.

이 방법을 사용하기 위해서는 어떤 내용의 파일을 생성할 것인지 Jenkins에 설정해 둬야 한다.

 

Jenkins 관리 탭으로 이동해 System Configuration 하위의 Managed files를 클릭한다.

 

그럼 아래와 같은 페이지로 접근하게 되는데 Add a new Config를 눌러 추가해준다.

아래 이미지는 이미 추가해둔 파일들이고 아마 최초 접근 시에는 아무것도 없을 것이다.

 

여기서 생성할 타입을 선택하고 next로 넘어간다.

yml 또는 properties는 Properties file을 선택하면 되고 React의 .env같은 파일은 Custom file을 선택하면 된다.

ID는 자동 생성이기 때문에 그냥 Next!

 

여기에서는 Name과 Comment, Content를 작성한다.

Name은 파일의 이름을 작성해주면 된다. 이 Name이 그대로 파일명이 되는 것은 아니다.

Comment는 설명 정도.

Content에는 파일의 내용을 작성해주면 된다.

 

이렇게 필요한 Configuration file 들을 작성해 생성해주면 된다.

이걸 적용하는건 아래 Job 설정에서 마저 정리한다.

Jenkins Job 설정 및 Build 테스트

git clone을 통한 사전 배포 테스트가 정상적으로 수행되었기 때문에 Jenkins를 마저 설정하고 build 테스트까지 정리한다.

Jenkins 페이지에서 Job 을 새로 작성하기 위해 새로운 Item 버튼을 눌러 생성한다.

 

그럼 아래와 같은 페이지가 나온다.

Item name을 원하는 이름으로 작성해주고 Freestyle project를 선택한 뒤 OK 버튼을 클릭.

이때 Item name은 EC2 내에서 프로젝트 경로명이 되므로 너무 복잡하게 설정하면 나중에 피곤할 것 같다.

 

소스 코드 관리 탭에서는 Git에 올라가있는 프로젝트를 대상으로 할 것이기 때문에 GIt을 선택해준다.

Repository URL은 해당 프로젝트의 git url을 적어준다.

그리고 Credentials는 git 계정에 대한 정보인데 처음 생성하면 없을 것이므로 + Add 버튼을 눌러 생성해준다.

 

Add 버튼을 눌렀을 때 아래와 같은 창이 뜰 것이다.

git username과 비밀번호를 입력하고 Add 버튼을 눌러준다.

git에서는 personal Token을 사용하고 있어 해당 토큰 값을 비밀번호로 넣어줬다.

그러고보니 웹에서 로그인할 때 사용하는 비밀번호로는 테스트를 안해봤는데..

이후 webhook 연동할 때도 personal Token을 사용하기 때문에 없다면 다음 포스팅에서 git personal token 생성하는 부분을 먼저 보고 생성한 뒤 사용하시는 것이 좋을 것 같습니다.

 

Add 버튼을 눌러 Credentials를 생성하고 나면 생성된 Credentials를 선택할 수 있으니 선택해준다.

 

빌드 유발탭에서는 GitHub hook trigger for GITScm polling을 선택해준다.

다음 포스팅에서 git webhook과 연동할때 사용되는 건데 그때 수정하지 않기 위해 미리 체크한다.

git webhook 연동까지 처리하지 않을 것이라면 체크하지 않아도 된다.

 

빌드 환경 탭에서는 Provide Configuration files와 Provide Node & npm bin/folder to PATH를 체크한다.

Provide Node & npm bin/ folder to PATH의 경우 NodeJS가 필요하다면 체크하는 것이므로 자신의 환경에 NodeJS가 사용되지 않는다면 체크할 필요가 없다.

체크한다면 초반 Jenkins plugin 설치 이후 Tools의 NodeJS Installation에서 설정해뒀던 정보가 알아서 설정되어있기 때문에 따로 건드릴건 없다.

 

Configuration file에 대한 설정을 해두었다면 체크했을 때 아래와 같은 탭이 생성될 것이고 File에서는 생성한 파일들의 목록이 나올 것이다.

Target에는 경로를 설정해준다.

기본 시작 경로는 프로젝트 루트 경로이다.

그렇기 때문에 프로젝트 내부에서 src/main/resources 안에 위치하는 application.yml은 아래 이미지 처럼 작성해준다.

이때 파일명까지 작성해줘야 한다.

이 처리를 필요한 파일의 개수만큼 처리해주면 된다.

 

 

다음으로는 BuildSteps다.

Add build step 버튼을 누르면 여러 설정 중 선택해 처리할 수 있다.

여기에서도 두가지 선택지로 간단하게 처리할 수 있다.

가장 먼저 매우 간단한 Invoke Gradle script다.

빌드 과정에서 별다른 스크립트가 필요하지 않고 빌드만 하는 것으로 처리가 된다면 Invode Gradle script를 선택하는 것이 편하다.

 

아래와 같은 탭이 생길텐데 Use Gradle Wrapper를 선택하고 Make gradlew executable을 체크.

Wrapper location 에는 ${workspace}라고 작성하면 알아서 프로젝트 경로를 잡아준다.

Tasks에는 build 라고 작성해주는 것만으로 ./gradlew build 까지 수행하게 된다.

 

하지만 스크립트를 작성해 처리해야 할 것이 필요하다면 Execute shell을 선택해 처리한다.

이전에는 Spring, thymeleaf로 작성된 프로젝트를 배포해 Invoke Gradle script를 통해 간단히 처리할 수 있었으나 오류가 발생했기 때문에 Execute shell을 통해 처리했다.

 

프로젝트는 Spring Boot와 React의 통합 빌드를 처리하기 위해 build.gradle에 스크립트가 작성되어있다.

그래서 Invoke Gradle script 설정으로 간단하게 처리될 줄 알았는데 오산이었다.

install React FAILED 오류가 대체적으로 발생하였고 이 오류에 대한 해결방안으로 npm cache 초기화와 node_modules를 삭제하는 방법이 있었다.

 

그래서 빌드 수행 이전 해당 처리를 위해 아래 이미지처럼 스크립트를 작성했고 빌드를 수행하도록 처리했다.

 

추가적으로 통합 빌드 기준 이렇게 수행하더라도 Jenkins에서 React 경고를 오류로 인식해 빌드에 실패하는 경우가 있다.

그런 경우 npm run build 앞에 CI=false를 추가해 주면 되는데 이 문제에 대해서는 execute shell에 작성하는 것이 아닌 build.gradle에 작성해 문제를 해결했다.

 

마지막 Job 설정으로는 빌드 후 조치에 대한 설정을 해주면 끝난다.

빌드 후 조치로는 Post build task를 선택해준다.

빌드가 성공했다면 BUILD SUCCESSFUL이 찍히기 때문에 해당 로그가 찍혔을 때 스크립트가 동작하게 된다.

그래서 스크립트에는 jar 파일을 실행하도록 작성해둔다면 빌드에 성공했을 때 jar 파일을 실행해 서버가 배포된다.

 

여기까지 체크가 끝났다면 Apply 이후 저장!

 

그럼 Jenkins 페이지에서 해당 job으로 이동하고 지금 빌드 버튼을 눌렀을 때 Build History에 추가가 될 것이다.

성공한 경우 초록색 체크 표시가 뜨는데 jar 파일 실행까지 모두 작성한 경우에는 종료되지 않고 계속 돌아가고 있기 때문에 상태바가 거의 다 채워진 것 처럼 보일 때 도메인으로 접근해 서버가 동작하고 있는지 확인할 수 있다.

중단하기 위해서는 해당 히스토리의 오른쪽 상단 x 버튼을 누르면 서버가 중단된다.