CI/CD] CodeDeploy - 적용 과정

📌 CI와 AWS 환경설정을 먼저 해야한다.

CI/CD] Github Actions CD - AWS 환경 설정

CI/CD] Github Actions CI

 

 

📌 깃헙  > Actions

 

 

📌 Actions secrets 생성 

 

📍Setting > Secrets and variables > Actions > New repository secret 클릭

 

📍2개 생성 각각 ( AWS 환경설정글 4번에서 다운받은 CSV파일에서 키ID 값과 액세스키를 가져와 각각 적용)

- CSV는 ,로 값을 나눈다. 

 

 

 

📌  AppSpec 파일 생성

********* AppSpec 파일명은 appspec으로 모두 소문자로 해야함!!!!!!! 아래처럼 했다가 255 Error봄 

root 폴더 즉, builda.gradle 이나 gradlew 등이 있는 경로에 생성. 이 파일은 CodeDeploy가 배포를 위해 참조하는 파일!

여기서 파일을 EC2 어느 경로에 복사할건지, 배포 이후에 어떤 행동을 하게 할 건지 할 수 있어 서버 배포에 대한 설정을 할 수 있다.

version: 0.0                                        # 버젼
os: linux                                           # OS

files:                                              # 배포 파일 설정
  - source:  /                                      # 인스턴스에 복사할 디렉터리 경로
    destination: /home/ubuntu/app                   # 인스턴스에서 파일이 복사될 목적지
    overwrite: yes                                  # 덮어쓰기 허용

permissions:                                        # 파일에 관한 권한 설정
  - object: /                                       # 권한 지정되는 파일 또는 경로
    pattern: "**"                                   # 매칭되는 패턴에만 권한부여
    owner: ubuntu                                   # Object 소유자
    group: ubuntu                                   # Object 그룹 이름

hooks:                                              # 배포 이후 수행할 스크립트 부분
  AfterInstall:                                     # 파일 설치 후 실행되는 스크립트
    - location: scripts/stop.sh                     # 실행되는 스크립트 경로, 위치
      timeout: 60                                   # 스크립트 실행 허용 시간, 넘으면 배포 실패
      runas: ubuntu                                 # 스크립트 실행 사용자
  ApplicationStart:                                 # 애플리케이션 실행 스크립트
    - location: scripts/start.sh
      timeout: 60
      runas: ubuntu

📍 Code Deploy 흐름 생각해서 hook 작성

 

 

 

 

📌  실행 스크립트 작성

root폴더에 scripts 폴더 생성

appspec 파일에서 실행 시킬 실행 스크립트 또한 작성한다.

 

뱀귤님 코드를 그대로 써서 공부했습니다! 7-1과 7-2번 코드!

Github Actions CD: AWS EC2 에 Spring Boot 배포하기

📍 stop.sh (기존에 실행 중이던 파일을 종료)

#!/usr/bin/env bash

PROJECT_ROOT="/home/ubuntu/app"
JAR_FILE="$PROJECT_ROOT/CICD_githubActions-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)

# 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 &                          # 계속 실행되게 nohup으로 실행

CURRENT_PID=$(pgrep -f $JAR_FILE)                                             # nohup으로 실행 후 프로세스 아이디를 얻음
echo "$TIME_NOW > 실행된 프로세스 아이디 : $CURRENT_PID" >> $DEPLOY_LOG

📍 start.sh (새로운 jar파일을 실행)

#!/usr/bin/env bash
# #!은 명령어 집합표시, 뒤는 이 명령어들을 해석할 프로그램 위치와 프로그램

#-------------------------------------------------- 변수 선언 START
PROJECT_ROOT="/home/ubuntu/app"                                             # 종료할 jar파일 위치
JAR_FILE="$PROJECT_ROOT/CICD_githubActions-0.0.1-SNAPSHOT.jar"                                  # 종료할 jar파일 이름

DEPLOY_LOG="$PROJECT_ROOT/deploy.log"                                       # 로그파일 생성

TIME_NOW=$(date +%c)                                                        # 현재시간

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

#-------------------------------------------------- 명령어 START
# 프로세스가 켜져 있으면 종료
if [ -z $CURRENT_PID ]; then
  # 리눅스에서 > 와 >> 의 차이 : > (뒤에 나오는 파일에 write or overwrite), >> (뒤에 나오는 파일에 추가 append)
  echo "$TIME_NOW > 현재 실행중인 애플리케이션이 없습니다" >> $DEPLOY_LOG         # 리눅스 터미널 출력 명령어
