Vite로 구축한 정적 웹사이트를 AWS S3와 GitHub Actions로 배포하고 관리하기

Vite로 구축한 정적 웹사이트를 AWS S3와 GitHub Actions로 배포하고 관리하기

투머치한 타이틀, 그것이 다이다.

CI/CD란 무엇일까?

CI (Continuous Integration) : 코드의 지속적인 통합을 통해 유효한 코드인지 검사하는 프로세스. CI는 코드 변경사항을 정기적으로 빌드 및 테스트하여 공유 리포지토리에 병합하는 자동화 프로세스이다.

CD (Continuous Delivery/Deployment) : CI과정을 통해 성공적으로 통합된 코드를 자동으로 배포하는 과정. 이는 개발자의 변경사항을 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하는 것을 의미한다.

Continuous Delivery : 개발환경의 배포까지 자동화된 것. Continuous Deployment : 실제 사용자에게 제공되는 Production 환경에 배포를 자동화한 것.

이 글에서는 CI/CD 파이프라인의 구축 과정을 Amazon S3 및 GitHub Actions를 활용한다.

클라우드형 CI/CD 플랫폼인 GitHub Actions

: GitHub Actions는 소프트웨어 워크플로를 자동화하는 도구이다. 코드 통합, 테스트 실행, 서버에 새 기능 또는 버전 배포 등 다양한 작업을 수행할 수 있다. 그렇기 때문에 CI/CD 파이프라인의 구축에만 신경 쓸 수 있다. 여러 Job으로 구성되고, 특정 Event에 의해 트리거될 수 있는 자동화된 프로세스이다.

1. AWS S3를 활용한 정적 웹사이트 호스팅

AWS S3는 Amazon Simple Storage Service(Amazon S3)의 준말로 아마존에서 제공하는 객체 스토리지 서비스 이다. 특정 정적 웹사이트 호스팅에 사용된다.

수동으로 버킷에 빌드 파일을 업로드하는 방식은 번거로우며 시간이 많이 소요가 되고 번거롭다. 이를 해결하기위해 AWS CLI를 사용한 자동화 스크립트 이용할 수 있다. 예를 들면,aws s3 sync dist/ s3://버킷이름 --delete 명령어는 dist/ 디렉토리에 있는 파일을 S3 버킷에 동기화 하고 기존에 업로드된 파일을 삭제한다. 이러한 스크립트를 'package.json'에 포함시켜 배포 프로세스를 자동화 할 수 있다.

2. GitHub Actions 기본 설정

(부제 : 내가 지정하는 브랜치에 push되는 코드에 적용시키기.)

GitHub Actions를 사용하여 코드의 변경 사항이 감지될 때마다 설정한 정해진 작업이 자동으로 실행되도록 설정할수 있다. .github/workflows 디렉토리에 .yml 파일 생성하여 push 이벤트가 일어 날 때마다 워크플로가 작동하도록 설정한다.

name: CI/CD
on:
  push:
    branches:
      - master

job:
  cicd:
    runs-on: ubuntu-latest
    steps:
      - run: echo hello,cicd
  • on: push : push 이벤트가 발생할 때 워크플로를 실행하겠다는 의미. ('master'브랜치에 코드가 push 되면 워크플로가 시작됨.)
  • branches : 워크플로가 실행될 브랜치 지정.('master'브랜치 지정됨)
  • jobs : 여러 작업을 정의할 수 있는 섹션. 각 작업은 독립적으로 실행될 수 있음.
  • runs-on : 워크플로가 실행될 환경을 지정. (최신 버전의 Ubuntu 사용)
  • steps : 실행할 각 단계를 정의. ('echo helo,cicd'커맨드 실행)

워크플로의 실행

'master'브랜치에 코드가 push될 때마다 GitHub Actions는 정의된 워크플로를 실행한다. 위의 예시에서는 간단한 'echo' 커맨드가 실행되지만, 테스트 실행 및 빌드 프로세스, 배포 작업등이 이 단게에서 수행될 수 있다.

3. Github Actions로 CI 구축 해보기

CI는 코드 변경 사항이 주기적으로 빌드되고 리모트 레포지토리에 병합되기전에 테스트한다. 테스트 과정을 추가해본다.

vite에서 테스트 환경 구축하기

CRA(Create React App)과는 달리, Vite는 기본적으로 테스트 환경이 구성되어 있지 않기 때문에 테스트 환경을 설정해야한다. (참고한 블로그 글)

1) 필요한 패키지 설치

아래의 패키지들을 설치한다.

npm i -D jest ts-jest @testing-library/react @testing-library/jest-dom @testing-library/user-event @babel/preset-react @babel/preset-typescript @babel/preset-env identity-obj-proxy

jest : 테스트 프레임워크 ts-jest : Jest에서 Typescript를 사용할 수 있게 해주는 도구 @testing-library/react : React DOM 테스팅 유틸리티 @testing-library/jest-dom : DOM 상태 테스트용 도구 @testing-library/user-event : 사용자처럼 이벤트 발생시키는 도구 identity-obj-proxy : import한 CSS 모듈 등을 mock 데이터로 사용할 수 있게 해주는 도구

