자 이번에는 1편의 수동에서 GitAction을 사용해서 자동화로 만들어 보겠다.
Action 설정 이번에는 1편의 수동에서 GitAction을 사용해서 자동화로 만들어 보겠다.
Action 설정
깃허브에서 레퍼지스토리를 들어가면 위에 Actions 탭을 확인할 수 있다.
하지만 설정하기 전 워크플로우 구성을 먼저 해야 한다.
깃허브 변수를 추가해 주자. 사용자에 따라 옵션이지만 비용을 지불하고 사용하는 DB일수록 필수로 설정해주어야 한다.
변수 설정
위 페이지에서 sb환경변수와 민간함 정보 등을 관리할 수 있다.
특히 Spring boot의
- application.properties 와 yml 파일이나,
- EC2_HOST(설정) : ec2 접속 정보
- EC2_KEY(설정) : ec2 접속 정보
- EC2_USER(설정) : ec2 접속 정보
- AWS 시크릿키
등 추가해 주어야 한다.
(그렇지 않으면 운 나쁜 경우 해커들에 의해 무시무시한 요금폭탄을 받는다..!)
일단 지금은 왜 해야 하는지만 짚고 넘어가겠다.
Trigger 설정
우린 main 브런치에 git push를 하게 되면, 혹은 dev 브런치에, pull request를 하게 되면,
하위 github 내부 작업과 ec2 작업 들을 순서대로 진행하겠다!
~를 설정하는 것이다.
그렇다면 먼저 YML파일을 설정해 보도록 하겠다.
IntelliJ를 실행해 보자.
최상위 디렉터리에 `. github` 를 추가해 주자.
그다음. github > workflows > deploy.yml까지 순서대로 생성하면 된다.
yml에서는 필수 프로퍼티인 'jobs', 'on'가 포함되어야 한다.
먼저 jobs는 github내부설정과 EC2 작업 두 개로 나뉜다.
github내부 작업
- ubuntu linux 준비
- 프로젝트 checkout
- jdk 17 설치
- application.yml 동적 생성
- 보안 정보 세팅 (디비 주소, 계정)등
- build 준비
- 관리상 jar 파일명 변경
- jar 파일 ec2 업로드 (github -> 클라우드 내 지정한 서버로 업로드)
EC2 작업
- 접속
- jar 파일 위치 조정 (필요시)
- 반영됨
- 서버가동 (웹서비스 시작)
을 만들어줘야 한다.
먼저 해당 디렉터리에 만든 yml파일에 아래와 같이 추가해 주자.
name: Deploy for CI/CD
# Trigger the workflow on push
on:
# 원인: push
push:
# 브랜치: master(본인 브랜치 master or main...)
branches:
- master
# Jobs
jobs:
# job 이름: cicd-deploy
cicd-deploy:
# ubuntu-latest 환경에서 실행
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
# JDK 17 설치
- name: Set up JDK 17
uses: actions/setup-java@v4
with:
distribution: 'temurin'
java-version: '17'
추가적으로 아래의 페이지에 들어가면 Actions에 대한 많은 사용법 예시가 있으므로 필요한 건 확인하면 된다.
GitHub Actions
Automate your GitHub workflows. GitHub Actions has 74 repositories available. Follow their code on GitHub.
github.com
그다음 commit & push를 하면
이렇게 Actions탭에 새롭게 workflow가 추가되게 된다.
한번 들어가 보자.
아래의 경고문은 ubuntu-lastest의 버전에 대한 경고문이므로 무시하면 된다.
이제 cicd-deploy를 클릭해 보자.
내가 설정한 Jobs들을 세부적으로 확인할 수 있다.
이건 Github 내부에서 작동하는 것으로, 즉 JDK는 AWS가 아닌 Github 내부 클라우드에서 작동하는 것이다.
자 이제 다음으로 넘어가 보자.
Build 추가
Gradle을 build 하기 위해 아래 코드를 추가한다.
# build 준비
- name: Build with Gradle
run: ./gradlew clean build
그리고 Commit & Push를 하면 잘 작동하는 사람도 있을 텐데
이처럼 오류가 뜰 수 있다.
한번 자세히 가서 뜯어보자!
Permission denied 메시지는 1편에서도 설정했던 권한 문제이다.
해결하기 위해선 `chmod +x./gradlew` 를 추가하면 된다.
# build 준비
- name: Build with Gradle
run: |
chmod +x gradlew
./gradlew clean build
자 그렇다면 다시 가서 봐보면!
빌드가 진행 중이다! 이렇게 gradle build까지 완료하게 되었다.
파일이름 변경
이제 빌드된 Jar파일을 확인해 보자.
그리고 이름까지 한 번에 바꿔보도록 하겠다.
# build 준비
- name: Build with Gradle
# 커미션 > 빌드 > libs > *.jar
run: |
chmod +x gradlew
./gradlew clean build
ls ./build/libs
- name: Change file name
run: |
mv ./build/libs/*SNAPSHOT.jar ./springboot-aws.jar
ls ./build/libs
위와 같은 결과가 나오는데 40, 41 라인은 `ls./build/libs` 에 대한 출력이며,
아래 2 라인을 보면 이름을 잘 변경되었다는 것을 알 수 있다.
그다음은 EC2로 업로드만 하면 GitAction에서 해야 할 일은 끝났으며 해당 설정을 얼른 해주자.
Secret 변수 설정
EC2로 업로드하기 위해선 아래와 같은 종류가 필요하다.
- 호스트 정보 `IP`
- 접속자 명 `ubuntu` (확인)
- 키파일 `pem`
- 업로드 대상 `springboot-aws.jar`
- 타깃의 업로드 경로
여기서 ip, 접속자명, 키파일은 개인정보가 포함되어 있으므로 secret으로 넘겨야 한다.
다시 깃허브의 Secret설정으로 넘어가자.
먼저 IP를 추가해 주겠다. 아래는 AWS IP를 입력하는데,
이처럼 ip주소가 바뀌면 그때마다 설정이 바꿔야 하므로 전에 배운 탄력적 IP를 사용하면 좋다.
그다음 키파일을 열어 전부 복사하고,
이렇게 전부 복사해 주면 된다.
변수 3개가 추가되면 완료!
EC2에 업로드
다음은 아래를 해결해 보자.
- 업로드 대상 `springboot-aws.jar`
- 타깃의 업로드 경로
- name: Upload .jar to EC2
uses: appleboy/scp-action@v0.1.7
with:
host: ${{ secrets.EC2_HOST }}
username: ${{ secrets.EC2_USER }}
key: ${{ secrets.EC2_KEY }}
source: ./springboot-aws.jar
target: /home/${{ secrets.EC2_USER }}/server/demo
자 우리가 위에서 만든 변수들을 입력해 주고, source 에는 업로드 파일, target에 경로를 입력해 주면 된다.
커밋해 보면...
성공적으로 되었다고 나온다.
만약 29라인에서 폴더가 없다고 나오면
AWS console에서 생성해 주자!
mkdir -p ~/server/demo
이제 AWS Console에서 확인해 보자.
잘 이동되었다!
자 이제 마지막 3편에서 마무리하겠다.
'SK 루키즈 > Cloud' 카테고리의 다른 글
[Rookies 개발 2기] 스프링부트 + GitAction + CI/CD (4) (2) | 2025.01.17 |
---|---|
[Rookies 개발 2기] 스프링부트 + GitAction + CI/CD (3) (0) | 2025.01.17 |
[Rookies 개발 2기] VPC 기본 개념 및 설정 (0) | 2025.01.16 |
[Rookies 개발 2기] 스프링부트 + GitAction + CI/CD (1) (3) | 2025.01.16 |
[Rookies 개발 2기] AWS에 Java Spring 프로젝트를 올려보자 (2) (0) | 2025.01.16 |