executor

プラン: Free、Premium、Ultimate
提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

GitLab Runnerは、さまざまな環境でビルドを実行するために使用できる異なるexecutorを実装しています:

アクティブな機能開発の下にない他のexecutorが利用可能です。これらは重要なセキュリティアップデートは受け取りますが、新機能は受け取りません。

一部の機能では、fleetingを使用するRunnerが必要です。Docker Autoscalerとインスタンスのexecutorは、fleetingを使用します。GitLab Runnerの全機能を活用するには、これらのexecutorのいずれかに移行する必要があります。

どのexecutorを選択すべきか不明な場合は、selecting the executorを参照してください。

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

これらのexecutorはロックされており、新規のexecutorの開発や受け入れは行っていません。詳細については、contributing new executorsを参照してください。

executorを選択する

executorは、プロジェクトをビルドするためのさまざまなプラットフォームと開発手法をサポートしています。次の図は、オペレーティングシステムとプラットフォームに基づいてどのexecutorを選択すべきかを示しています。

flowchart LR
    Start([Executor<br/>Selection]) --> Auto{Autoscaling?}

    Auto -->|YES| Platform{Platform?}
    Auto -->|NO| BuildType{Build<br/>Type?}

    Platform -->|Cloud<br/>Native| K8s[Kubernetes]
    Platform -->|Cloud<br/>VMs| OS1{OS?}

    OS1 -->|Linux| L1[Fleeting:<br/>Docker Autoscaler<br/>or Instance]
    OS1 -->|macOS| M1[Fleeting:<br/>Docker Autoscaler<br/>or Instance]
    OS1 -->|Windows| W1[Fleeting:<br/>Docker Autoscaler<br/>or Instance]

    BuildType -->|Container| OS2{OS?}
    BuildType -->|Shell| OS3{OS?}

    OS2 -->|Linux| L2[Docker<br/>Podman]
    OS2 -->|macOS| M2[Docker]
    OS2 -->|Windows| W2[Docker]

    OS3 -->|Linux| L3[Bash<br/>Zsh]
    OS3 -->|macOS| M3[Bash<br/>Zsh]
    OS3 -->|Windows| W3[PowerShell 5.1<br/>PowerShell 7.x]
    OS3 -->|Remote| R3[SSH<br/>#40;maintenance mode#41;]

    classDef question fill:#e1f3fe,stroke:#333,stroke-width:2px,color:#000
    classDef result fill:#dcffe4,stroke:#333,stroke-width:2px,color:#000
    classDef start fill:#f9f9f9,stroke:#fff,stroke-width:2px,color:#000

    class Start start;
    class Auto,Platform,BuildType,OS1,OS2,OS3 question;
    class K8s,L1,M1,W1,L2,M2,W2,L3,M3,W3,R3 result;

SSH executorはメンテナンスモードです。重要なセキュリティアップデートは受け取りますが、新しい機能は計画されていません。また、サポートが最も少ないexecutorの1つです。ローカルのShellベースのビルドには、代わりにShell executorの使用を検討してください。

下の表は、各executorのキーとなる事実を示しており、どのexecutorを使用するかを決定するのに役立ちます:

SSH、Shell、VirtualBox、Parallels、およびCustom executorはメンテナンスモードです。重要なセキュリティアップデートは受け取りますが、新しい機能は計画されていません。

executor	Docker	Docker Autoscaler	インスタンス	Kubernetes	SSH	Shell	VirtualBox	Parallels	カスタム
すべてのビルドのためのクリーンなビルド環境	✓	✓	条件付き¹	✓	✗	✗	✓	✓	条件付き¹
存在する場合は、以前のクローンを再利用する	✓	✓	条件付き¹	✓ ²	✓	✓	✗	✗	条件付き¹
Runnerファイルシステムアクセス保護済み³	✓	✓	✗	✓	✓	✗	✓	✓	条件付き
Runnerマシンを移行する	✓	✓	✓	✓	✗	✗	部分的	部分的	✓
同時ビルドのゼロ設定サポート	✓	✓	✓	✓	✗	✗ ⁴	✓	✓	条件付き¹
複雑なビルド環境	✓	✓	✗ ⁵	✓	✗	✗ ⁵	✓ ⁶	✓ ⁶	✓
ビルドの問題のデバッグ	普通	普通	普通	普通	簡単	簡単	難しい	難しい	普通

補足説明:

プロビジョニングする環境によって異なります。完全に分離することも、ビルド間で共有することもできます。
並行処理ごとの永続ビルドボリューム設定が必要です。
Runnerのファイルシステムアクセスが保護されていない場合、ジョブはRunnerのトークンや他のジョブのキャッシュとコードなど、システム全体にアクセスできます。✓が付いているexecutorは、デフォルトではRunnerがファイルシステムにアクセスすることを許可していません。ただし、セキュリティ上の欠陥または特定の設定により、ジョブがコンテナからブレイクアウトし、Runnerをホスティングしているファイルシステムにアクセスする可能性があります。
ビルドマシンにインストールされているサービスをビルドで使用する場合、executorを選択できますが、問題があります。
依存関係を手動でインストールする必要があります。
たとえば、Vagrantを使用します。

Docker executor

Docker executorは、コンテナを介してクリーンなビルド環境を提供します。すべての依存関係がDockerイメージにパッケージ化されているため、依存関係を容易に管理できます。このexecutorを使用するには、RunnerホストにDockerがインストールされている必要があります。

このexecutorは、MySQLなどの追加のサービスをサポートしています。また、Podmanを代替コンテナランタイムとして受け入れます。

このexecutorは、一貫性のある分離されたビルド環境を保持します。

Docker Autoscaler executor

Docker Autoscaler executorは、Runnerマネージャーが処理するジョブに対処するために、オンデマンドでインスタンスを作成するオートスケール対応のDocker executorです。Docker executorをラップしているため、すべてのDocker executorのオプションと機能がサポートされています。

Docker Autoscalerは、フリートプラグインを使用してオートスケールします。フリートとは、オートスケールされたインスタンスのグループの抽象化であり、Google Cloud、AWS、Azureなどのクラウドプロバイダーをサポートするプラグインを使用します。このexecutorは、動的なワークロードの要件がある環境に特に適しています。

インスタンスexecutor

インスタンスexecutorは、Runnerマネージャーが処理するジョブの予期されるボリュームに対処するために、オンデマンドでインスタンスを作成するオートスケール対応のexecutorです。

このexecutorと、関連するDocker Autoscale executorは、GitLab RunnerフリートおよびTaskscalerテクノロジーと連携する新しいオートスケールexecutorです。

インスタンスexecutorもフリートプラグインを使用してオートスケールします。

ジョブがホストインスタンス、オペレーティングシステム、および接続デバイスへのフルアクセスを必要とする場合は、インスタンスexecutorを使用できます。インスタンスexecutorは、シングルテナントジョブとマルチテナントジョブに対応するように設定することもできます。

Kubernetes executor

ビルドに既存のKubernetesクラスターを使用する場合にKubernetes executorを使用できます。このexecutorはKubernetesクラスターAPIを呼び出して、各GitLab CI/CDジョブの新しいポッド（ビルドコンテナとサービスコンテナを含む）を作成します。このexecutorは、クラウドネイティブ環境に特に適しており、優れたスケーラビリティとリソース利用率を実現します。

メンテナンスモードのexecutor

これらのexecutorは重要なセキュリティアップデートを受け取りますが、新しい機能は計画されていません:

互換性チャート

異なるexecutorでサポートされる機能。

executor	Docker	Docker Autoscaler	インスタンス	Kubernetes	SSH	Shell	VirtualBox	Parallels	カスタム
セキュアな変数	✓	✓	✓	✓	✓	✓	✓	✓	✓
`.gitlab-ci.yml`: イメージ	✓	✓	✗	✓	✗	✗	✓ ⁽¹⁾	✓ ⁽¹⁾	✓（`$CUSTOM_ENV_CI_JOB_IMAGE`を使用）
`.gitlab-ci.yml`: サービス	✓	✓	✗	✓	✗	✗	✗	✗	✓
`.gitlab-ci.yml`: キャッシュ	✓	✓	✓	✓	✓	✓	✓	✓	✓
`.gitlab-ci.yml`: アーティファクト	✓	✓	✓	✓	✓	✓	✓	✓	✓
ステージ間のアーティファクトの受け渡し	✓	✓	✓	✓	✓	✓	✓	✓	✓
GitLabコンテナレジストリのプライベートイメージを使用する	✓	✓	該当なし	✓	該当なし	該当なし	該当なし	該当なし	該当なし
インタラクティブWeb端末	✓	✗	✗	✓	✗	✓	✗	✗	✗

補足説明:

GitLab Runner 14.2でサポートが追加されました。詳細については、ベースVMイメージの上書きセクションを参照してください。

各種Shellでサポートされているシステムを以下に示します:

Shell	Bash	PowerShell Desktop	PowerShell Core	sh
Linux	✓ ¹	✗	✓	✓
macOS	✓ ¹	✗	✓	✓
FreeBSD	✓ ¹	✗	✗	✓
Windows	✗ ³	✓ ⁴	✓ ^2,5	✗

補足説明:

デフォルトShell
Runner登録用およびshell executorを使用するジョブのデフォルトShellです。
Bash ShellはWindowsではサポートされていません。
docker-windowsおよびkubernetes executorを使用するジョブのデフォルトShellです。
shell executorを使用するジョブのデフォルトShellです。

各種ShellによりサポートされているインタラクティブWeb端末のシステムを以下に示します:

Shell	Bash	PowerShell Desktop	PowerShell Core	sh
Windows	✗	✓	✓	✗
Linux	✓	✗	✓	✓
macOS	✓	✗	✓	✓
FreeBSD	✓	✗	✗	✓

非Docker executorのGit要件

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

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

git lfs installを使用して、GitLab Runnerコマンドを実行するユーザーに対してGit LFSを初期化してください。システム全体でGit LFSを初期化するには、git lfs install --systemを使用します。

GitLabインスタンスとのGitインタラクションを認証するため、GitLab RunnerではCI_JOB_TOKENを使用します。FF_GIT_URLS_WITHOUT_TOKENSの設定によっては、事前にインストールされたGit認証情報ヘルパー（たとえば、Git credential managerなど）に、最後に使用された認証情報がキャッシュされている場合があります。これは、そのようなヘルパーがインストールされ、認証情報をキャッシュするように設定されている場合に限ります:

FF_GIT_URLS_WITHOUT_TOKENSがfalseの場合、最後に使用されたCI_JOB_TOKENは、事前にインストールされたGit認証情報ヘルパーに保存されます。
FF_GIT_URLS_WITHOUT_TOKENSがtrueの場合、CI_JOB_TOKENは、事前にインストールされたGit認証情報ヘルパーに保存またはキャッシュされることはありません。