리액트 앱 Github Actions를 이용하여 CI/CD 구축하기

 

2025.03.31 - [AWS] - 리액트 AWS S3 + CloudFront로 배포하기 - 1. S3, CloudFront 설정

2025.03.31 - [AWS] - 리액트 AWS S3 + CloudFront로 배포하기 - 2. 도메인 구매 + Route 53 + ACM 설정

리액트 AWS S3 + CloudFront로 배포하기 - 2. 도메인 구매 + Route 53 + ACM 설정

 

이전에 리액트 앱을 S3 + CloudFront를 이용해서 배포해보았다.

하지만 이 상태라면 프로젝트의 변경사항이 있을때마다 빌드 → S3버킷에 파일올리기 → CloudFront 캐시 무효화 과정을 진행해야 한다.

그래서 매번 하기 귀찮은 이 과정을 자동화할 필요가 있고 이제 그걸 해볼것이다!

 

Github Actions를 이용해서 dev 브랜치에 push됐을 때, 빌드된 파일을 S3에 올리고,  CloudFront 캐시 무효화 해주는 과정을 자동화해보자

 

GitHub Actions란?

GitHub에 코드가 푸시(Push)되거나 PR(Pull Request)이 생성될 때 자동으로 빌드 / 테스트 / 배포 / 린트 등을 실행하는 자동화 도구입니다.

 

주요 특징

1. 이벤트 기반 실행: GitHub 리포지토리에서 발생하는 다양한 이벤트(예: 푸시, 풀 리퀘스트, 이슈 생성 등)에 반응하여 워크플로우를 자동으로 실행할 수 있습니다.
2. 워크플로우 구성: .github/workflows 디렉토리에 YAML 파일 형식으로 워크플로우를 정의합니다. 이 파일에서 실행할 작업, 실행 환경, 실행 조건 등을 세부적으로 지정할 수 있습니다.
3. 다양한 빌드 환경 지원: Linux, Windows, macOS 등 다양한 운영 체제에서 워크플로우를 실행할 수 있으며, Docker 컨테이너 내에서 워크플로우를 실행하는 것도 가능합니다.
4. 마켓플레이스: GitHub Actions 마켓플레이스에서는 다양한 커뮤니티가 만든 액션을 찾아서 사용할 수 있습니다. 이를 통해 워크플로우를 쉽게 확장하고 재사용할 수 있습니다.

 

기본 구성 요소

1. 워크플로우(Workflows): 하나 이상의 작업(Job)을 정의하고, 특정 이벤트에 의해 실행되도록 구성된 자동화된 프로세스이다.
2. 이벤트(Events): 워크플로우 실행을 트리거하는 활동이다. 예를 들어, push 이벤트가 발생하면 해당 워크플로우가 실행된다.
3. 작업(Jobs): 워크플로우 내에서 실행되는 일련의 단계(Steps)를 포함한다. 각 작업은 서로 다른 러너(Runner)에서 병렬로 또는 순차적으로 실행될 수 있다.
4. 단계(Steps): 각 작업 내에서 실행되는 개별 명령이나 액션이다. 스크립트 실행, 액션 실행 등을 할 수 있다.
5. 액션(Actions): 재사용 가능한 워크플로우 구성 요소로, 커뮤니티에서 공유하거나 직접 생성할 수 있다. 액션을 사용하여 로그인, 코드 린팅, 테스트 실행 등의 공통 작업을 쉽게 추가할 수 있다.
6. 러너(Runners): 워크플로우가 실행되는 서버. GitHub에서는 GitHub-hosted runners를 제공하며, 사용자는 자체 서버에 self-hosted runners를 설정할 수도 있다.

 

1. Github Actions 설정하기

 

Github Actions는 root 경로의 .github/workflows/deploy.yml 을 읽고 작업을 실행합니다.

deploy.yml의 이름은 작성자 마음대로 변경할 수 있어서 나는 user-dev-deploy.yml로 설정하고 진행했다.

 

2-1. .env파일 작성하기

VITE_SERVER_URL="http://localhost:8080"

 

.env는 깃허브에 올라갈 환경변수를 설정하는 파일이다.

나는 application-dev.yml 처럼 로컬에서 사용하게 될 것으로 env.local 파일도 만들어주었다.

 

2.2 deploy.yml 파일 작성하기

name: Deploy to S3 and Invalidate CloudFront Cache

on:
  push:
    branches:
      - main

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v2

      - name: Set up Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '20'

      - name: Create .env file
        run: |
          echo 'VITE_SERVER_URL=${{ secrets.VITE_SERVER_URL }}' > .env

      - name: Install dependencies
        run: npm install

      - name: Build project
        run: npm run build

      - 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: ap-northeast-2

      - name: Deploy to S3
        uses: jakejarvis/s3-sync-action@v0.5.1
        with:
          args: --follow-symlinks --delete
        env:
          AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET_NAME }}
          SOURCE_DIR: build

      - name: Invalidate CloudFront cache
        run: |
          aws cloudfront create-invalidation --distribution-id ${{ secrets.CLOUDFRONT_DISTRIBUTION_ID }} --paths "/*"

 

Github Actions에서는 가상머신을 통해 빌드하고, 빌드된 아티펙트를 배포하는 과정을 추가할 수 있다.

해당 과정에선 Github Repository의 Setting에서 설정한 Secrets를 사용하여 빌드를 한다. Secret을 설정하는 부분은 아래에서 설명하겠다.

 

