Github Actions으로 배포 자동화하기

Sunghwan Shin·2020년 4월 6일

본 포스트는 Github Action을 이용해서 특정 브랜치를 실시간으로 감시하고, 변동이 생겼을 때 자동으로 AWS에 푸시할 수 있는 파이프라인을 구축하는 글입니다. AWS IAM의 간단한 개념과 S3를 통해 정적인 배포를 할 줄 아시는 분에게 적합합니다.

S3를 통해 정적인 배포 환경을 구성하는 법이 궁금하다면 S3, ACM, CloudFront, Route53으로 서버리스 페이지 https 배포하기 [1/4]을 참고하세요! S3 배포만이 목적이라면 1편만 보시면 됩니다 🥰

개념 소개

AWS IAM
AWS Identity and Access Management의 약자로, 루트 사용자가 아닌 다른 사람으로 하여금 루트 사용자가 허락한 수준의 권한을 사용 수 있도록 해주는 서비스입니다.
이 글에서는 Github Action에서 돌아가는 머신에 IAM 사용자를 생성하고 부여함으로써 직접 콘솔을 열지 않고도 자동으로 S3 버킷에 파일을 업로드 할 수 있도록 하기 위해 사용합니다.
Github Action
새로 추가된지 오래 되지 않은 기능으로, 빌드나 테스트 등을 자동화하는데 사용할 수 있는 기능입니다. github/workflows/ 디렉토리에 명령어 파일을 직접 세트하거나, 템플릿을 바탕으로 웹 상에서 작성할 수도 있습니다. 도커 배포나 npm 배포 등 다른 다양한 기능들을 사용할 수도 있습니다.주로 yml 문법을 사용하는 것으로 보입니다.

전체적인 아키텍쳐

Github Repository: 기존 방식대로 협업하며, master 브랜치에는 자동으로 배포 될 버전들이 머지됩니다.
Github Actions: master 브랜치를 실시간으로 감시하며, push가 일어난 경우에 자동 배포 프로세스를 수행합니다. AWS IAM 키를 repository의 secret에 보관하다가 전달받습니다.
AWS: Github Actions로부터 빌드된 파일을 업로드받습니다.

작업 순서

AWS IAM 발급
Github Secret 설정
Github Actions 설정
잘 되나 테스트해보기

1. AWS IAM 발급

첫 번째로 Github에 등록될 권한을 갖는 가상 유저를 생성해 봅시다. [서비스 > IAM > 사용자]로 이동해서 적절한 이름을 정하고 프로그래밍 방식 액세스에 체크 해 주세요.

S3에 있는 버킷에 업로드 할 권한이 필요하므로, 다음 단계에서 [기존 정책 직접 연결]을 선택하여 Full access를 부여합니다.

태그는 따로 추가할 필요 없습니다. 마무리 되었습니다! 이 때, 마지막 화면에 표시되는 비밀 키를 꼭 복사해서 보관해 주세요. 다시 확인할 수 없습니다.

만약에 실수로 키를 확인하지 않고 지나친 경우에는 리스트에서 사용자를 클릭한 뒤 [보안 자격 증명 > 액세스 키 만들기]로 새로 만들 수 있습니다. 이 경우 기존 키는 삭제해 주세요.

AWS에서 할 일은 여기까지입니다! 이제 깃허브로 넘어가 봅시다.

2. Github Secret 추가

이제 깃허브에 액션을 설정할 차례입니다. 먼저 바로 앞에서 발급한 ID와 비밀번호를 가지고 Action을 사용할 레포지토리의 [Settings > Secrets]로 이동 해 주세요. Secrets는 레포지토리에 직접 업로드하기 민감한 비밀번호나 환경변수 등을 별도로 관리할 수 있는 기능입니다. 본인을 포함하여, 협엽 중인 Admin 레벨의 공동 작업자라 하더라도 한번 업로드 한 키의 값을 다시 볼 수는 없습니다. (삭제 후 재등록은 가능합니다.)

AWS_IAM_MANAGER_KEY_ID 와 AWS_IAM_MANAGER_SECRET_ACCESS_KEY 라는 이름으로 두 개의 값을 추가 해 줍니다. 이름을 다르게 써도 되지만, 혹시나 아래 코드를 붙여넣을 때 잘 동작하지 않을까 걱정된다면 같은 이름을 쓰는걸 추천합니다.

