正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

グローバル変数を使用してチャートを設定する

  • プラン: Free、Premium、Ultimate
  • 提供形態: GitLab Self-Managed

ラッパーHelmチャートのインストール時に同じ設定を何度も重複してすることを軽減するため、いくつかの設定はglobalvalues.yamlセクションで設定できます。これらのグローバル設定は複数のチャートを通じて使用されますが、他のすべての設定はそのチャート内がスコーピングされます。グローバル変数の仕組みの詳細については、グローバル変数に関するHelmドキュメントを参照してください。

ホストを設定する

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
名前デフォルト説明
domain文字列example.comベースドメイン。GitLabとレジストリは、この設定のサブドメインで公開されます。そのデフォルトはexample.comですが、nameプロパティが設定されているホストには使用されません。下記のgitlab.nameminio.name、およびregistry.nameのセクションを参照してください。
externalIPnilプロバイダーから要求される外部IPアドレスを設定します。これは、より複雑なnginx.service.loadBalancerIPの代わりに、NGINXチャート内でテンプレート処理されて使用されます。
externalGeoIPnilexternalIPと同じですが、NGINX Geoチャート用です。統合URLを使用してGitLab Geoサイトの静的IPを設定するために必要です。externalIPとは異なっている必要があります。
httpsブール値truetrueに設定されている場合は、NGINXチャートが証明書にアクセスできることを確認する必要があります。Ingressの前にTLSターミネーションがある場合は、global.ingress.tls.enabledを調べるとよいでしょう。外部URLでは、httpsの代わりにhttp://を使用するため、falseに設定します。
hostSuffix文字列下記を参照
gitlab.httpsブール値falsehosts.httpsまたはgitlab.httpstrueの場合、GitLab外部URLではhttp://ではなくhttps://を使用します。
gitlab.name文字列GitLabのホスト名。設定されている場合、global.hosts.domainglobal.hosts.hostSuffixの設定に関係なくこのホスト名が使用されます。
gitlab.hostnameOverride文字列WebserviceのIngress設定で使用されているホスト名をオーバーライドします。ホスト名を内部ホスト名に書き換えるWAFの背後からGitLabに到達可能でなければならないという場合に役立ちます(例: gitlab.example.comgitlab.cluster.local)。
gitlab.serviceName文字列webserviceGitLabサーバーを操作しているserviceの名前。チャートにより、サービス(および現在の.Release.Name)のホスト名がテンプレート処理され、適切な内部serviceNameが作成されます。
gitlab.servicePort文字列workhorseGitLabサーバーに到達できるserviceの名前付きポート。
keda.enabledブール値falseHorizontalPodAutoscalersの代わりにKEDA ScaledObjectsを使用します
minio.httpsブール値falsehosts.httpsまたはminio.httpstrueの場合、MinIO外部URLではhttp://ではなくhttps://を使用します。
minio.name文字列minioMinIOのホスト名。設定されている場合、global.hosts.domainglobal.hosts.hostSuffixの設定に関係なくこのホスト名が使用されます。
minio.serviceName文字列minioMinIOサーバーを操作しているserviceの名前。チャートにより、サービス(および現在の.Release.Name)のホスト名がテンプレート処理され、適切な内部serviceNameが作成されます。
minio.servicePort文字列minioMinIOサーバーに到達できるserviceの名前付きポート。
registry.httpsブール値falsehosts.httpsまたはregistry.httpstrueの場合、レジストリの外部URLではhttp://ではなくhttps://を使用します。
registry.name文字列registryレジストリのホスト名。設定されている場合、global.hosts.domainglobal.hosts.hostSuffixの設定に関係なくこのホスト名が使用されます。
registry.serviceName文字列registryレジストリサーバーを操作しているserviceの名前。チャートにより、サービス(および現在の.Release.Name)のホスト名がテンプレート処理され、適切な内部serviceNameが作成されます。
registry.servicePort文字列registryレジストリサーバーに到達できるserviceの名前付きポート。
smartcard.name文字列smartcardスマートカード認証のホスト名。設定されている場合、global.hosts.domainglobal.hosts.hostSuffixの設定に関係なくこのホスト名が使用されます。
kas.name文字列kasKASのホスト名。設定されている場合、global.hosts.domainglobal.hosts.hostSuffixの設定に関係なくこのホスト名が使用されます。
kas.httpsブール値falsehosts.httpsまたはkas.httpstrueの場合、KAS外部URLではws://ではなくwss://を使用します。
pages.name文字列pagesGitLab Pagesのホスト名。設定されている場合、global.hosts.domainglobal.hosts.hostSuffixの設定に関係なくこのホスト名が使用されます。
pages.https文字列global.pages.httpsglobal.hosts.pages.https、またはglobal.hosts.httpstrueの場合、プロジェクト設定UIにおいて、GitLab PagesのURLにはhttp://ではなくhttps://を使用します。
ssh文字列SSH経由でリポジトリを複製するためのホスト名。設定されている場合、global.hosts.domainglobal.hosts.hostSuffixの設定に関係なくこのホスト名が使用されます。

hostSuffix

ベースdomainを使用してホスト名を構成する際にはhostSuffixがサブドメインに付加されますが、独自のnameが設定されているホストには使用されません。

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

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

Horizontal Pod Autoscalerを設定する

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

名前デフォルト説明
apiVersion文字列HorizontalPodAutoscalerオブジェクトの定義で使用するAPIバージョン。

PodDisruptionBudgetを設定する

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

名前デフォルト説明
apiVersion文字列PodDisruptionBudgetオブジェクトの定義で使用するAPIバージョン。

CronJobを設定する

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

名前デフォルト説明
apiVersion文字列CronJobオブジェクトの定義で使用するAPIバージョン。

モニタリングを設定する

ServiceMonitorsおよびPodMonitorsのGitLabグローバル設定は、global.monitoringキーの下にあります:

名前デフォルト説明
enabledブール値falsemonitoring.coreos.com/v1 APIの可用性に関係なく、モニタリングリソースを有効にします。

Ingressを設定する

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

名前デフォルト説明
apiVersion文字列Ingressオブジェクトの定義で使用するAPIバージョン。
annotations.*annotation-key*文字列annotation-keyは、あらゆるIngressでアノテーションとして値とともに使用される文字列です。例: global.ingress.annotations."nginx\.ingress\.kubernetes\.io/enable-access-log"=true。デフォルトの場合、グローバルアノテーションは提供されません。
configureCertmanagerブール値true下記を参照
useNewIngressForCertsブール値false下記を参照
class文字列gitlab-nginxIngressリソースのkubernetes.io/ingress.classアノテーションまたはspec.IngressClassNameを制御するグローバル設定。無効にする場合はnone、空にする場合は""に設定します。注: noneまたは""の場合、不要なIngressリソースがチャートによってデプロイされないようにするため、nginx-ingress.enabled=falseに設定してください。
enabledブール値trueサービスでサポートするIngressオブジェクトを作成するかどうかを制御するためのグローバル設定。
tls.enabledブール値truefalseに設定すると、GitLabのTLSが無効になります。これは、IngressのTLSターミネーションを使用できない場合(TLSターミネーションプロキシがIngressコントローラーの前にある場合など)に役立ちます。httpsを完全に無効にする場合は、global.hosts.httpsとともにfalseに設定する必要があります。
tls.secretName文字列global.hosts.domainで使用されるドメインのワイルドカード証明書とキーが含まれるKubernetes TLS Secretの名前。
path文字列/Ingressオブジェクトpathエントリのデフォルト
pathType文字列Prefixパスタイプを使用すると、パスのマッチング方法を指定できます。現在のデフォルトはPrefixですが、ユースケースに応じてImplementationSpecificExactも使用できます。
provider文字列nginx使用するIngressプロバイダーを定義するグローバル設定。nginxがデフォルトのプロバイダーとして使用されます。

