• ホストの設定
  • ホスト接尾辞
• 水平ポッド・オートスケーラーの設定
• PodDisruptionBudgetの設定
• CronJobの設定
• Ingressの設定
  • イングレス・パス
  • クラウドプロバイダーのロードバランサー
  • global.ingress.configureCertmanager
• GitLabバージョン
• すべての画像タグにサフィックスを追加
• PostgreSQL の設定
  • ChartごとにPostgreSQL
  • PostgreSQL SSL
  • PostgreSQLの負荷分散
  • 複数のデータベース接続の設定
• Redisの設定
  • Redisチャート固有の設定
  • Redisセンチネルのサポート
  • 複数のRedisのサポート
  • セキュアなRedisスキームの指定(SSL)
  • パスワードなしのRedisサーバー
• レジストリ設定の構成
  • 通知
• Gitalyの設定
  • Gitalyホスト
    • 内部
    • 外部ノード
    • 混合
  • authToken
  • 非推奨のGitaly設定
  • TLS設定
• Praefectの設定
  • Praefectを有効にする
  • Praefectのグローバル設定
• MinIOの設定
• appConfigの設定
  • 一般的なアプリケーション設定
    • コンテンツセキュリティポリシー
    • defaultProjectsFeatures
  • Gravatar/Libravatar の設定
  • GitLabインスタンスへのAnalyticsサービスのフック
  • 統合オブジェクトストレージ
  • バケットの指定
    • ストレージオプション
  • LFS、アーティファクト、アップロード、パッケージ、外部MR差分、依存プロキシ
    • 接続
    • とき（外部MR Diffの場合のみ）
    • cdn (CIアーティファクトのみ)
  • 受信メールの設定
  • KASの設定
    • カスタムシークレット
    • カスタムURL
    • 外部KAS
    • TLS設定
  • 推奨レビュアー設定
  • LDAP
    • LDAP ウェブサインインを無効にします。
    • カスタムCAまたは自己署名LDAP証明書の使用
  • DuoAuth
  • Duo 秘密キーの設定
  • オムニ認証
    • プロバイダ
  • cronジョブ関連の設定
  • Sentryの設定
  • gitlab_docs 設定
  • スマートカード認証設定
  • Sidekiqルーティングルール設定
• Rails の設定
• Workhorse の設定
  • ブートスナップキャッシュ
• GitLab Shell の設定
  • ポート
  • TCP プロキシプロトコル
• GitLab Pages の設定
• ウェブサービスの設定
  • ワーカータイムアウト
• カスタム認証局
• アプリケーションリソース
• GitLabベースイメージ
• サービスアカウント
• 注釈
• ノードセレクタ
• ラベル
  • 一般的なラベル
  • ポッド
  • サービス
• トレーシング
• extraEnv
• 追加EnvFrom
• OAuthの設定
• Kerberos
  • Kerberos専用ポート
  • LDAPカスタム許可レルム
• 送信メール
• プラットフォーム
• 親和性
• ポッドの優先順位と先取り
• ログのローテーション

グローバルを使用したChartの設定

Helmのラッパー・チャートをインストールする際に設定の重複を減らすために、values.yaml のglobal セクションでいくつかの設定を行うことができます。 これらのグローバル設定は複数のチャートで使用され、その他の設定はそのチャート内でスコープされます。グローバル変数がどのように動作するかについては、Helmのグローバルに関するドキュメントを参照してください。

• ホスト
• イングレス
• GitLab バージョン
• PostgreSQL
• Redis
• レジストリ
• Gitaly
• Praefect
• MinIO
• アプリコンフィグ
• Rails
• Workhorse
• GitLab シェル
• Pages
• ウェブサービス
• カスタム認証局
• アプリケーションリソース
• GitLabベースイメージ
• サービスアカウント
• 注釈
• トレース
• extraEnv
• extraEnvFrom
• OAuth
• Kerberos
• 送信メール
• プラットフォーム
• 親和性
• ポッドの優先順位と先取り
• ログローテーション

ホストの設定

GitLab グローバルホスト設定はglobal.hosts キーの下にあります。

global:
  hosts:
    domain: example.com
    hostSuffix: staging
    https: false
    externalIP:
    gitlab:
      name: gitlab.example.com
      https: false
    registry:
      name: registry.example.com
      https: false
    minio:
      name: minio.example.com
      https: false
    smartcard:
      name: smartcard.example.com
    kas:
      name: kas.example.com
    pages:
      name: pages.example.com
      https: false
    ssh: gitlab.example.com

ホスト接尾辞

hostSuffix はdomain を基本としてホスト名を組み立てるときにサブドメインに付加されますが、name が設定されているホストには使われません。

デフォルトは設定されていません。設定されている場合、サフィックスはサブドメインにハイフンを付加します。以下の例では、gitlab-staging.example.com やregistry-staging.example.com のような内部ホスト名を使用することになります：

global:
  hosts:
    domain: example.com
    hostSuffix: staging

水平ポッド・オートスケーラーの設定

HPAのGitLabグローバルホスト設定はglobal.hpa キーの下にあります：

PodDisruptionBudgetの設定

PDBのGitLabグローバルホスト設定はglobal.pdb キーの下にあります：

CronJobの設定

CronJobsのGitLabグローバルホスト設定はglobal.batch.cronJob キーの下にあります：

Ingressの設定

IngressのGitLabグローバルホスト設定はglobal.ingress キーの下にあります：

様々なクラウドプロバイダのサンプル設定は examples フォルダにあります。

• AWS
• GKE

イングレス・パス

このChartは、Ingressオブジェクトのpath エントリーの定義を変更する必要があるユーザーを支援する手段として、global.ingress.path を採用しています。多くのユーザーはこの設定を必要としないので、_設定すべきでは_ありません。

