これまでの記事の内容を進めていくことで、
1, S3バケットの用意
2, AWS CLIによるS3へのファイルのアップロード
ができるようになったと思います。

本記事では、
上記の設定を用いて、GitHubからS3へファイルが自動的にアップロードするための方法を解説していきたいと思います。

GitHubからS3へアップロードする

GitHubからS3へアップロードするには、
GitHub Actionsを用いてファイルをアップロードします。

1. ローカル環境の変更をGitHubにプッシュする
2. GitHubへのプッシュを受けてGitHub Actionsを起動する
3. GitHub ActionsによってAWS CLIを実行する
4. AWS CLIによってS3バケットへファイルのアップロードを行う

上記の一連の流れを自動化し、人の手を排除していきたいと思います。
この手法を「CI/CD」という言葉で表します。

CI/CDとは

Linux のディストリビューションを出しているRedHat社配下のように説明しています。

ここで聴きなれないワードが出てきました。
「継続的インティグレーション」と「継続的デリバリー」です。

継続的インティグレーションとは

インテグレーションという単語には、
統合する、一体化する、集積するなどの意味があり、
継続的インティグレーションというのは、
定期的に繰り返して一つにまとめるという意味を示しています。

継続的デリバリーとは

デリバリーという単語はそれほど難しくはなくそのままの意味で、
継続的デリバリーというのは
定期的に繰り返して配信・配達するという意味を表しています。

結果、何を表すのか

この「CI/CD」という言葉は何を意味しているかを簡単に表すと、
「開発者がソースコードをマージして一つにまとめ、その纏めた物をテストし、ビルドしたのちにある箇所に移動・配信することを繰り返す」ことを意味します。
で、実際に自身が受ける体験はどのようなものかというと、
「ソースコードを修正してGitHubにプッシュした時、master(main)にマージされたならば、テストを行い、本番用ファイルを生成し、本番環境にアップロードする」ことが自動で行なわれ、
「１回限りではなくプッシュされる度に同じ動作が実行される」という体験を享受することになります。

本題：GitHub Actionsを使用してS3バケットへファイルをアップロード（デプロイ）する

一つ前置きとして記載しておきますが、
GitHub ActionsからS3へのアップロードするには２通りあります。
1, IAMユーザーのクレデンシャル（鍵）をGitHubに登録してAWSにアクセスする方法
2, GitHubのOIDC(OpenIDConnect)情報をAWSに登録してAWSにアクセスする方法
前者はAWSの認証データをGitHubに預けてAWSの入口で確認する方法で
後者はAWSにGitHubの認証データを預けてAWSの入口で認証する方法になります。
セキュリティ的には後者の方が良いですが、
今回は前者の方法で進めさせていただきます。
前者はなぜセキュリティ的にダメなのかというと、
AWSのクレデンシャル情報を外に持ち出しているところにあります。
この点だけは注意しておいてください。

実際にする作業としては以下の流れになります。

1. AWSのクレデンシャル情報をGitHubに登録する
2. Workflow(Action)を定義する
3. ファイルを修正してリポジトリへプッシュする

プッシュした後は自動で処理が進んでいくので、
GitHubのページからWorkflowがちゃんと動いていることを確認し、
Workflowの処理が完了したらS3バケットへファイルがアップロードされているかの確認を行うことになります。

AWSのクレデンシャル情報をGitHubに登録する

step1
S3バケットにアップロードしたいリポジトリのページを開き
「Settings」タブ → サイドメニュー「Secrets and variables」
　→ アコーディオン内の「Actions」 をクリック

この時、リポジトリの公開設定が public であった場合、
Seacets は 「Environment secrets」 と 「Repository secrets」が表示されます。
今回は「Repository secrets」の方を利用します。

緑色の「New Repository Secrets」を押すことで登録画面に遷移します。

step2
こちらの画面でローカルからS3へアップロードする際に configure で登録した内容を設定していきます。
識別しやすいように
アクセスキーIDを「AWS_ACCESS_KEY_ID」
シークレットキーを「AWS_SECRET_ACCESS_KEY」という名で登録します。
※ ここで登録する鍵情報は、IAMユーザーの方を登録しましょう。

それでは、①に上記の名前を入力し、
②に鍵情報をコピーして貼り付けてましょう。
③で登録になります。

step3
右図下図のように登録されていれば問題ありません。

Workflow(Action)を定義する

Workflowではリポジトリに起こったアクションによって動作させることができる処理を登録します。
ローカル環境では、ビルドしてAWSCLIを使ってS3にアップしていた作業を、
workflowに時系列に沿って処理するように登録してみましょう。

workflowファイル（.yaml）を作成する方法は２種類あって、
1, GitHub上で作成する
2, リポジトリ内に直接ファイルを作成する
上記の２通りがあります。

画像では1のGitHub上での方法を紹介します。

step1
「Actions」タブ → 「set up a workflow yourself」リンクをクリックする。

step2
ファイル名は任意の名前で大丈夫です。
エディターエリアには何も入力されていないかと思いますが、
もし何か入っている場合は全て消しましょう。

name: build and Deploy to S3
on:
  push:
      branches:
        - main
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@main  # リポジトリをチェックアウト

      - name: Install Dependencies
        run: yarn install

      - name: Build
        run: yarn build  # ビルド

      - name: Deploy  # S3にデプロイ 
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        run:
          aws s3 cp dist/ s3://[S3バケットの名前]/ --recursive --region [S3バケットが作成されているリージョン]

こちらの .yaml ファイルを登録してプッシュした時点で、Actionsが動作します。
というのも、このファイルが登録されているブランチ自体が「main」ブランチの為、
２〜5行目に記載されているようにターゲットのブランチにプッシュされたら動作するようになっているので、
意図していないですが、動作検証のように動いてしまいます。

ファイルを修正してリポジトリへプッシュする

GitHub上でWorkflowの.yamlファイルを作成した場合、pullが必要になります。
ローカル開発環境でファイルを修正し、あらためてコミットをプッシュすると、
Actionが走るのを確認できると思います。
実際にActionが走った場合の画面を表示します。
成功した時（緑）、失敗した時（赤）は画像のようにアイコンで示されるので、
失敗した際はエラー内容を確認し、設定を修正して再度チャレンジしてください。
画像の失敗は、IAMユーザーのクレデンシャルを使用しているにもかかわらず、
S3へIAMユーザーのアクセス許可をおこなっていなかったために失敗しました。

まとめ

今回はIAMユーザーのクレデンシャル情報をGitHubに登録してCI/CDを行いました。
前の記事までの流れで、全てが揃っていたので、それほど難しくなかったと思います。
GitHubのOIDCを使ったS3へのアクセス→アップロードはまた機会があれば、
手順を解説していければと思います。

ubuntu-latestにインストールされているソフトウェアや機能の内容は下記になります。
気になる方は確認していただければと思います。
GitHub Actions Runner Images for ubuntu-latest at 230417