さまざまなクラウドプロバイダーの設定のサンプルが、examplesフォルダーにあります。

Ingressパス

このチャートでは、Ingressオブジェクトのpathエントリの定義を変更する必要があるユーザーを支援する手段として、global.ingress.pathを採用しています。多くのユーザーはこの設定を必要としないため、設定しないでください

GCPでingress.class: gce、AWSでingress.class: albを利用する場合など、プロバイダーの必要に応じてロードバランサー/プロキシの動作に一致するように、pathの定義を/*で終了させる必要があるユーザー向けです。

この設定により、このチャート全体としてIngressリソースのすべてのpathエントリのレンダリングでこれが使用されるようになります。唯一の例外として、gitlab/webserviceデプロイの設定にデータを入力する場合にはpathを指定する必要があります。

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

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

プロバイダーレイヤーサンプルスニペット
AWS4aws/elb-layer4-loadbalancer
AWS7aws/elb-layer7-loadbalancer
AWS7aws/alb-full

global.ingress.configureCertmanager

Ingressオブジェクトのcert-managerの自動設定を制御するグローバル設定。trueの場合は、certmanager-issuer.emailが設定されている必要があります。

falseの場合、かつglobal.ingress.tls.secretNameが未設定で、global.ingress.tls.enabledがtrueまたは未設定の場合は、自己署名証明書の自動生成がアクティブになり、すべてのIngressオブジェクトに対してワイルドカード証明書が作成されます。

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

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

global.ingress.useNewIngressForCerts

cert-managerの動作を変更して、毎回動的に作成される新しいIngressを使用してACMEチャレンジ検証を実行するようにするためのグローバル設定。

デフォルトのロジック(global.ingress.useNewIngressForCertsfalseの場合)は、検証のために既存のIngressを再利用します。このデフォルトは、状況によっては適切ではありません。フラグをtrueに設定すると、検証のたびに新しいIngressオブジェクトが作成されます。

GKE Ingressコントローラーで使用する場合、global.ingress.useNewIngressForCertstrueに設定することはできません。

GitLabバージョン

この値は、開発目的か、またはGitLabサポートからの明示的なリクエストがあった場合のみに使用してください。本番環境の設定ファイルでは、この値を使用しないでください。代わりに、Helmを使用したデプロイの説明に従ってバージョンを設定してください。

チャートのデフォルトイメージタグで使用されているGitLabのバージョンは、global.gitlabVersionキーを使用して変更できます:

--set global.gitlabVersion=11.0.1

これは、webservicesidekiq、およびmigrationのチャートで使用されるデフォルトのイメージタグに影響します。gitalygitlab-shell、およびgitlab-runnerのイメージタグは、個別に更新して、GitLabバージョンと互換性のあるバージョンにする必要があります。

すべてのイメージタグにサフィックスを追加する

Helmチャートで使用されるすべてのイメージの名前にサフィックスを追加する場合は、global.image.tagSuffixキーを使用することができます。このユースケースの例としては、GitLabからFIPS準拠のコンテナイメージを使用する場合があり、それらはすべてイメージタグに拡張子-fipsを付けて構成されます。

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

すべてのコンテナのカスタムタイムゾーン

すべてのGitLabコンテナに対してカスタムタイムゾーンを設定する場合は、global.time_zoneキーを使用することができます。使用可能な値については、tzデータベースのタイムゾーンのリストTZ identifierを参照してください。デフォルトはUTCです。

--set global.time_zone="America/Chicago"

PostgreSQLを設定する

GitLabのグローバルPostgreSQLの設定は、global.psqlキーの下にあります。GitLabでは2つのデータベース接続を使用しており、1つはmainデータベース用、もう1つはci用です。デフォルトでは、これらは同じPostgreSQLデータベースを指します。

global.psqlの下の値はデフォルトであり、両方のデータベース設定に適用されます。2つのデータベースを使用する場合は、global.psql.mainglobal.psql.ciで接続の詳細を指定できます。

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:
    main: {}
      # host: postgresql-main.hostedsomewhere.else
      # ...
    ci: {}
      # host: postgresql-ci.hostedsomewhere.else
      # ...
名前デフォルト説明
host文字列使用するデータベースを持つPostgreSQLサーバーのホスト名。このチャートによってデプロイされたPostgreSQLを使用している場合は、省略できます。
serviceName文字列PostgreSQLデータベースを操作しているserviceの名前。これが存在し、hostが存在しない場合、チャートはhost値の代わりにサービスのホスト名をテンプレート処理します。
database文字列gitlabhq_productionPostgreSQLサーバーで使用するデータベースの名前。
password.useSecretブール値truePostgreSQLのパスワードをシークレットまたはファイルから読み取るかどうかを制御します。
password.file文字列PostgreSQLのパスワードを含むファイルへのパスを定義します。password.useSecretがtrueの場合、無視されます。
password.key文字列PostgreSQLのpassword.key属性は、パスワードを含むシークレット(下記)内のキーの名前を定義します。password.useSecretがfalseの場合、無視されます。
password.secret文字列PostgreSQLのpassword.secret属性は、プル元のKubernetes Secretの名前を定義します。password.useSecretがfalseの場合、無視されます。
port整数5432PostgreSQLサーバーへの接続に使用するポート。
username文字列gitlabデータベースへの認証に使用するユーザー名。
preparedStatementsブール値falsePostgreSQLサーバーとの通信時にプリペアドステートメントを使用するかどうか。
databaseTasksブール値trueGitLabが特定のデータベースに対してデータベースタスクを実行するかどうか。共有ホスト/ポート/データベースがmainと一致する場合、自動的に無効になります。
connectTimeout整数データベース接続を待機する秒数。
keepalives整数クライアント側のTCP keepalivesを使用するかどうかを制御します(1はオン、0はオフを意味します)。
keepalivesIdle整数TCPがキープアライブメッセージをサーバーに送信するまでの非アクティブ状態の秒数。値がゼロの場合は、システムのデフォルトを使用します。
keepalivesInterval整数サーバーによって確認応答されないTCPキープアライブメッセージを再送信するまでの秒数。値がゼロの場合は、システムのデフォルトを使用します。
keepalivesCount整数サーバーへのクライアント接続が切断されたと見なされるまでに失われる可能性のあるTCP keepalivesの数。値がゼロの場合は、システムのデフォルトを使用します。
tcpUserTimeout整数送信されたデータが確認応答されない場合に接続が強制的に閉じられるまでのミリ秒数。値がゼロの場合は、システムのデフォルトを使用します。
applicationName文字列データベースに接続しているアプリケーションの名前。無効にするには、空白文字列("")に設定します。デフォルトでは、これは実行中のプロセスの名前(sidekiqpumaなど)に設定されます。
ci.enabledブール値true2つのデータベース接続を有効にします。

チャートごとのPostgreSQL

一部の複雑なデプロイでは、このチャートの異なる部分をPostgreSQLの異なる設定で構成することが要件となる場合があります。v4.2.0時点では、global.psql内で使用可能なすべての属性は、gitlab.sidekiq.psqlなどのチャート単位で設定できます。ローカル設定を指定した場合、グローバル値はオーバーライドされ、psql.load_balancingを除き、global.psqlから_継承されていないもの_はすべて継承されます。

PostgreSQLのロードバランシングは、設計上、グローバルからは_決して_継承されません。

PostgreSQL SSL

SSLサポートは相互TLSのみです。イシュー#2034イシュー#1817を参照してください。

相互TLS経由でGitLabをPostgreSQLデータベースに接続する場合は、クライアントキー、クライアント証明書、およびサーバー認証局を異なるシークレットキーとして含むシークレットを作成します。次に、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
名前デフォルト説明
secret文字列次のキーを含むKubernetes Secretの名前。
clientCertificate文字列Secret内で、クライアント証明書を含むキーの名前。
clientKey文字列Secret内で、クライアント証明書のキーファイルを含むキーの名前。
serverCA文字列Secret内で、サーバーの認証局を含むキーの名前。

正しいキーを指すように環境変数をエクスポートするために、extraEnv値を設定する必要がある場合もあります。

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のロードバランシング

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

GitLabのRailsコンポーネントには、PostgreSQLクラスターを利用して読み取り専用クエリの負荷分散を行う機能があります。

この機能は、次の2つの方法で設定できます:

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

分かりやすいのは静的リストによる設定です:

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

サービスディスカバリの設定はもっと複雑になることがあります。この設定、パラメータ、およびそれらに関連する動作の詳細については、GitLab管理ドキュメントサービスディスカバリを参照してください。

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管理ドキュメントで詳しく説明されており、これらの属性はload_balancingの下に直接追加できます。

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

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

GitLab 16.0では、GitLabはデフォルトで、同じPostgreSQLデータベースを指す2つのデータベース接続を使用するようになっています。

Redisを設定する

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

デフォルトでは、単一の非レプリケートRedisインスタンスを使用します。高可用性Redisが必要な場合は、外部Redisインスタンスを使用することをおすすめします。

外部Redisインスタンスは、redis.install=falseを設定し、高度なドキュメントに従って設定することで実現できます。

global:
  redis:
    host: redis.example.com
    serviceName: redis
    database: 7
    port: 6379
    auth:
      enabled: true
      secret: gitlab-redis
      key: redis-password
    scheme:
名前デフォルト説明
connectTimeout整数Redis接続を待機する秒数。値を指定しない場合、クライアントのデフォルトは1秒です。
readTimeout整数Redisの読み取りを待機する秒数。値を指定しない場合、クライアントのデフォルトは1秒です。
writeTimeout整数Redisの書き込みを待機する秒数。値を指定しない場合、クライアントのデフォルトは1秒です。
host文字列使用するデータベースが格納されているRedisサーバーのホスト名。serviceNameの代わりとして省略できます。
serviceName文字列redisRedisデータベースを操作しているserviceの名前。これが存在し、hostが存在しない場合、チャートはhost値の代わりにサービスのホスト名(および現在の.Release.Name)をテンプレート処理します。これは、RedisをGitLabチャート全体の一部として使用する場合に便利です。
port整数6379Redisサーバーへの接続に使用するポート。
database整数0Redisサーバー上の接続先データベース。
user文字列Redisに認証するために使用するユーザー名(Redis 6.0以降)。
auth.enabledブール値trueauth.enabledは、Redisインスタンスでパスワードを使用するかどうかの切替機能を提供します。
auth.key文字列Redisのauth.key属性は、パスワードを含むシークレット(下記)内のキーの名前を定義します。
auth.secret文字列Redisのauth.secret属性は、プル元のKubernetes Secretの名前を定義します。
scheme文字列redisRedis URLを生成するために使用するURIスキーム。有効な値は、redisrediss、およびtcpです。rediss(SSL暗号化された接続)スキームを使用する場合、サーバーで使用される証明書は、システムで信頼するチェーンの一部である必要があります。これを実現するには、カスタム認証局のリストに追加してください。

Redisチャート固有の設定を構成する

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

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

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

Redis Sentinelのサポート

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

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

GitLabでデプロイされたRedisクラスターでのSentinelのサポートを追跡するイシューが、追跡目的で作成されています。

redis:
  install: false
global:
  redis:
    host: redis.example.com
    serviceName: redis
    port: 6379
    sentinels:
      - host: sentinel1.example.com
        port: 26379
      - host: sentinel2.example.com
        port: 26379
    auth:
      enabled: true
      secret: gitlab-redis
      key: redis-password
名前デフォルト説明
host文字列host属性には、sentinel.confで指定されているクラスター名を設定する必要があります。
sentinels.[].host文字列Redis HA設定用のRedis Sentinelサーバーのホスト名。
sentinels.[].port整数26379Redis Sentinelサーバーへの接続に使用するポート。

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

Redis Sentinelのパスワードサポート

redis:
  install: false
global:
  redis:
    host: redis.example.com
    serviceName: redis
    port: 6379
    sentinels:
      - host: sentinel1.example.com
        port: 26379
      - host: sentinel2.example.com
        port: 26379
    auth:
      enabled: true
      secret: gitlab-redis
      key: redis-password
    sentinelAuth:
      enabled: false
      secret: gitlab-redis-sentinel
      key: sentinel-password
名前デフォルト説明
sentinelAuth.enabledブール値falsesentinelAuth.enabledは、Redis Sentinelインスタンスでパスワードを使用するかどうかの切替機能を提供します。
sentinelAuth.key文字列RedisのsentinelAuth.key属性は、パスワードを含むシークレット(下記)内のキーの名前を定義します。
sentinelAuth.secret文字列RedisのsentinelAuth.secret属性は、プル元のKubernetes Secretの名前を定義します。

global.redis.sentinelAuthを使用して、すべてのSentinelインスタンスのSentinelパスワードを設定できます。

sentinelAuthは、Redisインスタンス固有の設定 、またはglobal.redis.redisYmlOverrideでオーバーライドできないことに注意してください。

複数のRedisのサポート

GitLabチャートには、さまざまな永続クラス用に別個のRedisインスタンスで実行するためのサポートが含まれています。現在のところ、次のとおりです:

インスタンス目的
actioncableActionCableのPub/Subキューバックエンド
cacheキャッシュされたデータを保存する
kasKAS固有のデータを保存する
queuesSidekiqバックグラウンドジョブを保存する
rateLimitingRackAttackとアプリケーション制限のためのレート制限の利用状況を保存する
repositoryCacheリポジトリ関連データを保存する
sessionsユーザーセッションデータを保存する
sharedState分散ロックなど、さまざまな永続データを保存する
traceChunksジョブトレースを一時的に保存する
workhorseWorkhorseのPub/subキューバックエンド

インスタンスの数に制限はありません。指定されていないインスタンスは、global.redis.hostで指定されたプライマリRedisインスタンスによって処理されるか、チャートからデプロイされたRedisインスタンスを使用します。唯一の例外は、GitLabエージェントサーバー(KAS)であり、Redis設定を次の順序で検索します:

  1. global.redis.kas
  2. global.redis.sharedState
  3. global.redis.host

例:

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

次の表に、Redisインスタンスの各ディクショナリの属性を示します。

名前デフォルト説明
.host文字列使用するデータベースが格納されているRedisサーバーのホスト名。
.port整数6379Redisサーバーへの接続に使用するポート。
.password.enabledブール値truepassword.enabledは、Redisインスタンスでパスワードを使用するかどうかの切替機能を提供します。
.password.key文字列Redisのpassword.key属性は、パスワードを含むシークレット(下記)内のキーの名前を定義します。
.password.secret文字列Redisのpassword.secret属性は、プル元のKubernetes Secretの名前を定義します。

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

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

セキュアなRedisスキーム(SSL)を指定する

SSLでRedisに接続するには、次のようにします:

  1. redisssは2個)スキームパラメータを使用するように設定を更新します。

  2. 設定で、authClientsfalseに設定します:

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

    Redisのデフォルトは相互TLSであり、それはすべてのチャートコンポーネントでサポートしているわけではないため、この設定は必須です。

  3. BitnamiのTLSを有効にする手順に従います。チャートコンポーネントが、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

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

enabledhostapitokenIssuerの詳細については、コマンドラインオプションおよびWebserviceのドキュメントを参照してください。

hostは、自動生成された外部レジストリホスト名参照をオーバーライドするために使用されます。

notifications

この設定は、レジストリの通知を設定するために使用されます。これは、(アップストリームの仕様に従って)マップを取り込みますが、Kubernetes Secretとして機密ヘッダーを提供するという機能が追加されています。たとえば、認証ヘッダーには機密データが含まれ、他のヘッダーには標準のデータが含まれている次のスニペットについて考えてみましょう:

global:
  registry:
    notifications:
      events:
        includereferences: true
      endpoints:
        - name: CustomListener
          url: https://mycustomlistener.com
          timeout: 500mx
          # DEPRECATED: use `maxretries` instead https://gitlab.com/gitlab-org/container-registry/-/issues/1243.
          # When using `maxretries`, `threshold` is ignored: https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md?ref_type=heads#endpoints
          threshold: 5
          maxretries: 5
          backoff: 1s
          headers:
            X-Random-Config: [plain direct]
            Authorization:
              secret: registry-authorization-header
              key: password

この例の場合、ヘッダーX-Random-Configは標準のヘッダーであり、その値はvalues.yamlファイル内に、または--setフラグを介してプレーンテキストで指定できます。ただし、ヘッダーAuthorizationは機密ヘッダーであるため、Kubernetes Secretからマウントすることをおすすめします。シークレットの構造の詳細については、シークレットに関するドキュメントを参照してください。

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ノードを使用することもできます:

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

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

現時点で、Gitaly認証トークンは、内部または外部のすべてのGitalyサービスで同一であることが期待されています。これらが揃っていることを確認してください。詳細については、イシュー#1992を参照してください。

internal

現在のところ、internalキーは1つのキーnamesだけで構成されており、これはチャートによって管理されるストレージ名のリストです。リスト内の名前ごとに(論理的な順序で)、1つのポッドが起動します。その名前は${releaseName}-gitaly-${ordinal}です(ordinalnamesリスト内のインデックス)。動的なプロビジョニングが有効になっている場合、PersistentVolumeClaimは一致します。

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

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

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

external

externalキーは、クラスターの外部にあるGitalyノードの設定を提供します。このリストの各アイテムには、次の3つのキーがあります:

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

GitLabでは、外部Gitalyサービスの使用に関する高度な設定ガイドを提供しています。examplesフォルダーには、複数の外部サービスの設定の例もあります。

可用性の高いGitalyサービスを提供するために、外部Praefectを使用することもできます。クライアントにとっては違いがないため、2つの設定は交換可能です。

混合

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

examplesフォルダーに、内部ノードと外部ノードの混合設定の例があります。

authToken

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

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

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

非推奨のGitaly設定

名前デフォルト説明
host (非推奨)文字列使用するGitalyサーバーのホスト名。serviceNameの代わりとして省略できます。この設定を使用すると、internalまたはexternalの値がオーバーライドされます。
port (非推奨)整数8075Gitalyサーバーへの接続に使用するポート。
serviceName (非推奨)文字列Gitalyサーバーを操作しているserviceの名前。これが存在し、hostが存在しない場合、チャートはhost値の代わりにサービスのホスト名(および現在の.Release.Name)をテンプレート処理します。これは、GitalyをGitLabチャート全体の一部として使用する場合に便利です。

TLSの設定

TLS経由で動作するようにGitalyを設定する方法について詳しくは、Gitalyチャートのドキュメントをご覧ください。

Praefectを設定する

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

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

Praefectを有効にする

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

詳しくは、Gitalyクラスタ(Praefect)をご覧ください。

Praefectのグローバル設定

global:
  praefect:
    enabled: false
    virtualStorages:
    - name: default
      gitalyReplicas: 3
      maxUnavailable: 1
    dbSecret: {}
    psql: {}
名前デフォルト説明
enabledブール値falsePraefectを有効にするかどうか。
virtualStoragesリスト必要な仮想ストレージのリスト(それぞれをGitaly StatefulSetで処理)デフォルトについては、複数の仮想ストレージを参照してください。
dbSecret.secret文字列データベースの認証に使用するシークレットの名前。
dbSecret.key文字列使用するdbSecret.secretの中のキーの名前。
psql.host文字列使用するデータベースサーバーのホスト名(外部データベースを使用する場合)。
psql.port文字列データベースサーバーのポート番号(外部データベースを使用する場合)。
psql.user文字列praefect使用するデータベースユーザー。
psql.dbName文字列praefect使用するデータベースの名前。

MinIOを設定する

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

global:
  minio:
    enabled: true
    credentials: {}

appConfigを設定する

WebserviceSidekiq 、およびGitalyのチャートでは複数の設定が共有されており、それらはglobal.appConfigキーで設定されます。

global:
  appConfig:
    # cdnHost:
    relativeUrlRoot: ""
    contentSecurityPolicy:
      enabled: false
      report_only: true
      # directives: {}
    enableUsagePing: true
    enableSeatLink: true
    enableImpersonation: true
    applicationSettingsCacheSeconds: 60
    usernameChangingEnabled: true
    issueClosingPattern:
    defaultTheme:
    defaultColorMode:
    defaultSyntaxHighlightingTheme:
    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: ""
    oidcProvider:
      openidIdTokenExpireInSeconds: 120
    smartcard:
      enabled: false
      CASecret:
      clientCertificateRequiredHost:
    sidekiq:
      routingRules: []

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

Railsアプリケーションの一般的なプロパティを微調整するために使用できるappConfig設定について、以下に説明します:

名前デフォルト説明
cdnHost文字列(空)静的アセットを処理するための、CDNのベースURLを設定します(https://mycdnsubdomain.fictional-cdn.comなど)。
relativeUrlRoot文字列(空)GitLabの相対URLルートを設定します(例: /gitlab)。設定すると、GitLabにはルートパスではなく、指定されたパスでアクセスできるようになります。
contentSecurityPolicy構造体下記を参照
enableUsagePingブール値truepingの使用のサポートを無効にするフラグ。
enableSeatLinkブール値trueシートリンクのサポートを無効にするフラグ。
enableImpersonationnil管理者によるユーザーの代理を無効にするフラグ。
applicationSettingsCacheSeconds整数60アプリケーション設定キャッシュを無効にする間隔の値(秒単位)。
usernameChangingEnabledブール値trueユーザーがユーザー名を変更できるかどうかを決定するフラグ。
issueClosingPattern文字列(空)イシューを自動的に完了するパターン
defaultTheme整数GitLabインスタンスのデフォルトテーマの数値ID。テーマのIDを示す数値を指定します。
defaultColorMode整数GitLabインスタンスのデフォルトのカラーモード。カラーモードのIDを示す数値を指定します。
defaultSyntaxHighlightingTheme整数GitLabインスタンスのデフォルト構文ハイライトのテーマ。ハイライトした構文テーマのIDを示す数値を指定します。
defaultProjectsFeatures.*feature*ブール値true下記を参照
webhookTimeout整数(空)フックが失敗したと見なされるまでの待機時間(秒単位)。
graphQlTimeout整数(空)RailsがGraphQLリクエストを完了するまでの時間(秒単位)。

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

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

CSPの安全なデフォルト値は、GitLabにより自動的に提供されます。

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_onlytrueに変更して設定をテストするとよいかもしれません。

相対URLルートを設定する

  • ステータス: ベータ

GitLabの相対URLを設定すると、Geo に関する既知の問題テストの制限が発生します。

GitLabは独自のドメインまたはサブドメインにインストールする必要がありますが、必要に応じて相対URLの下にインストールできます。たとえばhttps://example.com/gitlabなどです。

すべてのWebサービスデプロイのIngressには、このプレフィックスが付きます。

global:
  appConfig:
    relativeUrlRoot: "/gitlab"
  hosts:
    domain: example.com
    gitlab:
      name: example.com

defaultProjectsFeatures

新規プロジェクト作成時に、対応する各機能をデフォルトで有効にするかどうかを決定するフラグ。どのフラグもデフォルトはtrueです。

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

Gravatar/Libravatarの設定

デフォルトでは、チャートはgravatar.comで利用可能なGravatarアバターサービスと連携します。ただし、必要に応じてカスタムLibravatarサービスを使用することもできます:

名前デフォルト説明
gravatar.plainURL文字列(空)LibravatarインスタンスのHTTP URL(gravatar.comの使用に代わるもの)
gravatar.sslUrl文字列(空)LibravatarインスタンスのHTTPS URL(gravatar.comの使用に代わるもの)

GitLabインスタンスに対するAnalyticsサービスのフック

Google AnalyticsやMatomoなどのAnalyticsサービス設定は、appConfigの下のextraキーで定義されています:

名前デフォルト説明
extra.googleAnalyticsId文字列(空)Google AnalyticsのトラッキングID。
extra.matomoSiteId文字列(空)MatomoサイトID。
extra.matomoUrl文字列(空)Matomo URL。
extra.matomoDisableCookiesブール値(空)Matomoクッキーを無効にする(MatomoスクリプトのdisableCookiesに対応)。
extra.oneTrustId文字列(空)OneTrust ID。
extra.googleTagManagerNonceId文字列(空)GoogleタグマネージャーID。
extra.bizibleブール値falseBizibleスクリプトを有効にする場合はtrueに設定。

統合されたオブジェクトストレージ

以下のセクションではオブジェクトストレージの個々の設定方法について説明していますが、これに加えて、これらの項目に共通の設定を使いやすくするため、統合されたオブジェクトストレージ設定を追加しました。object_storeを活用すると、connectionを一度だけ設定すれば、オブジェクトストレージでサポートされる機能のうち、個別にconnectionプロパティが設定されていないものすべてに対してその接続設定が使用されます。

  enabled: true
  proxy_download: true
  storage_options:
  connection:
    secret:
    key:
名前デフォルト説明
enabledブール値false統合されたオブジェクトストレージの使用を有効にします。
proxy_downloadブール値trueGitLab経由のすべてのダウンロードについて、bucketから直接ダウンロードする代わりにプロキシを有効にします。
storage_options文字列{}下記を参照
connection文字列{}下記を参照

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

デフォルト以外の値を使用する場合に、項目ごとに(global.appConfig.artifacts.bucketなど)設定する必要があるのは、bucketenabledproxy_downloadのプロパティだけです。

接続AWSプロバイダー(同梱されているMinIOなどのS3互換プロバイダー)を使用する場合、GitLab Workhorseはストレージ関連のすべてのアップロードをオフロードできます。この統合設定を使用する場合、これは自動的に有効になります。

バケットを指定する

オブジェクトは、タイプごとに異なるバケットに格納する必要があります。デフォルトで、GitLabがタイプごとに使用するバケット名は次のとおりです:

オブジェクトタイプバケット名
CIアーティファクトgitlab-artifacts
Git LFSgit-lfs
パッケージgitlab-packages
アップロードgitlab-uploads
外部マージリクエストの差分gitlab-mr-diffs
Terraformステートgitlab-terraform-state
CIセキュアファイルgitlab-ci-secure-files
依存プロキシgitlab-dependency-proxy
Pagesgitlab-pages

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

--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>

storage_options

storage_optionsは、S3サーバー側の暗号化を設定するために使用されます。

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

設定説明
server_side_encryption暗号化モード(AES256またはaws:kms)。
server_side_encryption_kms_key_idAmazonリソース名。これが必要になるのはserver_side_encryptionaws:kmsを使用する場合だけです。KMS暗号化の使用に関するAmazonドキュメントを参照してください。

例:

  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:
名前デフォルト説明
enabledブール値LFS、アーティファクト、アップロード、およびパッケージのデフォルトはtrueオブジェクトストレージでこれらの機能の使用を有効にします。
proxy_downloadブール値trueGitLab経由のすべてのダウンロードについて、bucketから直接ダウンロードする代わりにプロキシを有効にします。
bucket文字列さまざまオブジェクトストレージプロバイダーから使用するバケットの名前。サービスに応じて、デフォルトはgit-lfsgitlab-artifactsgitlab-uploadsgitlab-packagesのどれかになります。
connection文字列{}下記を参照

connection

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

このプロパティには、secretkeyの2つのサブキーがあります。

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

有効な設定キーについては、GitLabジョブアーティファクトの管理のドキュメントに記載されています。これはFogに対応しており、プロバイダーモジュールに応じて異なります。

AWSGoogleプロバイダーの場合の例が、examples/objectstorageにあります。

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

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

when(外部MR差分のみ)

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

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

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

受信メールの設定

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

KASの設定

カスタムシークレット

オプションとして、KAS secretの名前とkeyをカスタマイズできます。そのためには、以下のようにしてHelmの--set variableオプションを使用するか、:

--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" \
--set global.appConfig.gitlab_kas.clientTimeoutSeconds=10 # Optional, default is 5 seconds

または、values.yamlを以下のように設定します:

global:
  appConfig:
    gitlab_kas:
      externalUrl: "wss://custom-kas-url.example.com"
      internalUrl: "grpc://custom-internal-url"
      clientTimeoutSeconds: 10 # Optional, default is 5 seconds

外部KAS

外部KASサーバー(チャートによって管理されていないもの)は、それを明示的に有効にして必要なURLを設定することにより、GitLabバックエンドに認識させることができます。そのためには、以下のようにして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" \
--set global.appConfig.gitlab_kas.clientTimeoutSeconds=10 # Optional, default is 5 seconds

または、values.yamlを以下のように設定します:

global:
  appConfig:
    gitlab_kas:
      enabled: true
      externalUrl: "wss://custom-kas-url.example.com"
      internalUrl: "grpc://custom-internal-url"
      clientTimeoutSeconds: 10 # Optional, default is 5 seconds

TLSの設定

KASは、kasポッドとその他のGitLabチャートコンポーネントとの間でTLS通信をサポートします。

前提要件:

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

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

説明
global.kas.tls.enabled証明書ボリュームをマウントし、kasエンドポイントへのTLS通信を有効にします。
global.kas.tls.secretName証明書の保存場所となるKubernetes TLSシークレットを指定します。
global.kas.tls.caSecretNameカスタムCAの保存場所となるKubernetes TLSシークレットを指定します。

たとえば、チャートをデプロイするには、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

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'

Helmの--set項目の中で、カンマは特殊文字と見なされます。bind_dnなどの値では、カンマをエスケープしてください(例: --set global.appConfig.ldap.servers.main.bind_dn='cn=administrator\,cn=Users\,dc=domain\,dc=net')。

LDAP Webサインインを無効にする

SAMLなどの代替手段を優先したい場合、Web UIでのLDAP認証を無効にすると便利です。これにより、グループ同期にLDAPを使用しつつ、SAML Identity Providerがカスタム2FAなどの追加チェックを処理できるようになります。

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

Webサインインに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設定でそれを使用することが指定されます。

GitLab 15.9以降、/etc/ssl/certs/の証明書にca-cert-のプレフィックスが付くことはなくなりました。これは、デプロイ済みポッド向けに証明書シークレットを準備するコンテナとしてalpineが使われていたことに起因する、以前の動作です。現在では、Debianベースのgitlab-baseコンテナがこの処理に使用されています。

詳細については、カスタム認証局を参照してください。

duoAuth

これらの設定を使用して、Cisco Duoで2要素認証(2FA)を有効にします。

global:
  appConfig:
    duoAuth:
      enabled:
      hostname:
      integrationKey:
      secretKey:
      #  secret:
      #  key:
名前デフォルト説明
enabledブール値falseCisco Duoとのインテグレーションを有効または無効にします。
hostname文字列Cisco Duo APIホスト名
integrationKey文字列Cisco Duo APIインテグレーションのキー。
secretKeyCisco Duo APIのシークレットキー。シークレットの名前とキーの名前で構成されている必要があります。

Cisco Duoシークレットキーを構成する

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

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

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

OmniAuth

GitLabでは、OmniAuthを利用することにより、ユーザーがGitHub、Google、その他の一般的なサービスを使用してサインインできるようになっています。詳細については、GitLabのOmniAuthドキュメントを参照してください。

omniauth:
  enabled: false
  autoSignInWithProvider:
  syncProfileFromProvider: []
  syncProfileAttributes: ['email']
  allowSingleSignOn: ['saml']
  blockAutoCreatedUsers: true
  autoLinkLdapUser: false
  autoLinkSamlUser: false
  autoLinkUser: ['openid_connect']
  externalProviders: []
  allowBypassTwoFactor: []
  providers: []
  # - secret: gitlab-google-oauth2
  #   key: provider
  # - name: group_saml
名前デフォルト
allowBypassTwoFactorブール値または配列false
allowSingleSignOnブール値または配列['saml']
autoLinkLdapUserブール値false
autoLinkSamlUserブール値false
autoLinkUserブール値または配列false
autoSignInWithProvidernil
blockAutoCreatedUsersブール値true
enabledブール値false
externalProviders[]
providers[]
syncProfileAttributes['email']
syncProfileFromProvider[]

providers

providersは、ソースからインストールする場合と同じように、gitlab.ymlの設定に使用されるマップの配列として提示されます。サポートされているプロバイダーの利用可能な選択については、GitLabドキュメントを参照してください。デフォルトは[]です。

このプロパティには、secretkeyの2つのサブキーがあります:

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

あるいは、プロバイダーに名前以外の設定がない場合、name属性だけを指定した2番目の形式を使うことができます。オプションとしてlabelまたはiconの属性も指定できます。対象となるプロバイダーは次のとおりです:

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

Google OAuth 2.0の設定例:

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>'

この内容は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

グループSAMLの設定例:

omniauth:
  providers:
    - name: group_saml

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

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

--set引数は使い方が複雑であるため、ユーザーによっては、YAMLスニペットを使用し、-f omniauth.yamlを使ってhelmに渡す方法を選択するかもしれません。

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

これらの設定は、Sidekiq、Webサービス(UIにツールチップを表示するため)、およびToolbox(デバッグ目的)のポッドの間で共有されます。

global:
  appConfig:
    cron_jobs:
      stuck_ci_jobs_worker:
        cron: "0 * * * *"
      pipeline_schedule_worker:
        cron: "3-59/10 * * * *"
      expire_build_artifacts_worker:
        cron: "*/7 * * * *"

