GitHubセルフホストランナー導入の記録
githubセルフホストランナーの構築にあたって考えることが多く悩みました。
構築のパターンや方法を紹介している記事は多々ありましたが、Github セルフホストランナーの選定に悩んでるような記事をなかなか見かけなかったので共有します。
■概要
terraform-aws-github-runnerというTerraformを利用したossの利用とカスタマイズによってGithub セルフホストランナーを構築した。
■背景
Github actionsを導入して使い始め1ヶ月程経過した。（それまではGitLab CI またはそもそもCIなし）
GitlabからGithubに移行したプロジェクトの自動テストがかなり充実していてciの実行時間が膨大になり、コスト面や実行時間の課題が生じたためセルフホストランナーを導入して検証していた。
最初は社内に置いてあるオンプレにVMwareで構築したlinux環境をセルフホストランナーにして運用を始めた。
■オンプレVMware環境で発生した課題
接続先の、特に午前中に頻繁に通信が安定しなくなるネットワークの影響をモロに受け、実行時間が大幅に伸びてしまう。
会社のネットワークは午前中混雑していることが多く、その時間帯に実行してしまうと平気で2,3時間経っても終わらない場合があった。
また、VMware上のLinux環境の数は固定のため、複数のPRが立った場合などでactionが渋滞するとエラーを吐き始め、手動でリトライする必要があり、自動テスト感がなく、使いにくかった。
■調査・比較した内容
上記の課題を解決するためにセルフホストランナーの実装パターンを調査し、比較しました。
調べていて見かけた選択肢とそれに対するざっくりとした個人的な印象を記載します
- githubがホストするデフォルトのランナーをそのまま利用する。
- キャッシュやdocker imageの利用を深く考える必要がなく、シンプルで簡単な選択肢。
- ただ、1分あたり0.008$のコストは会社にとっては割高で、今後別チームにgithub actionsを普及していった時にさらにコストが膨れ上がる可能性がある。
- オンプレサーバーを増やしてセルフホストランナーの数を増やして対応
- AWSの移行によって利用されなくなったオンプレサーバーを利用してセルフホストランナーの数を物理的に増やして対応。
- オンプレのハードの管理が面倒で作業が増えそうなのでやりたくなく、見送り。
- terraform-aws-github-runnerをカスタマイズして利用
- EC2スポットインスタンスを、Lambdaで起動、終了、セルフホストランナー登録・解除を管理するため、他の選択肢に比べてコスト的な優位性がある。
- 会社に馴染みがあるAWSで実装できる。
- カスタマイズの余地があり、サンプル、ドキュメントが充実している。
- デメリットに感じるのは社内にTerraformを利用した例がなく、使えるエンジニアが現状いないこと。
- 実装した自分しかわからない状況になるのは避けたいため、教えたり引継ぎの手間はかかりそう。
- k8sでセルフホストランナーを立てるパターン
- Githubが推奨している方法の一つらしい。
- Terraformと同様、k8sの採用例が社内になかった。
- k8sについて個人的に学習したが、多少さわった程度で構築やアーキテクチャを考えるには奥が深すぎ、会社に提案したり、安定的に稼働させるイメージがわかなかった。
- AWS codebuildによるマネージドGithub Self hosted Runnerの構築
- マネージドでやってくれるところはかなり魅力的。
- ただし、実行時間に対する料金が割と高く、githubがホストするランナーに比べてコスト的なメリットが薄かった。
- AMIとかカスタマイズしてパフォーマンスを上げるような用途では活躍しそうなイメージ。
- この目的ならEC2を立ち上げて利用する解決策でいい気もする。
- Terraformを利用するパターンでこの用途を満たせる。
■terraform-aws-github-runnerをカスタマイズして利用するパターンを採用
チームに状況と調査内容を報告し、
コスト面のメリットが大きく、構築する工数の少なく、カスタマイズ性があって継続的にメンテナンスされそうなOSSである、terraform-aws-github-runnerを選び提案しました。
Terraformが入ることに若干懸念があるようですが、CI/CDの重要性を理解していただき、実装が楽そうなのと運用にあたってのコスパが刺さったようで採用に至りました。
■悩みポイント
セルフホストランナーの実行環境がec2なのでvpcが必要でネットワークの通信料のコストを考慮する必要がありました。
プライベートサブネットに通信を転送するためにNatgatewayを利用すると、ネットワークで処理したデータ量に対しての課金となり、料金が膨れそうなことが懸念に感じられました。
最終的に、セルフホストランナー自体がまだ社内では様子見の構築であることと、ネットワーク通信料とセキュリティの兼ね合いから妥協策としてnatインスタンスを利用して構築しました。
■構成図
ほぼほぼ公式の構成図を引用。一部カスタマイズした部分などを記載。
■最後に
社内への普及など課題が大量にありますが、書くような知見があればまた共有していこうと思います。
Discussion