GitHub Actions(デプロイ自動化)で、S3+CloudFrontへの手動アップロード作業をゼロにした話

おはようございます。今日はポートフォリオサイトの運用を1つアップデートした話です。地味だけど、これから先ずっと楽になる類の改善なので、記録として残しておきます。

結論

「コードを直したら、あとはGitHubにプッシュするだけでサイトに反映される」仕組みを作りました。しかも、AWSへの「合鍵」を一切どこにも保存しない、少し安全性にこだわった作り方をしています。

今まで何が面倒だったか

このポートフォリオサイトは、S3(ファイルを置く場所)とCloudFront(それを世界中に速く届ける仕組み)で公開しています。今まで、コードを直すたびに手動でこんな作業をしていました。

1. ファイルをS3に手動でアップロード(同期)する
2. CloudFrontに残っている古いキャッシュ(以前の内容の写し)を、手動で消す

1行直すだけの修正でも、この2つのコマンドを毎回自分で打つ必要がありました。忘れると「直したはずなのに古いままの表示」が続く、というオチになりがちです。

自動化の仕組みを作ってもらった

今回は、GitHub Actions(デプロイ自動化)という仕組みを使いました。ざっくり言うと「GitHub上である出来事が起きたら、決まった作業を自動で実行してくれるロボット」のようなものです。

今回設定したのは、こんな流れです。

「本番用の履歴に変更がプッシュされたら → 自動でS3に同期 → 自動でCloudFrontのキャッシュを消す」

これで、今後は`git push`という1つのコマンドを打つだけで、サイトへの反映まで全部終わるようになりました。

こだわったのは「鍵を持たせない」こと

ここが今回、一番時間をかけた部分です。

普通、こういった自動化を組む場合は、AWSの「合鍵」のようなもの(アクセスキー)を発行して、それをGitHub側に預けておく方法が一般的です。ただ、この方法だと、預けた合鍵がもし漏れてしまった場合、ずっと有効な鍵なので被害が広がりやすいという弱点があります。

そこで今回選んだのが、OIDCという仕組みです。イメージとしては、合鍵を渡す代わりに「毎回、その場限りの入場チケットを発行してもらう」方式です。

具体的には:

権限自体も「S3のこのバケットへのアクセス」と「このCloudFrontのキャッシュ削除」だけに絞り込んであるので、万が一何かがあっても被害範囲が限定される作りになっています。

実際にやってみて

設定自体は、AWS側の権限周りの設定(IAMロールという、権限のかたまりを新しく作る作業)と、GitHub側の手順書(ワークフローファイル)を1つ作るだけで完了しました。作業自体は決して長くなく、初回のプッシュで実際にきちんと動いているのをGitHub上で確認できたときは、地味に達成感がありました。

今回の要点まとめ

まとめ

「動けばいい」だけなら、合鍵を預ける簡単な方法で十分だったかもしれません。それでもあえて一手間かけて「鍵を持たせない」設計にしたのは、実際の現場でも意識されている考え方に触れておきたかったからです。地味な改善ですが、個人的には「めんどくさがり屋」なので今回の作業の中で一番納得感のある部分でした。

それでは、また次の記事で。