[Spring boot] CI/CD 프로젝트에 적용해보기!

하비·2023년 11월 14일
JPASpring bootawscdciec2git actionrds
0

HOW

목록 보기
4/5

네~ 갑자기 자동배포로 훌쩍 뛰어넘었습니다

원래 포스팅을 프로젝트에서 적용한 순서대로 상세히 적는게 목표였으나 제가 오늘 CI/CD를 성공한게 너무 기뻐서 이 기쁨을 나누고, 더 새록새록 기억이 날 때 남기고자 작성하게 되었습니다!

블로그를 쓰면서는 많은 분들이 보실 수 있어서 좀 더 자세히 알아보고, 좀 더 가공을 하다보니 시간이 오래 걸리더라고요
프로젝트를 하면서는 시간이 없으니까 노션에 날 것으로 필요한 이미지랑 소스들만 휙휙 던져놓고, 나중에 시간될 때 블로그 포스팅을 하는 방식으로 쓰고 있답니다

현재 프로젝트 막바지에 접어들었는데요, 이번 CI/CD 부분은 제가 수업시간에 배웠던 내용을 바탕으로 제 프로젝트에 적용하였던 내용입니다

수업 시간에 배웠던 걸 그대로 적용하려고 보니, 웬걸 실습 예제 코드가 node로 되어 있더라고요?! 그리고 workflow의 deploy.yml과 scipts의 start.sh, stop.sh도 모두 써져 있어 쉬웠던 것이었습니다.ㅎㅎㅎ

저는 이 알려주지 않은 부분과 spring boot에 적용, 그리고 git ignore에 의해 숨겨진 파일들을 처리하느라 애를 좀 먹었습니다.

저는 이 부분은 이 블로그를 참고했습니다!

https://velog.io/@vector13/Springboot-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-Github-Action%EC%9D%84-%EC%9D%B4%EC%9A%A9%ED%95%B4%EC%84%9C-%EB%B0%B0%ED%8F%AC-%EC%9E%90%EB%8F%99%ED%99%94%ED%95%98%EA%B8%B0#4-codedeploy-%EC%83%9D%EC%84%B1

나중에 client 부분 CI/CD도 해서 server랑 연결하는 것까지 해보겠습니다~

지금은 서버만이에요!
일단 제 환경은 이렇습니다.

  1. git에 코드가 있다. (git 연동)
  2. ec2에 git clone을 받은 상태다.
  3. ec2에서 git pull을 한 후 빌드를 하는 수동 배포 스크립트가 작성되어 있고, 수동 배포를 하고 있다.
  4. 데이터베이스는 aws의 rds를 사용하고 있고, mysql이다.
  5. 프록시 서버를 ngnix를 이용해 무중단 배포를 하고 있는 상황이다.
  6. ec2의 os는 ubuntu이고, 로컬 os는 window다.

이제 시작해봅시다~!

작동 방식은 다음과 같습니다.
1. git action에서 프로젝트 빌드 후 파일들을 압축해서 S3 버킷에 업로드해줍니다.
2. git action에서 Code Deploy를 실행합니다.
3. Code Deploy에서 EC2에 appsec.yml에 쓰여있는 배포 명령을 내리게 됩니다.
4. EC2에서 S3에 압축된 파일을 가져옵니다.

1. IAM 사용자

1-1. 액세스 키 생성

IAM->사용자->보안 자격 증명->액세스 키->액세스 키 만들기를 클릭해줍니다.

github에서 aws 연결을 위한 액세스 키(id, secrets으로 구성)를 생성하고 csv 파일을 다운로드해줍니다.
이건 나중에 git secret에서 넣어주게 됩니다.