Sentryの設定

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

global:
  appConfig:
    sentry:
      enabled:
      dsn:
      clientside_dsn:
      environment:
名前デフォルト説明
enabledブール値falseインテグレーションを有効または無効にする
dsn文字列バックエンドエラーのSentry DNS
clientside_dsn文字列フロントエンドエラーのSentry DNS
environment文字列Sentry環境を参照

gitlab_docsの設定

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

global:
  appConfig:
    gitlab_docs:
      enabled:
      host:
名前デフォルト説明
enabledブール値falsegitlab_docsを有効または無効にする
host文字列""ドキュメントホスト

OpenID Connectトークンの有効期限

OpenID Connect(OIDC)プロバイダーのトークンの有効期限を設定します。

global:
  appConfig:
    oidcProvider:
      openidIdTokenExpireInSeconds: 120
名前デフォルト説明
openidIdTokenExpireInSeconds整数120IDトークンが有効期限切れになるまでの時間(秒単位)。

スマートカード認証の設定

global:
  appConfig:
    smartcard:
      enabled: false
      CASecret:
      clientCertificateRequiredHost:
      sanExtensions: false
      requiredForGitAccess: false
名前デフォルト説明
enabledブール値falseスマートカード認証を有効または無効にする。
CASecret文字列CA証明書が格納されているシークレットの名前。
clientCertificateRequiredHost文字列スマートカード認証に使用するホスト名。デフォルトでは、指定された、または計算によるスマートカードホスト名が使用されます。
sanExtensionsブール値falseユーザーと証明書を照合するためにSAN拡張機能を使用できるようにします。
requiredForGitAccessブール値falseGitアクセスのためのスマートカードサインインでブラウザセッションを必須にします。

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

