【革命】GitHub ActionsでReactをAWS環境へ自動デプロイ

こんにちは！クラウドソリューション開発部の西谷です。GitHub Actionsを使ってReactで実装したアプリケーションをAWS環境へ自動デプロイ設定し、業務効率を向上させました。手軽に実践できるので情報をシェアします。

はじめに

現在携わっている開発プロジェクトではReactでフロントエンド開発を行っています。その中で、開発中のUIが想定通りのものになっているかをクライアントに確認してもらうために、かなり盛んにデプロイを行っています。ただこのデプロイを手動でやるとそれなりに手間がかかってしまうということから、GitHub Actionsで自動デプロイを設定することにしました。設定してみた結果、かなり好感触だったので記事にしようと思います。

前提

React19 + Vite
AWS CloudFront + S3

設定するGitHub Actions

GitHub Actionsを一言で説明すると、「GitHub上で行われた何かしらの操作をトリガーに、定義した操作を自動で実行するための機能」です。この「定義」が書かれたファイルをワークフローと呼びます。このワークフローをリポジトリの.github/workflowsに保存することで実行できるようになります。今回私が設定したのは、下記の添付画像の通り、特定のブランチにマージされたら自動ビルド&デプロイを行うワークフローです。

定義は下記の通りです。色々書いていますが、steps以降に書かれていることが実際にやりたいことで、

ソースコードをチェックアウト
Node.jsをセットアップ
パッケージインストール
Reactアプリケーションをビルド
AWSのクレデンシャル取得
S3へアップロード
CloudFrontのキャッシュ削除

となっています。

name: Auto Deploy

on:
  pull_request:
    types: [closed]
    branches:
      - develop

permissions:
  contents: read
  id-token: write

jobs:
  build_and_deploy:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    environment: dev
    env:
      VITE_API_BASE_URL: ${{ vars.VITE_API_BASE_URL}}
      VITE_USE_MSW: ${{ vars.VITE_USE_MSW }}
      AWS_ROLE_ARN: ${{ vars.AWS_ROLE_ARN }}
      AWS_REGION: ${{ vars.AWS_REGION }}
      AWS_TARGET_S3_BUCKET_URL: ${{ vars.AWS_TARGET_S3_BUCKET_URL }}
      AWS_CLOUDFRONT_ID: ${{ vars.AWS_CLOUDFRONT_ID }}

    steps:
      - name: Checkout repository
        uses: actions/checkout@v2

      - name: Set up Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '18'
         
      - name: Install dependencies
        run: npm install

      - name: Build
        run: npm run build

      - name: Set up AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-session-name: ecomott-blog-cicd
          role-to-assume: ${{env.AWS_ROLE_ARN}}
          aws-region: ${{env.AWS_REGION}}

      - name: Deploy to S3
        run: |
          aws s3 sync ./dist ${{env.AWS_TARGET_S3_BUCKET_URL}} --delete

      - name: Invalidate CloudFront Cache
        run: |
          aws cloudfront create-invalidation --distribution-id ${{env.AWS_CLOUDFRONT_ID}} --paths "/*"

name: Auto Deploy

on:

pull_request:

types: [closed]

branches:

- develop

permissions:

contents: read

id-token: write

jobs:

build_and_deploy:

if: github.event.pull_request.merged == true

runs-on: ubuntu-latest

environment: dev

env:

VITE_API_BASE_URL: ${{ vars.VITE_API_BASE_URL}}

VITE_USE_MSW: ${{ vars.VITE_USE_MSW }}

AWS_ROLE_ARN: ${{ vars.AWS_ROLE_ARN }}

AWS_REGION: ${{ vars.AWS_REGION }}

AWS_TARGET_S3_BUCKET_URL: ${{ vars.AWS_TARGET_S3_BUCKET_URL }}

AWS_CLOUDFRONT_ID: ${{ vars.AWS_CLOUDFRONT_ID }}

steps:

- name: Checkout repository

uses: actions/checkout@v2

- name: Set up Node.js

uses: actions/setup-node@v2

with:

node-version: '18'

- name: Install dependencies

run: npm install

- name: Build

run: npm run build

- name: Set up AWS Credentials

uses: aws-actions/configure-aws-credentials@v4

with:

role-session-name: ecomott-blog-cicd

role-to-assume: ${{env.AWS_ROLE_ARN}}

aws-region: ${{env.AWS_REGION}}

- name: Deploy to S3

run: |

aws s3 sync ./dist ${{env.AWS_TARGET_S3_BUCKET_URL}} --delete

- name: Invalidate CloudFront Cache

run: |

aws cloudfront create-invalidation --distribution-id ${{env.AWS_CLOUDFRONT_ID}} --paths "/*"

ポイント

上記のワークフローの中で一番重要なポイントであるS3へのアップロード周りについて説明します。

認証

認証を行っている部分はここです。

      - name: Set up AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-session-name: ecomott-blog-cicd
          role-to-assume: ${{env.AWS_ROLE_ARN}}
          aws-region: ${{env.AWS_REGION}}

- name: Set up AWS Credentials

uses: aws-actions/configure-aws-credentials@v4

with:

role-session-name: ecomott-blog-cicd