1-2. IAM 역할 수정

  1. ec2->인스턴스 선택->작업->보안->IAM 역할 수정
  2. 새 IAM 역할 생성
  3. 역할 만들기 클릭
  4. AWS 서비스, EC2 선택 후 다음 클릭
  5. 권한 정책에서
    S3 검색->AmazonS3FullAccess 선택,
    SSM 검색 → AmazonSSMFullAccess 선택,
    CodeDeploy → AWSCodeDeployRole 선택
  6. 다음으로 넘어가서 역할 이름 입력
  7. 권환 확인 후 역할 생성 버튼 클릭
  8. 역할에서 생성한 role로 접근하고 신뢰 관계 탭에서 신뢰 정책 편집 버튼을 누른다.
  9. Service 파트를 배열로 변경한 후 "codedeploy.ap-northeast-2.amazonaws.com"를 추가하고 정책 업데이트를 눌러준다.
  10. EC2 IAM 역할 수정으로 돌아와서 새로고침 후 생성한 IAM 역할을 선택하고 IAM 역할 업데이트를 클릭한다.

2. CodeDeploy 구성

2-1. 배포 애플리케이션 생성

  1. AWS에서 CodeDeploy를 검색한 후 애플리케이션 탭으로 가서 애플리케이션 생성을 누른다.
  2. 이름을 입력한 후, EC2를 선택하고 애플리케이션 생성 버튼을 누른다.

2-2. 배포 그룹 생성

  1. 만든 애플리케이션에서 배포 그룹 생성을 눌러준다.
  2. 이름을 입력한 후, 1-2의 6번에서 만들었던 역할을 입력해줍니다.
  3. Amazon EC2 인스턴스를 선택하고, 키-값으로 연결하고자 하는 EC2를 연결해줍니다.
  4. 로드밸런싱 체크 해제 후 배포 그룹 생성 버튼을 눌러줍니다.

3. S3 생성

GitActions에서 코드 압축 후 저장할 S3 버킷을 생성해줄겁니다.
버킷 이름만 입력한 후에 버킷 만들기를 해줍니다.

4. Github Secrets 등록

4-1. Secrets 생성

git repository에서 settings->Actions->Secrets을 클릭합니다.
그리고 새로운 secret 키를 생성해줍니다.

  • AWS_ACCESS_KEY_ID : 1-1에서 생성한 IAM user 액세스 csv 파일에서 확인
  • AWS_SECRET_ACCESS_KEY : 1-1에서 생성한 IAM user 액세스 csv 파일에서 확인
  • BUCKET_NAME : 3에서 생성한 버킷 이름
  • CODEDEPLOY_APP_NAME : 2-1에서 생성한 배포 에플리케이션 이름
  • CODEDEPLOY_DG_NAME : 2-2에서 생성한 배포 그룹 이름

5. Github Action

이제 github action을 위한 workflow 코드를 입력해줘야 합니다.
여기서부터는 수업 시간에 배운 부분과 달라 다음 블로그를 참고했습니다!

https://velog.io/@vector13/Springboot-프로젝트-Github-Action을-이용해서-배포-자동화하기#4-codedeploy-생성

먼저, git respository에서 Action에 들어가줍니다.

여기에서 Java with Gradle이라고 써져 있는 Configure 버튼을 클릭해줬습니다.
그러면 다음과 같은 코드가 자동으로 써집니다.

  • workflows/gradle.yml
# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
# documentation.
# This workflow will build a Java project with Gradle and cache/restore any dependencies to improve the workflow execution time
# For more information see: https://help.github.com/actions/language-and-framework-guides/building-and-testing-java-with-gradle

name: Spring Boot & Gradle CI/CD 

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

permissions:
  contents: read

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Set up JDK 11
      uses: actions/setup-java@v3
      with:
        java-version: '11'
        distribution: 'temurin'
    - name: Grant execute permission for gradlew
      run: chmod +x gradlew
    - name: Build with Gradle
      # uses: gradle/gradle-build-action@67421db6bd0bf253fb4bd25b31ebb98943c375e1
      # with:
        # arguments: build
      run : ./gradlew clean build

저는 JDK를 17로 썼기 때문에 java-version을 17로 바꿔주었습니다.

  • workflows/gradle.yml
# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
# documentation.
# This workflow will build a Java project with Gradle and cache/restore any dependencies to improve the workflow execution time
# For more information see: https://help.github.com/actions/language-and-framework-guides/building-and-testing-java-with-gradle

name: Spring Boot & Gradle CI/CD 

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