GitLabでは、ジョブのスケジュールを設定する前に、ワーカーから目的のキューへのジョブルーティングがサポートされています。Sidekiqクライアントは、設定されたルーティングルールリストに基づいてジョブを照合します。ルールは先頭から順に評価され、特定のワーカーで一致した時点で、そのワーカーの処理は停止されます(最初の一致が優先されます)。ワーカーがどのルールにも一致しない場合、ワーカー名から生成されるキュー名に戻ります。

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

ルーティングルールリストは、クエリとそれに対応するキューのタプルを要素とする順序付き配列です:

  • クエリは、ワーカー一致クエリの構文に従います。
  • <queue_name>は、sidekiq.podsで定義されている有効なSidekiqキュー名sidekiq.pods[].queuesと一致する必要があります。キュー名(queue_name)がnilまたは空の文字列の場合、ワーカーはワーカー名から生成されるキューにルーティングされます。参考として、Sidekiqの完全な設定例をご覧ください。

クエリは、ワイルドカード*による一致をサポートしており、これはすべてのワーカーに一致します。そのため、ワイルドカードを使用したクエリはリストの最後に配置する必要があります。そうしないと、それ以降のルールは無視されます:

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に接続する必要があるすべてのチャートで使用され、個別ではなくグローバルに設定するための簡単なアクセス手段となります。

