GitHub Action을 이용하여 S3에 파일 올리기

 

Github Actions를 통한 배포 Flow (클라이언트)

 

이번 클라이언트 배포는 간단하게 3가지 단계로 나뉜다.

• Source: Github reference 브랜치에 코드가 커밋되면
• Build: github acitons의 YAML 파일에 적힌 명령어를 토대로 Webpack을 이용해 빌드를 하고
• Deploy: github acitons의 YAML 파일에 적힌 명령어를 토대로 s3로 빌드 결과를 업로드한다.

 

---

 

Github Actions는 프론트엔드 개발자의 반복적이고 번거로운 작업들을 자동화해준다.

• 빌드 자동화: GitHub Actions를 사용하여 프론트엔드 애플리케이션의 빌드 작업을 자동화할 수 있다.
  • 예를 들어, 코드가 푸시되거나 머지될 때 자동으로 빌드가 실행되도록 설정할 수 있다.
  • 이를 통해 개발자는 수동으로 빌드하는 시간과 노력을 절약할 수 있다.
• 배포 자동화: GitHub Actions를 사용하여 프론트엔드 애플리케이션의 배포 작업을 자동화할 수 있다.
  • 예를 들어, 특정 브랜치에 푸시가 발생하면 자동으로 배포 스크립트가 실행되어 실시간으로 애플리케이션을 배포할 수 있다.
• 테스트 자동화: GitHub Actions를 사용하여 프론트엔드 애플리케이션의 테스트 작업을 자동화할 수 있다.
  • 예를 들어, 코드 변경이 있을 때마다 자동으로 유닛 테스트 또는 통합 테스트를 실행하여 코드의 품질과 안정성을 검증할 수 있다.
    
    

---

 

1. AWS access key, secret key 받기

• AWS에서 IAM 계정을 생성하여 access key와 secret key를 받는다.
• 기존에 AWS 엑세스 키와 시크릿 키가 생성되어 있어야 한다. 생성할 때 처음만 알 수 있으므로 미리 잘 복사해둬야 한다.
• IAM 사용자의 액세스 키 관리 
  • AWS Identity and Access Management(IAM)은 AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스이다.
  • IAM을 사용하면 사용자가 액세스할 수 있는 AWS 리소스를 제어하는 권한을 중앙에서 관리할 수 있다.
  • IAM을 사용하여 리소스를 사용하도록 인증(로그인) 및 권한 부여(권한 있음)된 대상을 제어다.
• AWS 액세스 키 발급받는 방법

 

2. AWS access key, secret key를 Github Actions에 등록

• 배포할 코드가 올라가 있는 git repository에 들어간다. (public이어야 기능 제한 없이 무료로 사용이 가능하다.)
• 상단 탭의 Settings > Secrets > Actions 로 들어가 New repository secret 버튼을 클릭하여 2개의 키를 등록한다. 
• 각각의 키의 이름은 변수의 역할로 나중에 yml 파일에도 동일하게 작성해줘야 한다.
• Github Actions에 AWS 시크릿 정하는 방법

 

2. '.github' 폴더에 yml 파일 작성

코드 에디터로 돌아가서, 루트 폴더에 .github 폴더를 만든 후 yml 파일을 작성해준다.

• 하고자 하는 자동화 작업 내용은 아래와 같다.

# .github/workflows/client.yml
# reference 브랜치에서 push 이벤트를 트리거하고, Node.js 프로젝트의 종속성을 설치하고 빌드한 다음, 
# AWS CLI 버전을 표시하고, 로컬 디렉토리를 S3 버킷과 동기화한다. 이 때, 작업 디렉토리는 ./my-agora-states-client로 설정되었다.

name: prac # 자동으로 처리할 액션의 이름 (여기서는 prac)
on: # 언제 이 액션이 실행될지 명시 
  push:  
    branches:
      - reference # (reference 브랜치에서 git push시 실행)
jobs: # 구체적으로 실행할 내용
  build:
    runs-on: ubuntu-20.04 # 배포 실행될 환경
    steps: # 각 단계의 이름과 실행내용을 나열

      - name: Checkout source code.
        uses: actions/checkout@v3

      # 빌드를 하기 위한 모듈 설치
      - name: Install dependencies   
        run: npm install # 실행할 명령어 제공 
        working-directory: ./my-agora-states-client-react # 배포할 클라이언트의 디렉토리명

      - name: Build
        run: npm run build
        working-directory: ./my-agora-states-client-react

      # AWS의 버전을 확인하는 단계로 엑세스 키, 시크릿 키가 필요
      - name: SHOW AWS CLI VERSION
        run: |
          aws --version

      # 빌드한 클라이언트를 버킷에 배포
      - name: Sync Bucket
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} # 시크릿 매니저를 제공하며, 이를 통해 비밀 변수를 안전하게 저장하고 액세스
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_KEY }} # GitHub Actions에서 시크릿 매니저에 저장된 AWS 키 ID에 대한 참조
          AWS_EC2_METADATA_DISABLED: true
        run: |
          aws s3 sync \  # sync는 업데이트한 파일만 복사 / cp는 상관없이 모든 파일을 복사   # 🟣 설명(1)
            --region ap-northeast-2  \            # 🟣 설명(2)
            build s3://f~~~버킷이름~~~3 \ 
            --delete  # 업로드시 삭제된 파일이 있다면, 버킷에서도 해당 파일을 동일하게 삭제한다. 
        working-directory: ./my-agora-states-client-react

 

