analogcoding

Github action 을 이용한 S3 배포 - 번역 본문

Be well coding/Learn more

Github action 을 이용한 S3 배포 - 번역

be well 2020. 4. 22. 14:01

React 앱을 S3 에 Github Action 으로 배포하기.

(출저 : https://medium.com/trackstack/deploying-a-react-app-to-aws-s3-with-github-actions-b1cb9ba75c95 )

img

Github Actions는 버전 관리 외에 프로젝트 관리 측면을 열어 놓은 Github 의 비교적 새로운 기능입니다.
이러한 기능 중 하나는 작년에 이미 혼잡한 시장에 도입 된 CI / CD (Continuous Deployment)입니다.
그러나 이 기능에서 볼 수 있는 주요 이점은 모든 배포 요구를 처리하는 단일 서비스입니다.

이 게시물에서는 Github Actions로 기본 연속 배포 파이프 라인을 설정하여 React 앱을 AWS S3에 배포하는 단계를 간략하게 설명합니다.
복잡하지 않은 방법을 알려 드리겠습니다.

  • 스테이징 및 프로덕션 인스턴스를 위한 설정 워크 플로우 파일 생성
  • Github에 AWS secret 추가
  • S3 버킷에 파일을 배포하는 Github Action 설치
  • S3 버킷에 React 앱 배포

기본 설정 :

처음에는 React 앱을 설정하고 Github에 푸시하는 방법을 알고 있다고 가정합니다.
그렇지 않다면 여기여기 에서 시작할 수 있습니다 .
앱이 준비되면 두 가지 방법으로 작업 워크 플로우를 시작할 수 있습니다.
첫 번째는 Github 리포지토리의 Action 탭을 통하거나 두 번째는 로컬 리포지토리 자체에서 직접 하는 방법이 있습니다.
둘 다 괜찮지만 이 예제에서는 첫 번째 방법을 사용하여 Actions 인터페이스에 익숙해 질 것입니다.

action

처음 클릭하면 기본 제공되는 기본 구성을 제공하는 '시작' 페이지가 표시됩니다.
이를 건너 뛰고 워크 플로 설정을 직접 클릭 (set up a workflow yourself) 하고 처음부터 시작할 수 있습니다.

yml0

다음으로 Github의 코드 편집기에서 워크 플로를 수동으로 편집하고 변경 사항을 커밋 할 수 있습니다.
구문은 YAML이라는 언어이며 매우 일반적인 구성 도구입니다.
거의 모든 CI / CD 플랫폼은 구성 파일에서 이를 사용합니다.
당신이 전에 그것을 보지 못했다면, 픽업하기가 매우 쉽습니다.
가장 먼저 할 일은 파일 production.yml의 이름을 바꾸고 커밋 시작을 클릭하여 변경 사항을 저장합니다.

배포하기 :

이제 로컬 리포지토리로 다시 이동하여 새 작업 워크 플로 파일이 포함 된 최신 변경 사항을 가져올 수 있습니다.
준비 및 프로덕션 환경에 배포 할 파일을 추가 할 위치입니다.
편집기를 연 상태에서 name프로덕션 빌드로 변경하고 브랜치에 푸시 할 때와 풀 요청이 열릴 때 트리거 하는 키를 변경하십시오.

name: Production Build
on:
  pull_request:
  push:
    branches:
      - master

그러면 특정 푸시가 발생할 때마다 해당 파일과 아래에 설명 된 단계가 트리거됩니다.
트리거하려는 항목에 따라 동일하거나 다른 분기를 수신하는 파일을 원하는 만큼 설정할 수 있습니다.
다음 단계는 jobs푸시 후에 수행 할 기능을 추가해야하는 단계입니다 .
아래에서 볼 수 있듯이 build 작업이 이미 존재하므로 runs-on단계 와 함께 유지할 수 있습니다 .
여기에서는 앱을 실행할 가상 인스턴스에 대해 간략하게 설명하고 이 예제에서는 기본값을 유지합니다.
그러나 strategyand matrix키를 사용하여 실행하려는 Node 버전을 추가해야 합니다.

name: Production Build
on:
  pull_request:
  push:
    branches:
      - master
jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [8.x, 10.x, 12.x]

지금까지는 아무 것도 트리거하지 않고 머신 및 노드 버전을 지정하기 만했습니다.
8.x, 10.x 및 12.x 용 노드 버전이 포함되어 있음을 알 수 있습니다.
이 버전은 필요하지 않지만 앱이 이러한 각 버전에서 작동하도록 합니다.
원하는대로 제거하거나 더 추가 할 수 있습니다.
이제 앱 배포에 필요한 단계로 넘어갈 수 있습니다.

name: Production Build
on:
  pull_request:
  push:
    branches:
      - master
jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [8.x, 10.x, 12.x]

    steps:
      - uses: actions/checkout@v1
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}

