스무스한 자동화 배포 도전! (boot+Github actions+Code deploy)

자동화 배포와 무중단배포를 구현하려고 하는 이유

제가 원래 배포하던 방식은 다음과 같았습니다.

인텔리제이에서 jar 파일을 빌드 한 후
FTP인 FileZilla를 사용하여 EC2에 jar 파일을 전송하고
EC2에서 여러 명령어를 통해 서버를 멈췄다가, 재배포 하는 방식을 사용했었습니다.

위와 같은 방식을 처음 사용했을 때는 문제점을 많이 느끼지 못했습니다.

직관적인 방법이긴 하지만, CI/CD에 대해 공부하다보니 새로운 관점을 가지게 되었고

다시 바라본 저의 배포방식에 여러 문제점이 있다는것을 느꼈습니다.

제가 생각한 문제점은 다음과 같습니다.

main 브랜치에 푸쉬하고 배포를 하는 시점에 테스트가 진행되지 않는다.
개발자가 수동으로 해줘야 하는 작업들이 많다. (FTP로 jar 전송, EC2에서의 각종 명령어)
배포를 하는 도중에 서버가 10초정도 멈춘다. (무중단 배포 미구현)
ec2에 전송되는 jar파일에 민감한 정보인 application.properties가 그대로 노출된다.

해당 문제점들을 고치기 위해, 자동화 배포 + 무중단 배포를 여러 게시글에 걸쳐서 진행할예정입니다.

밑의 사진에서 보이는 봐와 같이 Github Actions + CodeDeploy + S3 +Nginx 등을 사용할예정입니다.
(요번 글에서는 자동화 배포까지만 하겠습니다. 4번 까지 진행되고, Nginx는 제외하고 보시면 됩니다)

전체적인 흐름도이면서 구현할 아키텍처입니다.
(push를 해서 Github Actions이 실행 되었고, 스크립트에 적어둔 테스트가 통과했다는 가정하에)

Github Actions에서 워크 플로우에 따라, S3에 jar 파일을 업로드합니다.
마찬가지로 워크플로우에 따라 CodeDeploy에게 S3에 있는 jar 파일을 가지고 배포를 진행해달라고 요청합니다.
CodeDeploy는 배포할 EC2 인스턴스 내부에 있는 CodeDeploy Agent에게 배포 명령을 내리고
Agent는 S3에게 jar 파일을 받아서 주어진 스크립트에 따라 배포를 진행합니다.

새로운 Spring Boot WAS를 띄우고, Nginx 스위칭을 통해 무중단 배포를 할 수 있도록 Agent에게 배포 스크립트를 제공합니다.

👉 최종적으로는 자동화 배포 + 무중단 배포 까지 할 예정이지만, 두가지를 직접 구현해본 입장으로서 하나씩 이해하는게 맞는것 같습니다. 자동화 배포에서 쓰던 스크립트가, 무중단 배포에서는 업그레이드 된 스크립트로 변경되는 이유도 있습니다. 요번 글에서는 Spring boot + Github actions + AWS Code deploy를 사용한 자동화 배포에 초점을 맞추겠습니다!

🚅 알아두면 좋을 인프라
👉 AWS IAM(Identity and Access Management)

AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스입니다.
IAM을 사용하면 사용자, 그룹 및 역할을 만들고 이들에 대한 권한을 정의하여 AWS 계정의 리소스에 대한 접근을 관리할 수 있습니다.
이를 통해 사용자는 필요한 서비스에 대한 액세스를 제한하고 AWS 리소스를 안전하게 관리할 수 있습니다.
IAM을 사용하여 사용자가 AWS Management Console에 로그인하고 AWS 서비스에 대한 액세스를 얻을 수 있도록 허용하거나 거부할 수 있습니다.

