Create React App(CRA) 프로젝트를 AWS S3와 CloudFront를 활용하여 배포하고 Github Action을 통해 CI/CD하기 (2) ~S3 와 Github Action 연결~

이전 포스팅 :

Create React App(CRA) 프로젝트를 AWS S3와 CloudFront를 활용하여 배포하고 Github Action을 통해 CI/CD하기 (1) ~S3 생성 및 프로젝트 배포, CloudFront 연결 까지~

Create React App(CRA) 프로젝트를 AWS S3와 CloudFront를 활용하여 배포하고 Github Action을 통해 CI/CD하기 (1)

 

이번 포스팅에서는 Cloud  Front로 연결한 S3의 소스들을 CI/CD할 수 있게끔 S3와 

Github Action을 연동하고자 한다.

 

우선, 외부 연동이 필요하니IAM(권한설정)부터 살펴보자

 

1.  IAM 생성

IAM 대쉬보드로 이동한 다음 액세스 관리 하위의 "사용자" 클릭

 

이후 "사용자 추가" 클릭

 

이름을 작성해 준다음, 다음..

 

 

권한 설정에서 

"직접 정책 연결" 클릭

 

S3 검색 후 AmazonS3FullAccess 체크!

 

"다음" 클릭

 

"사용자 생성" 클릭

 

 

 

성공적으로 생성됨을 볼 수 있다.

 

이 IAM을 외부에서 사용할 수 있게 하려면 "보안자격증명"에서 액세스 키를 만들어야 한다.

(일종의 열쇠 복사 느낌)

 

 

IAM 사용자 상세 페이지 => 보안 자격 증명 => 액세스 키 만들기 클릭

 

응 권장사항 안따를거야~

필자는 해당 엑서스키를 서드파티 서비스(깃헙)에서 사용할 것이므로 서드 파트 서비스를 선택한다(사실 의미가 없다)

"다음"클릭

이름 참 길다

태그를 설정하고 "액세스 키 만들기" 클릭

 

지금이 아니면 만날 수 없는 기회!!

액세스키를 다운로드 해줍니다. 아마 이전에는 IAM 생성과 함께 다운로드 되게끔 되었을 텐데

새로운 UI와 정책으로 바뀌었나보다.. ^^;

".csv 다운로드" 클릭..

해당 권한이 소중하다면 email이나 drive에 저장을 권장한다

필자는 소중하지 않기에 Download에 던져두기로 한다.

 

 

다운되는 것이 확인했으면 완료 클릭

 

 

액세스 키가 생성된 것을 확인할 수 있다.

 

---

 

이제 이 액세스 키를 Github에서 요긴하게 써보자

 

Github => 자동 배포할 Repository 이동

 

 

Setting 클릭 후

 

 

Secrets and variables => Actions 클릭

 

비밀친구 할래..?

 

New repository secret 클릭 후 

아까 다운받은 엑셀을 킨다..!

 

 

Access key 와 secret access key를 확인해준 후

 

 

2열에 있는 정보를 Secret에 넣으시고 Name은 마음대로...긴한데

AWS_ACCESS_KEY_ID란 이름으로 값을 저장..

 

"Add secret" 클릭

 

다시 나와서 이번엔 Secret Access Key를 저장해줄 차례입이다

동일한 방법으로 진행..

 

 

"Add secret" 클릭

 

잘 생성된 것을 확인할 수 있다..

 

 

※ 주의
엑셀에서 셀로 value를 복사 시, 개행이되어서 들어가는데
이 개행도 문자열이기 때문에 value값의 변형이 발생해서 S3에 Push 시, 권한 에러가 발생할 수 있으니(SSH~~~blah blah) 반드시 개행을 지워줘야 한다

 

 

이제 깃헙 Action을 설정 해보자

 

Github => 자동 배포할 Repository 이동

 

Actions 클릭

 

뭐야 이거.. 무서워..

저의 CRA 프로젝트는 NPM기반으로 만들어졌기에 publish Node.js Package를 통해 구성하려 했으나..

무언가 예시를 찾기 어려워서 다른 분들이 작성해놓은 workflow를 짜깁기했다..

 

오레노... 와크 프로우!!

set up a workflow yourself를 클릭

 

# This workflow will run tests using node and then publish a package to GitHub Packages when a release is created
# For more information see: https://docs.github.com/en/actions/publishing-packages/publishing-nodejs-packages

name: Node.js Package

on:
  push:
    branches: ['master'] # push시 배포할 branch명, 보통 main을 많이 쓰던데..

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      # git 소스 체크아웃
      - name: git checkout
        uses: actions/checkout@v3
        
      # node 버전 설정
      - name: setup node
        uses: actions/setup-node@v2.5.2
        with:
          node-version: 17.x
      # npm install 진행(모듈 설치)
      - name: npm install
        run: npm install
        
      # 리엑트 프로젝트 빌드
      - name: npm build
        run: npm run build
        env:
          CI: false
      
      # s3에 배포
      - name: deploy s3
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        run:
          # sync : 변경된 파일만 / --delete : 원본경로에서 삭제시 타깃에서도 삭제
          aws s3 sync --delete --region ap-northeast-2 build s3://coding-orca-test-bucket

위 코드를 복사하여 작성..

필자는 Node 17.4.0 환경에서 코딩하고 빌드하였기에 위와 같이 설정..

 

※ 중간 npm run build에서 env : CI : false를 설정하는 이유는