관련 내용 출처 : React 테스트 환경 구축하기

2) package.json에 테스트 스크립트 추가

package.json 파일에 테스트를 실행할 스크립트를 추가한다.

"scripts": {
    "test": "jest"
},

3) jest.config.json

Jest 설정 파일 jset.config.json을 생성하여 테스트 관련 설정을 정의한다.

{
  "roots": ["<rootDir>"],
  "testMatch": ["**/*.test.ts?(x)"],
  "testEnvironment": "jsdom",
  "moduleNameMapper": {
    "\\.(css|less|svg)$": "identity-obj-proxy"
  },
  "setupFilesAfterEnv": ["<rootDir>/jest.setup.ts"],
  "transform": {
    "^.+\\.tsx?$": "ts-jest"
  }
}

4) jest.setup.ts

json.setup.ts파일을 만들어 Jest-dom을 포함시킨다.

import "@testing-library/jest-dom";

5) 테스트 코드 작성

간단 한 테스트 코드를 작성하여 설정이 올바르게 작동하는지 확인한다.

npm run test로 테스트를 동작시켜 pass 된 결과 확인

6) GitHub Actions 설정

GitHub Actions 통해 자동화된 테스트를 구현한다. .github/workflows 디렉토리에 아래와 같은 내용의 yaml 파일을 생성한다.

name: CI/CD

on:
  push:
    branches:
      - main

jobs:
  cicd:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          ref: "main"
      - run: npm ci
      - run: npm run test
      - run: echo "success"

main브랜치에 코드가 push될 때마다 GitHub Actions는 자동으로 종속성을 설치하고, 테스트를 실행한 후 성공메시지를 출련한다.

성공한 것을 확인 할 수 있다.

4. Github Actions를 활용한 CD(Continous Deployment) 구축

Github Marketplace 에서 만들어진 Action 가져오기

GitHub Marketplace는 다양한 Actions을 제공하며, 이를 통해 배포과정을 자동화 할 수 있다. Action을 선택할 때, star 수와 사용자 수가 많으면서 유지보수상태와 에러 및 이슈 등을 고려하여 신뢰할 수 있는 Action을 선택한다.

S3 Sync Action 사용

S3 Sync Action을 사용하여 GitHub Actions 워크플로를 통해 S3 버킷 파일에 파일 자동으로 동기화 한다. 이 Action을 사용하기 위해서는 Aamazon S3와 관련된 정보를 안전하게 저장해야하기 때문에 secrets사용한다.

S3에 대한 시크릿

해당하는 GitHub 레포지토리의 Settings > Secret and variables > actions > New repository secret경로를 을 통해 S3에 대한 접근 정보를 Secret에 저장한다. 이 정보는 .env 파일에 저장하지 않으며, 실제로 깃허브가 읽을 수 없기 때문에 secrets 를 통해 actions에 전달한다.

GitHub Actions 설정

GitHub Actions 워크플로에서 다음과 같은 yaml 파일을 사용하여 S3에 자동으로 배포한다.

name: CI/CD

on:
  push:
    branches:
      - main

jobs:
  cicd:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          ref: "main"
      - run: npm ci
      - run: npm run test
      - run: npm run build
      - name: deploy to s3
        uses: jakejarvis/s3-sync-action@master
        with:
          args: --delete
        env:
          AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_REGION: "ap-northeast-2"
          SOURCE_DIR: "dist"

with의 args: 이 부분은 S3 CLI 명령어에 추가할 옵션을 지정. 여기서 --delete 옵션은 새로운 코드가 푸시될 때마다 이전에 업로드된 파일들을 S3 버킷에서 삭제함으로써, 최신 버전의 애플리케이션이 항상 반영되도록 한다.

secrets 사용: AWS 관련 정보(AWS S3 버킷 이름, AWS 액세스 키 ID, AWS 비밀 액세스 키 등)는 보안을 위해 GitHub Secrets에 저장되며, 이 정보들은 워크플로에서 직접 참조된다.

AWS_REGION과 SOURCE_DIR 설정: AWS_REGION은 배포할 S3 버킷의 지역을 지정하며, SOURCE_DIR은 배포할 빌드 파일이 위치한 디렉토리를 지정한다.

main 브랜치에 코드가 push될 때마다 자동으로 종속성을 설치하고, 테스트를 수행하고, 빌드를 생성한 후 S3 버킷으로 파일을 동기화한다.

5. 배포 확인

이 설정을 통해 코드가 변경될 때마다 자동으로 S3 버킷에 배포되며, 웹사이트에 즉시 반영된다. 이 사이트에서 변경 사항을 확인할 수 있다.

Reference

Related posts

AWS Lambda + API Gateway로 Serverless API 만들기same topic, 1 shared tagBuilding The BlogObsidian 기능 쇼케이스recent postBuilding The BlogContent Boundariesrecent postFrontend ArchitectureOpenAPI Generator를 붙이며 나눈 경계recent post