❓AWS IAM에서 단일 사용자일 때 리소스의 접근을 분리하는게 의미가 있을까? 어차피 AWS의 root 계정 하나가 처리하는것 같은데?
1. 사용자가 하나더라도 IAM을 사용하여 최소한의 권한을 부여하면 해당 사용자가 실수를 했을 때나 계정이 탈취되었을 때 피해를 최소화 할 수 있습니다.
2. 계정이 확정될 가능성을 위해 사용자의 권한을 효과적으로 관리할 수 있습니다.

👉 AWS Code deploy

AWS CodeDeploy는 애플리케이션 배포 서비스로, 사용자가 EC2 인스턴스, 온프레미스 서버, Lambda 함수 등 다양한 컴퓨팅 서비스에 코드를 자동으로 배포할 수 있게 해줍니다.
이 서비스를 사용하면 소프트웨어 배포 프로세스를 자동화하여 빠르고 안정적으로 애플리케이션을 배포할 수 있습니다. 코드 배포는 배포할 대상을 지정하고 배포할 코드 버전을 선택한 다음, 애플리케이션을 업데이트하고 코드를 배포하는 프로세스를 자동화합니다. 코드 배포는 지속적인 배포를 지원하며, GitHub, Bitbucket, Amazon S3 등과 같은 다양한 소스에서 코드를 가져올 수 있습니다.

👉 Elastic IP (EIP)

AWS에서 EIP는 Elastic IP의 약어로, 동적 클라우드 컴퓨팅 환경에서 인스턴스에 고정된 퍼블릭 IPv4 주소를 할당하는 서비스입니다.
이는 인스턴스에 고정된 퍼블릭 IP 주소를 제공하여, 해당 인스턴스에 항상 동일한 고정 IP 주소가 할당되도록 합니다. 이를 통해 인스턴스의 고유한 인터넷 주소를 유지하면서도, 인스턴스를 중지하거나 다시 시작할 때도 주소가 변경되지 않도록 보장할 수 있습니다.
Elastic IP는 인스턴스의 재시작, 중지, 다시 시작, 또는 기타 상황에서 변경되지 않고 계속 유지됩니다. 이는 고정 IP 주소를 요구하는 서비스를 운영하거나, 특정 IP 주소로부터 액세스가 허용된 네트워크 환경을 구축하는 등의 상황에서 매우 유용합니다.

* 개발환경

프로젝트: Spring boot 
빌드툴: Gradle
JDK: openjdk 17

💻 개요

Part.1 환경 세팅

IAM 세팅: 계정 생성, Github과 연동, 역할 생성
배포할 서버 세팅 (AWS EC2)
S3 세팅: 빌드 결과물 저장
Code deploy 세팅

Part.2 코드 작성

Github actions 워크플로우 생성
appspec.yml 작성
실행, 정지 script 작성

Part.3 배포 🚀

Part.4 확인

🧭 Part 1. 환경 세팅

🌍 IAM 세팅

먼저 AWS에서 CICD를 담당할 IAM 계정과 필요한 역할을 생성하겠습니다.

1) IAM 계정 생성

지금 생성할 IAM 계정은 CICD관련 작업에 사용할 계정입니다.

먼저 IAM 콘솔에 접속한 후, 사용자를 생성해보겠습니다.

2) 키페어 발급

이제 Github에 방금 생성한 계정의 Keypair를 입력해줄 것 입니다.

그러니 Keypair부터 발급받아 보겠습니다.

태그값은 본인이 구분하기 쉽게 입력하고, 키페어를 생성하게 되면, Access key와 Secret key를 발급받습니다.

Secret key같은 경우는 한번만 볼 수 있고, 다시 볼 수 없게 되니

일단 발급받은 키페어를 안전한 곳 어딘가에 메모해두면 좋겠습니다.

3) Github에 키페어 입력하기

배포할 코드가 있는 깃헙 레포지토리로 이동해서 발급받은 Keypair를 입력해줍니다. 입력할 때, 각 값의 이름은 아무렇게나 지어도 되지만, 같은 KEY 이름으로 적어야 실습해보는 과정에서 헷갈리지 않을것 같습니다.

