ランナーSaaS
GitLab.com上でCI/CDジョブを実行するには、GitLabがホストするSaaSランナーを使用すると、異なる環境でアプリケーションをシームレスにビルド、テスト、デプロイできます。これらのRunnerはGitLab.comと完全にインテグレーションされており、すべてのプロジェクトでデフォルトで有効になっており、設定は不要です。ジョブは以下の環境で実行できます:
サイズに基づいてマシンタイプに適用されるコスト係数については、コスト係数を参照してください。これらのランナーで使用できる分数は、サブスクリプションプランの 最大コンピュートユニット数に依存します。
タグ付けされていないジョブは、small
Linux Runner上のコンテナで自動的に実行されます。
目標はCI/CDジョブの90%を120秒以内に実行開始させること。エラー率は0.5%未満でなければなりません。
SaaSランナーの仕組み
SaaS Runnerを利用すると:
- 各ジョブは、特定のジョブ専用に新しくプロビジョニングされたVMで実行されます。
- VMはジョブの間だけアクティビティとなり、すぐに削除されます。つまり、ジョブが仮想マシンに加えた変更は、後続のジョブでは利用できません。
- ジョブが実行される仮想マシンは、パスワードなしで
sudo
にアクセスできます。 - ストレージはオペレーションシステム、プリインストールソフトウェアのイメージ、クローンしたリポジトリのコピーによって共有されます。これは、ジョブが使用できる空きディスク容量が減少することを意味します。
SaaSランナーのセキュリティ
Linux と Windows 上の GitLab SaaS Runner は Google Compute Platform 上で動作します。Google Infrastructure Security Design Overviewのホワイトペーパーでは、Googleがどのように技術インフラにセキュリティを設計しているかの概要を説明しています。GitLabTrust Centerと GitLab Security Compliance Controlsのページでは、GitLab SaaS Runnerを管理するセキュリティとコンプライアンスのコントロールの概要を説明しています。
次のセクションでは、GitLab Runner SaaS CIビルド環境のセキュリティを強化する追加のビルトインレイヤーの概要を説明します。
CI ジョブ実行のセキュリティ
専用の一時ランナーVMが各CIジョブをホストし、実行します。GitLab SaaSでは、2つのCIジョブが同じVM上で実行されることはありません。
この例では、プロジェクトのパイプラインに3つのジョブがあります。そのため、パイプラインを実行するために3つの一時的なVM、つまりジョブごとに1つのVMが使用されます。
ビルドジョブはrunner-ns46nmmj-project-43717858
で、テストジョブはf131a6a2runner-new2m-od-project-43717858
で、デプロイジョブはrunner-tmand5m-project-43717858
で実行されます。
GitLabは、CIジョブが完了した直後に、一時的なRunner VMを削除するコマンドをGoogle Compute APIに送信します。Google Compute Engineのハイパーバイザーが仮想マシンと関連データをセキュアに削除するタスクを引き継ぎます。
CIジョブVMのネットワークセキュリティ
- ファイアウォールのルールは、一時的なVMから公開インターネットへのアウトバウンド通信のみを許可します。
- 公開インターネットから一時的なVMへのインバウンド通信は許可されません。
- ファイアウォールルールはVM間の通信を許可しません。
- 一時的なVMに許可される内部通信はRunner Managerからのものだけです。
サポートされるイメージのライフサイクル
MacOS および Windows 上の Runner では、サポートされているイメージでのみジョブを実行できます。独自のイメージを持ち込むことはできません。サポートされているイメージのライフサイクルは以下のとおりです:
- ベータ版
- 一般に利用可能
- 非推奨
ベータ版
イメージを一般に利用可能にする前に(GA) イメージに関するフィードバックを収集し、あらゆるイシューに対処するために、新しいイメージはベータ版としてリリースされます。ベータ版イメージで実行されるジョブは、サービスレベル契約の対象外となります。ベータ版イメージを使用している場合は、イシューを作成することでフィードバックを提供できます。
一般に利用可能
一般に入手可能な(GA) 画像は、画像がベータ段階を完了し、一般的な使用に適しているとみなされた後にリリースされます。GA になるためには、そのイメージは以下の要件を満たす必要があります:
- 報告された重大なバグをすべて解決し、ベータ段階を完了していること。
- インストールされたソフトウェアとOSの互換性
GAイメージ上で実行されるジョブは、定義されたサービスレベル契約の対象となります。時間の経過とともに、これらのイメージは廃止されます。
非推奨
一般に利用可能な(GA) イメージは、一度に最大 2 つまでサポートされます。新しいGAイメージがリリースされると、最も古いGAイメージは非推奨となります。非推奨イメージは更新されなくなり、非推奨ガイドラインに従って3ヶ月後に削除されます。
主なバージョンの変更(ブレーク)
GitLab CI/CDとRunnerの進化に伴い、特定のブレークチェンジが必要になりました。
GitLab 15.0以降では、すべての変更点は以下のページに記載されています:
以前のメジャーバージョンリリースのGitLab Runnerの変更点は以下の通りです:
- 14.0:変更なし。
- 13.0:
-
バックポートされた
os.Expand
を削除します。 - Fedora 29 パッケージのサポートを削除しました。
- MacOS 32 ビットサポートを削除しました。
-
debug/jobs/list?v=1
エンドポイントを削除。 - Docker Executorのサービス定義時の文字列配列のサポートを削除しました。
-
登録コマンドの
--docker-services
フラグを削除。 - レガシービルドディレクトリのキャッシュを削除しました。
-
FF_USE_LEGACY_VOLUMES_MOUNTING_ORDER
機能フラグを削除しました。 - Windows Server 1803 のサポートを削除します。
-
バックポートされた
- 12.0: