Runnerの動作原理

目次

• CI/CD Pipelineを動かすRunnerとは何か
• Runnerの種類
• Pipelineの並列実行設定

CI/CD Pipelineを動かすRunnerとは何か

GitLab Runner は、GitLab CI/CD と連携してパイプラインでジョブを実行するアプリケーションです。Runnerは複数の実行形態(Excutor)があります。例えば、SSH, ShellのようなRunnerを導入した環境でそのままjobを実行するものと、Kubernetes, Docker, VirtualBoxのような仮想環境を利用してjobを実行することもできます。

Runnerの種類

GitLab Runnerは以下の３種類があります。

• Shared runners：
  • SaaS版の場合はGitLabが提供する共有runnerで、self-managed版ではGitLab instanceの設定になる
• Group runners：
  • Sub-Groupごとに設定でき、その下の全てのSub-GroupとProjectが利用できる
• Specific runners：
  • Projectごとに設定でき、通常は1プロジェクトのみ利用する
  • 2つ以上のProjectが同じRunnerを使用するように設定は可能

　　参考：https://docs.gitlab.com/ee/ci/runners/runners_scope.html

Runner登録方法及びGroup/Projectとの関係

具体的なRunner登録手順は 公式サイト をご参考ください。

Runnerごとに違うマシンを登録する方法以外に、点線で囲まれたようなイメージで、同じマシンに複数runnerの登録も可能です。

pipeline/jobの並列実行

以下Group runnersとSpecific runnersを同一マシンにした場合を例として、各runnerの設定がconfig.tomlに定義されます。config.tomlの設定によって、同時に実行できるjobの上限数と、登録された3つのRunnerとして、それぞれの上限数が決まります。（参考：https://docs.gitlab.com/runner/configuration/advanced-configuration.html）

• concurrent：Runnerマシン全体同時に実行できるjobの上限数
• limit：Runner毎、同時に実行できるjobの上限数
• request_concurrency：Runner毎、GitLab からの新しいジョブに対する同時リクエストの上限数

pipleline/jobの実行順序

Group runnersとSpecific runnersは、先入れ先出し (FIFO) のjob queueを使っているので、pipilineの実行順序と設定された同時実行可能なjob数によって、pipeline/jobの並列処理の順序が決まります。

例：

　　project-Aのpiplelineに2つのジョブがあり、config.tomlのconcurrent=4, limit=2と設定されたとします。3つのfeature branchが同時にプッシュされた場合、pipelineが3つ起動されるが、2つはすぐにrunningになり、もう1つはpendingになります。

同一Project、複数ブランチのpipelineが同時に起動された場合の動き

結論から言うと、複数pipelineが同時に動いたとしても、フォルダが分離されているため、互いに影響しません。

作業フォルダ構成：~builds/runner-name/連番/top-group/sub-group/project/

①：job実行のdefault directory、Excutorの種類によって違う。config.tomlにbuilds_dir追加することによって違うpathに変更可能。

②：Runner名。

③：CONCURRENT_ID。複数pipelineが同時実行の場合、0からの連番で自動作成。例えば、同時実行中のpipelineが3つある場合、以下のようになる：

④：top-group～projectのpath。

sub-group及びその中のprojectは違うrunnerを利用する場合、どのrunnerが優先的に利用されるかについて実際に試してみた結果：

• 同じpipelineのjobが違うrunnerで動かされた
• 同じjobが毎回違うrunnerで動かされた

この結果により、runner優先利用の指定がないと考えています。