CICD_ACCESS_KEY와 CIDE_SECRET_KEY가 그림과 같이 생성되었다면→ Github에서 나의 AWS S3와 Code deploy에 접근할 수 있게 됩니다!

4) IAM 역할 생성

이따가 필요하게 될 IAM 역할 2가지를 미리 생성해놓도록 하겠습니다.

IAM > 역할 콘솔에 들어가면, 역할을 생성할 수 있습니다.

4-1) EC2에서 S3 접근을 위한 IAM 역할

이 역할은 이따가 생성할 EC2에게 부여해줄 것입니다.

역할의 이름은 자유롭게 만들어주면 된다. 작명 팁은 AWS에서 기본적으로 제공되는 수 많은 역할들과는 조금 다른 느낌으로 이름을 짓는 것을 권장합니다. 왜냐하면 기본 역할과 내가 만든 역할을 혼동될 수 있기 때문입니다.

4-2) Code deploy를 위한 IAM 역할

🌍 EC2 세팅

1) 인스턴스 생성

EC2 > 인스턴스 콘솔로 이동한 후, 새로운 인스턴스를 하나 만들어줍니다.

쓰기 편한 OS를 선택하면 되는데, ubuntu로 설정을 하도록 하겠습니다.

(그리고 버전은 20.04)

22.04 버전의 경우 Code deploy agent를 설치하는데에 있어서 뭔가 매끄럽지가 못해서, 설치 매뉴얼이 존재하는 20.04버전을 선택했습니다.

2) 네트워크 설정

네트워크 설정은 EC2를 위치시킬 VPC와 서브넷을 선택해주면 됩니다.

3) 키페어

키페어는 필요하다면, 새롭게 발급 받아서 연결해주면 됩니다.

저는 이 서버만을 위한 키페어를 새롭게 발급받았습니다.

4) 보안그룹

보안그룹은 이렇게 미리 만들어두고, 연결해줍니다.

8080포트로 스프링을 돌릴거라 8080포트도 열어주었습니다.

(이후 무중단배포를 위해 8081과 8082 포트도 사용할꺼라, 이부분에서 미리 8081,8082를 추가해주면 좋습니다.)

5) EIP 생성, 연결

탄력적 IP를 하나 생성해서, EC2에 연결해줍니다.

EIP생성, 연결은 간단해서 길게 이야기하지는 않겠습니다.

6) CodeDeploy agent 설치

이제 EC2 서버에 CodeDeploy Agent를 설치해줄 차례입니다.

맨처음 보여드린 전체흐름도에서, 빨간색 박스 부분입니다.

Ubuntu를 위한 agent 설치 매뉴얼을 AWS에서 제공하고 있는데, 이 매뉴얼을 참고해서 서버에 Agent프로그램을 설치해주도록 하겠습니다.

Ubnuntu 20.04버전으로 EC2를 만들었다면, 서버에 접속한 수 아래의 명령어를 순차적으로 실행해주면 됩니다.

6-1) 설치

sudo apt update
sudo apt install ruby-full
sudo apt install wget
cd /home/ubuntu
wget https://aws-codedeploy-ap-northeast-2.s3.ap-northeast-2.amazonaws.com/latest/install
chmod +x ./install
sudo ./install auto > /tmp/logfile

6-2) 실행 확인

sudo service codedeploy-agent status

정상적으로 설치가 됐다면 이렇게, 서비스가 잘 돌아가고 있다고 메세지가 출력될 것입니다.

7) Java 설치

아래 명령어들로 Java 16버전을 설치하도록 하겠습니다.

sudo apt update
sudo apt install openjdk-16-jdk

#위의 명령어로 설치가 잘 되지 않는다면, 밑의 명령어로...
sudo add-apt-repository ppa:linuxuprising/java
sudo apt update
sudo apt install openjdk-16-jdk

8) IAM 역할 연결

이전에 만들어둔 EC2에, S3를 접근하기 위해 만들어둔 IAM 역할을 연결해주도록 하겠습니다.

