티스토리 뷰

레벨 4의 첫 미션인 성능 최적화 미션은 AWS S3와 Cloudfront로 배포해야 합니다.

 

따라서 CI/CD를 적용하지 않으면 코드의 변경사항이 생길 때마다 매번 수동으로 빌드해야 합니다. 그리고 드래그 앤 드랍으로 S3 버킷에 파일을 업데이트 해줘야 합니다.

 

하지만 Github Actions를 이용해 CI/CD를 적용한다면 이러한 불편함을 단번에 해소할 수 있습니다.

 

다음과 같은 순서로 Gihub Actions를 적용해보겠습니다.

 

1. S3와 Cloundfront 생성 및 연동

2. S3 ACL(액세스 제어 목록) 편집

3. 개인 AWS 계정 새 액세스키 발급

4. Github Settings에서 Secrets 추가

5. Github Actions workflow 생성

6. 자동 배포 결과 확인

 

1. S3와 Cloundfront 생성 및 연동

먼저, S3에 버킷을 만들고 Cloudfront를 연결해줍니다.

이 부분은 엘라의 포스팅을 참고합시다 😄 (Thanks Ella)

 

 

React 앱을 S3+CloudFront로 배포하기(1) - S3 Bucket 생성

지금부터 S3와 CloudFront로 React application을 배포했던 과정을 정리해볼까 한다. 순서는 다음과 같다. S3 Bucket 생성 CloudFront 설정 도메인 구입하여 설정 S3 Bucket 생성하기 1. S3 버킷 생성하기 AWS S3..

hjuu.tistory.com

 

 

2. S3 ACL(액세스 제어 목록) 편집

이제 S3의 ACL(액세스 제어 목록)을 편집해야합니다.

 

여기서 잠깐 왜 ACL을 편집해야할까..? 🤔

 

의문이 드실 수도 있는데요. 그 이유는 우테코 AWS 계정이 보안상의 이유로 aws access keysecret access key를 공개하지 않기 때문입니다. (한 명이라도 보안 키를 노출하는 순간... 아찔하네요)

 

자동 배포를 위한 인스턴스에서 AWS CLI를 사용하려면 aws access keysecret access key가 필요합니다. 하지만 저희는 사용할 수가 없죠.

 

그렇다면 어떻게 백엔드 크루들은 자동 배포를 할 수 있었냐하면 우테코 AWS 계정에서 생성된 인스턴스를 사용했기 때문입니다. 같은 계정에서 생성된 인스턴스에서 별도의 권한을 부여하면 key가 없어도 S3의 읽기/쓰기가 가능해집니다. (물론, 퍼블릭 액세스 차단을 해제하면 읽기/쓰기가 가능해지지만 모두에게 가능해지는만큼 보안적으로 위험해지겠죠...?! 그리고 슬랙 알람이 뜰 겁니다. 거기에는 크루들의 무수한 갈고리가 ㅠㅠ)

 

But, 팀 단위의 미션도 아닌 개인 미션에서 모두가 인스턴스를 사용하는 것은 다소 무리가 있어보입니다.

그래서 생각해낸 방안이 S3의 접근 권한을 편집하는 방법입니다.

 

시작에 앞서, 이 방법을 사용하려면 개인 AWS 계정이 필요합니다. 계정이 없다면 회원가입을 진행해주시기 바랍니다.

 

이제 하나씩 단계별로 S3의 접근 권한을 편집해보겠습니다.

먼저, 우테코 AWS 계정에서 자신이 만든 S3 버킷으로 들어가 권한을 클릭 합니다.

 

 

우선, 스크롤을 내려 객체 소유권의 편집 버튼을 클릭 합니다.

 

 

다음과 같은 화면이 뜨면 객체 소유권을 버킷 소유자 선호로 변경하고 저장 합니다.

 

기본적으로 객체는 객체를 업로드한 계정이 권한을 가집니다. 객체 소유권 변경은 다른 계정에서 --acl bucket-owner-full-control로 업로드 되는 모든 객체에 대한 권한을 S3 버킷 소유자가 가지도록 만듭니다. 객체의 소유 권한을 우테코 AWS 계정이 가지고 있어야 Cloudfront가 정상적으로 S3의 객체를 읽어올 수 있기 때문에 꼭 변경해줍시다.

 

 

그리고 스크롤을 쭉 내려서 ACL(액세스 제어 목록)의 편집 버튼을 클릭 합니다.

 

 

다음과 같은 화면이 뜨면 피부여자 추가 버튼을 누르고 모든 체크 박스를 체크해줍니다.

 

 

여기서 피부여자는 S3에 접근 권한을 허용할 다른 AWS 계정을 말합니다. 피부여자 입력란에 개인 AWS 계정 정식 ID를 입력해주면 됩니다. 이때 정식 ID는 AWS 로그인 시에 필요한 ID가 아닙니다. 시크릿 모드로 새 창을 열어준 다음 개인 AWS 계정으로 로그인 합시다. (동시에 두 개의 계정으로 로그인 하기 위함)

 

개인 aws 계정으로 로그인한 창에서 정식 ID을 확인하려면 우선, 상단의 계정 드롭다운을 눌렀을 때 나오는 내 보안 자격 증명을 클릭 합니다.

 

 

그 다음 나온 페이지에서 계정 ID를 클릭하면 정규 사용자 ID를 확인할 수 있습니다. 이걸 복사해서 우테코 AWS 계정 창으로 돌아와 피부여자에 붙여넣기하고 변경 사항 저장을 눌러줍시다. 그러면 접근 권한 설정은 모두 끝났습니다. 이제 내 개인 계정으로 우테코 AWS 계정의 S3에 접근할 수 있게 됐습니다.

 

 

 