추가도 끝났습니다! 이제 마지막으로 Github actions을 작성해서 가동해 보도록 합시다.

3. Github Actions 설정

따로 파일을 만들어 올려도 되긴 하는데 웹에서 Actions를 만들면 경로도 자동으로 잡아 줍니다. [Actions > Set up a workflow yourself]를 눌러 새 액션을 만듭니다.

이제, 새 창에 아래 코드를 붙여넣고 버킷 이름과 버킷 위치를 제대로 입력합니다.

    name: Deploy to Production
    
    on:
      push:
        branches:
          - master
    
    jobs:
      deploy:
        name: Build, Deploy to S3 bucket
        runs-on: [ubuntu-latest]
    
        strategy:
          matrix:
            node-version: [12.16.x]
    
        steps:
          - uses: actions/checkout@v2
    
          - name: Use Node.js ${{ matrix.node-version }}
            uses: actions/setup-node@v1
            with:
              node-version: ${{ matrix.node-version }}
    
          - name: Npm install
            run: npm install
    
          - name: Build
            run: npm run build
    
          - name: Transfer to S3 for serving static
            uses: jakejarvis/s3-sync-action@master
            with:
              args: --acl public-read --follow-symlinks --delete
            env:
              AWS_S3_BUCKET: !!!버킷이름(my-s3-bucket)!!!
              AWS_ACCESS_KEY_ID: ${{ secrets. AWS_IAM_MANAGER_KEY_ID }}
              AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_IAM_MANAGER_SECRET_ACCESS_KEY }}
              AWS_REGION: !!!버킷의 region (ex. ap-northeast-2)(!!!
              SOURCE_DIR: 'dist'

코드를 구조와 순서를 간단하게 요약하면 아래와 같습니다.

트리거 조건

master 브랜치에 푸시가 되었을 때 실행된다.

수행하는 작업

사용자가 지정한 Node.js 버전의 환경을 셋업한다.
npm install, npm run build 를 통해 패키지를 설치하고 빌드한다.
(jakejarvis/s3-sync-action@master를 이용)secret에 있는 AWS IAM을 통해 지정한 S3 버킷에 /dist 안에 있는 파일들을 업로드한다.

버킷 이름만 고치고 우상단의 "Start commit" 버튼을 눌러 변경사항을 저장하게 되면 모든 작업이 완료됩니다.

4. 잘 되나 테스트해보기

테스트는 간단합니다. master 브랜치에 푸시가 일어나면 액션이 트리거되므로, 커밋을 하나 해 보면 되겠죠. 만약에 위의 actions 파일을 바로 master에서 작성하고 커밋했다면 별도의 작업을 하지 않아도 자동으로 첫 action이 실행됩니다.

푸시가 완료되었다면 상단의 Actions를 다시 눌러 봅시다. 이젠 아까와 다른 창이 저희를 반겨줍니다. Workflow에 노란색이 뱅글뱅글 돌고 있다면 성공적으로 Action이 수행되고 있는 것입니다.

해당 액션을 누르고 왼쪽의 노란 동글이를 눌러 들어가 보면 현재 작업의 진행 상태를 확인할 수 있습니다.

첫 실행시 Node js 셋업에 시간이 상당히 소요됩니다. 이 글을 쓰면서 작업한 프로젝트의 경우 8분 48초가 걸렸습니다. 느긋하게 잠시 컴퓨터를 덮고 시원한거라도 한잔... 🍺(?)

모두 초록색 체크가 나왔따면 완료된 것이고, 빨간 엑스표가 나온다면 뭔가 잘못된 것입니다. 잘못된 경우, 위 화면에서 삼각형을 눌러 자세한 에러 로그를 확인하고 문제를 고쳐 봅시다.

모두 체크가 되었다면 정말 마지막으로 업로드가 잘 되었는지 콘솔에서 확인 해 보아야 합니다. 다시 버킷으로 들어가서 "마지막 수정" 타임스탬프가 방금 액션에 의한 업로드 시간과 맞는지 확인 해 봅시다. 배포가 되어 있더라도 가끔 캐시 등이 남아 링크에서는 바로 확인이 되지 않는 경우가 있어 타임스탬프로 확인하는 것이 가장 확실합니다.

수고하셨습니다! 이제 마스터로 PR을 머지하거나 커밋을 푸시하면 자동으로 Actions가 빌드하여 배포를 진행하는 환경을 갖추셨습니다.