🌍 S3 세팅

Github action의 워크플로우가 수행되면, 코드를 압축해서 S3에 jar 파일로 업로드할 것입니다.

그때 사용할 S3를 만들어 보도록 하겠습니다.

이름만 짓고, 나머지 설정은 디폴트 입니다.

🌍 Code deploy 세팅

애플리케이션 배포를 자동화하는 배포 서비스인 Code deploy를 세팅해보겠습니다.

1) 애플리케이션 생성

Code deploy 콘솔로 이동한 후 애플리케이션을 만들어줍니다.

2) 배포 그룹 생성

cicid-tset-CD 오타가 있는데 → cicd-test-CD 로 다시 수정했습니다! (참고!)

이렇게 모든 환경 세팅이 완료되었습니다.

이제 워크플로우와 필요한 스크립트 파일을 작성해보도록 하겠습니다!

🧭 Part 2. 코드 작성

1) GitHub Actions 워크플로우 작성

프로젝트의 제일 상위 폴더(루트경로)에서 .github 폴더안에 workflows 폴더를 만드시고 → yml 파일 만드셔야 합니다.

env 부분 고대로 따라 하시지 마시고, aws에서 만든 이름과 같은지 다시한번 확인해주세요! (오타가 있거나 다른 이름으로 만들었다면 오류납니다)

name: CICD Test
run-name: Running
on:
  push:
    branches:
        - main
    pull_request:
        - main

env:
  AWS_REGION: ap-northeast-2
  AWS_S3_BUCKET: cicd-sean-bucket
  AWS_CODE_DEPLOY_APPLICATION: cicd-test-CD
  AWS_CODE_DEPLOY_GROUP: cicd-test-CD-group

jobs:
  build-with-gradle:
    runs-on: ubuntu-20.04
    steps:
    - name: checkout-main 브랜치로 이동
      uses: actions/checkout@v3

    - name: JDK 16 설치
      uses: actions/setup-java@v3
      with:
        java-version: '16'
        distribution: 'corretto'

    - name: application.properties 파일 생성
      run: touch ./src/main/resources/application.properties
    - name: application.properties에 작성
      run: echo "${{ secrets.APPLICATION }}" > ./src/main/resources/application.properties
    - name: application.properties 내용 표시
      run: cat ./src/main/resources/application.properties

    - name: gradlew에 실행 권한 부여
      run: chmod +x ./gradlew
    - name: 프로젝트 빌드
      run: ./gradlew clean build -x test

    - name: AWS credential 설정
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-region: ${{ env.AWS_REGION }}
        aws-access-key-id: ${{ secrets.CICD_ACCESS_KEY }}
        aws-secret-access-key: ${{ secrets.CICD_SECRET_KEY }}

    - name: S3에 업로드
      run: 
            aws deploy push 
                --application-name ${{ env.AWS_CODE_DEPLOY_APPLICATION }} 
                --ignore-hidden-files 
                --s3-location s3://$AWS_S3_BUCKET/cicdtest/$GITHUB_SHA.zip 
                --source .

    - name: EC2에 배포
      run: 
            aws deploy create-deployment 
                --application-name ${{ env.AWS_CODE_DEPLOY_APPLICATION }} 
                --deployment-config-name CodeDeployDefault.AllAtOnce 
                --deployment-group-name ${{ env.AWS_CODE_DEPLOY_GROUP }} 
                --s3-location bucket=$AWS_S3_BUCKET,key=cicdtest/$GITHUB_SHA.zip,bundleType=zip

각 스텝들의 역할은 name으로 추측하시면 될것 같습니다.

요 부분에서 제가 헤맸던 부분은 application.properties 부분입니다! (중요)

처음 자동화배포 관련글을 참고하면서 진행했을 때는

요 부분을 작성하지 않고 진행했었습니다.

제가 원래 배포하던 방식은

