AWS CodeBuildのGitHub ActionsランナーからLatchkeyへ移行
CodeBuildはGitHub Actionsランナーを自社のAWSアカウント内でホストします。Latchkeyはそれをあなたの代わりにホストします。移行時に何が変わるかを正確に説明します。
AWS CodeBuildのドキュメントによると、CodeBuild上でGitHub Actionsを実行するには、Runnerタイプのプロジェクトを作成し、GitHubを接続し、WORKFLOW_JOB_QUEUEDイベントをフィルタするwebhookを構成し、codebuild-<project>-${{ github.run_id }}-${{ github.run_attempt }}という形式のruns-onラベルで対象を指定します。AWSにフルコミットしているなら強力ですが、プロジェクト、IAMサービスロール、VPC配線、webhookはあなたが所有します。Latchkeyは、1行のruns-on変更で到達できる完全マネージド・自己修復のランナー上で同じjobを実行し、運用するAWSアカウントやインフラはありません。移行の様子を以下に示します。
CodeBuildホストのランナー vs Latchkey
| 機能 | AWS CodeBuild（セルフホストランナー） | Latchkey |
|---|---|---|
| ランナーの所在 | 自社のAWSアカウント | あなたの代わりに完全マネージド |
| セットアップ | CodeBuildプロジェクト + IAMロール + webhook | 1行のruns-onラベル変更 |
| AWSアカウント / IAM / VPCが必要 | 必要 | 不要 |
| 構成するwebhook | あり（WORKFLOW_JOB_QUEUED） | なし |
| 自己修復（一時的障害の自動リトライ） | なし | あり |
| AWSとの深い統合 | あり（IAM、VPC、AWSサービス） | AWSネイティブではない |
| 得意分野 | 自分で運用するAWSネイティブのランナー | AWSセットアップ不要のマネージド自己修復ランナー |
CodeBuildが本当に優れている点
CodeBuildはAWSネイティブです。AWS CodeBuildのドキュメントによると、GitHub Actionsランナーはあなたのアカウント内でIAMサービスロールとともに実行され、VPC内で実行してRDSやElastiCacheのようなリソースに到達できます。buildがすでにAWS認証情報、プライベートサブネット、厳格なIAM境界を前提としているなら、そのネイティブ統合は実際の利点であり、残る良い理由です。
Latchkeyで運用しなくなるもの
LatchkeyはAWSで構成・保守する部分を取り除きます。RunnerタイプのCodeBuildプロジェクトなし、スコープするサービスロールなし、配線するVPCサブネットとセキュリティグループなし、デバッグするWORKFLOW_JOB_QUEUEDのwebhookなしです。GitHub Actionsにはマネージドランナーが見え、一時的・機械的な障害はjobを失敗させる代わりに自動的に自己修復・リトライされます。
移行の仕組み
- 1つのworkflowを選び、そのruns-onをcodebuild-<project>-...のラベルからLatchkeyのラベルに変更します。
- CodeBuildの経路と並行して実行し、実際のbuildで実時間と信頼性を比較します。
- 残りのworkflowを1ラベルずつ展開します。YAML、actions、stepsは同じままです。
- 本当にVPC内AWSアクセスが必要なjobはCodeBuildに残し、残りを移行します。
結論
ネイティブなVPC内AWSアクセスと厳格なIAMが必要なjobはCodeBuildに残します。それ以外については、CodeBuildプロジェクト、サービスロール、VPC、webhookの運用が望む以上の負担なら、Latchkeyは1行のruns-on変更で完全マネージド・自己修復のランナーを提供します。1つのworkflowで試験導入し、実際のCodeBuild buildと比較してください。