GitLab Runnerのエグゼキュータ
(トップページはこちら) - (GitLab Runnerを始める)
GitLab Runnerは、CI/CDパイプラインを実行するための強力なツールです。その中核となるのが「エグゼキューター」という概念です。エグゼキューターは、ビルドジョブをどのような環境で実行するかを決定する重要な要素であり、プロジェクトの特性やインフラ環境に応じて適切に選択する必要があります。
本記事では、GitLab Runnerが提供する10種類のエグゼキューターについて、それぞれの特徴、適用シーン、そして選択基準を詳しく解説します。
1. エグゼキューターとは
エグゼキューターは、GitLab Runnerがビルドジョブを実行する際の「実行環境の種類」を定義するものです。シンプルなローカル実行から、クラウドネイティブなKubernetes環境まで、多様な選択肢が用意されています。
現在、GitLab Runnerは以下の10種類のエグゼキューターを提供しています。
- SSH - 外部サーバーでの実行
- Shell - ローカルシェルでの実行
- Parallels - Parallels仮想マシンでの実行
- VirtualBox - VirtualBox仮想マシンでの実行
- Docker - Dockerコンテナでの実行
- Docker Autoscaler - 自動スケーリング対応Dockerコンテナ
- Docker Machine - 自動スケーリング対応Dockerコンテナ(非推奨)
- Kubernetes - Kubernetesクラスターでの実行
- Instance - クラウドインスタンスでの実行
- Custom - カスタム実行環境
なお、これらのエグゼキューターは現在ロックされており、新しいエグゼキューターの開発や受け入れは行われていません。
2. エグゼキューター選択フローチャート
まず、適切なエグゼキューターを選択するための判断フローを示します。このフローチャートに従うことで、プロジェクトの要件に最適なエグゼキューターを効率的に選択できます。
3. エグゼキューター選択の基準
エグゼキューターを選択する際には、以下の要素を考慮する必要があります。
3.1. 主要な比較ポイント
| 機能 | SSH | Shell | VirtualBox | Parallels | Docker | Docker Autoscaler | Instance | Kubernetes | Custom |
|---|---|---|---|---|---|---|---|---|---|
| ビルドごとにクリーンな環境 | ✗ | ✗ | ✓ | ✓ | ✓ | ✓ | 条件付き4 | ✓ | 条件付き4 |
| 前回のクローンを再利用 | ✓ | ✓ | ✗ | ✗ | ✓ | ✓ | 条件付き4 | ✓6 | 条件付き4 |
| Runnerファイルシステムアクセス保護5 | ✓ | ✗ | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ | 条件付き |
| Runnerマシンの移行 | ✗ | ✗ | 部分的 | 部分的 | ✓ | ✓ | ✓ | ✓ | ✓ |
| 並行ビルドのゼロ構成サポート | ✗ | ✗1 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | 条件付き4 |
| 複雑なビルド環境 | ✗ | ✗2 | ✓3 | ✓3 | ✓ | ✓ | ✗2 | ✓ | ✓ |
| ビルド問題のデバッグ | 簡単 | 簡単 | 困難 | 困難 | 中程度 | 中程度 | 中程度 | 中程度 | 中程度 |
3.2. 脚注の詳細説明
1 並行ビルドについて
ビルドマシンにインストールされたサービスを使用する場合、エグゼキューターの選択は可能ですが問題が発生する可能性があります。例えば、複数のジョブが同じポートを使用しようとする場合などです。
2 依存関係のインストール
手動で依存関係をインストールする必要があります。これは、ビルド環境のセットアップに時間がかかり、環境の一貫性を保つのが難しくなる可能性があることを意味します。
3 仮想化ツールの活用
Vagrantなどのツールを使用することで、複雑なビルド環境を構築できます。これにより、再現可能な環境を作成し、異なる構成をテストすることが可能になります。
4 条件付きサポート
プロビジョニングする環境に依存します。完全に分離された環境にすることも、ビルド間で共有することも可能です。設定次第で動作が変わるため、要件に応じた適切な構成が必要です。
5 ファイルシステムアクセス保護
Runnerのファイルシステムアクセスが保護されていない場合、ジョブはRunnerのトークンや他のジョブのキャッシュ、コードを含むシステム全体にアクセスできてしまいます。✓マークのエグゼキューターは、デフォルトでRunnerがファイルシステムにアクセスできないようになっています。ただし、セキュリティの欠陥や特定の構成により、ジョブがコンテナから抜け出してRunnerをホストしているファイルシステムにアクセスする可能性があります。
6 Kubernetesでのクローン再利用
永続的な並行ビルドボリューム(persistent per-concurrency build volumes)の構成が必要です。この設定により、ビルド間でGitリポジトリのクローンを再利用でき、ビルド時間を短縮できます。
3.3. 選択のポイント
シンプルさ重視
Shell エグゼキューターは、セットアップが最も簡単で、デバッグも容易です。小規模なプロジェクトや、依存関係が少ないビルドに適しています。
環境の一貫性重視
Docker エグゼキューターは、毎回クリーンな環境を提供し、依存関係をDockerイメージとして管理できます。チーム全体で同じ環境を共有でき、「私の環境では動く」問題を解決します。
自動スケーリング重視
Docker Autoscaler、Instance、Kubernetes エグゼキューターは、負荷に応じて自動的にリソースをスケールします。ピーク時のビルド待ち時間を削減し、コストを最適化できます。
クラウドネイティブ
Kubernetes エグゼキューターは、既存のKubernetesインフラを活用でき、リソース利用率が高く、スケーラビリティに優れています。
特殊要件
Custom エグゼキューターは、標準的なエグゼキューターでは対応できない特殊な環境や要件に対応できます。
4. 主要エグゼキューターの詳細
4.1. Shell エグゼキューター:シンプルさを追求
Shell エグゼキューターは、最もシンプルな構成オプションです。GitLab Runnerがインストールされているシステム上でジョブをローカルに実行します。
特徴
- Linux、macOS、FreeBSDではBashをサポート
- Windows環境ではPowerShellをサポート
- すべての依存関係を手動でインストールする必要がある
- ジョブ間の分離は限定的
適用シーン
- 依存関係が少ないビルド
- 開発環境でのクイックテスト
- レガシーシステムとの統合
メリット
- セットアップが簡単
- デバッグが容易
- オーバーヘッドが最小
デメリット
- ビルド環境の汚染リスク
- セキュリティ上の懸念(ファイルシステムアクセス保護なし)
- 並行ビルドの管理が複雑
4.2. Docker エグゼキューター:クリーンで一貫性のある環境
Docker エグゼキューターは、コンテナを通じてクリーンなビルド環境を提供します。
特徴
- 依存関係管理が簡単(Dockerイメージにパッケージ化)
- Runner ホストにDockerのインストールが必要
- MySQLなどの追加サービスをサポート
- Podmanを代替コンテナランタイムとして使用可能
- 一貫性のある分離されたビルド環境を維持
適用シーン
- コンテナベースのアプリケーション開発
- 複数のサービスを使用する統合テスト
- 環境の再現性が重要なプロジェクト
メリット
- 毎回クリーンな環境
- 依存関係の管理が容易
- 環境の再現性が高い
- 並行ビルドのサポート
デメリット
- Dockerのセットアップが必要
- イメージのビルドとプルに時間がかかる場合がある
- ホストリソースの消費
4.3. VirtualBox エグゼキューター:仮想マシンでの分離
VirtualBox エグゼキューターは、VirtualBox仮想マシンを使用してビルドを実行します。
特徴
- 完全に分離されたビルド環境
- 毎回クリーンな環境を提供
- Vagrantなどのツールと組み合わせて複雑な環境を構築可能
- GitLab Runner 14.2以降、ベースVMイメージのオーバーライドをサポート
適用シーン
- 特定のOS環境が必要なビルド
- 完全な分離が必要なセキュリティ要件の高いプロジェクト
- デスクトップアプリケーションのビルド
メリット
- 完全な環境分離
- 複雑なビルド環境のサポート
- ホストOSに依存しない
デメリット
- 起動時間が長い
- リソース消費が大きい
- デバッグが困難
- Runnerマシンの移行が部分的にしかサポートされない
4.4. Parallels エグゼキューター:macOS環境での仮想化
Parallels エグゼキューターは、Parallels仮想マシンを使用してビルドを実行します。主にmacOS環境で使用されます。
特徴
- VirtualBoxと同様の特性
- macOS環境での仮想化に最適化
- 完全に分離されたビルド環境
- GitLab Runner 14.2以降、ベースVMイメージのオーバーライドをサポート
適用シーン
- macOS環境でのビルド
- iOSアプリケーションの開発
- macOS特有の機能を使用するプロジェクト
メリット・デメリット
VirtualBox エグゼキューターと同様ですが、macOS環境でのパフォーマンスが最適化されています。
4.5. Docker Machine エグゼキューター:自動スケーリング(非推奨)
重要な注意事項
この機能はGitLab 17.5で非推奨となり、バージョン20.0での削除が予定されています。代わりに「GitLab Runner Autoscaler」(Docker AutoscalerまたはInstance エグゼキューター)の使用が推奨されています。
特徴
- 自動スケーリングをサポートする特別なバージョンのDocker エグゼキューター
- Docker Machineによってオンデマンドでビルドホストを作成
- AWS EC2などのクラウド環境で特に効果的
- 可変ワークロードに対して優れた分離性とスケーラビリティを提供
移行パス
既存のDocker Machine エグゼキューターを使用している場合は、Docker Autoscaler エグゼキューターまたはInstance エグゼキューターへの移行を計画してください。
4.6. Docker Autoscaler エグゼキューター:次世代の自動スケーリング
Docker Autoscaler エグゼキューターは、自動スケーリングが有効化されたDocker エグゼキューターです。Runnerマネージャーが処理するジョブに対応するため、オンデマンドでインスタンスを作成します。
特徴
- Docker エグゼキューターをラップしているため、すべてのDocker エグゼキューターのオプションと機能をサポート
- Fleeting プラグインを使用して自動スケーリング
- Google Cloud、AWS、Azureなどのクラウドプロバイダーをサポート
Fleeting プラグインとは
Fleetingは、自動スケーリングされたインスタンスのグループを抽象化したもので、クラウドプロバイダーをサポートするプラグインを使用します。これにより、異なるクラウド環境でも統一されたインターフェースで自動スケーリングを実現できます。
適用シーン
- 動的なワークロード要件がある環境
- クラウドネイティブなCI/CD環境
- コスト最適化が重要なプロジェクト
メリット
- 負荷に応じた自動スケーリング
- コストの最適化(使用した分だけ課金)
- Docker エグゼキューターの全機能を利用可能
デメリット
- 初期セットアップが複雑
- クラウドプロバイダーの知識が必要
- インスタンス起動時間によるオーバーヘッド
4.7. Instance エグゼキューター:フルアクセスが必要な場合
Instance エグゼキューターは、Runnerマネージャーが処理するジョブの予想ボリュームに対応するため、オンデマンドでインスタンスを作成する自動スケーリング対応エグゼキューターです。
特徴
- GitLab Runner FleetingおよびTaskscaler技術と連携
- Fleeting プラグインを使用して自動スケーリング
- ホストインスタンス、オペレーティングシステム、接続されたデバイスへのフルアクセスが必要なジョブに使用可能
- シングルテナントおよびマルチテナントジョブに対応可能
Taskscaler技術とは
Taskscalerは、ジョブの予想ボリュームに基づいてインスタンスを事前にプロビジョニングする技術です。これにより、ジョブの待ち時間を最小化できます。
適用シーン
- ホストインスタンスへのフルアクセスが必要なジョブ
- ハードウェアデバイスとの統合が必要な場合
- コンテナでは実行できないワークロード
メリット
- 完全なシステムアクセス
- 柔軟な構成(シングル/マルチテナント)
- 自動スケーリング
デメリット
- セキュリティリスク(ファイルシステムアクセス保護なし)
- リソース消費が大きい
- セットアップが複雑
4.8. Kubernetes エグゼキューター:クラウドネイティブの選択
Kubernetes エグゼキューターは、既存のKubernetesクラスターをビルドに使用できます。
特徴
- Kubernetes クラスターAPIを呼び出し、各GitLab CI/CDジョブに対して新しいPodを作成
- ビルドコンテナとサービスコンテナを含むPodを作成
- 優れたスケーラビリティとリソース利用率
適用シーン
- Kubernetesを既に運用している組織
- クラウドネイティブアプリケーション開発
- マイクロサービスアーキテクチャ
メリット
- 既存のKubernetesインフラを活用
- 優れたリソース利用率
- 自動スケーリングとロードバランシング
- 高い可用性
デメリット
- Kubernetesの知識が必要
- 初期セットアップが複雑
- デバッグが中程度の難易度
4.9. SSH エグゼキューター:レガシーシステム向け
SSH エグゼキューターは、完全性のために追加されていますが、最もサポートが少ないエグゼキューターの1つです。
特徴
- GitLab Runnerが外部サーバーに接続してビルドを実行
- 一部の組織で成功事例はあるものの、通常は他のタイプを使用すべき
適用シーン
- レガシーシステムとの統合
- 特定のリモートサーバーでのビルドが必要な場合
メリット
- 既存のサーバーインフラを活用
- デバッグが簡単
デメリット
- サポートが限定的
- 並行ビルドのゼロ構成サポートなし
- Runnerマシンの移行不可
4.10. Custom エグゼキューター:独自の実行環境
Custom エグゼキューターは、独自の実行環境を指定できます。
特徴
- GitLab Runnerが提供しないエグゼキューター(例:Linuxコンテナ以外)を使用可能
- カスタム実行可能ファイルを使用して環境のプロビジョニングとクリーンアップが可能
適用シーン
- 特殊な要件がある場合
- 標準的なエグゼキューターでは対応できない環境
- 独自のオーケストレーションシステムとの統合
メリット
- 完全な柔軟性
- 独自の要件に対応可能
- 既存のツールチェーンとの統合
デメリット
- 実装とメンテナンスのコストが高い
- サポートが限定的
- 複雑なセットアップ
5. 機能互換性チャート
各エグゼキューターがサポートする機能は以下の通りです。
| 機能 | SSH | Shell | VirtualBox | Parallels | Docker | Docker Autoscaler | Instance | Kubernetes | Custom |
|---|---|---|---|---|---|---|---|---|---|
| セキュア変数 | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
.gitlab-ci.yml: image |
✗ | ✗ | ✓※1 | ✓※1 | ✓ | ✓ | ✗ | ✓ | ✓※2 |
.gitlab-ci.yml: services |
✗ | ✗ | ✗ | ✗ | ✓ | ✓ | ✗ | ✓ | ✓ |
.gitlab-ci.yml: cache |
✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
.gitlab-ci.yml: artifacts |
✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| ステージ間でのアーティファクト受け渡し | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| GitLab Container Registryプライベートイメージ使用 | N/A | N/A | N/A | N/A | ✓ | ✓ | N/A | ✓ | N/A |
| インタラクティブWebターミナル | ✗ | ✓ (UNIX) | ✗ | ✗ | ✓ | ✗ | ✗ | ✓ | ✗ |
※1 VirtualBoxとParallelsでのimageサポートは、GitLab Runner 14.2で追加されました。ベースVMイメージのオーバーライド機能を使用します。
※2 Custom エグゼキューターでは、$CUSTOM_ENV_CI_JOB_IMAGE環境変数を使用することでimageをサポートできます。
6. シェルのサポート状況
6.1. 各オペレーティングシステムでサポートされているシェル
| OS | Bash | PowerShell Desktop | PowerShell Core | Windows Batch (非推奨) |
|---|---|---|---|---|
| Windows | ✗※4 | ✓※3 | ✓ | ✓※2 |
| Linux | ✓※1 | ✗ | ✓ | ✗ |
| macOS | ✓※1 | ✗ | ✓ | ✗ |
| FreeBSD | ✓※1 | ✗ | ✗ | ✗ |
※1 デフォルトシェルです。
※2 非推奨です。shellが指定されていない場合のデフォルトシェルです。
※3 新しいRunnerを登録する際のデフォルトシェルです。
※4 WindowsでのBashシェルはサポートされていません。
6.2. インタラクティブWebターミナルのシェルサポート
インタラクティブWebターミナルは、ビルド中にブラウザから直接コンテナやシェルにアクセスできる機能です。
| OS | Bash | PowerShell Desktop | PowerShell Core | Windows Batch (非推奨) |
|---|---|---|---|---|
| Windows | ✗ | ✗ | ✗ | ✗ |
| Linux | ✓ | ✗ | ✗ | ✗ |
| macOS | ✓ | ✗ | ✗ | ✗ |
| FreeBSD | ✓ | ✗ | ✗ | ✗ |
現在、インタラクティブWebターミナルは、UNIX系OSのBashシェルでのみサポートされています。
7. 非Dockerエグゼキューターの前提条件
ヘルパーイメージに依存しないエグゼキューター(Shell、SSH、VirtualBox、Parallels、Instance、Custom)を使用する場合、以下の前提条件があります。
7.1. Git のインストール
ターゲットマシンにGitがインストールされており、PATHに含まれている必要があります。常に最新の利用可能なバージョンのGitを使用してください。
# Gitのバージョン確認
git --version
# Gitのインストール(Ubuntu/Debian)
sudo apt-get update
sudo apt-get install git
# Gitのインストール(CentOS/RHEL)
sudo yum install git
# Gitのインストール(macOS)
brew install git
7.2. Git LFS のサポート
GitLab Runnerは、ターゲットマシンにGit LFSがインストールされている場合、git lfsコマンドを使用します。GitLab Runnerがこれらのエグゼキューターを使用するシステムでは、Git LFSを最新の状態に保つようにしてください。
# Git LFSのインストール(Ubuntu/Debian)
sudo apt-get install git-lfs
# Git LFSのインストール(macOS)
brew install git-lfs
# ユーザーレベルでの初期化
git lfs install
# システム全体での初期化
git lfs install --system
GitLab Runnerコマンドを実行するユーザーに対して、git lfs installでGit LFSを初期化してください。システム全体でGit LFSを初期化するには、git lfs install --systemを使用します。
7.3. Git 認証とトークンキャッシング
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認証情報ヘルパーに保存されます。これにより、次回のGit操作で認証情報が再利用されますが、セキュリティ上のリスクがあります。
FF_GIT_URLS_WITHOUT_TOKENSがtrueの場合
CI_JOB_TOKENは事前インストールされたGit認証情報ヘルパーに保存またはキャッシュされません。これにより、セキュリティが向上しますが、毎回認証が必要になります。
推奨設定
セキュリティを重視する場合は、FF_GIT_URLS_WITHOUT_TOKENSをtrueに設定することを推奨します。
8. エグゼキューター選択の実践的なガイドライン
8.1. プロジェクトタイプ別の推奨エグゼキューター
Webアプリケーション開発
- 推奨: Docker エグゼキューター
- 理由: 依存関係の管理が容易で、データベースなどのサービスを簡単に統合できます
モバイルアプリケーション開発(iOS)
- 推奨: Parallels エグゼキューター または Shell エグゼキューター(macOS)
- 理由: Xcodeなどのツールが必要で、macOS環境が必須です
マイクロサービスアーキテクチャ
- 推奨: Kubernetes エグゼキューター
- 理由: 既存のKubernetesインフラを活用でき、スケーラビリティに優れています
レガシーシステム
- 推奨: Shell エグゼキューター または SSH エグゼキューター
- 理由: 既存の環境をそのまま利用でき、移行コストが低いです
大規模プロジェクト(変動するワークロード)
- 推奨: Docker Autoscaler エグゼキューター または Kubernetes エグゼキューター
- 理由: 自動スケーリングにより、ピーク時の待ち時間を削減し、コストを最適化できます
8.2. コスト面での考慮事項
固定コスト型
Shell、SSH エグゼキューターは、既存のインフラを使用するため、追加コストが最小限です。ただし、リソースの無駄が発生する可能性があります。
変動コスト型
Docker Autoscaler、Instance、Kubernetes エグゼキューターは、使用した分だけ課金されるため、コストを最適化できます。ただし、クラウドプロバイダーの料金体系を理解する必要があります。
ハイブリッド型
基本的なビルドにはShell エグゼキューターを使用し、重いビルドやテストにはDocker Autoscaler エグゼキューターを使用するなど、複数のエグゼキューターを組み合わせることも可能です。
8.3. セキュリティ面での考慮事項
高セキュリティ要件
Docker、VirtualBox、Parallels、Kubernetes エグゼキューターは、ファイルシステムアクセスが保護されており、セキュリティリスクが低いです。
中セキュリティ要件
SSH、Custom エグゼキューターは、構成次第でセキュリティレベルを調整できます。
低セキュリティ要件(注意)
Shell、Instance エグゼキューターは、ファイルシステムアクセスが保護されていないため、信頼できるコードのみを実行すべきです。
8.4. パフォーマンス面での考慮事項
起動時間
- 最速: Shell、SSH(既存の環境を使用)
- 高速: Docker(イメージがキャッシュされている場合)
- 中速: Kubernetes(Podの起動時間)
- 低速: VirtualBox、Parallels(VMの起動時間)
- 変動: Docker Autoscaler、Instance(インスタンスの起動時間に依存)
ビルド時間
- 最速: Shell(オーバーヘッドが最小)
- 高速: Docker(適切にキャッシュされている場合)
- 中速: Kubernetes、VirtualBox、Parallels
- 変動: Docker Autoscaler、Instance(ネットワーク遅延に依存)
リソース効率
- 最高: Kubernetes(リソースの共有と最適化)
- 高: Docker(コンテナの軽量性)
- 中: Shell、SSH
- 低: VirtualBox、Parallels(VMのオーバーヘッド)
8.5. 移行パスの推奨
Shell → Docker
依存関係をDockerfileに移行し、環境の一貫性を向上させます。段階的に移行することで、リスクを最小化できます。
Docker → Kubernetes
既にDockerを使用している場合、Kubernetesへの移行は比較的スムーズです。Kubernetes固有の設定(リソース制限、永続ボリュームなど)を追加する必要があります。
Docker Machine → Docker Autoscaler
Docker Machineは非推奨となっているため、Docker Autoscalerへの移行を計画してください。Fleeting プラグインの設定が必要ですが、基本的な動作は類似しています。
Shell → Docker Autoscaler
自動スケーリングが必要な場合、ShellからDocker Autoscalerへの移行を検討してください。まずDockerに移行し、その後自動スケーリングを有効化するのが安全です。
9. まとめ
GitLab Runnerのエグゼキューターは、CI/CDパイプラインの実行環境を柔軟に選択できる強力な機能です。プロジェクトの要件、インフラ環境、スケーラビリティのニーズ、セキュリティ要件、コスト制約に応じて、最適なエグゼキューターを選択することが重要です。
選択の決定木
-
自動スケーリングが必要か?
- はい → Docker Autoscaler、Instance、Kubernetes
- いいえ → 次へ
-
コンテナベースか?
- はい → Docker、Kubernetes
- いいえ → 次へ
-
既存のインフラを活用するか?
- Kubernetes → Kubernetes エグゼキューター
- 既存サーバー → Shell、SSH
- 仮想化環境 → VirtualBox、Parallels
- 特殊要件 → Custom
-
セキュリティ要件は?
- 高 → Docker、Kubernetes、VirtualBox、Parallels
- 中 → SSH、Custom
- 低(信頼できるコードのみ) → Shell、Instance
各エグゼキューターの特性を理解し、プロジェクトに最適な選択を行うことで、効率的で信頼性の高く、コスト効率の良いCI/CDパイプラインを構築できます。また、プロジェクトの成長に応じて、エグゼキューターを段階的に移行することも検討してください。