Github Actions で AWS S3 にファイルを置いてみた

はじめに

こんにちは、やしまです。
実は環境設定は苦手でプログラミングが好きなのですが、書いたものはすべて環境設定な気がしています。
苦手だからこそ書いて残すことに意味があると信じながら、今日はちょっと特殊な方向としてGitHubのActionsでAWSにアクセスしてみようかと思います。

普通に考えられるケースとしては、リポジトリにpushしたものをビルドして、そこで生成されたものをAWSのS3に置いたりコンテナ用のリポジトリにpushするなんて用途かなと。
ソースのリポジトリもAWSに置いて内部で連携するなんてことはやったことある気がするのですが（もう覚えてない）今回はGitHubのリポジトリからAWSのサービスに連携してみようという試みです。
あまり難しいことまでは含めたくないので、シンプルなWebサイトを想定して、リポジトリの特定ディレクトリ以下をS3の特定バケットに半自動で連携します。
連携方法はアクセスキーを使う方法とOIDCがあるそうなのですが、セキュリティリスクが少ないというOIDCで今回は連携します。

前提

• GitHubに連携するファイルを管理するリポジトリがある
  • 連携するファイルはリポジトリルートのstaticディレクトリ以下に配置しているものとします
• AWSにアカウントがある（今回の範囲程度なら無料で作れて利用できるはずなので持ってない方は作っておいても良いと思います）

やったこと

S3に同期対象のバケットを作成

AWSのS3にファイルを連携するバケットを作成します。
今回はちょっと丁寧めに書きますが、次回からはわかりきったようなことはガンガン省略して書くつもりです。

管理コンソールでS3を開く

まずAWSの管理コンソール（ブラウザ）にログインして、S3を開きます。
検索窓にサービス名（今回でいえばS3）を入力すると該当するサービスが表示されるので、それを開きます。（けっこう適当に入力しても汲んでくれるのでうろ覚えでも大丈夫）
そして画面の右上あたりに米国(北部バージニア)という選べそうなものがありますが、これはリージョンっていう物理的にどこに作るかというものです。
物理的な距離が近いほうがアクセスが早くなることを考慮して、作る場所を決定します。

バケットを作成

S3の管理画面で汎用バケットのところからバケットを作成をぽちっとします。
いろいろ設定できるものはありますが、一般的な設定だけをちょっといじって作成してしまいます。（他の設定は細かいことになるはずなので今回はスルーしておきます）
まず、バケット名は自分でわかりやすいバケット名にします。
ここでたぶんバケット名前空間がデフォルトでグローバルになっていると思うのですが、推奨となっているアカウントのリージョナル名前空間にして画面右最下部にあるバケットを作成をぽちっとします。
これでバケットが作成できるはずなので、バケット一覧の画面に戻って（パンくずから）バケットが作成されていることを確認します。
自分でつけた名前の後ろにアカウントIDやリージョンがついてるバケットが表示されているはずです。

IAMロールを作成

IDプロバイダの追加

AWSの管理コンソールでIAMを開きます。
左側のメニューのアクセス管理の中にIDプロバイダというのがあるはずなのでこれを開きプロバイダを追加をぽちっとします。
IDプロバイダを追加する画面になるので、まずはプロバイダのタイプとしてOpenID Connectを選択します。
プロバイダのURL入力ができるはずなので、以下を入力します。

https://token.actions.githubusercontent.com

対象者には以下を入力します。

sts.amazonaws.com

※ 参考URL（GitHub公式）

ロールの作成

IAMの左側のメニューのアクセス管理の中にロールというのがあるはずなのでこれを開きロールを作成をぽちっとします。
信頼されたエンティティタイプとしてウェブアイデンティティを選択します。
アイデンティティプロバイダ、Audienceに先ほど作成したIDプロバイダと対象者を選択します（なぜ名称表記が違うのか⋯）
GitHub organizationにはリポジトリのオーナー（個人の場合はユーザ名）を入力します。
GitHub repositoryには連携するリポジトリを入力します。
*の（省略した）場合は全リポジトリから連携可能になるので指定しないでもいいですが、セキュリティリスクを考慮して指定しておいたほうが良いです。
GitHub branchは状況に応じて対象ブランチを入力します。
今回はテスト的に連携するのでmainブランチなど指定せずにそのまま（*）でいきます。
ただし本番に連携する場合は、誤って本番にmain以外が混入しないようmainを入力しておくことをおススメします。
入力が終わったら次へをぽちっとして、ポリシー設定の画面にいきます。
死ぬほどポリシーが表示される（ページングあり）ので、以下を検索してチェックONにして次へをぽちっとして最後の画面へいきます。

AmazonS3FullAccess

ここではロール名、説明を入力します。
説明に日本語が使えないようなので、つたない英語で入力してみました。