3.  push 해보기

그 뒤에 코드를 세팅된 repository로 push를 하면 자동으로 테스트와 빌드를 한 후에 버킷에 업로드 된다.

• S3 버킷에도 해당 파일이 잘 업로드 된 것을 확인하고, 속성의 정적 웹 호스팅 링크를 클릭하면 작업한 결과물이 뜬다.

---

 

🟣 설명 (1) aws s3 sync.... 

 

설명이라기보다는 내가 헤맸던 부분에 대해 간단하게 기록해두고자 한다.

• aws s3 sync A B 명령어는 A 디렉토리의 내용을 B 디렉토리로 동기화한다는 것이다. 
• 따라서 A, B에 대한 패스를 적어줘야 한다.
• 아래와 같이 run 바로 아래 줄에 [LocalPath]와 [S3Uri]를 각각 작성해주었는데 오류가 떴다.
• 처음에 경로 오류가 나서 상대 경로를 ../my-agora-states-client-react 이렇게 고쳐주니 node_modules를 받는데만 8분 이상이 걸렸다. 

 

처음 시도한 코드

# 빌드한 클라이언트를 버킷에 배포
      - name: Sync Bucket
        .
        .
        .
        run: |
          aws s3 sync ../my-agora-states-client-react s3://f~~버킷이름~~3 \   
            --region ap-northeast-2  \
            --delete
            build s3://f~~버킷이름~~3
        working-directory: ./my-agora-states-client-react

 

결론적으로 이유는 A에 해당하는 위치에 작업 폴더 전체를 지정했기 때문이었다.

• 따라서 아래와 같이 3번째 줄에 working-directory의 build 폴더만 지정해주면 문제는 해결된다.
• --region이 먼저 나오는 이유는 (순서를 바꾸니 배포 오류가 난다) s3의 범위를 잡아주기 위해서라고 이해했다.

 

변경한 코드

          aws s3 sync \
            --region ap-northeast-2  \
            build s3://fe-75--name-s3 \      
            --delete
         working-directory: ./my-agora-states-client-react

 

🟣 설명 (2) | 와 \  

 

또 다른 궁금증은 run 뒤에 | 기호는 백틱의 역할을 하는 것이라고 이해했는데, (줄 바꿈이 그대로 반영)

• aws s3 sync를 입력하고 바로 엔터를 쳐서 --region .... 명령어를 쭉 입력해주면 명령어 인식이 안 되는 오류가 발생했다.

 

• 결론부터 얘기하면 \ 기호를 쓰면 해결이 된다.
• 우선은 아래와 같이 한 줄로 작성할 수 있는 것을 \ 기호를 사용하여 줄바꿈을 해주기 위함이라고 생각하기로 했다. (마지막에 정확한 이유가 나온다!!!)

          aws s3 sync \
            --region ap-northeast-2  \
            build s3://fe-75--name-s3 \      
            --delete
         working-directory: ./my-agora-states-client-react   
         
         // 이렇게도 작성 가능
         aws s3 sync --region ap-northeast-2 ./build s3://fe-75-doyu-lee-s3 --delete

 

• 재밌는 것은 \ 기호 전에는 아무리 띄어쓰기를 해도 괜찮지만 뒤에 띄어쓰기를 하면 오류가 난다는 것이다. 

          aws s3 sync     \# 가능 
            --region ap-northeast-2 \    ..<-여기까지 띄어쓰기 함 # 오류
            build s3://fe-75--name-s3 \# 가능       
            --delete

 

 

---

 

 

그걸 어떻게 알았냐고요?

 

 

+ 부트캠프 동기 분께서 정확한 이유를 친절하게 알려주셨다..! ⇩⇩

 

• 조금 더 알아보니 yaml은 여기서 문제가 되는 줄바꿈과 크게 관련이 없어 보입니다.
  • https://codebeautify.org/yaml-validator/cb600519 작성된 코드에서 백슬래시(\)를 지워도 여전히 유효합니다.
• yaml이 아닌 bash에서 줄바꿈을 무시하기 위하여 사용한다고 합니다.
  • https://askubuntu.com/questions/1199854/why-are-there-backslash-line-breaks-on-this-apt-install-command 터미널 명령어의 줄바꿈을 위해 사용한 듯하네요. 

 

넘나 진심이었던 댓글ㅋㅋㅋ