permissions:
  contents: read

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Set up JDK 17
      uses: actions/setup-java@v3
      with:
        java-version: '17'
        distribution: 'temurin'
    - name: Grant execute permission for gradlew
      run: chmod +x gradlew
    - name: Build with Gradle
      # uses: gradle/gradle-build-action@67421db6bd0bf253fb4bd25b31ebb98943c375e1
      # with:
        # arguments: build
      run : ./gradlew clean build

이제 git Action에 들어가면 build 결과를 확인할 수 있습니다.

빌드 오류 1


저는 다음과 같은 에러가 나왔고, 원인은 git ignore에 main 함수가 담겨있는 HowApplication을 등록해놔서 그런 것이었습니다. 그래서 git ignore에서 HowApplication을 빼주고, git에 업로드 해줬더니 해결되었습니다.

빌드 오류 2


그 다음엔 참고했던 블로그에서 나온 것처럼 똑같은 오류가 났고, test 관련 빌드 때문에 생긴 것이라 테스트를 스킵하고 빌드하는 걸로 코드를 변경했습니다.

# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
# documentation.
# This workflow will build a Java project with Gradle and cache/restore any dependencies to improve the workflow execution time
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-java-with-gradle

name: Java CI with Gradle

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

permissions:
  contents: read

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Set up JDK 17
      uses: actions/setup-java@v3
      with:
        java-version: '17'
        distribution: 'temurin'
    - name: Grant execute permission for gradlew
      run: chmod +x gradlew
    - name: Build with Gradle
      #uses: gradle/gradle-build-action@bd5760595778326ba7f1441bcf7e88b49de61a25 # v2.6.0
      #with:
        #arguments: build
      run : ./gradlew clean build --exclude-task test

빌드 해결

S3 업로드

이제 빌드된 파일들을 압축해서 만들었던 S3 버킷에 업로드를 해줄겁니다.

  • gradle.yml
# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
# documentation.
# This workflow will build a Java project with Gradle and cache/restore any dependencies to improve the workflow execution time
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-java-with-gradle

name: Java CI with Gradle

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