이제steps 에 키를 사용하여 워크 플로가 진행되는 단계를 간략하게 설명 할 수 있습니다.
첫 번째는 actions/checkout Github Action을 실행하는 것 입니다.
이 조치는 $GITHUB_WORKSPACE 아래에서 저장소를 체크 아웃 하므로 워크 플로우가 액세스 할 수 있습니다.
기본적으로 워크 플로우를 트리거 한 저장소는 체크 아웃됩니다.
체크아웃과 함께 actions/setup-node 가 실행되며, 이는 전략 단계 중 매트릭스에서 정의한 노드 버전을 사용하여 환경에 대한 노드를 설정합니다.
보시다시피 이 작업은 ${{ matrix.node 버전}}을 참조하며 매트릭스 어레이에 정의된 노드 버전만큼 많은 버전으로 실행됩니다.
이제 S3에 배포하기 전에 앱을 설치, 빌드 및 테스트 할 수 있습니다.
이것은 매우 간단하며 다른 앱의 CI / CD 구성을 작성한 경우 이를 인식합니다.
이 경우 Yarn을 create-react-app의 기본 패키지 관리자로 사용합니다.
그러나 이것은 NPM 및 기타와 동일하게 작동합니다.
이 Yarn 스크립트를 실행하면 앱이 올바르게 빌드되고 S3 버킷으로 푸시되기 전에 모든 단위 테스트를 통과하지만 린트와 같은 것을 이 단계에서 더 많은 단계를 추가 할 수 있습니다.

name: Production Build
on:
  pull_request:
  push:
    branches:
      - master
jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [8.x, 10.x, 12.x]

    steps:
      - uses: actions/checkout@v1
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}
      - name: Yarn Install
        run: |
          yarn install
      - name: Production Build
        run: |
          yarn build
      - name: Unit Tests
        run: |
          yarn test

마지막으로, 우리는 Github 액션 s3-sync-action by Jake Jarvis 에서 호출을 사용하여 이루어질 수 있는 배치 단계에 추가할 필요가 있습니다.
Action은 컴파일 된 애플리케이션을 가져와 미리 정의 된 환경 변수를 사용하여 지정된 S3 버킷으로 보냅니다 (나중에 자세히 설명).
uses 키를 다시 한 번 사용하면 동작을 가져 오기 위해 수행해야 할 모든 것입니다.
그런 다음 with키를 사용하여 S3에 업로드 할 때 필요한 관련 인수를 활용합니다.

  • --acl public-read: 당신의 S3버캇이 공개적으로 읽을 수 있도록 구성되어 있다고 가정할 경우 이는 사람이 올린 파일이 있도록 보장할 것입니다.
  • --delete: 이것은 올린 파일에 없는 S3버킷이 안에 있는 파일을 삭제합니다.

우리의 최종 배포 스크립트:

name: Production Build
on:
  pull_request:
  push:
    branches:
      - master
jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [8.x, 10.x, 12.x]

    steps:
      - uses: actions/checkout@v1
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}
      - name: Yarn Install
        run: |
          yarn install
      - name: Production Build
        run: |
          yarn build
      - name: Unit Tests
        run: |
          yarn test
      - name: Deploy to S3
        uses: jakejarvis/s3-sync-action@master
        with:
          args: --acl public-read --delete
        env:
          AWS_S3_BUCKET: ${{ secrets.AWS_PRODUCTION_BUCKET_NAME }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_REGION: ${{ secrets.AWS_REGION }}
          SOURCE_DIR: "build"

환경 변수:

현재 워크 플로우는 명시 적으로 설정되지 않은
AWS_S3_BUCKET,
AWS_ACCESS_KEY_ID,
AWS_SECRET_ACCESS_KEY 또는
AWS_REGIONS3 에 업로드하는 데 필요한 변수를 설정해야 합니다.
이러한 코드가 코드 내에 노출되지 않도록 하기 위해 각 리포지토리의 설정 메뉴를 통해 추가하고 액세스 할 수 있습니다.
설정을 클릭 한 다음 secret 옵션을 선택하면이 페이지가 나타납니다.

secret

보시다시피 API 키 또는 자격 증명과 같은 많은 비밀 변수를 공개하지 않고 추가 할 수 있습니다.
새 비밀 추가를 클릭 하고 비밀 키와 해당 값을 입력하면 됩니다.
이 안내서를 확인하지 않으면 프로덕션 및 스테이징 환경에 대해 AWS로 S3 버킷을 이미 설정했다고 가정합니다.
준비가 되면 이 안내서 에 따라 AWS 키와 ID를 검색 할 수 있습니다.
이제 React 앱을 설정하고, 프로덕션 환경의 워크 플로우를 완료하고, S3 버킷을 설정하고, 환경 비밀을 Github에 추가해야 합니다.
이제 변경 사항을 적용하고 첫 번째 CI / CD 배포를 시작할 수 있습니다.
master 워크 플로우를 시작하려면 지점에서 수행해야 합니다 .
Github과 repo의 Actions 탭으로 가면 빌드 및 배포가 실행되고있는 것을 볼 수 있습니다.

ready

워크 플로우 준비 :

마지막으로해야 할 일은 준비 환경에 대한 프로덕션 워크 플로를 복제하는 것입니다.
기본적으로 이 인스턴스에 대해 다른 S3 버킷을 설정하지 않았다면 아직 Github의 다른 환경 비밀에 준비 버킷 이름(AWS_STAGING_BUCKET_NAME)을 추가해야 합니다.
이 작업이 완료되면, 우리는 workflows 폴더에 새로운 staging.yml 파일을 생성 할 수 있습니다.
이제 작업이 커밋되고 staging 지점으로 푸시 된 경우에만이 워크 플로가 실행되도록 약간의 변경 작업을 수행할 준비가 되었습니다.

이 파일의 주요 변경 사항은 다음과 같습니다.

  • 워크 플로우의 이름을 Staging Build
  • 준비 환경으로 끌어 오기 요청을 할 가능성이 거의 없으므로 on 섹션에서 pull_request 를 제거하십시오.
  • 변경 master에 branches 에 staging
  • Production Build단계 이름을 다음으로 변경하십시오. Staging Build
  • AWS_S3_BUCKET 환경 변수를 다음으로 변경하십시오.${{ secrets.AWS_STAGING_BUCKET_NAME }}
name: Staging Build
on:
  push:
    branches:
      - staging
jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [8.x, 10.x, 12.x]

    steps:
      - uses: actions/checkout@v1
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}
      - name: Yarn Install
        run: |
          yarn install
      - name: Staging Build
        run: |
          yarn build
      - name: Unit Tests
        run: |
          yarn test
      - name: Deploy to S3
        uses: jakejarvis/s3-sync-action@master
        with:
          args: --acl public-read --delete
        env:
          AWS_S3_BUCKET: ${{ secrets.AWS_STAGING_BUCKET_NAME }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_REGION: ${{ secrets.AWS_REGION }}
          SOURCE_DIR: "build"

이러한 변경 사항이 저장되고 staging지점으로 푸시되면 Github 리포지토리의 작업 탭에서 동일한 워크 플로가 실행됩니다.
그런 다음 각 프로덕션 및 준비 URL로 이동하여 새로 배포 된 React 앱이 현재 활성화되어 있는지 확인할 수 있습니다.

Comments