GitHub Actionsの設定

AWS側の権限設定が終わったので、GitHub側でActionsの設定をします。
そもそもGitHub Actionsとは何かというと、GitHubが提供している自動、または手動でコマンドを実行する仕組みです。
コマンドを実行というところがちょいちょいミソで、ビルドやらテストやらデプロイやら、けっこう何でも出来てしまうすぐれものです。
特にリポジトリにpushされたら自動で実行される仕組みはCI/CDにとても有用だと思っています。
詳しくは公式を見てください。（公式サイト）

実行定義の作成（入口）

まずは実行定義を作ります。
リポジトリルートの .github/workflows に xxx.yml を置くと、それがワークフローアクションとして自動で登録されます。
ただし、これはmainブランチに置かれている必要があります（中身はブランチごとに違うものでも良いのですがファイルが必要）
このあたり、自分なりの勝手な理解なので、間違っていたら教えていただけたら幸いです。

実行定義の作成（内容）

とりあえず説明は後にして、リポジトリルートの .github/workflows/deploy.yml として以下を作ります。

name: Deploy to S3

on:
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest

    permissions:
      id-token: write
      contents: read

    steps:
      - name: コード取得
        uses: actions/checkout@v4

      - name: AWS認証（OIDC）
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::${AWS_ACCOUNT_ID}:role/${AWS_ROLE_NAME}
          aws-region: ${AWS_REGION}

      - name: S3にアップロード
        run: |
          aws s3 sync ./static s3://${AWS_BUCKET_NAME}
# 完全に同期させるには --delete オプションを付けるが、今回は見送る
#          aws s3 sync ./static s3://${AWS_BUCKET_NAME} --delete

シェルの変数的なところはご自身の環境に合わせて適宜変更してください（適宜というか変更しないと動かないはずです）
AWSのアクセスキーは使わない方式なので、ロール設定をひどいことにしていなければセキュリティリスクもたいしてないとは思いますが、それでもアカウントIDやバケット名やロール名をコミットしたくない場合は、GitHubの環境変数（シークレットでもOK）に設定して、それに合わせた記載にしてください。

変数名	意味	概要
AWS_ACCOUNT_ID	AWSのアカウントID	管理コンソールの右上などに出ている数字の羅列 ロールのARNを見るとわかると思います
AWS_ROLE_NAME	AWSの利用するロール名	先ほど作成したロール名を指定します
AWS_REGION	利用するロールのリージョン	ロールを作成したときのリージョンです よくわからなかったらus-east-1にしておけば良いとか
AWS_BUCKET_NAME	S3のバケット名	ファイルの連携先のバケット名です 今回はディレクトリには対応していないです

ファイルを作り終わったらmainブランチをpushしてください。

GitHub Actionsの実行

mainブランチ以外のブランチのファイルを連携したい場合、そのブランチにも先ほど作成したdeploy.ymlが含まれるようにしておいてください。

ブラウザから実行

準備が出来たらGitHubの対象リポジトリをブラウザで開きます。
上から2行目のメニュー（Code、Issues、...と並んでいるところ）にActionsというの（アイコンは再生ボタンぽいやつ）があるので、ここへ進みます。
すると、左のペインにActions、右のペインにAll workflowsと表示された画面になると思います。
もしそういうのではなく、今からActionsを作成するからテンプレートを作成してね！みたいな画面が出た場合、mainブランチにdeploy.ymlが正しくpushされていない可能性が高いです。確認してみてください。

左のペインからDeploy to S3（deploy.ymlのname）をぽちっとすると右のペインがそのワークフロー用に切り替わります。
Run workflowという選択するっぽい形のボタンがあるはずなので、これもぽちっとします。
するとUse workflow fromというキャプションでブランチを選択するところと、下にRun workflowというボタンが出るので、ファイルを連携したいブランチを選択して、Run workflowボタンをぽちっとします。
すると実行画面に切り替わるので、あとは待っていれば実行が完了します。
グリーンになったら成功です。
念のためS3を確認して、想定通りのファイルが連携されているかを確認してください。

失敗例

グリーンではなくレッドだった場合は失敗です。
ぽちっとしたらGitHubActionsのログがある程度ですが見えるので、原因を推測して直しましょう。
ありがちなパターンはよくわからないので、よくわからないエラーだったらAIさんにでも相談すると良いと思います。

終わりに

ちょっと個人的に準備中のホームページの運用方式を検討してたのを記事として書いてみました。
が、まずは単にGitHub Actionsを使ってみるぐらいが良かったのではないかと後悔しています。
そうしたほうが無駄に長くないだろうし需要もあるだろうしって感じで。

そして個人的にやっていることがどんどん汎用的でなくなっていく感じがしているので、何か書けることが見つかれば書きますけど期待はしないでくださいということで今回は終わりです。

ではでは。