tl;dr
- GitHub Actionsのプライベートリポジトリでarm64ランナーを使うためにはSelf-Hosted Runnerの設定が必要(2025年6月現在)
- AWSの場合は、CodeBuildがSelf-Hosted Runner向けの設定をサポートしているのでそれに従うと楽に構築可能
- パブリックリポジトリの場合は、2025年6月現在パブリックプレビューでarm Runnerが使えるのでこの記事の対応は不要
この記事でわかること
- GitHub Actions+CodeBuildでSelf-Hosted Runnerを構築する手順
前置き
私の開発するサービスでは現在、
- 開発者向け支給PCがほぼApple Silicon搭載のマシンに切り替わったこと
- EC2 → ECS on Fargateへのリプレイスを経て、キャパシティ戦略をより柔軟に組み立てられるようになったこと
- コスト削減の波
などの状況の変化に合わせて、サービスの実行環境をamd64からarm64、つまりGravitonインスタンスでの実行に切り替え始めています。
まずは開発環境をGraviton化し、他の開発メンバーにも触ってもらいながら動作や開発体験に問題がないかを確認してもらっていたのですが、さっそく問題が発生しました。
ときどきではありますが、ビルドキャッシュを参照せずにビルドすることがあり、その場合通常10分程度で完了するデプロイが1時間以上かかっていることが判明したのです。
原因はamd64のランナー上でarm64のイメージをビルドしていることでした。
ビルド処理ではdocker/buildxを使ってQEMUを経由したクロスプラットフォームビルドを実行していたのですが、ドキュメントにある通り、当然この方式はamd64のマシン上でamd64のイメージをビルドするときと比べてビルドが遅くなります。
Emulation with QEMU can be much slower than native builds, especially for compute-heavy tasks like compilation and compression or decompression.
Use multiple native nodes or cross-compilation instead, if possible.
特に、今回問題になっていたイメージはPHPのアプリケーションコンテナで、pecl周りで上記の コンパイルや圧縮・解凍など負荷の高い処理 が複数動いていたために長いビルド時間になってしまっていたようです。
そこで、ドキュメントにもある通り、ネイティブな環境でビルドすることで高速化を図ることにしました。
ネイティブな環境はGitHub-Hosted Runnerが使えたらよかったのですが、プライベートリポジトリではまだ実行できないことから、Self-Hosted Runnerを構築して使うことにしました。
この記事では、GitHub Actions+CodeBuildでSelf-Hosted Runnerを構築する手順を紹介します。
Self-Hosted Runnerを構築してarmなイメージをビルドする
AWS公式のチュートリアルを参照しながら、CodeBuildプロジェクトを設定していきます。
GitHub – AWSの接続を設定する
まずはGitHubに連携するための設定をします。
この設定を行うことで、GitHubのアカウント/Organization以下にある情報をCodeBuildから参照できるようになります。
接続の設定へはCodeBuild(や、他のCode.*系サービス)のサイドメニューから辿りつけます。
一覧画面から、 接続を作成 をクリックします。
プロバイダーを選択し、名前を決めて先に進みます。
接続方法を選択して、接続ボタンを押します。
GitHubの認証ページにリダイレクトされるので、許可をしたら接続設定の作業は完了です。
Self-Hosted Runner向けのCodeBuildプロジェクトを作成する
前の手順で作成した接続を開くと、その接続を使ってできることの一覧が表示されます。
今回は、GitHub Actions セルフホストランナーをセットアップする を選択します。
ランナープロジェクトが選択された状態でCodeBuildのプロジェクト設定画面に遷移するので、必要項目を埋めていきます。
この設定で、重要な項目が2点あります。
ランナープロバイダー設定
ランナープロバイダー設定では、ランナーを実行できる呼び出し元を指定できます。
万が一、GitHub側の権限が乗っ取られたりしたときに、呼び出し元が制限されていると被害を小さくできます。
最小権限の原則に従って、可能であればリポジトリ単位で呼び出し元を指定するのをおすすめします。
環境設定
環境設定では、GitHub Actionのジョブを実行する環境について設定ができます。
今回は、arm64のランナーを設定したいので、イメージに aws/codebuild/amazonlinux-aarch64-standard:3.0 を指定します。
また、必要に応じて 追加設定 内のコンピューティングスペックの調整や、Docker Hubへのログインをせずにイメージをpullする場合はVPC設定などを実施してください。
GitHubでランナーを呼び出す
ここまでの設定を終わらせることで、GitHub ActionsのランナーとしてCodeBuildプロジェクトを指定するできるようになります。
ランナーのラベルは codebuild-CodeBuildのプロジェクト名-${{ github.run_id }}-${{ github.run_attempt }} になっています。
プロジェクト名が hogepiyo-project であれば、以下のようなワークフロー設定で呼び出すことができます。
name: sample
on:
push:
branches:
- main
jobs:
do-something:
runs-on: codebuild-hogepiyo-project-${{ github.run_id }}-${{ github.run_attempt }}
steps:
- uses: actions/checkout@v4
armなランナーにおいても、docker/build-push-action, docker/metadata-action, docker/setup-buildx-actionなどがそのまま使えるため、普段通りにビルド&プッシュの処理を書いてあげれば(もしくは既存のビルド処理のrunner:部分だけ差し替えてあげれば)ビルドが実行できます。
まとめ
上記の手順でarm64のランナーを設定することで、GitHub Actionsでネイティブにarm64のコンテナイメージをビルドできるようになります。
また、今回の目的だったビルド時間の短縮についても、キャッシュが使えなかった際もおおむね5～6分程度でビルドが完了するようになったため、解決できたと言えそうです。
GitHub ActionsのSelf-Hosted Runnerを構築する手順については、AWSがサポートしているため非常に簡単に設定することができます。
今回はarm64ビルドのためのランナー構築でしたが、
- コストのかかる処理をGitHub Actionsの体験はそのままにCodeBuildにオフロードしたい
- VPC内のリソースに対して定期的な処理を行いたい
などのユースケースでもCodeBuildでSelf-Hosted Runnerを用意する手法は有効そうです。
ただし
記事冒頭でも書いたとおり、パブリックリポジトリの場合は、2025年6月現在パブリックプレビューでARM Runnerが使えます。
パブリックプレビュー化されているということは、近々プライベートリポジトリでもarmなGitHub-Hosted Runnerが使えるようになりそうです。
armなランナーで処理したい、というユースケースにおいては、しばらく待ってみるというのも有効な解答になるかもしれません。
検証中に参考にした記事
Views: 1
