日々開発やら運用やらをしていると、だいたい「何かイベントが起きた時に何かを実行する」というのを繰り返していることが多いなと感じる。以前からそれを自動化するための汎用的な実装を探していて、Kubernetes 上でうまく実現するための仕組みなんかも試作してみたりしたのだけど、今は GitHub Actions がすごく気に入っている。

先日 GitHub Actions の API が公開されて、Self-hosted runner を登録するための仕組みも自動化することが可能になった。API が公開される前はリポジトリごとにトークンを発行し、それを指定して Runner を起動する必要があったので大きな改善だ。これで GitHub からは直接アクセスできないようなネットワーク内でも Runner と API を組み合わせてより手軽に GitHub Actions が実行できるようになるわけだ。

個人的にはリポジトリ名を指定したら、あとはいい感じに Runner を起動して GitHub Actions を実行できるようにしたかったので、Kubernetes でそのあたりの作業をうまくやってくれる actions-runner-controller というのを開発している。このコントローラーを Kubernetes 上にインストールして、以下のような Runner というリソースに Runner を実行したいリポジトリ名を書いて保存するだけで、あとは Kubernetes がいいように Runner を運用してくれる。

# runner.yaml
apiVersion: actions.summerwind.dev/v1alpha1
kind: Runner
metadata:
  name: example-runner
spec:
  repository: summerwind/actions-runner-controller

$ kubectl apply -f runner.yaml

この例では GitHub の summerwind/actions-runner-controller リポジトリに example-runner という名前の Runner を登録することを示している。コントローラーはこのリソースの作成をトリガーに、GitHub の API でRunner が使用するトークンを発行し、そのトークンを渡して Runner コンテナの Pod を実行している。

開発の途中で GitHub Actions の Workflow が1回実行されるたびに Pod を再作成するうまい方法はないかと悩んでいたら、同じようなことを考えていた @mumoshu さんが -once というオプションがあることを教えてくれた。これを試してみたところ1回実行するたびにプロセスが終了するようになり、まさにやりたかったことが実現できたのだった。どうもありがとうございました。

細かい機能追加とかテストの実装とかはまだ残っているものの、おおよそうまく動くようになってきたので仕事などでも使ってみようと思う。しかし Kubernetes の「コントローラー」や「カスタムリソース」という仕組みは、こういったプロセスを自動化するためのフレームワークとしてよくできているよなぁと、改めて思うのだった。