Github Actions의 자동 배포 문제 수정

이전 포스팅에서 Github Action을 통한 자동 배포에 성공했습니다. 그러나 문제가 발생하여 이 deploy.yml을 사용하면 현재 모든 파일이 EC2에 업로드됩니다. 그러면 당연히 관리가 필요한 서브모듈에서 생성된 정보까지 EC2에 업로드된다. 도저히 안되겠어서 다른 방법을 찾아봤습니다.

쉬운 목차

목표

목표는 4개의 appspec.yml, .jar 파일, start.sh 및 stop.sh만 EC2에 업로드하는 것입니다.

CodeDeploy 동작

CodeDeploy는 ZIP 파일을 허용합니다. jar 파일은 허용되지 않습니다.
EC2에 업로드하기 전에 ZIP 파일이 자동으로 압축 해제되고 appspec.yml이 실행됩니다.
이제 appspec.yml의 코드에 따라 코드가 실행됩니다.

프로세스를 이해

Github 리포지토리로 푸시합니다.
워크플로는 githubAction에서 실행됩니다.
1. 워크플로는 하위 모듈을 확인합니다.
2. 짓다. (JAR 파일 생성)
3. 위의 4개 파일을 압축합니다.
4. AWS로 인증합니다.
5. ZIP 파일을 S3에 업로드
6. CodeDeploy로 보내기
CodeDeploy에서 ZIP 파일 압축 해제
appspec.yml 실행
stop.sh, start.sh 순서대로 실행!!

실제 코드

이제 흐름을 이해했으므로 직접 deploy.yml을 작성하여 구현했습니다.

'추천 관련글,

배포.yml

name: Deploy to Amazon EC2

on:
  push:
    branches: ( "main" )

env:
  AWS_REGION: ap-northeast-2
  S3_BUCKET_NAME: todaysgym-github-actios-s3-bucket
  CODE_DEPLOY_APPLICATION_NAME: todaysgym-codedeploy-app
  CODE_DEPLOY_DEPLOYMENT_GROUP_NAME: todaysgym-codedeploy-deployment-group

permissions:
  contents: read

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    environment: production

    steps:
    # (1) 기본 체크아웃
    - name: Checkout
      uses: actions/checkout@v3

    # (2) JDK 11 세팅
    - name: Set up JDK 11
      uses: actions/setup-java@v3
      with:
        distribution: 'temurin'
        java-version: '11'
        
    # (3) 서브 모듈 접근하기
    - name: Checkout repo
      uses: actions/checkout@v3
      with:
        token: ${{ secrets.TOKEN }}
        submodules: true

    # (4) 서브 모듈 변경 점 있으면 update
    - name: Git Sumbodule Update
      run: |
        git pull --recurse-submodules
        git submodule update --remote --recursive

    # (5) gradle 권한 변경
    - name: Run chmod to make gradlew executable
      run: chmod +x ./gradlew

    # (6) Gradle build (Test 제외)
    - name: Build with Gradle
      uses: gradle/gradle-build-action@0d13054264b0bb894ded474f08ebb30921341cee
      with:
        arguments: clean build -x test
	
    # (7) 원하는 파일 Zip 하기
    - name: Zip build file and deploy sh
      run: |
        mv ./build/libs/*.jar ./
        zip buildFile.zip ./appspec.yml ./*.jar ./scripts/start.sh ./scripts/stop.sh

    # (8) AWS 인증 (IAM 사용자 Access Key, Secret Key 활용)
    - name: Configure AWS 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: ${{ env.AWS_REGION }}

    # (9) 빌드 결과물을 S3 버킷에 업로드
    - name: Upload to AWS S3
      run: |
        aws s3 cp \
          --region ap-northeast-2 \
          buildFile.zip s3://$S3_BUCKET_NAME/community-build/

    # (10) S3 버킷에 있는 파일을 대상으로 CodeDeploy 실행
    - name: Deploy to AWS EC2 from S3
      run: |
        aws deploy create-deployment \
          --application-name ${{ env.CODE_DEPLOY_APPLICATION_NAME }} \
          --deployment-config-name CodeDeployDefault.AllAtOnce \
          --deployment-group-name ${{ env.CODE_DEPLOY_DEPLOYMENT_GROUP_NAME }} \
          --s3-location bucket=$S3_BUCKET_NAME,key=community-build/buildFile.zip,bundleType=zip

이전 글의 코드와 거의 비슷하지만 압축하는 부분과 S3에 업로드하는 부분이 다릅니다.

s3는 cp로 복사 및 이동되었습니다.

그러면 코드가 성공적으로 실행됩니다.

stop.sh

#!/usr/bin/env bash

PROJECT_ROOT="/home/ubuntu/app"
JAR_FILE="$PROJECT_ROOT/todaysgym-0.0.1-SNAPSHOT.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 -15 $CURRENT_PID
fi

시작.sh

#!/usr/bin/env bash

PROJECT_ROOT="/home/ubuntu/app"
JAR_FILE="$PROJECT_ROOT/todaysgym-0.0.1-SNAPSHOT.jar"

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

TIME_NOW=$(date +%c)

# jar 파일 실행
echo "$TIME_NOW > $JAR_FILE 파일 실행" >> $DEPLOY_LOG
nohup java -jar \
-Dspring.profiles.active=main \
$JAR_FILE > $APP_LOG 2> $ERROR_LOG &

CURRENT_PID=$(pgrep -f $JAR_FILE)
echo "$TIME_NOW > 실행된 프로세스 아이디 $CURRENT_PID 입니다." >> $DEPLOY_LOG

여기서 -Dspring.profiles.active=main은 자동 배포 중에 main과 무조건 병합되는 경우에만 EC2에 자동 배포된다는 점에 유의하십시오. 따라서 프로필을 기본으로 설정해야 합니다. 그 이유는 서브모듈에 yml 파일을 2개 생성했기 때문입니다. dev 브랜치용 yml 파일과 메인 브랜치용 yml 파일. 따라서 EC2 인스턴스는 기본 yml을 수신하고 실행해야 합니다.

문제 해결

이것을 실행한 후에도 여전히 application-main.yml에 액세스할 수 없습니다. 물론 빌드할 때 configuration 폴더에 있는 두 개의 yml을 src/main/resources에 복사해야 합니다.

그 역할의 일부

task copyGitSubmodule(type: Copy) {
   from './config'
   include '*.yml'
   into 'src/main/resources'
}

build.gradle에 추가한 부분입니다. 그런데 그 부분이 안 먹혔어요. 구글링을 해보니 코드가 빠졌네요.

processResources.dependsOn('copyGitSubmodule')
task copyGitSubmodule(type: Copy) {
   from './config'
   include '*.yml'
   into 'src/main/resources'
}

위에서 processResources.dependsOn(‘copyGitSubmodule’)을 추가해야 합니다.

processResources.dependsOn(‘copyGitSubmodule’)이란 무엇입니까?
processResources는 빌드 프로세스 중에 실행되는 작업 중 하나입니다. 이것은 src/main/resources에서 작동합니다.
디렉토리의 파일을 클래스 경로에 복사하십시오.

dependsOn은 Gradle에서 작업 간의 종속성을 정의하는 방법 중 하나입니다.
dependsOn은 processResources 작업이 copyGitSubmodule 작업에 종속됨을 나타냅니다. 즉, processResources 작업이 실행되기 전에 copyGitSubmodule 작업이 실행되어야 합니다.

결국 내가 main/src/resources/application.yml을 읽기 전에 먼저 구성에서 두 yml에 액세스하지 않았기 때문에 이 문제가 발생했습니다.

그러나 나는 여전히 한 가지를 배웠습니다.