GCPでingress.class: gce 、AWSでingress.class: alb 、またはその他のプロバイダを使用する場合など、ロードバランサ/プロキシの動作に合わせて、path の定義を/* で終わらせる必要があるユーザー向けです。

この設定により、このChart全体のIngressリソースのすべてのpath エントリが、これでレンダリングされることが保証されます。唯一の例外は、gitlab/webservice デプロイ設定に入力するときで、path を指定する必要があります。

クラウドプロバイダーのロードバランサー

さまざまなクラウドプロバイダのロードバランサの実装は、このチャートの一部としてデプロイされたIngressリソースとNGINXコントローラの設定に影響を与えます。次の表に例を示します。

global.ingress.configureCertmanager

Ingressオブジェクトに対するcert-managerの自動設定を制御するグローバル設定。true の場合、certmanager-issuer.email の設定に依存します。

false とglobal.ingress.tls.secretName が設定されていない場合、自己署名証明書の自動生成が有効になり、すべての Ingress オブジェクトに対してワイルドカード証明書が作成されます。

外部cert-manager を使用する場合は、以下を指定する必要があります：

• gitlab.webservice.ingress.tls.secretName
• registry.ingress.tls.secretName
• minio.ingress.tls.secretName
• global.ingress.annotations

GitLabバージョン

Chartのデフォルトのイメージタグで使用されるGitLabのバージョンは、global.gitlabVersion キーで変更できます：

--set global.gitlabVersion=11.0.1

これはwebservice,sidekiq,migration チャートで使われるデフォルトのイメージタグに影響します。gitaly,gitlab-shell,gitlab-runner のイメージタグは、GitLabのバージョンと互換性のあるものに別途更新する必要があることに注意してください。

すべての画像タグにサフィックスを追加

Helm Chart で使用するすべてのイメージの名前にサフィックスを追加したい場合は、global.image.tagSuffix キーを使用します。たとえば、GitLab の fips 準拠のコンテナイメージを使いたい場合などです。GitLab のコンテナイメージはすべて image タグに-fips という拡張子をつけてビルドされています。

--set global.image.tagSuffix="-fips"

PostgreSQL の設定

GitLabグローバルPostgreSQL設定はglobal.psql キーの下にあります。

global:
  psql:
    host: psql.example.com
    # serviceName: pgbouncer
    port: 5432
    database: gitlabhq_production
    username: gitlab
    applicationName:
    preparedStatements: false
    databaseTasks: true
    connectTimeout:
    keepalives:
    keepalivesIdle:
    keepalivesInterval:
    keepalivesCount:
    tcpUserTimeout:
    password:
      useSecret: true
      secret: gitlab-postgres
      key: psql-password
      file:

ChartごとにPostgreSQL

複雑なデプロイでは、PostgreSQLに対してこのチャートの異なる部分を異なる設定で構成したい場合があります。v4.2.0 の時点で、global.psql 内で利用可能なすべてのプロパティは、例えばgitlab.sidekiq.psqlのように、Chart単位で設定することができます。psql.load_balancingを除いて、global.psqlから_存在しない_ものはすべて継承されます。

PostgreSQLの負荷分散は、設計上、グローバルから継承される_ことは_ありません。

PostgreSQL SSL

GitLab と PostgreSQL データベースを相互 TLS で接続したい場合は、クライアント鍵、クライアント証明書、サーバー認証局をそれぞれ別の秘密鍵として含むシークレットを作成します。そして、global.psql.ssl マッピングを使ってシークレットの構造を記述します。

global:
  psql:
    ssl:
      secret: db-example-ssl-secrets # Name of the secret
      clientCertificate: cert.pem    # Secret key storing the certificate
      clientKey: key.pem             # Secret key of the certificate's key
      serverCA: server-ca.pem        # Secret key containing the CA for the database server

また、正しい鍵を指すようにextraEnv の値を Exporter 環境値に設定する必要があるかもしれません。

global:
  extraEnv:
      PGSSLCERT: '/etc/gitlab/postgres/ssl/client-certificate.pem'
      PGSSLKEY: '/etc/gitlab/postgres/ssl/client-key.pem'
      PGSSLROOTCERT: '/etc/gitlab/postgres/ssl/server-ca.pem'

PostgreSQLの負荷分散

このChartではPostgreSQLをHA方式でデプロイしないため、この機能には外部のPostgreSQLを使用する必要があります。

GitLabのRailsコンポーネントには、PostgreSQLクラスタを利用して読み込み専用のクエリをロードバランスする機能があります。

この機能は2つの方法で設定できます：

• セカンダリの_ホスト_名の静的リストを使用する方法。
• DNSベースのサービス発見メカニズムの使用。

静的リストによる設定は簡単です：

global:
  psql:
    host: primary.database
    load_balancing:
       hosts:
       - secondary-1.database
       - secondary-2.database

サービスディスカバリーの設定はもっと複雑です。この設定の完全な詳細、パラメータと関連する動作については、GitLab Administrationドキュメントの Service Discoveryを参照してください。

global:
  psql:
    host: primary.database
    load_balancing:
      discover:
        record:  secondary.postgresql.service.consul
        # record_type: A
        # nameserver: localhost
        # port: 8600
        # interval: 60
        # disconnect_timeout: 120
        # use_tcp: false
        # max_replica_pools: 30

古い読み込みの処理に関して、さらなるチューニングも可能です。GitLab Administration ドキュメントではこれらの項目について詳しく説明しており、これらのプロパティはload_balancing で直接追加することができます。

global:
  psql:
    load_balancing:
      max_replication_difference: # See documentation
      max_replication_lag_time:   # See documentation
      replica_check_interval:     # See documentation

複数のデータベース接続の設定

gitlab:db:decomposition:connection_status RakeタスクはGitLab 15.11で導入されました。

GitLab 16.0では、GitLabはデフォルトで同じPostgreSQLデータベースを指す2つのデータベース接続を使用します。

単一のデータベース接続に戻したい場合は、ci.enabled キーをfalse に設定してください：

global:
  psql:
    ci:
      enabled: false

Redisの設定

GitLabのグローバルRedis設定はglobal.redis キーの下にあります。

デフォルトでは、単一の複製されていないRedisインスタンスを使用します。可用性の高いRedisが必要な場合は、外部のRedisインスタンスを使用することをお勧めします。

外部Redisインスタンスを使用するには、redis.install=false を設定し、高度なドキュメントに従って設定を行います。

global:
  redis:
    host: redis.example.com
    serviceName: redis
    port: 6379
    auth:
      enabled: true
      secret: gitlab-redis
      key: redis-password
    scheme:

Redisチャート固有の設定

Redisチャートを直接設定するための設定は、redis キーの下にあります：

redis:
  install: true
  image:
    registry: registry.example.com
    repository: example/redis
    tag: x.y.z

詳細については、設定の完全なリストを参照してください。

Redisセンチネルのサポート

現在のRedis Sentinelサポートは、GitLabチャートとは別にデプロイされたSentinelのみをサポートしています。そのため、GitLabチャートを介したRedisのデプロイは、redis.install=false で無効にする必要があります。Redisのパスワードを含むKubernetesシークレットは、GitLabチャートをデプロイする前に手動で作成する必要があります。

GitLabチャートからのHA Redisクラスターのインストールは、センチネルの使用をサポートしていません。センチネルをサポートしたい場合は、RedisクラスターをGitLabチャートのインストールとは別に作成する必要があります。これはKubernetesクラスタの内部または外部で行うことができます。

GitLabデプロイされたRedisクラスターでのセンチネルのサポートを追跡するためのイシューが作成されました。

redis:
  install: false
global:
  redis:
    host: redis.example.com
    serviceName: redis
    port: 6379
    sentinels:
      - host: sentinel1.example.com
        port: 26379
      - host: sentinel2.exeample.com
        port: 26379
    auth:
      enabled: true
      secret: gitlab-redis
      key: redis-password

一般的なRedis設定にある以前のRedis属性はすべて、上の表で指定し直さない限り、Sentinelサポートでも引き続き適用されます。

複数のRedisのサポート

GitLabのChartには、現在のところ、異なる永続化クラスに対して別々のRedisインスタンスで実行するためのサポートが含まれています：

インスタンスはいくつでも指定できます。指定されていないインスタンスは、global.redis.host で指定されたプライマリ Redis インスタンスで処理されるか、Chart からデプロイされた Redis インスタンスを使用します。例えば

redis:
  install: false
global:
  redis:
    host: redis.example
    port: 6379
    auth:
      enabled: true
      secret: redis-secret
      key: redis-password
    cache:
      host: cache.redis.example
      port: 6379
      auth:
        enabled: true
        secret: cache-secret
        key: cache-password
    sharedState:
      host: shared.redis.example
      port: 6379
      auth:
        enabled: true
        secret: shared-secret
        key: shared-password
    queues:
      host: queues.redis.example
      port: 6379
      auth:
        enabled: true
        secret: queues-secret
        key: queues-password
    actioncable:
      host: cable.redis.example
      port: 6379
      auth:
        enabled: true
        secret: cable-secret
        key: cable-password
    traceChunks:
      host: traceChunks.redis.example
      port: 6379
      auth:
        enabled: true
        secret: traceChunks-secret
        key: traceChunks-password
    rateLimiting:
      host: rateLimiting.redis.example
      port: 6379
      auth:
        enabled: true
        secret: rateLimiting-secret
        key: rateLimiting-password
    sessions:
      host: sessions.redis.example
      port: 6379
      auth:
        enabled: true
        secret: sessions-secret
        key: sessions-password
    repositoryCache:
      host: repositoryCache.redis.example
      port: 6379
      auth:
        enabled: true
        secret: repositoryCache-secret
        key: repositoryCache-password

以下の表では、Redisインスタンスの各ディクショナリの属性について説明します。

分離されていない追加の永続化クラスがあるため、プライマリRedis定義が必要です。

各インスタンス定義では、Redis Sentinelサポートを使用することもできます。Sentinelの設定は共有されず、Sentinelを使用するインスタンスごとに指定する必要があります。Sentinelサーバーの設定に使用される属性については、Sentinel設定を参照してください。

セキュアなRedisスキームの指定(SSL)

SSLを使用してRedisに接続します：

1. rediss (doubles) スキームパラメータを使用するように設定を更新します。

2. 設定で、authClients をfalse に設定します：

   global:
     redis:
       scheme: rediss
   redis:
     tls:
       enabled: true
       authClients: false
   

   Redisはデフォルトで相互TLSに設定されていますが、すべてのChartコンポーネントが対応しているわけではないので、この設定は必須です。

3. Bitnami の手順に従ってTLS を有効にしてください。ChartコンポーネントがRedisの証明書作成に使用した認証局を信頼していることを確認してください。
4. オプションです。カスタム認証局を使用する場合は、カスタム認証局のグローバル設定を参照してください。

パスワードなしのRedisサーバー

Google Cloud Memorystoreなどの一部のRedisサービスでは、パスワードと関連するAUTH コマンドを使用しません。パスワードの使用と要求は、次の設定によって無効にすることができます：

global:
  redis:
    auth:
      enabled: false
    host: ${REDIS_PRIVATE_IP}
redis:
  enabled: false

レジストリ設定の構成

グローバルレジストリ設定は、global.registry キーの下にあります。

global:
  registry:
    bucket: registry
    certificate:
    httpSecret:
    notificationSecret:
    notifications: {}
    ## Settings used by other services, referencing registry:
    enabled: true
    host:
    api:
      protocol: http
      serviceName: registry
      port: 5000
    tokenIssuer: gitlab-issuer

bucket,certificate,httpSecret,notificationSecret の設定の詳細については、レジストリチャート内のドキュメントを参照してください。

enabled,host,api,tokenIssuer の詳細については、コマンドラインオプションと ウェブサービスのドキュメントを参照してください。

host は自動生成された外部レジストリホスト名参照を上書きするために使われます。

通知

この設定はレジストリ通知の設定に使用します。マップ（アップストリーム仕様に従う）を取り込みますが、機密ヘッダーをKubernetesシークレットとして提供する機能が追加されています。例えば、Authorizationヘッダが機密データを含み、他のヘッダが通常データを含む以下のスニペットを考えてみましょう：

global:
  registry:
    notifications:
      events:
        includereferences: true
      endpoints:
        - name: CustomListener
          url: https://mycustomlistener.com
          timeout: 500mx
          threshold: 5
          backoff: 1s
          headers:
            X-Random-Config: [plain direct]
            Authorization:
              secret: registry-authorization-header
              key: password

この例では、ヘッダX-Random-Config は通常のヘッダであり、その値はvalues.yaml ファイルまたは--set フラグでプレーンテキストで提供できます。しかし、ヘッダーAuthorization は機密データなので、Kubernetesシークレットからマウントすることが推奨されます。シークレットの構造の詳細については、シークレットドキュメントを参照してください。

Gitalyの設定

Gitalyのグローバル設定は、global.gitaly キーの下にあります。

global:
  gitaly:
    internal:
      names:
        - default
        - default2
    external:
      - name: node1
        hostname: node1.example.com
        port: 8075
    authToken:
      secret: gitaly-secret
      key: token
    tls:
      enabled: true
      secretName: gitlab-gitaly-tls

Gitalyホスト

GitalyはGitリポジトリへのハイレベルなRPCアクセスを提供するサービスで、GitLabが行うすべてのGitコールを処理します。

管理者は以下の方法でGitalyノードを使用することができます：

• Chartの内部で、Gitalyチャートを介してStatefulSet 。
• チャート外部、外部ペットとして。
• 内部ノードと外部ノードの両方を使用する混合環境。

新しいプロジェクトに使用するノードの管理については、リポジトリ保存パスのドキュメントを参照してください。

gitaly.host を指定した場合、gitaly.internal とgitaly.external のプロパティは無視されます。非推奨のGitaly設定を参照してください。

Gitaly認証トークンは、現時点では内部・外部を問わず、すべてのGitalyサービスで同一であることが期待されます。これらが一致していることを確認してください。詳細はイシュー#1992をご覧ください。

内部

internal キーは、現在のところ、Chartが管理するストレージ名のリストであるnames という1つのキーのみで構成されています。${releaseName}-gitaly-${ordinal}ordinal はnames リスト内のインデックスです。ダイナミック・プロビジョニングが有効になっている場合、PersistentVolumeClaim が一致します。

このリストのデフォルトは['default'] で、1 つのストレージ・パスに関連する 1 つのポッドを提供します。

gitaly.internal.names のエントリを追加または削除して、この項目を手動でスケーリングする必要があります。スケールダウンすると、他のノードに移動していないリポジトリは利用できなくなります。Gitaly チャートはStatefulSet であるため、動的にプロビジョニングされたディスクは再要求されません。つまり、データディスクは持続し、names リストにノードを再追加することで、セットが再びスケールアップされたときに、その上のデータにアクセスできます。

複数の内部ノードの設定サンプルは、examples フォルダにあります。

外部ノード

external キーは、クラスター外部のGitalyノード用の設定を提供します。このリストの各項目には3つのキーがあります：

• name:ストレージの名前。name: default 。
• hostname:Gitalyサービスのホスト。
• port(オプション) ホストに到達するためのポート番号。デフォルトは8075 です。
• tlsEnabled(オプション) この特定のエントリのglobal.gitaly.tls.enabled を上書きします。

外部のGitalyサービスを利用するための高度な設定ガイドを提供しています。また、examplesフォルダに複数の外部サービスの設定例があります。

外部のPraefectを使用して、可用性の高いGitalyサービスを提供することができます。クライアントから見た場合、両者の設定に違いはありません。

混合

内部Gitalyノードと外部Gitalyノードの両方を使用することは可能ですが、以下の点に注意してください：

• 常にdefault という名前のノードが必要で、内部はデフォルトでこれを提供します。
• 外部ノードが最初に生成され、次に内部ノードが生成されます。

内部ノードと外部ノードが混在する設定のサンプルは、examplesフォルダにあります。

authToken

Gitaly のauthToken 属性には、2つのサブキーがあります：

• secret は、プルするKubernetesSecret の名前を定義します。
• key は、authTokenを含む上記のシークレットのキーの名前を定義します。

すべてのGitalyノードは同じ認証トークンを共有する必要があります。

非推奨のGitaly設定

TLS設定

GitalyがTLS経由でサービスを提供するための設定は、Gitalyチャートのドキュメントに詳しく記載されています。

Praefectの設定

Praefect のグローバル設定は、global.praefect キーの下にあります。

Praefect はデフォルトで無効になっています。追加設定なしで有効にすると、3つのGitalyレプリカが作成され、PraefectデータベースをデフォルトのPostgreSQLインスタンス上に手動で作成する必要があります。

Praefectを有効にする

Praefect をデフォルト設定で有効にするには、global.praefect.enabled=true を設定します。

Praefectを使用してGitalyクラスターをオペレーションする方法の詳細については、Praefectのドキュメントを参照してください。

Praefectのグローバル設定

global:
  praefect:
    enabled: false
    virtualStorages:
    - name: default
      gitalyReplicas: 3
      maxUnavailable: 1
    dbSecret: {}
    psql: {}

MinIOの設定

GitLabグローバルMinIO設定はglobal.minio キーの下にあります。これらの設定の詳細については、MinIOチャート内のドキュメントを参照してください。

global:
  minio:
    enabled: true
    credentials: {}

appConfigの設定

Webservice、Sidekiq、Gitalyの各チャートは、global.appConfig キーで設定される複数の設定を共有しています。

global:
  appConfig:
    # cdnHost:
    contentSecurityPolicy:
      enabled: false
      report_only: true
      # directives: {}
    enableUsagePing: true
    enableSeatLink: true
    enableImpersonation: true
    applicationSettingsCacheSeconds: 60
    usernameChangingEnabled: true
    issueClosingPattern:
    defaultTheme:
    defaultProjectsFeatures:
      issues: true
      mergeRequests: true
      wiki: true
      snippets: true
      builds: true
      containerRegistry: true
    webhookTimeout:
    gravatar:
      plainUrl:
      sslUrl:
    extra:
      googleAnalyticsId:
      matomoUrl:
      matomoSiteId:
      matomoDisableCookies:
      oneTrustId:
      googleTagManagerNonceId:
      bizible:
    object_store:
      enabled: false
      proxy_download: true
      storage_options: {}
      connection: {}
    lfs:
      enabled: true
      proxy_download: true
      bucket: git-lfs
      connection: {}
    artifacts:
      enabled: true
      proxy_download: true
      bucket: gitlab-artifacts
      connection: {}
    uploads:
      enabled: true
      proxy_download: true
      bucket: gitlab-uploads
      connection: {}
    packages:
      enabled: true
      proxy_download: true
      bucket: gitlab-packages
      connection: {}
    externalDiffs:
      enabled:
      when:
      proxy_download: true
      bucket: gitlab-mr-diffs
      connection: {}
    terraformState:
      enabled: false
      bucket: gitlab-terraform-state
      connection: {}
    ciSecureFiles:
      enabled: false
      bucket: gitlab-ci-secure-files
      connection: {}
    dependencyProxy:
      enabled: false
      bucket: gitlab-dependency-proxy
      connection: {}
    backups:
      bucket: gitlab-backups
    microsoft_graph_mailer:
      enabled: false
      user_id: "YOUR-USER-ID"
      tenant: "YOUR-TENANT-ID"
      client_id: "YOUR-CLIENT-ID"
      client_secret:
        secret:
        key: secret
      azure_ad_endpoint: "https://login.microsoftonline.com"
      graph_endpoint: "https://graph.microsoft.com"
    incomingEmail:
      enabled: false
      address: ""
      host: "imap.gmail.com"
      port: 993
      ssl: true
      startTls: false
      user: ""
      password:
        secret:
        key: password
      mailbox: inbox
      idleTimeout: 60
      inboxMethod: "imap"
      clientSecret:
        key: secret
      pollInterval: 60
      deliveryMethod: webhook
      authToken: {}

    serviceDeskEmail:
      enabled: false
      address: ""
      host: "imap.gmail.com"
      port: 993
      ssl: true
      startTls: false
      user: ""
      password:
        secret:
        key: password
      mailbox: inbox
      idleTimeout: 60
      inboxMethod: "imap"
      clientSecret:
        key: secret
      pollInterval: 60
      deliveryMethod: webhook
      authToken: {}

    cron_jobs: {}
    sentry:
      enabled: false
      dsn:
      clientside_dsn:
      environment:
    gitlab_docs:
      enabled: false
      host: ""
    smartcard:
      enabled: false
      CASecret:
      clientCertificateRequiredHost:
    sidekiq:
      routingRules: []

一般的なアプリケーション設定

Railsアプリケーションの一般的なプロパティを調整するために使用できるappConfig ：

コンテンツセキュリティポリシー

Content Security Policy(CSP) を設定することで、JavaScriptのクロスサイトスクリプティング(XSS) 攻撃を阻止することができます。設定の詳細についてはGitLabのドキュメントを参照してください。コンテンツセキュリティポリシーのドキュメント

GitLabは自動的にCSPのセキュアなデフォルト値を提供します。

global:
  appConfig:
    contentSecurityPolicy:
      enabled: true
      report_only: false

カスタムCSPを追加するには

global:
  appConfig:
    contentSecurityPolicy:
      enabled: true
      report_only: false
      directives:
        default_src: "'self'"
        script_src: "'self' 'unsafe-inline' 'unsafe-eval' https://www.recaptcha.net https://apis.google.com"
        frame_ancestors: "'self'"
        frame_src: "'self' https://www.recaptcha.net/ https://content.googleapis.com https://content-compute.googleapis.com https://content-cloudbilling.googleapis.com https://content-cloudresourcemanager.googleapis.com"
        img_src: "* data: blob:"
        style_src: "'self' 'unsafe-inline'"

CSPルールの設定を誤ると、GitLabが正しく動作しなくなる可能性があります。ポリシーをロールアウトする前に、report_only をtrue に変更して設定をテストすることもできます。

defaultProjectsFeatures

新しいプロジェクトをデフォルトでそれぞれの機能で作成するかどうかを決めるフラグ。すべてのフラグのデフォルトはtrueです。

defaultProjectsFeatures:
  issues: true
  mergeRequests: true
  wiki: true
  snippets: true
  builds: true
  containerRegistry: true

Gravatar/Libravatar の設定

デフォルトでは、Chartはgravatar.comで利用可能なGravatarアバターサービスで動作します。しかし、必要に応じてカスタムのLibravatarサービスを使用することもできます：

GitLabインスタンスへのAnalyticsサービスのフック

Google Analytics や Matomo のような Analytics サービスの設定はappConfig 以下のextra キーで定義します：

統合オブジェクトストレージ

オブジェクトストレージの個別の設定方法を説明する以下のセクションに加えて、これらの項目の共有設定の使用を容易にするために、オブジェクトストレージの統合設定を追加しました。object_store を利用することで、一度設定すれば、connection プロパティで個別に設定されていないすべてのオブジェクトストレージのバック機能に使用さ connectionれます。

  enabled: true
  proxy_download: true
  storage_options:
  connection:
    secret:
    key:

プロパティ構造は共有されており、ここにあるすべてのプロパティは以下の個々の項目でオーバーライドできます。connection のプロパティ構造は同じです。

注意 bucket 、enabled、proxy_download プロパティは、デフォルト値から逸脱したい場合、項目ごとに設定しなければならない唯一のプロパティです (global.appConfig.artifacts.bucket、…)。

接続に AWS プロバイダを使用する場合（付属のMinIOのようなS3互換プロバイダ）、GitLab Workhorseはすべてのストレージ関連のアップロードをオフロードすることができます。この統合設定を使用すると、自動的に有効になります。

バケットの指定

それぞれのオブジェクトタイプは、異なるバケットに保存する必要があります。デフォルトでは、GitLabはそれぞれのタイプにこれらのバケット名を使います：

これらのデフォルトを使用するか、バケツ名を設定することができます：

--set global.appConfig.artifacts.bucket=<BUCKET NAME> \
--set global.appConfig.lfs.bucket=<BUCKET NAME> \
--set global.appConfig.packages.bucket=<BUCKET NAME> \
--set global.appConfig.uploads.bucket=<BUCKET NAME> \
--set global.appConfig.externalDiffs.bucket=<BUCKET NAME> \
--set global.appConfig.terraformState.bucket=<BUCKET NAME> \
--set global.appConfig.ciSecureFiles.bucket=<BUCKET NAME> \
--set global.appConfig.dependencyProxy.bucket=<BUCKET NAME>

ストレージオプション

GitLab 13.4で導入されました。

storage_options はS3 Server Side Encryption の設定に使用します。

S3バケットにデフォルトの暗号化を設定するのが暗号化を有効にする最も簡単な方法ですが、暗号化されたオブジェクトだけがアップロードされるようにバケットポリシーを設定したい場合もあるでしょう。そのためには、storage_options の設定セクションで適切な暗号化ヘッダを送信するように GitLab を設定する必要があります：

使用例：

  enabled: true
  proxy_download: true
  connection:
    secret: gitlab-rails-storage
    key: connection
  storage_options:
    server_side_encryption: aws:kms
    server_side_encryption_kms_key_id: arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab

LFS、アーティファクト、アップロード、パッケージ、外部MR差分、依存プロキシ

これらの設定の詳細は以下のとおりです。bucket プロパティのデフォルト値を除けば、構造的に同じであるため、個別にドキュメントは繰り返しません。

  enabled: true
  proxy_download: true
  bucket:
  connection:
    secret:
    key:

接続

connection プロパティは Kubernetes Secret に移行されました。このシークレットの内容はYAML形式のファイルである必要があります。デフォルトは{} で、global.minio.enabled がtrueの場合は無視されます。

このプロパティには2つのサブキーがあります:secret とkey 。

• secret はKubernetesシークレットの名前です。この値は、外部オブジェクトストレージを使用するために必要です。
• key はYAMLブロックを格納するシークレット内のキーの名前です。デフォルトはconnection です。

有効な設定キーはGitLab ジョブアーティファクト管理ドキュメントにあります。これはFogにマッチし、プロバイダモジュールによって異なります。

AWSとGoogleプロバイダの例はexamples/objectstorageにあります。

• rails.s3.yaml
• rails.gcs.yaml
• rails.azurerm.yaml

connection の内容を含む YAML ファイルが作成されたら、このファイルを使用して Kubernetes でシークレットを作成します。

kubectl create secret generic gitlab-rails-storage \
    --from-file=connection=rails.yaml

とき（外部MR Diffの場合のみ）

externalDiffs 設定には、特定の差分をオブジェクトストレージに条件付きで保存するためのキーwhen が追加されています。この設定は、Railsコードによってデフォルト値が割り当てられるように、Chartのデフォルトでは空のままになっています。

cdn (CIアーティファクトのみ)

artifacts 設定には、Google Cloud Storage バケットの前に Google CDN を設定するためのキーcdn が追加されています。

受信メールの設定

受信メールの設定は、コマンドラインオプションのページで説明されています。

KASの設定

カスタムシークレット

Helm の--set variable オプションを使うことで、KASsecret の名前とkey をカスタマイズすることができます：

--set global.appConfig.gitlab_kas.secret=custom-secret-name \
--set global.appConfig.gitlab_kas.key=custom-secret-key \

を使うか、values.yaml を設定してください：

global:
  appConfig:
    gitlab_kas:
      secret: "custom-secret-name"
      key: "custom-secret-key"

シークレットの値をカスタマイズしたい場合は、シークレットのドキュメントを参照してください。

カスタムURL

GitLabバックエンドがKASに使用するURLは、Helmの--set variable オプションを使ってカスタマイズすることができます：

--set global.appConfig.gitlab_kas.externalUrl="wss://custom-kas-url.example.com" \
--set global.appConfig.gitlab_kas.internalUrl="grpc://custom-internal-url" \

を使うか、values.yaml を設定してください：

global:
  appConfig:
    gitlab_kas:
      externalUrl: "wss://custom-kas-url.example.com"
      internalUrl: "grpc://custom-internal-url"

外部KAS

GitLab バックエンドは、明示的に有効にして必要な URL を設定することで、外部の KAS サーバー（Chart で管理されていないもの）を認識できるようになります。これは Helm の--set variable オプションを使って行います：

--set global.appConfig.gitlab_kas.enabled=true \
--set global.appConfig.gitlab_kas.externalUrl="wss://custom-kas-url.example.com" \
--set global.appConfig.gitlab_kas.internalUrl="grpc://custom-internal-url" \

を使うか、values.yaml を設定してください：

global:
  appConfig:
    gitlab_kas:
      enabled: true
      externalUrl: "wss://custom-kas-url.example.com"
      internalUrl: "grpc://custom-internal-url"

TLS設定

KAS はkas ポッドと他の GitLab Chart コンポーネント間の TLS 通信をサポートしています。

前提条件：

• GitLab 15.5.1以降を使用してください。GitLabのバージョンはglobal.gitlabVersion: <version> で設定できます。 最初のデプロイ後に強制的にイメージを更新する必要がある場合は、global.image.pullPolicy: Always も設定してください。
• kas ポッドが信頼する認証局と証明書を作成します。

作成した証明書を使用するようにkas を設定するには、以下の値を設定します。

例えば、あなたのChartをデプロイするために、values.yaml ファイルで以下を使用することができます：

.internal-ca: &internal-ca gitlab-internal-tls-ca # The secret name you used to share your TLS CA.
.internal-tls: &internal-tls gitlab-internal-tls # The secret name you used to share your TLS certificate.

global:
  certificates:
    customCAs:
    - secret: *internal-ca
  hosts:
    domain: gitlab.example.com # Your gitlab domain
  kas:
    tls:
      enabled: true
      secretName: *internal-tls
      caSecretName: *internal-ca

推奨レビュアー設定

オプションで、Suggested Reviewerssecret の名前とkey をカスタマイズできます。Helm の--set variable オプションを使います：

--set global.appConfig.suggested_reviewers.secret=custom-secret-name \
--set global.appConfig.suggested_reviewers.key=custom-secret-key \

を使うか、values.yaml を設定してください：

global:
  appConfig:
    suggested_reviewers:
      secret: "custom-secret-name"
      key: "custom-secret-key"

シークレットの値をカスタマイズしたい場合は、シークレットのドキュメントを参照してください。

LDAP

ldap.servers 設定により、LDAPユーザー認証を設定できます。これはマップとして表示され、ソースからのインストールと同様にgitlab.yml で適切な LDAP サーバ設定に変換されます。

パスワードの設定は、パスワードを保持するsecret を指定することで行えます。このパスワードは実行時にGitLabの設定に注入されます。

設定スニペットの例です：

ldap:
  preventSignin: false
  servers:
    # 'main' is the GitLab 'provider ID' of this LDAP server
    main:
      label: 'LDAP'
      host: '_your_ldap_server'
      port: 636
      uid: 'sAMAccountName'
      bind_dn: 'cn=administrator,cn=Users,dc=domain,dc=net'
      base: 'dc=domain,dc=net'
      password:
        secret: my-ldap-password-secret
        key: the-key-containing-the-password

グローバルチャートを使用する場合の--set 設定項目の例：

--set global.appConfig.ldap.servers.main.label='LDAP' \
--set global.appConfig.ldap.servers.main.host='your_ldap_server' \
--set global.appConfig.ldap.servers.main.port='636' \
--set global.appConfig.ldap.servers.main.uid='sAMAccountName' \
--set global.appConfig.ldap.servers.main.bind_dn='cn=administrator\,cn=Users\,dc=domain\,dc=net' \
--set global.appConfig.ldap.servers.main.base='dc=domain\,dc=net' \
--set global.appConfig.ldap.servers.main.password.secret='my-ldap-password-secret' \
--set global.appConfig.ldap.servers.main.password.key='the-key-containing-the-password'

LDAP ウェブサインインを無効にします。

SAML などの代替手段を使用する場合は、Web UI で LDAP 認証情報を使用しないようにすると便利です。これにより、グループ同期に LDAP を使用できるようになり、同時に SAML ID プロバイダがカスタム 2FA などの追加チェックを処理できるようになります。

LDAP Web サインインを無効にすると、ユーザーにはサインイン・ページに LDAP タブが表示されなくなります。これは、Git へのアクセスに LDAP 認証情報を使用することを無効にするものではありません。

ウェブサインインに LDAP を使わないようにするには、global.appConfig.ldap.preventSignin: true を設定します。

カスタムCAまたは自己署名LDAP証明書の使用

LDAPサーバーがカスタムCA証明書または自己署名証明書を使用する場合は、次のことが必要です：

1. カスタムCA/自己署名証明書がクラスター/ネームスペースにシークレットまたはConfigMapとして作成されていることを確認します：

   # Secret
   kubectl -n gitlab create secret generic my-custom-ca-secret --from-file=unique_name.crt=my-custom-ca.pem
      
   # ConfigMap
   kubectl -n gitlab create configmap my-custom-ca-configmap --from-file=unique_name.crt=my-custom-ca.pem
   

2. 次に

   # Configure a custom CA from a Secret
   --set global.certificates.customCAs[0].secret=my-custom-ca-secret
      
   # Or from a ConfigMap
   --set global.certificates.customCAs[0].configMap=my-custom-ca-configmap
      
   # Configure the LDAP integration to trust the custom CA
   --set global.appConfig.ldap.servers.main.ca_file=/etc/ssl/certs/unique_name.pem
   

これにより、CA証明書が/etc/ssl/certs/unique_name.pem 、関連するポッドにマウントされ、LDAP設定での使用が指定されます。

詳細はカスタム認証作成者を参照してください。

DuoAuth

これらの設定を使用して、Duoによる2要素認証（2FA）を有効にします。

global:
  appConfig:
    duoAuth:
      enabled:
      hostname:
      integrationKey:
      secretKey:
      #  secret:
      #  key:

Duo 秘密キーの設定

GitLab Helm チャートで Duo 認証インテグレーションを設定するには、global.appConfig.duoAuth.secretKey.secret 設定に Duo 認証 secret_key 値を含むシークレットを指定する必要があります。

Duo アカウントを保存する Kubernetes シークレットオブジェクトを作成するにはsecretKey 、コマンドラインから実行します：

kubectl create secret generic <secret_object_name> --from-literal=secretKey=<duo_secret_key_value>

オムニ認証

GitLabはOmniAuthを活用し、Twitter、GitHub、Google、その他の一般的なサービスを使ってサインインすることができます。詳しいドキュメントはGitLabのOmniAuthドキュメントをご覧ください。

omniauth:
  enabled: false
  autoSignInWithProvider:
  syncProfileFromProvider: []
  syncProfileAttributes: ['email']
  allowSingleSignOn: ['saml']
  blockAutoCreatedUsers: true
  autoLinkLdapUser: false
  autoLinkSamlUser: false
  autoLinkUser: ['saml']
  externalProviders: []
  allowBypassTwoFactor: []
  providers: []
  # - secret: gitlab-google-oauth2
  #   key: provider

プロバイダ

providers は、ソースからインストールしたときと同じようにgitlab.yml に入力するために使われるマップの配列として表示されます。サポートされるプロバイダの選択については GitLab ドキュメントを参照してください。デフォルトは[]です。

このプロパティには2つのサブキーがあります:secret とkey ：

• secret:(必須)プロバイダブロックを含む KubernetesSecret の名前。
• key:(オプション)プロバイダブロックを含むSecret のキーの名前。デフォルトはprovider

OmniAuth Providers で説明されているように、これらのエントリのSecret には YAML または JSON 形式のブロックが含まれています。このシークレットを作成するには、これらの項目を取得するための適切な手順に従って、YAML または JSON ファイルを作成します。

Google OAuth2 の設定例：

name: google_oauth2
label: Google
app_id: 'APP ID'
app_secret: 'APP SECRET'
args:
  access_type: offline
  approval_prompt: ''

SAMLの設定例：

name: saml
label: 'SAML'
args:
  assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback'
  idp_cert_fingerprint: 'xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx'
  idp_sso_target_url: 'https://SAML_IDP/app/xxxxxxxxx/xxxxxxxxx/sso/saml'
  issuer: 'https://gitlab.example.com'
  name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient'

Microsoft Azure OAuth 2.0 OmniAuth プロバイダ設定例：

name: azure_activedirectory_v2
label: Azure
args:
  client_id: '<CLIENT_ID>'
  client_secret: '<CLIENT_SECRET>'
  tenant_id: '<TENANT_ID>'

グループ SAML設定例：

name: group_saml

このコンテンツをprovider.yaml として保存し、そこからシークレットを作成することができます：

kubectl create secret generic -n NAMESPACE SECRET_NAME --from-file=provider=provider.yaml

一旦作成されると、providers 、設定にマップを提供することで有効になります：

omniauth:
  providers:
    - secret: gitlab-google-oauth2
    - secret: azure_activedirectory_v2
    - secret: gitlab-azure-oauth2
    - secret: gitlab-cas3

設定例--set グローバルチャートを使用する場合の項目：

--set global.appConfig.omniauth.providers[0].secret=gitlab-google-oauth2 \

--set の引数を使うのは複雑なので、ユーザーは-f omniauth.yaml でhelm に渡される YAML スニペットを使いたいと思うかもしれません。

cronジョブ関連の設定

Sidekiqには、cronスタイルのスケジュールを使用して定期的に実行するように設定できるメンテナンスジョブがあります。以下にいくつかの例を示します。その他のジョブ例については、サンプルgitlab.yml のcron_jobs とee_cron_jobs セクションを参照してください。

これらの設定は、Sidekiq、Webservice（UIでツールチップを表示するため）、Toolbox（デバッグ目的）のポッド間で共有されます。

global:
  appConfig:
    cron_jobs:
      stuck_ci_jobs_worker:
        cron: "0 * * * *"
      pipeline_schedule_worker:
        cron: "19 * * * *"
      expire_build_artifacts_worker:
        cron: "*/7 * * * *"

