CodeBuild-hosted GitHub Actions runner使ってみた①〜紹介編〜

はじめに

DTダイナミクスでSREセクションのテックリードをしている霜鳥です。
以前の記事はこちら↓

TL;DR

2024年4月24日にAWS CodeBuildがGitHub Actions(以下GHA)のランナーに対応したことを発表しました。
cf: AWS CodeBuild がマネージド型の GitHub Action ランナーのサポートを開始
CI/CDの選択肢を広げるこのサービスを使ってみたので今回と次回の2回を通して紹介します。

フルマネージドx従量課金という GitHub hosted runner の特徴と、OS/スペックの柔軟性という self-hosted runner の特徴を併せ持つ CodeBuild-hosted GitHub Actions runner という第三の選択肢について概要と所感をお伝えしたいなと思います!!

はじめに
TL;DR
これまでの選択肢
CodeBuild-hosted GitHub Actions runner
🙆合いそうなユースケース
🙅合わなそうなユースケース
次回予告

これまでの選択肢

これまでGHAを使うには以下の2通りの方法がありました。

GitHub hosted runner
self-hosted runner

1は言わずもがな ユーザ側がGHAのコンピューティングリソースを自前で用意する必要のないパターン ですね。
相当量の無料枠があるのでyamlファイル1つ書けばやりたいことをすぐに試せるのが魅力的です。
しかし無料枠は1アカウントに対して付与されるため、規模によっては無料枠はすぐに使い切ってしまいます。
さらにランナーのOSによって消費速度は大きく変わり、WindowsではLinuxの2倍、macOSでは10倍の速度で消費します。
また、vCPU数やメモリ数の選択ができない、カスタムイメージが使えないなどの制約もあります。

cf: GitHub ホステッドランナーの概要

そういう場合に使うのが2のself-hosted runnerです。

Git、Dockerが使えてGitHubと通信可能な場所にあればいいので極端な話をすれば開発者のローカルマシンでも良く、
一般的にはオンプレのサーバ、AWSでいえばAmazon EC2などがそのコンピューティングリソースとして使われます。
また1.に比べてジョブの制限時間も6時間から5日とかなり制限がゆるくなるため重たいテストやビルドを回したいという要件にも答えることができます。

今回紹介するのはこのself-hosted runnerの新しい選択肢です。

cf: 自己ホストランナーの概要

CodeBuild-hosted GitHub Actions runner

CodeBuildはCI/CDにおけるビルド処理やテストの実行を行えるフルマネージドなサービスです。
CodePipelineやCodeDeployなどAWSのCodeシリーズと組み合わせてCI/CDを組むことが多いですよね。

cf: CodeBuild

普段CodeBuildを使う際には処理を buildspec.yml に定義します。
しかしGHAのランナーとして用いる場合、処理の定義は普通のGHAと同様にGitHub リポジトリの .github/workflows 配下のyamlファイルに定義します。
CodeBuild-hosted GitHub Actions runnerの特徴を簡単に述べ、その後に合いそうなケース/合わなそうなケースを挙げてみます。

分かりやすくするためにCodeBuild側の特性を引き継ぐものには☀️、GHA側の特性を引き継ぐものには🌴を項目の先頭につけておきます。
(絵文字のチョイスに深い意味は無いです笑)

☀️従量課金である

CodeBuildの課金体系に則るため完全にコンピューティングに使った分だけが課金されます。
具体的には配置するリージョンとスペックの組み合わせで決まってきます。
EC2インスタンスにself-hosted runnerを立てた場合はインスタンスを起動している間ずっと課金されるので従量課金はありがたいですよね。

cf: AWS CodeBuild の料金

☀️フルマネージドであること

これはGitHubが用意したランナーを用いるのと同じ特徴ではあります。
ビルドやテストに用いるマシンを管理する運用コストが抑えられるのはインフラチームとしてはありがたいことです。

☀️使えるイメージが柔軟であること

CodeBuildにはAmazonLinux系の他、Ubuntu、macOS、WindowsServer(リージョンに制限あり)などのイメージが使用可能です。

cf: EC2 コンピューティングイメージ

さらにAmazon ECRなどにあげたカスタムイメージも使用可能なため特殊な計算ライブラリを都度インストールする必要がないのも魅力です。

🌴GHAのactionsを流用できること

GHAにはMarketplaceで公開されたactionsを uses で簡単に使うことができます。
例えば以下は各stepごとに、GitHubのcheckout、AWSへのログインを簡単に実現しています。
これがそのまま使えるため処理を完結に保つことができるのは素晴らしいですよね。

steps:
  - name: Checkout
    uses: actions/checkout@v4

 - name: Configure Aws Credentials
    uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
      aws-region: ${{ secrets.AWS_REGION }}
      role-duration-seconds: 7200

🌴トリガー設定が柔軟にできること

CodePipelineやAzure DevOpsなどをCI/CDツールとして使う場合、発火条件はブランチ単位になることが多いですよね。
その場合README.mdなどのドキュメントを変更しただけでもビルドが走って時間やお金がかかる...ということもあります。
しかしこれは実質的にはGHAなので発火条件を特定パス配下の変更、タグ付け、ラベル追加、さらには手動実行(workflow_dispatch)まで柔軟に設定可能です。

cf: ワークフローをトリガーするイベント