2020-06-11

Hugo のビルドとデプロイに CodePipeline をやめて CodeBuild だけを使うようにした

AWS

このブログ (Hugo) のビルドとデプロイには AWS CodePipeline を使っており、パイプラインの実行が完了するまでに 2 〜 3 分かかっていました。せっかく Hugo のビルドが高速なのに全体でそんなに時間がかかっているのは残念だったので、なんとかして時間短縮できないかなーというのが今回の話です。

目次

やること

CodePipeline を使用した Hugo のビルドおよびデプロイの時間を、なんとかして短縮したいと思います。 ‘なんとかして’ といっても何が原因がわからないと手のつけようがないので、とりあえず現状の構成をおさらいしておきます。

CodePipeline を使ったビルド・デプロイフロー

これまでは次のような構成で Hugo のビルドとデプロイを行っていました。

build and deploy Hugo in CodePipeline

CodePipeline では、 GitHub への Push とトリガーにして次の 3 つのフェーズで処理を実行していました。

  1. GitHub からソースを取得
  2. CodeBuild で Hugo のビルド、 S3 バケットへデプロイ
  3. Lambda 関数を実行し、 Slack へパイプラインの実行結果を通知

この中でメインなのはもちろん “2. CodeBuild で Hugo のビルド、 S3 バケットへデプロイ” ですが、その処理自体の所要時間は約 1 分程度でした。

ソースの取得は CodeBuild 単体でもできますし、昨年 12 月のアップデートにより、各 Code シリーズから SNS トピックおよび今年の 4 月に GA となった AWS Chatbot 経由で通知を行うことが出来るようになりました。

じゃあもう CodeBuild だけでいいやん。となるわけです。

AWS CodeBuild から送信されるイベント情報を SNS 経由で Slack に通知してみた

やったこと

CodePipeline の使用をやめて、 CodeBuild だけでビルド・デプロイフローを完結するように構成を変更しました。

CodeBuild だけを使ったビルド・デプロイフロー

CodeBuild だけを使ったビルド・デプロイフローは、次のような構成になります。

build and deploy Hugo via only CodeBuild

GitHub への Push を CodeBuild で検出し、ビルドを開始します。そして、結果の通知は AWS Chatbot によって Slack に通知します。この構成にすることで、全体の処理時間は約 1 分となりました。

ただし、通知の内容に関しては以前よりも簡素なものになりました。以前は 通知用の Lambda 関数を用意して、実行中のパイプラインの情報をゴニョゴニョして次のような通知を Slack に投げていました。

notify to Slack via Lamda

これが、 AWS Chatbot 経由になると次のような通知内容になります。

notify to Slack via AWS Chatbot

ま、ビルド終わったかどうかがわかれば良いので、十分といえば十分ですね。

CodeBuild だけにすることで発生するメリット・デメリット

CodeBuild だけにすることで発生するメリットとデメリットのおさらいです。

メリット

まず、メリットとしては下記の 3 点が挙げられます。

フロー全体の時間短縮はもちろんですが、使用しなくなった CodePipeline 、 Lambda の費用削減も達成することができます。特に CodePipeline に関しては、毎月の無料枠としてアクティブなパイプライン 1 つは無料ですが、それ以降はパイプライン 1 つあたり 1 USD/month の費用が発生します。既に 2 つ以上のパイプラインがアクティブな場合は 1 USD の削減になりますし、アクティブなパイプラインがこれだけだった場合は、貴重な無料枠を空けることができます。

…と、この内容は以前にも書いていました。

節約のために CodePipeline をやめて CodeBuild に全部任せてみた

デメリット

今回のフローに関していてば、デメリットは無いと思います。あえて上げるとすれば、 Slack への通知内容が簡素になったくらいでしょうか。

まとめ

Hugo のビルドとデプロイに CodePipeline をやめて CodeBuild だけを使うようにした話でした。
今回のようにソースが GitHub で管理されている場合には 1 CodeBuild で Push 等のイベントをトリガーにすることができるので、 CodePipeline でフローを開始する必要がなくなります。また、 Code シリーズからの通知、 Chatbot の GA により通知に関しても CodeBuild 単体で行うことが出来るようになったので、ここでも CodePipeline および通知用の Lambda 関数が不要となります。

このブログのような個人のちょっとしたプロジェクトや、実際のプロジェクトでも簡素なものに関しては CodeBuild だけでも十分なビルドフローを構築できそうです。

Footnotes

  1. ソースが CodeCommit の場合には直接トリガーすることができないため、 EventBridge 経由で Lambda を実行し、その中で該当の CodeBuild を実行する といった流れが必要になります。