Sentryの設定

SentryによるGitLabエラーレポートを有効にするには、これらの設定を使用します。

global:
  appConfig:
    sentry:
      enabled:
      dsn:
      clientside_dsn:
      environment:

gitlab_docs 設定

gitlab_docsを有効にするには、これらの設定を使用します。

global:
  appConfig:
    gitlab_docs:
      enabled:
      host:

スマートカード認証設定

global:
  appConfig:
    smartcard:
      enabled: false
      CASecret:
      clientCertificateRequiredHost:
      sanExtensions: false
      requiredForGitAccess: false

Sidekiqルーティングルール設定

GitLabは、ジョブをスケジュールする前にワーカーから任意のキューにルーティングすることをサポートしています。Sidekiqクライアントは設定されたルーティングルールのリストとジョブを照合します。ルールは最初のものから最後のものへと評価され、指定されたワーカーにマッチするものが見つかり次第、そのワーカーの処理は停止されます（最初にマッチしたものが勝ちます）。ワーカーがどのルールにもマッチしない場合は、ワーカー名から生成されたキュー名にフォールバックします。

デフォルトでは、ルーティングルールは設定されず (あるいは空の配列で示され)、すべてのジョブはワーカー名から生成されたキューにルーティングされます。

ルーティングルールリストは、クエリと対応するキューのタプルを並べた配列です：