인텔리제이에서 jar 파일을 빌드 한 후
FTP인 FileZilla를 사용하여 EC2에 jar 파일을 전송하고
EC2에서 여러 명령어를 통해 서버를 내리고, 재배포 하는 방식을 사용했었습니다.

요 과정에서 1번 부분을 보면, 빌드 후 만들어낸 jar 파일안에는 gitignore 파일에 명시된것과 관계없이 프로젝트의 빌드 구성에 따라 거의 모든 파일이 압축되어 들어갑니다.

그렇게 자연스럽게 application.properties 파일도 들어가서 문제가 안되었습니다.

actions/checkout@v3은 GitHub 저장소의 코드를 가져오는 데 사용됩니다. .gitignore에 명시된 파일들은 GitHub에 올라가있지 않기 때문에 actions/checkout@v3를 사용하여 코드를 가져올 때 application.properties 파일은 포함되지 않습니다.

위와 같은 이유로 application.properties파일을 별도로 만들어줘야합니다.

--ignore-hidden-files 옵션은 숨겨진 파일들(유닉스 기반 시스템에서 이름이 '.'으로 시작하는 파일들)을 무시하도록 지정합니다. 고로 해당 옵션은 .gitignore에 명시된 파일들을 제외하는 옵션이 아닙니다!

(저도 처음에는 --ignore-hidden-files 옵션때문에 .gitignore에 명시된 파일들이 제외되는줄 알고 착각했네요...)

그래서 결론적으로는 제외되었지만 필요한 파일인 application.properties 파일을 만드는 부분이 필요합니다.

(제가 application.properties를 해결하려고 하루정도를 소비해서 길게 적어봤습니다..)

Settings의 secrets안에 key value형태로 만들어주면 됩니다.

(Name은 배포.yml파일과 맞춰주면 되고, Secret에는 properties 내용을 전부 붙여넣기 하면 됩니다.)

2) appspec.yml 작성

그리고 프로젝트의 루트 경로에 appspec.yml도 작성해주어야합니다.

appSpec.yml 은 배포에 필요한 모든 절차를 적어둔 명세서라고 생각하시면 됩니다.

이 파일은 CodeDeploy가 실행하는것 아니라, EC2에 있는 CodeDeploy Agent 가 수행할 일들을 작성하는 곳입니다.

appspec.yml 은 공식 매뉴얼을 보고 작성하면 좋을 것 같습니다.

version: 0.0
os: linux

files:
  - source:  /
    destination: /home/ubuntu/spring-github-action
    overwrite: yes

permissions:
  - object: /
    owner: ubuntu
    group: ubuntu

hooks:
  AfterInstall:
    - location: scripts/stop.sh
      timeout: 60
  ApplicationStart:
    - location: scripts/start.sh
      timeout: 60

appspec.yml을 작성하면서 조금 더 부연설명을 드려보겠습니다.

밑의 그림에서 CodeDeploy와 CodeDeplyAgent의 관계와 각각이 하는일을 부연설명하겠습니다.

우리는 앞서GitHub Actions 워크플로우 파일인 .github.workflows.deploy.yml를 작성했고

그 안에서 미리 만들어준 특정 CodeDeploy에게 부가적으로 지시했습니다.

(여러개의 CodeDeploy를 가지고 있었고, 그중 환경 변수를 통해 어떤 CodeDeploy를 지정한것이라 ‘특정’이라는 키워드를 붙였습니다.)

그리고 사용해야할 S3 버킷과 파일경로도 알려주었습니다.

위의 코드를 통해서 Github Actions는 전체흐름도에서 2번을 진행하게 된것이며,

AWS CodeDeploy가 CodeDeply Agent에게 어떤 일을 해야하는지 명령하는것이지,

AWS CodeDeploy가 직접일을 하는것은 아닙니다.

CodeDeploy Agent는 EC2 인스턴스에 설치되어 CodeDeploy의 명령을 기다리고 있습니다.
CodeDeploy에게 배포에 대한 명령을 수신받고, 실행하고, 보고 합니다.

해당 과정만 순차적으로 보자면