on: push: branches: 에는 어떤 브랜치에 푸시가 되면 CI/CD를 실행시킬지 지정해주는 요소이다.

jobs: deploy: runs-on: 은 실행환경을 작성해 준다. 나는 우분투 리눅스 환경을 적어주었다.

그 외 기타 요소들의 설명들이다.

on	언제 실행할지 조건 설정 (예: push, pull_request, schedule)
jobs	하나의 워크플로우 내 실행 단위들
runs-on	어떤 OS에서 실행할지 (보통 ubuntu-latest)
steps	실제 실행되는 작업들 (run, uses)
uses	GitHub에서 만든 액션 재사용 (예: actions/checkout)

 

위의 과정은 크게 하나의 job에 8개의 step으로 구성되어 있다. YAML파일로 정의된 IAC 방식은 항상 정의된 방법으로 빌드, 배포하는 과정을 보장할 수 있으므로 협업에 있어 큰 장점을 갖는다.

또한 각 과정에 대해 명시적으로 정의할 수 있기 때문에 가독성이 좋다.

 

잘보면 .env에서 설정한 환경변수가 들어가 있는 것이 보인다.

export const apiClient = axios.create({
  baseURL: `${import.meta.env.VITE_SERVER_URL}/api/v1`,
  withCredentials: true
})

 

아래는 apiClient.ts 파일인데 여기서도 .env의 환경변수로 갈아끼워 주었다.

 

여기까지 진행됐다면 github/workflows/deploy.yml 을 읽고 실행할 수 있도록 깃허브에 Push 해주자

나는 스크립트에 main에 push되면 스크립트가 실행되도록 설정해두어서 main브랜치로 merge까지 해주었다.

 

 

 

그럼 이렇게 깃허브의 Actions 탭에서 원래 없었던 workflows가 표시된다! 왕신기🤩

그리고 우리가 스크립트로 작성해뒀던 job들이 차례대로 실행될 것이다.

 

 

그리고 이렇게 오류를 만나게 된다. Github Actions secrets을 설정안해줬기 때문

 

 

3. Github Actions Secrets 설정하기

 

프로젝트 레포지토리의 Settings > Secrets and variables > Actions

여기에서 프로젝트를 빌드하고 배포하는데에 필요한 env들을 설정할 수 있다.

 

New repository secret를 눌러 필요한 키들을 입력해준다.

우리가 .env에서 설정해뒀던 환경변수들을 입력하면 된다.

 

 

4. AWS Access key 발급 받기

워크플로우에서 AWS에 접근하려면 시크릿 키 등록이 필요하기 때문에 발급받아 보겠다.

🔥 AWS Access key
AWS에선 기본적인 보안에 대해선 지원해주지만, 사용자의 부주의에 대한 책임은 지지 않습니다.
따라서 사용자가  AWS를 이용하기 위한 권한을 갖기 위해선 AWS에 접근하는 아이디와 비밀번호가 필요합니다.
AWS의 경우 클라우드 서비스이기 때문에 여러 사용자가 하나의 계정을 사용할 수도 있습니다.

하지만 공유하고있는 모든 사용자가 AWS에 대한 모든 권한을 갖고있다면 AWS의 서비스는 한두가지가 아니기 때문에
AWS서비스에 대한 관리가 제대로 되지 않을 수 있습니다.

따라서, 전체 권한을 가진 Root 사용자가 IAM이라는 계정을 만들어서 해당 계정에 필요한 권한만 부여할 수 있습니다.
발급된 IAM에 대한 접근 권한을 인증하는 수단으로 AWS Access key가 있습니다.

 

AWS > 보안 자격 증명 선택

 

 

 

이후 자세한 내용은 이전 글의 2.IAM 액세스 키 생성하기를 봐주길 바란다.

2025.02.19 - [AWS] - AWS S3에 이미지 저장하기 - 2. IAM 사용자 생성 및 권한 설정하기

AWS S3에 이미지 저장하기 - 2. IAM 사용자 생성 및 권한 설정하기

 

 

이후 만들어진 액세스키에 CloudeFront 권한을 추가해주면 된다.

 

해당 Access key를 가진 사용자는 IAM 권한에 해당하는 모든 기능에 대해 접근이 가능하므로 절대로 누군가에게 알려줘서는 안된다! ❌

또한 한 번 본 이후엔 다시 확인할 수 없으므로 csv파일에 저장해두는 것이 좋다.

 

 

다시 Actions secrets로 돌아와와서 발급해준 Access Key를 비롯한 환경변수들을 입력해준다.

VITE_SERVER_URL은 BaseUrl을 넣어주었고,

CLOUDFRONT_DISTRIBUTION_ID는 CloudFront에서 만들었던 배포 아이디를 넣어주면 된다.

 

이렇게 완성한 후 다시 Rerun job을 누르면 과연.. 실패!

 

이 부분에서 에러가 났다.

찾아보니 나는 Vite를 사용중이였는데 Vite는 기본적으로 dist/ 폴더로 빌드되는데 GitHub Actions에서는 build/를 기준으로 S3에 업로드 중인 것이다.

 

build: {
	outDir: 'build' // S3 배포용으로 'build/'로 변경
}

 

그래서 빌드가 되면 build 파일로 생성될 수 있게 vite.config 파일에 위 코드를 추가해주었다.

 

 

그리고 다시 돌려보니 성공이였다 🥳

 

CI/CD의 동작과정을 이해할 수 있었던 좋은 시간이였다.

백엔드 CI/CD까지 가보자고!