- ランナーの種類
- ランナーのキャッシュを手動でクリア
- Runnerの最大ジョブタイムアウトの設定
- 機密情報の取り扱いに注意
- ランナーのIPアドレスの決定
- タグを使用して、Runnerを使用するジョブ数を制限します。
GitLab Runner の設定
GitLab CI/CDでは、Runnerは.gitlab-ci.ymlで定義されたコードを実行します。 GitLab Runnerは軽量で拡張性の高いエージェントで、GitLab CI/CDのコーディネータAPIを通してCIジョブをピックアップし、ジョブを実行し、結果をGitLabインスタンスに送り返します。
ランナーは管理者によって作成され、GitLab UIに表示されます。 ランナーは特定のプロジェクトに限定することも、全てのプロジェクトで利用することもできます。
ランナーの種類
ランナーには3つのタイプがあります：
GitLab を自主管理している場合は、独自の Runner を作成することができます。
GitLab.comを使用している場合は、GitLabが提供する共有Runnerを使用するか、独自のグループや特定のRunnerを作成することができます。
共有Runner
共有ランナーは、GitLabインスタンス内のすべてのプロジェクトで利用できます。
同じような要件を持つ複数のジョブがある場合は、共有Runnerを使用してください。 多くのプロジェクトのために複数のRunnerを待機させるのではなく、複数のプロジェクトを処理する少数のRunnerを持つことができます。
GitLabのセルフマネージドインスタンスを使用している場合：
- 管理者は、プロジェクトの[設定]>[CI/CD]に進み、[ランナー]セクションを展開し、[ランナーのインストール手順を表示]をクリックすることで、共有ランナーをインストールし、登録することができます。 これらの手順は、ここでも利用可能です。
- 管理者は、グループごとに共有ランナーパイプラインの最大分数を設定することもできます。
GitLab.comを使用している場合：
- GitLabが管理する共有ランナーのリストから選択できます。
- 共有 Runner は、アカウントに含まれるパイプライン分を消費します。
シェアード・ランナーはどのようにジョブを選ぶのか
共有Runnerは、公平な使用キューを使用してジョブを処理します。 このキューは、プロジェクトが何百ものジョブを作成し、利用可能なすべての共有Runnerリソースを使用することを防ぎます。
公正利用キューアルゴリズムは、共有Runner上で実行中のジョブ数が最も少ないプロジェクトに基づいてジョブを割り当てます。
例1
これらのジョブがキューにある場合：
- プロジェクト1のジョブ1
- プロジェクト1のジョブ2
- プロジェクト1のジョブ3
- プロジェクト2のジョブ4
- プロジェクト2のジョブ5
- プロジェクト3のジョブ6
公正利用アルゴリズムはこの順序でジョブを割り当てます：
- ジョブ 1 が最初に選択されます。これは、実行中のジョブがないプロジェクト (つまり、すべてのプロジェクト) の中で、ジョブ番号が最も小さいからです。
- ジョブ 4 は、実行中のジョブがないプロジェクト（プロジェクト 1 には実行中のジョブがある）の中で、最も低いジョブ番号になります。
- プロジェクト 1 と 2 ではジョブが実行されています）。
- ジョブ2はその次で、実行中のジョブ数が最も少ない（それぞれ1）プロジェクトの中で、ジョブ数が最も少ないからです。
- プロジェクト1では2つのジョブが実行中であり、ジョブ5はプロジェクト2と3の間で最も残ジョブ数が少ないので、ジョブ5はその次です。
- 最後にジョブ3です…残された唯一のジョブですから。
例2
これらのジョブがキューにある場合：
- プロジェクト1のジョブ1
- プロジェクト1のジョブ2
- プロジェクト1のジョブ3
- プロジェクト2のジョブ4
- プロジェクト2のジョブ5
- プロジェクト3のジョブ6
公正利用アルゴリズムはこの順序でジョブを割り当てます：
- ジョブ 1 が最初に選択されます。これは、実行中のジョブがないプロジェクト (つまり、すべてのプロジェクト) の中で、ジョブ番号が最も小さいからです。
- ジョブ1を終了します。
- ジョブ1が終了すると、すべてのプロジェクトでジョブは0になり、ジョブ2は最も低いジョブ番号になります。
- プロジェクト 1 がジョブを実行しているため、プロジェクト 2 と 3 がジョブを実行していない場合、4 が最少となります。
- 4つ目のジョブを終えました。
- ジョブ4が終了し、プロジェクト2にはジョブはありません。
- プロジェクト3は実行中のジョブがない唯一のプロジェクトなので、次はジョブ6です。
- 最後に、私たちはジョブ3を選びます…繰り返しになりますが、それが残された唯一のジョブだからです。
共有ランナーの有効化
GitLab.comでは、すべてのプロジェクトで共有Runnerがデフォルトで有効になっています。
GitLabのセルフマネージドインスタンスでは、管理者がインストールして登録する必要があります。
また、個々のプロジェクトで共有ランナーを有効または無効にすることもできます。
共有ランナーを有効または無効にします：
- プロジェクトの Settings >CI/CDに移動し、Runnerセクションを展開します。
- 共有ランナーの許可］または［共有ランナーの無効化］をクリックします。
グループランナー
グループランナーは、グループ内のすべてのプロジェクトがランナーのセットにアクセスできるようにする場合に使用します。
グループランナーは、先入れ先出し（FIFO）キューを使用してジョブを処理します。
グループRunnerの作成
GitLabインスタンスまたはGitLab.comのグループRunnerを作成することができます。 グループのオーナー権限が必要です。
グループRunnerを作成するには：
- ランナーをインストールします。
- Runnerを活躍させたいグループに行きましょう。
- settings} Settings >CI/CDと進み、Runnerセクションを展開します。
- URLとトークンに注意してください。
- ランナーを登録してください。
グループ Runner の一時停止または削除
グループ Runner を一時停止または削除することができます。 グループのオーナー権限が必要です。
- ランナーを削除または一時停止したいグループに移動します。
- settings} Settings >CI/CDと進み、Runnerセクションを展開します。
- 一時停止またはランナーの削除をクリックします。
- 確認ダイアログで「OK」をクリックします。
特定のランナー
特定のプロジェクトにRunnerを使用する場合は、Specific Runnerを使用します。 例えば、以下のような場合です：
- 資格が必要なデプロイの仕事など、特定の条件があるジョブ。
- CIアクティビティが多く、他のRunnerから分離することで恩恵を受けることができるプロジェクト。
特定のRunnerを複数のプロジェクトで使用するように設定することができます。 特定のRunnerは、各プロジェクトで明示的に有効にする必要があります。
特定のrunnerは、先入れ先出し（FIFO）キューを使用してジョブを処理します。
特定のランナーの作成
自分で管理するGitLabインスタンスやGitLab.com用に特定のRunnerを作成することができます。 プロジェクトのオーナー権限が必要です。
特定のRunnerを作成します：
特定のプロジェクトで特定のRunnerを有効にします。
特定のRunnerは、そのRunnerが作成されたプロジェクトで使用できます。 管理者は、特定のRunnerを他のプロジェクトにも適用できるようにすることができます。
- プロジェクトのオーナー権限が必要です。
- 特定のランナーはロックされてはいけません。
プロジェクトの特定のRunnerを有効または無効にします：
- プロジェクトの Settings >CI/CDに移動し、Runnerセクションを展開します。
- このプロジェクトで有効にする］または［このプロジェクトで無効にする］をクリックします。
特定の Runner が他のプロジェクトで有効にならないようにします。
特定のRunnerを「ロック」して、他のプロジェクトで有効にできないように設定することができます。 この設定は、最初にRunnerを登録するときに有効にできますが、後で変更することもできます。
Runner をロックまたはアンロックします：
- プロジェクトの Settings >CI/CDに移動し、Runnerセクションを展開します。
- ロックまたはロック解除したいランナーを探し、有効になっていることを確認します。
- 鉛筆ボタンをクリックします。
- 現在のプロジェクトにロックする]オプションにチェックを入れます。
- 変更を保存する］をクリックします。
ランナーのキャッシュを手動でクリア
キャッシュの消去をお読みください。
Runnerの最大ジョブタイムアウトの設定
各ランナーに対して、最大ジョブタイムアウトを指定することができます。 このタイムアウトは、プロジェクトで定義されたタイムアウトよりも小さい場合、優先されます。
この機能は、タイムアウトが長い（例えば1週間）ジョブを持つプロジェクトによって共有Runnerが圧迫されるのを防ぐために使用できます。
設定されていない場合、Runnerはプロジェクトのタイムアウトをオーバーライドしません。
この機能の仕組み
例 1 - Runner のタイムアウトがプロジェクトのタイムアウトより大きい場合。
- ランナーの_最大ジョブタイムアウトは_24時間に設定されています。
- プロジェクトのCI/CDタイムアウトを 2時間に設定した場合
- ジョブ開始
- ジョブが長く実行された場合、2時間後にタイムアウトします。
例 2 - ランナータイムアウトが設定されていない場合
- _最大ジョブのタイムアウト_設定をランナーから削除します。
- プロジェクトのCI/CDタイムアウトを 2時間に設定した場合
- ジョブ開始
- ジョブが長く実行された場合、2時間後にタイムアウトします。
例 3 - ランナーのタイムアウトがプロジェクトのタイムアウトより小さい場合
- ランナーの_最大ジョブタイムアウトを_ 30分に設定した場合
- プロジェクトのCI/_CDタイムアウトを_2時間に設定した場合
- ジョブ開始
- ジョブが長く実行された場合、30分後にタイムアウトします。
機密情報の取り扱いに注意
いくつかのRunnerExecutor では、Runner 上でジョブを実行することができれば、ファイルシステムにフルアクセスすることができ、Runner のトークンと同様にジョブの実行するすべてのコードにアクセスすることができます。 共有 Runner では、Runner 上でジョブを実行する誰もが、Runner 上で実行される他の誰かのコードにアクセスできることを意味します。
また、Runnerトークンにアクセ スできるので、例えばRunnerのクローンを作成して偽のジョブを投入することも可能です。
大規模な公開GitLabインスタンスでの共有Runnerの使用を制限したり、GitLabインスタンスへのアクセスをコントロールしたり、より安全なRunnerExecutorを使用したりすることで、上記は簡単に回避できます。
ランナーが機密情報を漏らさないようにします。
GitLab 10.0で導入されました。
ランナーが保護されている場合、ランナーは保護されたブランチまたは保護されたタグで作成されたジョブのみを選択し、その他のジョブは無視されます。
Runnerの保護または保護解除：
- プロジェクトの Settings >CI/CDに移動し、Runnerセクションを展開します。
- 保護または保護解除したいランナーを見つけてください。 有効になっていることを確認してください。
- 鉛筆ボタンをクリックします。
- 保護オプションをチェックしてください。
- 変更を保存する］をクリックします。
フォーク
プロジェクトがフォークされるたびに、そのプロジェクトに関連するジョブの設定がコピーされます。 これは、あるプロジェクトに共有Runnerが設定されていて、誰かがそのプロジェクトをフォークした場合、共有Runnerはそのプロジェクトのジョブにも対応することを意味します。
ランナーにおける攻撃ベクトル
先ほども少し触れましたが、Runnerの以下のようなことが悪用される可能性があります。 私たちは常に、これらのセキュリティ上の注意を緩和する貢献をしてくれる人を探しています。
プロジェクトのRunner登録トークンのリセット
プロジェクトの登録トークンが公開されたと思われる場合は、それをリセットしてください。 トークンを使って、プロジェクトに別のRunnerを登録することができます。 その新しいRunnerを使って、秘密変数の値を取得したり、プロジェクトのコードをクローンしたりすることができます。
トークンをリセットするには
- プロジェクトの{設定} 設定 >CI/CDに移動します。
- General pipelines settingsセクションを展開します。
- Runner tokenフォームフィールドを見つけ、Reveal valueボタンをクリックしてください。
- 値を削除し、フォームを保存します。
- ページが更新されたら、Runner settingsセクションを展開し、登録トークンを確認してください。
今後、古いトークンは無効となり、プロジェクトに新しいRunnerを登録することはできません。 新しいRunnerのプロビジョニングと登録にツールを使用している場合は、それらのツールで使用されているトークンを更新して、新しいトークンの値を反映させる必要があります。
ランナーのIPアドレスの決定
GitLab 10.6で導入されました。
RunnerのIPアドレスを知っておくと、そのRunnerのイシューをトラブルシュートするときに便利です。 GitLabは、ジョブをポーリングするときにGitLabに行うHTTPリクエストのソースを表示することで、IPアドレスを保存して表示します。 IPアドレスは常に最新の状態に保たれているので、RunnerのIPが変更されると、GitLabで自動的に更新されます。
共有Runnerと特定RunnerのIPアドレスは異なる場所にあります。
共有ランナーのIPアドレスの決定
共有 Runner の IP アドレスを表示するには、GitLab インスタンスへの管理者権限が必要です。 これを決定するには、以下のようにします：
- admin} 管理エリア > 概要 > Runnerにアクセスしてください。
- テーブルのRunnerを探すと、IP Addressの列があるはずです。
特定のランナーのIPアドレスの決定
特定のプロジェクトのRunnerのIPアドレスを見つけるには、そのプロジェクトのオーナー権限が必要です。
- プロジェクトの Settings >CI/CDに移動し、Runnerセクションを展開します。
- 詳細ページにIPアドレスの行が表示されます。
タグを使用して、Runnerを使用するジョブ数を制限します。
Runnerが共有するプロジェクトで遭遇する可能性のあるすべての異なるタイプのジョブを実行できるように、Runnerをセットアップする必要があります。 タグがなければ、これは大量のプロジェクトで問題になるでしょう。
Runnerに処理できるジョブの種類をタグ付けすることで、共有Runnerが実行可能なジョブのみを実行するようにすることができます。
例えばGitLabでは、Railsのテストスイートを実行するために適切な依存関係が含まれているRunnerにはrails 。
Runnerを登録すると、デフォルトではタグ付けされたジョブのみが選択されます。 これを変更するには、プロジェクトのオーナー権限が必要です。
Runnerにタグなしジョブを選択させるには：
- プロジェクトの Settings >CI/CDに移動し、Runnerセクションを展開します。
- タグなしジョブを選択したいRunnerを見つけて、有効になっていることを確認してください。
- 鉛筆ボタンをクリックします。
- タグなしジョブの実行］オプションをオンにします。
- 変更を有効にするには、[変更を保存] ボタンをクリックします。
以下は、さまざまなバリエーションのシナリオ例です。
タグ付きジョブのみを実行するランナー
次の例は、タグ付きジョブのみを実行するようにRunnerを設定した場合の潜在的な影響を示しています。
例1：
- Runnerはタグ付きジョブのみを実行するように設定されており、
dockerタグが付いています。 -
helloタグを持つジョブが実行され、スタックします。
例2：
- Runnerはタグ付きジョブのみを実行するように設定されており、
dockerタグが付いています。 -
dockerタグを持つジョブが実行され、実行されます。
例3：
- Runnerはタグ付きジョブのみを実行するように設定されており、
dockerタグが付いています。 - タグが定義されていないジョブが実行され、スタックします。
runnerはタグなしジョブの実行を許可されます。
次の例は、タグ付きおよびタグなしジョブを実行するようにRunnerが設定されている場合の潜在的な影響を示しています。
例1：
- Runnerはタグなしジョブを実行するように設定されており、
dockerタグがあります。 - タグが定義されていないジョブが実行されます。
-
dockerタグが定義された2つ目のジョブが実行されます。
例2：
- Runnerはタグなしジョブを実行するように構成されており、タグは定義されていません。
- タグが定義されていないジョブが実行されます。
-
dockerタグが定義されている2つ目のジョブがスタックしています。