global:
  workhorse:
    serviceName: webservice-default
    host: api.example.com
    port: 8181
名前デフォルト説明
serviceName文字列webservice-default内部APIトラフィックの宛先となるサービスの名前。リリース名はテンプレート処理されるため、含めないでください。gitlab.webservice.deploymentsのエントリと一致する必要があります。gitlab/webserviceチャートを参照してください。
scheme文字列httpAPIエンドポイントのスキーム
host文字列APIエンドポイントの完全修飾ホスト名またはIPアドレス。serviceNameがあればそれをオーバーライドします。
port整数8181関連するAPIサーバーのポート番号。
tls.enabledブール値falsetrueに設定すると、WorkhorseのTLSサポートが有効になります。

Bootsnapキャッシュ

Railsコードベースでは、ShopifyのBootsnap gemを使用しています。その動作を設定するため、以下の設定が使用されます。

bootsnap.enabledは、この機能をアクティブにするかどうかを制御します。デフォルトはtrueです。

テストの結果、Bootsnapを有効にすると、アプリケーションのパフォーマンスが全体として向上することが示されました。プリコンパイル済みキャッシュが利用可能な場合、一部のアプリケーションコンテナでは33%を超える性能向上が見られます。現時点で、GitLabではコンテナにこのプリコンパイル済みキャッシュが同梱されていないため、「わずか」14%の向上にとどまっています。ただし、プリコンパイル済みキャッシュが存在しない場合、この性能向上の代償として、各ポッドの初回起動時に小規模なIOが集中的に多数発生します。このため、Bootsnapの使用が問題となる環境でBootsnapの使用を無効にする手段が公開されています。

