今回は、ホステッドランナーについて触れます！！

皆さんこんにちは。
最近、GithubActionsでセルフホステッドランナーを使用する機会があり、そもそもランナーとは何ぞやとなった、小山こと"こやまん"です。

Githubには、GithubActionsと呼ばれるCI/CD機能を提供する自動化ツールがあり、トリガーに応じてテストやビルドを自動で実行できるため、開発効率の向上に大きく役立ちます。一例では、PR（プルリクエスト）を作成したタイミングで、テストを自動実行し、テストが失敗した場合はマージさせないようにすることで、手動でのテストの実行時間の削減しリグレッションを防止することが可能です。

この便利なGitHubActionsを実行するための仮想環境はランナーと呼ばれます。本記事では、このランナーについて触れていきます。

ランナーの種類について

下記は、GithubActionsのワークフローの一部です。

1name: Test Sample Workflow
2
3on:
4  push:
5    branches: [ develop ]
6  pull_request:
7    branches: [ develop ]
8
9jobs:
10  test:
11    runs-on: ubuntu-latest
12    .......

runs-onという記述がりますが、こちらの項目がランナーの設定となっています。
恥ずかしながら、今までは特に深く考えず、runs-onをubuntu-latestに設定すれば動くのね程度の認識でした。

ランナーには、大きく分けて二つの種類があります。一つはGithub公式が提供するGithubホステッドランナー、もう一つはユーザーが管理するサーバー上に設置するセルフホステッドランナーです。

容易に扱えるGithubホステッドランナー

特に深く考えず、自前で環境を用意する必要もないことから、GithubActionsを利用している大部分の人が、Githubホステッドランナーを利用しているかと思われます。すぐに利用が可能で、ランナー自体もGithubによって自動的に更新・管理されるため、セキュリティやパフォーマンス面でのメンテナンスが容易なことが特徴です。
仮想マシンの種類は、Linux、Windows、macOSなどが用意されており、ubuntu-latest、windows-latest、macos-latestなどを指定することで利用可能です。
注意点として、GithubActionsの実行は、１ヶ月あたり2,000分の無料枠がありますが、Linuxに対して、Windowsの場合は２倍、macOSの場合は10倍の無料枠が消費されます。
また、GithubActionsを実行するリポジトリがパブリックリポジトリか、プライベートリポジトリかで仮想マシンの性能が変わる仕様となっているようです。

プライベートリポジトリでubuntu-latestを指定した場合

CPU：2
メモリ：7GB
ストレージ：14GB

パブリックポジトリでubuntu-latestを指定した場合

CPU：4
メモリ：16GB
ストレージ：14GB

流石に業務で扱ってるリポジトリをパブリックにする訳には行きませんが、パブリックリポジトリが羨ましくなったり...

自由度の高いセルフホステッドランナー

自前で用意するため、高度なカスタマイズ性があり、特定の環境要件を満たすことが可能です。反面、メンテナンスをユーザーが実施していく必要があります。
AWSのEC2や、GCPのGCEを利用することが多いのではないかなと考えます。

ランナーの選定基準

GitHub Actionsは、公開リポジトリに対しては無制限に無料で使用できますが、プライベートリポジトリでは一定の無料枠を超えると料金が発生します。2024年2月現在、個人プランでは最大2,000分まで無料で利用可能です。
ワークフローの内容や実行タイミングによりますが、個人開発の場合、例えば1回あたりのアクションが約10分であれば、1日に6回実行することができ、無料枠内で十分な余裕があると考えられます。
しかし、組織での開発では複数人による作業で無料枠を超える可能性が高いです。例として、私が頻繁に使用する"ubuntu-latest"の公式ホステッドランナーを利用すると、CPUの数が2で、1分あたりのコストが1.2円になります。組織全体で1日に100回のアクションを行うと仮定すると、1ヶ月で30,000分を使用し、無料枠を3,000分とした場合、残り27,000分に対して32,400円の費用がかかる計算になります。
このような、リポジトリがプライベートかつ、GithubActionsの実行時間が無料枠を超える場合に、セルフホステッドランナーの利点が大きくなってきます。
自前でランナーの動作環境を用意すれば、GithubActionsからの課金はなく、動作環境の維持費で済むようになります。
もちろん、費用面以外でセルフホステッドランナーにする理由がない場合は、GithubActionsでの課金額とセルフホステッドランナーの動作環境の維持費を比較し、課金額の方が安ければ、セルフホステッドランナーを選択しなくても良いと思います。

