- 余っているマシンに GitHub Actions self-hosted runner を立てて Private リポジトリの GitHub Actions 無料枠を節約したい
- GitHub Actions での
docker buildにキャッシュを効かせて高速化したい
目次
やりたいこと
Runner をどこにどうやって起動するか
要件
- ホスト OS: Ubuntu, macOS, Windows
- ゲスト OS: Ubuntu
- ホスト OS の環境を汚さずに GitHub Actions self-hosted runner を使いたい
- dind (Docker in Docker) も避けたいので仮想環境で self-hosted runner を実行したい
- 仮想環境の作成と起動、および self-hosted runner のインストールと起動をコマンドで完結させたい
採用した方法
- VirtualBox and Vagrant
採用を見送ったもの
- VMware and Vagrant: VMware を購入するほどのメリットは感じなかった
- KVM and Vagrant: vagrant-libvirt
が使えそうだったが
vagrant plugin install vagrant-libvirtがどうしても成功しなかったので諦めた - Vagrant の provision における Ansible の利用も検討したが、途中で「ここまでする必要なくね？」と思ったのでやめた
デプロイ先
- リソースに余力のあるローカルマシン
- GCE (Google Compute Engine) や EC2 のインスタンス
GitHub Actions self-hosted runner
runner はここで開発されている。
プリインストールのツールなどはここで管理されている。
やってみたリポジトリ
README の指示に従えばツールや self-hosted runner をインストールした Ubuntu 20.04 の VM を起動できる。 どのようなツールがインストールされるかはリポジトリを参照されたい。
- VirtualBox 6.1
- Vagrant 2.2.16
git clone https://github.com/peaceiris/actions-self-hosted-runners.git
cd ./actions-self-hosted-runners/images/ubuntu-20.04
git checkout v0.4.0
vim .env
make up
vagrant ssh
cd actions-runner
./config.sh --url https://github.com/[owner]/[repo] --token [token]
nohup ./run.sh &
.env は以下のような内容で作成。
VB_CPUS = '4'
VB_MEMORY = '8192'
VB_DISK_SIZE = '30GB'
VB_CPUS: CPU core 数VB_MEMORY: メモリーサイズVB_DISK_SIZE: ディスクサイズ
Install VirtualBox
Ubuntu 18.04/20.04
sudo apt install -y virtualbox
macOS
brew cask install virtualbox
Install Vagrant
Ubuntu 18.04/20.04
curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add -
sudo apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main"
sudo apt update && sudo apt install -y vagrant
vagrant autocomplete install
macOS
brew install vagrant
vagrant autocomplete install
爆速 docker build
GitHub hosted runner と異なり self-hosted runner は job 毎に破棄されたりしないので、 ローカルと同様に Docker Layer Caching が効くようになる。 actions/cache のトリッキーな使い方や容量上限に悩まされることもない。 docker build の job が爆速になって目的を達成。
name: CI frontend
on:
push:
branches:
- main
pull_request:
jobs:
docker:
runs-on: self-hosted
timeout-minutes: 3
env:
COMPOSE_DOCKER_CLI_BUILD: 1
DOCKER_BUILDKIT: 1
steps:
- uses: actions/[email protected]
- run: hadolint ./Dockerfile
- run: sudo docker-compose build frontend
また、複数の self-hosted runner を登録して同じラベル名 (self-hosted とか) で利用している場合、当然 runner 間で Docker Layer Cache は共有されていないので、 job の実行タイミング次第でキャシュが効いたり効かなかったりすることには注意。 runner それぞれに固有のラベルを付けて job ではそのラベルを使用し、 必ず同じ runner が割り当てられるようにしておくと良い。
Runner のスケーリング
self-hosted runner が処理できる job は同時に1つまでなので、 複数の job で1つの self-hosted runner を利用すると順番待ちが発生する。
今回のように利用目的が個人利用であったり docker build を高速化したいだけであれば、
たいして気にならないがチームで利用する場合には同時実行できる job は多ければ多いほどよい。
そこで self-hosted runner をスケーリングしたくなってくるが、 なんだかんだ VM を管理しない方が絶対に楽なので、 一月の合計実行時間がそこまで長くないのであれば、まず GitHub hosted runner への課金を検討したい。
GitHub hosted runner への課金額が self-hosted runner の管理コストを大きく上回る場合に self-hosted runner の利用を考えればよい。
もしマシンリソースに余力があれば、1つのマシンで複数の VM を立ち上げてもよい。 これが一番簡単な解決策だが、当然 VM の数が増えればメンテナンスが煩雑になってくる。 もっと上手くスケーリングできる方法があればそれを採用したい。
self-hosted runner をスケーリング可能にするプロジェクトを探してみたところ、 以下の2つを見つけた。 チームの規模・許容できる管理コストと相談して適切なものを採用したい。
actions-runner-controller
Kubernetes でスケーリングするタイプ。
myshoes
VM をスケーリングするタイプで、個人的に期待しているプロジェクト。
meows
2021-09-11 追記: Kubernetes でスケーリングするタイプ。
まとめ
VirtualBox, Vagrant で簡単に VM 上に GitHub Actions self-hosted runner を起動して docker build を高速化できた。
