Blog

GitHubのOrganizationレベルで利用できるRunnerをAWS CodeBuildで用意する

ニフティ社内で使われているGitHub Enterpriseの管理者をしている石川です。

今年の4月にself-hosted runnerとしてCodeBuildを利用できるようになる嬉しいアップデートがありましたね。
CodeBuild-hosted GitHub Actions runnerは、4月時点ではリポジトリとCodeBuildプロジェクトが1対1で利用する方法しか取れませんでしたが、6月のアップデートでOrganizationやEnterpriseレベルでひとつのCodeBuildをRunnerとして指定することができるようになりました!
AWS CodeBuild now supports organization and global GitHub webhooks – AWS

ということで今回はOrganizationレベルでのRunner設定を試してみます。


CodeBuildの設定

Terraformだと以下のようなコードで設定できます。

CFnでも作れるとよかったのですが、まだ対応していないようです。

Global webhooks and GitHub Enterprise webhooks are not supported by AWS CloudFormation.

Filter GitHub organization webhook events (AWS CloudFormation) – AWS CodeBuild

デプロイ前に注意が必要なのが、事前にGitHub認証情報をCodeBuildに手動で登録する必要があります。上記コードでは除いてしまってますが、PATやOAuthを使いSecret Managerに認証情報を格納した場合、CodeBuildのサービスロールにシークレットを取得する権限も必要となります。

参考:GitHub and GitHub Enterprise Server access in CodeBuild – AWS CodeBuild

CodeBuildのプロジェクトが作成されると同時にOrganizationにWebhookが登録されます。

管理者視点だとちょっと困ったことがあって、Webhooks一覧を見てもどのAWSアカウントのCodeBuildが呼ばれるのかここからだと識別できません。
GitHub認証情報管理の問題もありますし、Organization共通のRunnerは専用のAWSアカウントで管理した方がいいかもしれません。

Runnerの利用制限

Organization全体で使えるようなRunnerとして登録しつつも、利用方法に制限を加えたい場合があります。その場合はWebhookのFilterを使って制限を行います。

参考:aws_codebuild_webhook | Resources | hashicorp/aws | Terraform | Terraform Registry

上記の例だと特定のワークフロー名で実行されたGitHub Actionのときのみ利用できるRunnerとなります。ほかにもいろいろな条件でFilterを作成することができます。
Terraformに限っては、まだ REPOSITORY_NAME を使っての制限は作れないようなので、ここはアップデートを待ちましょう。

参考:[Enhancement]: Add REPOSITORY_NAME event type filter to aws_codebuild_webhook resource · Issue #38868 · hashicorp/terraform-provider-aws

GitHub Actionsの設定

組織レベルでもリポジトリレベルでも変わりません。
WorkflowのYAMLに以下のフォーマットでRunnerを指定すれば動作します。
組織内のリポジトリであれば、これだけで利用できるはかなりお手軽ですね。

参考:Tutorial: Configure a CodeBuild-hosted GitHub Actions runner – AWS CodeBuild

Jobを実行するまでのセットアップも課金対象

CodeBuildで実行する場合、毎回Runnerのセットアップと登録処理が行われます(buildspecの指定はできないため、どんなイメージを用意しても必ず実行される)。これが20〜30秒かかっていて、数秒で終わるJobだろうとこの時間が追加で実行時間として加算されます。
GitHub Actionsよりも格段に安いですが、Job実行時間以外も計算に入れておかないといけない点に注意が必要です。

リポジトリごとにビルド費用を算出できるか

CUR/CUR2 で確認しましたが、CodeBuildのビルドステータスにあるイニシエータの情報はありませんでした。CloudWatch Logsに出力できるCodeBuildのログからもリポジトリの情報は標準では出力されておらず。残念ながらCURやCodeBuildのログから算出することはできませんでした。

なので、ちょっと手をかけて算出する必要があります。

まとめ

  • 組織レベルのRunnerを作るのは簡単
  • GitHub Organization ownerの認証情報管理とRunnerの置き場はちゃんと考える必要がある
  • リポジトリごとの利用量や費用算出は一手間かければできる

CI/CDを組織全体で共有管理している場合は、とても嬉しいアップデートですね。
一方各アカウントでCI/CDを管理している場合は、Organization owner権限が必要なポイントがあり、複数リポジトリで利用したいから使いたいという用途では少々使いにくい面もあります。
GitHub認証情報をどう管理していくかという問題とも紐づいているため、そこも考慮して利用を検討していくといいのではないかと思います。

ニフティでは、
さまざまなプロダクトへ挑戦する
エンジニアを絶賛募集中です!
ご興味のある方は以下の採用サイトより
お気軽にご連絡ください!

ニフティに興味をお持ちの方は
キャリア登録をぜひお願いいたします!

connpassでニフティグループに
参加いただくと
イベントの
お知らせが届きます!