執行utor
GitLab Runnerは、様々なシナリオでビルドを実行するために使用できる多くのエクゼキュータを実装しています。 何を選択すればよいかわからない場合は、「よくわからない」のセクションをお読みください。互換性チャートで、各エクゼキュータがサポートしている機能とサポートしていない機能をご確認ください。
各executorの具体的なドキュメントをご覧になるには、こちらをご覧ください：
上記の executor のリストはロックされています。 もう開発者はいませんし、新しいものも受け付けていません。CONTRIBUTION.mdで詳細を確認してください。
執行者の選定
下の表は、どのexecutorを使うかを決めるのに役立つ、各executorの主要な事実を示しています。
| 執行者 | SSH | Shell | バーチャルボックス | Parallels | Docker | Kubernetes | Custom |
|---|---|---|---|---|---|---|---|
| クリーンなビルド環境 | ✗ | ✗ | ✓ | ✓ | ✓ | ✓ | 条件付き (4) |
| 前のクローンがあればそれを再利用 | ✓ | ✓ | ✗ | ✗ | ✓ | ✗ | 条件付き (4) |
| ランナーファイルシステムアクセス保護 (5) | ✓ | ✗ | ✓ | ✓ | ✓ | ✓ | ただし付き |
| ランナーマシンの移行 | ✗ | ✗ | パーシャル | パーシャル | ✓ | ✓ | ✓ |
| 同時ビルドのためのゼロコンフィギュレーションサポート | ✗ | ✗ (1) | ✓ | ✓ | ✓ | ✓ | 条件付き (4) |
| 複雑なビルド環境 | ✗ | ✗ (2) | ✓ (3) | ✓ (3) | ✓ | ✓ | ✓ |
| ビルドの問題のデバッグ | 造作もない | 造作もない | 難しい | 難しい | ミディアム | ミディアム | ミディアム |
- 可能ですが、ほとんどの場合、ビルドがビルドマシンにインストールされたサービスを使用する場合に問題があります。
- すべての依存関係を手作業でインストールする必要があります。
- 例えば、VagrantVagrantの
- どのような環境をプロビジョニングするかによって、完全に分離することも、各ビルド間で共有することもできます。
- Runner のファイルシステムへのアクセスが保護されていない場合、ジョブは Runner のトークン、他のジョブのキャッシュやコードを含むシステム全体にアクセスすることができます。 Executor はデフォルトでは Runner がファイルシステムにアクセスすることを許可しません。 しかし、セキュリティの欠陥や特定の設定により、ジョブはコンテナから抜け出して Runner をホストするファイルシステムにアクセスすることができます。
よくわかりません
シェル executor
Shellは設定するのが最も簡単なexecutorです。 ビルドに必要な依存関係はすべて、Runnerがインストールされているのと同じマシンに手動でインストールする必要があります。
仮想マシン executor (VirtualBox / Parallels)
このタイプのエクゼキューターは、既に作成された仮想マシンを使用することができ、その仮想マシンをクローンしてビルドを実行するために使用します。 私たちは、VirtualBoxと Parallelsの2つの完全なシステム仮想化オプションを提供しています。 GitLab Runnerは、Windows、Linux、MacOS、またはFreeBSD上で仮想マシンを作成し、GitLab Runnerが仮想マシンに接続してビルドを実行することができるので、異なるオペレーティングシステム上でビルドを実行したい場合に便利です。 その使用は、インフラストラクチャのコストを削減するためにも役立ちます。
docker executor
Dockerを使用すると、依存関係を簡単に管理しながらクリーンなビルド環境を構築することができます（プロジェクトをビルドするための依存関係はすべてDockerイメージに入れることができます）。 Docker executorを使用すると、MySQLのような依存するサービスを含むビルド環境を簡単に作成することができます。
docker Machine executor
DockerMachineは自動スケーリングをサポートしたDockerexecutorの特別バージョンです。 通常のDockerexecutorのように動作しますが、_Docker Machineによって_オンデマンドでビルドホストが作成されます。
Kubernetes executor
Kubernetesexecutorを使うと、既存のKubernetesクラスターをビルドに使うことができます。 executorはKubernetesクラスターAPIを呼び出し、GitLab CIジョブごとに新しいポッド（ビルドコンテナとサービスコンテナを含む）を作成します。
SSH executor
SSHエグゼキューターは念のため追加しましたが、すべてのエグゼキューターの中で最もサポートされていません。 GitLab Runnerを外部サーバーに接続させ、そこでビルドを実行します。 このエグゼキューターを使った組織からの成功例もありますが、通常は他のタイプのどれかを使うことをお勧めします。
カスタムexecutor
Customexecutorでは、独自の実行環境を指定することができます。 GitLab Runnerがexecutorを提供しない場合（例えばLXCコンテナなど）、独自のexecutorをGitLab Runnerに提供することで、任意の環境をプロビジョニング、クリーンアップすることができます。
相性チャート
各 executor がサポートする機能：
| 執行者 | SSH | Shell | バーチャルボックス | Parallels | Docker | Kubernetes | Custom |
|---|---|---|---|---|---|---|---|
| セキュリティ変数 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| GitLab Runner Exec コマンド | ✗ | ✓ | ✗ | ✗ | ✓ | ✓ | ✓ |
gitlab-ci.ymlイメージ
| ✗ | ✗ | ✗ | ✗ | ✓ | ✓ | を経由して$CUSTOM_ENV_CI_JOB_IMAGE
|
gitlab-ci.ymlサービス
| ✗ | ✗ | ✗ | ✗ | ✓ | ✓ | ✗ |
gitlab-ci.ymlキャッシュ
| ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
gitlab-ci.ymlアーティファクト
| ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| ステージ間のアーティファクトの受け渡し | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| GitLab Container Registryの非公開イメージを使用します。 | 該当なし | 該当なし | 該当なし | 該当なし | ✓ | ✓ | 該当なし |
| インタラクティブWeb端末 | ✗ | ✓(UNIX) | ✗ | ✗ | ✓ | ✓ (1) | ✗ |
- インタラクティブ・ウェブ・ターミナルは
gitlab-runnerHelm chartではまだサポートされていませんが、サポートされる予定です。
シェルによってサポートされるシステムが異なります：
| シェル | Bash | PowerShellデスクトップ | PowerShellコア | Windowsバッチ（非推奨） |
|---|---|---|---|---|
| Windows | ✗ (4) | ✓ (3) | ✓ | ✓ (2) |
| Linux | ✓ (1) | ✗ | ✓ | ✗ |
| macOS | ✓ (1) | ✗ | ✓ | ✗ |
| FreeBSD | ✓ (1) | ✗ | ✗ | ✗ |
- デフォルトのシェル。
- 非推奨。
shellを指定しなかった場合のデフォルトシェル。 - 新しいGitLab Runnerが登録されたときのデフォルトシェル。
- Bashシェルは現在、この問題のためWindowsではすぐに動作しませんが、近いうちに再びサポートされる予定です。 回避策については、この問題を参照してください。
様々なシェルによる対話型ウェブ端末のサポートシステム：
| シェル | Bash | PowerShellデスクトップ | PowerShellコア | Windowsバッチ（非推奨） |
|---|---|---|---|---|
| Windows | ✗ | ✗ | ✗ | ✗ |
| Linux | ✓ | ✗ | ✗ | ✗ |
| macOS | ✓ | ✗ | ✗ | ✗ |
| FreeBSD | ✓ | ✗ | ✗ | ✗ |