可能な場合は、これを有効にしておくことをおすすめします。

GitLab Shellを設定する

GitLab Shellチャートのグローバル設定には、複数の項目があります。

global:
  shell:
    port:
    authToken: {}
    hostKeys: {}
    tcp:
      proxyProtocol: false
名前デフォルト説明
port整数22詳細については、下記のportのドキュメントを参照してください。
authTokenGitLab ShellチャートのauthTokenに関するドキュメントを参照してください。
hostKeysGitLab ShellチャートのhostKeysに関するドキュメントを参照してください。
tcp.proxyProtocolブール値false詳細については、下記のTCPプロキシプロトコルを参照してください。

ポート

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

global:
  shell:
    port: 32022

global.shell.portnginx-ingress.controller.service.type=NodePortを組み合わせることにより、NGINXコントローラーのServiceオブジェクトの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を設定する

他のチャートで使用されるグローバルGitLab Pages設定についてのドキュメントは、global.pagesキーの下にあります。

global:
  pages:
    enabled:
    accessControl:
    path:
    host:
    port:
    https:
    externalHttp:
    externalHttps:
    customDomainMode:
    artifactsServer:
    objectStore:
      enabled:
      bucket:
      proxy_download: true
      connection: {}
        secret:
        key:
    localStore:
      enabled: false
      path:
    apiSecret: {}
      secret:
      key:
    namespaceInPath: false
