3.1.3 기본적인 CI/CD 파이프라인 만들기

윤희빈·2026년 8월 25일

Infra Spring boot aws ec2 github actions 백엔드

AWS CI/CD 구축

목록 보기

14/25

코드 배포 과정 자동화하기

이전 포스트에서 했던 것들을 자동화하겠다.

1. .github/workflows/deploy.yml 작성

이때 "SSH로 EC2에 접속하기"를 보자.
참고로 SSH는 다른 컴퓨터로 원격 접속하는 방식을 의미한다.
EC2에 접속하기 위해, 필요한 것들을 일일히 작성해도 되지만,강의에서는 "라이브러리"를 이용했다!!
깃허브의 라이브러리는 "github actions marketplace"에서 확인할 수 있다.

uses: {라이브러리}를 통해 라이브러리를 이용할 수 있다.

여기서 사용한 라이브러리: appleboy/ssh-action의 정보는 공식문서를 참고
appleboy/ssh-action 공식문서

name: Deploy To EC2

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: SSH로 EC2에 접속하기
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.EC2_HOST }} # EC2의 주소
          username: ${{ secrets.EC2_USERNAME }} # EC2 접속 username
          key: ${{ secrets.EC2_PRIVATE_KEY }} # EC2의 Key 파일의 내부 텍스트
          script_stop: true # 아래 script 중 실패하는 명령이 하나라도 있으면 실패로 처리
          script: |
            cd /home/ubuntu/cicd-ex # 여기 경로는 자신의 EC2에 맞는 경로로 재작성하기
            git pull origin main
            ./gradlew clean build
            sudo fuser -k -n tcp 8080 || true 
            # || true를 붙인 이유는 8080에 종료시킬 프로세스가 없더라도 실패로 처리하지 않기 위해서이다. 
            nohup java -jar build/libs/*SNAPSHOT.jar > ./output.log 2>&1 & 
            # jar 파일을 실행시키는 명령어이다. 그리고 발생하는 로그들을 ./output.log 파일에 남기는 명령어이다.

여기서 마지막 줄의 nohup ... & 부분의 코드를 수동으로 배포할 때의 코드( nohup java -jar ________.jar &)와 다르게하는 이유는 해당 라이브러리의 이슈 때문이지, 다른 이유는 아니다! 이슈가 해결되면 다시 고쳐도 된다!
해당 이슈
username: ${{ secrets.EC2_USERNAME }} # EC2 접속 username 부분은 인스턴스 연결 시에 있던 값이다. 사진을 첨부한다.

2. Github에 Secret값 넣어주기

EC2_HOST

인스턴스의 public IP 주소를 넣는다.
EC2_USERNAME
ubuntu
EC2_PRIVATE_KEY
터미널에서 cat 명령어로 키페어를 읽는다. 이때, -----BEGIN부터 END ... ----를 모두 복사한다!

3. Github에 Push해서 Github Actions가 잘 작동하는지 확인하기

4. 실제 서버에 접속하기

코드를 수정해서 다시 푸시해보았다.

잘 되는 것을 확인.

application.yml 따로 관리하기

보통 application.yml 파일에 민감한 값을 보관하는 경우가 많다. 따라서, .gitignore에 이 파일을 추가하여 더이상 버전관리가 되지 않도록 설정하겠다.
다만 이 때문에 배포할때는 application.yml을 따로 넣어줘야 하는 귀찮은 과정이 포함이 된다.
이 과정을 자동화하겠다.

1. .gitignore에 application.yml 추가

gitignore

...
application.yml

2.application.yml 파일 작성

src/main/resources/application.yml

aws:
	access-key: 1234
    secret-key: 5678

3. Git이 추적하는지 확인해보기

아직도 src/main/resources/application.yml을 추적하는것을 확인할 수 있다.
이는 깃허브의 캐싱 때문이다.
캐시를 다시 리프레시하자.

git rm -r --cached .

이제 더 이상 .gitignore에 추가된 application.yml을 추적하지 않는다!

이제 push하자.

이제 application.yml이 빠졌다.

4. Gitbub Actions 코드 수정하기

.github/workflows/deploy.yml

jobs:
  Deploy:
    runs-on: ubuntu-latest
    steps:
      - name: SSH로 EC2에 접속하기!
        # ssh로 접속하는 명령어를 일일히 쓰기 보다는 라이브러리를 사용!
        uses: appleboy/ssh-action@v1.0.3
        env:
          APPLICATION_PROPERTIES: ${{ secrets.APPLICATION_PROPERTIES }}
        with:
          host: ${{ secrets.EC2_HOST }}
          username: ${{ secrets.EC2_USERNAME }}
          key: ${{ secrets.EC2_PRIVATE_KEY}}
          envs: APPLICATION_PROPERTIES
          script_stop: true
          script: |
            cd /home/ubuntu/cicd-ex
            rm -rf src/main/resources/application.yml
            git pull origin main
            echo "$APPLICATION_PROPERTIES" > src/main/resources/application.yml
            ./gradlew clean build
            sudo fuser -k -n tcp 8080 || true
            nohup java -jar build/libs/*SNAPSHOT.jar > ./output.log 2>&1 &

5. Github에 Secret 값 넣어주기

6. 실제 EC2에 application.yml 파일도 같이 배포 잘 됐는 지 체크하기

파일이 잘 생긴걸 확인할 수 있다.

만약 application.yml 파일을 수정할려면 actions의 secret 값을 수정해야한다.

테스트 코드 실패하면 CI/CD 과정이 실패하는 지 확인하기

1. Spring Boot 프로젝트에 내장되어 있는 테스트 코드가 잘 작동하는 지 실행해보기

$ ./gradlew test

잘 작동한다.

2.테스트 실패하게 수정하기

test/…/___ApplicationTests.java

package com.example.demo;

import org.junit.jupiter.api.Test;
import org.springframework.boot.test.context.SpringBootTest;

@SpringBootTest
class DemoApplicationTests {

	@Test
	void contextLoads() {
		throw new RuntimeException("Fail!");
	}
}