• クエリはワーカーマッチングクエリ構文に従います。
• <queue_name> は、sidekiq.pods の下で定義された有効な Sidekiq キュー名sidekiq.pods[].queues と一致しなければなりません。キュー名がnil、または空文字列の場合、ワーカーは、代わりにワーカー名で生成されたキューにルーティングされます。

クエリは、すべてのワーカーにマッチするワイルドカードマッチング* をサポートしています。その結果、ワイルドカードクエリはリストの最後になければなりません：

global:
  appConfig:
    sidekiq:
      routingRules:
      - ["resource_boundary=cpu", "cpu-boundary"]
      - ["feature_category=pages", null]
      - ["feature_category=search", "search"]
      - ["feature_category=memory|resource_boundary=memory", "memory-bound"]
      - ["*", "default"]

Rails の設定

GitLab スイートの大部分は Rails をベースにしています。そのため、プロジェクト内の多くのコンテナがこのスタックでオペレーションを行っています。これらの設定はすべてのコンテナに適用され、グローバルに設定したり個別に設定したりするための簡単なアクセス方法を提供します。

global:
  rails:
    bootsnap:
      enabled: true

Workhorse の設定

GitLabスイートのいくつかのコンポーネントはGitLab Workhorseを介してAPIと話します。これは現在Webserviceチャートの一部です。これらの設定はGitLab Workhorseにコンタクトする必要のある全てのChartで消費され、グローバルに、または個別に設定する簡単なアクセスを提供します。

