executor

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

どのexecutorを選択すればよいかわからない場合は、executorを選択するを参照してください。

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

GitLab Runnerは次のexecutorを提供します:

• SSH
• Shell
• Parallels
• VirtualBox
• Docker
• Docker Autoscaler
• Docker Machine（オートスケーリング）
• Kubernetes
• インスタンス
• カスタム

これらのexecutorはロックされており、新規のexecutorの開発や受け入れは行っていません。詳細については、新しいexecutorのコントリビュートを参照してください。

Docker以外のexecutorの前提要件

ヘルパーイメージに依存しない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認証情報マネージャーなど）がインストールされていて、認証情報をキャッシュに入れるように設定されている場合、最後に使用された認証情報がそのヘルパーのキャッシュに入れられることがあります:

• FF_GIT_URLS_WITHOUT_TOKENSがfalseなら、最後に使用されたCI_JOB_TOKENが、インストール済みのGit認証情報ヘルパーに保存されます。
• FF_GIT_URLS_WITHOUT_TOKENSがtrueなら、CI_JOB_TOKENは、インストール済みのGit認証情報ヘルパーに保存されず、そのキャッシュに入れられることもありません。

executorを選択する

executorは、プロジェクトをビルドするためのさまざまなプラットフォームと開発手法をサポートしています。次の表に、使用するexecutorを決定する際に役立つ各executorの重要な情報を示します。

補足説明:

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

Shell executor

Shell executorは、GitLab Runnerの最もシンプルな設定オプションです。GitLab Runnerがインストールされているシステムでジョブをローカルに実行し、すべての依存関係を同じマシンに手動でインストールする必要があります。

このexecutorは、Linux、macOS、およびFreeBSDオペレーティングシステムではBashをサポートし、Windows環境ではPowerShellをサポートしています。

最小限の依存関係を持つビルドにとって理想的ですが、ジョブ間の分離は限定的です。

Docker executor

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

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

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

Docker Machine Executor（非推奨）

Docker Machine Executorは、オートスケーリングに対応しているDocker executorの特別なバージョンです。標準的なDocker executorと同様に動作しますが、Docker Machineによってオンデマンドで作成されたビルドホストを使用します。この機能により、このexecutorはAWS EC2などのクラウド環境で特に効果的であり、さまざまなワークロードに対して優れた分離性とスケーラビリティを提供します。

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は、クラウドネイティブ環境に特に適しており、優れたスケーラビリティとリソース利用率を実現します。

SSH executor

SSH executorは完全性を期すために追加されましたが、サポートが最も少ないexecutorの1つです。SSH executorを使用すると、GitLab Runnerは外部サーバーに接続し、そこでビルドを実行します。このexecutorを使用している組織からの成功事例がいくつかありますが、通常は他のタイプのexecutorを使用してください。

カスタムexecutor

カスタムexecutorを使用すると、独自の実行環境を指定できます。GitLab Runnerがexecutor（Linuxコンテナなど）を提供しない場合、カスタムの実行可能ファイルを使用して環境をプロビジョニングおよびクリーンアップできます。

互換性チャート

各種executorでサポートされている機能を以下に示します:

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

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

1. デフォルトのShell。
2. 非推奨。shellが指定されていない場合のデフォルトのShell。
3. 新しいRunnerの登録時のデフォルトのShell。
4. WindowsのBash Shellはサポートされていません。

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

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]
    
    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;