CI는 default가 true인데, 이는 "Warning"이 있으면 build를 해주지 않기 때문이다..
부끄럽지만 본인 프로젝트에는 warning이 상당수있기에 false로 설정해 주었다.

이제 작성했다면

 

상단의 .yml 이름을 변경해도 되고 안해도 되고..

start commit => Commit new file 클릭!

 

두근두근

이제 이 yml파일이 master branch에 commit 되면서 자동으로 s3에 빌드/배포될 것이다..!

 

뭔가 돌아가는데..

 

 

 

왼쪽에 jobs에 build-and-deploay를 클릭하면..

 

뭔가 열심히 돌아간다..

 

영롱하군요..

기다리다보면 초록색 체크마크와 함께 완료되었음을 알려준다..!

 

※ 여기서 build에 실패할 경우 CI옵션에 false를 두는 것을 염두해두길 바란다.

위에서 언급했듯, CI 값이 true일 경우 warning 하나에도 build가 안되게끔 webpack에서 관리하기 때문

 

※ 만일, deploy s3에서 실패할 경우 아까 Settings에서 설정한

access id와 secret key 값을 살펴보길 바란다. 공백이나 개행이 있을 수도 있으니

공백/개행을 지우고 다시한번 키값을 저장한 뒤 재시도하길 바란다.

 

이제 actions의 작동을 확인했으니 vs code에서 커밋 후 실제 AWS S3 => Cloud Front 도메인 사이트에 반영이 되는지 살펴보자.

 

 

상단의 Header를 수정해주겠다.

 

Header.js내의 BASE REACT를 위와 같이 수정 후 master branch 에서

Commit을 누른 뒤, Sync Changes를 클릭하여 리모트 저장소(깃허브)에 동기화한다.

 

이후 해당 리포지토리의 Github Actions를 확인하면..

 

오..오옷!!

뭔가 열심히 돌아간다!

 

이녀석...!(감동)

두근두근..

 

자 이제 Code deploy가 제대로 되었는지 봐야한다.

 

마지막 수정이 변경되었다!

S3의 bucket에서 객체를 살펴보면 마지막 수정이 변경된 것을 확인할 수 있다.

 

이제 Cloud Front에서 확인하면..!!

 

엥?

뭐야 왜 똑같지??

 

왜..왜일까..!!

왜일까..

왜긴, 캐싱때문이지!

 

S3버킷의 호스팅 주소로 가보면 

 

잘 되고 있다 즉, 배포는 잘 진행되었지만

Cloud Front에서 원본 (S3 Bucket)을 캐싱 처리하여 효율을 높이기 때문인데..

 

즉, 원본이 변경 되어도 특정 시간이 지나지 않으면 Cloud Front에서 보여주는 것이 바뀌지 않는다는 것이다.

느긋하게 변경되도 되는 경우엔 신경쓸 필요 없지만

당장 변경해야 하는 UI 에러나, CSS 수정의 경우 곤란하게 느껴질 수 있다.

이 때 실행해 주는것이 바로 "무효화"이다

 

무야호~~~

Cloud Front -> 배포 -> 해당 배포 상세화면 -> 무효화 클릭

"무효화 생성" 클릭

 

 

/* (모든 경로를 무효화)

입력 후 "무효화 생성"

 

이후 다시 새로고침 하면...

 

잘 바뀐것을 확인할 수 있다.

 

아니 만약에 Test 단계에서 계속 배포를 해서 수정을 해야 할경우 일일히 무효화 작성이 귀찮을 수 있다.

 

이때는  Cache 정책을 변경해주어야 하는데..

 

우선 Header를 다시 수정하고 커밋하도록 하자

 

웰컴백..!

잘 돌아간다..!

잠시 후 S3의 웹호스팅 앤드포인트를 확인해 보면 "GITHUB-TEST"가 지워진 것을 확인할 수 있다.

 

 

하지만, Cloud Front에는 여전히 예전 화면을 보여주고 있는데..

 

이 바보야 진짜 아니야..

 

 

이를 변경하려면 Cloud Front => 해당 배포 상세페이지 => 동작 에 들어가준다.

해당 동작(모든 경로패턴)의 체크박스를 클릭 후 편집을 눌러주자

 

 

캐시 키 및 원본 요청에서 CachingDisabled를 선택

그 후 "변경 사항 저장"을 클릭한 뒤 

 

 

다시 아까의 Cloud Front 도메인의 요청하고 강력 새로고침(브라우저 캐싱 제거)을 하면..!

 

 

의도한대로 잘 나오는 것을 확인할 수 있다.

 

캐싱을 설정하지 않을 경우 많은 요청이 있을 경우 부하가 걸릴 수 있고, 사용자에게 더 느린 환경을 제공하기에

운영시에는 권장하지 않는다.

 

운영시에는 배포를 할 때 마다 무효화(무야호) 를 통해 캐시를 지워주는 것을 권장한다.

 

이번 시리즈는 여기서 마감하지만

이번에 구축해놓은 것들은 후에 ECR에 도커 이미지를 배포하여 해당 이미지를 ECS를 사용해 컨테이너를 띄워 동작하게 하는 API 서버와 연동할 생각이다. 

 

아래의 글은 EC2에서 도커 이미지를 빌드하여 ECR에 Push한 뒤, ECS를 띄우는 과정을 소개하고있다

참고하면 좋을듯..?하다.

 

 

ECS + Github action + CodeDeploy를 위한 여정 (1) ~ EC2 구성 및 Docker 설치 ~

ECS + Github action + CodeDeploy를 위한 여정 (1) ~ EC2 구성 및 Docker 설치 ~