グローバル変数を使用してチャートを設定する
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab Self-Managed
ラッパーHelmチャートのインストール時に同じ設定を何度も重複してすることを軽減するため、いくつかの設定はglobalのvalues.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.name、minio.name、およびregistry.nameのセクションを参照してください。 |
externalIP | nil | プロバイダーから要求される外部IPアドレスを設定します。これは、より複雑なnginx.service.loadBalancerIPの代わりに、NGINXチャート内でテンプレート処理されて使用されます。 | |
externalGeoIP | nil | externalIPと同じですが、NGINX Geoチャート用です。統合URLを使用してGitLab Geoサイトの静的IPを設定するために必要です。externalIPとは異なっている必要があります。 | |
https | ブール値 | true | trueに設定されている場合は、NGINXチャートが証明書にアクセスできることを確認する必要があります。Ingressの前にTLSターミネーションがある場合は、global.ingress.tls.enabledを調べるとよいでしょう。外部URLでは、httpsの代わりにhttp://を使用するため、falseに設定します。 |
hostSuffix | 文字列 | 下記を参照。 | |
gitlab.https | ブール値 | false | hosts.httpsまたはgitlab.httpsがtrueの場合、GitLab外部URLではhttp://ではなくhttps://を使用します。 |
gitlab.name | 文字列 | GitLabのホスト名。設定されている場合、global.hosts.domainとglobal.hosts.hostSuffixの設定に関係なくこのホスト名が使用されます。 | |
gitlab.hostnameOverride | 文字列 | WebserviceのIngress設定で使用されているホスト名をオーバーライドします。ホスト名を内部ホスト名に書き換えるWAFの背後からGitLabに到達可能でなければならないという場合に役立ちます(例: gitlab.example.com→gitlab.cluster.local)。 | |
gitlab.serviceName | 文字列 | webservice | GitLabサーバーを操作しているserviceの名前。チャートにより、サービス(および現在の.Release.Name)のホスト名がテンプレート処理され、適切な内部serviceNameが作成されます。 |
gitlab.servicePort | 文字列 | workhorse | GitLabサーバーに到達できるserviceの名前付きポート。 |
keda.enabled | ブール値 | false | HorizontalPodAutoscalersの代わりにKEDA ScaledObjectsを使用します |
minio.https | ブール値 | false | hosts.httpsまたはminio.httpsがtrueの場合、MinIO外部URLではhttp://ではなくhttps://を使用します。 |
minio.name | 文字列 | minio | MinIOのホスト名。設定されている場合、global.hosts.domainとglobal.hosts.hostSuffixの設定に関係なくこのホスト名が使用されます。 |
minio.serviceName | 文字列 | minio | MinIOサーバーを操作しているserviceの名前。チャートにより、サービス(および現在の.Release.Name)のホスト名がテンプレート処理され、適切な内部serviceNameが作成されます。 |
minio.servicePort | 文字列 | minio | MinIOサーバーに到達できるserviceの名前付きポート。 |
registry.https | ブール値 | false | hosts.httpsまたはregistry.httpsがtrueの場合、レジストリの外部URLではhttp://ではなくhttps://を使用します。 |
registry.name | 文字列 | registry | レジストリのホスト名。設定されている場合、global.hosts.domainとglobal.hosts.hostSuffixの設定に関係なくこのホスト名が使用されます。 |
registry.serviceName | 文字列 | registry | レジストリサーバーを操作しているserviceの名前。チャートにより、サービス(および現在の.Release.Name)のホスト名がテンプレート処理され、適切な内部serviceNameが作成されます。 |
registry.servicePort | 文字列 | registry | レジストリサーバーに到達できるserviceの名前付きポート。 |
smartcard.name | 文字列 | smartcard | スマートカード認証のホスト名。設定されている場合、global.hosts.domainとglobal.hosts.hostSuffixの設定に関係なくこのホスト名が使用されます。 |
kas.name | 文字列 | kas | KASのホスト名。設定されている場合、global.hosts.domainとglobal.hosts.hostSuffixの設定に関係なくこのホスト名が使用されます。 |
kas.https | ブール値 | false | hosts.httpsまたはkas.httpsがtrueの場合、KAS外部URLではws://ではなくwss://を使用します。 |
pages.name | 文字列 | pages | GitLab Pagesのホスト名。設定されている場合、global.hosts.domainとglobal.hosts.hostSuffixの設定に関係なくこのホスト名が使用されます。 |
pages.https | 文字列 | global.pages.https、global.hosts.pages.https、またはglobal.hosts.httpsがtrueの場合、プロジェクト設定UIにおいて、GitLab PagesのURLにはhttp://ではなくhttps://を使用します。 | |
ssh | 文字列 | SSH経由でリポジトリを複製するためのホスト名。設定されている場合、global.hosts.domainとglobal.hosts.hostSuffixの設定に関係なくこのホスト名が使用されます。 |
hostSuffix
ベースdomainを使用してホスト名を構成する際にはhostSuffixがサブドメインに付加されますが、独自のnameが設定されているホストには使用されません。
デフォルトでは未設定です。設定されている場合、サブドメインにハイフンとこのサフィックスが付加されます。以下の例では、gitlab-staging.example.comやregistry-staging.example.comのような外部ホスト名が使用されることになります:
global:
hosts:
domain: example.com
hostSuffix: stagingHorizontal 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 | ブール値 | false | monitoring.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-nginx | Ingressリソースのkubernetes.io/ingress.classアノテーションまたはspec.IngressClassNameを制御するグローバル設定。無効にする場合はnone、空にする場合は""に設定します。注: noneまたは""の場合、不要なIngressリソースがチャートによってデプロイされないようにするため、nginx-ingress.enabled=falseに設定してください。 |
enabled | ブール値 | true | サービスでサポートするIngressオブジェクトを作成するかどうかを制御するためのグローバル設定。 |
tls.enabled | ブール値 | true | falseに設定すると、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ですが、ユースケースに応じてImplementationSpecificやExactも使用できます。 |
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コントローラーの設定に影響を与えます。次の表に例を示します。
| プロバイダー | レイヤー | サンプルスニペット |
|---|---|---|
| AWS | 4 | aws/elb-layer4-loadbalancer |
| AWS | 7 | aws/elb-layer7-loadbalancer |
| AWS | 7 | aws/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.secretNameregistry.ingress.tls.secretNameminio.ingress.tls.secretNameglobal.ingress.annotations
global.ingress.useNewIngressForCerts
cert-managerの動作を変更して、毎回動的に作成される新しいIngressを使用してACMEチャレンジ検証を実行するようにするためのグローバル設定。
デフォルトのロジック(global.ingress.useNewIngressForCertsがfalseの場合)は、検証のために既存のIngressを再利用します。このデフォルトは、状況によっては適切ではありません。フラグをtrueに設定すると、検証のたびに新しいIngressオブジェクトが作成されます。
GKE Ingressコントローラーで使用する場合、global.ingress.useNewIngressForCertsをtrueに設定することはできません。
GitLabバージョン
この値は、開発目的か、またはGitLabサポートからの明示的なリクエストがあった場合のみに使用してください。本番環境の設定ファイルでは、この値を使用しないでください。代わりに、Helmを使用したデプロイの説明に従ってバージョンを設定してください。
チャートのデフォルトイメージタグで使用されているGitLabのバージョンは、global.gitlabVersionキーを使用して変更できます:
--set global.gitlabVersion=11.0.1これは、webservice、sidekiq、およびmigrationのチャートで使用されるデフォルトのイメージタグに影響します。gitaly、gitlab-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.mainとglobal.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_production | PostgreSQLサーバーで使用するデータベースの名前。 |
password.useSecret | ブール値 | true | PostgreSQLのパスワードをシークレットまたはファイルから読み取るかどうかを制御します。 |
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 | 整数 | 5432 | PostgreSQLサーバーへの接続に使用するポート。 |
username | 文字列 | gitlab | データベースへの認証に使用するユーザー名。 |
preparedStatements | ブール値 | false | PostgreSQLサーバーとの通信時にプリペアドステートメントを使用するかどうか。 |
databaseTasks | ブール値 | true | GitLabが特定のデータベースに対してデータベースタスクを実行するかどうか。共有ホスト/ポート/データベースがmainと一致する場合、自動的に無効になります。 |
connectTimeout | 整数 | データベース接続を待機する秒数。 | |
keepalives | 整数 | クライアント側のTCP keepalivesを使用するかどうかを制御します(1はオン、0はオフを意味します)。 | |
keepalivesIdle | 整数 | TCPがキープアライブメッセージをサーバーに送信するまでの非アクティブ状態の秒数。値がゼロの場合は、システムのデフォルトを使用します。 | |
keepalivesInterval | 整数 | サーバーによって確認応答されないTCPキープアライブメッセージを再送信するまでの秒数。値がゼロの場合は、システムのデフォルトを使用します。 | |
keepalivesCount | 整数 | サーバーへのクライアント接続が切断されたと見なされるまでに失われる可能性のあるTCP keepalivesの数。値がゼロの場合は、システムのデフォルトを使用します。 | |
tcpUserTimeout | 整数 | 送信されたデータが確認応答されない場合に接続が強制的に閉じられるまでのミリ秒数。値がゼロの場合は、システムのデフォルトを使用します。 | |
applicationName | 文字列 | データベースに接続しているアプリケーションの名前。無効にするには、空白文字列("")に設定します。デフォルトでは、これは実行中のプロセスの名前(sidekiq、pumaなど)に設定されます。 | |
ci.enabled | ブール値 | true | 2つのデータベース接続を有効にします。 |
チャートごとのPostgreSQL
一部の複雑なデプロイでは、このチャートの異なる部分をPostgreSQLの異なる設定で構成することが要件となる場合があります。v4.2.0時点では、global.psql内で使用可能なすべての属性は、gitlab.sidekiq.psqlなどのチャート単位で設定できます。ローカル設定を指定した場合、グローバル値はオーバーライドされ、psql.load_balancingを除き、global.psqlから_継承されていないもの_はすべて継承されます。
PostgreSQLのロードバランシングは、設計上、グローバルからは_決して_継承されません。
PostgreSQL SSL
相互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 | 文字列 | redis | Redisデータベースを操作しているserviceの名前。これが存在し、hostが存在しない場合、チャートはhost値の代わりにサービスのホスト名(および現在の.Release.Name)をテンプレート処理します。これは、RedisをGitLabチャート全体の一部として使用する場合に便利です。 |
port | 整数 | 6379 | Redisサーバーへの接続に使用するポート。 |
database | 整数 | 0 | Redisサーバー上の接続先データベース。 |
user | 文字列 | Redisに認証するために使用するユーザー名(Redis 6.0以降)。 | |
auth.enabled | ブール値 | true | auth.enabledは、Redisインスタンスでパスワードを使用するかどうかの切替機能を提供します。 |
auth.key | 文字列 | Redisのauth.key属性は、パスワードを含むシークレット(下記)内のキーの名前を定義します。 | |
auth.secret | 文字列 | Redisのauth.secret属性は、プル元のKubernetes Secretの名前を定義します。 | |
scheme | 文字列 | redis | Redis URLを生成するために使用するURIスキーム。有効な値は、redis、rediss、および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 | 整数 | 26379 | Redis 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 | ブール値 | false | sentinelAuth.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インスタンスで実行するためのサポートが含まれています。現在のところ、次のとおりです:
| インスタンス | 目的 |
|---|---|
actioncable | ActionCableのPub/Subキューバックエンド |
cache | キャッシュされたデータを保存する |
kas | KAS固有のデータを保存する |
queues | Sidekiqバックグラウンドジョブを保存する |
rateLimiting | RackAttackとアプリケーション制限のためのレート制限の利用状況を保存する |
repositoryCache | リポジトリ関連データを保存する |
sessions | ユーザーセッションデータを保存する |
sharedState | 分散ロックなど、さまざまな永続データを保存する |
traceChunks | ジョブトレースを一時的に保存する |
workhorse | WorkhorseのPub/subキューバックエンド |
インスタンスの数に制限はありません。指定されていないインスタンスは、global.redis.hostで指定されたプライマリRedisインスタンスによって処理されるか、チャートからデプロイされたRedisインスタンスを使用します。唯一の例外は、GitLabエージェントサーバー(KAS)であり、Redis設定を次の順序で検索します:
global.redis.kasglobal.redis.sharedStateglobal.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 | 整数 | 6379 | Redisサーバーへの接続に使用するポート。 |
.password.enabled | ブール値 | true | password.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に接続するには、次のようにします:
rediss(sは2個)スキームパラメータを使用するように設定を更新します。設定で、
authClientsをfalseに設定します:global: redis: scheme: rediss redis: tls: enabled: true authClients: falseRedisのデフォルトは相互TLSであり、それはすべてのチャートコンポーネントでサポートしているわけではないため、この設定は必須です。
BitnamiのTLSを有効にする手順に従います。チャートコンポーネントが、Redis証明書の作成に使用する認証局を信頼していることを確認します。
任意。カスタム認証局を使用する場合については、カスタム認証局のグローバル設定を参照してください。
パスワードレス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-issuerbucket、certificate、httpSecret、notificationSecretの設定の詳細については、レジストリチャート内のドキュメントを参照してください。
enabled、host、api、tokenIssuerの詳細については、コマンドラインオプションおよび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-tlsGitalyホスト
Gitalyは、Gitリポジトリへの高レベルRPCアクセスを提供するサービスであり、GitLabによってなされるすべてのGit呼び出しを処理します。
管理者は、次の方法でGitalyノードを使用することもできます:
- チャート内部 (Gitalyチャートを介して
StatefulSetの一部として)。 - チャートの外部(外部ペットとして)。
- 内部ノードと外部ノードの両方を使用する混合環境。
新規プロジェクト用に使用されるノードの管理の詳細については、リポジトリストレージパスのドキュメントを参照してください。
gitaly.hostが指定されている場合、gitaly.internalプロパティとgitaly.externalプロパティは無視されます。非推奨のGitaly設定を参照してください。
現時点で、Gitaly認証トークンは、内部または外部のすべてのGitalyサービスで同一であることが期待されています。これらが揃っていることを確認してください。詳細については、イシュー#1992を参照してください。
internal
現在のところ、internalキーは1つのキーnamesだけで構成されており、これはチャートによって管理されるストレージ名のリストです。リスト内の名前ごとに(論理的な順序で)、1つのポッドが起動します。その名前は${releaseName}-gitaly-${ordinal}です(ordinalはnamesリスト内のインデックス)。動的なプロビジョニングが有効になっている場合、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ノードの両方を使用することは可能ですが、次の点に注意してください:
defaultというノードが常に存在する必要があります。内部ではこれがデフォルトで提供されます。- 外部ノードが最初に入力され、次に内部が入力されます。
examplesフォルダーに、内部ノードと外部ノードの混合設定の例があります。
authToken
GitalyのauthToken属性には、次の2つのサブキーがあります:
secretは、プル元のKubernetesSecretの名前を定義します。keyは、上記のシークレットのうちauthTokenを含むキーの名前を定義します。
すべてのGitalyノードは、同じ認証トークンをmust(共有する必要があります)。
非推奨のGitaly設定
| 名前 | 型 | デフォルト | 説明 |
|---|---|---|---|
host (非推奨) | 文字列 | 使用するGitalyサーバーのホスト名。serviceNameの代わりとして省略できます。この設定を使用すると、internalまたはexternalの値がオーバーライドされます。 | |
port (非推奨) | 整数 | 8075 | Gitalyサーバーへの接続に使用するポート。 |
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 | ブール値 | false | Praefectを有効にするかどうか。 |
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を設定する
Webservice 、Sidekiq 、および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 | ブール値 | true | pingの使用のサポートを無効にするフラグ。 |
enableSeatLink | ブール値 | true | シートリンクのサポートを無効にするフラグ。 |
enableImpersonation | nil | 管理者によるユーザーの代理を無効にするフラグ。 | |
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_onlyをtrueに変更して設定をテストするとよいかもしれません。
相対URLルートを設定する
- ステータス: ベータ
GitLabは独自のドメインまたはサブドメインにインストールする必要がありますが、必要に応じて相対URLの下にインストールできます。たとえばhttps://example.com/gitlabなどです。
すべてのWebサービスデプロイのIngressには、このプレフィックスが付きます。
global:
appConfig:
relativeUrlRoot: "/gitlab"
hosts:
domain: example.com
gitlab:
name: example.comdefaultProjectsFeatures
新規プロジェクト作成時に、対応する各機能をデフォルトで有効にするかどうかを決定するフラグ。どのフラグもデフォルトはtrueです。
defaultProjectsFeatures:
issues: true
mergeRequests: true
wiki: true
snippets: true
builds: true
containerRegistry: trueGravatar/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 | ブール値 | false | Bizibleスクリプトを有効にする場合はtrueに設定。 |
統合されたオブジェクトストレージ
以下のセクションではオブジェクトストレージの個々の設定方法について説明していますが、これに加えて、これらの項目に共通の設定を使いやすくするため、統合されたオブジェクトストレージ設定を追加しました。object_storeを活用すると、connectionを一度だけ設定すれば、オブジェクトストレージでサポートされる機能のうち、個別にconnectionプロパティが設定されていないものすべてに対してその接続設定が使用されます。
enabled: true
proxy_download: true
storage_options:
connection:
secret:
key:| 名前 | 型 | デフォルト | 説明 |
|---|---|---|---|
enabled | ブール値 | false | 統合されたオブジェクトストレージの使用を有効にします。 |
proxy_download | ブール値 | true | GitLab経由のすべてのダウンロードについて、bucketから直接ダウンロードする代わりにプロキシを有効にします。 |
storage_options | 文字列 | {} | 下記を参照。 |
connection | 文字列 | {} | 下記を参照。 |
プロパティの構造は共有されており、ここに示されているすべてのプロパティは、以下の個々の項目によってオーバーライドできます。connectionプロパティの構造は同じです。
デフォルト以外の値を使用する場合に、項目ごとに(global.appConfig.artifacts.bucketなど)設定する必要があるのは、bucket、enabled、proxy_downloadのプロパティだけです。
接続にAWSプロバイダー(同梱されているMinIOなどのS3互換プロバイダー)を使用する場合、GitLab Workhorseはストレージ関連のすべてのアップロードをオフロードできます。この統合設定を使用する場合、これは自動的に有効になります。
バケットを指定する
オブジェクトは、タイプごとに異なるバケットに格納する必要があります。デフォルトで、GitLabがタイプごとに使用するバケット名は次のとおりです:
| オブジェクトタイプ | バケット名 |
|---|---|
| CIアーティファクト | gitlab-artifacts |
| Git LFS | git-lfs |
| パッケージ | gitlab-packages |
| アップロード | gitlab-uploads |
| 外部マージリクエストの差分 | gitlab-mr-diffs |
| Terraformステート | gitlab-terraform-state |
| CIセキュアファイル | gitlab-ci-secure-files |
| 依存プロキシ | gitlab-dependency-proxy |
| Pages | gitlab-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_id | Amazonリソース名。これが必要になるのはserver_side_encryptionでaws: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-1234567890abLFS、アーティファクト、アップロード、パッケージ、外部MR差分、依存プロキシ
これらの設定の詳細を以下に示します。bucketプロパティのデフォルト値を除けば、構造的に同じなので、ドキュメントを個別に繰り返すことはしません。
enabled: true
proxy_download: true
bucket:
connection:
secret:
key:| 名前 | 型 | デフォルト | 説明 |
|---|---|---|---|
enabled | ブール値 | LFS、アーティファクト、アップロード、およびパッケージのデフォルトはtrue | オブジェクトストレージでこれらの機能の使用を有効にします。 |
proxy_download | ブール値 | true | GitLab経由のすべてのダウンロードについて、bucketから直接ダウンロードする代わりにプロキシを有効にします。 |
bucket | 文字列 | さまざま | オブジェクトストレージプロバイダーから使用するバケットの名前。サービスに応じて、デフォルトはgit-lfs、gitlab-artifacts、gitlab-uploads、gitlab-packagesのどれかになります。 |
connection | 文字列 | {} | 下記を参照。 |
connection
connectionプロパティは、Kubernetes Secretに移行されました。このシークレットの内容は、YAML形式のファイルでなければなりません。デフォルトは{}であり、global.minio.enabledがtrueの場合は無視されます。
このプロパティには、secretとkeyの2つのサブキーがあります。
secretはKubernetes Secretの名前です。外部オブジェクトストレージを使用するには、この値が必要です。keyは、YAMLブロックが含まれるシークレット内でのキーの名前です。デフォルトはconnectionです。
有効な設定キーについては、GitLabジョブアーティファクトの管理のドキュメントに記載されています。これはFogに対応しており、プロバイダーモジュールに応じて異なります。
AWSとGoogleプロバイダーの場合の例が、examples/objectstorageにあります。
connectionの内容を含むYAMLファイルを作成したら、このファイルを使用してKubernetesにシークレットを作成します。
kubectl create secret generic gitlab-rails-storage \
--from-file=connection=rails.yamlwhen(外部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 secondsTLSの設定
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-caLDAP
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または自己署名証明書を使用する場合は、以下を実行する必要があります:
カスタム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その上で、以下を指定します:
# 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 | ブール値 | false | Cisco Duoとのインテグレーションを有効または無効にします。 |
hostname | 文字列 | Cisco Duo APIホスト名 | |
integrationKey | 文字列 | Cisco Duo APIインテグレーションのキー。 | |
secretKey | Cisco 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 |
autoSignInWithProvider | nil | |
blockAutoCreatedUsers | ブール値 | true |
enabled | ブール値 | false |
externalProviders | [] | |
providers | [] | |
syncProfileAttributes | ['email'] | |
syncProfileFromProvider | [] |
providers
providersは、ソースからインストールする場合と同じように、gitlab.ymlの設定に使用されるマップの配列として提示されます。サポートされているプロバイダーの利用可能な選択については、GitLabドキュメントを参照してください。デフォルトは[]です。
このプロパティには、secretとkeyの2つのサブキーがあります:
secret:*(必須)*プロバイダーブロックを含むKubernetesSecretの名前。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に渡す方法を選択するかもしれません。
cronジョブ関連の設定
Sidekiqには、cronスタイルのスケジュールを使用して定期的に実行されるように設定できるメンテナンスジョブが含まれています。いくつかの例を以下に示します。ジョブのその他の例については、サンプルgitlab.ymlのcron_jobsとee_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 | ブール値 | false | gitlab_docsを有効または無効にする |
host | 文字列 | "" | ドキュメントホスト |
OpenID Connectトークンの有効期限
OpenID Connect(OIDC)プロバイダーのトークンの有効期限を設定します。
global:
appConfig:
oidcProvider:
openidIdTokenExpireInSeconds: 120| 名前 | 型 | デフォルト | 説明 |
|---|---|---|---|
openidIdTokenExpireInSeconds | 整数 | 120 | IDトークンが有効期限切れになるまでの時間(秒単位)。 |
スマートカード認証の設定
global:
appConfig:
smartcard:
enabled: false
CASecret:
clientCertificateRequiredHost:
sanExtensions: false
requiredForGitAccess: false| 名前 | 型 | デフォルト | 説明 |
|---|---|---|---|
enabled | ブール値 | false | スマートカード認証を有効または無効にする。 |
CASecret | 文字列 | CA証明書が格納されているシークレットの名前。 | |
clientCertificateRequiredHost | 文字列 | スマートカード認証に使用するホスト名。デフォルトでは、指定された、または計算によるスマートカードホスト名が使用されます。 | |
sanExtensions | ブール値 | false | ユーザーと証明書を照合するためにSAN拡張機能を使用できるようにします。 |
requiredForGitAccess | ブール値 | false | Gitアクセスのためのスマートカードサインインでブラウザセッションを必須にします。 |
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: trueWorkhorseを設定する
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 | 文字列 | http | APIエンドポイントのスキーム |
host | 文字列 | APIエンドポイントの完全修飾ホスト名またはIPアドレス。serviceNameがあればそれをオーバーライドします。 | |
port | 整数 | 8181 | 関連するAPIサーバーのポート番号。 |
tls.enabled | ブール値 | false | trueに設定すると、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のドキュメントを参照してください。 |
authToken | GitLab ShellチャートのauthTokenに関するドキュメントを参照してください。 | ||
hostKeys | GitLab ShellチャートのhostKeysに関するドキュメントを参照してください。 | ||
tcp.proxyProtocol | ブール値 | false | 詳細については、下記のTCPプロキシプロトコルを参照してください。 |
ポート
IngressがSSHトラフィックを渡すために使用するポートと、GitLabから提供されるSSH URLで使用されるポートは、global.shell.portにより制御できます。これは、サービスがリッスンするポートと、プロジェクトUIで提供されるSSHクローンURLに反映されます。
global:
shell:
port: 32022global.shell.portとnginx-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: NodePortTCPプロキシプロトコル
SSH Ingressでプロキシプロトコルの処理を有効にすると、プロキシプロトコルヘッダーを追加するアップストリームプロキシからの接続を適切に処理できます。それにより、SSHが追加のヘッダーを受信してSSHが損なわれるのを防ぐことができます。
プロキシプロトコルの処理を有効にすることが必要になる環境としてよくあるのは、クラスターへの受信接続を処理するELBでAWSを使用している場合です。そのための適切な設定については、AWSレイヤー4ロードバランサーの例を参照してください。
global:
shell:
tcp:
proxyProtocol: true # default falseGitLab 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 | ブール値 | false | GitLab Pagesへのアクセス制御を有効にします。 |
path | 文字列 | /srv/gitlab/shared/pages | Pagesデプロイ関連のファイルを保存するパス。注: オブジェクトストレージが使用されるため、デフォルトでは未使用です。 |
host | 文字列 | Pagesルートドメイン。 | |
port | 文字列 | UIでPagesのURLを構成するために使用されるポート。設定されていない場合、PagesのHTTPS状況に基づいて80または443がデフォルト値として設定されます。 | |
https | ブール値 | true | GitLab UIにPagesのHTTPS URLを表示するかどうか。global.hosts.pages.httpsとglobal.hosts.httpsのどちらよりも優先されます。 |
externalHttp | リスト | [] | HTTPリクエストがPagesデーモンに到達するまでのIPアドレスのリスト。カスタムドメインをサポートするため。 |
externalHttps | リスト | [] | HTTPSリクエストがPagesデーモンに到達するまでのIPアドレスのリスト。カスタムドメインをサポートするため。 |
customDomainMode | 文字列 | カスタムドメインを有効にするように設定します: httpまたはhttps。 | |
artifactsServer | ブール値 | true | GitLab Pagesでアーティファクトの表示を有効にします。 |
objectStore.enabled | ブール値 | true | Pagesでオブジェクトストレージの使用を有効にします。 |
objectStore.bucket | 文字列 | gitlab-pages | Pagesに関連するコンテンツの保存に使用されるバケット。 |
objectStore.connection.secret | 文字列 | オブジェクトストレージの接続詳細を含むシークレット。 | |
objectStore.connection.key | 文字列 | 接続シークレットのうち、接続の詳細が格納されるキー。 | |
localStore.enabled | ブール値 | false | Pagesに関連するコンテンツに(objectStoreではなく)ローカルストレージを使用できるようにします。 |
localStore.path | 文字列 | /srv/gitlab/shared/pages | Pagesのファイル保存先のパス。localStoreがtrueに設定されている場合にのみ使用されます。 |
apiSecret.secret | 文字列 | Base64エンコード形式の32ビットAPIキーを内容とするシークレット。 | |
apiSecret.key | 文字列 | APIキーシークレットのうち、APIキーが格納されるキー。 | |
namespaceInPath | ブール値 | false | (ベータ版)ワイルドカードDNSを使用しない設定をサポートするため、URLパスでのネームスペースを有効または無効にします。詳細については、ワイルドカードDNSを使用しないPagesドメインのドキュメントを参照してください。 |
Webserviceを設定する
(他のチャートでも使用される)Webserviceのグローバル設定についてのドキュメントは、global.webserviceキーの下にあります。
global:
webservice:
workerTimeout: 60workerTimeout
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アプリケーションを識別するために作成できます。バージョンv1beta1のApplication CRDがすでにクラスターにデプロイされている必要があります。
有効にするには、global.application.createをtrueに設定します:
global:
application:
create: trueGoogle GKE Marketplaceなどの一部の環境においては、ClusterRoleリソースの作成が許可されていません。以下の値を設定することにより、アプリケーションカスタムリソース定義に含まれるClusterRoleのコンポーネントと、クラウドネイティブGitLabに同梱の関連チャートを無効にしてください。
global:
application:
allowClusterRoles: false
nginx:
controller:
scope:
enabled: true
gitlab-runner:
rbac:
clusterWideAccess: false
installCertmanager: falseGitLabベースイメージ
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=trueとglobal.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: productionservice
カスタムラベルをサービスに適用することができます。これらのラベルは、この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_valueextraEnvFrom
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この実装において、異なるコンテンツタイプで値名を再利用することはサポートされていません。同じ名前を類似の内容でオーバーライドすることは可能ですが、secretKeyRefやconfigMapKeyRefなどのソースが混在しないようにしてください。
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 | 文字列 | api | GitLab 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.keytabGitの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.antiAffinityとglobal.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/hostnametopology.kubernetes.io/zonetopology.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 templateやhelm 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をオーバーライドします |