global:
  workhorse:
    serviceName: webservice-default
    host: api.example.com
    port: 8181

ブートスナップキャッシュ

私たちのRailsコードベースはShopifyのBootsnapGemを利用しています。ここでの設定は、その動作を設定するために使用します。

bootsnap.enabled はこの機能のアクティビティを制御します。デフォルトはtrue です。

テストによると、Bootsnap を有効にすると、アプリケーション全体のパフォーマンスが向上しました。プリコンパイルされたキャッシュが利用可能な場合、一部のアプリケーションコンテナでは 33% を超える向上が見られます。現時点では、GitLabはこのコンパイル済みキャッシュをコンテナに同梱していないため、14%しか向上していません。プリコンパイルされたキャッシュがないと、各ポッドの初回起動時に小さなIOの激しいスパイクが発生します。このため、イシューとなる環境ではBootsnapの使用を無効にする方法を公開しました。

可能であれば、これを有効にしておくことをお勧めします。

GitLab Shell の設定

GitLab Shellのグローバル設定にはいくつかの項目があります。

global:
  shell:
    port:
    authToken: {}
    hostKeys: {}
    tcp:
      proxyProtocol: false

ポート

Ingress が SSH トラフィックを渡す際に使用するポートや、GitLab からglobal.shell.port 経由で提供される SSH URL で使用するポートを制御できます。これはサービスがリッスンするポートや、プロジェクト UI で提供される SSH クローン URL に反映されます。

