執行者

GitLab Runnerは、異なる環境でビルドを実行するために使用できる多くのExecutorを実装しています。

どの Executor を選べばよいかわからない場合は、Selecting the executor を参照してください。

各 Executor でサポートされている機能の詳細については、互換性チャートを参照してください。

GitLab Runner は以下の Executor を提供します:

これらのエクゼキュータはロックされており、新しいエクゼキュータの開発や受付は終了しています。詳細については、新しいエクゼキュータを貢献するを参照してください。

Docker以外のエクゼキュータの前提条件

ヘルパーイメージに依存しないエクゼキュータでは、ターゲットマシンとPATHに Git をインストールする必要があります。 常に利用可能な最新バージョンの Gitを使用してください。

GitLab Runnerは、ターゲットマシンにGit LFSがインストールされている場合、git lfs コマンドを使用します。GitLab RunnerがこれらのExecutorを使用するシステムでは、Git LFSが最新であることを確認してください。

GitLab Runnerのコマンドを実行するユーザーのGit LFSは、必ずgit lfs install で初期化してください。git lfs install --systemでシステム全体のGit LFSを初期化することができます。

Executor の選択

エクゼキュータは、プロジェクト構築のための異なるプラットフォームと方法論をサポートしています。下の表は、どのエクゼキュータを使うかを決めるのに役立つ、各エクゼキュータの主要な事実を示しています。

エクゼキュータSSHShell仮想ボックスParallelsDockerKubernetesCustom
クリーンなビルド環境条件付き (4)
前のクローンがあればそれを再利用条件付き (4)
ランナーファイルシステムアクセス保護 (5)条件付き
マイグレーションランナーマシンパーシャルパーシャル
同時ビルドのためのゼロ設定サポート✗ (1)条件付き (4)
複雑なビルド環境✗ (2)✓ (3)✓ (3)
ビルドの問題のデバッグ簡単簡単ハードハード媒体媒体媒体
  1. 可能ですが、ほとんどの場合、ビルドがビルドマシンにインストールされたサービスを使用する場合は問題があります。
  2. 手動での依存関係のインストールが必要です。
  3. 例えばVagrantVagrantを使います。
  4. どのような環境をプロビジョニングするかに依存します。完全に分離することも、ビルドごとに共有することもできます。
  5. ランナーのファイルシステムへのアクセスが保護されていない場合、ジョブはランナーのアクセストークンや他のジョブのキャッシュやコードを含むシステム全体にアクセスできます。マークされた Executor は、デフォルトでは Runner がファイルシステムにアクセスすることを許可しません。しかし、セキュリティ上の欠陥や特定の設定により、ジョブがコンテナから抜け出し、ランナーをホストしているファイルシステムにアクセスできる可能性があります。

Shell Executor

Shellは最も設定が簡単なエクゼキューターです。ビルドに必要な依存関係はすべて、GitLab Runnerがインストールされている同じマシンに手動でインストールする必要があります。

仮想マシン Executor (VirtualBox / Parallels)

この Executor を使うと、すでに作成されている仮想マシンをクローンしてビルドの実行に使うことができます。GitLab Runnerは2つの完全なシステム仮想化オプションを提供します:VirtualBoxと Parallelsで、Windows、Linux、MacOS、FreeBSDオペレーティングシステム上でビルドを実行することができます。GitLab Runnerは仮想マシンに接続し、その上でビルドを実行します。仮想マシンエグゼキューターは、インフラストラクチャのコストを削減するためにも使用できます。

Dockerエクゼキュータ

Dockerを使えば、クリーンなビルド環境を構築できます。プロジェクトをビルドするための依存関係はすべてDockerイメージに入れることができるので、依存関係の管理がより簡単になります。Dockerエクゼキュータを使って、MySQLのような依存サービスを含むビルド環境を作ることができます。

Docker Machine Executor。

Docker Machineは自動スケーリングをサポートした特別バージョンのDockerExecutorです。典型的なDockerExecutorのように動作しますが、Dock_er Machineによって_オンデマンドでビルドホストが作成されます。

Kubernetes executor

Kubernetesexecutorを使用すると、既存のKubernetesクラスターをビルドに使用できます。ExecutorはKubernetesクラスタAPIを呼び出し、GitLab CIジョブごとに新しいポッド(ビルドコンテナとサービスコンテナを含む)を作成します。

SSH executor

SSHエクゼキュータは念のため追加していますが、最もサポートされていないエクゼキュータです。SSHエクゼキュータを使うと、GitLab Runnerは外部のサーバーに接続し、そこでビルドを実行します。このエクゼキュータを使った組織の成功例もありますが、通常は他のタイプのエクゼキュータを使うことをお勧めします。

カスタムエグゼキューター

Customexecutorを使用して、独自の実行環境を指定することができます。GitLab Runnerがエクゼキュータを提供しない場合(例えばLXCコンテナなど)、GitLab Runnerに独自のエクゼキュータを提供することで、任意の環境をプロビジョニングしてクリーンアップすることができます。

互換性チャート

各 Executor がサポートする機能:

エクゼキュータSSHShell仮想ボックスParallelsDockerKubernetesCustom
セキュリティ変数
GitLab Runner Exec コマンド
.gitlab-ci.ymlイメージ✓ (1)✓ (1)($CUSTOM_ENV_CI_JOB_IMAGE経由)
.gitlab-ci.ymlサービス
.gitlab-ci.ymlキャッシュ
.gitlab-ci.ymlアーティファクト
ステージ間のアーティファクトの受け渡し
GitLab Container Registry の非公開イメージを使用します。n/an/an/an/an/a
インタラクティブWeb端末✓(UNIX)
  1. GitLab Runner 14.2 でサポートが追加されました。詳細はベースVMイメージの上書きセクションをご参照ください。

異なるシェルでサポートされるシステム:

シェルBashPowerShellデスクトップPowerShellコアWindowsバッチ(非推奨)
Windows✗ (4)✓ (3)✓ (2)
Linux✓ (1)
macOS✓ (1)
FreeBSD✓ (1)
  1. デフォルトのシェル。
  2. 非推奨。shell が指定されていない場合のデフォルトの Shell。
  3. 新しい Runner が登録されたときのデフォルトの Shell。
  4. WindowsのBashシェルはサポートされていません。

シェルの違いによる対話型ウェブ端末の対応システム:

シェルBashPowerShellデスクトップPowerShellコアWindowsバッチ(非推奨)
Windows
Linux
macOS
FreeBSD