role-to-assume: ${{env.AWS_ROLE_ARN}}

aws-region: ${{env.AWS_REGION}}

S3を構築する時に、通常外部からのアクセスを許可することは推奨されていません。この自動デプロイを行う場合においても例外ではなく、このCI/CDプロセスの中でクレデンシャルを取得しなければいけません。

真っ先に思いつくのは、IAMのアクセスキー、シークレットキーを使う方法ですが、AWSのお作法としてこれらを使うことは推奨されていません。

そんな悩みを解決する代替案が、 uses: aws-actions/configure-aws-credentials@v4 です。（GitHub – aws-actions/configure-aws-credentials: Configure AWS credential environment variables for use in other GitHub Actions.）

このusesは第三者が用意したアクションを利用するためのディレクティブで、aws-actions/configure-aws-credentials@v4は、AWSが公式に開発している、GitHub Actions内でAssume Roleを簡単に実現するための機能をそろえたものになっています。

これを使うことで何が嬉しいのかについてのヒントが上記ワークフローのenvにあります。AWS_から始まる値から何となく察することができるかと思いますが、このワークフローの設定では、認証を取得するためのシークレット情報が不要となります。

利用するにはAWS上でIDプロバイダを設定する必要があります。説明が長くなるので紹介は省略しますが、詳しくはGitHubのこの記事を参考にしてください。Configuring OpenID Connect in Amazon Web Services – GitHub Docs

キャッシュのクリア

      - name: Invalidate CloudFront Cache
        run: |
          aws cloudfront create-invalidation --distribution-id ${{env.AWS_CLOUDFRONT_ID}} --paths "/*"

- name: Invalidate CloudFront Cache

run: |

aws cloudfront create-invalidation --distribution-id ${{env.AWS_CLOUDFRONT_ID}} --paths "/*"

手動での作業でよく忘れてしまうのがCloudFrontのキャッシュクリアです。すぐにできるのですが、地味に面倒なのでこれもワークフローで定義しました。 runを見てわかる通り、aws cliのコマンドを実行しているだけですね。たったこれだけで自動でクリアできるので非常に楽です。

ロールなどの説明

最後に必要になるロールの設定を紹介して終わろうと思います。必要になるのは1つのロールですが、信頼ポリシーとIAMポリシーの2つを設定する必要があります。まずは信頼ポリシーです。OIDCプロバイダーとの信頼ポリシーになります。

{

    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::<アカウントID>:oidc-provider/token.actions.githubusercontent.com"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
                },
                "StringLike": {
                    "token.actions.githubusercontent.com:sub": "<GitHubユーザー名または組織名>/<リポジトリ名>:*"
                }
            }
        }
    ]
}

{

"Version": "2012-10-17",

"Statement": [

{

"Sid": "",

"Effect": "Allow",

"Principal": {

"Federated": "arn:aws:iam::<アカウントID>:oidc-provider/token.actions.githubusercontent.com"

"Action": "sts:AssumeRoleWithWebIdentity",

"Condition": {

"StringEquals": {

"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"

"StringLike": {

"token.actions.githubusercontent.com:sub": "<GitHubユーザー名または組織名>/<リポジトリ名>:*"

}

]

}

次にIAMポリシーです。対象を制限しています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:ListBucket",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::<s3バケット名>",
                "arn:aws:s3:::<s3バケット名>/*",
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "cloudfront:CreateInvalidation"
            ],
            "Resource": [
                "arn:aws:cloudfront::<アカウントID>:distribution/<CloudFrontディストリビューションID>"
            ]
        }
    ]
}

{

"Version": "2012-10-17",

"Statement": [

{

"Effect": "Allow",

"Action": [

"s3:PutObject",

"s3:ListBucket",

"s3:DeleteObject"

"Resource": [

"arn:aws:s3:::<s3バケット名>",

"arn:aws:s3:::<s3バケット名>/*",

]

{

"Effect": "Allow",

"Action": [

"cloudfront:CreateInvalidation"

"Resource": [

"arn:aws:cloudfront::<アカウントID>:distribution/<CloudFrontディストリビューションID>"

]

}

]

}

これで作成できたIAMロールのARNをGitHub Actionsで利用します。

最後に

まだテストが充実していないので省略しましたが、自動テスト等も自動化できてしまいます。プロジェクトが進むにつれて充実させていきたいですが、少しずつ取り入れていく今のアプローチでもメリットがかなり大きいなと思いました。

エコモットでは一緒にモノづくりをしていく仲間を募集中です。弊社に少しでも興味がある方、AWSを使った開発に興味がある方はぜひ下記の採用ページをご覧ください！

【革命】GitHub ActionsでReactをAWS環境へ自動デプロイ

はじめに

前提

設定するGitHub Actions

ポイント

認証

キャッシュのクリア

ロールなどの説明

最後に

最近の投稿

カテゴリー

採用情報

IoTプラットフォーム「FASTIO」

はじめに

前提

設定するGitHub Actions

ポイント

認証

キャッシュのクリア

ロールなどの説明

最後に

最近の投稿

人気の投稿

カテゴリー

採用情報

IoTプラットフォーム「FASTIO」