global:
  shell:
    port: 32022

global.shell.port とnginx-ingress.controller.service.type=NodePort を組み合わせて、NGINX コントローラのサービスオブジェクトに NodePort を設定することができます。nginx-ingress.controller.service.nodePorts.gitlab-shell が設定されている場合、NGINX の NodePort を設定する際にglobal.shell.port を上書きすることに注意してください。

global:
  shell:
    port: 32022

nginx-ingress:
  controller:
    service:
      type: NodePort

TCP プロキシプロトコル

プロキシプロトコルヘッダを追加するアップストリームプロキシからの接続を適切に処理するために、SSH Ingressでプロキシプロトコルの処理を有効にすることができます。こうすることで、SSHが追加のヘッダを受け取らないようになり、SSHが壊れることはありません。

プロキシプロトコルの処理を有効にする必要がある一般的な環境として、クラスターへのインバウンド接続をELBで処理するAWSを使用する場合があります。AWSのレイヤー4ロードバランサーの例を参考にして、適切に設定してください。

global:
  shell:
    tcp:
      proxyProtocol: true # default false

GitLab Pages の設定

他のChartで使われるグローバルなGitLab Pagesの設定は、global.pages キーの下に文書化されています。

global:
  pages:
    enabled:
    accessControl:
    path:
    host:
    port:
    https:
    externalHttp:
    externalHttps:
    artifactsServer:
    objectStore:
      enabled:
      bucket:
      proxy_download: true
      connection: {}
        secret:
        key:
    localStore:
      enabled: false
      path:
    apiSecret: {}
      secret:
      key:

