CircleCI の Runner に入門した

CircleCI には Self-hosted Runner と呼ばれる機能がある

circleci.com

「CircleCI のジョブを CircleCI が保持している実行環境ではなくて、自分たちが持っている環境上で実行する機能」ってことくらいしか知らなくて。「ビルドやデプロイを自分たちの閉じた環境の中でだけ扱いたい」って場合に便利なんだろうなぁ、って遠くから見てたのだった

でも、昨日突然「Runner 触ってみたいな」と思ったので触ってみることにした。仕事としてではなくて、個人的な趣味として公式ドキュメントを読みながら触ってみた。インストール方法とかは公式ドキュメントがあるのでここでは書かない。自分の理解をメモとして残しておく

Self-hosted Runner?

Self-hosted Runnerを使うと、ジョブを自分たちの持っているマシン上で実行できる。コントロールプレーン的な部分は CircleCI のままで、config.yml に「これは僕らの環境で実行して!」って設定を書けばそのジョブが自分たちの環境で実行される

そのSelf-hosted Runnerには2種類ある:マシンランナーとコンテナランナー

マシンランナー

マシンランナーは、1つの VM や物理サーバーにエージェントをインストールして、ランナーとして使うというもの

GCP に Debian の VM を立てて試してみた

これは、こういうときに便利そう

  • Docker イメージのビルドをしたいとき
  • マシン上に特別なコマンドや設定を入れておいて使いたいとき

コンテナランナー

つい数日前に GA になった。Kubernetes 上で動くランナー

「なんでコンテナランナーが必要なんだろう?」って思ってたんだけど

  • 1つのマシンランナーでは同時に1つのジョブしか実行できない
  • マシンランナーでは Docker イメージを指定しての実行はできない

それが、コンテナランナーを使うと Kubernetes 上でコンテナを使ってビルドをするので

  • 1つのコンテナランナーで複数のジョブを同時に実行できる
  • コンテナランナーでは Docker イメージを指定して実行できる

ってことで「なるほどー」ってなって、GKE を構築してやってみた

ということは?

だから、CircleCI を使ってて Docker Executor と Machine Executor を使い分けてたみたいにして、自分の環境のコンテナランナーとマシンランナーを使うことができそう

  • Docker イメージを使ってビルドしたいとき→コンテナランナー
  • 特別な環境でビルドしたいとき→マシンランナー

Dockerイメージをビルドしたいときは Docker をインストールしたマシンランナーを使えば簡単だと思うけど、コンテナランナーでも Kaniko みたいにコンテナ上でビルドできる仕組みを使えば可能

制限事項

  • Self-hosted Runner では(マシンランナー・コンテナランナー両方とも)
    • Docker Layer Caching が使えない
    • CIRCLE_PREVIOUS_BUILD_NUM と非推奨の環境変数は使えない
  • コンテナランナーでは
    • Rerun with SSH は使えない
    • setup_remote_docker は使えない

フィードバック

コンテナランナーを試すときに「あれ?」ってなる部分があったので社内でフィードバックしておこうと思う

↓こちらの記事ありがたいです。ありがとうございます

zenn.dev

ランナーに入門できた!