else
  echo "$TIME_NOW > 실행중인 $CURRENT_PID 애플리케이션 종료 " >> $DEPLOY_LOG
  kill -15 $CURRENT_PID                                                     # -15 프로세스를 안전하게 종료
fi

 

📌  plain.jar 생성되지 않게 build.gradle 설정

빌드시 일반 jar파일 말고도 plain.jar파일이 하나 더 생성되는 데 이를 방지, 아래 코드를 추가하면 된다.

* plain.jar는 plain archive라고 해서 dependency를 모두 제외한 순수한 소스코드와 리소스만을 가지고 있는 파일 

jar {
    enabled = false
}

 

 

📌  gradle.yml 수정

📍 수정 전

name: Java CI with Gradle

on:                                                               # 워크플로우를 실행할 이벤트 종류와 특정 브랜치 설정
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

permissions:                                                      # 권한 설정
  contents: read

jobs:                                                             # 수행할 워크플로우 
  build:                                                          # 빌드
    runs-on: ubuntu-latest                                        # 빌드가 실행할 OS

    steps:                                                        # 단계 설정
    
    - uses: actions/checkout@v3                                   # 워크플로우 실행전 체크아웃

    - name: Set up JDK 11                                         # JDK 11 버전 설치
      uses: actions/setup-java@v3
      with:
        java-version: '11'
        distribution: 'temurin'

    - name: Grant execute permission for gradlew
      run: chmod +x ./gradlew
      # Build

    - name: Build with Gradle                                     # gradle로 빌드 실행
      uses: gradle/gradle-build-action@67421db6bd0bf253fb4bd25b31ebb98943c375e1
      with:
        arguments: build

 

📍 수정 후

# 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/CD with Gradle

on:                                                               # 워크플로우를 실행할 이벤트 종류와 특정 브랜치 설정
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

env:                                                              # 환경 설정
  AWS_REGION: ap-northeast-2
  S3_BUCKET_NAME: littlezerobucket
  CODE_DEPLOY_APPLICATION_NAME: cicd_Test
  CODE_DEPLOY_DEPLOYMENT_GROUP_NAME: cicd_group        # IAM의 CodeDeploy용 역할

permissions:                                                      # 권한 설정
  contents: read

jobs:                                                             # 수행할 워크플로우 
  deploy:                                                         # Deploy
    name: Deploy
    runs-on: ubuntu-latest                                        # 빌드가 실행할 OS
    environment: production

    steps:                                                        # 단계 설정

    # 체크아웃
    - name: Checkout
      uses: actions/checkout@v3                                   # 워크플로우 실행전 체크아웃

    # JDK 11 세팅
    - name: Set up JDK 11                                         # JDK 11 버전 설치
      uses: actions/setup-java@v3
      with:
        java-version: '11'
        distribution: 'temurin'

    # BUILD 권한 부여
    - name: Grant execute permission for gradlew
      run: chmod +x ./gradlew
      # Build

    # BUILD
    - name: Build with Gradle                                     # gradle로 빌드 실행
      uses: gradle/gradle-build-action@67421db6bd0bf253fb4bd25b31ebb98943c375e1
      with:
        arguments: clean build

    # AWS 인증
    - 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 }}

      # 빌드한 파일 S3 버킷에 업로드
    - name: Upload to AWS S3
      run: |
        aws deploy push \
          --application-name ${{ env.CODE_DEPLOY_APPLICATION_NAME }} \
          --ignore-hidden-files \
          --s3-location s3://$S3_BUCKET_NAME/$GITHUB_SHA.zip \
          --source .

      # 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=$GITHUB_SHA.zip,bundleType=zip

 

 

 

📌 그리고 아래 발생한 다양한 트러블... 들을 해결하고 나서 드디어 자동 배포 성공! 

 

 트러블 슈팅들 ****  

*** 1)

Error: The security token included in the request invalid.

 

문제: credential 검증에서 오류

원인: Code Deploy Application Name 값과 Code Deploy Application Group Name을 잘못넣어서 발생

해결: AWS CodeDeploy에서 생성한 애플리케이션 이름과 그 안의 배포 그룹 이름으로 설정해주니 해결

 

📍 둘다 AWS환경 설정 글에서 9번에서 만든 것을 yml에 넣어줘야 한다.  

위에 애플리케이션에서 해당 이름 누르면 있는 배포 그룹

 

---

 *** 2)

Error: Process completed with exit code 255.

appspec.yml was not found.

 

문제: appspec.yml을 찾지 못해 실행 못함

원인: appspec 파일명을 AppSpec으로 해서 찾지 못함

해결: 파일명을 모두 소문자로 해줬더니 해결

 

 

---

*** 3)

Error: Process completed with exit code 127.