ウェブサービスの設定

グローバル Webservice 設定 (他の Chart でも使用) はglobal.webservice キーの下にあります。

global:
  webservice:
    workerTimeout: 60

ワーカータイムアウト

ウェブサービスマスタープロセスによってウェブサービスワーカープロセスが強制終了されるリクエストタイムアウト (秒単位) を設定します。デフォルト値は 60 秒です。

global.webservice.workerTimeout の設定は最大リクエスト時間には影響しません。最大リクエスト時間を設定するには、以下の環境変数を設定してください：

gitlab:
  webservice:
    workerTimeout: 60
    extraEnv:
      GITLAB_RAILS_RACK_TIMEOUT: "60"
      GITLAB_RAILS_WAIT_TIMEOUT: "90" 

カスタム認証局

ユーザーによっては、内部で発行された SSL 証明書を TLS サービスに使用する場合など、カスタム認証局を追加する必要があるかもしれません。この機能を提供するために、シークレットやコンフィグマップを通じて、これらのカスタムルート認証局をアプリケーションに注入するメカニズムを提供しています。

シークレットまたは ConfigMap を作成するには、以下の手順に従います：

# Create a Secret from a certificate file
kubectl create secret generic secret-custom-ca --from-file=unique_name.crt=/path/to/cert

# Create a ConfigMap from a certificate file
kubectl create configmap cm-custom-ca --from-file=unique_name.crt=/path/to/cert

シークレットまたは ConfigMap、またはその両方を設定するには、グローバルでそれらを指定します：

global:
  certificates:
    customCAs:
      - secret: secret-custom-CAs           # Mount all keys of a Secret
      - secret: secret-custom-CAs           # Mount only the specified keys of a Secret
        keys:
          - unique_name.crt
      - configMap: cm-custom-CAs            # Mount all keys of a ConfigMap
      - configMap: cm-custom-CAs            # Mount only the specified keys of a ConfigMap
        keys:
          - unique_name_1.crt
          - unique_name_2.crt

PEMエンコードされたCA証明書を保持する任意の数のキーを含む、任意の数のシークレットまたはConfigMapを提供することができます。これらは、global.certificates.customCAs の下のエントリとして設定されます。keys: に特定の鍵のリストが提供されない限り、すべての鍵がマウントされます。すべてのシークレットとコンフィグマップにわたってマウントされる鍵は一意でなければなりません。シークレットとコンフィグマップにはどのような名前を付けてもかまいませんが、 重複する鍵名を使ってはいけません。

アプリケーションリソース

GitLabはオプションでApplicationリソースを含めることができ、クラスター内でGitLabアプリケーションを識別するために作成することができます。アプリケーションCRD、バージョンv1beta1、すでにクラスターにデプロイされている必要があります。

有効にするには、global.application.create をtrue に設定します：

global:
  application:
    create: true

Google GKE Marketplace などの一部の環境では、ClusterRole リソースの作成が許可されていません。アプリケーションカスタムリソース定義とCloud Native GitLabに同梱されている関連ChartでClusterRoleコンポーネントを無効にするには、以下の値を設定します。

global:
  application:
    allowClusterRoles: false
nginx:
  controller:
    scope:
      enabled: true
gitlab-runner:
  rbac:
    clusterWideAccess: false
certmanager:
  install: false

GitLabベースイメージ

GitLab Helm chartは様々な初期化タスクに共通のGitLabベースイメージを使用します。このイメージはUBIビルドをサポートし、他のイメージとレイヤーを共有します。現在は廃止されたbusyboxイメージに取って代わるものです。

サービスアカウント

GitLab Helmチャートでは、カスタムサービスアカウントを使ってポッドを実行することができます。この設定はglobal.serviceAccount で行います：

global:
  serviceAccount:
    enabled: false
    create: true
    annotations: {}
    ## Name to be used for serviceAccount, otherwise defaults to chart fullname
    # name:

• global.serviceAccount.enabled の設定により、各コンポーネントの ServiceAccount への参照をspec.serviceAccountName 経由で制御します。
• global.serviceAccount.create を設定すると、Helm 経由で ServiceAccount オブジェクトの作成を制御します。
• global.serviceAccount.name を設定することで、ServiceAccount オブジェクト名と各コンポーネントが参照する名前を制御します。

注釈

カスタムアノテーションは、デプロイ、サービス、Ingressオブジェクトに適用できます。

global:
  deployment:
    annotations:
      environment: production

  service:
    annotations:
      environment: production

  ingress:
    annotations:
      environment: production

ノードセレクタ

カスタムnodeSelectorは、すべてのコンポーネントにグローバルに適用できます。グローバルなデフォルトは、各サブチャートで個別に上書きすることもできます。

global:
  nodeSelector:
    disktype: ssd

注意: 外部で管理されているチャートは、現時点ではglobal.nodeSelector を尊重しないため、利用可能なチャート値に基づいて個別に設定する必要があります。これには Prometheus、cert-manager、Redis などが含まれます。

ラベル

一般的なラベル

ラベルは、設定common.labels を使って、さまざまなオブジェクトによって作成されるほぼすべてのオブジェクトに適用することができます。これは、global キーの下に適用することも、特定のChartの設定の下に適用することもできます。例

global:
  common:
    labels:
      environment: production
gitlab:
  gitlab-shell:
    common:
      labels:
        foo: bar

上記の設定例では、Helm チャートによってデプロイされたほぼすべてのコンポーネントにラベルセットenvironment: production が提供されます。GitLab Shell チャートのすべてのコンポーネントは、ラベルセットfoo: bar を受け取ります。いくつかのチャートでは、さらにネストを追加することができます。例えば、Sidekiq チャートやWebservices チャートでは、設定のニーズに応じてデプロイを追加することができます：

gitlab:
  sidekiq:
    pods:
      - name: pod-0
        common:
          labels:
            baz: bat

上記の例では、pod-0 Sidekiqデプロイに関連付けられているすべてのコンポー ネントも、ラベルセットbaz: bat を受け取ります。詳細については、Sidekiq および Webservice チャートを参照してください。

私たちが依存しているいくつかのChartは、このラベル設定から除外されています。GitLabコンポーネントのサブチャートのみが、これらの余分なラベルを受け取ります。

ポッド

カスタムラベルは様々なデプロイやジョブに適用できます。これらのラベルは、このHelm Chartで作成された既存のラベルや設定済みのラベルを補足するものです。これらの補足ラベルはmatchSelectors には利用されません。

global:
  pod:
    labels:
      environment: production

サービス

カスタムラベルをサービスに適用することができます。これらのラベルは、このHelm Chartによって構築された既存のラベルや設定済みのラベルを補足するものです。

global:
  service:
    labels:
      environment: production

トレーシング

GitLab Helm チャートはトレースをサポートしており、次のようにして設定できます：

global:
  tracing:
    connection:
      string: 'opentracing://jaeger?http_endpoint=http%3A%2F%2Fjaeger.example.com%3A14268%2Fapi%2Ftraces&sampler=const&sampler_param=1'
    urlTemplate: 'http://jaeger-ui.example.com/search?service={{ service }}&tags=%7B"correlation_id"%3A"{{ correlation_id }}"%7D'

• global.tracing.connection.string で設定することができます。詳しくはGitLab トレースドキュメントをご覧ください。
• global.tracing.urlTemplate はGitLabパフォーマンスバーのトレース情報URLレンダリングのテンプレートとして使われます。

extraEnv