3. 개인 AWS 계정 새 액세스 키 발급

여기는 기존 액세스 키가 있다면 건너뛰셔도 괜찮습니다. 하지만 키를 분실하셨다면 새로 발급해주세요.

개인 AWS 개정 창에서 액세스 키(액세스 키 ID 및 비밀 액세스 키)를 눌러주세요. 그리고 새 액세스 키 발급을 눌러줍니다. 이렇게 생성된 키는 다운로드 받아서 보관하시는 걸 추천합니다. 닫기 버튼을 누르면 다시는 볼 수가 없답니다... ㅎㅎ

 

이 키는 Github Actions에서 AWS CLI가 사용하게 됩니다. 이제 우리는 개인 계정의 액세스 키를 이용하여 우테코 AWS 계정의 S3를 수정할 수 있습니다.

 

 

 

 

4. Github Settings에서 Secrets 추가

이제 Github Settings에 앞서 발급 받은 액세스 키를 Secrets에 추가할 겁니다. 본인이 적용할 프로젝트의 저장소에 들어가서 상단 메뉴 중 Settings를 클릭 합니다. 그 다음 Secrets를 클릭 합니다. 그리고 New repository secret을 클릭합니다.

 

여기서 Value에 앞서 발급 받은 액세스 키를 입력하면 됩니다. AWS CLI로 S3 버킷을 업데이트 하기 위해서는 AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_DEFAULT_REGION 세 가지가 필요합니다. 앞의 두 키는 앞서 발급 받은 AWS 키를 입력하면 됩니다. AWS_DEFAULT_REGION은 ap-northeast-2를 입력해주세요. Asia Pacific (Seoul)을 의미합니다. 그러면 이제 모든 준비가 끝났습니다. 본격적으로 Github Actions를 적용해봅시다.

 

 

5. Github Actions workflow 생성

저장소 상단 메뉴 중 Actions를 클릭 합니다. 스크롤을 내려 Manual workflow Set up this workflow를 클릭 합니다.

그러면 다음과 같은 페이지가 나오게 됩니다. 여기서 본인이 workflow 파일을 수정하여 본인이 원하는 github event에 특정한 동작을 수행시킬 수 있습니다.

 

 

이제 코드를 다음과 같이 수정해줍니다.

 

name: push_builder # 이름은 자유롭게 설정

on:
  push: # 이벤트 설정 - push 이벤트 때 동작
    branches: main # 브랜치 설정 - main 브랜치에서 push 이벤트가 일어나면 동작

jobs:
  deploy:
    runs-on: ubuntu-latest # 인스턴스 OS
    steps: 
    - name: Checkout source code
      uses: actions/checkout@v2 # 워크플로에서 액세스할 수 있도록 에서 저장소를 체크아웃
    
    - name: Setup node
      uses: actions/setup-node@v1 # 노드 설치
      with:
        node-version: '14'
        
    - run: npm install
    
    - name: Setup yarn
      run: npm install -g yarn
      
    - name: Install Dependencies
      run: yarn
      
    - name: Build
      run: yarn build
      env: # build 할 때 필요한 환경 변수 추가, Settings의 Secrets에서 추가 가능
        SOME_API_KEY: ${{ secrets.SOME_API_KEY }}

    - name: S3 Deploy
      run: aws s3 sync ./dist s3://perf-basecamp-yungo1846/ --acl bucket-owner-full-control # 본인 S3 이름 입력
      env:
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        AWS_DEFAULT_REGION: ${{ secrets.AWS_DEFAULT_REGION }}

 

script 명령어는 본인 프로젝트 설정에 맞게 변경하면 됩니다 :)

 

변경이 끝났다면 오른쪽 상단의 Start Commit을 누르고 Commit directly to the main branch 옵션으로 Commit new file을 눌러줍니다.

 

 

6. 자동 배포 결과 확인

커밋이 새로 생기면서 main 브랜치에 .github이라는 폴더 안에 workflow 파일이 생성 됩니다. 그리고 다시 상단 메뉴의 Actions로 이동하여 Github Actions의 인스턴스가 동작하는 것을 확인할 수 있습니다. 다음과 같이 작업이 모두 끝났다면 정상적으로 배포가 완료된 것입니다.

 

 

이제 S3로 들어가 파일이 제대로 업로드 됐는지 확인해봅시다.

 

 

S3에 빌드 결과물이 정상적으로 업로드 됐네요! 우리는 이제 수동 빌드와 드래그 앤 드랍에서 벗어났습니다. 이상 인스턴스 없이 S3 액세스 권한을 편집하여 CI/CD를 적용하는 방법에 대해 알아보았습니다.

 

그럼 모두 즐거운 코딩하세요 😄

 

+) 웹팩 빌드 시 환경 변수가 제대로 들어가지 않는 문제는 다음 포스팅을 참고하시면 도움이 됩니다.

 

github actions를 이용해 빌드 + 배포된 서버에서 `process.env.[환경변수]`를 사용하려면 어떻게 해야 할

파이어베이스를 사용하기 위해 아래와같이 설정해주고,.env 파일에 firebaseConfig에서 사용할 환경변수들을 설정해주었습니다.env 파일은 깃헙 저장소에 올라가면 안되기때문에 .gitignore에 .evn를 추

velog.io

 

참고

ACL(액세스 제어 목록) 개요

S3 객체 소유권을 사용하여 업로드 된 객체의 소유권 제어

환경 변수를 사용하여 AWS CLI 구성