permissions:
  contents: read

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Set up JDK 17
      uses: actions/setup-java@v3
      with:
        java-version: '17'
        distribution: 'temurin'
    - name: Grant execute permission for gradlew
      run: chmod +x gradlew
    - name: Build with Gradle
      #uses: gradle/gradle-build-action@bd5760595778326ba7f1441bcf7e88b49de61a25 # v2.6.0
      #with:
        #arguments: build
      run : ./gradlew clean build --exclude-task test

    # 전송할 파일을 담을 디렉토리 생성
    - name: Make Directory for deliver
      run: mkdir /var/www/deploy

    # Jar 파일 Copy
    - name: Copy Jar
      run: cp ./build/libs/*.jar /var/www/deploy

    # 파일 및 폴더를 압축하여 server.zip으로 저장
    - name: zip distributions
      run: zip -r server.zip /var/www/deploy
    
    # AWS 인증 정보 설정
    - name: AWS configure credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ap-northeast-2

    # S3로 압축 파일 업로드
    - name: upload to S3
      run: aws s3 cp --region ap-northeast-2 /var/www/deploy/server.zip s3://${{secrets.BUCKET_NAME}}/public/

    # AWS CodeDeploy를 사용하여 배포
    - name: deploy with AWS codeDeploy
      run: aws deploy create-deployment
        --application-name ${{secrets.CODEDEPLOY_APP_NAME}}
        --deployment-config-name CodeDeployDefault.OneAtATime
        --deployment-group-name ${{secrets.CODEDEPLOY_DG_NAME}}
        --s3-location bucket=${{secrets.BUCKET_NAME}},bundleType=zip,key=public/server.zip

빌드 오류 3


directory를 생성할 권한이 없다고 떠서 sudo를 붙여줬습니다.

# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
# documentation.
# This workflow will build a Java project with Gradle and cache/restore any dependencies to improve the workflow execution time
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-java-with-gradle

name: Java CI with Gradle

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

permissions:
  contents: read

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Set up JDK 17
      uses: actions/setup-java@v3
      with:
        java-version: '17'
        distribution: 'temurin'
    - name: Grant execute permission for gradlew
      run: chmod +x gradlew
    - name: Build with Gradle
      #uses: gradle/gradle-build-action@bd5760595778326ba7f1441bcf7e88b49de61a25 # v2.6.0
      #with:
        #arguments: build
      run : ./gradlew clean build --exclude-task test

    # 전송할 파일을 담을 디렉토리 생성
    - name: Make Directory for deliver
      run: sudo mkdir /var/www/deploy

    # Jar 파일 Copy
    - name: Copy Jar
      run: sudo cp ./build/libs/*.jar /var/www/deploy

    # 파일 및 폴더를 압축하여 server.zip으로 저장
    - name: zip distributions
      run: sudo zip -r server.zip /var/www/deploy
    
    # AWS 인증 정보 설정
    - name: AWS configure credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ap-northeast-2

    # S3로 압축 파일 업로드
    - name: upload to S3
      run: aws s3 cp --region ap-northeast-2 /var/www/deploy/server.zip s3://${{secrets.BUCKET_NAME}}/public/

    # AWS CodeDeploy를 사용하여 배포
    - name: deploy with AWS codeDeploy
      run: aws deploy create-deployment
        --application-name ${{secrets.CODEDEPLOY_APP_NAME}}
        --deployment-config-name CodeDeployDefault.OneAtATime
        --deployment-group-name ${{secrets.CODEDEPLOY_DG_NAME}}
        --s3-location bucket=${{secrets.BUCKET_NAME}},bundleType=zip,key=public/server.zip

빌드 오류 4


파일 및 폴더를 압축(server.zip)하는 곳을 바꿔주었습니다.

# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
# documentation.
# This workflow will build a Java project with Gradle and cache/restore any dependencies to improve the workflow execution time
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-java-with-gradle

name: Java CI with Gradle

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

permissions:
  contents: read

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Set up JDK 17
      uses: actions/setup-java@v3
      with:
        java-version: '17'
        distribution: 'temurin'
    - name: Grant execute permission for gradlew
      run: chmod +x gradlew
    - name: Build with Gradle
      #uses: gradle/gradle-build-action@bd5760595778326ba7f1441bcf7e88b49de61a25 # v2.6.0
      #with:
        #arguments: build
      run : ./gradlew clean build --exclude-task test

    # 전송할 파일을 담을 디렉토리 생성
    - name: Make Directory for deliver
      run: sudo mkdir /var/www/deploy

    # Jar 파일 Copy
    - name: Copy Jar
      run: sudo cp ./build/libs/*.jar /var/www/deploy/

    # 만든 디렉토리로 이동
    - name: into deploy
      run: cd /var/www/deploy

    # 파일 및 폴더를 압축하여 server.zip으로 저장
    - name: zip distributions
      run: sudo zip -r server.zip .
    
    # AWS 인증 정보 설정
    - name: AWS configure credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ap-northeast-2

    # S3로 압축 파일 업로드
    - name: upload to S3
      run: aws s3 cp --region ap-northeast-2 server.zip s3://${{secrets.BUCKET_NAME}}/public/

    # AWS CodeDeploy를 사용하여 배포
    - name: deploy with AWS codeDeploy
      run: aws deploy create-deployment
        --application-name ${{secrets.CODEDEPLOY_APP_NAME}}
        --deployment-config-name CodeDeployDefault.OneAtATime
        --deployment-group-name ${{secrets.CODEDEPLOY_DG_NAME}}
        --s3-location bucket=${{secrets.BUCKET_NAME}},bundleType=zip,key=public/server.zip

드디어 빌드 성공!

S3 버킷을 보면 server.zip이 잘 업로드되어 있는 것을 볼 수 있습니다.

굿~~~


아직 ec2에 관련된 코드는 없기 때문에 ec2에는 폴더가 없습니다. (저는 이때까지만 해도 빌드된 파일이 자동으로 ec2에 저장되는 줄 알았답니다. 자세히 보니 ec2 관련된 코드가 없더군요)

6. EC2에 배포(CodeDeploy)

ec2에 배포를 하기 위해서는 appspec.yml이라는 파일을 생성해줘야 합니다.

  • appspec.yml
version: 0.0           # appspec 파일의 버전을 지정
os: linux              # 운영 체제 지정

files:                 # 배포될 파일 및 디렉터리에 대한 정보
  - source: /          # 소스 디렉터리 지정 (루트 디렉터리)
    destination: /var/www/deploy  # 대상 디렉터리 지정
    overwrite: yes     # 이미 존재하는 파일 또는 디렉터리를 덮어쓸지 결정

hooks:                 # 배포 생명주기 이벤트에 대한 스크립트 지정
  ApplicationStop:    # 애플리케이션 중지 전에 실행될 스크립트
    - location: scripts/stop.sh   # 실행할 스크립트 위치
      runas: root                 # 스크립트를 실행할 사용자 지정 (여기서는 root 사용자로 실행)
  ApplicationStart:   # 애플리케이션 시작 전에 실행될 스크립트
    - location: scripts/start.sh   # 실행할 스크립트 위치
      runas: root                  # 스크립트를 실행할 사용자 지정 (여기서는 root 사용자로 실행)

배포 스크립트 작성

  • scripts/start.sh
#!/usr/bin/env bash

PROJECT_ROOT="/var/www/deploy"
JAR_FILE="$PROJECT_ROOT/ryulSpring.jar"

APP_LOG="$PROJECT_ROOT/application.log"
ERROR_LOG="$PROJECT_ROOT/error.log"
DEPLOY_LOG="$PROJECT_ROOT/deploy.log"

TIME_NOW=$(date +%c)

# build 파일 복사
echo "$TIME_NOW > $JAR_FILE 파일 복사" >> $DEPLOY_LOG
cp $PROJECT_ROOT/build/libs/*.jar $JAR_FILE

# jar 파일 실행
echo "$TIME_NOW > $JAR_FILE 파일 실행" >> $DEPLOY_LOG
nohup java -jar $JAR_FILE > $APP_LOG 2> $ERROR_LOG &

CURRENT_PID=$(pgrep -f $JAR_FILE)
echo "$TIME_NOW > 실행된 프로세스 아이디 $CURRENT_PID 입니다." >> $DEPLOY_LOG
  • scripts/stop.sh
#!/usr/bin/env bash

PROJECT_ROOT="/var/www/deploy"
JAR_FILE="$PROJECT_ROOT/ryulSpring.jar"

DEPLOY_LOG="$PROJECT_ROOT/deploy.log"

TIME_NOW=$(date +%c)

# 현재 구동 중인 애플리케이션 pid 확인
CURRENT_PID=$(pgrep -f $JAR_FILE)

# 프로세스가 켜져 있으면 종료
if [ -z $CURRENT_PID ]; then
  echo "$TIME_NOW > 현재 실행중인 애플리케이션이 없습니다" >> $DEPLOY_LOG
else
  echo "$TIME_NOW > 실행중인 $CURRENT_PID 애플리케이션 종료 " >> $DEPLOY_LOG
  kill -9 $CURRENT_PID
fi

제가 수동 배포했던 스크립트와 비교를 해보니 git pull, 빌드 부분 빼고, 나머지를 jar 파일 실행 부분과 애플리케이션 종료 부분으로 나눈 것 같습니다.

  • 수동 배포 스크립트 파일
#!/bin/bash

REPOSITORY=/var/www
PROJECT_NAME=Backend

cd $REPOSITORY/$PROJECT_NAME/

echo "> Git Pull"

git add .
git pull

echo "> 프로젝트 Build 시작"

./gradlew build

echo "> /var/www 디렉토리로 이동"

cd $REPOSITORY

echo "> Build 파일 복사"

cp $REPOSITORY/$PROJECT_NAME/build/libs/*.jar $REPOSITORY/

echo "> 현재 구동중인 애플리케이션 pid 확인"

CURRENT_PID=$(pgrep -f how.*.jar)

echo "현재 구동 중인 애플리케이션 pid: $CURRENT_PID"

if [ -z "$CURRENT_PID" ]; then
        echo "현재 구동 중인 애플리케이션이 없으므로 종료하지 않습니다."
else
        echo "> kill -15 $CURRENT_PID"
        kill -15 $CURRENT_PID
        sleep 5
fi

echo "> 새 애플리케이션 배포"

JAR_NAME=$(ls -tr $REPOSITORY/ | grep jar | tail -n 1)

echo "> JAR Name: $JAR_NAME"

nohup java -jar $REPOSITORY/$JAR_NAME 2>&1 &

git Action의 빌드가 성공했기 때문에 바로 적용이 되는지 확인해보기 위해 코드를 바꿔주었습니다.

live 등록 @operation 부분에 "(수정 필요)"라고 써놔봤습니다.
결과는

변화가 없었습니다..ㅇㅁㅇ
분명 git action에서 빌드는 잘 됐는데 대체 뭐가 문제인걸까 살펴보았습니다.

배포 실패


이런! aws의 CodeDeploy에서 배포가 실패되고 있었습니다. 빨간색이 주르르륵....눈이 아프군요

제일 마지막으로 실행한 배포를 클릭해보니 다음과 같은 오류가 나왔었습니다.

참고: https://github.com/jojoldu/freelec-springboot2-webservice/issues/80

이분도 저와 똑같은 오류가 발생했었습니다.


혼자 오류를 해결한 모습이 멋있네요 저도 저렇게 되고 싶습니다☺️
이분이 해결한 것처럼 저도 /var/log/aws/codedeploy-agent 경로에 위치한 로그를 확인해보았습니다.

이런 오류가 떴습니다. stop.sh가 없다는 얘기인데, 분명 생성해줬는데 왤까요?

참고: https://stackoverflow.com/questions/40013282/script-does-not-exist-at-specified-location

stackoverflow 형님께서 자신도 그런 적이 있다. 경로랑 파일이 잘못되지 않았는데 저렇게 됐다고 합니다.
그래서 code deploy agent를 멈추고, deploy 파일을 지우고, 다시 시작해줬다고 합니다.

저도 다음과 같이 명령어를 실행시켜줬습니다.

sudo service codedeploy-agetn stop
sudo rm -r /opt/codedeploy-agent/deployment-root
sudo service codedeploy-agent start

## 실행 중인지 확인
sudo service codedeploy-agent start

배포 성공


역시 스택오버플로우 형님들 짱짱!


그러면 이제 ec2에 해당 폴더에 코드 파일들이 잘 있는걸 볼 수 있습니다.(감격)

ngnix 파일 수정

저는 이제 ngnix를 프록시 서버로 사용하고 있었기 때문에 ngnix에서 실행할 파일의 경로를 바꿔주었습니다.

vi /etc/nginx/sites-available/default
## 수정하고 nginx 다시 시작
systemctl restart nginx


원래는 root /var/www/Backend 였지만 deploy로 바꿔주었습니다.

실행 실패 1

이렇게 바꿔주었는데, 반영이 안됩니다.
대체 뭐가 잘못 된걸까요
이젠 log와 정말 친해진 것 같습니다.
벌써 정이 들어버렸어요(log는 내 칭긔칭긔~)
이번엔 deploy 폴더에 있는 log 파일을 보도록 하겠습니다.

여기 있는 파일 중 deploy.log는 실행했던 log이고, error.log는 에러가 난 부분이 적혀있습니다.

vi error.log


ryulSpring.jar를 접근할 수 없다고 합니다.
ls를 했을 때 jar 파일이 없어서 의아하긴 했는데, 역시 이것 때문이었나봅니다.
대체 왜 생성이 안될걸까요

쉘에 명령어를 쳤을 때 잘되는지 확인해보았습니다.

음 이 오류 때문 같은데

  • start.sh
#!/usr/bin/env bash

PROJECT_ROOT="/var/www/deploy"
#JAR_FILE="$PROJECT_ROOT/ryulSpring.jar"

APP_LOG="$PROJECT_ROOT/application.log"
ERROR_LOG="$PROJECT_ROOT/error.log"
DEPLOY_LOG="$PROJECT_ROOT/deploy.log"

TIME_NOW=$(date +%c)

# build 파일 복사
echo "$TIME_NOW > jar 파일 복사" >> $DEPLOY_LOG
cp $PROJECT_ROOT/build/libs/*.jar $PROJECT_ROOT/

# jar 찾기
JAR_FILE=$(ls -tr $PROJECT_ROOT/ | grep jar | tail -n 1)
echo "JAR Name: $JAR_FILE" >> $DEPLOY_LOG

# jar 파일 실행
echo "$TIME_NOW > $JAR_FILE 파일 실행" >> $DEPLOY_LOG
nohup java -jar $PROJECT_ROOT/$JAR_FILE > $APP_LOG 2> $ERROR_LOG &

CURRENT_PID=$(pgrep -f $JAR_FILE)
echo "$TIME_NOW > 실행된 프로세스 아이디 $CURRENT_PID 입니다." >> $DEPLOY_LOG
  • stop.sh
#!/usr/bin/env bash

PROJECT_ROOT="/var/www/deploy"

DEPLOY_LOG="$PROJECT_ROOT/deploy.log"

TIME_NOW=$(date +%c)

# jar 찾기
JAR_FILE=$(ls -tr $PROJECT_ROOT/ | grep jar | tail -n 1)
echo "JAR Name: $JAR_FILE" >> $DEPLOY_LOG

# 현재 구동 중인 애플리케이션 pid 확인
CURRENT_PID=$(pgrep -f $PROJECT_ROOT/$JAR_FILE)

# 프로세스가 켜져 있으면 종료
if [ -z $CURRENT_PID ]; then
  echo "$TIME_NOW > 현재 실행중인 애플리케이션이 없습니다" >> $DEPLOY_LOG
else
  echo "$TIME_NOW > 실행중인 $CURRENT_PID 애플리케이션 종료 " >> $DEPLOY_LOG
  kill -9 $CURRENT_PID
fi

어떻게 해도 directory가 아니라고 떠서
제 수동 배포 스크립트를 참고해서 jar 파일을 찾아서 복사해서 넣어주는 걸로 코드를 변경했습니다.

거의 다 왔습니다!!! 이젠 error.log에 아무것도 안뜹니다!!

실행 실패 2

이제는 application.log를 봐줘야 합니다.

역시 database 오류였습니다. 왜냐하면 제 git에는 git inore 때문에 database 정보가 있는 application.yml이 없기 때문이죠 (이미 예상하고 있었다!)
이제 이것만 해결되면 모든게 끝날 것 같습니다!!

여기서 고민을 좀 했습니다.
1. 수동 배포할 때처럼 ec2에 직접 application.yml을 추가하면 될까?
2. 추가했을 때, ec2에 코드가 배포될 때마다 application.yml은 사라질까?

결과를 말하자면 yml 파일은 사라지지 않았지만 여전히 똑같은 오류가 떴었습니다.
역시 git에서 빌드할 때 application.yml이 같이 있어야하는 것 같습니다.
이미 git action에서 빌드돼서 ec2에서는 실행할 수 있는 jar만 실행하기 때문이죠

7. Git Secret으로 민감정보 관리

참고: https://velog.io/@sun1203/Github-Action-Spring-Application.properties-민감정보-관리하기

여기에서 나온 것처럼 secret에 아예 application.yml의 내용을 넣어놓고, deploy할 때 application.yml을 생성해주는 방식으로 하겠습니다.

gradle.yml 파일에서 파란색으로 표시된 부분을 추가해줬습니다. (먼저 secret에 APPLICATION과 값에 application.yml 내용을 넣어주세요)

최종 성공!!!!!!!!!


드디어 성공!!!!!!!!! 정말 굉장한 사투였습니다. start라는 말이 이렇게 반갑네요

수정된 코드도 잘 반영이 된걸 볼 수 있습니다~

만약, 아래 그림과 같이 뜬다면

lsof -i TCP:8080
kill -9 {삭제하고자 하는 pid} //-9는 kill의 강제 종료 시그널인 9번을 사용한다는 의미다.

를 해주고, 배포 재시도를 하면 잘 될겁니다~


33트만에 성공

자동 배포하니까 선사시대에서 IT 시대로 온 듯한 기분이 드네요 아주 좋습니다b

profile
하비
멋진 개발자가 될테야
이전 포스트

[Spring boot] JWT와 Swagger JWT 적용하기

다음 포스트

[Spring boot] Stomp와 SockJS를 사용해 실시간 운동 라이브 방 만들기 - 1

0개의 댓글

관련 채용 정보