GitHub Actions → AWS CodeDeploy "배포를 시작해주세요 (actions가 알려준 환경 인지)"
CodeDeploy → CodeDeploy Agent에게 "이렇게 배포해주세요 (실제 배포)"
CodeDeploy Agent는 코드 저장소에서 프로젝트 전체를 내려받고, appSpec.yml 파일을 읽어 해당 파일에 적힌 절차대로 배포
배포를 진행 한 후 CodeDeploy Agent는 CodeDeploy에게 성공/실패 등의 결과를 보고

결론은 appspec.yml 파일은 AWS CodeDeploy Agent가 어떤 작업을 수행해야하는지 정의한 파일입니다.

밑은 appspec.yml 파일에 대한 각 주요 섹션에 대한 설명입니다.

각 단계는 그 단계가 완료될 때까지 다음 단계로 진행되지 않습니다. 만약 특정 단계에서 문제가 발생하면, AWS CodeDeploy는 해당 배포를 롤백하거나 중지할 수 있습니다.

version: 파일 버전을 지정합니다.
os: 사용 중인 운영 체제를 지정합니다.
files: 배포될 파일과 디렉터리의 목록을 지정합니다.
hooks: 배포의 각 단계에 대한 스크립트를 정의합니다. (각 순서대로 진행)
1. ApplicationStop: 애플리케이션 중지 시 수행할 작업 정의
2. BeforeInstall: 새 버전의 애플리케이션을 설치하기 전에 수행할 작업 정의
3. AfterInstall: 새 버전의 애플리케이션을 설치한 후에 수행할 작업 정의
4. ApplicationStart: 애플리케이션 시작 시 수행할 작업 정의
5. ValidateService: 애플리케이션 배포의 유효성을 확인하기 위한 사용자 정의 검증 스크립트 정의
- timeout: 해당 단계의 스크립트가 허용된 실행 시간을 초과하는 경우 작업을 중지합니다.
- runas: 스크립트를 실행할 때 어떤 사용자 권한으로 실행할지를 지정합니다.

3) stop.sh, start.sh 작성

루트 경로에서 scripts 폴더를 만들고 그안에 start.sh와 stop.sh를 만드시면 됩니다.

stop.sh

#!/bin/bashROOT_PATH="/home/ubuntu/spring-github-action"
JAR="$ROOT_PATH/application.jar"
STOP_LOG="$ROOT_PATH/stop.log"
SERVICE_PID=$(pgrep -f $JAR) # 실행중인 Spring 서버의 PID

if [ -z "$SERVICE_PID" ]; then
  echo "서비스 NouFound" >> $STOP_LOG
else
  echo "서비스 종료 " >> $STOP_LOG
  kill "$SERVICE_PID"
  # kill -9 $SERVICE_PID # 강제 종료를 하고 싶다면 이 명령어 사용
fi

이 스크립트는 실행되고 있는 Spring 서버를 종료하는 역할을 합니다.

start.sh

#!/bin/bashROOT_PATH="/home/ubuntu/spring-github-action"
JAR="$ROOT_PATH/application.jar"

APP_LOG="$ROOT_PATH/application.log"
ERROR_LOG="$ROOT_PATH/error.log"
START_LOG="$ROOT_PATH/start.log"

NOW=$(date +%c)

echo "[$NOW] $JAR 복사" >> $START_LOG
cp $ROOT_PATH/build/libs/spring-github-action-1.0.0.jar $JAR

echo "[$NOW] > $JAR 실행" >> $START_LOG
#iptables 명령어는 80포트를 적지않아도 되게 해주는 명령어로, 안적으셔도 되긴합니다.
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
nohup java -jar $JAR > $APP_LOG2> $ERROR_LOG &

SERVICE_PID=$(pgrep -f $JAR)
echo "[$NOW] > 서비스 PID: $SERVICE_PID" >> $START_LOG

🧭 Part 3. 배포

🚀 실행!

요기까지 따라오느라 고생하셨습니다!

