이사 결심
프론트 배포처를 vercel에서 aws로 이사를 했다. 주된 이유는 다음과 같다.
- vercel은
yarn v4를 지원하지 않는다. - 위 사항이 크게 문제되지는 않았으나, 며칠 전부터 vercel 배포 오류가 발생
- github actions를 사용하여 ci를 구축해보고싶었음
- 실무에서 vercel보단 aws를 많이 사용할 것 같았음.
대략 이런 이유들로 vercel => aws로 이사를 결심했다.
프론트 AWS 배포 방식
구글링해보니, 배포 방식은 3가지 정도가 있었다.
- EC2 : 안전하고 크기조정 가능한 컴퓨팅 파워를 클라우드에서 제공한다. 단순하게 생각하면 가상의 컴퓨터를 빌려주는 거다.
- S3 : 대용량 바이너리 파일을 저장하는데 사용되는 스토리지같은 개념. 정적 파일을 업로드할때 자주 쓰인다.
a. CloudFront : 프론트엔드용 CDN라고 생각하면 편하다. 정적 자산을 캐싱해주고 제일 가까운 서버에 연결해준다. - Amplify : 풀스택애플리케이션을 배포할때 쓰인다. 프론트환경에서 클라우드 서비스를 쉽게 crud할수 있게 해준다. 단점은 S3+Cloudfront보다 트래픽비용이 비싸다.
우리가 선택한건 S3 + Cloudfront였다. 실제로 많은 프론트엔드 배포를 이렇게 하기도 했고 EC2는 굳이 필요없어서 제외. Amplify는 요금때문에 선택지가 아니었다.
어떻게 하는건데?
AWS를 프로그래머스에서 백엔드팀에게 제공해주었기에 기본 설정(계정,route53, ssl발급...)은 백엔드측에서 해주셨다.
프론트측에서 한 일은 첫 빌드파일 업로드와 github-actions를 이용한 자동배포 구축이었다.
그리고 이 글의 주제는 github actions를 주로 다룰거라...자세한 aws 프론트 배포 방법은 정말 잘 작성해주신 분의 블로그를 보면 좋을 것 같다!
github actions
Automate your workflow from idea to production
공식문서에 적혀있는 설명이다. 이 글로 github actions이 뭔지 감이 오지 않는다면 다음을 보자.
즉, 특정 이벤트를 대상으로 어떠한 작업을 자동화한 것이 바로 github ations다.
그러면 특정 이벤트의 종류에는 뭐가 있을까?
- 특정 시간에 동작하게 스케쥴링을 할수 있다.
- 배포 상태가 변경되었을 때
- 브랜치에 어떠한 수정이 가해졌을 때.
이러한 이벤트가 트리거됬을때 어떠한 작업을 특정 환경에서 실행시킬 수 있다.
참고로 github에서 제공하는 기본 환경은 다음과 같다.
이러한 환경 위에서 우리는 특정 브랜치에 push, pull-request일때 aws에 배포하길 원한다.
YAML(YAML Ain't Markup Language)
JSON하고 비슷한 문법을 지원한다. github actions는 이 YAML을 이용해서 문서를 작성한다. 한번 익히면 굉장히 쉽다!
아래는 어제 작성해본 따끈따끈한 YAML이다.
# 이 작업의 이름이다.
name: Tikitaza frontend continuous developments
# 언제 트리거 할건지
on:
push:
branches: main
pull_request:
branches: main
# 어떠한 작업을 할 건지
jobs:
# 작업의 이름
build-and-deploy:
# 어떤 환경에서 할건지
runs-on: ubuntu-latest
# 어떠한 단계들로 구성할건지
steps:
# 체크아웃. 저장소의 코드를 checkout하여 github actions가 돌아가는 서버로 내려받은 후 특정 브랜치로 전환한다.
- name: Checkout
#uses에 어떤 액션을 사용할건지 적어놓는다. 이 액션의 공식문서는 여기 >> https://github.com/actions/checkout
uses: actions/checkout@v4
# 노드 설치. actions/setup-node@v4를 이용해서 버전 20의 노드를 설치한다.
- name: Set up Node
uses: actions/setup-node@v4
with:
node-version: 20
# corepack 설정. yarn v4를 사용하기위해 corepack을 enable상태로 변경한다.
- name: Enable Corepack
run: corepack enable
# yarn 버전 설정. 현재 개발환경에서 4.1.0을 사용중이다.
- name: Set Yarn Version
run: |
yarn set version 4.1.0
# 의존성 설치.
- name: Install dependencies
run: yarn install
# 빌드. 환경변수를 넣고싶다면, 아래 다시 설명하겠음.
- name: Build with yarn
run: yarn run build
env:
VITE_CLIENT_SECRET: ${{ secrets.VITE_CLIENT_SECRET }}
VITE_KAKAO_CLIENT_ID: ${{ secrets.VITE_KAKAO_CLIENT_ID }}
VITE_KAKAO_REDIRECT_URI: ${{ secrets.VITE_KAKAO_REDIRECT_URI }}
# aws 인증
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: ap-northeast-2
# aws 배포. 최신버전 유지를 위해 S3의 /assets 폴더 내부를 재귀적으로 삭제, 배포성공한 파일과 S3버킷을 동기화
- name: Deploy to AWS S3
env:
BUCKET_NAME: ${{ secrets.AWS_S3_BUCKET_NAME }}
run: |
aws s3 rm s3://$BUCKET_NAME/assets/ --recursive
aws s3 sync ./dist s3://$BUCKET_NAME
# Cloudfront의 캐싱을 무효화한다.
- name: CloudFront Invalidation
env:
CLOUD_FRONT_ID: ${{ secrets.AWS_CLOUDFRONT_ID }}
run: aws cloudfront create-invalidation --distribution-id $CLOUD_FRONT_ID --paths "/*"
#참고로 위 경로 지정할때 "따옴표"가 굉장히 중요하다위 파일을 프로젝트 루트 디렉토리기준 ./github/workflows/파일이름.yaml로 저장하면 된다.
참고로 환경변수를 넣고싶다면..
리포지토리 Setting => Security => Secrets and variables => Actions => Repository secrets에서 설정해주면 된다.
yaml파일에 환경변수 적을땐 아래처럼!
env:
내맘대로_환경변수_이름: ${{ secrets.설정한_레포지토리_변수이름 }}개선점
총 배포시간이 vercel기준 65초 => 50초로 약 20프로 내외 감소하였지만, 여러 문제가 남아있다.
- github actions의 캐싱 기능을 활용하지 못한다.
- zero-install 기능을 활용하지 못한다. (치명적)
위 두개를 개선하면 배포시간을 훨씬 단축할 수 있을 듯 하다.
다음에는 배포 개선으로 뵙겠습니다!
