GitLab Runnerチャートの使用

GitLab Runnerサブチャートは、CIジョブを実行するためのGitLab Runnerを提供します。これはデフォルトで有効になっており、S3互換オブジェクトストレージを使用したキャッシュをサポートし、すぐに使用できるはずです。

要件

GitLab 16.0では、Runner認証トークンを使用してRunnerを登録する新しいRunner作成ワークフローが導入されました。登録トークンを使用する従来のワークフローは非推奨となり、GitLab 17.0ではデフォルトで無効になっています。これはGitLab 18.0で削除される予定です。

推奨されるワークフローを使用するには:

• 認証トークンを生成します。

• 設定はshared-secretsジョブで処理されないため、Runnerシークレット（<release>-gitlab-runner-secret）を手動で更新します。

• gitlab-runner.runners.lockedをnullに設定します:

  gitlab-runner:
    runners:
      locked: null

従来のワークフローを使用する場合（推奨されません）:

• 従来のワークフローを再度有効にする必要があります。
• 登録トークンは、shared-secretsジョブによって入力されたものです。
• GitLab 18.0より前に新しいワークフローに移行する必要があります。これにより、従来のワークフローのサポートが削除されます。

設定

詳細については、使用方法と設定に関するドキュメントを参照してください。

スタンドアロンRunnerのデプロイ

既定では、gitlabUrlを推測し、登録トークンを自動的に生成し、migrationsチャートを介して生成します。この動作は、実行中のGitLabインスタンスでデプロイする場合は機能しません。

この場合、gitlabUrlの値を、実行中のGitLabインスタンスのURLに設定する必要があります。また、gitlab-runnerシークレットを手動で作成し、実行中のGitLabから提供されたregistrationTokenでそれを満たす必要があります。

Docker-in-Dockerを使用する

Docker-in-Dockerを実行するには、Runnerコンテナが、必要な機能にアクセスできるように特権を持っている必要があります。これを有効にするには、privilegedの値をtrueに設定します。これがtrueにデフォルト設定されていない理由については、アップストリームドキュメントを参照してください。

セキュリティに関する懸念

特権コンテナには拡張機能があり、たとえば、実行元のホストから任意のファイルをマウントできます。重要なものが隣で実行されないように、隔離された環境でコンテナを実行してください。

デフォルトのRunner設定

GitLabチャートで使用されるデフォルトのRunner設定は、デフォルトでキャッシュ用に含まれているMinIOを使用するようにカスタマイズされています。Runner config値を設定する場合は、独自のキャッシュ設定も構成する必要があります。

gitlab-runner:
  runners:
    config: |
      [[runners]]
        [runners.kubernetes]
        image = "ubuntu:22.04"
        {{- if .Values.global.minio.enabled }}
        [runners.cache]
          Type = "s3"
          Path = "gitlab-runner"
          Shared = true
          [runners.cache.s3]
            ServerAddress = {{ include "gitlab-runner.cache-tpl.s3ServerAddress" . }}
            BucketName = "runner-cache"
            BucketLocation = "us-east-1"
            Insecure = false
        {{ end }}

カスタマイズされたすべてのGitLab Runnerチャートの設定は、gitlab-runnerキーの下のトップレベルvalues.yamlファイルにあります。