코드를 main 브랜치에 push를 해보고, 잘 진행되는지 확인해보록 하겠습니다.

1) 워크플로우 확인

2) S3 확인

3) Code deploy 확인

3-1) 이슈1: 자격증명 에러

자격증명에 관해서 에러가 발생할 수 있습니다.

Code deploy의 로그를 보는 방법은 이곳에서 안내해주고 있습니다.

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

이런 에러 로그가 찍혀있는 것을 볼 수 있습니다.

공식문서를 확인해보니 자격 증명하는 부분에 문제가 있는 것을 확인했습니다.

서치를 해보니, EC2에 IAM을 적용한 게 Code deploy agent입장에서 제대로 반영이 안됐을 수도 있다고 합니다.

EC2를 재부팅해보도록 하겠습니다.

3-2) 이슈2: Permission denied 에러

재부팅후 다시 실행해보니, 이번에는 script를 실행하는 부분에서 Permission denied에러가 발생했습니다.

찾아보니 code deploy agent의 사용자, 그룹명이 appspec.yml에 작성한 것과 달라서 발생한 문제였습니다.

문제를 해결하는 방법은 AWS 공식문서에서 알려주고 있습니다.

아래의 명령어들을 실행하면 됩니다.

Agent 소유자 변경

sudo service codedeploy-agent stop
sudo sed -i 's/""/"ubuntu"/g' /etc/init.d/codedeploy-agent
sudo systemctl daemon-reload
sudo chown ubuntu:ubuntu -R /opt/codedeploy-agent/
sudo chown ubuntu:ubuntu -R /var/log/aws/

Agent 재실행, 상태 확인

sudo service codedeploy-agent start
sudo service codedeploy-agent status

이외의 다른 에러가 나오면 chapGPT에게 물어보면 생각보다 쉽게 솔루션을 줄거라 믿습니다 👍

🧭 Part 4. 확인

앞으로 자주 사용할 ubuntu linux의 명령어에 대해 살펴보도록 하겠습니다.

ls -al #현재 디렉터리에 있는 모든 파일과 디렉터리를 자세한 형식으로 나열, 숨겨진 파일도 보임
cd 폴더이름 #폴더를 옮김
cat 파일이름 #log를 볼 때 활용
vim 파일이름 #파일 수정
> 파일이름 #어떤 내용이 있는 로그 파일을 백지로 만듦

sudo lsof -i :포트번호 #해당 포트번호의 상태를 검색
ps -p PID #pid 번호로 검색
kill -9 PID #해당 pid 중지

#위의 명령어 권한문제가 발생하면 앞에 sudo를 붙여주시면 됩니다.
#tab을 누르면 자동완성을 해줍니다. (1~2 글자를 입력했다는 가정하에)

1) 목표한 jar파일 생성

2) 서비스 구동 확인

ps -ef | grep java

3) 접속 확인

2023.11.17 - [프로젝트 일지] - 우당탕탕 무중단 배포 도전! (boot+Github actions+Code deploy)

우당탕탕 무중단 배포 도전! (boot+Github actions+Code deploy)

2023.11.17 - [프로젝트 일지] - Spring boot + Github actions + AWS Code deploy 자동화배포 도전! Spring boot + Github actions + AWS Code deploy 자동화배포 도전! 자동화 배포와 무중단배포를 구현하려고 하는 이유 제가

sean-lets-go.tistory.com

참고한 링크
- [Github Action] Spring Application.properties 민감정보 관리하기
- 실전! Github actions, AWS Code deploy로 Spring boot 배포 자동화하기
추가로 보면 좋을 링크

'DevOps > CI & CD' 카테고리의 다른 글

CI/CD Pipeline 그리기 by draw.io (0)	2024.03.12
GKE-Argo CD failed to provision volume, QUOTA_EXCEEDED 오류 (1)	2024.02.25
우당탕탕 무중단 배포 도전! (boot+Github actions+Code deploy) (0)	2023.11.17