名前デフォルト説明
enabledブール値falseクラスターにGitLab Pagesチャートをインストールするかどうかを決定します。
accessControlブール値falseGitLab Pagesへのアクセス制御を有効にします。
path文字列/srv/gitlab/shared/pagesPagesデプロイ関連のファイルを保存するパス。注: オブジェクトストレージが使用されるため、デフォルトでは未使用です。
host文字列Pagesルートドメイン。
port文字列UIでPagesのURLを構成するために使用されるポート。設定されていない場合、PagesのHTTPS状況に基づいて80または443がデフォルト値として設定されます。
httpsブール値trueGitLab UIにPagesのHTTPS URLを表示するかどうか。global.hosts.pages.httpsglobal.hosts.httpsのどちらよりも優先されます。
externalHttpリスト[]HTTPリクエストがPagesデーモンに到達するまでのIPアドレスのリスト。カスタムドメインをサポートするため。
externalHttpsリスト[]HTTPSリクエストがPagesデーモンに到達するまでのIPアドレスのリスト。カスタムドメインをサポートするため。
customDomainMode文字列カスタムドメインを有効にするように設定します: httpまたはhttps
artifactsServerブール値trueGitLab Pagesでアーティファクトの表示を有効にします。
objectStore.enabledブール値truePagesでオブジェクトストレージの使用を有効にします。
objectStore.bucket文字列gitlab-pagesPagesに関連するコンテンツの保存に使用されるバケット。
objectStore.connection.secret文字列オブジェクトストレージの接続詳細を含むシークレット。
objectStore.connection.key文字列接続シークレットのうち、接続の詳細が格納されるキー。
localStore.enabledブール値falsePagesに関連するコンテンツに(objectStoreではなく)ローカルストレージを使用できるようにします。
localStore.path文字列/srv/gitlab/shared/pagesPagesのファイル保存先のパス。localStoreがtrueに設定されている場合にのみ使用されます。
apiSecret.secret文字列Base64エンコード形式の32ビットAPIキーを内容とするシークレット。
apiSecret.key文字列APIキーシークレットのうち、APIキーが格納されるキー。
namespaceInPathブール値false(ベータ版)ワイルドカードDNSを使用しない設定をサポートするため、URLパスでのネームスペースを有効または無効にします。詳細については、ワイルドカードDNSを使用しないPagesドメインのドキュメントを参照してください。

Webserviceを設定する

(他のチャートでも使用される)Webserviceのグローバル設定についてのドキュメントは、global.webserviceキーの下にあります。

global:
  webservice:
    workerTimeout: 60

workerTimeout

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

global.webservice.workerTimeoutの設定は、最大リクエスト時間には影響しません。最大リクエスト時間を設定するには、次の環境変数を設定します:

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

カスタム認証局

これらの設定は、バンドルされているサードパーティのチャートには影響しません。

社内で発行されたSSL証明書をTLSサービスで使用する場合など、カスタム認証局(CA)を追加する必要が生じることがあります。この機能を提供するため、シークレットまたはConfigMapを通じて、アプリケーションにカスタムルート認証局を適用するためのメカニズムが用意されています。

シークレットまたは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

シークレットのキー名に含まれる.crt拡張子は、Debian update-ca-certificatesパッケージにとって重要です。この手順を実行すれば、カスタムCAファイルがその拡張子でマウントされ、証明書initContainersで処理されることが保証されます。以前は、ドキュメントの記述とは異なり、証明書ヘルパーイメージがalpineベースだった場合、実際にはファイル拡張子が必須ではありませんでした。UBIベースのupdate-ca-trustユーティリティには、同じ要件はないようです。

任意の数のシークレットまたはConfigMapを指定し、それぞれに、PEMエンコードのCA証明書を保持するキーを必要な数だけ設定できます。これらは、global.certificates.customCAsの下のエントリとして設定します。マウントする特定のキーのリストをkeys:に指定しない限り、すべてのキーがマウントされます。すべてのシークレットおよびConfigMapにわたるマウント対象のキーは、いずれも一意でなければなりません。シークレットとConfigMapには任意の名前を付けることができますが、キー名が競合してはいけません

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

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

有効にするには、global.application.createtrueに設定します:

global:
  application:
    create: true

Google GKE Marketplaceなどの一部の環境においては、ClusterRoleリソースの作成が許可されていません。以下の値を設定することにより、アプリケーションカスタムリソース定義に含まれるClusterRoleのコンポーネントと、クラウドネイティブGitLabに同梱の関連チャートを無効にしてください。

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

GitLabベースイメージ

GitLab Helmチャートでは、さまざまな初期化タスクのために1つの共通のGitLabベースイメージを使用します。このイメージではUBIビルドがサポートされており、レイヤーを他のイメージと共有します。

サービスアカウント

GitLab Helmチャートでは、カスタムサービスアカウントを使用してポッドを実行することができます。これは、global.serviceAccountで次のように設定します:

global:
  serviceAccount:
    enabled: false
    create: true
    annotations: {}
    automountServiceAccountToken: false
    ## Name to be used for serviceAccount, otherwise defaults to chart fullname
    # name:
  • global.serviceAccount.enabledの設定は、各コンポーネントでのspec.serviceAccountNameを介したサービスアカウントへの参照を制御します。
  • global.serviceAccount.createの設定は、Helmを介したサービスアカウントオブジェクトの作成を制御します。
  • global.serviceAccount.nameの設定は、サービスアカウントのオブジェクト名と、各コンポーネントが参照する名前を制御します。
  • global.serviceAccount.automountServiceAccountTokenの設定は、デフォルトのServiceAccountアクセストークンをポッドにマウントする必要があるかどうかを制御します。これは、特定のサイドカーが正常に機能するために必要という場合(Istioなど)を除き、有効にしないようにしてください。

global.serviceAccount.create=trueglobal.serviceAccount.nameを一緒に使用しないでください。同じ名前の複数のServiceAccountオブジェクトを作成するようにチャートに指示することになるためです。グローバル名を指定する場合は、代わりにglobal.serviceAccount.create=falseを使用します。

アノテーション