command not found

 

문제: 요구하는 arguments를 못불러옴

원인: 해당 arguments 앞에 맞지 않는 arguments가 붙어 뒤를 읽지 못함

해결: 불필요한 arguments 삭제로 해결

 

 

---

*** 4) 

CodeDeploy agent was not able to receive the lifecycle event. Check the CodeDeploy agent logs on your host and make sure the agent is running and can connect to the CodeDeploy server.

- CodeDeploy agent가 라이프사이클 이벤트를 받을 수 없으니 host의 로그를 살펴보라는 내용

 

EC2 로그는 처음 우분투 접속 기준

../../var/log/aws/codedeploy-agent/codedeploy-agent.log 

에 위치하고 있다. 그곳에 써있는 로그를 보면

 

ERROR [codedeploy-agent(1163)]: InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Missing credentials - please check if this instance was started with an IAM instance profile

 

문제: github actions에서 Deploy가 성공했음에도 불구하고 실제로 AWS Deploy결과를 봤을 때 ApplicationStop에서 바로 실패한 케이스

원인: IAM 역할을 지정하지 않은 인스턴스에 CodeDeployAgent를 먼저 설치해 버려 CodeDeploy에 해당 역할을 실행할 수 있는 자격 증명이 없어서 생긴 문제

해결: CodeDeploy Agent를 EC2에서 다시 실행 시키면 된다.

 

- 1) 다시 실행

- 2) 상태 확인

sudo service codedeploy-agent restart
sudo service codedeploy-agent status

 

 

 

📌 위에 성공 로그 보다가 든 의문점

이 로그를 보면 현재 실행중인 애플리케이션이 없다고 한다. 하지만 아래처럼 쉘 스크립트를 넣어줬고, 기존 nohup을 죽이고 새로운 빌드 파일로도 변경이되서 nohup으로 돌아가는 상황. 근데 프로세스가 켜져있어서 stop.sh가 kill해줬다면 실행중인 프로세스 아이디와 애플리케이션 종료에 대한 로그도 찍혔어야하는 데 없다. 이미 stop전에 프로세스가 kill이 된 것으로 보인다.

# 프로세스가 켜져 있으면 종료
if [ -z $CURRENT_PID ]; then
  # 리눅스에서 > 와 >> 의 차이 : > (뒤에 나오는 파일에 write or overwrite), >> (뒤에 나오는 파일에 추가 append)
  echo "$TIME_NOW > 현재 실행중인 애플리케이션이 없습니다" >> $DEPLOY_LOG         # 리눅스 터미널 출력 명령어
else
  echo "$TIME_NOW > 실행중인 $CURRENT_PID 애플리케이션 종료 " >> $DEPLOY_LOG
  kill -15 $CURRENT_PID                                                     # -15 프로세스를 안전하게 종료
fi

직접 kill하지 않아도 application을 stop해 주는 로직이 있는 걸까 싶어 이벤트를 보니 ApplicationStop이 마음에 걸린다.

 

혹시 정말 앞에서 해주고 있는 거 아닐까 싶어서

AfterInstall과정에서 stop.sh을 실행할 수 있도록 설정한 yml 파일 부분을 아예 주석처리 해버리고 테스트를 했는데

띠용 잘된다. 앞서 찍힌 로그와 달리 마지막 로그엔 stop.sh에 있는 현재 실행중인 애플리케이션이 없습니다 로그도 없다.  그럼 stop.sh가 없는 버젼으로 잘 실행됬다는 이야기..

 

찾아보니 배포 라이프사이클 이벤트 중에 ApplicationStop은 마지막으로 성공 배포한 버젼에서 appspec file과 스크립트를 가져와서 사용한다고 한다. 이 말은 즉 새로 배포한 파일에서의 applicationStop관련은 이번 배포가 아닌 다음 배포를 위해 적용된다는 뜻이기도 하다. 하지만 나는 전에도 후에도 applicationStop에 kill하는 걸 설정해준 적이 없는데? 아니면 전에 파일을 다시 역행하는 방식? 은.. 아닌거 같고 왜 kill처리를 주석해줬음에도 kill하는게 되는 걸까 궁금해!!

 

이에 대한 내용은 좀 더 조사해봐야할 거 같다. 

 

 

 

---

 

➕ CI/CD 연습한 깃헙 레포지토리

GitHub - littlezero48/CICD_githubActions: CI/CD GithubAction을 연습

 

➕ 공부자료 

AWS 1편: EC2 생성 후 Spring Boot 띄우기

[SpringBoot] Github Action으로 AWS EC2 자동 빌드/배포하기(CI/CD)