GitHub ActionsでSelf-Hosted Runnerを使う

CI/CDに携わっていて、GitHub Actions(GHA)を業務で毎日使用しています。プロジェクトでは、これまで100% GitHub-Hosted Runnerを使用していたのですが、社内事情でSelf-Hosted Runnerを一部で使用することになりました。この記事では、Self-Hosted Runnerの設定の仕方、workflowの書き方を紹介します。

読者ターゲット

• GHAでSelf-Hosted Runnerをこれから使用予定の人
• GHAでGitHub-Hosted Runnerを使用してWorkflowを作成したことがある人

Self-Hosted Runnerが使用されるケース

• GitHub-Hosted Runnerではセキュリティ要件を満たせない
• Workflowの実行にかかる費用を抑えたい
• GitHub-Hosted Runnerよりもハイスペックなサーバが必要

Self-Hosted Runnerの設定

設定方法は2通りあります。（ここでは、1を紹介します）

1. リポジトリごとに設定する
2. Organizationで一元管理して設定する

2の場合、複数のリポジトリを一元管理することができます。

OS・サーバ

Self-Hosted Runnerを設定するサーバは以下の通りです。

• Ubuntu 20.04.06 LTS

この他のOSやアーキテクチャについては、GitHub公式ドキュメントを参照してください。

設定方法

1. Self-Hosted Runnerでworkflowを使用したいリポジトリを選択

2. Settings > Code and Automation > Actions > Runnersを選択

3. New self-hosted runnerをクリック

   

4. Self-Hosted Runnerを設定するサーバに関する情報を入力

   1. サーバのOS: Ubuntu Server 22.04 LTS → Runner image: Linux
   2. サーバのアーキテクチャ: x64 → Architecture: x64

   

5. Self-Hosted Runnerを設定するサーバへ移動し、適切なディレクトリを作成または該当のディレクトリに移動
   ℹ️ 私のプロジェクトの場合は、Organizationの一元管理ではなく、個々のチームが同じサーバ（Self-Hosted Runner）で複数のリポジトリを使用していたので、リポジトリの名前やプロジェクトの名前でディレクトリを作成しています

6. RunnerをダウンロードするディレクトリでDownloadとConfigureに表示されているコマンドを叩く

   # Download 
   # Create a folder
   $ mkdir actions-runner && cd actions-runner # Download the latest runner package
   $ curl -o actions-runner-osx-x64-2.317.0.tar.gz -L https://github.com/actions/runner/releases/download/v2.317.0/actions-runner-osx-x64-2.317.0.tar.gz # Optional: Validate the hash
   $ echo "0b23ee79731522d9e1229d14d62c200e06ac9d7dddf5641966209a7700a43c14  actions-runner-osx-x64-2.317.0.tar.gz" | shasum -a 256 -c # Extract the installer
   $ tar xzf ./actions-runner-osx-x64-2.317.0.tar.gz
   

   3行目の./config.shまでを実行

   # Configure
   # Create the runner and start the configuration experience
   $ ./config.sh --url https://github.com/アカウント名/リポジトリ名 --token XXXXXXXXXXXXXX # Last step, run it!
   $ ./run.sh
   

   ℹ️ config.shを実行すると、インタラクティブにrunnerを配置するディレクトリ名やリポジトリをクローンするディレクトリ名、labelの設定などが可能です。
   この設定はそれぞれのプロジェクトでやりやすいように管理すれば良いと思います。私のプロジェクトでは、複数のRunnerを同一のサーバ上で使用しており、下記のように現状なっていますがこれといって懸念点や問題は出ていません。

   • runnerを配置するディレクトリ名: デフォルトを使用(actions_runnerやactions-runner)
   • リポジトリをクローンするディレクトリ名: デフォルト名（_work）を使用
   • labelの設定: 設定なし

   ℹ️ ./run.shは手動でSelf-Hosted Runnerを起動するシェルです。単発でSelf-Hosted Runnerを使用したい時に使用するようです。ちなみに私のプロジェクトでは、初めて設定した時にRunnerの設定ができたかの確認で使用したのみで、それ以来は使用していません。

7. Runnerが常に起動するよう設定する
   6で./run.shを使用していないと書きましたが、代わりに./svc.shを使用しています

   $ ./svc.sh start
   

   statusの確認、Runnerの停止、svc.shのコマンド一覧の表示をさせることも可能です

   $ ./svc.sh status # statusの確認
   $ ./svc.sh stop # Runnerを停止
   $ ./svc.sh help # コマンド一覧の表示
   

   Self-Hosted Runnerの設定は以上です。

   （補足説明: ここまで読まれて、リポジトリ単体でrunnerを登録する方が、Organizationで一元管理するよりもメリットがあるのかと思われたかもしれません。弊社では、Organizationは経理部署が管理しており、他部署であること、我々エンジニアが設定したりその設定を直接確認できないため、同じサーバであってもリポジトリごとにrunnerを設定した方が効率的に良いため、このような運用をしています。一般的にリポジトリ単体でrunnerを登録する方がメリット高というわけではありません）

Workflowの書き方

Self-Hosted Runnerを使用する場合、workflowで使用するOSを明記する必要があります。

「OS・サーバ」で紹介した環境と同じで、設定時にlabelの指定をしなかった場合、workflowには下記のように記載します。

runs-on: [self-hosted, linux, ARM64]

labelを設定した場合は、上記に含ませる必要があります。
例えば、cicdというlabelを設定した場合は下記のように記載します。

runs-on: [self-hosted, linux, ARM64, cicd]

この箇所以外はいつものworkflowのように記載することができます。

参考資料

GitHub公式ドキュメント | About Self-Hosted Runner

最後に

最後まで読んでいただき、ありがとうございました！
これからSelf-Hosted Runnerを使うエンジニアさんのお役に、少しでも立てると嬉しいです。