Deployment、Service、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キーの下、または特定のチャートの設定の下で適用できます。例:

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

上記の設定例の場合、Helmチャートによってデプロイされるほぼすべてのコンポーネントに、ラベルセットenvironment: productionが指定されています。GitLab Shellチャートのすべてのコンポーネントが、ラベルセットfoo: barを受け取ることになります。一部のチャートでは、追加のネストが可能です。たとえば、SidekiqチャートとWebserviceチャートでは、設定のニーズに応じて追加のデプロイが可能です:

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

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

ここで利用している一部のチャートは、このラベル設定から除外されています。これらの追加ラベルを受け取るのは、GitLabコンポーネントのサブチャートだけです。

pod

カスタムラベルは、さまざまなデプロイとジョブに適用できます。これらのラベルは、このHelmチャートによって構築される既存のラベルまたは事前設定済みラベルを補完するものです。これらの補足ラベルは、matchSelectorsではnot(利用されません)。

global:
  pod:
    labels:
      environment: production

service

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

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)によりデプロイされるポッド内のすべてのコンテナで、追加の環境変数を公開できます。グローバルレベルで設定された追加の環境変数は、チャートレベルで指定された変数にマージされ、チャートレベルで指定された変数が優先されます。

extraEnvの使用例を以下に示します:

global:
  extraEnv:
    SOME_KEY: some_value
    SOME_OTHER_KEY: some_other_value

extraEnvFrom

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

この実装において、異なるコンテンツタイプで値名を再利用することはサポートされていません。同じ名前を類似の内容でオーバーライドすることは可能ですが、secretKeyRefconfigMapKeyRefなどのソースが混在しないようにしてください。

OAuthを設定する

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

global:
  oauth:
    gitlab-pages: {}
    # secret
    # appid
    # appsecret
    # redirectUri
    # authScope
名前デフォルト説明
secret文字列サービスのOAuth認証情報を含むシークレットの名前。
appIdKey文字列シークレットのうち、サービスのアプリIDが格納されるキー。設定されるデフォルト値はappidです。
appSecretKey文字列シークレットのうち、サービスのアプリシークレットが格納されるキー。設定されるデフォルト値はappsecretです。
redirectUri文字列認証が成功した後、ユーザーがリダイレクトされる先のURI。
authScope文字列apiGitLab APIでの認証に使用されるスコープ。

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

Kerberos

GitLab HelmチャートでKerberosインテグレーションを設定するには、GitLabホストのサービスプリンシパルを指定したKerberos keytabを含むシークレットを、global.appConfig.kerberos.keytab.secret設定に指定する必要があります。keytabファイルがない場合は、Kerberos管理者にお問い合わせください。

次のスニペットを使用してシークレットを作成できます(gitlabネームスペースにチャートをインストールしており、サービスプリンシパルを含むkeytabファイルがgitlab.keytabであると仮定しています):

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

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

falseのままにした場合も、Helmチャートは、ツールボックス、Sidekiq、およびWebサービスのポッドにkeytabをマウントします。それを、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では、Git操作にHTTPプロトコルを使用する場合、認証交換でnegotiateヘッダーが含まれていると基本認証にフォールバックするというGitの制限の回避策として、Kerberosネゴシエーション専用ポートの使用がサポートされています。

現在のところ、GitLab CI/CDを使用する場合に専用ポートの使用は必須です。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の中でGitLab用に終端処理され、設定されます。

nginx-ingress Helmチャートのフォークに関する現在の制限のため、現在のところ、dedicatedPortを指定しても、チャートのnginx-ingressコントローラーで使用するためのポートは公開されません。クラスターのオペレーターが、このポートを自分で公開する必要があります。詳細および可能な回避策については、こちらのチャートイシューを参照してください。

LDAPカスタム許可レルム

ユーザーのLDAP DNがユーザーのKerberosレルムと一致しない場合、LDAPのアイデンティティとKerberosのアイデンティティをリンクするために使用されるドメインのセットを、global.appConfig.kerberos.simpleLdapLinkingAllowedRealmsにより指定できます。詳細については、Kerberosインテグレーションのドキュメントにあるカスタム許可レルムのセクションを参照してください。

送信メール

送信メールは、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パッケージのSMTP設定のドキュメントに、詳しい例が含まれています。

プラットフォーム

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

アフィニティ

アフィニティは、global.antiAffinityglobal.affinityにより設定できます。アフィニティを使用すると、ノードのラベルまたはノードですでに実行されているポッドのラベルに基づいて、ポッドをスケジュール可能なノードを制限できます。これにより、ポッドをクラスター全体に分散させたり、特定のノードを選択したりすることが可能になり、ノードに障害が発生した場合の復元力を高めることができます。

global:
  antiAffinity: soft
  affinity:
    podAntiAffinity:
      topologyKey: "kubernetes.io/hostname"
名前デフォルト説明
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
名前デフォルト説明
priorityClassName文字列ポッドに割り当てられる優先度クラス。

ログローテーション

デフォルトでは、GitLab Helmチャートはログローテーションを実行しません。これにより、長時間実行されるコンテナで、一時的なストレージの問題が発生する可能性があります。

ログローテーションを有効にするには、GITLAB_LOGGER_TRUNCATE_LOGS環境変数をtrueに設定します。詳細については、GitLab Loggerのドキュメントを参照してください。特に、以下の情報を参照してください:

ジョブ

元々、GitLabのジョブには、Helmの.Release.Revisionがサフィックスとして付いていましたが、helm upgrade --installを実行するたびに、何も変更されていなくても常にジョブが更新されてしまうため、理想的な方法ではありませんでした。また、ArgoCDを使用している場合など、helm templateに基づくワークフローとの連携が正しく動作しない原因にもなっていました。ジョブ名に.Release.Revisionを使用するという判断は、ジョブが1回しか実行されず、かつhelm uninstallがジョブを削除しないという前提に基づいていましたが、これは(現在では)間違っています。

GitLab Helmチャート7.9以降では、ジョブ名にはデフォルトで、チャートのアプリバージョンとチャートの値(global.gitlabVersionを含む可能性がある)に基づくハッシュがサフィックスとして付与されます。このアプローチにより、(何も変更されていない場合は)helm templatehelm upgrade --installを複数回実行してもジョブ名は安定して維持されます。また、ジョブの不変フィールドの値を変更した場合でも(名前が新しくなることで新しいジョブに置き換えられ)、デプロイ中にエラーが発生しなくなります。

global.job.nameSuffixOverrideを設定することにより、デフォルトで生成されるハッシュを、カスタムサフィックスでオーバーライドすることができます。このフィールドはテンプレート処理をサポートしているため、.Release.Revisionを名前のサフィックスとして使用していた以前の動作を再現することができます:

global:
  job:
    nameSuffixOverride: '{{ .Release.Revision }}'

すべてのバージョンでlatestのような浮動タグ付けを使用しているなどの理由で、意図的に常に変更をトリガーする場合、デフォルトで生成されるハッシュを、タイムスタンプなどの動的な値でオーバーライドすることができます:

global:
  job:
    nameSuffixOverride: '{{ dateInZone "2006-01-02-15-04-05" (now) "UTC" }}'

または、コマンドラインでhelmを使用することもできます:

helm <command> <options> --set global.job.nameSuffixOverride=$(date +%Y-%m-%d-%H-%M-%S)
名前デフォルト説明
nameSuffixOverride文字列自動的に生成されるハッシュを置き換えるカスタムサフィックス

Traefik

Traefikは、globals.traefikにより設定できます。

global:
  traefik:
    apiVersion: ""
名前デフォルト説明
apiVersion文字列TraefikのリソースのデフォルトのapiVersionをオーバーライドします