extraEnv を使うと、GitLab チャート (charts/gitlab/charts) 経由でデプロイされたポッド内のすべてのコンテナで追加の環境変数を公開することができます。グローバルレベルで設定された追加環境変数は、Chartレベルで設定されたものにマージされます。

以下はextraEnv の使用例です：

global:
  extraEnv:
    SOME_KEY: some_value
    SOME_OTHER_KEY: some_other_value

追加EnvFrom

extraEnvFrom を使用すると、ポッド内のすべてのコンテナで、他のデータソースからの追加の環境変数を公開できます。追加環境変数は、global レベル (global.extraEnvFrom) およびサブチャートレベル (<subchart_name>.extraEnvFrom) で設定できます。

SidekiqチャートとWebserviceチャートは、追加のローカル・オーバーライドをサポートしています。詳細はそれぞれのドキュメントを参照してください。

以下はextraEnvFrom の使用例です：

global:
  extraEnvFrom:
    MY_NODE_NAME:
      fieldRef:
        fieldPath: spec.nodeName
    MY_CPU_REQUEST:
      resourceFieldRef:
        containerName: test-container
        resource: requests.cpu
gitlab:
  kas:
    extraEnvFrom:
      CONFIG_STRING:
        configMapKeyRef:
          name: useful-config
          key: some-string
          # optional: boolean

OAuthの設定

OAuthインテグレーションは、それをサポートするサービスに対してすぐに設定されます。global.oauth で指定されたサービスは、デプロイ中にGitLabのOAuthクライアントアプリケーションとして自動的に登録されます。デフォルトでは、アクセスコントロールが有効になっている場合、このリストにはGitLab Pagesが含まれます。

global:
  oauth:
    gitlab-pages: {}
    # secret
    # appid
    # appsecret
    # redirectUri
    # authScope

シークレットの詳細については、シークレットドキュメントを確認してください。

Kerberos

GitLab HelmチャートでKerberosインテグレーションを設定するには、GitLabホストのサービスプリンシパルを持つKerberoskeytabを含むシークレットをglobal.appConfig.kerberos.keytab.secret 。Kerberos管理者がkeytabファイルを作成する手助けをしてくれます。

次のスニペットでシークレットを作成することができます（gitlab ネームスペースにチャートをインストールし、gitlab.keytab がサービスプリンシパルを含む keytab ファイルであると仮定します）：

kubectl create secret generic gitlab-kerberos-keytab --namespace=gitlab --from-file=keytab=./gitlab.keytab

Git の Kerberos インテグレーションを有効にするには、global.appConfig.kerberos.enabled=true を設定します。また、kerberos プロバイダを、ブラウザでチケットベースの認証を行うOmniAuthプロバイダのリストに追加します。

false のままにしておいても、Helm チャートはkeytab を toolbox、Sidekiq、webservice ポッドにマウントします。これは Kerberos 用に手動設定されたOmniAuth 設定で使用できます。

Kerberos クライアントの設定はglobal.appConfig.kerberos.krb5Config で提供できます。

global:
  appConfig:
    kerberos:
      enabled: true
      keytab:
        secret: gitlab-kerberos-keytab
        key: keytab
      servicePrincipalName: ""
      krb5Config: |
        [libdefaults]
            default_realm = EXAMPLE.COM
      dedicatedPort:
        enabled: false
        port: 8443
        https: true
      simpleLdapLinkingAllowedRealms:
        - example.com

詳細はKerberosのドキュメントを確認してください。

Kerberos専用ポート

GitLabは、HTTPプロトコルでGitオペレーションを行う際にKerberosネゴシエーションのための専用ポートを使うことをサポートしています。これは、認証交換の際にnegotiate ヘッダが提示された場合にGitがBasic認証にフォールバックしてしまう制限を回避するためです。

GitLab RunnerヘルパーはGitLabからクローンするためにURL内の認証に依存しているためです。

これはglobal.appConfig.kerberos.dedicatedPort の設定で有効にすることができます：

global:
  appConfig:
    kerberos:
      [...]
      dedicatedPort:
        enabled: true
        port: 8443
        https: true

GitLab UI に Kerberos ネゴシエーション専用のクローン URL を追加できます。https: true の設定はURL生成のみで、追加のTLS設定は公開されません。TLSはIngress for GitLabで終了され、設定されます。

LDAPカスタム許可レルム

global.appConfig.kerberos.simpleLdapLinkingAllowedRealms を使用して、ユーザーの LDAP DN がユーザーの Kerberos レルムと一致しない場合に、LDAP と Kerberos ID をリンクするために使用するドメインのセットを指定できます。詳細については、Kerberosインテグレーション・ドキュメントの「Custom allowed realm」セクションを参照してください。

送信メール

送信メールの設定は、global.smtp.* 、global.appConfig.microsoft_graph_mailer.* 、global.email.* 。

global:
  email:
    display_name: 'GitLab'
    from: 'gitlab@example.com'
    reply_to: 'noreply@example.com'
  smtp:
    enabled: true
    address: 'smtp.example.com'
    tls: true
    authentication: 'plain'
    user_name: 'example'
    password:
      secret: 'smtp-password'
      key: 'password'
  appConfig:
    microsoft_graph_mailer:
      enabled: false
      user_id: "YOUR-USER-ID"
      tenant: "YOUR-TENANT-ID"
      client_id: "YOUR-CLIENT-ID"
      client_secret:
        secret:
        key: secret
      azure_ad_endpoint: "https://login.microsoftonline.com"
      graph_endpoint: "https://graph.microsoft.com"

利用可能な設定オプションの詳細については、送信メールのドキュメントを参照してください。

より詳細な例はLinux package SMTP settings documentation にあります。

プラットフォーム

platform キーは、GKE や EKS のような特定のプラットフォームをターゲットにした特定の機能のために予約されています。

親和性

Affinity 設定は、global.antiAffinity とglobal.affinity から利用できます。Affinityを使用すると、ノードラベルまたはノード上ですでに実行されているポッドのラベルに基づいて、ポッドがスケジューリングされる対象となるノードを制限できます。これにより、クラスター全体にポッドを分散させたり、特定のノードを選択したりすることができ、障害ノードが発生した場合の回復力を高めることができます。

global:
  antiAffinity: soft
  affinity:
    podAntiAffinity:
      topologyKey: "kubernetes.io/hostname"

• global.antiAffinity は2つの値を取ります：
  • soft:preferredDuringSchedulingIgnoredDuringExecution 、Kubernetesスケジューラがルールの適用を試みますが、結果は保証されません。
  • hard:requiredDuringSchedulingIgnoredDuringExecution 、ポッドがノードにスケジュールされるためにルールが満たさ_れなければ_ならないアンチアフィニティを定義しました。
• global.affinity.podAntiAffinity.topologyKey ノードを論理ゾーンに分割するために使用されるノード属性を定義します。最も一般的なtopologyKey の値は ：
  • kubernetes.io/hostname
  • topology.kubernetes.io/zone
  • topology.kubernetes.io/region

ポッド間アフィニティとアンチアフィニティに関するKubernetesのリファレンス

ポッドの優先順位と先取り

ポッドの優先順位は、global.priorityClassName またはpriorityClassName を使ってサブチャートごとに設定できます。ポッドの優先順位を設定すると、スケジューラに優先順位の低いポッドを追い出して、保留中のポッドのスケジューリングを可能にするように指示できます。

global:
  priorityClassName: system-cluster-critical

ログのローテーション

GitLab 15.6で導入されました。

デフォルトでは、GitLab Helmチャートはログをローテーションしません。これは、長時間稼働するコンテナではエフェメラルストレージの問題を引き起こす可能性があります。

ログのローテーションを有効にするには、GITLAB_LOGGER_TRUNCATE_LOGS 環境変数を true に設定します。また、GITLAB_LOGGER_TRUNCATE_INTERVAL とGITLAB_LOGGER_MAX_FILESIZE 環境変数をそれぞれ設定することで、ログのローテーション頻度と最大ログサイズを設定できます：

global:
  extraEnv:
    GITLAB_LOGGER_TRUNCATE_LOGS: true
    GITLAB_LOGGER_TRUNCATE_INTERVAL: 300
    GITLAB_LOGGER_MAX_FILESIZE: 1000