GCPのGCE上にセルフホステッドランナーをデプロイしてみます！

さて、今までは深く考えずにGithubホステッドランナーを使ってましたが、セルフホステッドランナーの理解も深めるため、実際に触れていきます。
GithubActionsを実行したいリポジトリの設定画面にランナーの項目があります。

ランナーの管理画面から、セルフホステッドランナーを作成することが可能です。
今回の仮想環境は、GCPのGCEのe2-mediumでブートディスクはDebian GNU/Linux 12 (bookworm)を利用します。

CPU：2
メモリ：4GB
ストレージ：10GB

GCEのVMインスタンスへのセルフホステッドランナーの導入は非常に簡単で、SSH接続したのちに、指示通りにコマンドを実行していくだけで完了します。

今回は、RailsアプリケーションのMiniTestををRuby3.1.4、MySQL8.0の環境で実行するワークフローを利用します。

1name: Rails MiniTest
2
3# 実行トリガー設定
4on:
5  push:
6    branches: develop
7  pull_request:
8    branches: develop
9
10# 実行環境設定
11jobs:
12  test:
13    runs-on: ubuntu-latest
14    services:
15      mysql:
16        image: mysql:8.0
17        env:
18          MYSQL_ALLOW_EMPTY_PASSWORD: yes
19        ports:
20          - 3306:3306
21        # サービスのヘルスチェック
22        options: >-
23          --health-cmd="mysqladmin ping"
24          --health-interval=10s
25          --health-timeout=5s
26          --health-retries=5
27    steps:
28    # リポジトリのチェックアウト
29    - uses: actions/checkout@v4
30
31    - name: Set up Ruby
32      uses: ruby/setup-ruby@v1
33      with:
34        ruby-version: 3.1.4
35
36    - name: Install dependencies
37      run: |
38        gem install bundler
39        bundle install
40
41    - name: Setup database
42      env:
43        RAILS_ENV: test
44      # CI用のデータベース設定の適用、データベースの作成とスキーマのロード
45      run: |
46        cp config/database.ci.yml config/database.yml
47        bundle exec rake db:create db:schema:load
48
49    - name: Run tests
50      env:
51        RAILS_ENV: test
52      run: bundle exec rake test

まずは、Githubホステッドランナーで実行してみたところ、１分29秒で実行が完了しました。
続いて、runs-onをself-hostedに変更して、セルフホステッドランナーで実行した結果、Error: docker: command not foundとDockerコマンドが見つからない旨のエラーが発生しました。今回のワークフローでは、MySQLをDockerで動かす必要性があるため、Dockerが必要になりますが、自前のホステッドランナーにはDockerがインストールされていないため、エラーが発生した形になります。
Githubホステッドランナーでは、Dockerがプリインストールされているため、Dockerをインストールしなくても利用できた訳です。
今回のワークフローでは、他にもRubyやJavaScriptが必要となります。
このように、セルフホステッドランナーでは、必要なライブラリを適切にインストールする必要があるため、GithubActionsと比較し、扱いの難易度がやや上がります。
必要なライブラリをインストールし終え、セルフホステッドランナーで実行したところ、1分3秒で実行を完了しました。
また、今回、セルフホステッドランナーにRubyをインストールしているため、ワークフローの以下の項目は不要となります。

1    - name: Set up Ruby
2      uses: ruby/setup-ruby@v1
3      with:
4        ruby-version: 3.1.4

Githubホステッドランナーを利用する場合と、セルフホステッドランナーを利用する場合で、ワークフローの内容が変わっていくことにも注意が必要です。

セルフホステッドランナーを複数作成する場合は

セルフホステッドランナーが複数存在する場合は、ランナーの管理画面より、セルフホステッドランナーに識別用のラベルを追加します。
self-hosted, Linux, X64のラベルは、セルフホステッドランナーの構築時にデフォルトで作成されるラベルとなります。

ワークフローでラベルを指定することで任意のホステッドランナーを実行することが可能です。

1    runs-on: [self-hosted, hoge]

ランナーを触ってみて

Githubホステッドランナーと、セルフホステッドランナーを触ってみて、どちらを利用するのが良いかは、開発方針や要件によりますが、それぞれの利点を活かして、より良い開発環境の構築に繋げられたらと思います。それでは、皆さんも良いエンジニアライフをお過ごしください。